Cómo tomar el control de su infraestructura de red. Capítulo uno Retención

Este artículo es el primero de una serie de artículos titulados "Cómo tomar la infraestructura de red bajo su control". El contenido de todos los artículos de la serie y los enlaces se puede encontrar aquí .

Admito plenamente que hay un número suficiente de empresas en las que una red simple de una hora o incluso un día no es crítica. Desafortunadamente o afortunadamente, no tuve la oportunidad de trabajar en esos lugares. Pero, por supuesto, las redes son diferentes, los requisitos son diferentes, los enfoques son diferentes y, sin embargo, de una forma u otra, la lista a continuación será en muchos casos "mast-do".

Entonces, las condiciones iniciales.

Usted está en un nuevo lugar de trabajo o tiene un ascenso, o decide revisar sus responsabilidades. La red de la empresa es su área de responsabilidad. Para usted, esto es en gran medida un desafío y uno nuevo, que de alguna manera justifica el tono de mentoría de este artículo :). Pero, espero que el artículo también pueda ser útil para cualquier ingeniero de redes.

Su primer objetivo estratégico es aprender a resistir la entropía y mantener el nivel de servicio proporcionado.

Muchas de las tareas que se describen a continuación se pueden resolver por varios medios. Intencionalmente no planteo el tema de la implementación técnica, ya que en principio, a menudo no es tan importante cómo resolvió un problema en particular, sino cómo lo usa y si lo usa es importante. Es de poca utilidad, por ejemplo, de su sistema de monitoreo construido profesionalmente, si no mira allí y no responde a las alertas.

Equipo


Primero debe comprender dónde están los mayores riesgos.

De nuevo, podría ser diferente. Admito que en algún lugar, por ejemplo, estos serán problemas de seguridad, y en algún lugar problemas relacionados con la continuidad del servicio, y en algún lugar, tal vez, algo más. Por que no

Supongamos con certeza que esto es, sin embargo, una continuidad del servicio (este fue el caso en todas las empresas donde trabajé).

Entonces necesitas comenzar con el equipo. Aquí hay una lista de temas a tener en cuenta:

  • clasificación de criticidad del equipo
  • redundancia de equipos críticos
  • soporte, licencias

Debe considerar posibles fallas, especialmente con equipos en la parte superior de su clasificación de criticidad. Por lo general, se descuida la probabilidad de problemas dobles, de lo contrario, su solución y soporte pueden llegar a ser excesivamente costosos, pero en el caso de elementos de red realmente críticos, cuya falla puede afectar significativamente el negocio, debe pensar en esto.

Ejemplo

Supongamos que estamos hablando de un interruptor raíz en un centro de datos.

Como acordamos que la continuidad del servicio es el criterio más importante, es razonable proporcionar una "redundancia" de este equipo. Pero eso no es todo. También debe decidir cuánto tiempo, en caso de avería del primer interruptor, es aceptable que viva con un solo interruptor restante, porque existe el riesgo de que se rompa.

Importante! No tiene que resolver este problema usted mismo. Debe describir los riesgos, las posibles soluciones y el valor para su gerencia o gerencia de la compañía. Deben tomar decisiones.

Por lo tanto, si se decidió que, dada la pequeña probabilidad de una doble avería, trabajar durante 4 horas con un interruptor es, en principio, aceptable, entonces puede tomar el soporte adecuado (para lo cual se reemplazará el equipo en 4 horas).

Pero existe el riesgo de que no se entreguen. Desafortunadamente, una vez nos encontramos en tal situación. ¡En lugar de cuatro horas, el equipo se fue por una semana!

Por lo tanto, este riesgo también necesita ser discutido, y tal vez sería más correcto que compre otro interruptor (tercero) y lo mantenga en repuestos (respaldo en frío) o lo use para fines de laboratorio.

Importante! Haga una tabla de todos los apoyos que tiene con las fechas de finalización y agréguelos al calendario para que al menos un mes después reciba una carta en la que debería comenzar a preocuparse por extender el soporte.

No será perdonado si olvida extender el soporte y el día después de que termine, su equipo se descompondrá.

Trabajo de emergencia


Pase lo que pase en su red, idealmente, debe mantener el acceso a su equipo de red.

Importante! Debe tener acceso de consola a todos los equipos y este acceso no debe depender de la operatividad de la red de transmisión de datos del usuario (datos).

También debe prever posibles escenarios negativos y documentar las acciones necesarias. La disponibilidad de este documento es crítica, por lo tanto, no solo debe compartirse en un recurso compartido por el departamento, sino que también debe almacenarse localmente en las computadoras de los ingenieros.

Debe haber

  • información necesaria para abrir una aplicación en apoyo de un proveedor o integrador
  • información sobre cómo llegar a cualquier equipo (consola, administración)

