pliego de prescripciones tecnicas particulares … · las subredes de acceso constituyen la puerta...

Teodoro Dublang margolaria,25 – 3garren solairu Pintor Teodoro Dublang, 25 – 3ª planta 01008 Vitoria-Gasteiz

Tel.: 945 16 14 13 Fax: 945 16 16 00

[email protected] www.vitoria-gasteiz.org

Idazkaritza Teknikoaren Zerbitzua

Servicio de Secretaría Técnica

Udal Administrazioaren Saila Informazionaren Teknologiak

Departamento de Administración Municipal Tecnologías de la Información

PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA LA CONTRATACIÓN DE LA REORGANIZACIÓN DE LA ARQUITECTUR A DE RED Y SEGURIDAD

2 de 24

NDICE

1. OBJETIVOS DEL PROYECTO __________________________ ____________________ 4

2. ALCANCE DEL PROYECTO ____________________________ ____________________ 4

3. DESCRIPCIÓN DEL PROYECTO ____________________________________________ 5

3.1. ARQUITECTURA DE RED ACTUAL ____________________ _______________ 5

3.1.1. ELEMENTOS DE LA ARQUITECTURA 7 3.1.2. SUBREDES INTERNAS 7 3.1.3. SUBREDES DE ACCESO 8

3.2. ARQUITECTURA DE RED OBJETIVO __________________ _______________ 8

3.2.1. ELEMENTOS DE LA ARQUITECTURA 10 3.2.2. SUBREDES INTERNAS 11 3.2.3. SUBREDES DE ACCESO 11 3.2.4. ACCESO A INTERNET 11

3.3. SERVICIOS DE SEGURIDAD AVANZADA _______________ ______________ 12

3.3.1. HERRAMIENTA DE IPS 12 3.3.2. HERRAMIENTA DE SANDBOXING 13 3.3.3. TRÁFICO WEB SEGURO: FILTRADO WEB + ANTIVIRUS 13 3.3.4. CORREO ELECTRÓNICO SEGURO: ANTISPAM + ANTIVI RUS 14

4. REQUISITOS MÍNIMOS___________________________________________________ 14

4.1. REQUISITOS GENERALES _________________________________________ 14

4.2. CONSOLAS DE LOS FIREWALL______________________ _______________ 14

4.3.SERVICIOS ESPECÍFICOS EN LOS FW _______________________________ 15

4.4.HERRAMIENTAS DE IPS ___________________________________________ 15

4.5.HERRAMIENTA DE SANBOXING _______________________ _____________ 16

4.6.SOLUCIÓN DE NAVEGACIÓN WEB SEGURA ______________ ____________ 17

4.7.SOLUCIÓN DE CORREO ELECTRÓNICO SEGURO _____________________ 18

4.8.PLAN DE MIGRACIÓN ______________________________ _______________ 18

4.9.REVISIÓN DE LA ARQUITECTURA DE RED Y SEGURIDAD _ _____________ 20

4.10.REQUISITOS DE FORMACIÓN _____________________________________ 20

3 de 24

5. ENTREGABLES A LA PRESENTACIÓN DEL PLIEGO ________ __________________ 20

5.1. PLAN DIRECTOR DEL PROYECTO ____________________ ______________ 20

5.2. PLAN DE MIGRACIÓN _____________________________ ________________ 21

5.3. DOCUMENTACIÓN TÉCNICA _______________________________________ 21

5.4. PLAN DE FORMACIÓN _____________________________ _______________ 21

6. ENTREGABLES A LA CONCLUSIÓN DEL PROYECTO________ _________________ 22

6.1. INFORME DE LA REVISIÓN DE LOS FIREWALLS _______ _______________ 22

6.2. INFORME DE LA REVISIÓN DE LA ARQUITECTURA DE R ED Y SEGURIDAD 22

6.3. INFORME DE LA EJECUCIÓN DEL PROYECTO__________ ______________ 22

6.4. DOCUMENTACIÓN DE LA FORMACIÓN _________________ _____________ 22

6.5. DOCUMENTACIÓN TÉCNICA _______________________________________ 23

4 de 24

INTRODUCCIÓN

El objeto de este documento es definir las indicaciones que deben seguirse para la implantación del proyecto Reorganización de la Arquitectura de Red y de Seguridad del Ayuntamiento de Vitoria-Gasteiz.

El Ayuntamiento parte para este proyecto de una arquitectura de red existente en la que se cuenta con unos dispositivos concretos de unos fabricantes concretos. Además, se dispone de tres parejas de firewalls de reciente adquisición. Como resultado de la implantación del proyecto se quiere llegar a una nueva arquitectura de red que ha sido consensuada en reuniones previas con expertos en redes y seguridad externos, en la que se integren las parejas de firewalls de reciente adquisición y sobre la que se implementen un conjunto de herramientas de seguridad también consensuadas con expertos externos.

1. OBJETIVOS DEL PROYECTO

