Compartilhar via

Estratégias de arquitetura para proteger segredos do aplicativo

Aplica-se a esta recomendação de lista de verificação do Azure Well-Architected Framework Security:

SE:09 Proteja os segredos do aplicativo endurecendo o armazenamento e restringindo o acesso e a manipulação e auditando essas ações. Execute um processo de rotação confiável e regular que pode improvisar rotações para emergências.

Este guia descreve as recomendações para proteger informações confidenciais em aplicativos. O gerenciamento adequado de segredos é crucial para manter a segurança e a integridade do aplicativo, da carga de trabalho e dos dados associados. O tratamento inadequado de segredos pode levar a violações de dados, interrupções de serviço, violações regulatórias e outros problemas.

Credenciais, como chaves de API, tokens OAuth (Autorização Aberta) e chaves SSH (Secure Shell) são segredos. Algumas credenciais, como tokens OAuth do lado do cliente, podem ser criadas dinamicamente em runtime. Segredos dinâmicos ainda precisam ser protegidos apesar de sua natureza temporária. Informações não essenciais, como certificados e chaves de assinatura digital, também podem ser confidenciais. Os requisitos de conformidade podem fazer com que as configurações que normalmente não são consideradas secretas sejam tratadas como segredos do aplicativo.

Definições 

Prazo Definição
Certificados Arquivos digitais que contêm as chaves públicas para criptografia ou descriptografia.
Credentials Informações usadas para verificar a identidade do fornecedor ou consumidor em um canal de comunicação.
Exame de credenciais O processo de validação do código-fonte para garantir que os segredos não estejam incluídos.
Encryption O processo pelo qual os dados se tornaram ilegíveis e bloqueados com um código secreto.
Key Um código secreto usado para bloquear ou desbloquear dados criptografados.
Acesso com privilégios mínimos Um princípio de Confiança Zero que visa minimizar um conjunto de permissões para concluir uma função de trabalho.
Identidade gerenciada Uma identidade atribuída aos recursos e gerenciada pelo Azure.
Não seguro Informações que não colocam em risco a postura de segurança da carga de trabalho se ela for vazada.
Rotation O processo de atualização regular de segredos para que, se eles estiverem comprometidos, eles estejam disponíveis apenas por um tempo limitado.
Secret Um componente confidencial do sistema que facilita a comunicação entre componentes de carga de trabalho. Se vazado, os segredos podem causar uma violação.
X.509 Um padrão que define o formato de certificados de chave pública.

Importante

Não trate não-secretários como segredos. Os segredos exigem rigor operacional desnecessário para não-secretários e isso pode resultar em custos extras.

As configurações de aplicativo, como URLs para APIs que o aplicativo usa, são um exemplo de não-secretários. Essas informações não devem ser armazenadas com o código do aplicativo ou os segredos do aplicativo. Considere usar um sistema de gerenciamento de configuração dedicado, como a Configuração de Aplicativos do Azure, para gerenciar essas configurações. Para obter mais informações, consulte o que é a Configuração de Aplicativos do Azure?.

Sua estratégia de gerenciamento de segredos deve minimizar os segredos o máximo possível e integrá-los ao ambiente aproveitando os recursos da plataforma. Por exemplo, se você usar uma identidade gerenciada para seu aplicativo, as informações de acesso não serão inseridas em cadeias de conexão e é seguro armazenar as informações em um arquivo de configuração. Considere as seguintes áreas de preocupação antes de armazenar e gerenciar segredos:

  • Os segredos criados devem ser mantidos no armazenamento seguro com controles de acesso estritos.

  • A rotação de segredo é uma operação proativa, enquanto a revogação é reativa.

  • Somente identidades confiáveis devem ter acesso a segredos.

  • Você deve manter uma trilha de auditoria para inspecionar e validar o acesso a segredos.

Crie uma estratégia em torno desses pontos para ajudar a prevenir o roubo de identidade, evitar repúdio e minimizar a exposição desnecessária às informações.

Gerenciar segredos da carga de trabalho

Se possível, evite criar segredos. Encontre maneiras de delegar a responsabilidade para a plataforma. Por exemplo, use as identidades gerenciadas internas da plataforma para lidar com credenciais. Menos segredos resultam em área de superfície reduzida e menos tempo gasto no gerenciamento de segredos.

Recomendamos que as chaves tenham três funções distintas: usuário, administrador e auditor. A distinção de função ajuda a garantir que apenas identidades confiáveis tenham acesso a segredos com o nível de permissão apropriado. Eduque desenvolvedores, administradores e outras pessoas relevantes sobre a importância das práticas recomendadas de gerenciamento de segredos e segurança.

