Criando um Framework para Habilitação de Serviços na AWS

Introdução

Durante a jornada de adoção da nuvem AWS muitos clientes se perguntam como ter agilidade mantendo os aspectos de governança, segurança e escalabilidade no ambiente. O desafio enfrentado é que enquanto desenvolvedores e áreas de negócio buscam inovação e novos serviços, times de plataforma e segurança se preocupam com padronização, gerenciamento de riscos, operação e conformidade.O cenário pode ser endereçado através da criação de um Framework de Habilitação de Serviços, onde cada serviço AWS é analisado seguindo um processo padronizado, identificando a necessidade de negócio, modelagem de ameaças (threat modeling), controles de segurança e monitoração. Como resultado, times de negócio ou desenvolvedores podem provisionar serviços AWS de maneira autossuficiente, mantendo conformidade da empresa na AWS, sem depender de times centralizados.Este blog post descreve um Framework dividido em 8 etapas que são aplicáveis a todos os clientes, independente do nível de maturidade em nuvem ou escala. Clientes podem utilizar o modelo como um guia para habilitação de serviços AWS de forma ágil e segura.

Framework de Habilitação de Serviços na AWS

O diagrama abaixo ilustra as 8 etapas envolvidas no Framework

1. Problema ou oportunidade de negócio:

Entenda o problema ou oportunidade de negócios que sua empresa deseja explorar, independentemente do contexto técnico do serviço AWS. Algumas perguntas podem ajudar no entendimento:

• Quem é o cliente que eu preciso atender? Quais informações e insights nós possuímos sobre ele?
• Qual o problema ou oportunidade a ser explorado? Quão baseado em dados nós estamos?
• Qual serviço AWS está sendo considerado para o problema/oportunidade? Existe outro serviço habilitado que cobre o mesmo escopo?
• Qual a importância de habilitar este serviço para a experiência do meu cliente? Quais benefícios relevantes ele terá?

A definição e contextualização das respostas servirá de base para habilitar o serviço, inclusive priorizando funcionalidades em detrimento de outras. Um serviço AWS pode conter diversos subserviços e funcionalidades, permitindo assertividade no escopo escolhido para a habilitação.

Essa etapa deve ser revisitada após a etapa 2. Aprofundando-se, a fim de verificar se o serviço AWS atende o problema ou oportunidade de negócios, assim prosseguindo (ou não) com os esforços de habilitação.

2. Aprofundando-se no Serviço AWS:

Habilitar e tornar-se o responsável pelo serviço AWS na empresa, significa conhecer de forma profunda o mesmo, incluindo suas características, configurações, integração com outros serviços, funcionalidades, chamadas de API, monitoramento (saúde e cotas do serviço) além das capacidades de segurança (criptografia, IAM, ABAC, logging, etc.).

• • Leia sobre o Produto. Serviços AWS possuem User Guide, Developer Guide e API References que podem ser utilizados para entendimento de detalhes. Cada serviço AWS possui capítulo de Segurança em seu User Guide;
  • Utilize a documentação do blog AWS, AWS Prescriptive Guidance, Workshops e Treinamentos para casos de uso prático;
  • Atualize o backlog e roadmap inserindo o serviço com o status de em Avaliação. Isso irá dar visibilidade sobre o processo de avaliação e habilitação, permitindo um ponto de contato com o responsável, evitando retrabalho e duplicação de esforços;
  • Execute POT (Proof of Technology) em ambiente de desenvolvimento, sendo responsável pelo serviço em processo de avaliação/habilitação obtenha conhecimento e experiência prática;
  • Revisite o problema ou oportunidade de negócios da etapa 1, validando se o mesmo pode ser atendido pelo escopo do serviço. Quaisquer informações adicionais de experiência, problemas e usabilidade podem ser utilizadas como insumos para a modelagem de ameaças;

3. Realize a Modelagem de Ameaças:

