A infraestrutura como código é fundamental para DevOps, automatizando o trabalho de criação e manutenção de infraestrutura de sistemas, tornando-a melhor definida, eficiente, testável, auditável e padronizada.

Mas, para muitos de nós que trabalham em ambientes regulados, precisamos de mais. Precisamos de conformidade como código.

Pense em restrições regulamentares, políticas e procedimentos de conformidade, processos e restrições dirigidas, e faça tanto uso disso quanto possível em fluxos de trabalho e testes automatizados.

Toolkit DevOps de auditoria de defesa

Alguns grandes passos em direção à conformidade como código são definidos no pacote de ferramentas para auditoria DevOps, um documento livremente disponível que explica como os requisitos de conformidade, tais como a separação de funções entre os desenvolvedores e suas operações, e detectar/impedir alterações não autorizadas, podem ser atendidos em um ambiente DevOps, usando alguns controles básicos comuns:

1. Revisões de código: todas as alterações de código devem ser revisadas ​​antes do check-in. Quaisquer alterações de alto risco no código devem ser revisadas uma segunda vez por um expert. Revisores devem verificar o código e realizar os testes quanto à correção funcional, operacional e de consistência. Eles olham para a codificação, o design e para os erros e lacunas, dependências operacionais, backdoors e vulnerabilidades de segurança. O que significa que os desenvolvedores devem ser treinados e orientados sobre como fazer revisões corretamente. As revisões em par também podem garantir que as mudanças não sejam feitas sem que pelo menos uma ou outra pessoa da equipe tenha total entendimento sobre o que está acontecendo.
2. A análise estática: ela é executada em todas as mudanças para encontrar bugs de segurança e outros problemas. Qualquer violação das regras de codificação irá quebrar o código.
3. Teste automatizado é feito com Integração/Distribuição Contínua: testes unitários, de integração e testes de segurança. O pacote de ferramentas de auditoria assume que os desenvolvedores seguem o TDD para garantir um elevado nível de cobertura do teste. O código deve passar em todos os testes.
4. Rastreabilidade: enviar todas as alterações de volta para o pedido original, usando um sistema de bilhetagem como o Jira (você não pode apenas usar cartões de indexação para descrever o trabalho e jogá-los fora quando tiver terminado).
5. Operações de checagem: após a implantação e inicialização, é necessário obter feedback do monitoramento de operações e, especialmente, a partir de falhas de produção. Métricas e postagem de resultados são usados ​​para conduzir melhorias de teste e instrumentação, bem como alterações mais profundas na definição de políticas, treinamento e contratação – como referência, veja a apresentação de João Allspaw, chamada Ops Meta-Metrics: The Currency you use to pay for Change, do Velocity 2010, e aprenda como isso isso pode ser feito.
6. Todas as mudanças ao código e definições de infraestrutura, incluindo correções de bugs e patches, são implementadas através do mesmo pipeline automatizado e auditável em Continuous Delivery.

Um ponto de partida

O pacote de ferramentas de auditoria DevOps fornece um ponto de partida, um exemplo para construir código. Você pode adicionar suas próprias regras, checagens, revisões, testes e retornos de feedback.

Isso também é um trabalho em progresso. Existem alguns problemas importantes ainda a serem trabalhados, vejamos a seguir.

Principais mudanças

O pacote de ferramentas de auditoria descreve como as mudanças padrão podem ser tratadas em relação à distribuição contínua: pequenas, mas bem definidas, com alterações de baixo impacto são efetivamente pré-aprovadas. Operações e gestão são notificadas assim que essas mudanças são implantadas (as modificações são registradas, as informações são exibidas em telas e também incluídas nos relatórios), mas não há comunicação honesta ou coordenação dessas alterações, porque isso não deveria ser necessário. Os desenvolvedores podem forçar alterações logo que elas estejam prontas, e estas são distribuídas imediatamente após todas as revisões e outras verificações passarem no teste.