Chaves pré-compartilhadas

Você pode controlar o acesso criando chaves distintas para cada consumidor. Por exemplo, um cliente se comunica com uma API de terceiros usando uma chave pré-compartilhada. Se outro cliente precisar acessar a mesma API, ele deverá usar outra chave. Não compartilhe chaves mesmo que dois consumidores tenham os mesmos padrões de acesso ou funções. Os escopos do consumidor podem mudar ao longo do tempo e você não pode atualizar permissões independentemente ou distinguir padrões de uso depois que uma chave é compartilhada. O acesso distinto também facilita a revogação. Se a chave de um consumidor estiver comprometida, será mais fácil revogar ou girar essa chave sem afetar outros consumidores.

Essa orientação se aplica a ambientes diferentes. A mesma chave não deve ser usada para ambientes de pré-produção e produção. Se você for responsável por criar chaves pré-compartilhadas, crie várias chaves para dar suporte a vários clientes.

Para obter mais informações, consulte Recomendações parade gerenciamento de identidade e acesso.

Armazenamento secreto

Use um sistema de gerenciamento de segredos, como o Azure Key Vault, para armazenar segredos em um ambiente protegido, criptografar em repouso e em trânsito e auditar o acesso e as alterações em segredos. Se você precisar armazenar segredos do aplicativo, mantenha-os fora do código-fonte para facilitar a rotação.

Os certificados só devem ser armazenados no Key Vault ou no repositório de certificados do sistema operacional. Por exemplo, não é recomendável armazenar um certificado X.509 em um arquivo PFX ou em um disco. Se você precisar de um nível mais alto de segurança, escolha sistemas que tenham recursos de HSM (módulo de segurança de hardware) em vez de repositórios secretos baseados em software.

Compensação: as soluções de HSM são oferecidas a um custo mais alto. Você também pode ver um efeito no desempenho do aplicativo devido a camadas de segurança adicionadas.

Um sistema de gerenciamento de segredos dedicado facilita o armazenamento, a distribuição e o controle do acesso aos segredos do aplicativo. Somente identidades e serviços autorizados devem ter acesso a repositórios secretos. O acesso ao sistema pode ser restrito por meio de permissões. Sempre aplique a abordagem de privilégio mínimo ao atribuir permissões.

Você também precisa controlar o acesso no nível do segredo. Cada segredo só deve ter acesso a um único escopo de recurso. Crie limites de isolamento para que um componente só possa usar segredos necessários. Se um componente isolado estiver comprometido, ele não poderá obter o controle de outros segredos e, potencialmente, de toda a carga de trabalho. Uma maneira de isolar segredos é usar vários cofres de chaves. Não há custos adicionais para a criação de cofres de chaves extras.

Implemente a auditoria e o monitoramento para acesso secreto. Registre quem acessa segredos e quando identificar atividades não autorizadas ou suspeitas. Para obter informações sobre o registro em log de uma perspectiva de segurança, consulte Recomendações sobre monitoramento de segurança e detecção de ameaças.

Rotação de segredo

Tenha um processo em vigor que mantenha a higiene secreta. A longevidade de um segredo influencia a gestão desse segredo. Para reduzir os vetores de ataque, os segredos devem ser desativados e substituídos por novos segredos com a maior frequência possível.

Lide com os tokens de acesso OAuth com cuidado, levando em consideração seu tempo de vida útil. Considere se a janela de exposição precisa ser ajustada para um período mais curto. Os tokens de atualização devem ser armazenados com segurança com exposição limitada ao aplicativo. Certificados renovados também devem usar uma nova chave. Para obter informações sobre tokens de atualização, consulte Secure OAuth 2.0 On-Behalf-Of tokens de atualização.

Substitua os segredos depois que eles atingirem o fim da vida útil, não forem mais usados pela carga de trabalho ou se eles tiverem sido comprometidos. Por outro lado, não desative segredos ativos a menos que seja uma emergência. Você pode determinar o status de um segredo exibindo logs de acesso. Os processos de rotação de segredo não devem afetar a confiabilidade ou o desempenho da carga de trabalho. Use estratégias que criam redundância em segredos, consumidores e métodos de acesso para rotação suave.

Para obter mais informações sobre como o Armazenamento do Azure lida com a rotação, consulte Gerenciar chaves de acesso da conta.

Os processos de rotação devem ser automatizados e implantados sem nenhuma interação humana. Armazenar segredos em um repositório de gerenciamento de segredos que dá suporte nativo a conceitos de rotação pode simplificar essa tarefa operacional.

