O que é política como código (PaC)?

Em vez de depender de humanos para verificar a conformidade ou lembrar das regras de segurança, essas regras existem como lógica executável que é acionada sempre que um desenvolvedor ou sistema propõe uma alteração ou solicitação. Se alguém enviar uma alteração, um mecanismo de políticas avalia automaticamente a alteração em relação às regras codificadas e permite, nega ou sinaliza a alteração.

Esse processo migra as práticas de gerenciamento de políticas de documentos estáticos para uma superfície de controle dinâmica e continuamente aplicada, incorporada no pipeline de entrega de software.

Regras baseadas em código ajudam a garantir que as mesmas políticas sejam aplicadas em todos os lugares, de forma repetível e escalável. Os mecanismos de políticas podem executar verificações automatizadas em segundos durante compilações ou implementações, reduzindo os ciclos de feedback e ajudando as equipes de DevOps a evitar surpresas de segurança ou conformidade em estágios avançados.

O PaC permite que as empresas melhorem sua postura geral de cibersegurança e mantenham a conformidade com os padrões regulatórios e do setor. Além disso, tratar as políticas como código está alinhado com uma transição mais ampla para "tudo como código", que transforma itens como solicitações de infraestrutura em arquivos de código revisáveis, nos quais as equipes de desenvolvimento podem colaborar.

Em termos de DevOps, uma política é uma regra clara e aplicável sobre como a infraestrutura e as aplicações de TI devem ser configuradas, acessadas ou executadas. Mais precisamente, as políticas ditam quais ações são permitidas, necessárias ou proibidas para que os sistemas continuem funcionando em seu estado ideal.

Por exemplo, "todos os buckets de armazenamento devem ser criptografados" ou "nenhum serviço público pode expor a porta 22" são políticas, pois especificam restrições concretas sobre o comportamento do sistema.

Com o PaC, as políticas são escritas em uma linguagem de programação estruturada, permitindo que mecanismos de políticas e ferramentas de automação as analisem e as avaliem de forma determinística. Dessa forma, as políticas se tornam proteções executáveis que os sistemas e os engenheiros devem satisfazer, em vez de diretrizes que as pessoas podem interpretar de forma diferente.

As ferramentas de "Política como Código" permitem que os desenvolvedores escrevam código executável em ambientes de tempo de execução e pipelines de integração contínua/entrega contínua (CI/CD), de forma que cada alteração seja verificada automaticamente quanto à adesão.

Tecnicamente, a maioria das configurações de PaC segue as mesmas etapas principais:

• Os desenvolvedores escrevem políticas na forma de arquivos de código. Eles podem usar uma variedade de linguagens imperativas e declarativas de alto nível, incluindo Python, YAML, JavaScript Object Notation (JSON) ou Rego, que normalmente é usado junto com o Open Policy Agent (OPA), um mecanismo de políticas de código aberto. Cada arquivo de política declara as entradas que lhe interessam (“resource.kind,” “metadata.labels,” por exemplo), codifica condições (também chamadas de "predicados") e resultados (permissão/negação, gravidade, mensagens).

• O código é enviado a um sistema de controle de versão, como Git ou GitHub, e passa pelos mesmos fluxos de trabalho que o código da aplicação, incluindo pull requests, avaliações de código e testes de sintaxe rigorosos.

• Um mecanismo de políticas lê o arquivo de código, o analisa e o transforma em estruturas de dados e instruções compreensíveis internamente. Essas estruturas e instruções são então convertidas em um formato de instrução compacto e de baixo nível (bytecode) para uma rápida avaliação.

• Um chamador, o trecho de código que solicita uma decisão ao mecanismo de políticas, normaliza as entradas de dados. O chamador processa diferentes formatos de entrada, incluindo arquivos da HashiCorp Configuration Language (HCL) e modelos JSON de ferramentas IaC, manifestos YAML do Kubernetes e plataformas em nuvem, solicitações HTTP de chamadas de API, dados de aplicativos e de telemetria de ambientes de tempo de execução e produção. Ela limpa e remodela a entrada bruta em uma estrutura padrão, para que as políticas possam ler as entradas de forma consistente.

• O chamador devolve os dados normalizados ao mecanismo de políticas, que começa a executar o código da política nas entradas de dados.

• O mecanismo de políticas analisa as regras e verifica os predicados de cada regra em relação à entrada para entender quais predicados se aplicam. Podemos pensar no mecanismo de políticas como se ele perguntasse: "O que esta regra diz sobre essa entrada?"

