Este artigo é o terceiro de uma série de artigos intitulada 'Como colocar a infraestrutura de rede sob seu controle'. Você pode encontrar o conteúdo de todos os artigos da série e links. aqui.

Não faz sentido falar sobre a eliminação total dos riscos de segurança. Na verdade, não podemos reduzi-los a zero. Também é importante entender que, ao tentar tornar a rede cada vez mais segura, nossas soluções se tornam cada vez mais caras. É necessário encontrar um compromisso razoável para sua rede entre preço, complexidade e segurança.

Claro, o design de segurança está organicamente integrado na arquitetura geral e as soluções de segurança utilizadas afetam a escalabilidade, confiabilidade, gerenciabilidade da infraestrutura de rede, o que também deve ser levado em consideração.

Mas, lembrando que neste momento não estamos falando sobre a criação da rede. De acordo com nossas condições iniciais já temos o design escolhido, o equipamento selecionado e a infraestrutura criada, e neste estágio devemos, na medida do possível, 'viver' e encontrar soluções no contexto da abordagem anteriormente escolhida.

Nossa tarefa agora é identificar os riscos relacionados à segurança no nível da rede e reduzi-los a um nível razoável.

Auditoria de Segurança de Rede

Se em sua organização foram implementados processos ISO 27k, então a auditoria de segurança e as mudanças na rede devem estar organicamente integradas nos processos gerais dentro dessa abordagem. Mas esses padrões ainda não tratam de soluções específicas, nem de configurações, nem de design... Não existem conselhos unívocos, não há padrões que ditam detalhadamente como deve ser sua rede, essa é a complexidade e a beleza dessa tarefa.

Eu destacaria algumas possíveis auditorias de segurança de rede:

auditoria de configuração de equipamentos (hardening)
auditoria do design de segurança
auditoria de acessos
auditoria de processos

Auditoria de configuração de equipamentos (hardening)

Parece que, na maioria dos casos, esse é o melhor ponto de partida para auditar e melhorar a segurança da sua rede. Na minha opinião, isso é uma boa demonstração da Lei de Pareto (20% dos esforços proporcionam 80% dos resultados, enquanto os outros 80% dos esforços resultam em apenas 20% do resultado).

A essência é que geralmente temos recomendações dos fornecedores sobre 'melhores práticas' de segurança ao configurar equipamentos. Isso é chamado de 'hardening'.

É comum encontrar um questionário (ou elaborar um), com base nessas recomendações, que o ajudará a determinar o quão bem a configuração do seu hardware corresponde a essas «melhores práticas» e, de acordo com os resultados, fazer alterações em sua rede. Isso permitirá que você reduza significativamente os riscos de segurança de forma bastante fácil, na verdade, sem custos.

Alguns exemplos para alguns sistemas operacionais Cisco.
Endurecimento da Configuração do Cisco IOS
Endurecimento da Configuração do Cisco IOS-XR
Endurecimento da Configuração do Cisco NX-OS
Lista de Verificação de Segurança Básica da Cisco
Com base nesses documentos, pode ser criado uma lista de requisitos de configuração para cada tipo de hardware. Por exemplo, para o Cisco N7K VDC, esses requisitos podem parecer assim.

Dessa forma, podem ser criados arquivos de configuração para diferentes tipos de equipamentos ativos de sua infraestrutura de rede. Em seguida, manualmente ou com a ajuda da automação, você pode 'carregar' esses arquivos de configuração. Como automatizar esse processo será abordado em outra série de artigos dedicados à orquestração e automação.

Auditoria do design de segurança

Normalmente, em uma rede empresarial, em uma forma ou outra, existem os seguintes segmentos:

DC (Serviços públicos DMZ e data center Intranet)
Acesso à Internet
VPN de acesso remoto
WAN edge
Filial
Campus (Escritório)
Núcleo

Os nomes foram retirados do Cisco SAFE modelos, mas não é necessário, é claro, atentar-se apenas a esses nomes e a esse modelo. Afinal, é importante falar sobre a essência e não se prender a formalidades.