Mas o pacote de ferramentas para auditoria é omisso sobre como gerenciar mudanças em maior escala, incluindo alterações nos dados e bases de dados, mudanças nas interfaces com outros sistemas, as alterações necessárias para cumprir as novas regras e regulamentos e os principais novos recursos do cliente e suas respectivas atualizações técnicas. As alterações que são mais difíceis de serem revertidas têm maior impacto e maior risco, e exigem muito mais coordenação, o que, naturalmente, é o que mais importa.

Você precisa de métodos claros e explícitos para operações e atendimento ao cliente para mudanças maiores, de modo que todas as partes interessadas compreendam as dependências e os riscos de impacto sobre como isso funciona, para que tudo possa ser planejado com antecedência. Isso ainda pode ser feito de uma forma DevOps, mas requer reuniões e planejamento, algum gerenciamento de projetos e muita papelada. Como exemplo, veja como o site Etsy gerencia lançamentos de recursos.

Também é preciso garantir que as políticas de definição de quais mudanças são pequenas e simples o suficiente sejam pré-aprovadas, e decidir quais alterações de código serão de alto risco e precisam de revisão adicional e quais são razoáveis ​​e inequivocamente consistentes. Você precisa fazer revisões frequentes para garantir que essas políticas serão rigorosamente seguidas e que as pessoas não as interpretem erroneamente ou tentem escapar delas com mudanças de maior risco, sem padronização ou supervisão gerencial ou do Conselho Consultivo de Mudanças (CAB CAB – Change Advisory Board – ITIL) e aprovação explícita de mudança.

Feito corretamente, isso significa que o peso total do controle de mudança só é exercido quando for necessário – para mudanças que tenham verdadeiro risco operacional ou de negócios. Então você quer encontrar formas de minimizar esses riscos, para quebrar mudanças em pedaços menores de forma a simplificar, agilizar e automatizar o máximo do trabalho necessário quanto possível, aproveitando a mesma infraestrutura de testes e entrega.

Testes de segurança

Há muita atenção voltada para os testes de segurança presentes no pacote de ferramentas para auditoria. Como as alterações são feitas de forma incremental e interativa, e são enviadas automaticamente, você precisará de ferramentas e testes que funcionem automaticamente, de forma incremental e interativa, o que não é, infelizmente, como a maioria das ferramentas de segurança funciona, nem como a maioria dos testes de segurança é feita hoje.

Não há muitas organizações que usam ferramentas como Gauntlt ou BDD-Security para escrever testes e verificações de segurança automatizadas de nível superior como parte da integração contínua ou da distribuição contínua. A maioria de nós depende de scanners e fuzzers dinâmicos e estáticos que podem levar horas para serem executados e exigem revisão manual e atenção em detrimento de testes manuais caros e demorados. Isso claramente não pode ser feito a cada check-in, mas à medida que mais equipes adotam Ágil e agora práticas DevOps, a maneira como o teste de segurança é feito também está mudando, a fim de se sustentar. Ferramentas de análise estática estão ficando mais rápidas, e muitas delas podem fornecer feedback diretamente para os desenvolvedores em seus IDEs, ou trabalhar contra conjuntos de mudanças incrementais predefinidos. Ferramentas e serviços de testes dinâmicos estão se tornando mais personalizáveis, mais escalonáveis e até mesmo mais simples de usar, com APIs abertas.

Ferramentas de teste de segurança interativos, como Contrast ou Quotium, podem encontrar erros de segurança em tempo de execução, se o sistema estiver sendo testado em integração/entrega contínua. E empresas como Signal Sciences estão trabalhando em novas maneiras de tornar a segurança ágil para sistemas online. Mas ainda há muita coisa que precisa ser feita.

Desenvolvedores precisam ter acesso à produção?

O pacote de ferramentas de auditoria assume que os desenvolvedores terão acesso de leitura para registros de produção, e também podem precisar de acesso direto à produção, a fim de ajudar na solução de problemas e suporte. Mesmo se você restringir o acesso dos desenvolvedores somente à leitura, isso levantará preocupações em torno da privacidade e confidencialidade dos dados.

