Partilhar via

Recomendações para proteger segredos de aplicativos

  • Artigo

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

SE:09 Proteja os segredos dos aplicativos protegendo seu armazenamento e restringindo o acesso e a manipulação, além de auditar 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 de seu aplicativo, carga de trabalho e dados associados. O tratamento inadequado de segredos pode levar a violações de dados, interrupção do serviço, violações regulatórias e outros problemas.

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

Definições 

Vigência Definição
Certificados Ficheiros digitais que contêm as chaves públicas para encriptação ou desencriptação.
Credencial Informações usadas para verificar a identidade do editor ou consumidor em um canal de comunicação.
Análise de credenciais O processo de validação do código-fonte para garantir que os segredos não sejam incluídos.
Encriptação O processo pelo qual os dados são tornados ilegíveis e bloqueados com um código secreto.
Chave Um código secreto usado para bloquear ou desbloquear dados criptografados.
Acesso com privilégios mínimos Um princípio Zero Trust que visa minimizar um conjunto de permissões para concluir uma função de trabalho.
Identidade gerida Uma identidade atribuída a recursos e gerenciada pelo Azure.
Não secreto Informações que não comprometam a postura de segurança da carga de trabalho caso sejam vazadas.
Rotação O processo de atualizar regularmente segredos para que, se forem comprometidos, fiquem disponíveis apenas por um tempo limitado.
Segredo Um componente confidencial do sistema que facilita a comunicação entre os componentes da carga de trabalho. Se vazados, os segredos podem causar uma violação.
X.509 Um padrão que define o formato dos certificados de chave pública.

Importante

Não trate os não segredos como segredos. Os segredos exigem rigor operacional que é desnecessário para os não secretos e que pode resultar em custos extras.

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

Principais estratégias de design

Sua estratégia de gerenciamento de segredos deve minimizar os segredos tanto quanto 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 incorporadas 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 em armazenamento seguro com controles de acesso rigorosos.

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

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

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

Crie uma estratégia em torno desses pontos para ajudar a evitar o roubo de identidade, evitar o 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 formas de delegar responsabilidades à 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 na gestão de segredos.

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

Chaves pré-partilhadas

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 com o tempo, e você não pode atualizar permissões ou distinguir padrões de uso de forma independente depois que uma chave é compartilhada. O acesso distinto também facilita a revogação. Se a chave de um consumidor estiver comprometida, é mais fácil revogá-la ou girá-la sem afetar outros consumidores.

Esta orientação aplica-se a diferentes ambientes. A mesma chave não deve ser usada para ambientes de pré-produção e produção. Se for responsável pela criação de chaves pré-partilhadas, certifique-se de que cria várias chaves para suportar vários clientes.

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

Armazenamento secreto

Use um sistema de gerenciamento secreto, 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 nos 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 Cofre da Chave ou no armazenamento de certificados do SO. Por exemplo, armazenar um certificado X.509 em um arquivo PFX ou em um disco não é recomendado. Se você precisar de um nível mais alto de segurança, escolha sistemas que tenham recursos de módulo de segurança de hardware (HSM) em vez de armazenamentos secretos baseados em software.

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

Um sistema de gerenciamento secreto dedicado facilita o armazenamento, distribuição e controle de acesso aos segredos do aplicativo. Apenas identidades e serviços autorizados devem ter acesso a lojas secretas. O acesso ao sistema pode ser restringido através de permissões. Sempre aplique a abordagem de privilégios mínimos ao atribuir permissões.

Você também precisa controlar o acesso no nível secreto. Cada segredo só deve ter acesso a um único escopo de recurso. Crie limites de isolamento para que um componente só possa usar os segredos de que precisa. Se um componente isolado for 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 auditoria e 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 perspetiva de segurança, consulte Recomendações sobre monitoramento de segurança e deteção de ameaças.

Rotação secreta

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 retirados e substituídos por novos segredos com a maior frequência possível.

Lide com tokens de acesso OAuth com cuidado, levando em consideração seu tempo de vida. Ponderar se a janela de exposição necessita de ser ajustada para um período mais curto. Os tokens de atualização devem ser armazenados de forma segura com exposição limitada ao aplicativo. Os 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 refresh tokens.

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

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

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

Use 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 aos 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 desastres devem incluir procedimentos secretos de recuperação. Tenha um processo para situações em que uma chave está comprometida ou vazada e precisa ser regenerada sob demanda. Considere as seguintes práticas recomendadas de segurança ao usar segredos:

Impedir a codificação

Não codifice segredos como texto estático em artefatos de código, como código de aplicativo, arquivos de configuração e pipelines de implantação de compilação. 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 autenticar em outros recursos por meio do provedor de identidade (IdP). 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 detetam periodicamente segredos expostos no código do aplicativo e criam artefatos. Você pode adicionar essas ferramentas como ganchos de pré-confirmação do Git que verificam as credenciais antes que o código-fonte confirme a implantação. Revise e limpe os logs de aplicativos regularmente para ajudar a garantir que nenhum segredo seja registrado inadvertidamente. Você também pode reforçar a deteção por meio de avaliações por pares.

Nota

Se as ferramentas de digitalização descobrirem um segredo, esse segredo deve ser considerado comprometido. Deve ser revogado.

Responder à rotação secreta

Como proprietário de uma carga de trabalho, você precisa entender o plano de rotação secreta e as políticas para poder incorporar novos segredos com o mínimo de interrupção para os 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 alcançar 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 mudanças. Você deve informar os proprietários de credenciais quando encerrar uma parte do aplicativo que usa credenciais que não são mais necessárias.

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

Facilitação do Azure

Armazene segredos usando o Cofre da Chave. Armazene segredos no sistema de gerenciamento secreto do Azure, no Cofre da Chave, 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. O ID do Microsoft Entra e as identidades gerenciadas ajudam a minimizar a necessidade de segredos. O Microsoft Entra ID oferece uma experiência altamente segura e utilizável para controle de acesso com mecanismos internos para lidar com a rotação de chaves, 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 Visão geral do modelo do Access.

Implemente a deteção de exposição secreta. Integre processos em sua carga de trabalho que detetam atividades suspeitas e verifique 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 aplicativos ou pipelines de integração contínua e entrega contínua (CI/CD). Os desenvolvedores devem usar o Visual Studio Connected Services 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