POLITICAS PARA GESTIÓN DE RED

Introducción:        

Objetivo:                

Alcance:                

Segmento:                 Masivo (Bogotá y Regiones)

Definiciones

Tabla de contenido

POLITICAS PARA GESTIÓN DE RED        

1.        Arquitectura        

2.        Backup        

3.        Seguridad        

4.        Conectividad        

5.        Políticas de Licenciamiento        

6.        Políticas de Acceso        

POLITICAS PARA GESTIÓN DE RED

1. Arquitectura

1. Todas las redes deben incluir un gestor propietario para el gobierno de sus elementos de red.
2. Las plataformas de gestión de red deben contar con redundancia preferiblemente geográfica y con configuración de IP virtual para acceder a todos sus servicios desde cualquier tipo de cliente.
3. Las funciones de los gestores de elementos de red deben estar alineadas con el modelo FCAPS: Fallas, Configuración, Administración, Desempeño y Seguridad.
4. Las plataformas de gestión deben contar con una capacidad de crecimiento del 30% sin necesidad de crecimiento en hardware.

1. Backup

1. Las plataformas de gestión de red deben integrarse con la plataforma de backup automáticos de ETB, preferiblemente usando interfaces exclusivas.
2. Se debe respaldar cada uno de los archivos necesarios para recuperar la plataforma en caso de un evento fortuito que provoque indisponibilidad parcial o total de la misma. Esta información debe ser entregada por cada fabricante.
3. La frecuencia de los backup debe establecerse de acuerdo a la recomendación de cada fabricante.
4. Las tareas de backup deben hacerse en los horarios de menor uso de la plataforma.

1. Seguridad

1. Los gestores de red deben conectarse detrás de un firewall y cualquier conexión hacia ellos debe pasar por él a excepción de interfaces internas propias de la solución como “heart beat”.
2. Los servidores de presentación para funciones de “web enabled” deben pasar obligatoriamente por firewall, no pueden conectarse directamente a los demás servidores de la solución usando switch L2.
3. Las integraciones hacia OSS deben hacerse por las conexiones firewall to firewall existentes y de acuerdo a las disposiciones del grupo de seguridad informática.
4. Todas las plataformas deberán permitir la autenticación local de  los usuarios que acceden el sistema.
5. Las plataformas de gestión deben permitir la integración mediante protocolos como RADIUS, TACACS a directorios activos externos para la autenticación de usuarios.
6. Las plataformas de gestión deben integrarse al directorio activo corporativo de ETB.

1. Conectividad

1. Los gestores y sus elementos de red deben utilizar como protocolo de comunicación de eventos de gestión SNMP, preferiblemente en la versión SNMP V3.
2. La conexión hacia los elementos de red se debe hacer usando una VRF exclusiva para cada red con el objetivo de independizar el tráfico de gestión del de servicios.
3. Los productos deben ser monitoreados y contar con un proceso de aseguramiento con  responsables de atender los eventos de afectación del servicio con procesos de remedición enmarcados en los ANS.
4. Las interfaces de usuario de gestión deben ser basadas en tecnología web.
5. Todas las plataformas de gestión deben estar integradas con la plataforma de Gestión Unificada.
6. Los procesos de aprovisionamiento/des-aprovisionamiento deben incluir las respectivas modificaciones/ajustes sobre los element manager para reflejar el estado real de los servicios existentes sobre la red.
7. La automatización de monitoreos con fines de aseguramiento y gestión de la capacidad se solicitaran a través de la Dirección de Ingeniería de servicios masivos con el fin de viabilizarlos, valorizar su desarrollo, implementarlos y entregarlos al área solicitante.
8. Cada plataforma deberá conectarse al servidor de protocolo NTP para sincronizar su reloj al de la red de ETB.

1. Políticas de Licenciamiento

1. Toda plataforma de gestión debe incluir desde su alistamiento, las licencias de sistema operativo, suscripciones, bases de datos, aplicaciones y cualquier otra que aplique de acuerdo al funcionamiento de cada una. Es obligación de todos los proveedores entregar estas licencias a nombre de ETB.
2. Las licencias para las aplicaciones web-enabled deben ser independientes a las de acceso a la GUI de la plataforma y a las de NBI (North Bound Interface)

1. Políticas de Acceso

1. Para acceso a cada plataforma se debe tener es siguiente esquema de acceso como se ilustra en la figura:

[pic 2]

• Usuarios: Todos los usuarios creados deben corresponder a usuarios de red existente, el cual identifique la persona que utiliza el usuario. No deben crearse usuarios de grupos genéricos.
• Grupos de usuarios: Se deben crear los grupos de cada área que  pertenezca el cada usuario: Planeación, Aseguramiento, Alistamiento y Aprovisionamiento.
• Perfil de acceso: Los roles no se asignan directamente a los usuarios, sino que se asignan a los grupos de usuarios. Esto quiere decir que para que un usuario tenga permiso para realizar una operación determinada, este debe pertenecer a un grupo que contenga el rol apropiado que permita realizar dicha operación.
• Grupo de permisos: Los permisos disponibles para cada rol de usuario son configurados a nivel interno dentro de cada plataforma, esta labor de ser responsabilidad del administrador de cada plataforma y solo este podrá cambiar o modificar los permisos. Cada plataforma deberá tener su manual de configuración de grupos, perfiles y permisos.

1. Los agentes de Help Desk deben tener acceso únicamente a la interfaz web del Gestor de Gestores para observar la información de fallas y desempeño de los elementos que les interesa monitorear.
2. El acceso a la GUI debe ser exclusivo para el personal de soporte de segundo y tercer nivel. En el caso del NOC y aprovisionamiento de servicios, se debe usar la interfaces web enabled de la plataforma en los casos que aplique.
3. Cada usuario de la plataforma debe tener sus propias credenciales, no se deben configurar usuarios grupales. Es potestad del área administradora de la plataforma la creación de los usuarios y los procedimientos para solicitud y análisis de viabilidad de la misma.

...