El objetivo principal del proyecto Reorganización de la Arquitectura de Red y de Seguridad es dotar al Ayuntamiento de Vitoria-Gasteiz de una arquitectura de red robusta, escalable y concebida como un bloque en la que se incluya una capa de seguridad adicional que mitigue una parte de los riesgos de ciberataques que existen hoy en día. Se quieren potenciar las defensas ante riesgos provenientes de amenazas en Internet y, especialmente, las que se transmiten a través del correo electrónico y la navegación web.

Se fijan, además, varios objetivos secundarios. El primero es reducir el número de tecnologías que deben gestionar los técnicos de comunicaciones del Ayuntamiento con el fin de facilitar un nivel de conocimiento más profundo de los elementos que forman parte de la arquitectura de red. Además se quieren sustituir los equipamientos obsoletos y migrar su funcionalidad a equipamiento moderno. Por último, se persigue identificar mejoras tanto en la arquitectura de red como en las medidas de seguridad que puedan ser implantadas en proyectos futuros.

2. ALCANCE DEL PROYECTO

Forma parte del alcance del proyecto diseñar un plan de migración robusto que permita integrar sobre la arquitectura de red actual los firewalls de reciente adquisición y las medidas de seguridad que se proponen en el pliego hasta alcanzar la arquitectura objetivo.

Forma parte del alcance del proyecto proveer las herramientas de seguridad que se proponen en el pliego del proyecto.

Queda fuera del alcance del proyecto proponer una arquitectura de red final distinta de la que se describe en el pliego. Sí se considera como parte del proyecto una fase de análisis de la arquitectura de red y seguridad objetivo que permita introducir mejoras en la misma bien en el presente proyecto o bien en proyectos futuros.

Queda fuera del alcance del proyecto proponer la adquisición de nuevos firewalls. El objetivo es introducir los firewall adquiridos recientemente y no sustituirlos por otros nuevos.

Todos los firewalls que forman parte de la arquitectura de red objetivo cuentan con un licenciamiento recientemente renovado. Queda fuera del alcance del proyecto modificar dicho.

5 de 24

Queda fuera del alcance el proyecto proponer herramientas de seguridad distintas de las que se describen en el pliego y que han sido consensuadas previamente. De nuevo, ya se ha considerado como parte del proyecto una fase de análisis de la arquitectura de red y seguridad objetivo que permita introducir mejoras en la misma bien en el presente proyecto o bien en proyectos futuros.

3. DESCRIPCIÓN DEL PROYECTO

El proyecto parte de la arquitectura corporativa actual de red, la cual se quiere migrar a una arquitectura de red objetivo consensuada previamente con expertos en redes y seguridad externos y a la que, además, se quiere dotar de unas medidas de seguridad adicionales.

3.1. ARQUITECTURA DE RED ACTUAL

En este apartado se describe la arquitectura actual de la red corporativa del Ayuntamiento. Será el punto de partida para migrar a la arquitectura de red objetivo como paso previo a la implementación de medidas de seguridad adicionales.

6 de 24

FWSM

EDIFICIOS MUNICIPALES

ROUTER ACCESO ÚNICO

FW PyV Subredes de trabajo no protegidas

Subredes de trabajo

protegidas

Subredes de servidores

DMZ wifi

ROUTING NEXUS

Subredes de acceso wifi

INTERNET

FW EXTERNO

Entidades Colaboradoras

Usuarios Autorizados

Mediatecas

Otras M2M

Otros Edificios

Municipales

VPN

VPN

Intravit

DMZ PyV

VPN SSL

VPN

AMVISA

KUTXABANK

EJIE DFA

NGN

DMZ VDI

DMZ Internet

Figura 1: arquitectura de red actual del Ayuntamiento de Vitoria-Gasteiz.

7 de 24

3.1.1. ELEMENTOS DE LA ARQUITECTURA

• FWSM: son 2 módulos Cisco FWSM en switches Catalyst 6500 funcionando en cluster activo-pasivo.

• FW Externo: son 2 appliances Checkpoint 12400 en cluster activo-pasivo.

• FW PyV: son 2 Fortigate110C en cluster activo-pasivo.

• Firewall de AMVISA: es un Fortigate 300A.

• Firewall de EJIE: es un Fortigate 110C.

• Router de la DFA (Diputación Foral de Álava): es un cisco serie 800.

• Finalizador de túneles VPN SSL: es un Junos Pulse Gateway MAG6610 con un módulo de servicio MAG-SM160.

• Routing Nexus: integrado por 2 Nexus 5672UP con licencia de capa 3 y con alta disponibilidad mediante HSRP.

3.1.2. SUBREDES INTERNAS

Incluyen a las redes corporativas del Ayuntamiento. Son tanto las redes de trabajo de los empleados como las redes de servidores. Están representadas en la arquitectura como nubes de color amarillo (acceso controlado por firewall) o blanco (acceso no controlado por firewall). Se distinguen varios grupos de subredes:

• SUBREDES DE TRABAJO NO PROTEGIDAS: son aquellas subredes de trabajo con acceso no controlado por firewall.

• SUBREDES DE TRABAJO PROTEGIDAS: son aquellas subredes de trabajo con acceso controlado por el firewall interno.

• SUBRED DE AMVISA: es un caso particular de subred de trabajo con acceso controlado por firewall, puesto que el firewall que controla el acceso es un firewall exclusivo en lugar de ser el firewall interno.