Por supuesto, cualquier otra información útil puede estar contenida, por ejemplo, una descripción del procedimiento de actualización para varios equipos y comandos de diagnóstico útiles.

Socios


Ahora debe evaluar los riesgos asociados con los socios. Por lo general

  • Proveedores de servicios de Internet y puntos de intercambio de tráfico (IX)
  • proveedores de canales de comunicación

¿Qué preguntas necesitas hacerte? Como en el caso del equipo, es necesario considerar varias opciones para situaciones de emergencia. Por ejemplo, para los proveedores de servicios de Internet, podría ser algo como:

  • ¿Qué sucederá si ISP X deja de brindarle un servicio por alguna razón?
  • ¿Tiene suficiente ancho de banda para otros proveedores?
  • ¿Qué tan buena será la coherencia?
  • ¿Cuán independientes son sus ISP y un accidente grave en uno de ellos generará problemas con otros?
  • ¿Cuántas entradas ópticas a su centro de datos?
  • ¿Qué sucede si una de las entradas se destruye por completo?

En cuanto a las entradas, en mi práctica en dos compañías diferentes, en dos centros de datos diferentes, la excavadora destruyó los pozos y solo por un milagro nuestra óptica no se vio afectada. Este no es un caso tan raro.

Bueno, por supuesto, no solo necesita hacer estas preguntas, sino, nuevamente, con el apoyo del liderazgo, proporcionar una solución aceptable en cualquier situación.

Copia de seguridad


La siguiente prioridad puede ser una copia de seguridad de las configuraciones de hardware. En cualquier caso, este es un punto muy importante. No enumeraré aquellos casos en los que puede perder la configuración, es mejor hacer una copia de seguridad regular y no pensar en ello. Además, la copia de seguridad periódica puede ser muy útil para controlar los cambios.

Importante! Haga una copia de seguridad diariamente. Esta no es una gran cantidad de datos para guardar en esto. Por la mañana, el ingeniero de turno (o usted) debe recibir un informe del sistema que indique claramente si la copia de seguridad fue exitosa o no, y en caso de una copia de seguridad fallida, el problema debe resolverse o debe crearse un ticket (consulte los procesos del departamento de red).

Versión de software


La cuestión de si actualizar o no el software de hardware no está tan clara. Por un lado, las versiones antiguas son errores conocidos y vulnerabilidades, pero por otro lado, el nuevo software es, en primer lugar, no siempre un procedimiento de actualización indoloro, y en segundo lugar, nuevos errores y vulnerabilidades.

Aquí necesitas encontrar la mejor opción. Algunas recomendaciones obvias

  • solo versiones estables
  • Aún así, no debes vivir con versiones muy antiguas de software
  • hacer una señal con información sobre cualquier software
  • lea periódicamente informes sobre vulnerabilidades y errores en las versiones de software, y en caso de problemas críticos, vale la pena pensar en una actualización

En esta etapa, al tener acceso de la consola al equipo, información de soporte y una descripción del procedimiento de actualización, usted está, en principio, listo para este paso. La opción ideal es cuando tiene un equipo de laboratorio donde puede verificar todo el procedimiento, pero, desafortunadamente, esto no sucede con frecuencia.

En el caso de equipos críticos, puede ponerse en contacto con el soporte del proveedor con una solicitud para ayudarlo con la actualización.

Sistema de entradas


Ahora puedes mirar a tu alrededor. Necesita establecer procesos de interacción con otros departamentos y dentro del departamento.

Quizás esto no sea obligatorio (por ejemplo, si su empresa es pequeña), pero recomiendo organizar el trabajo de tal manera que todas las tareas externas e internas pasen por el sistema de tickets.

Un sistema de tickets es esencialmente su interfaz para comunicaciones internas y externas, y debe describir esta interfaz con un grado suficiente de detalle.

Tomemos un ejemplo de una tarea importante y frecuente de abrir el acceso. Describiré un algoritmo que funcionó muy bien en una de las empresas.

Ejemplo

Para empezar, los clientes de acceso a menudo expresan sus deseos en un lenguaje incomprensible para un ingeniero de redes, es decir, en el lenguaje de la aplicación, por ejemplo, "dame acceso a 1C".

Por lo tanto, nunca aceptamos solicitudes directamente de dichos usuarios.
Y ese fue el primer requisito

  • las solicitudes de acceso deben provenir de los departamentos técnicos (en nuestro caso, se trataba de ingenieros de unix, windows, helpdesk)

El segundo requisito es que

  • este acceso debe estar registrado (por el departamento técnico del cual recibimos esta solicitud) y como solicitud recibimos un enlace a este acceso registrado

La forma de esta solicitud debe ser clara para nosotros, es decir

  • la solicitud debe contener información sobre qué y en qué acceso de subred debe estar abierto, así como sobre el protocolo y (en el caso de tcp / udp) puertos

