Este artigo é o terceiro dunha serie de artigos "Como tomar o control da túa infraestrutura de rede". Pódense atopar os contidos de todos os artigos da serie e as ligazóns .
Non ten sentido falar de eliminar completamente os riscos de seguridade. En principio, non podemos reducilos a cero. Tamén temos que entender que a medida que nos esforzamos por facer a rede cada vez máis segura, as nosas solucións son cada vez máis caras. Debes atopar unha compensación entre custo, complexidade e seguridade que teña sentido para a túa rede.
Por suposto, o deseño de seguridade está integrado organicamente na arquitectura xeral e as solucións de seguridade utilizadas afectan á escalabilidade, fiabilidade, manexabilidade,... da infraestrutura de rede, que tamén se deben ter en conta.
Pero permíteme recordar que agora non estamos a falar de crear unha rede. Segundo o noso xa escollemos o deseño, seleccionamos o equipamento e creamos a infraestrutura, e nesta fase, se é posible, deberíamos "vivir" e atopar solucións no contexto do enfoque escollido previamente.
A nosa tarefa agora é identificar os riscos asociados á seguridade a nivel de rede e reducilos a un nivel razoable.
Auditoría de seguridade da rede
Se a súa organización implementou procesos ISO 27k, as auditorías de seguridade e os cambios de rede deberían encaixar perfectamente nos procesos xerais deste enfoque. Pero estes estándares seguen sen tratar de solucións específicas, nin de configuración, nin de deseño... Non hai consellos claros, nin estándares que diten en detalle como debe ser a túa rede, esta é a complexidade e beleza desta tarefa.
Destacaría varias posibles auditorías de seguridade da rede:
- auditoría de configuración de equipos (endurecemento)
- auditoría de deseño de seguridade
- auditoría de acceso
- auditoría de procesos
Auditoría de configuración de equipos (endurecemento)
Parece que na maioría dos casos este é o mellor punto de partida para auditar e mellorar a seguridade da túa rede. En mi humilde opinión, esta é unha boa demostración da lei de Pareto (o 20% do esforzo produce o 80% do resultado e o 80% restante produce só o 20% do resultado).
A conclusión é que normalmente temos recomendacións dos provedores sobre as "mellores prácticas" de seguridade á hora de configurar o equipo. Isto chámase "endurecemento".
Tamén podes atopar moitas veces un cuestionario (ou crear un ti mesmo) baseado nestas recomendacións, que che axudará a determinar o que a configuración do teu equipo cumpre con estas "prácticas recomendadas" e, de acordo co resultado, a realizar cambios na túa rede. . Isto permitirache reducir significativamente os riscos de seguridade con bastante facilidade, practicamente sen custo.
Varios exemplos para algúns sistemas operativos de Cisco.
A partir destes documentos pódese crear unha lista de requisitos de configuración para cada tipo de equipo. Por exemplo, para un Cisco N7K VDC estes requisitos poden parecer .
Deste xeito, pódense crear ficheiros de configuración para diferentes tipos de equipos activos na súa infraestrutura de rede. A continuación, manualmente ou mediante a automatización, pode "cargar" estes ficheiros de configuración. Como automatizar este proceso comentarase en detalle noutra serie de artigos sobre orquestración e automatización.
Auditoría de deseño de seguridade
Normalmente, unha rede empresarial contén os seguintes segmentos dunha forma ou outra:
- DC (Servizos públicos DMZ e centro de datos Intranet)
- Acceso a Internet
- VPN de acceso remoto
- bordo WAN
- Rama
- Campus (oficina)
- Núcleo
Títulos tirados de modelo, pero non cómpre, por suposto, unirse precisamente a estes nomes e a este modelo. Aínda así, quero falar da esencia e non atascarme en trámites.
Para cada un destes segmentos, os requisitos de seguridade, os riscos e, en consecuencia, as solucións serán diferentes.
Vexamos cada un deles por separado para os problemas que podes atopar desde o punto de vista do deseño de seguridade. Por suposto, repito de novo que de ningún xeito este artigo pretende ser completo, cousa que non é doado (por non dicir imposible) de acadar neste tema verdadeiramente profundo e polifacético, pero que reflicte a miña experiencia persoal.
Non hai unha solución perfecta (polo menos aínda). Sempre é un compromiso. Pero é importante que a decisión de utilizar un enfoque ou outro se tome conscientemente, entendendo os seus pros e contras.
Centro de datos
O segmento máis crítico dende o punto de vista da seguridade.
E, como é habitual, tampouco hai aquí unha solución universal. Todo depende en gran medida dos requisitos da rede.
É necesario ou non un firewall?
Parece que a resposta é obvia, pero non todo está tan claro como parece. E a súa elección pode ser influenciada non só prezo.
Exemplo 1. Atrasos.
Se a baixa latencia é un requisito esencial entre algúns segmentos de rede, o que é, por exemplo, certo no caso dun intercambio, entón non poderemos usar cortalumes entre estes segmentos. É difícil atopar estudos sobre a latencia nos cortalumes, pero poucos modelos de interruptor poden proporcionar unha latencia inferior a ou da orde de 1 mkseg, polo que creo que se os microsegundos son importantes para ti, os cortalumes non son para ti.
Exemplo 2. Actuación.
O rendemento dos interruptores L3 superiores adoita ser unha orde de magnitude superior ao rendemento dos cortalumes máis potentes. Polo tanto, no caso de tráfico de alta intensidade, tamén o máis probable é que teña que permitir que este tráfico evite os cortalumes.
Exemplo 3. Fiabilidade.
Os firewalls, especialmente os modernos NGFW (Next-Generation FW) son dispositivos complexos. Son moito máis complexos que os interruptores L3/L2. Ofrecen un gran número de servizos e opcións de configuración, polo que non é de estrañar que a súa fiabilidade sexa moito menor. Se a continuidade do servizo é fundamental para a rede, quizais teñas que escoller o que levará a unha mellor dispoñibilidade: seguridade cun firewall ou a sinxeleza dunha rede construída en conmutadores (ou varios tipos de tecidos) utilizando ACL habituais.
No caso dos exemplos anteriores, o máis probable é que (como de costume) teña que atopar un compromiso. Busca as seguintes solucións:
- se decide non usar firewalls dentro do centro de datos, entón cómpre pensar en como limitar o acceso ao perímetro o máximo posible. Por exemplo, pode abrir só os portos necesarios desde Internet (para o tráfico de clientes) e o acceso administrativo ao centro de datos só desde servidores de salto. Nos servidores de salto, realice todas as comprobacións necesarias (autenticación/autorización, antivirus, rexistro, ...)
- pode usar unha partición lóxica da rede do centro de datos en segmentos, semellante ao esquema descrito en PSEFABRIC . Neste caso, o enrutamento debe configurarse de forma que o tráfico sensible ao atraso ou de alta intensidade vaia "dentro" dun segmento (no caso de p002, VRF) e non pase polo firewall. O tráfico entre distintos segmentos seguirá pasando polo firewall. Tamén pode utilizar a fuga de rutas entre VRF para evitar redirixir o tráfico a través do firewall
- Tamén pode usar un firewall en modo transparente e só para aquelas VLAN onde estes factores (latencia/rendemento) non sexan significativos. Pero cómpre estudar coidadosamente as restricións asociadas ao uso deste mod para cada provedor
- pode querer considerar o uso dunha arquitectura de cadea de servizos. Isto permitirá que só o tráfico necesario pase polo firewall. Parece ben en teoría, pero nunca vin esta solución na produción. Probamos a cadea de servizo para Cisco ACI/Juniper SRX/F5 LTM hai uns 3 anos, pero naquel momento esta solución parecíanos "bruta".
Nivel de protección
Agora debes responder á pregunta de que ferramentas queres usar para filtrar o tráfico. Estas son algunhas das funcións que adoitan estar presentes en NGFW (por exemplo, ):
- firewall con estado (predeterminado)
- firewall de aplicacións
- prevención de ameazas (antivirus, anti-spyware e vulnerabilidades)
- Filtrado de URL
- filtrado de datos (filtrado de contido)
- bloqueo de ficheiros (bloqueo de tipos de ficheiros)
- dos protección
E tampouco todo está claro. Parece que canto maior sexa o nivel de protección, mellor. Pero tamén hai que telo en conta
- Canto máis use as funcións de firewall anteriores, máis caro será naturalmente (licenzas, módulos adicionais)
- o uso dalgúns algoritmos pode reducir significativamente o rendemento do firewall e tamén aumentar os atrasos, consulte por exemplo
- como calquera solución complexa, o uso de métodos de protección complexos pode reducir a fiabilidade da súa solución, por exemplo, ao usar o firewall de aplicacións, atopei o bloqueo dalgunhas aplicacións de traballo bastante estándar (dns, smb).
Como sempre, debes atopar a mellor solución para a túa rede.
É imposible responder definitivamente á pregunta de que funcións de protección poden ser necesarias. En primeiro lugar, porque, por suposto, depende dos datos que estea transmitindo ou almacenando e que intente protexer. En segundo lugar, en realidade, moitas veces a elección das ferramentas de seguridade é unha cuestión de fe e confianza no provedor. Non coñeces os algoritmos, non sabes o efectivos que son e non podes probalos completamente.
Polo tanto, en segmentos críticos, unha boa solución pode ser utilizar ofertas de diferentes empresas. Por exemplo, pode activar o antivirus no firewall, pero tamén usar a protección antivirus (de outro fabricante) localmente nos hosts.
Segmentación
Estamos a falar da segmentación lóxica da rede de centros de datos. Por exemplo, a partición en VLAN e subredes tamén é unha segmentación lóxica, pero non o consideraremos debido á súa obviedade. Interesante segmentación tendo en conta entidades como zonas de seguridade FW, VRF (e os seus análogos en relación con varios provedores), dispositivos lóxicos (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Dáse un exemplo desta segmentación lóxica e o deseño do centro de datos actualmente demandado .
Unha vez definidas as partes lóxicas da súa rede, pode describir como se move o tráfico entre os distintos segmentos, en que dispositivos se realizará o filtrado e con que medios.
Se a túa rede non ten unha partición lóxica clara e as regras de aplicación das políticas de seguridade para os distintos fluxos de datos non están formalizadas, isto significa que cando abres tal ou aquel acceso, tes que resolver este problema, e con moita probabilidade resolverao cada vez de forma diferente.
Moitas veces, a segmentación baséase só en zonas de seguridade do FW. Entón cómpre responder ás seguintes preguntas:
- que zonas de seguridade necesitas
- que nivel de protección quere aplicar a cada unha destas zonas
- ¿Permitirase o tráfico dentro da zona por defecto?
- se non, que políticas de filtrado de tráfico se aplicarán dentro de cada zona
- que políticas de filtrado de tráfico se aplicarán a cada par de zonas (fonte/destino)
TCAM
Un problema común é a insuficiente TCAM (Ternary Content Addressable Memory), tanto para o enrutamento como para os accesos. En mi humilde opinión, este é un dos problemas máis importantes á hora de elixir o equipo, polo que debes tratar este problema co grao de coidado adecuado.
Exemplo 1. Táboa de reenvío TCAM.
Vexamos cortalumes
Vemos que o tamaño da táboa de reenvío IPv4* = 32K
Ademais, este número de rutas é común para todos os VSYS.Supoñamos que segundo o teu deseño decides usar 4 VSYS.
Cada un destes VSYS está conectado mediante BGP a dous PE MPLS da nube que usas como BB. Así, 4 VSYS intercambian todas as rutas específicas entre si e teñen unha táboa de reenvío con aproximadamente os mesmos conxuntos de rutas (pero diferentes NH). Porque cada VSYS ten 2 sesións BGP (coa mesma configuración), entón cada ruta recibida a través de MPLS ten 2 NH e, en consecuencia, 2 entradas FIB na táboa de reenvío. Se asumimos que este é o único firewall do centro de datos e debe coñecer todas as rutas, isto significará que o número total de rutas no noso centro de datos non pode ser superior a 32K/(4 * 2) = 4K.Agora, se asumimos que temos 2 centros de datos (co mesmo deseño) e queremos usar VLAN "estiradas" entre centros de datos (por exemplo, para vMotion), entón para resolver o problema de enrutamento, debemos utilizar rutas de host. . Pero isto significa que para 2 centros de datos non teremos máis de 4096 hosts posibles e, por suposto, isto pode non ser suficiente.
Exemplo 2. ACL TCAM.
Se planea filtrar o tráfico en conmutadores L3 (ou outras solucións que usan conmutadores L3, por exemplo, Cisco ACI), ao elixir o equipo debe prestar atención á ACL TCAM.
Supoña que quere controlar o acceso nas interfaces SVI do Cisco Catalyst 4500. Entón, como se pode ver en , para controlar o tráfico saínte (así como o entrante) nas interfaces, só pode usar 4096 liñas TCAM. O que ao usar TCAM3 dará uns 4000 mil ACE (liñas ACL).
Se se enfronta ao problema da TCAM insuficiente, primeiro, por suposto, cómpre considerar a posibilidade de optimización. Polo tanto, en caso de problema co tamaño da táboa de reenvío, cómpre considerar a posibilidade de agregar rutas. No caso de que exista un problema co tamaño de TCAM para accesos, audite os accesos, elimine rexistros desactualizados e superpostos e, posiblemente, revise o procedemento para abrir accesos (discutirase en detalle no capítulo de auditoría de accesos).
Alta dispoñibilidade
A pregunta é: debería usar HA para cortalumes ou instalar dúas caixas independentes "en paralelo" e, se unha delas falla, dirixir o tráfico pola segunda?
Parece que a resposta é obvia: use HA. O motivo polo que segue xurdindo esta pregunta é que, por desgraza, as porcentaxes teóricas e publicitarias 99 e varias porcentaxes decimais de accesibilidade na práctica resultan estar lonxe de ser tan rosas. HA é loxicamente unha cousa bastante complexa, e en diferentes equipos, e con diferentes provedores (non houbo excepcións), detectamos problemas e erros e paradas de servizo.
Se usas HA, terás a oportunidade de desactivar nodos individuais, cambiar entre eles sen deter o servizo, o que é importante, por exemplo, ao facer actualizacións, pero ao mesmo tempo tes unha probabilidade moi lonxe de cero de que ambos nodos romperá ao mesmo tempo, e tamén que o próximo a actualización non vai funcionar tan ben como promete o vendedor (este problema pódese evitar se tes a oportunidade de probar a actualización en equipos de laboratorio).
Se non usas HA, entón desde o punto de vista do dobre fallo os teus riscos son moito menores (xa que tes 2 firewalls independentes), pero xa que... as sesións non están sincronizadas, entón cada vez que cambie entre estes firewalls perderá tráfico. Por suposto, pode usar un firewall sen estado, pero entón o punto de usar un firewall pérdese en gran medida.
Polo tanto, se como resultado da auditoría descubriches firewalls solitarios e estás a pensar en aumentar a fiabilidade da túa rede, entón HA, por suposto, é unha das solucións recomendadas, pero tamén debes ter en conta as desvantaxes asociadas. con este enfoque e, quizais, especificamente para a súa rede, outra solución sería máis axeitada.
Manexabilidade
En principio, HA tamén se trata de controlabilidade. En lugar de configurar 2 caixas por separado e tratar o problema de manter as configuracións sincronizadas, xestionas como se tiveses un dispositivo.
Pero quizais teña moitos centros de datos e moitos firewalls, entón esta pregunta xorde nun novo nivel. E a pregunta non é só sobre a configuración, senón tamén sobre
- configuracións de copia de seguridade
- actualizacións
- actualizacións
- vixilancia
- rexistro
E todo isto pódese solucionar mediante sistemas de xestión centralizados.
Entón, por exemplo, se está a usar firewalls de Palo Alto, entón é tal solución.
Continuar.
Fonte: www.habr.com