• O mecanismo de políticas considera os resultados de todas as regras e os combina em uma única decisão política, um processo chamado agregação de decisões, e cria uma lista de mensagens. As mensagens fornecem mais detalhes (qual regra foi violada e qual objeto a violou) sobre o código com falha e, às vezes, oferecem sugestões sobre correções.

• O mecanismo de políticas retorna a decisão, incluindo mensagens relevantes, tags e informações de gravidade. Se a decisão for "negar", o mecanismo de políticas bloqueia todos os pull requests e merges de código e interrompe a implementação até que os desenvolvedores corrijam a violação da política. Se a decisão for "permitir", o mecanismo cria um artefato de compilação (um arquivo de código compilado, empacotado e testado) e implementa o código. Se houver avisos, o código poderá passar, mas o mecanismo incluirá os avisos em arquivos de log ou comentários.

As verificações de políticas podem ocorrer em qualquer ponto do ciclo de vida de desenvolvimento de software (SDLC), desde a integração do código até a produção e o monitoramento em tempo real.

Como as políticas são códigos, elas também podem ser tratadas como qualquer outro artefato de software.

As equipes de desenvolvimento podem escrever testes automatizados que alimentam entradas de amostra nas políticas e verificam as decisões que elas retornam para acelerar os ciclos de feedback quando as políticas mudam.

Ao codificar as políticas, os desenvolvedores podem extrair a lógica comum em módulos ou funções reutilizáveis. Várias políticas de nível superior podem então recorrer a políticas compartilhadas em vez de duplicar condições em todos os lugares.

Os desenvolvedores também podem renomear, reestruturar ou dividir políticas grandes em políticas menores sem alterar seu comportamento, assim como acontece ao refatorar uma grande função de aplicativo em funções menores.

Esses recursos permitem que as equipes apliquem as práticas de engenharia de software existentes à lógica de governança, o que as ajuda a manter os requisitos de segurança e conformidade à medida que as arquiteturas de TI escalam e evoluem.

Digamos que a Empresa X queira implementar uma política "somente HTTPS", na qual todos os serviços da web devem usar HTTPS, não HTTP simples. Para codificar a política, um engenheiro de plataforma escreve uma regra simples que diz:

• Se o protocolo de um serviço for HTTP, a alteração deverá ser rejeitada.
• Se o protocolo de um serviço for HTTPS, a alteração será permitida.

O engenheiro coloca esse arquivo de política em uma pasta “policies” dentro do mesmo repositório de código da aplicação e abre um pull request para adicionar a política. Esse pull request aciona uma verificação automática de sintaxe do arquivo de políticas e uma avaliação do código por outro engenheiro. Somente após a política passar pelos testes necessários é que ela é incorporada à branch principal.

No pipeline de integração contínua (CI), todos os arquivos de política são carregados no mecanismo de políticas a partir da pasta “policies”. O mecanismo de políticas lê a política, converte-a em uma representação interna e a compila em um formato compacto e de baixo nível. Esse formato compacto permite que o mecanismo responda rapidamente "permitir ou negar?" para cada serviço verificado no pipeline.

Independentemente do formato do arquivo, um trabalho de CI pega o arquivo de configuração existente, extrai os campos importantes (nome, protocolo, porta) e cria uma descrição JSON simples de cada serviço.

O responsável pela chamada solicita uma decisão ao mecanismo de políticas enviando a descrição padronizada do serviço como entrada e indicando que o pacote de políticas “somente HTTPS” deve ser aplicado.

O mecanismo de políticas então avalia o input em relação às regras e verifica o campo de protocolo do serviço. Se o protocolo for HTTP, isso significa que a entrada corresponde à condição de "negação" na política. O mecanismo indica que a alteração deve ser negada e cria uma mensagem informando ao desenvolvedor que o serviço deve usar HTTPS em vez de HTTP. Se o serviço usar HTTPS, nenhuma das condições de negação será atendida, e o mecanismo indicará que a alteração é permitida.

Em seguida, o mecanismo de políticas resume as avaliações de regras em um único objeto de decisão para o serviço. Os objetos de decisão normalmente especificam se a decisão geral é "permitir" ou "negar" e a gravidade do problema (alta, média, baixa). Eles também incluem uma lista de mensagens explicando por que a entrada foi negada e quaisquer avisos que o mecanismo encontrou no processo de avaliação. Se tudo estiver em conformidade, o objeto de decisão indica que a alteração é permitida e inclui apenas notas informativas (ou nenhuma mensagem).