A modelagem de ameaças trata da identificação de possíveis riscos ou falta de controles de segurança necessários para a empresa, em particular, como o serviço em avaliação poderia ser explorado em um ataque cibernético, este processo que suporta e prioriza a mitigação dos riscos identificados. Analisamos como atores podem afetar a confidencialidade, integridade ou disponibilidade dos sistemas, seus possíveis caminhos e metodologias de ataque, finalmente, quantificamos o impacto potencial de cada ameaça se for bem-sucedida. Geralmente essa etapa é conduzida por um especialista de segurança, somada a um time multidisciplinar que irá compor os trabalhos, sob a coordenação do responsável pelo serviço.

A AWS oferece um Workshop detalhado sobre modelagem de ameaças intitulado Threat modeling the right way for builders, o qual sua equipe poderá se basear para montar o modelo. Nessa etapa do processo de habilitação foram extraídos os principais elementos desse workshop.

Questões chave para Threat Modeling segundo o Frame Shostack:

• Em que estamos trabalhando?
• O que pode dar errado?
• O que nós vamos fazer sobre isso?
• Fizemos um bom trabalho?

3.1 Em que estamos trabalhando?

O objetivo desta pergunta é ajudar a entender e concordar com o serviço que estamos habilitando e se os detalhes sobre sua utilização são relevantes para a segurança. Criar um modelo/diagrama é a maneira mais comum para responder a essa pergunta, pois ajuda a visualizar o que você está construindo.

Diagramas de Fluxo de Dados

O tipo mais comum de diagrama para modelagem de ameaças é um Diagrama de Fluxo de Dados, modelando um sistema como um conjunto de fluxos de dados entre os elementos do sistema, no nosso caso o serviço AWS que será habilitado:

Exemplo de Diagrama de Fluxo de Dados para o Amazon S3

Os diagramas de fluxo de dados não são iguais aos diagramas de arquitetura, embora compartilhem algumas das mesmas propriedades. Um diagrama de arquitetura geralmente é um bom ponto de partida para criar um diagrama de fluxo de dados porque geralmente contém elementos semelhantes.

Os diagramas de fluxo de dados podem ser usados para modelar diferentes tipos de sistemas. Eles nos permitem identificar os ativos (coisas de valor) que podem existir dentro do sistema e onde estão armazenados (persistências). Podemos usá-los para entender como os dados fluem por exemplo, do serviço AWS para a Internet ou para a VPC Interna, como e onde as coisas podem dar errado com o armazenamento, manipulação ou fluxo desses dados.

Zona de Confiabilidade (Trust boundaries)

Dentro de um sistema ou serviço, diferentes zonas (camadas) podem apresentar níveis distintos de confiabilidade. Dentro de uma zona de confiança, consideramos todos os elementos igualmente confiáveis. Consideramos cada zona identificada como confiável de forma diferente, o que não implica necessariamente mais ou menos confiança.

Os fluxos de dados que ultrapassam os limites de confiança tendem a ser onde as coisas podem dar errado, portanto, eles devem ser examinados de perto quanto a ameaças. Geralmente, aplica-se controles de segurança (mitigações) em limites de confiança para manter as propriedades de segurança de um sistema.

Considere por exemplo um nível de confiança como sendo o tráfego na mesma conta da AWS da sua organização, outro nível para o acesso cross-account, um terceiro para serviços que acessa a Internet, entre outras zonas de confiabilidade que os participantes da habilitação possam considerar.

Para o Diagrama de Fluxo de Dados e definição de Zona de Confiança considere no mínimo a análise dos itens abaixo no serviço:

• Identity-Based Policies (adicionalmente Trusted Entities)
• Resource-Based Policies
• Network-Based Policies (VPCs and Transit)
• Internal Permission (ACL, LocalDatabase, etc.)
• Identity Federation
• Data Perimeter (Perímetro de Dados)
• Internet Traffic (Egress and Ingress Traffic)

3.2 O que pode dar errado?

