Abordagens Centralizadas e Descentralizadas na Gestão de Segredos em Nuvem

Escolhendo a Estratégia Certa para Gerenciar Segredos

Uma das perguntas mais comuns entre organizações que trabalham com a AWS diz respeito à centralização de segredos. Embora o debate frequentemente se concentre apenas no armazenamento centralizado, existem quatro dimensões importantes a considerar: criação, armazenamento, rotação e monitoramento de segredos. Cada uma dessas dimensões pode ser tratada de forma centralizada ou descentralizada, e a escolha tem implicações diretas na segurança, operação e escalabilidade da infraestrutura.

Não existe uma solução única que funcione para todas as organizações. A melhor estratégia depende da estrutura operacional, requisitos de segurança e capacidades técnicas de cada empresa. Neste artigo, exploramos os benefícios e desvantagens de cada abordagem.

Criação Centralizada de Segredos

Quando uma organização opta pela criação centralizada de segredos, o foco geralmente está em implementar práticas modernas de DevOps que automatizam e padronizam a implantação. Muitas empresas têm investido em plataformas internas de desenvolvedor, que utilizam o conceito de “caminhos de ouro” (golden paths) para permitir que desenvolvedores façam implantação em modelo de autoatendimento através de infraestrutura como código (IaC).

Essas plataformas oferecem templates pré-aprovados que implementam as melhores práticas da organização. Uma equipe de engenharia de plataforma central mantém esses caminhos, garantindo conformidade com padrões corporativos. Ferramentas como o AWS Service Catalog e projetos de código aberto como Backstage.io são exemplos de tecnologias que facilitam essa abordagem.

Um exemplo prático seria um caminho de ouro que padroniza a implantação de um microsserviço que acessa um banco de dados. Esse caminho poderia determinar que o serviço deve ser construído com o AWS Cloud Development Kit (AWS CDK), executado no Amazon Elastic Container Service (Amazon ECS), e que as credenciais de banco de dados sejam obtidas através do AWS Secrets Manager. A equipe de plataforma também pode incluir verificações automatizadas para garantir que a política de recurso do segredo apenas permite acesso ao papel (role) correto e que a criptografia utiliza chaves gerenciadas pelo cliente.

Vantagens da Criação Centralizada

Nomenclatura e controle de acesso consistentes: Segredos criados centralmente podem seguir convenções de nomenclatura padronizadas baseadas em conta, workload, serviço ou classificação de dados. Isso facilita a implementação de padrões escaláveis como controle de acesso baseado em atributos (ABAC).
Verificações de privilégio mínimo em pipelines CI/CD: A criação de segredos dentro de pipelines IaC permite o uso de ferramentas como a AWS IAM Access Analyzer com a API check-no-new-access. Os pipelines podem ser templizados, permitindo que equipes individuais se beneficiem dos padrões organizacionais.
Colaboração entre engenharia de plataforma e segurança: Essa transição permite que equipes de segurança trabalhem em conjunto com engenharia de plataforma para incorporar segurança por padrão nos caminhos de ouro, em vez de implementá-la posteriormente.

Desvantagens da Criação Centralizada

Requer investimento significativo em tempo e recursos para construir e manter plataformas de desenvolvedor dedicadas.
É necessário manter bibliotecas de caminhos de ouro apropriados para os casos de uso da organização, o que pode ser inviável dependendo do tamanho.
Os caminhos de ouro precisam acompanhar novas features dos serviços subjacentes. Se um serviço recebe uma atualização importante, os desenvolvedores precisam esperar pela inclusão dessa feature nos templates existentes.

Criação Descentralizada de Segredos

Em um modelo descentralizado, as equipes de aplicação são donas dos templates IaC e mecanismos de implantação em suas próprias contas. Cada equipe opera de forma independente, o que pode dificultar a aplicação de padrões padronizados como código.

Vantagens da Criação Descentralizada

Velocidade: Desenvolvedores conseguem se mover rapidamente com maior autonomia, já que não dependem de uma função central para criar novos segredos.
Flexibilidade: As equipes ainda podem utilizar recursos como a API check-no-new-access, mas fica a critério delas implementar essas verificações em seus pipelines.

Desvantagens da Criação Descentralizada

Falta de padronização: Sem mecanismos centrais de criação templizada, fica mais difícil aplicar convenções consistentes de nomenclatura e tagging.
Inconsistência em controles de acesso: Políticas de recurso e controles de acesso podem variar significativamente entre equipes.
Maior carga nos desenvolvedores: Equipes precisam gerenciar uma maior parte da infraestrutura e dos pipelines de implantação por conta própria.