• SUBREDES DE SERVIDORES: son distintas redes de servidores, de producción o desarrollo, cuyo acceso está controlado por el firewall interno.

• DMZs: son redes de servidores cuyo acceso está controlado por el firewall externo o por el firewall de PyV. En la actualidad existen 3 DMZs:

o DMZ de Internet: es la DMZ para los servicios municipales con acceso desde Internet. Su acceso está controlado por el firewall externo.

o DMZ wifi: es la DMZ para la infraestructura de acceso wifi. Su acceso está controlado por el firewall de PyV.

o DMZ PyV: es la DMZ que da servicio a distintas redes de usuario de PyV. Su acceso está controlado por el firewall de PyV.

8 de 24

3.1.3. SUBREDES DE ACCESO

Las subredes de acceso constituyen la puerta de entrada de entidades o servicios concretos y controlados. Están representadas en la arquitectura como nubes de color gris claro. Se distinguen varios grupos de subredes:

• SERVICIOS DE OPERADORA: a través del router de acceso único se proporcionan diversos servicios de operadora como pueden ser:

o M2M: a través de la red M2M se da acceso controlado a distintos dispositivos móviles.

o Intravit: es otro tipo de red de acceso controlado para dispositivos móviles.

o Acceso a la NGN para el servicio de telefonía IP.

• SERVICIOS CIUDADANOS: se dan distintos servicios a ciudadanos a través de infraestructuras municipales. Entre ellos destacan:

o Servicio de navegación wifi.

o Mediatecas.

o Etc.

• ENTIDADES COLABORADORAS: existen distintos tipos de conexión punto a punto con entidades colaboradoras del Ayuntamiento. Entre ellos:

o Entidades con conexión directa de fibra:

� EJIE: acceso regulado por un firewall exclusivo.

� Diputación Foral de Álava.

� Kutxabank: acceso regulado por el firewall interno.

o Entidades con conexión VPN Lan2Lan: estas entidades acceden a distintos servicios internos del Ayuntamiento.

o Usuarios autorizados con conexión VPN Client2Lan o VPN SSL.

• ACCESOS MUNICIPALES EXTERIORES: se dan diversos casos de accesos municipales a través de las subredes de acceso. Entre ellos:

o Edificios municipales con conexión VPN Lan2Lan: aquellos edificios a los que no se llega por fibra óptica u otros medios que permita integrarlos en las subredes internas se conectan mediante línea de operadora a Internet y se configura una VPN Lan2Lan para dotarles de conectivicad con el resto del Ayuntamiento.

o Usuarios autorizados con conexión VPN Client2Lan o VPN SSL.

3.2. ARQUITECTURA DE RED OBJETIVO

En este apartado se describe la arquitectura de red a la que se quiere llegar y sobre la que se quieren implantar las medidas de seguridad adicionales que se describen posteriormente. En ella se eliminan los dispositivos obsoletos y se introducen las parejas de firewalls recientemente adquiridas (Fortigate 600D, Checkpoint 4600 y Fortigate 60D).

9 de 24

FW INTERNO

EDIFICIOS MUNICIPALES

ROUTER ACCESO ÚNICO

Subredes de trabajo no protegidas

Subredes de trabajo

protegidas

Subredes de servidores

DMZ wifi

ROUTING NEXUS

Subredes de acceso wifi

INTERNET

FW EXTERNO

Entidades Colaboradoras

VPN

Usuarios Autorizados

Mediatecas

Otras

M2M

Otros Edificios

Municipales

VPN

VPN

Intravit

DMZ PyV

AMVISA

KUTXABANK EJIE

DFA

FW ACCESO

NGN

VPN SSL

VPN SSL

DMZ VDI

DMZ Internet

FG60D

Figura 2: arquitectura de red objetivo del Ayuntamiento de Vitoria-Gasteiz.

10 de 24

3.2.1. ELEMENTOS DE LA ARQUITECTURA

Los elementos que forman parte de la arquitectura de red objetivo son los que se listan a continuación:

• FW INTERNO: son 2 appliances Fortigate 600D en cluster activo-pasivo.

• FW EXTERNO: son 2 appliances Checkpoint 12400 en cluster activo-pasivo.

• FW ACCESO: son 2 appliances Checkpoint 4600 en cluster activo-pasivo.

• FG60D: son 2 appliances Fortigate 60D en cluster activo-pasivo.

• Finalizador de túneles VPN SSL: es un Junos Pulse Gateway MAG6610 con un módulo de servicio MAG-SM160.

• Rounting Nexus: integrado por 2 Nexus 5672UP con licencia de capa 3 y con alta disponibilidad mediante HSRP.

• Router de acceso único: es un router de Telefónica a través del cuál se accede a servicios contratados como son NGN, M2M o Intravit.

Todos los elementos anteriores están disponibles en la actualidad. Ambas parejas de nodos Checkpoint están instaladas y configuradas en su disposición final repartidas entre ambos CPDs. Las parejas de nodos Fortigate 600D y 60D no están instaladas.

La relación de licencias y mantenimientos con las que cuentan los firewall de la red es la siguiente:

FW INTERNO:

• Soporte 24x7 con respuesta en 5 horas.

• Licencia de fw básico más bundle UTM.

FW EXTERNO:


• Licencia Next Generation Firewall (fw + VPN + application control + IPS).

FW DE ACCESO:


• Licencia de fw básico (fw + VPN).

FG60D:


• Licencia de fw básico más bundle UTM.

Es objetivo del proyecto introducir en la arquitectura los nuevos dispositivos y eliminar aquellos dispositivos obsoletos cuya funcionalidad es asumida por los nuevos dispositivos.

11 de 24

3.2.2. SUBREDES INTERNAS

Las subredes internas son las mismas que aparecían en el apartado correspondiente a la arquitectura de red actual. Es objetivo del proyecto reorganizar las redes internas para que queden dispuestas tal y como aparecen en la arquitectura objetivo.

3.2.3. SUBREDES DE ACCESO

Las subredes de acceso son las mismas que aparecían en el apartado correspondiente a la arquitectura de red actual. Es objetivo del proyecto reorganizar las redes de acceso para que queden dispuestas tal y como aparecen en la arquitectura objetivo.

3.2.4. ACCESO A INTERNET

En cuanto al acceso a Internet de la arquitectura de red objetivo, se pueden destacar los siguientes puntos:

• El tráfico hacia Internet se ha dividido en 2 bloques:

o Tráfico de navegación web: este bloque incluye tanto la navegación de los trabajadores municipales desde las subredes internas como la navegación de los servicios ciudadanos desde las subredes de acceso. Es un tipo de tráfico que no necesitaría una IP estática para funcionar.

o Tráfico corporativo: este bloque incluye a todos aquellos servicios corporativos que requieren una IP estática en su relación con Internet, tanto de entrada como de salida. Entre ellos están:

� Servicios web, como la web municipal, los blogs o la sede electrónica.

� Correo electrónico.

� DNS.

� VPNs.

� …

• Todo el tráfico corporativo se intercambia con Internet únicamente a través del FW Externo.

• Todo el tráfico de navegación se intercambia con Internet únicamente a través del FW de Acceso.

• El tráfico corporativo utiliza líneas de operadora diferentes a las que utiliza el tráfico de navegación.

• Ambos tipos de tráfico utilizan dos líneas de operadora distintas.

• El FW Externo gestiona la alta disponibilidad y el reparto de carga entre las 2 líneas de tráfico corporativo a través de la funcionalidad ISP Redundancy.

• El FW de Acceso no accede directamente a Internet, sino que lo hace a través de una pareja de Fortigate 60D en cluster activo-pasivo con licencia UTM que se encargan de 2 tareas:

12 de 24

o Reparto de tráfico entre las distintas líneas de navegación con gestión de las posibles caídas de una de ellas repartiendo el tráfico entre las demás.

o Filtrado básico de contenidos, control de aplicaciones y análisis antivirus.

Un resumen de todo lo anterior se representa en la siguiente figura:

Figura 3: arquitectura de del acceso a Internet de la red del Ayuntamiento de Vitoria-Gasteiz.

3.3. SERVICIOS DE SEGURIDAD AVANZADA

Partiendo de la arquitectura de red objetivo descrita en el apartado anterior, es objetivo del proyecto dotar a la red del Ayuntamiento de los siguientes servicios de seguridad avanzada:

3.3.1. HERRAMIENTA DE IPS

Se requiere, al menos, configurar el servicio IPS de los FW Externos. Se considerará, además, la configuración de servicios IPS en los FW Internos si tras la revisión de la arquitectura de red y seguridad así lo aprueban la empresa adjudicataria y el Ayuntamiento. En este caso, la configuración de los servicios IPS de los FW Internos formaría parte del presente proyecto y se incluiría en el plan de migración.

FW EXTERNO

INTERNET

FG60D

FW INTERNO

ISP Redundancy

FW ACCESO

13 de 24

En el apartado posterior de requisitos mínimos se recogen los requisitos adicionales.

3.3.2. HERRAMIENTA DE SANDBOXING

Es requisito dotar al Ayuntamiento de la herramienta Fortisandbox e integrarla tanto con los FW Internos como con la herramienta Fortimail que se introduce más adelante. Se considerará, además, la integración del Fortisandbox con los Fortigate 60D que securizan el tráfico de navegación a la salida de los FW de Acceso si tras la revisión de la arquitectura de red y seguridad así lo aprueban la empresa adjudicataria y el Ayuntamiento. En este caso, la integración del Fortisandbox con los FG60D formaría parte del presente proyecto y se incluiría en el plan de migración.

Se requiere que la herramienta resida en las instalaciones del Ayuntamiento, por lo que queda descartada la solución en la nube.


3.3.3. TRÁFICO WEB SEGURO: FILTRADO WEB + ANTIVIRUS

Dentro de la navegación web, se distinguen dos tipos de tráfico que tienen necesidades diferentes:

• Tráfico de navegación corporativa: se corresponde con el servicio de navegación para los trabajadores del Ayuntamiento desde subredes detrás del FW Interno.