También debe indicarse

  • Descripción de por qué se abre este acceso
  • temporal o permanente (si es temporal, hasta qué fecha)

Y un punto muy importante es

  • del jefe del departamento que inició el acceso (por ejemplo, contabilidad)
  • del jefe del departamento técnico, desde donde llegó esta solicitud al departamento de red (por ejemplo, servicio de asistencia)

Al mismo tiempo, se considera que el "propietario" de este acceso es el jefe del departamento que inició el acceso (contabilidad en nuestro ejemplo), y es responsable de mantener actualizada la página con acceso registrado para este departamento.

Registro


Esto es algo para ahogarse. Pero si desea implementar un enfoque proactivo, entonces necesita aprender a lidiar con este flujo de datos.

Aquí hay algunas sugerencias prácticas:

  • ver los registros que necesita diariamente
  • en el caso de una visualización programada (y no una emergencia), puede limitarse a niveles de gravedad de 0, 1, 2 y agregar sus patrones favoritos de otros niveles si lo considera necesario
  • escribir una secuencia de comandos que analice los registros e ignore los registros cuyos patrones ha agregado a la lista de ignorados

Este enfoque permitirá con el tiempo compilar una lista de ignorados de registros que no le interesan y dejar solo aquellos que realmente considere importantes.
Funcionó muy bien para nosotros.

Monitoreo


No es raro que una empresa no tenga un sistema de monitoreo. Puede, por ejemplo, confiar en los registros, pero el equipo puede simplemente "morir" sin tener que "decir" nada, o el paquete del protocolo udp syslog puede perderse y no alcanzarlo. En general, por supuesto, el monitoreo activo es importante y necesario.

Dos ejemplos más demandados en mi práctica:

  • monitorear la carga de canales de comunicación, enlaces críticos (por ejemplo, conectarse a proveedores). Le permiten ver proactivamente el posible problema de degradación del servicio debido a la pérdida de tráfico y, en consecuencia, evitarlo.
  • Gráficos basados ​​en NetFlow. Facilitan la búsqueda de anomalías de tráfico y son muy útiles para detectar algunos tipos de ataques de piratas informáticos simples pero significativos.

Importante! Configure la notificación de SMS para los eventos más críticos. Esto se aplica tanto a la supervisión como al registro. Si no tiene un turno de servicio, entonces los sms también deben llegar después del horario de atención.

Piense en el proceso de tal manera que no despierte a todos los ingenieros. Teníamos un ingeniero de guardia para esto.

Control de cambios


En mi opinión, no es necesario controlar todos los cambios. Pero, en cualquier caso, debería poder, si es necesario, encontrar fácilmente quién y por qué realizó esos u otros cambios en la red.

Algunos consejos:

  • use el sistema de tickets para obtener una descripción detallada de lo que se ha hecho como parte de este ticket, por ejemplo, copiando la configuración aplicada al ticket
  • Utilice las capacidades de comentario en el hardware de red (por ejemplo, comente comentarios en Juniper). Puedes registrar el número de boleto
  • use diff de sus copias de seguridad de configuración

Puede ingresar esto como un proceso mirando todos los tickets diariamente para ver los cambios.

Los procesos


Debe formalizar y describir los procesos en su equipo. Si ha llegado a este punto, al menos los siguientes procesos ya deberían funcionar en su equipo:

Procesos diarios:

  • trabajar con entradas
  • trabajar con troncos
  • control de cambios
  • hoja de verificación diaria

Procesos anuales:

  • extensión de garantías, licencias

Procesos asincrónicos:

  • respuesta a varias emergencias

Conclusión de la primera parte.


Notó que todo esto no se trata de la configuración de la red, el diseño, los protocolos de red, el enrutamiento o la seguridad ... Esto es algo alrededor. Pero estos, aunque quizás sean aburridos, pero, por supuesto, elementos muy importantes de la unidad de red.

Hasta ahora, como puede ver, no ha mejorado nada en su red. Si hubo vulnerabilidades de seguridad, entonces permanecieron; si hubo un diseño deficiente, entonces permaneció. Hasta que aplique sus habilidades y conocimientos de un ingeniero de redes, que probablemente pasó mucho tiempo, esfuerzo y, a veces, dinero. Pero primero debe crear (o fortalecer) la base, y luego hacer la construcción.

Las siguientes partes tratan sobre cómo buscar y corregir errores, y luego mejorar su infraestructura.

Por supuesto, no es necesario hacer todo de forma secuencial. El tiempo puede ser crítico. Hacer en paralelo si los recursos lo permiten.

Y una adición importante. Comunícate, pregunta, consulta con tu equipo. Al final, depende de ellos apoyar y hacer todo esto.

Source: https://habr.com/ru/post/es433614/


All Articles