Uma história prática do firewall – Parte 2: o valor da gestão

Jody Brazil CEO da FireMon A Check Point e os firewalls de inspeção de estado venceram a primeira batalha contra os firewalls proxy («Parte 1: os primeiros tempos»). É fácil sugerir que tudo se resumiu à tecnologia de inspeção, mas isso ignora uma inovação essencial da solução da Check Point: a gestão de políticas. A vitória dos firewalls de inspeção de estado sobre a concorrência dos proxies, em meados dos anos 90, deveu-se, em parte significativa, à facilidade de gestão. Grande parte deste artigo centra-se na Check Point. Isto deve-se sobretudo ao papel dominante que a Check Point desempenhou no mercado de firewalls no final dos anos 90 e no início dos anos 2000. No entanto, deve-se também, provavelmente, ao meu contacto com a Check Point nesses anos. Agradeço a sua perspetiva e aguardo os seus comentários. Meados dos anos 90 foram uma época em que as redes evoluíam rapidamente. Por exemplo, a ethernet era uma opção, mas nem sempre o protocolo de rede local em utilização (lembra-se do token ring?). A ligação à Internet não era assumida, era discutida. O acesso telefónico ainda era comum e a AOL era o interveniente dominante. Sugerir que os firewalls eram uma tecnologia generalizada seria entender mal a Internet como algo generalizado. Uma das implicações desta rede em rápida mudança era um grau significativo de desconhecimento e inexperiência. Neste contexto, a facilidade de gestão de um firewall não deve ser ignorada como fator determinante do mercado para o eventual vencedor. Hoje, no desenvolvimento de software, falamos de experiência do utilizador e usabilidade. Embora não fossem esses os termos da moda na altura, a razão pela qual falamos deles hoje era igualmente importante então. Os clientes «gostavam» mais do produto. Por isso, embora a segurança e o desempenho fossem importantes, a usabilidade da interface gráfica do firewall da Check Point não deve ser desvalorizada. Citando um comercial da Gauntlet na altura: «Não importava quem era o potencial cliente; em todas as contas em que entrava, tinha de combater a interface gráfica da Check Point – e normalmente perdia.» A Check Point lançou o seu firewall com gestão centralizada e uma interface de utilizador muito inovadora. Algumas das capacidades principais incluíam:

• Um editor gráfico de regras
• Repositório central de objetos partilhado entre as políticas de firewall
• Registo centralizado
• Gestão multidomínio e OPSEC

O editor de políticas da Check Point

O conceito de uma regra de firewall como um conjunto de cinco elementos – origem, destino, protocolo, porta (protocolo e porta eram combinados num único objeto designado por serviço) e ação – existia muito antes do editor de políticas da Check Point. As primeiras listas de controlo de acesso suportavam este conceito nos anos 80. No entanto, a Check Point mudou o paradigma com o editor gráfico de regras. Deixou de ser necessário conhecer a sintaxe da CLI para criar uma regra. Bastavam um rato e alguns cliques. Além disso, a edição de regras foi enriquecida com funcionalidades úteis como copiar e colar, comentários definidos pelo utilizador e vários objetos por coluna. Este último ponto, sobre vários objetos por coluna, foi revolucionário. As listas de controlo de acesso anteriores só suportavam uma única origem, um único destino e um único serviço nas respetivas colunas. O suporte para vários objetos tornou cada regra mais poderosa, e editar uma política passou muitas vezes a ser um ato de modificar uma regra existente em vez de criar novas regras. Grande parte deste editor de políticas assentava noutro avanço: o repositório central de objetos.

O repositório central de objetos da Check Point

Historicamente, as listas de controlo de acesso eram criadas com uma referência a um endereço IP específico para a origem ou o destino. Isto funcionava, mas se o IP de um sistema mudasse, todas as regras teriam de ser atualizadas. À semelhança do código-fonte reutilizável, a Check Point percebeu que criar um repositório central de objetos e utilizar esses objetos nas regras seria uma estratégia melhor. Assim, se um anfitrião mudasse de IP, apenas o objeto precisava de ser atualizado, e a política refletiria automaticamente essa atualização de forma correta, uma vez que utilizava uma referência ao objeto armazenado. Além disso, era possível criar grupos destes objetos (e grupos de grupos) para permitir a reutilização de grupos comuns de objetos em toda a política. Estes foram avanços significativos para uma gestão de políticas mais eficaz.