E se o acesso à leitura não é suficiente? E se os desenvolvedores precisam fazer uma correção de código ou de configuração que não pode ser feita através da via automatizada, ou com dados de produção de reparação? Agora você terá problemas com a separação de funções e integridade dos dados.

O que os desenvolvedores devem ser capazes de fazer e o que eles devem ser capazes de ver? E como isso pode ser controlado e monitorado? Se você está permitindo desenvolvedores na produção, você precisa ter respostas sólidas para essas perguntas.

Implantação contínua ou distribuição contínua?

O pacote de ferramentas de auditoria traz o argumento de que, com controles apropriados no lugar, os desenvolvedores devem ser capazes de enviar mudanças diretamente para produção quando elas estiverem prontas – desde que essas alterações sejam de baixo risco e apenas se elas mudanças passarem por todas as revisões e ensaios no fluxo de trabalho automatizado.

Mas isso não é algo que você tem que fazer ou até mesmo pode fazer – não por causa de restrições de conformidade necessariamente, mas porque seu ambiente de negócios ou sua arquitetura não suporta fazer alterações desse tipo. Entrega contínua não tem de significar implantação contínua. Você ainda pode seguir a entrega contínua disciplinada através de pré-produção, com todas as revisões e as verificações no local, e, em seguida, juntar as alterações e liberá-las quando isso fizer sentido.

Vendendo (a ideia) para reguladores e auditores

Você terá de explicar e vender essa abordagem para os reguladores, auditores, advogados ou aspirantes a advogados. Convencê-los – e ajudá-los – a olhar para o código e registrar as alterações, em vez de apenas as políticas legais e as listas de verificação. Convencê-los de que é normal para os desenvolvedores realizar alterações de baixo risco e pré-aprovadas para produção, se você quiser ir mais longe.

Assim como a beleza está nos olhos de quem vê, a adesão a isso é uma opinião do auditor. Ele pode não concordar ou não entender o que você está fazendo. E mesmo que um auditor entenda, outro pode não entender. Esteja preparado para uma venda difícil, e para definir determinadas coisas.

Disciplinado, Ágil e Enxuto

O pacote de ferramentas de auditoria e defesa DevOps descreve uma abordagem disciplinada, mas Ágil/Enxuto para a gestão de software e mudanças de sistema em um ambiente altamente regulamentado.

Isso definitivamente não é fácil. Não é simples. E tem um monte de disciplina de engenharia envolvida. E mais um monte de investimento em automação e na supervisão gerencial para fazer tudo funcionar.

Mas ainda é Ágil. Suporta o ritmo rápido, interativo e incremental de trabalho das equipes de desenvolvimento que querem trabalhar. E Enxuto. Porque todo o trabalho estará claramente definido e automatizado sempre que possível. Você pode mapear as cadeias de valor e os fluxos de trabalho, medir atrasos e otimizar processos ou revisá-los e melhorá-los.

Em vez de políticas, procedimentos e listas de verificação detalhadas que ninguém pode ter certeza se todos estão realmente seguindo, é possível automatizar os processos de implantação que você executa o tempo todo, então saberá como eles estão e como funcionam. As políticas e as orientações são utilizadas para conduzir as decisões, o que significa que elas podem ser mais simples, mais claras e mais práticas. Procedimentos e listas de verificação são criadas em etapas e com controles automatizados.

Isso poderia funcionar. E deve funcionar. Vale a pena tentar fazer esse trabalho. Em vez de todo um teatro sobre conformidade, isso promete que mudanças nos sistemas podem tornar as coisas mais simples, mais previsíveis, mais eficientes e mais seguras. E isso é algo que vale a pena fazer.

***

Jim Bird faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://swreflections.blogspot.com.br/2015/04/towards-compliance-as-code.html