Por fim, as ferramentas de CI reforçam a decisão. Se a decisão for "negar", a alteração não será integrada à branch principal do código. O engenheiro vê uma mensagem de erro dizendo que o serviço deve usar HTTPS e passar por modificações específicas. Se a decisão for “permitir”, o artefato será empacotado e implementado, e o pipeline de CI continuará normalmente.

A política como código surgiu de um movimento mais amplo de "tudo como código" no DevOps moderno e na engenharia de nuvem.

Originalmente, a infraestrutura como código (IaC) foi a grande mudança. Em vez de administradores de sistemas navegarem por interfaces de usuário ou seguirem runbooks, as equipes passaram a descrever servidores, redes e outros recursos em arquivos de código declarativo. Esses arquivos são armazenados em sistemas de controle de versão e aplicados por meio de pipelines automatizados.

À medida que as empresas viram os benefícios, a abordagem se espalhou para outros componentes das arquiteturas de TI. A configuração das aplicações migrou para abordagens baseadas em código. Os pipelines de CI/CD tornaram-se scripts que residem em repositórios de código. As regras de monitoramento e alerta também começaram a residir no código. Juntas, essas práticas ficaram conhecidas como “tudo como código”.

A ideia central de "tudo como código" é que, se alguma parte do sistema pode ser descrita, ela deve ser descrita como código e gerenciada da mesma forma que as aplicações de software.

O PaC é essencialmente a aplicação dessa filosofia às regras, governança e conformidade. Tradicionalmente, as políticas eram documentadas em PDFs e wikis ou definidas por comitês, e sua aplicação dependia de pessoas. Esse processo funcionava quando os ciclos de lançamento eram lentos e a infraestrutura era relativamente estática.

Com a ascensão das arquiteturas nativas da nuvem e microsserviços, e com as equipes implementando código várias vezes ao dia, os processos manuais não conseguiram acompanhar o ritmo. O PaC enfrentou esse desafio expressando políticas em formatos legíveis por máquina, para que elas possam ser versionadas no Git, revisadas como arquivos de código, testadas em CI e aplicadas automaticamente em pipelines ou em tempo de execução.

Política como código é uma prática para gerenciar políticas de TI como código de software. Infraestrutura como código (IaC) é semelhante, mas com um foco diferente. Ela permite que as equipes de engenharia definam e gerenciem a infraestrutura de TI usando aplicação.

Em vez de criar e configurar manualmente ativos de rede, como máquinas virtuais (VMs) e balanceadores de carga, o IaC permite que os desenvolvedores escrevam código para descrever o estado desejado desses recursos. Então, uma ferramenta de IaC pega esse código e cria ou modifica os recursos especificados.

O IaC facilita muito o dimensionamento e a automação da infraestrutura. Se uma equipe precisar de mais servidores, ela pode simplesmente alterar um número no código (de seis instâncias para nove, por exemplo). As ferramentas de automação cuidam dos detalhes de provisionamento desses recursos extras.

Em um alto nível, o IaC determina qual infraestrutura deve existir e como ela deve ser configurada, enquanto o PaC se concentra nas regras e restrições que a infraestrutura deve obedecer. O código IaC cria e configura recursos, e o código PaC ajuda a garantir que esses recursos (e as formas como são utilizados) sigam os requisitos de segurança definidos, os padrões de conformidade e as diretrizes operacionais.

Em muitas arquiteturas de TI modernas e configurações de CI/CD, IaC e PaC oferecem benefícios complementares. O IaC automatiza o provisionamento, e o PaC adiciona governança automatizada.

Quando um desenvolvedor altera um arquivo IaC, um mecanismo de PaC pode inspecionar o novo plano ou configuração. Se tudo estiver em conformidade com as políticas estabelecidas, a mudança poderá prosseguir e a infraestrutura será atualizada. Se algo violar uma regra, o pipeline falhará e nada será implementado até que o problema seja corrigido.

O DevSecOps consiste em incorporar segurança e conformidade ao ciclo de vida do DevOps, em vez de adicioná-las posteriormente. É uma abordagem de desenvolvimento em que os processos de segurança são priorizados e executados durante cada estágio do ciclo de vida do desenvolvimento do software.

O PaC apoia as práticas de DevSecOps por meio de:

O PaC ajuda as equipes a transferir as verificações de segurança para os estágios iniciais do processo de desenvolvimento, em vez de esperar para executar as verificações após a implementação, quando os problemas podem afetar os usuários. Se um desenvolvedor introduzir uma configuração arriscada ou um padrão inseguro, as políticas automatizadas podem ajudar a detectar o problema e interromper a compilação.