• Tráfico de navegación ciudadana: se corresponde con los servicios de navegación ciudadana desde subredes detrás del FW de Acceso, como pueden ser los servicios wifi o las mediatecas de los centros cívicos. La solución actual de filtrado web del Ayuntamiento para el tráfico de navegación ciudadana está basada en el filtrado web de los firewall de PyV con configuración de perfil único de filtrado para todo el mundo.

La solución actual de filtrado web del Ayuntamiento para el tráfico de navegación corporativa está basada en Optenet con perfiles de filtrado por IPs o grupos de IPs. Se requiere migrar la solución de filtrado web corporativo a los FW Internos y configurar en ellos, además, la funcionalidad de antivirus y control de aplicaciones. Es requisito, además, que se puedan establecer perfiles de filtrado por usuarios o grupos de usuarios de directorio activo.

Para proteger la navegación web ciudadana se requiere configurar los Fortigae 60D a la salida de los FW de Acceso. No son necesarios perfiles de filtrado web por usuario o grupos de usuarios. Al igual que con los FW Internos, se requiere también configurar la funcionalidad de antivirus y control de aplicaciones.

Es requisito adicional configurar los Fortigae 60D a la salida de los FW de Acceso para que hagan reparto de tráfico entre las distintas líneas de navegación mediante policy based routing y gestionen las posibles caídas de una de ellas repartiendo el tráfico entre las demás.

14 de 24

Por último, se requiere que la empresa adjudicataria integre los FW Internos con la herramienta Fortisandbox. Como se ha comentado anteriormente, se considerará adicionalmente la integración del Fortisandbox con los Fortigate 60D.


3.3.4. CORREO ELECTRÓNICO SEGURO: ANTISPAM + ANTIVI RUS

El tráfico de correo electrónico que se quiere proteger es el tráfico de correo electrónico corporativo. Se entiende por tráfico de correo electrónico corporativo al tráfico de correo que intercambian los servidores de correo del Ayuntamiento con otros servidores de correo en Internet. Los servidores de correo del Ayuntamiento están ubicados en una subred de servidores detrás del FW Interno. Adicionalmente, en la DMZ de Internet del FW Externo existen elementos que realizan tareas de relay SMTP.

Es objetivo del proyecto que todo el tráfico de correo corporativo esté protegido por la solución antispam y antivirus especialista independiente de los firewalls instalados. En concreto, se requiere que la empresa adjudicataria provea, instale y configure la herramienta de correo seguro Fortimail. Además, debe integrar el Fortimail con la herramienta Fortisandbox.


4. REQUISITOS MÍNIMOS

En este apartado se definen los requisitos mínimos que debe cumplir el proyecto.

4.1. REQUISITOS GENERALES

Es requisito mínimo que la solución que se presente cumpla con todo lo descrito en el apartado DESCRIPCIÓN DEL PROYECTO.

4.2. CONSOLAS DE LOS FIREWALL

La empresa adjudicataria proveerá, instalará y configurará una consola de gestión Checkpoint con SmartEvent desde la se gestionen de manera unificada tanto los FW Externos como los FW de Acceso. A esta consola se migrará la configuración de la consola de gestión actual.

La empresa adjudicataria proveerá, instalará y configurará una instancia de Fortianalyzer para la gestión de los eventos generados por el FW Interno. La instancia de Fortianalyzer que se instale debe incluir licencia para procesar al menos 5 GBs de logs al día y permitir un almacenamiento máximo de 3 TBs.

Ambas consolas podrán proveerse como máquina virtual o como máquina física. En caso de proveerse como máquina virtual, es responsabilidad de la empresa adjudicataria la implementación en la infraestructura VMWare existente en el Ayuntamiento y es responsabilidad del Ayuntamiento garantizar que la máquina virtual cuenta con los recursos (disco, procesador, memoria, etc.) necesarios. En caso de proveerse como máquina física se debe proponer una solución escalable y con un mínimo de medidas de seguridad que eviten punto único de fallo (doble fuente de alimentación y discos hot swap en RAID o 2

15 de 24

máquinas físicas trabajando en cluster).

Además, con respecto a ambas consolas:

• La empresa adjudicataria impartirá una formación exhaustiva a los técnicos del Ayuntamiento sobre su funcionamiento.

• La empresa adjudicataria entregará una documentación detallada de la configuración realizada así como de los procedimientos comunes de operación (incluida la gestión de eventos en las consolas).

• La empresa adjudicataria incluirá un contrato de mantenimiento con fabricante de 1 año de duración para cada una de las consolas en las mismas condiciones que el mantenimiento actual de los firewall (24x7 con respuesta en 5 horas).

• La empresa adjudicataria prestará un servicio de soporte para ambas consolas durante 1 año a partir de la fecha de aceptación del proyecto en las mismas condiciones que el mantenimiento actual de los firewall (24x7 con respuesta en 5 horas).

4.3. SERVICIOS ESPECÍFICOS EN LOS FW

Los únicos firewall no instalados en su ubicación definitiva a la fecha de la redacción del pliego eran los FW Internos. La empresa adjudicataria debe prever entre las tareas del proyecto la instalación y configuración inicial de ambos nodos de firewall, teniendo en cuenta que se quieren integrar con el directorio activo del Ayuntamiento para poder establecer reglas por usuario o grupo de usuario.