Para cada um desses segmentos, os requisitos de nível de segurança, riscos e, consequentemente, soluções serão diferentes.

Vamos considerar cada um deles separadamente em relação aos problemas que você pode enfrentar do ponto de vista do design de segurança. Certamente, nuevamente, ressalto que este artigo não pretende ser abrangente, algo que é realmente desafiador e multifacetado nesta temática (seja como for possível), mas reflete minha experiência pessoal.

Não existe uma solução perfeita (pelo menos agora). É sempre um compromisso. Mas é importante que a solução adote determinada abordagem de forma consciente, entendendo tanto seus prós quanto seus contras.

Centro de Dados

O segmento mais crítico do ponto de vista da segurança.
E, como sempre, aqui também não há uma solução universal. Tudo depende muito dos requisitos da rede.

Firewall: é necessário ou não?

À primeira vista, a resposta parece óbvia, mas a situação não é tão clara quanto pode parecer. E sua escolha pode ser influenciada não apenas por o preço.

Exemplo 1. Latência.
Se entre alguns segmentos de rede a baixa latência é um requisito crucial, como é o caso nas bolsas de valores, então não poderemos usar firewalls entre esses segmentos. É difícil encontrar estudos sobre latência em firewalls, mas poucos modelos de switches podem proporcionar latências inferiores a 1 microsegundo, por isso, se microsegundos são importantes para você, firewalls podem não ser a melhor opção.

Exemplo 2. Desempenho.
A largura de banda dos melhores switches L3 geralmente é muito maior do que a largura de banda dos firewalls mais potentes. Portanto, em casos de tráfego intenso, você provavelmente terá que contornar os firewalls.

Exemplo 3. Confiabilidade.
Firewalls, especialmente os modernos NGFW (Next-Generation Firewalls) – são dispositivos complexos. Eles são significativamente mais complicados do que switches L3/L2. Eles oferecem uma grande quantidade de serviços e opções de configuração, por isso não é surpreendente que sua confiabilidade seja muito menor. Se a continuidade do serviço é crítica para a rede, talvez você tenha que escolher o que levará a uma melhor disponibilidade — proteção através de firewall ou a simplicidade de uma rede baseada em switches (ou diversos tipos de fabrics) usando ACLs comuns.

Na maioria dos casos citados acima, você provavelmente (como costuma acontecer) terá que encontrar um compromisso. Considere as seguintes soluções:

se você decidiu não usar firewalls dentro do data center, precisará planejar como limitar ao máximo os acessos pela borda. Por exemplo, você pode abrir apenas as portas necessárias da Internet (para tráfego de clientes) e permitir acessos administrativos ao data center apenas a partir de jump hosts. Nos jump hosts, realize todas as verificações necessárias (autenticação/autorização, antivírus, registro, ...)
você pode usar a segmentação lógica da rede do data center em partes, semelhante ao esquema descrito no PSEFABRIC. exemplo p002A roteamento deve ser configurado de tal forma que o tráfego sensível a latências ou tráfego de alta intensidade transite "dentro" de um segmento (no caso de p002, VRF) e não passe pelo firewall. O tráfego entre diferentes segmentos ainda passará pelo firewall. O route leaking entre VRFs também pode ser utilizado para evitar o redirecionamento do tráfego pelo firewall.
Você também pode utilizar o firewall em modo transparente e apenas para VLANs onde esses fatores (latência/desempenho) não são significativos. No entanto, é necessário estudar atentamente as limitações relacionadas ao uso deste modo para cada fornecedor.
Você pode considerar a aplicação de uma arquitetura de service chain. Isso permitirá direcionar apenas o tráfego necessário através do firewall. Teoricamente, é uma ideia atraente, mas eu nunca vi essa solução em produção. Nós testamos service chain para Cisco ACI/Juniper SRX/F5 LTM há cerca de 3 anos, mas na época essa solução nos pareceu "bruta".

Nível de proteção

Agora você precisa responder à pergunta sobre quais ferramentas você deseja utilizar para filtrar o tráfego. Aqui estão algumas das funcionalidades que geralmente estão presentes em um NGFW (por exemplo, aqui):