Registo centralizado

Um problema extremamente comum com os firewalls é bloquear o tráfego errado. Particularmente ao colocar um firewall entre duas redes que anteriormente não estavam segmentadas, o que, no final dos anos 90, era o caso de praticamente todas as novas implementações de firewall. O registo centralizado de todos os registos de firewall, também facilmente pesquisável, tornava o diagnóstico de erros de política muito evidente e comparativamente simples. Um utilizador podia comunicar um problema, fornecer uma combinação de IP de origem/IP de destino, e um administrador podia encontrar o registo de «drop» no visualizador de registos e a regra associada que causou o bloqueio (ou, em alternativa, encontrar um registo de «accept» e informar o utilizador de que estava enganado). Os erros eram, e continuam a ser, comuns na administração de políticas de firewall, pelo que a facilidade de resolução de problemas era uma mais-valia essencial para qualquer plataforma de firewall.

Gestão multidomínio e OPSEC

No início dos anos 2000, a Check Point reforçou a aposta no poder da gestão ao introduzir a gestão multidomínio com o Provider-1 e as APIs de integração com o OPSEC. Ambos representaram uma aposta significativa no poder da gestão para distinguir a Check Point dos restantes concorrentes no mercado de firewalls – e resultou. O Provider-1, como o nome sugere, destinava-se à comunidade de fornecedores, telecomunicações e prestadores de serviços geridos. Embora os fornecedores tenham sido os primeiros a adotar a tecnologia, as empresas rapidamente encontraram razões para serem igualmente consumidoras do produto. Capacidades essenciais como o controlo de permissões, o desempenho de gestão e da interface através da divisão de políticas e bases de dados de objetos de grande dimensão, e as regras globais que podiam ser aplicadas e impostas globalmente eram todas funcionalidades muito procuradas pelas grandes empresas. Em grande medida, tratava-se de limitações da plataforma de gestão padrão. Embora haja quem defenda que a Check Point deveria ter corrigido a plataforma de gestão em vez de exigir que os clientes pagassem um prémio significativo pelo Provider-1, os clientes viam os benefícios e estavam dispostos a pagar por estas capacidades avançadas de gestão. O OPSEC era um programa de parceiros e um conjunto de APIs lançado pela Check Point para incentivar a integração de produtos de terceiros. Entre os primeiros êxitos contavam-se produtos de relatórios que utilizavam a Log Export API (LEA), produtos de filtragem de URL que utilizavam o URL Filtering Protocol (UFP) e produtos de gestão, como a FireMon, que utilizavam a Check Point Management Interface (CPMI). O programa e as integrações foram um enorme sucesso. Atualmente, existem bem mais de 100 parceiros OPSEC que oferecem alguma capacidade de integração com a plataforma. Este ecossistema de produtos de segurança confere aos clientes valor acrescentado e confiança no seu investimento. Hoje, damos as integrações por API como garantidas, mas em 2001, no lançamento do OPSEC, isso estava longe de ser tão comum.

A Cisco e a CLI eram um interveniente dominante

O mercado não era totalmente dominado pela Check Point e pela interface gráfica. Enquanto a Check Point se afirmava como líder no mercado de firewalls com uma interface gráfica poderosa e fácil de utilizar, a Cisco mantinha-se fiel às suas raízes com uma interface de linha de comandos (CLI) no Pix. O Pix era um concorrente mais antigo no mercado de firewalls, remontando a 1994 e adquirido pela Cisco em 1995. A familiaridade dos administradores de rede com a Cisco e a CLI fazia do Pix a escolha preferida quando a equipa de rede era responsável pela segurança. A Check Point iria erodindo esta vantagem com as suas funcionalidades de segurança e a interface gráfica, ajudada por uma lenta mudança na estrutura organizacional das empresas, em que a segurança passaria a ser um grupo separado da equipa de rede. À medida que esta mudança ocorria, a relação existente entre a Cisco e a equipa de rede foi tendo um papel cada vez menor na seleção do fornecedor de firewall. As capacidades de gestão melhoradas ajudaram a consolidar a posição da Check Point no mercado e reforçaram o valor da gestão para os produtos de segurança. Mas, tal como o desempenho ajudou a Check Point a vencer o proxy nos anos 90, nos anos seguintes o desempenho voltaria a ser um critério de decisão fundamental e, desta vez, a Check Point ficaria ameaçada. Parte 3: o desempenho assume o palco principal