Además, la empresa adjudicataria actualizará, en colaboración con los técnicos del Ayuntamiento, el S.O. de todos los firewalls que forman parte de la arquitectura de red corporativa (FW Interno, FW Externo y FW de Acceso) si, a fecha de adjudicación del proyecto, la versión recomendada por el fabricante es superior a la que en ese momento esté instalada. Estas tareas de formarán parte del plan de migración del proyecto que se describe posteriormente.

Se requiere que la empresa adjudicataria realice en colaboración con los técnicos del Ayuntamiento una revisión de la configuración, gestión, monitorización y procedimientos de operación habituales de todos los firewalls que forman parte de la arquitectura de red corporativa. A la conclusión de la revisión la empresa adjudicataria entregará un informe del trabajo en el que se recojan las conclusiones de la revisión. Las mejoras y los cambios sugeridos en el informe formarán parte del plan de migración del proyecto que se describe posteriormente.

Los técnicos del Ayuntamiento analizarán junto con la empresa adjudicataria las mejoras y los cambios sugeridos en el informe de trabajo. Aquellas medidas que sean aprobadas se implementarán como parte del proyecto, para lo cual la empresa adjudicataria adaptará el plan de migración.

4.4. HERRAMIENTA DE IPS

La empresa adjudicataria tendrá en cuenta los siguientes requisitos en relación con la configuración de la funcionalidad IPS de los firewall:

16 de 24

• La empresa adjudicataria consensuará con los técnicos del Ayuntamiento la configuración del servicio.

• Las instalaciones y/o configuraciones que sea necesario realizar correrán a cargo de la empresa adjudicataria.

• Inicialmente se hará una configuración en modo monitorización hasta afinar el servicio. Posteriormente y con el visto bueno de los técnicos del Ayuntamiento se activará el modo prevención.

• La empresa adjudicataria creará informes de uso de acuerdo con las indicaciones de los técnicos del Ayuntamiento y que podrán ser ejecutados de manera automática o a demanda.

• La empresa adjudicataria impartirá una formación exhaustiva a los técnicos del Ayuntamiento del funcionamiento de la herramienta así como de la generación de nuevos informes de uso.

• La empresa adjudicataria entregará una documentación detallada de la configuración de la herramienta así como de los procedimientos de operación más habituales.

• La empresa adjudicataria configurará junto con los técnicos del Ayuntamiento la monitorización de la herramienta con el objetivo de detectar posibles problemas y disponer de históricos de los indicadores más comunes de la herramienta.

• La empresa adjudicataria prestará un servicio de soporte durante 1 año a partir de la fecha de aceptación del proyecto en las mismas condiciones que el mantenimiento actual de los firewall (24x7 con respuesta en 5 horas).

4.5. HERRAMIENTA DE SANBOXING

La empresa adjudicataria tendrá en cuenta los siguientes requisitos en relación con la herramienta Fortisandbox:

• La herramienta podrá proveerse como máquina virtual o como máquina física.

En caso de proveerse como máquina virtual, es responsabilidad de la empresa adjudicataria la implementación en la infraestructura VMWare existente en el Ayuntamiento y es responsabilidad del Ayuntamiento garantizar que la máquina virtual cuenta con los recursos (disco, procesador, memoria, etc.) necesarios.

En caso de proveerse como máquina física se debe proponer una solución escalable y con un mínimo de medidas de seguridad que eviten punto único de fallo (doble fuente de alimentación y discos hot swap en RAID o 2 máquinas físicas trabajando en cluster).

• La herramienta debe incluir al menos 4 VM con licencia para los principales SO de puesto de trabajo y software de Office de Microsoft (al menos WinXP, Win7 y MS Office). La herramienta debe ser escalable en el número de VM que permite ejecutar así como en los entornos que permite emular.



17 de 24

• La empresa adjudicataria creará informes de uso de la herramienta de acuerdo con las indicaciones de los técnicos del Ayuntamiento y que podrán ser ejecutados de manera automática o a demanda.




• La empresa adjudicataria incluirá un contrato de mantenimiento con fabricante de 1 año de duración a partir de la fecha de aceptación del proyecto en las mismas condiciones que el mantenimiento actual de los firewall (24x7 con respuesta en 5 horas).


4.6. SOLUCIÓN DE NAVEGACIÓN WEB SEGURA

Tanto para la configuración de los FW Internos como para la configuración de los Fortigate 60D a la salida de los FW de Acceso, los requisitos mínimos son los siguientes:



• La empresa adjudicataria creará informes de uso de acuerdo con las indicaciones de los técnicos del Ayuntamiento, que podrán ser ejecutados de manera automática o a demanda.





18 de 24

4.7. SOLUCIÓN DE CORREO ELECTRÓNICO SEGURO

La empresa adjudicataria tendrá en cuenta los siguientes requisitos en relación con la herramienta Fortimail:

• La herramienta podrá proveerse como máquina virtual o como máquina física.