Ameaças são ações ou eventos acidentais ou intencionais que têm impactos indesejados e podem afetar a segurança da sua empresa. Sem uma compreensão clara do que pode dar errado, não temos como definir as mitigações necessárias. Existem muitas técnicas para identificar ameaças. Recomendamos o “STRIDE-per-Element” sendo simples e útil quando aplicado à maioria dos sistemas. O Responsável pelo Serviço e time multidisciplinar formado para a habilitação são incentivados também a explorar outros métodos, assim como adaptar aqueles já utilizados pela empresa.

STRIDE é um acrônimo que compreende seis categorias de ameaças e agrupa ameaças semelhantes pela propriedade de segurança que elas violam.

3.3 O que nós vamos fazer sobre isso?

Uma vez que sabemos o que pode dar errado, existem quatro estratégias para fazer algo a respeito:

• Mitigar o risco
• Evitar o risco
• Transferir o risco
• Aceitar o risco

No contexto de habilitação do serviço a decisão mais comum é a mitigação, mas dependendo do risco pode ser decidido por evitar. Nesse caso o serviço fica como não-habilitado possuindo todo o registro que embasou a decisão.

Ao final do processo a tabela de Modelagem de Ameaças irá conter as informações sobre ameaças, mitigação, prioridade, entre outros.

Modelagem de Ameaças (template de exemplo)

3.4 Fizemos um bom trabalho?

Temos como objetivo impulsionar melhorias no processo, cobrindo de forma apropriada as ameaças e a abordagem de riscos, caminhando na habilitação do serviço de forma sistemática, fundamentada e padronizada. Onde o serviço possa atender a demanda de inovação da sua empresa de forma segura e escalável.

• Identifique oportunidades para expandir o escopo da modelagem de ameaças. Por exemplo, ajude outro Responsável de Serviço a começar ou a melhorar seu modelo de ameaça.
• Explore outras técnicas para modelagem de sistema, como diagramas de sequência ou diagramas de transição de estado.
• Expanda a modelagem de ameaças além do seu serviço, permitindo contribuir ativamente para a postura de segurança da empresa.
• Considere a modelagem de ameaças, como um processo de negócios vital para as áreas de segurança, gerenciamento de riscos, governança, privacidade, auditoria e conformidade.

4. Defina a Utilização do Serviço:

Baseado na necessidade de negócios, funcionamento do serviço e modelagem de ameaças quem poderá utilizar o serviço?  Defina se serviço será habilitado ou não na organização, considerando ainda o seu público-alvo e modelo de consumo.

Dependendo do tipo de serviço pode ser definido que todos os usuários da empresa (AWS Accounts) podem fazer o deploy e uso do serviço, para outros casos somente o time do responsável pelo serviço poderá fazer a utilização, devido a restrições de segurança as quais só podem ser aplicadas em um modelo centralizado. Exemplos:

Amazon S3 – Todos os usuários podem fazer o deploy de buckets e utilizar o serviço.

AWS Private Certificate Authority – Somente a Squad de Segurança pode fazer o deploy do serviço (Autoridade Certificadora), os usuários geram certificados através API governada.

5. Escreva o Baseline de Segurança: O Baseline de Segurança (Security Baseline) irá refletir todos os controles administrativos e técnicos que deverão ser adotados pelos clientes, servindo de referência para utilização do serviço.

Certifique-se de refletir todas as mitigações selecionadas na modelagem de ameaças como parte da composição do baseline de segurança. A política de segurança e regulamentações do setor da sua empresa também irão influenciar e definir essa composição, incluindo itens como logging, criptografia, autenticação, permissionamento, monitoração, etc.

Os guardrails deverão ser definidos na etapa 7, assim como IaC (Infrastructure-as-Code) da etapa 8 que irão se utilizar dessas definições para garantia de conformidade e entrega padronizada no ambiente.

Um guardrail é uma regra de alto nível que fornece governança contínua para seu ambiente AWS. Existem três tipos de guardrails: preventivo, detectivo e proativo.