firewalling stateful (por padrão)
firewall de aplicativo
prevenção de ameaças (antivírus, anti-spyware e vulnerabilidades)
filtragem de URL
filtragem de dados (filtragem de conteúdo)
bloqueio de arquivos (bloqueio de tipos de arquivo)
proteção DoS

E também não é tudo tão claro. À primeira vista, quanto maior o nível de proteção, melhor. No entanto, você também precisa considerar que

quanto mais dessas funções acima mencionadas do firewall você utilizar, mais caro isso será (licenças, módulos adicionais)
o uso de alguns algoritmos pode reduzir significativamente a largura de banda do firewall, além de aumentar as latências, veja por exemplo aqui
como qualquer solução complexa, o uso de métodos de proteção complexos pode reduzir a confiabilidade da sua solução; por exemplo, ao usar firewalling de aplicativo, já enfrentei bloqueios de alguns aplicativos que funcionam de maneira padrão (dns, smb).

Como sempre, você precisa encontrar a solução ideal para sua rede.

Não é possível responder de forma clara quais funções de proteção podem ser necessárias. Em primeiro lugar, porque isso depende dos dados que você está transmitindo ou armazenando e tentando proteger. Em segundo lugar, na prática, a escolha dos meios de proteção é muitas vezes uma questão de fé e confiança no fornecedor. Você não conhece os algoritmos, não sabe quão eficazes eles são e não pode testá-los completamente.

Portanto, em segmentos críticos, uma boa solução pode ser o uso de ofertas de diferentes empresas. Por exemplo, você pode implementar um antivírus no firewall, mas também utilizar proteção antivírus (de outro fabricante) localmente nos hosts.

Segmentação