En caso de proveerse como máquina virtual, es responsabilidad de la empresa adjudicataria la implementación en la infraestructura VMWare existente en el Ayuntamiento y es responsabilidad del Ayuntamiento garantizar que la máquina virtual cuenta con los recursos (disco, procesador, memoria, etc.) necesarios.

En caso de proveerse como máquina física se debe proponer una solución escalable y con un mínimo de medidas de seguridad que eviten punto único de fallo (doble fuente de alimentación y discos hot swap en RAID o 2 máquinas físicas trabajando en cluster).

• La solución que se elija debe permitir un rendimiento de al menos 30.000 mensajes de correo enrutados por hora, 30.000 mensajes gestionados por los filtros antispam por hora o 20.000 mensajes gestionados por los filtros antispam y analizados por el antivirus por hora.



• La empresa adjudicataria creará informes de uso de acuerdo con las indicaciones de los técnicos del Ayuntamiento, que podrán ser ejecutados de manera automática o a demanda.




• La empresa adjudicataria incluirá un contrato de mantenimiento con fabricante de 1 año de duración a partir de la fecha de aceptación del proyecto en las mismas condiciones que el mantenimiento actual de los firewall (24x7 con respuesta en 5 horas).


4.8. PLAN DE MIGRACIÓN

Se requiere que la empresa adjudicataria entregue como parte de la documentación técnica del pliego un plan de migración lo más detallado posible de la arquitectura de red actual a la arquitectura de red objetivo y que incluya la puesta en marcha de los servicios

19 de 24

de seguridad avanzada.

Se prestará especial atención por su complejidad y por su impacto en los servicios de producción a las tareas del plan de migración para la sustitución de los FWSM por los FW internos y de los FW de PyV por los FW de Acceso.

Se requiere que en el plan de migración se incluya:

• Por cada tarea que forma parte del plan de migración, al menos:

o Una descripción de la tarea.

o Una estimación del personal (número y perfil), tanto de la empresa adjudicataria como del Ayuntamiento de Vitoria-Gasteiz, involucrados en la ejecución de la tarea.

o Una estimación del tiempo de ejecución.

o En caso necesario, una estimación del tiempo de parada de servicio en producción que requiere la tarea.

o Si corresponde, entregables a la conclusión de la tarea.

• Si las tareas se agrupan en fases o bloques, por cada fase o bloque al menos una descripción breve.

• Información sobre la dependencia entre tareas, fases o bloques del plan.

• Hitos más importantes del proyecto.

El plan de migración debe incluir, además, una batería de pruebas de funcionamiento y de rendimiento al menos de la solución completa y se valorará la realización de baterías de pruebas al completar hitos del proyecto de cierta relevancia.

Por otra parte, el plan de migración debe permitir realizar las tareas que forman parte del mismo de la manera más modular e independiente posible y con el menor impacto en el entorno de producción. Es decir, se valorará positivamente:

• Que esté organizado en bloques que puedan lanzarse en paralelo sin dependencias entre ellos.

• Que la ejecución de una tarea deje el proyecto y el entorno de producción en un estado estable de forma que si las tareas posteriores se retrasan, por el motivo que sea, los servicios en producción no se vean afectados.

• Que las tareas que requieran la parada de algún servicio de producción estén especialmente controladas y que el tiempo de parada de servicio no exceda de 2 horas por tarea.

• Que se ejecute como máximo una tarea que requiera de parada de algún servicio en producción en la misma ventana de parada.

• Que el plan de migración minimice el tiempo de parada de servicio para ser llevado a cabo.

Para terminar, el plan de migración de la empresa adjudicataria será revisado junto con los técnicos del Ayuntamiento para ceñirlo a la situación real de la arquitectura a la fecha de la adjudicación del proyecto y para incluir las posibles mejoras que surjan de la revisión de la

20 de 24

arquitectura de red y seguridad o las medidas que deriven de la revisión de la configuración, gestión, monitorización y procedimientos de operación habituales de los firewalls. Una vez revisado será aprobado por los técnicos del Ayuntamiento como paso previo a su puesta en marcha.

4.9. REVISIÓN DE LA ARQUITECTURA DE RED Y SEGURIDAD

Se requiere que la empresa adjudicataria realice en colaboración con los técnicos del Ayuntamiento una revisión de la arquitectura de red corporativa y de la arquitectura de seguridad con el objetivo de detectar posibles puntos de mejora. A la conclusión de la revisión la empresa adjudicataria entregará un informe del trabajo realizado.

Los técnicos del Ayuntamiento analizarán junto con la empresa adjudicataria las mejoras y los cambios sugeridos en el informe de trabajo. Aquellas medidas que sean aprobadas se implementarán como parte del presente proyecto, para lo cual la empresa adjudicataria adaptará el plan de migración. El resto de medidas serán incorporadas por parte del Ayuntamiento a la arquitectura de red y seguridad en proyectos futuros.

4.10. REQUISITOS DE FORMACIÓN

La formación que se incluye en el proyecto será impartida de forma presencial en las instalaciones del Ayuntamiento de Vitoria-Gasteiz por personal experto de la empresa adjudicataria o contratado por ésta. El número máximo de asistentes a cada sesión formativa nunca excederá de 5. Si una formación se debe impartir a un número mayor de personas se programarán varias sesiones para cumplir con la condición anterior.

