Share via

Recomendações para proteger segredos do aplicativo

  • Artigo

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

SE:09 Proteja os segredos do aplicativo protegendo seu 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 possa 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 credenciais, como certificados e chaves de assinatura digital, também podem ser confidenciais. Os requisitos de conformidade podem fazer com que as definições de configuração que normalmente não são consideradas secretas sejam tratadas como segredos do aplicativo.

Definições 

Termo Definição
Certificados Arquivos digitais que contêm as chaves públicas para criptografia ou descriptografia.
Credencial 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.
Criptografia O processo pelo qual os dados são 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 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.
Rotação O processo de atualização regular de segredos para que, se eles estiverem comprometidos, eles fiquem disponíveis apenas por um tempo limitado.
Segredo Um componente confidencial do sistema que facilita a comunicação entre componentes de carga de trabalho. Se vazado, 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 os não-seguros como segredos. Os segredos exigem rigor operacional desnecessário para não-seguros e isso 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 seguros. Essas informações não devem ser armazenadas com o código do aplicativo ou segredos do aplicativo. Considere usar um sistema de gerenciamento de configuração dedicado, como Configuração de Aplicativos do Azure, para gerenciar essas configurações. Para obter mais informações, consulte O que é Configuração de Aplicativos do Azure?.

Principais estratégias de design

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 será 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 estritos.

  • A rotação de segredos é 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 aos segredos.

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

Práticas seguras para gerenciamento de segredos

Se possível, evite criar segredos. Encontre maneiras de delegar a responsabilidade à 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. Instrua desenvolvedores, administradores e outras pessoas relevantes sobre a importância das práticas recomendadas de segurança e gerenciamento de segredos.

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.

Essas diretrizes se aplicam 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 para gerenciamento de identidades e acesso.

Armazenamento de segredos

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 em 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 de segredos 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 adicionais de segurança.

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 de segredos. O acesso ao sistema pode ser restrito por meio 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 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 for comprometido, ele não poderá obter 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 criar 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 segredos

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.

Manipule os tokens de acesso OAuth com cuidado, levando em consideração seu tempo de vida. 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. Os certificados renovados também devem usar uma nova chave. Para obter informações sobre tokens de atualização, consulte Proteger tokens de atualização on-behalf-of do OAuth 2.0.

Substitua os segredos depois que eles atingirem o fim da vida útil, não forem mais usados pela carga de trabalho ou se tiverem sido comprometidos. Por outro lado, não desative segredos ativos, a menos que seja uma emergência. Você pode determinar a 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 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 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.

Práticas seguras para usar segredos

Como um gerador ou operador de segredo, 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 de recuperação secretos. 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 para segurança ao usar segredos:

Impedir a codificação

Não embuta segredos em 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 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 no código do aplicativo e compilem artefatos. Você pode adicionar essas ferramentas como ganchos de pré-confirmação do Git que verificam credenciais antes da implantação do código-fonte. Examine e limpe os logs do aplicativo 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 de segredos

Como proprietário da carga de trabalho, você precisa entender o plano de rotação de segredos 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 alcançar não reconhece as 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 ter 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 de segredo 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 na 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 Key Vault. Armazene segredos no sistema de gerenciamento de segredos do Azure, Key Vault, HSM Gerenciado do Azure e outros locais. Para obter mais informações, consulte Como escolher a solução de gerenciamento de chaves correta.

Integrar o controle de acesso baseado em identidade. Microsoft Entra ID e identidades gerenciadas ajudam a minimizar a necessidade de segredos. Microsoft Entra ID oferece uma experiência altamente segura e utilizável para o 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 Visão geral do modelo de acesso.

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

Não armazene chaves e segredos para nenhum 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