Estamos falando sobre a segmentação lógica da rede do data center. Por exemplo, a divisão em VLANs e sub-redes também é uma segmentação lógica, mas não vamos considerar isso devido à sua obviedade. O interessante é a segmentação levando em conta entidades como zonas de segurança de FW, VRF (e seus equivalentes em diferentes fornecedores), dispositivos lógicos (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Um exemplo dessa segmentação lógica e do design de data center atualmente demandado é apresentado no p002 do projeto PSEFABRIC.

Depois de definir as partes lógicas da sua rede, você pode descrever como o tráfego se move entre os diferentes segmentos, em quais dispositivos ocorrerá a filtragem e quais meios serão utilizados.

Se a sua rede não apresentar uma clara divisão lógica e não houver regras formalizadas para a aplicação de políticas de segurança para diferentes fluxos de dados (flow), isso significa que ao abrir um determinado acesso você será forçado a resolver essa questão, e com grande probabilidade você a resolverá de maneira diferente a cada vez.

Frequentemente, a segmentação é baseada apenas em zonas de segurança de FW. Então, você precisa responder às seguintes perguntas:

quais zonas de segurança você precisa
qual nível de proteção você deseja implementar em cada uma dessas zonas
o tráfego intra-zone será permitido por padrão
se não, quais políticas de filtragem de tráfego serão aplicadas dentro de cada uma das zonas
quais políticas de filtragem de tráfego serão aplicadas para cada par de zonas (source/destination)

TCAM

Comumente encontramos o problema da falta de TCAM (Memória de Acesso Direto Ternário), tanto para roteamento quanto para acessos. IMHO, essa é uma das questões mais importantes ao escolher um hardware, portanto, é necessário abordar essa questão com o devido cuidado.

Exemplo 1. Tabela de Encaminhamento TCAM.
Vamos considerar Palo Alto 7k firewall.
Observamos que o tamanho da tabela de encaminhamento IPv4* = 32K.
Esse número de rotas é total para todas as VSYS.
Suponha que de acordo com seu design você decidiu usar 4 VSYS.
Cada uma dessas VSYS está conectada por BGP a duas PE na nuvem MPLS, que você utiliza como BB. Assim, as 4 VSYS trocam todas as rotas específicas entre si e têm uma tabela de encaminhamento com conjuntos de rotas aproximadamente iguais (mas com diferentes NH). Como cada VSYS tem 2 sessões BGP (com as mesmas configurações), cada rota recebida através do MPLS tem 2 NHs e, consequentemente, 2 registros FIB na Tabela de Encaminhamento. Se supormos que este é o único firewall no data center e ele deve ter conhecimento sobre todas as rotas, isso significa que o número total de rotas em nosso data center não pode ser mais do que 32K/(4 * 2) = 4K.
Agora, se supormos que temos 2 data centers (com design idêntico), e queremos usar VLANs 'estendidas' entre os data centers (por exemplo, para vMotion), para resolver o problema de roteamento, precisamos utilizar rotas de host. Mas isso significa que para 2 data centers teremos no máximo 4096 hosts possíveis e, claro, isso pode ser insuficiente.

Exemplo 2. ACL TCAM.
Se você planeja filtrar o tráfego em switches L3 (ou outras soluções que utilizem switches L3, por exemplo, Cisco ACI), ao escolher o hardware, deve prestar atenção ao ACL TCAM.
Suponha que você queira controlar os acessos nas interfaces SVI dos switches Cisco Catalyst 4500. Então, como é possível ver a partir de este artigo, para controlar o tráfego de saída (assim como o tráfego de entrada) nas interfaces, você pode usar apenas 4096 linhas TCAM. O que, ao usar o TCAM3, lhe proporcionará cerca de 4000 ACE (linhas ACL).

Se você se deparar com a questão de TCAM insuficiente, a primeira coisa a considerar é a possibilidade de otimização. Assim, em caso de problema com o tamanho da Forwarding Table, deve-se considerar a agregação de rotas. Se houver um problema com o tamanho do TCAM para acessos, uma auditoria dos acessos, a exclusão de entradas desatualizadas e sobrepostas, e talvez uma revisão do procedimento de abertura de acessos (isso será abordado em detalhes no capítulo sobre auditoria de acessos) é necessário.

Alta disponibilidade

A questão é se usar HA para firewalls ou instalar duas unidades independentes 'em paralelo' e, caso uma delas falhe, redirecionar o tráfego pela segunda?

À primeira vista, a resposta parece óbvia - usar HA. A razão pela qual essa questão ainda surge é que, infelizmente, os teóricos e os 99% de disponibilidade anunciados, com algumas casas decimais a mais, na prática revelam-se longe de ser tão otimistas. HA é uma coisa logicamente complexa, e em diferentes equipamentos e com diferentes fornecedores (não houve exceções) encontramos problemas, bugs e interrupções de serviço.

Ao usar HA, você terá a capacidade de desligar nodos individuais, alternar entre eles sem interromper o serviço, o que é importante, por exemplo, durante atualizações. No entanto, você ainda terá uma probabilidade não nula de que ambas as unidades falhem simultaneamente, além do fato de que uma atualização pode não ocorrer tão suavemente quanto promete o fornecedor (esse problema pode ser evitado se você tiver a possibilidade de testar a atualização em hardware de laboratório).

Se você não utilizar HA, sob a perspectiva de falhas duplas, seus riscos são significativamente menores (pois você terá dois firewalls independentes). No entanto, como as sessões não estão sincronizadas, sempre que ocorrer uma alternância entre esses firewalls, você perderá tráfego. É possível utilizar firewalls sem estado, mas isso em grande parte elimina o propósito de usar um firewall.

Portanto, se ao final da auditoria você encontrar firewalls isolados e estiver considerando aumentar a confiabilidade de sua rede, então HA é, sem dúvida, uma das soluções recomendadas. Mas você deve considerar também as desvantagens relacionadas a essa abordagem e, possivelmente, outra solução pode ser mais adequada para sua rede.

Conforto na gestão (managability)

Em princípio, HA também diz respeito à gerenciabilidade. Em vez de configurar 2 equipamentos separadamente e resolver o problema da sincronização das configurações, você os gerencia em grande parte como se tivesse um único dispositivo.

Mas, talvez, você tenha muitos data centers e muitos firewalls, então essa questão se eleva a um novo nível. E a questão não é apenas sobre configuração, mas também sobre