As ferramentas de PaC automatizam a aplicação ao incorporar regras de segurança diretamente nos pipelines de CI/CD e sistemas de tempo de execução, de modo que as verificações acontecem automaticamente sempre que o código ou a infraestrutura mudam. Em vez de depender de pessoas para lembrar de todos os padrões de segurança e fazer avaliações manualmente de cada alteração, o sistema avalia com consistência as alterações para garantir que nenhuma etapa seja ignorada de forma acidental.

O PaC ajuda os desenvolvedores a manter a velocidade de implementação sem sacrificar a consistência e a segurança. Ele executa as mesmas definições de política em todos os ambientes e em todas as etapas: desenvolvimento, teste, preparação e produção. Essa funcionalidade permite que as equipes façam lançamentos frequentes, pois podem confiar que o mesmo conjunto de regras está sendo aplicado em todos os lugares. Isso também ajuda a evitar situações em que ambientes diferentes se distanciam ou usam interpretações ligeiramente diferentes das regras.

O PaC trata as políticas de segurança de aplicação como qualquer outro artefato de código que reside em um sistema de controle de versão. As equipes de desenvolvimento, operações e segurança podem revisar, discutir e atualizar as políticas por meio de fluxos de trabalho familiares (avaliações de código, estratégias de ramificação), o que torna as discussões de políticas mais transparentes e mais integradas ao trabalho diário de desenvolvimento.

A política como código tem uma ampla gama de aplicações para arquiteturas de TI empresariais.

Desenvolvedores e profissionais de segurança estão explorando políticas como código como uma forma de criar modelos de proteção em camadas que abrangem todo o ciclo de vida de uma IA ou de um fluxo de trabalho agêntico. Embora a prática ainda esteja surgindo, as investigações iniciais revelaram muitas aplicações possíveis do PaC em fluxos de trabalho de IA.

O PaC pode ajudar a estabelecer uma separação clara entre o raciocínio da IA e o sistema que decide quais ações ela realmente pode executar. A ferramenta de IA pode propor ações ou planos, mas um mecanismo de políticas avalia essas propostas em relação a regras codificadas antes que qualquer sistema subjacente seja acionado.

Na fase de input, o PaC pode ajudar a filtrar ou transformar os prompts do usuário, ocultar dados confidenciais, impor o isolamento do tenant e bloquear padrões de ataque conhecidos. Durante o planejamento, o PaC pode exigir que agentes de IA produzam planos estruturados e validem cada etapa em relação às ferramentas, ações e condições de risco permitidas antes que a execução seja autorizada.

No tempo de execução, cada invocação de ferramenta ou chamada de API pode ser verificada pela camada de imposição de política. Essa camada decide se permite, nega ou modifica uma ação, ou se a encaminha para um ser humano. Após a execução, as políticas podem orientar o registro, as trilhas de auditoria, as regras de retenção e os pós-filtros nas saídas do modelo para ajudar a garantir que as respostas estejam em conformidade com os requisitos necessários.

• Consistência. Com o PaC, as políticas são aplicadas da mesma forma em todos os ambientes porque o mesmo código é executado em todos os lugares. Essa consistência reduz as configurações únicas, "snowflake", e evita que as equipes tenham que se lembrar de processos manuais ligeiramente diferentes para cada ambiente.

• Eficiência. Quando as políticas são codificadas, elas podem ser aplicadas automaticamente em pipelines de CI/CD ou no momento da implementação, eliminando a necessidade de verificações e aprovações manuais.

• Automação. O PaC permite a validação automatizada e o teste de políticas, o que ajuda as equipes a minimizar o impacto do erro humano, detectar configurações incorretas e lidar com vulnerabilidades de segurança antes que elas cheguem à produção.

• Visibilidade. Com políticas escritas em código e armazenadas de forma centralizada, os stakeholders podem ver exatamente quais regras estão em vigor, em vez de depender de documentos dispersos e da memória das pessoas.

• Escalabilidade. A avaliação de políticas é automatizada, para que as organizações possam aplicar políticas em escala em muitos serviços, clusters ou contas sem aumentos proporcionais no número de funcionários.

• Colaboração. O PaC simplifica a colaboração em torno do código de políticas. Esses fluxos de trabalho compartilhados eliminam silos, alinham a segurança e a governança com práticas de DevOps e tornam as discussões de políticas mais concretas e testáveis.