Usar segredos de carga de trabalho com segurança

Como um gerador ou operador secreto, você deve ser capaz de distribuir segredos de maneira segura. Muitas organizações usam ferramentas para compartilhar segredos com segurança dentro da organização e externamente para parceiros. Na ausência de uma ferramenta, tenha um processo para entregar corretamente as credenciais aos destinatários autorizados. Seus planos de recuperação de desastre devem incluir procedimentos secretos de recuperação. Tenha um processo para situações em que uma chave seja comprometida ou vazada e precise ser regenerada sob demanda. Considere as seguintes práticas recomendadas de segurança ao usar segredos:

Impedir a codificação

Não embuta segredos de código como texto estático em artefatos de código, como código do aplicativo, arquivos de configuração e pipelines de implantação de build. Essa prática de alto risco torna o código vulnerável porque os segredos são expostos a todos com acesso de leitura.

Você pode evitar essa situação usando identidades gerenciadas para eliminar a necessidade de armazenar credenciais. Seu aplicativo usa sua identidade atribuída para se autenticar em outros recursos por meio do IdP (provedor de identidade). Teste em ambientes de não produção com segredos falsos durante o desenvolvimento para evitar a exposição acidental de segredos reais.

Use ferramentas que detectam periodicamente segredos expostos em seu código de aplicativo e artefatos de build. Você pode adicionar essas ferramentas como ganchos de pré-compromisso do Git que verificam credenciais antes que o código-fonte confirme a implantação. Examine e sanitize os logs de aplicativos regularmente para ajudar a garantir que nenhum segredo seja registrado inadvertidamente. Você também pode reforçar a detecção por meio de revisões de pares.

Observação

Se as ferramentas de verificação descobrirem um segredo, esse segredo deverá ser considerado comprometido. Ele deve ser revogado.

Responder à rotação secreta

Como proprietário de uma carga de trabalho, você precisa entender o plano de rotação de segredo e as políticas para poder incorporar novos segredos com interrupção mínima aos usuários. Quando um segredo é girado, pode haver uma janela quando o segredo antigo não é válido, mas o novo segredo não foi colocado. Durante essa janela, o componente que o aplicativo está tentando acessar não reconhece solicitações. Você pode minimizar esses problemas criando lógica de repetição no código. Você também pode usar padrões de acesso simultâneos que permitem que você tenha várias credenciais que podem ser alteradas com segurança sem afetar umas às outras.

Trabalhe com a equipe de operações e faça parte do processo de gerenciamento de alterações. Você deve informar os proprietários de credenciais ao desativar uma parte do aplicativo que usa credenciais que não são mais necessárias.

Integre a recuperação e a configuração de segredo ao pipeline de implantação automatizado. A recuperação secreta ajuda a garantir que os segredos sejam buscados automaticamente durante a implantação. Você também pode usar padrões de injeção de segredo para inserir segredos no código do aplicativo ou configuração em runtime, o que impede que segredos sejam expostos acidentalmente a logs ou controle de versão.

Facilitação do Azure

Armazene segredos usando o Key Vault. Armazene segredos no sistema de gerenciamento de segredos do Azure, no Key Vault, no HSM Gerenciado do Azure e em outros locais. Para obter mais informações, consulte Como escolher a solução de gerenciamento de chaves correta.

Integre o controle de acesso baseado em identidade. A ID do Microsoft Entra e as identidades gerenciadas ajudam a minimizar a necessidade de segredos. A ID do Microsoft Entra oferece uma experiência altamente segura e utilizável para controle de acesso com mecanismos internos para lidar com a rotação de chaves, para anomalias e muito mais.

Use o RBAC (controle de acesso baseado em função) do Azure para atribuir permissões a usuários, grupos e aplicativos em um determinado escopo.

Use um modelo de acesso para controlar cofres de chaves, permissões e segredos. Para obter mais informações, consulte a visão geral do modelo do Access.

Implementar a detecção de exposição secreta. Integre processos em sua carga de trabalho que detectam atividades suspeitas e verificam periodicamente se há chaves expostas no código do aplicativo. Algumas opções incluem:

Não armazene chaves e segredos para qualquer tipo de ambiente em arquivos de configuração de aplicativo ou pipelines de CI/CD (integração contínua e entrega contínua). Os desenvolvedores devem usar os Serviços Conectados do Visual Studio ou arquivos somente locais para acessar credenciais.

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.

Lista de verificação de segurança

  • Last updated on