Así mismo, la empresa adjudicataria proporcionará una documentación detallada y completa sobre la materia de cada sesión formativa.

Se valorará positivamente que la formación impartida sea formación oficial de fabricante.

El plan de formación será aprobado tanto por los técnicos del Ayuntamiento como por la empresa adjudicataria al inicio del proyecto.

5. ENTREGABLES A LA PRESENTACIÓN DEL PLIEGO

En este apartado se describen los entregables que, al menos, deben formar parte de la documentación técnica del pliego.

5.1. PLAN DIRECTOR DEL PROYECTO

El plan director del proyecto debe incluir todas las tareas, tanto de gestión como de implantación, que forman parte del proyecto. Al menos debe incluir las siguientes tareas:

• Lanzamiento del proyecto.

• Aprobación del plan de formación.

• Revisión de la configuración, gestión, monitorización y procedimientos de operación habituales de todos los firewalls que forman parte de la arquitectura de red corporativa (descrito en el apartado de requisitos mínimos).

21 de 24

• Revisión de la arquitectura de red corporativa y de la arquitectura de seguridad (descrito en el apartado de requisitos mínimos).

• Revisión y aprobación del plan de migración.

• Ejecución del plan de migración.

• Ejecución del plan de formación.

• Cierre del proyecto.

Por cada una de las tareas que forman parte del plan director se debe incluir al menos la siguiente información:

• Una descripción de la tarea.

• Una estimación de los recursos necesarios para llevarla a cabo.

• Una estimación del tiempo de ejecución.

• Una relación de los entregables que genera la tarea.

5.2. PLAN DE MIGRACIÓN

Se debe entregar un plan de migración en los términos que se describen en el apartado correspondiente de los requisitos mínimos del proyecto.

5.3. DOCUMENTACIÓN TÉCNICA

Se debe incluir una documentación técnica sobre cada una de las herramientas y soluciones incluidas en el proyecto. Entre ellas:

• Las consolas de gestión Fortianalyzer y Checkpoint Smart Event.

• Herramienta de IPS.

• Herramienta de sandboxing.

• Solución de navegación web segura.

• Solución de correo electrónico seguro.

La documentación técnica debe incluir al menos:

• Descripción general de la herramienta.

• En caso de que la herramienta cuente con distintas arquitectura de implementación, la que se elija para el proyecto.

• En caso de implementarse como máquina virtual, las necesidades de recursos.

• Información sobre el licenciamiento contratado.

5.4. PLAN DE FORMACIÓN

Se debe incluir un plan de formación sobre cada una de las herramientas y soluciones incluidas en el proyecto. Entre ellas:

22 de 24

• Las consolas de gestión Fortianalyzer y Checkpoint Smart Event.

• Herramienta de IPS.

• Herramienta de sandboxing.

• Solución de navegación web segura.

• Solución de correo electrónico seguro.

El plan de formación de cada una de las herramientas debe incluir al menos:

• Temario.

• Nº de horas.

• Si es formación oficial de fabricante o no.

6. ENTREGABLES A LA CONCLUSIÓN DEL PROYECTO

En este apartado se describen los entregables que, al menos, deben entregarse a la finalización del proyecto.

6.1. INFORME DE LA REVISIÓN DE LOS FIREWALLS

A la finalización de la revisión de la configuración, gestión, monitorización y procedimientos de operación habituales de todos los firewalls que forman parte de la arquitectura de red corporativa, la empresa adjudicataria debe entregar un informe del trabajo en el que se recojan las conclusiones de la misma.

6.2. INFORME DE LA REVISIÓN DE LA ARQUITECTURA DE R ED Y SEGURIDAD

A la finalización de la revisión de la arquitectura de red corporativa y de la arquitectura de seguridad, la empresa adjudicataria debe entregar un informe del trabajo en el que se recojan los puntos de mejora que hayan sido detectados y que puedan ser implantados tanto en el presente proyecto como en proyectos futuros.

6.3. INFORME DE LA EJECUCIÓN DEL PROYECTO

A la finalización del proyecto, la empresa adjudicataria debe entregar un informe que refleje cómo ha sido la ejecución del proyecto y en el que se incluyan, entre otras, las desviaciones respecto al plan inicial de migración (en alcance, en tiempo…), los problemas surgidos y las soluciones que se les ha dado, las modificaciones realizadas y aprobadas del plan inicial de migración, los resultados de las pruebas de funcionamiento y de rendimiento o un informe sobre la formación impartida.

6.4. DOCUMENTACIÓN DE LA FORMACIÓN

La empresa adjudicataria debe entregar a la finalización de la formación una documentación detallada y completa sobre la materia impartida en cada una de las sesiones formativas.

23 de 24

6.5. DOCUMENTACIÓN TÉCNICA

A la finalización del proyecto, la empresa adjudicataria debe entregar una documentación detallada de la configuración realizada así como de los procedimientos de operación más habituales de todas y cada una de las herramientas implantadas en el proyecto.

pliego de prescripciones tecnicas particulares … · las subredes de acceso constituyen la puerta...

Documents