Armazenamento Centralizado de Segredos

Algumas organizações optam por manter todos os segredos em uma conta central, enquanto outras preferem armazenar segredos nas mesmas contas onde os workloads operam. A escolha dessa estratégia depende dos tradeoffs operacionais e de segurança envolvidos.

Vantagens do Armazenamento Centralizado

Monitoramento e observabilidade simplificados: Manter todos os segredos em uma única conta facilita o monitoramento centralizado, com uma equipe dedicada controlando o acesso a esses recursos sensíveis.

Desvantagens do Armazenamento Centralizado

Overhead operacional adicional: Ao compartilhar segredos entre contas, é necessário configurar políticas de recurso em cada segredo que será compartilhado.
Custo adicional do AWS KMS: Para compartilhar segredos entre contas, é obrigatório usar chaves gerenciadas pelo cliente do AWS Key Management Service (AWS KMS). Embora isso forneça um nível adicional de controle de acesso, isso aumentará os custos segundo a precificação do AWS KMS, além de exigir políticas adicionais de manutenção.
Concentração elevada de dados sensíveis: Centralizar segredos aumenta o potencial de impacto em caso de acesso indevido ou erro de configuração.
Limites de quota: Antes de optar por centralizar segredos, é importante revisar as quotas de serviço da AWS para garantir que a organização não atingirá limites em produção.
Segredos gerenciados por serviços: Serviços como o Amazon Relational Database Service (Amazon RDS) e Amazon Redshift gerenciam segredos automaticamente, armazenando-os na mesma conta do recurso. Para manter uma estratégia centralizada usando esses segredos gerenciados, seria necessário centralizar também os recursos.

Muitas organizações já utilizam serviços nativos da AWS como AWS Security Hub, IAM Access Analyzer, AWS Config e Amazon CloudWatch para obter observabilidade centralizada em ambientes multi-conta, sem necessidade de manter todos os segredos em um único local.

Armazenamento Descentralizado de Segredos

Na abordagem descentralizada, os segredos vivem nas mesmas contas que os workloads que precisam acessá-los, criando uma separação natural entre diferentes aplicações e equipes.

Vantagens do Armazenamento Descentralizado

Limites de conta como segmentação natural: As contas AWS fornecem isolamento por padrão. Acessar segredos de outra conta não é possível automaticamente, exigindo aprovação explícita tanto da política de recurso na conta de origem quanto da política IAM na conta de destino. Políticas de controle de recurso podem impedir completamente o compartilhamento de segredos entre contas.
Flexibilidade na escolha de chaves KMS: Se segredos não são compartilhados entre contas, as organizações podem optar entre usar chaves gerenciadas pelo cliente ou chaves gerenciadas pela AWS para criptografia.
Delegação de gerenciamento de permissões: Quando segredos estão na mesma conta das aplicações que os consomem, os donos das aplicações podem definir permissões granulares nas políticas de recurso dos segredos.

Desvantagens do Armazenamento Descentralizado

Auditoria e monitoramento complexos: Ferramentas de monitoramento precisam operar entre múltiplas contas para apresentar uma visão consolidada de conformidade.
Workflows de remediação automática mais complexos: Controles de detecção podem alertar sobre misconfigurations ou riscos relacionados a segredos, como quando um segredo é compartilhado fora dos limites organizacionais. Esses workflows são mais complexos em ambientes multi-conta, embora a AWS ofereça soluções como Automated Security Response on AWS.

Rotação Centralizada de Segredos

Quando a rotação é centralizada, uma equipe central gerencia e mantém as funções do AWS Lambda responsáveis pela rotação de segredos, oferecendo bibliotecas reutilizáveis para diferentes cenários.

Vantagens da Rotação Centralizada

Reutilização de funções de rotação: Equipes de aplicação podem reutilizar funções comuns desenvolvidas pela equipe central para diferentes tipos de banco de dados e aplicações SaaS, sem precisar desenvolver suas próprias soluções customizadas.
Logs gerenciados centralmente: Os logs das funções de rotação podem ser armazenados e acessados a partir de um local único, facilitando investigações e auditorias.

Desvantagens da Rotação Centralizada

Cenários adicionais de acesso entre contas: Funções Lambda na conta central precisam de permissões para criar, atualizar, deletar e ler segredos nas contas das aplicações, aumentando o overhead operacional.
Limites de quota: Ao centralizar essa função em escala, é importante verificar as quotas de serviço do Lambda para evitar gargalos em produção.