Baseline de Segurança para o Amazon S3 (exemplo)

6. Estabeleça Monitoramento e Métricas:

As cargas de trabalho da sua empresa podem ter diferentes características de monitoramento e performance, assim como questões de observabilidade. Todavia, durante a habilitação do serviço podem ser definidas métricas e alarmes de utilização, visando principalmente a disponibilidade da aplicação quanto ao atingimento das cotas do serviço (service quotas).

SLA/Availability

Por exemplo, considerando a cota padrão do serviço AWS Lambda temos 1000 execuções simultâneas de funções Lambda, você pode criar um alarme com base no Amazon CloudWatch para alertar quando 800 execuções simultâneas forem atingidas, permitindo proativamente solicitar o incremento do valor. Essa abordagem garante a escalabilidade e disponibilidade da sua aplicação

O monitoramento dos logs de aplicações também pode ser definido com templates, a partir do CloudWatch Logs você pode monitorar a saúde e acesso ao serviço, por exemplo, erros HTTP 4xx no log de acesso de um servidor web em um intervalo de tempo.

Na definição do monitoramento considere a habilitação de funcionalidades nativas da AWS que podem trazer valiosos insights com baixo ou nenhum overhead operacional, por exemplo, RDS Performance Insights, CloudWatch Container Insights, CloudTrail Insights, AWS X-Ray, Cost Anomaly Detection, AWS Trusted Advisor verificação completa (Business e Enterprise Suporte), entre outros.

7. Construa os Guardrails:

Os riscos a serem mitigados estabelecidos no baseline de segurança devem ser traduzidos em sua maioria em guardrails técnicos (controles de segurança), garantindo que a utilização do serviço esteja de acordo com a política da organização.

A construção dos guardrails muitas vezes se dá em paralelo com a própria escrita do baseline de segurança, uma vez que as respostas como remediação ou notificação fazem parte do documento.

Considerando a natureza do serviço, diferentes guardrails podem ser implementados por uma ou mais ferramentas:

• AWS Config – Permite codificar os requisitos de conformidade como regras do AWS Config, automatizando a avaliação de configurações de recursos com alertas e remediação automatizada para os recursos suportados.
• SCP (Service Control Policy) – Serviço AWS integrado ao AWS Organizations que permite a aplicação de políticas preventivas para restrição de chamadas de API, gerenciando permissões e controles centralizados em todas as contas da organização. Veja exemplos.
• Event-Driven Guardrail – Utilização do Amazon EventBridge e Função AWS Lambda para avaliação e remediação, considerando a detecção de chamada de API do serviço ou AWS CloudTrail – Veja exemplo.
• Policy-as-Code – Validação de política como código (policy-as-code) para de forma programática detectar problemas de segurança nos estágios iniciais de desenvolvimento e deployment. Exemplos de ferramentas que se enquadram nessa categoria AWS CloudFormation Guard, OPA (Open Policy Agent), Checkov e Terraform Compliance.

Lembre-se que os guardrails tem como objetivo manter a configuração no estado desejado (Baseline de Segurança), conhecer a fundo as chamadas de API, autorização de acessos e as capacidades de segurança de um serviço é essencial para que o mesmo seja habilitado com sucesso.

Seja cauteloso(a) na habilitação dos guardrails para evitar impactos indesejados aos workloads da organização. Realize testes em ambiente controlado, solicitando a avaliação e validação das suas propostas para áreas outras áreas como Fundação, Segurança, DevOps, CCOE.

8. Considere IaC e Self-Service:

É recomendado que o serviço habilitado possua templates de Infraestrutura como Código (IaC) em repositório corporativo, permitindo o provisionamento e gerenciamento utilizando técnicas de desenvolvimento de software como controle de versão e integração contínua. Times de plataforma podem criar templates reutilizáveis que atuam como porções de código que padronizam implementações.

Todos os controles definidos no baseline de segurança e requerimentos de monitoramento e métricas devem estar refletidos como IaC, fazendo parte de uma stack completa – padronizada segundo as definições da sua empresa.

