As arquiteturas e modelos operacionais existentes de cibersegurança começam a falhar quando as empresas adotam plataformas na nuvem pública. Por quê? Quase todas as violações na nuvem resultam de configurações incorretas (em inglês), não de ataques que comprometem a infraestrutura da nuvem.
A nuvem exige a configuração segura de aplicativos e sistemas. No entanto, os mecanismos tradicionais de cibersegurança não foram desenhados para assegurar uma configuração segura ou para operar no ritmo necessário para capturar os benefícios da agilidade e da velocidade que os líderes de negócios esperam. Como resultado, se as empresas quiserem capturar o valor da nuvem (em inglês), elas precisam adotar novas arquiteturas e processos de segurança para proteger suas cargas de trabalho na nuvem. Desse modo, a migração para a nuvem poderá aumentar não apenas a entrega de valor comercial, mas também a segurança dos sistemas e aplicativos em comparação com a oferecida pelo mundo antigo de TI localizada fisicamente na empresa.
A “segurança como código de programação” (SaC – security as code)1, ou simplesmente “segurança como código”, mostrou-se a abordagem mais eficaz para proteger cargas de trabalho na nuvem com rapidez e agilidade. Hoje em dia, a maioria das empresas que utilizam a nuvem concorda que a infraestrutura como código (IaC) permite-lhes automatizar a construção de sistemas na nuvem sem configuração manual, reconhecidamente sujeita a erros. A SaC vai um passo além e define políticas e padrões de cibersegurança por meio de códigos programáticos, de modo que possam ser acessados automaticamente pelos scripts de configuração utilizados para aprovisionar os sistemas na nuvem. Além disso, os sistemas executados na nuvem podem ser comparados com políticas de segurança para prevenir “drift”2 (Quadro 1). Se a empresa, por exemplo, instituir a política de que todas as informações pessoais identificáveis (PII) precisam ser criptografadas ao serem armazenadas, tal política será traduzida em um processo que se inicia automaticamente sempre que um desenvolvedor enviar algum código. O código que violar a política de PII será rejeitado automaticamente.
Para a maioria das empresas, capturar valor na nuvem exige a construção de um mecanismo de transformação (Quadro 2) que integre a nuvem aos negócios e às tecnologias, promova a adoção em domínios de negócios prioritários e estabeleça as capacidades fundamentais necessárias para dimensionar o uso da nuvem de forma segura e econômica. A SaC é o mecanismo para desenvolver as capacidades fundamentais de segurança e gestão de risco na nuvem.
Sim, teoricamente, a SaC poderia ser implementada nos próprios data centers da empresa, mas os recursos de automação disponibilizados pelos provedores de serviços na nuvem (CSPs) tornam muito mais prático implementá-la na nuvem.
Os três benefícios mais poderosos da SaC
O primeiro benefício da SaC é a rapidez. Para aproveitar plenamente os benefícios da nuvem para os negócios, as equipes de segurança devem agir em um ritmo ao qual não estão acostumadas na própria empresa. Intervenções manuais introduzem atrito, o que retarda o desenvolvimento e corrói a proposta geral de valor da nuvem para a empresa.
O segundo benefício é a redução dos riscos. Os controles de segurança locais simplesmente não dão conta das nuances da nuvem. A segurança na nuvem requer que os controles acompanhem uma carga de trabalho ao longo de todo o seu ciclo de vida. E a única maneira de atingir esse nível de segurança integrada é por meio da SaC.
Por fim, a SaC facilita os negócios. Os requisitos de segurança e de compliance estão se tornando cada vez mais fundamentais para os produtos e serviços essenciais de uma empresa. Nesse aspecto, a SaC não apenas acelera o time-to-market, como também amplia as oportunidades de inovação e criatividade de produtos sem comprometer a segurança.
Implementando a SaC
Em quase todas as empresas, a implementação da SaC requer uma postura totalmente nova em termos de políticas, arquitetura e cultura. Por esse motivo, muitas acham proveitoso utilizar a estrutura da SaC para classificar as cargas de trabalho de acordo com sua sensibilidade e criticalidade e, em seguida, aplicar controles específicos com base no risco e tipo de implementação de cada uma. Além disso, essa estrutura constitui um referencial para a arquitetura do estado futuro da segurança da empresa e, por meio de vários casos de uso de automação, descreve as principais decisões que precisam ser tomadas para concretizar a SaC de forma eficaz e eficiente. Por fim, a estrutura define como o modelo operacional da empresa precisa mudar para extrair todos os benefícios da nuvem (Quadro 3).
Classificações de risco, modelo de implantação e padrões/políticas
Depois de classificar a sensibilidade e a criticalidade da carga de trabalho e de seus dados, a etapa seguinte é aplicar políticas específicas que possam vir a ser concretizadas como código de programação. Para chegarem a esse nível, as organizações geralmente se deparam com três opções para cada área de controle.
A primeira é identificar e redigir novas políticas que deem conta de tecnologias que não estão presentes na localidade física da empresa. É o caso da segurança de contêineres, por exemplo. As empresas que sempre operaram a partir de suas próprias instalações tendem a não fiscalizar a varredura de contêineres em busca de vulnerabilidades – seja no envio, na implantação ou no tempo de execução. Da mesma forma, é preciso haver políticas para o uso de imagens confiáveis e registros seguros. Outro exemplo de uma lacuna comum nos padrões é a segurança da API e a necessidade de autenticar o tráfego e de controlar o uso de APIs por meio de um gateway.
Além de redigir novas políticas, as empresas devem modificar as políticas de segurança local existentes a fim aproveitarem o contexto de segurança específico da nuvem. Consideremos a segmentação de redes, por exemplo. Se, em suas localidades físicas, a maioria das organizações adota políticas de segmentação de redes que incluem não mais que regras de firewall para os limites um tanto vagos de suas redes, na nuvem elas poderão configurar grupos de segurança que oferecem proteções para a rede até o nível do host, o que equivale a oferecer microssegmentação mesmo em uma única sub-rede. Além disso, poderão continuar usando os controles mais rudimentares no nível de perímetro das sub-redes ou da rede virtual. Tudo isso pode ser configurado e mantido por códigos de programação, e não por processos manuais ou runbooks [procedimentos de rotina realizados pelo administrador do sistema].
Por fim, para que a promessa da SaC se torne realidade, todas as políticas – existentes e novas – devem ser redigidas com nível de detalhamento suficiente para que possam ser traduzidas em código de programação. Uma das maiores falhas que observamos na formulação de políticas de segurança eficazes é a escassez de pessoas que entendam como desenhar políticas eficazes e sua implementação. Se as políticas ou sua implementação forem de baixa qualidade, isso pode se tornar tão problemático e dispendioso quanto os riscos que elas visam eliminar. Talvez o exemplo mais comum envolva a segurança de aplicativos. As políticas devem ser granulares o suficiente para que automaticamente impeçam um aplicativo de entrar em produção se tiver alguma vulnerabilidade pendente cuja correção exceda um prazo prescrito. Do mesmo modo, para fins de gerenciamento de identidade e acesso, as políticas devem integrar os aplicativos de software como serviço (SaaS) a um sistema de identidade federada que automaticamente aplique autenticação multifator (MFA) conforme a classificação de risco do aplicativo.
Arquitetura e automação
Depois que a organização criou uma estrutura robusta de classificação de riscos e definiu suas políticas para a nuvem, o sucesso da implementação da SaC dependerá de decisões-chave sobre o desenho da arquitetura e da aplicação das capacidades de automação corretas. Assim como deve ser feito com as políticas, recomendamos mapear essas decisões para as áreas prioritárias de controle da organização.
Mas antes que uma empresa possa responder a perguntas fundamentais sobre sua arquitetura de segurança na nuvem, ela deve primeiro tomar decisões de desenho sobre sua arquitetura geral na nuvem. Isso pode parecer óbvio, mas é uma etapa crítica que muitas vezes é esquecida. A organização só deve começar a desenhar a arquitetura de segurança após ter esclarecido as principais questões sobre sua arquitetura multinuvem – incluindo, entre outras coisas, a escolha do provedor principal na nuvem e como o perímetro estratégico será desenhado.
Talvez a decisão mais importante para implementar a SaC seja saber se os objetivos da política serão concretizados por meio de ferramentas federadas, ferramentas do próprio provedor de serviços na nuvem, ou ferramentas centralizadas de terceiros. Não existe uma resposta inerentemente certa ou errada; na verdade, esta questão deve ser considerada no contexto do apetite por riscos da organização, da classificação das cargas de trabalho, dos objetivos da política e da estratégia geral para a nuvem. A preferência por ferramentas centralizadas de terceiros é justificável, pois elas possibilitam uma visão integrada tanto do ambiente local como da nuvem por meio de um único painel de vidro, por assim dizer.
A automação é fundamental para que as políticas sejam cumpridas nas diferentes fases do ciclo de vida do desenvolvimento dos sistemas (SDLC). Portanto, é importante que as organizações desenvolvam uma lista abrangente de casos de uso de automação da segurança para seu ambiente multinuvem. Ao contrário das metas das políticas e das capacidades das arquitetura (que foram mapeadas para áreas de controle), esses casos de uso devem ser mapeados para as fases do SDLC: codificar, construir, empacotar, implantar e operar. Alguns casos de uso, como a desativação de sistemas e os testes de failover [tolerância a falhas], são exclusivos de implantações de infraestrutura como um serviço (IaaS); outros, como transmissão de logs, ingestão e varredura de código, são comuns a vários modelos de implantação. Um “Serviço de Compliance do Mecanismo Governança da Nuvem” deve ser utilizado para gerenciar o processo. Trata-se de um serviço centralizado que se responsabiliza por aceitar solicitações de aprovisionamento e verificar se a IaC [infraestrutura como código] cumpre as normas de compliance da organização antes de aprovisionar os recursos da nuvem.
Modelo operacional e seu vínculo com uma estratégia mais ampla para a nuvem
Ao embarcarem em uma jornada para a nuvem e adaptarem sua segurança a essa nova realidade, quase todas as empresas priorizam a tecnologia. Todavia, por mais que a mudança de tecnologia seja importante, o modelo operacional das empresas precisa evoluir de modo a shift left [antecipar etapas], maximizar os autosserviços e automatizar a segurança de todo o ciclo de vida.
A SaC requer serviços altamente automatizados que os desenvolvedores possam consumir por meio de APIs. Isso, por sua vez, requer mudanças comportamentais nas equipes de segurança, infraestrutura e desenvolvimento de aplicativos. A organização de segurança deve passar de um modelo reativo e baseado em solicitações para outro que desenvolva produtos de segurança altamente automatizados – por exemplo, para o gerenciamento de identidade, acesso ou vulnerabilidades. Na nuvem, muitos controles são simples opções de configuração de um serviço de computação ou armazenamento. Como resultado, as equipes de engenharia de produtos de infraestrutura precisam colaborar muito mais de perto com seus colegas de segurança para aplicar as normas de segurança a seus backlogs de produtos. As equipes de desenvolvimento precisam de engenheiros da confiabilidade do site (SREs) que sejam sofisticados o suficiente para consumirem serviços de segurança de forma eficaz no aprovisionamento e no gerenciamento de aplicativos.
Para que isso aconteça, as empresas precisam alinhar uma cadeia de ferramentas de desenvolvimento em comum com pipelines de integração e entrega contínuas (CI/CD) (Quadro 4). Se essas capacidades não forem padronizadas, a SaC – e, portanto, a segurança na nuvem – torna-se praticamente impossível. Também é preciso aprimorar as habilidades em toda a organização de tecnologia. Os SREs precisam ser consumidores sofisticados de segurança. Os gerentes e engenheiros de produtos de infraestrutura precisam entender as implicações de segurança de seus produtos. E a organização de segurança precisa de mais capacidades de gerenciamento e engenharia de produtos do que de compliance.
Como uma empresa implementou a SaC
Uma instituição financeira de atacado pretendia mover 80% de suas cargas de trabalho para a nuvem. No entanto, logo ficou claro que a abordagem tradicional de resolver de forma reativa os problemas de compliance – isto é, depois que já haviam passado para ambientes de produção – não conseguiria dar conta das cargas de trabalho da nuvem. Diante disso, a empresa decidiu promover proativamente compliance no pipeline por meio da SaC.
Para que isso acontecesse, classificou cerca de 400 controles para seus aplicativos críticos para a missão a fim de assegurar a resiliência da infraestrutura na nuvem. Em seguida, formulou e implementou mais de 90 regras para oferecer suporte a esses controles e traduziu-as em pequenos trechos de código, que são invocados sempre que qualquer solicitação de aprovisionamento de infraestrutura é feita. Esses blocos de código garantem que todos as normas de compliance sejam cumpridas antes do aprovisionamento. Essa abordagem hoje fornece cobertura automatizada para cerca de metade de todos os requisitos de segurança.
Com demasiada frequência, a segurança é vista como algo que impede a empresa de adotar a nuvem. O que deveria ser um processo de implantação sem atritos, com segurança incorporada desde o início, torna-se semanas ou meses de idas e vindas entre desenvolvedores e pessoal de infraestrutura e segurança, que tentam adaptar “na marra” as implantações na nuvem aos mecanismos de segurança legados. Aprovações demoradas – envolvendo desde avaliações de terceiros até mudanças no firewall – não apenas diminuem a proposta de valor geral da nuvem, como também aumentam a necessidade de abrir exceções arriscadas às políticas a fim de acomodar os requisitos de negócios.
A SaC busca inverter essa tendência e posicionar os CISOs como facilitadores – não empecilhos – de negócios. Ao eliminar a necessidade de fluxos de trabalho baseados em tickets, de escalonamentos e de processos de mudança manuais, uma estrutura de SaC automatiza os controles de segurança mais críticos e aprimora a segurança geral em comparação com os sistemas locais – sem desacelerar os negócios ou sacrificar as normas de compliance.