Rotação Descentralizada de Segredos

A rotação descentralizada é a abordagem mais comum, onde as funções de rotação vivem na mesma conta que o segredo que gerenciam.

Vantagens da Rotação Descentralizada

Templização com customização: Desenvolvedores podem reutilizar templates de rotação, mas adaptá-los conforme necessário para seus casos de uso específicos.
Sem acesso entre contas: A rotação acontece integralmente dentro de uma única conta, eliminando complexidades de acesso cross-account.

Desvantagens da Rotação Descentralizada

Acesso centralizado aos logs: É necessário fornecer acesso centralizado ou federado aos logs das funções de rotação distribuídas em diferentes contas. Por padrão, Lambda envia automaticamente logs para CloudWatch Logs, que oferece diferentes formas de centralizar logs, cada uma com seus tradeoffs específicos.

Auditoria e Monitoramento Centralizados

Independentemente do modelo escolhido para criação, armazenamento e rotação, é altamente recomendado centralizar auditoria e monitoramento em ambientes multi-conta. A AWS oferece capacidades robustas para isso através da AWS Security Hub, que se integra com AWS Organizations para centralizar:

Descobertas das melhores práticas de segurança fundamentais relacionadas ao Secrets Manager
Descobertas do IAM Access Analyzer sobre acesso externo aos secrets
Descobertas do AWS Config sobre configurações de Secrets Manager
Descobertas de comportamento anômalo do Amazon GuardDuty

Nesse modelo, funções centralizadas ganham visibilidade organizacional, enquanto equipes individuais conseguem visualizar sua própria postura em nível de conta sem precisar ver a organização inteira. Além disso, usar trilhas organizacionais do AWS CloudTrail permite enviar todas as chamadas de API do Secrets Manager para uma conta de administração delegada centralizada.

Auditoria e Monitoramento Descentralizados

Para organizações que não requerem auditoria centralizada, é possível configurar o acesso de forma que equipes individuais determinem quais logs coletar, alertas configurar e verificações implementar relacionadas aos seus segredos.

Vantagens da Abordagem Descentralizada

Flexibilidade: Equipes de desenvolvimento têm liberdade para escolher ferramentas de monitoramento, auditoria e logging que melhor se ajustem às suas necessidades.
Menos dependências: Equipes não precisam depender de funções centralizadas para implementar alertas e monitoramento.

Desvantagens da Abordagem Descentralizada

Overhead operacional: Diferentes equipes podem acabar implementando soluções similares de forma redundante.
Dificuldade em investigações multi-conta: Quando logs e monitoramento estão descentralizados, investigações que afetam múltiplas contas se tornam mais complexas.

Combinando Abordagens: O Caso do Serviço Financeiro

A maioria das organizações, na prática, escolhe uma combinação dessas abordagens para atender suas necessidades específicas. Um exemplo seria uma empresa de serviços financeiros com uma equipe central de segurança operando centenas de contas AWS, com centenas de aplicações isoladas em nível de conta:

Centraliza a criação de segredos, aplicando padrões corporativos de nomenclatura, tagging e controle de acesso
Descentraliza o armazenamento, usando contas AWS como limite natural de acesso e delegando controle aos donos das aplicações
Descentraliza o gerenciamento de ciclo de vida, permitindo que donos das aplicações gerenciem suas próprias funções de rotação
Centraliza a auditoria, utilizando AWS Config, Security Hub e IAM Access Analyzer para dar visibilidade à equipe central de segurança enquanto mantém controle descentralizado

Conclusão

Não existe uma estratégia única de gestão de segredos que funcione para todas as organizações. A arquitetura ideal depende dos requisitos específicos de segurança, modelo operacional e capacidades técnicas de cada empresa.

Os pontos principais a considerar são:

Escolha sua arquitetura baseado nos requisitos específicos de sua organização
Use automação e infraestrutura como código para reforçar controles de segurança, independentemente da abordagem escolhida
Implemente capacidades robustas de monitoramento e auditoria através dos serviços AWS para manter visibilidade em seu ambiente

Para aprofundar seus conhecimentos sobre o AWS Secrets Manager, considere explorar os recursos adicionais disponibilizados pela AWS, incluindo guias de migração, melhores práticas e templates de referência que facilitam a implementação de soluções seguras e bem-estruturadas.

Fonte

Exploring common centralized and decentralized approaches to secrets management (https://aws.amazon.com/blogs/security/exploring-common-centralized-and-decentralized-approaches-to-secrets-management/)