Práticas como Inner Source podem aumentar a agilidade, absorver novas funcionalidades assim como corrigindo bugs no template do serviço,  permitindo colaboração entre clientes e times internos.

Serviços da AWS como  AWS Service Catalog e AWS Proton  podem ser utilizados para publicação de padrões, consumidos pelos times de desenvolvimento, focando em agilidade e abstração de toda a complexidade do deployment do serviço. Essa abordagem também garante a confiabilidade, padronização e escalabilidade.

Backlog e Roadmap de Habilitação

O processo de habilitação de serviços AWS pode ser gerido por múltiplos times dentro de uma organização, dessa forma dar visibilidade aos serviços habilitados (autorizados ao uso), não habilitados ou mesmo em backlog para ser analisado segundo o framework deverá ser estabelecido como um primeiro passo. Exemplo:

1. O time responsável pelo serviço atualiza o backlog e roadmap com informações iniciais.
2. O processo de habilitação de serviço é executado em sua completude geralmente com coordenação do responsável pelo serviço (Service Owner), adicionalmente com apoio de outros times como fundação, segurança, engenharia, DevOps, CCOE, etc.
3. Através de colaboração e ferramentas (Inner Source), associado as melhores práticas (Well-Architected Framework) os serviços são habilitados e revisados em ciclos.

Conclusão

Atualmente, a pergunta não é mais se a sua organização está migrando para a nuvem, mas com que rapidez e agilidade é possível migrar com segurança, visibilidade e controle.  A criação de times de plataforma que habilitam serviços na AWS é crucial para atingir esse objetivo, sendo a adoção de um framework na organização parte fundamental da jornada.

A visibilidade de um backlog e roadmap de habilitação centralizado irá permitir comunicação unificada, onde produtos possam ser priorizados de acordo com a necessidade da organização. A modelagem de ameaças, baseline de segurança e guardrails construídos irão gerir e mitigar os riscos na utilização do serviço alinhado as necessidades do negócio.

O monitoramento irá colaborar em aspectos como disponibilidade e observabilidade, enquanto IaC e auto-serviço irão trazer agilidade, padronização e escalabilidade – elevando a excelência operacional.

Por fim, o estabelecimento de um processo de habilitação de serviços na AWS através de um framework colaborativo irá permitir a sua organização atingir agilidade e inovação, enquanto observa importantes requisitos como governança, segurança e escalabilidade no ambiente.

Sobre os autores

Diogo Guedes atua como Sr. Security Consultant no time AWS ProServe LATAM focado em clientes estratégicos. Ele possui mais de 17 anos de experiência em segurança da informação e governança, liderando iniciativas para o setor financeiro e governo, ajudando clientes a melhorarem sua postura de segurança com agilidade e inovação em mente. Além da sua paixão por tecnologia, gosta de anime e passar tempo em família.

Guilherme Greco é Arquiteto de Soluções na AWS, focado no segmento financeiro. Com 19 anos de experiência em infraestrutura e arquitetura, Guilherme auxilia os clientes da AWS desde 2018 a terem sucesso em suas jornadas para nuvem, desde a etapa de criação de uma fundação sólida até migrações de soluções corporativas.

Joao Melo é Arquiteto de Soluções atendendo clientes Enterprise com foco em mercado financeiro. Com mais de 10 anos de experiência, João iniciou sua carreira como desenvolvedor Java e .NET, e posteriormente se especializou em infraestrutura como Engenheiro de Sistemas na Cisco Systems. Formado pela FEI, é entusiasta de Containers, DeFi, Sistemas de Pagamento e apaixonado por cinema e jogos.

Leonardo Roque é Arquiteto de Soluções na AWS atendendo clientes Enterprise com foco em mercado financeiro. Com mais de 12 anos de experiência atuando com desenvolvimento e arquitetura, Leonardo é entusiasta de Containers, Severless, DevOps e apaixonado por esportes.