Partilhar via

Recomendações para proteger segredos de aplicações

  • Artigo

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

SE:09 Proteja os segredos da aplicação ao proteger o respetivo armazenamento e restringir o acesso e manipulação e ao auditar essas ações. Execute um processo de rotação fiável e regular que pode improvisar rotações para emergências.

Este guia descreve as recomendações para proteger informações confidenciais nas aplicações. A gestão adequada dos segredos é crucial para manter a segurança e integridade da sua aplicação, carga de trabalho e dados associados. O processamento inadequado de segredos pode levar a violações de dados, interrupção do serviço, violações regulamentares e outros problemas.

As credenciais, como chaves de API, tokens OAuth (Open Authorization) e Secure Shell (SSH) são segredos. Algumas credenciais, como tokens OAuth do lado do cliente, podem ser criadas dinamicamente no runtime. Os segredos dinâmicos ainda precisam de ser salvaguardados, apesar da sua natureza temporária. As informações não incredenciais, 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 da aplicação.

Definições 

Termo Definição
Certificados Ficheiros digitais que contêm as chaves públicas para encriptação ou desencriptação.
Credencial Informações utilizadas para verificar a identidade do editor ou consumidor num canal de comunicação.
Análise de credenciais O processo de validação do código fonte para garantir que os segredos não estão 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 que é utilizado para bloquear ou desbloquear dados encriptados.
Acesso com menos privilégios Um princípio Confiança Zero que visa minimizar um conjunto de permissões para concluir uma função de trabalho.
Identidade gerida Uma identidade atribuída aos recursos e gerida pelo Azure.
Nãosecret Informações que não colocam em risco a postura de segurança da carga de trabalho se esta for divulgada.
Rotação O processo de atualização regular de segredos para que, se forem comprometidos, fiquem disponíveis apenas por um período de tempo limitado.
Segredo Um componente confidencial do sistema que facilita a comunicação entre componentes de carga de trabalho. Se forem divulgados, os segredos podem causar uma falha de segurança.
X.509 Um padrão que define o formato dos certificados de chave pública.

Importante

Não trate os não-secretos como segredos. Os segredos requerem rigor operacional desnecessário para os não-secretos e isso pode resultar em custos adicionais.

As definições de configuração da aplicação, como URLs para APIs que a aplicação utiliza, são um exemplo de não-serets. Estas informações não devem ser armazenadas com o código da aplicação ou os segredos da aplicação. Considere utilizar um sistema de gestão de configuração dedicado, como Azure App Configuration para gerir estas definições. Para obter mais informações, consulte O que é Azure App Configuration?.

Principais estratégias de design

A sua estratégia de gestão de segredos deve minimizar os segredos o máximo possível e integrá-los no ambiente ao tirar partido das funcionalidades da plataforma. Por exemplo, se utilizar uma identidade gerida para a sua aplicação, as informações de acesso não são incorporadas em cadeias de ligação e é seguro armazenar as informações num ficheiro de configuração. Considere as seguintes áreas de preocupação antes de armazenar e gerir segredos:

  • Os segredos criados devem ser mantidos no armazenamento seguro com controlos de acesso rigorosos.

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

  • Apenas as identidades fidedignas devem ter acesso a segredos.

  • Deve manter um registo de auditoria para inspecionar e validar o acesso aos segredos.

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

Práticas seguras para a gestão de segredos

Se possível, evite criar segredos. Encontre formas de delegar a responsabilidade à plataforma. Por exemplo, utilize as identidades geridas incorporadas da plataforma para processar credenciais. Menos segredos resultam numa área de superfície reduzida e menos tempo gasto na gestão de segredos.

Recomendamos que as chaves tenham três funções distintas: utilizador, administrador e auditor. A distinção de funções ajuda a garantir que apenas as identidades fidedignas têm acesso a segredos com o nível de permissão adequado. Informe os programadores, administradores e outras pessoas relevantes sobre a importância das melhores práticas de gestão e segurança de segredos.

Chaves pré-partilhadas

Pode controlar o acesso ao criar chaves distintas para cada consumidor. Por exemplo, um cliente comunica com uma API de terceiros com uma chave pré-partilhada. Se outro cliente precisar de aceder à mesma API, tem de utilizar outra chave. Não partilhe chaves mesmo que dois consumidores tenham os mesmos padrões ou funções de acesso. Os âmbitos de consumidor podem ser alterados ao longo do tempo e não pode atualizar permissões de forma independente ou distinguir padrões de utilização após a partilha de uma chave. O acesso distinto também facilita a revogação. Se a chave de um consumidor for comprometida, é mais fácil revogar ou rodar essa chave sem afetar outros consumidores.

Esta documentação de orientação aplica-se a diferentes ambientes. A mesma chave não deve ser utilizada para ambientes de pré-produção e de 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, veja Recomendações para gestão de identidades e acessos.

Armazenamento de segredos

Utilize um sistema de gestão de segredos, como o Azure Key Vault, para armazenar segredos num ambiente protegido, encriptar inativos e em trânsito, e auditar o acesso e as alterações aos segredos. Se precisar de armazenar segredos da aplicação, mantenha-os fora do código fonte para facilitar a rotação.

Os certificados só devem ser armazenados no Key Vault ou no arquivo de certificados do SO. Por exemplo, não é recomendado armazenar um certificado X.509 num ficheiro PFX ou num disco. Se precisar de um nível mais elevado de segurança, selecione sistemas que tenham capacidades do módulo de segurança de hardware (HSM) em vez de arquivos secretos baseados em software.

Desvantagem: as soluções HSM são oferecidas a um custo mais elevado. Também poderá ver um efeito no desempenho da aplicação devido a camadas de segurança adicionadas.

Um sistema de gestão de segredos dedicado facilita o armazenamento, distribuição e controlo do acesso aos segredos da aplicação. Apenas as identidades e serviços autorizados devem ter acesso a arquivos secretos. O acesso ao sistema pode ser restringido através de permissões. Aplique sempre a abordagem de menor privilégio ao atribuir permissões.

Também tem de controlar o acesso ao nível do segredo. Cada segredo só deve ter acesso a um único âmbito de recurso. Crie limites de isolamento para que um componente só possa utilizar segredos de que precisa. Se um componente isolado for comprometido, não poderá obter o controlo de outros segredos e, potencialmente, de toda a carga de trabalho. Uma forma de isolar segredos é utilizar vários cofres de chaves. Não existem custos adicionais para a criação de cofres de chaves adicionais.

Implementar auditoria e monitorização para acesso secreto. Registe quem acede a segredos e quando identificar atividades não autorizadas ou suspeitas. Para obter informações sobre o registo numa perspetiva de segurança, veja Recomendações sobre monitorização de segurança e deteçã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 descontinuados e substituídos por novos segredos com a maior frequência possível.

Processe cuidadosamente os tokens de acesso do OAuth, tendo em consideração o seu tempo de vida. Considere se a janela de exposição tem de ser ajustada para um período mais curto. Os tokens de atualização têm de ser armazenados de forma segura com exposição limitada à aplicação. Os certificados renovados também devem utilizar uma nova chave. Para obter informações sobre tokens de atualização, veja Secure OAuth 2.0 On-Behalf-Of refresh tokens (Tokens de atualização Secure OAuth 2.0 On-Behalf-Of).

Substitua os segredos depois de atingirem o fim de vida, já não são utilizados pela carga de trabalho ou se foram comprometidos. Por outro lado, não retire segredos ativos a menos que seja uma emergência. Pode determinar o estado de um segredo ao ver os registos de acesso. Os processos de rotação de segredos não devem afetar a fiabilidade ou o desempenho da carga de trabalho. Utilize 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, veja Gerir chaves de acesso à conta.

Os processos de rotação devem ser automatizados e implementados sem qualquer interação humana. Armazenar segredos num arquivo de gestão de segredos que suporta nativamente conceitos de rotação pode simplificar esta tarefa operacional.

Práticas seguras para utilizar segredos

Enquanto gerador ou operador secreto, deve conseguir distribuir segredos de forma segura. Muitas organizações utilizam ferramentas para partilhar segredos de forma segura, tanto na organização como externamente com os parceiros. Na ausência de uma ferramenta, tenha um processo para entregar corretamente as credenciais aos destinatários autorizados. Os seus planos de recuperação após desastre devem incluir procedimentos secretos de recuperação. Ter um processo para situações em que uma chave é comprometida ou vazada e precisa de ser regenerada a pedido. Considere as seguintes melhores práticas de segurança ao utilizar segredos:

Impedir a codificação

Não utilize segredos de código rígido como texto estático em artefactos de código, como código de aplicação, ficheiros de configuração e pipelines de implementação de compilação. Esta prática de alto risco torna o código vulnerável porque os segredos são expostos a todas as pessoas com acesso de leitura.

Pode evitar esta situação ao utilizar identidades geridas para eliminar a necessidade de armazenar credenciais. A sua aplicação utiliza a identidade atribuída para autenticar noutros recursos através do fornecedor 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.

Utilize ferramentas que detetem periodicamente segredos expostos no código da aplicação e criem artefactos. Pode adicionar estas ferramentas como ganchos de pré-compromisso do Git que procuram credenciais antes da implementação das consolidações de código fonte. Reveja e sanitize os registos de aplicações regularmente para ajudar a garantir que não são registados inadvertidamente segredos. Também pode reforçar a deteção através de revisões em modo de peering.

Nota

Se as ferramentas de análise descobrirem um segredo, esse segredo tem de ser considerado comprometido. Deve ser revogada.

Responder à rotação secreta

Enquanto proprietário da carga de trabalho, tem de compreender o plano de rotação de segredos e as políticas para poder incorporar novos segredos com interrupções mínimas para os utilizadores. Quando um segredo é rodado, 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 a aplicação está a tentar alcançar não reconhece os pedidos. Pode minimizar estes problemas ao criar lógica de repetição no código. Também pode utilizar padrões de acesso simultâneos que lhe permitem ter múltiplas credenciais que podem ser alteradas em segurança sem afetar uns aos outros.

Trabalhe com a equipa de operações e faça parte do processo de gestão de alterações. Deve informar os proprietários de credenciais quando desativar uma parte da aplicação que utiliza credenciais que já não são necessárias.

Integre a obtenção e a configuração de segredos no pipeline de implementação automatizada. A obtenção de segredos ajuda a garantir que os segredos são obtidos automaticamente durante a implementação. Também pode utilizar padrões de injeção secreta para inserir segredos no código da aplicação ou configuração no runtime, o que impede que os segredos sejam acidentalmente expostos a registos ou controlo de versões.

Facilitação do Azure

Armazene segredos com Key Vault. Armazene segredos no sistema de gestão de segredos do Azure, Key Vault, Azure Managed HSM e outras localizações. Para obter mais informações, veja Como escolher a solução de gestão de chaves correta.

Integrar o controlo de acesso baseado em identidades. Microsoft Entra ID e identidades geridas ajudam a minimizar a necessidade de segredos. Microsoft Entra ID oferece uma experiência altamente segura e utilizável para controlo de acesso com mecanismos incorporados para processar a rotação de chaves, para anomalias e muito mais.

Utilize o controlo de acesso baseado em funções (RBAC) do Azure para atribuir permissões a utilizadores, grupos e aplicações num determinado âmbito.

Utilize um modelo de acesso para controlar cofres de chaves, permissões e segredos. Para obter mais informações, veja Descrição geral do modelo do Access.

Implementar a deteção de exposição secreta. Integre processos na sua carga de trabalho que detetem atividades suspeitas e verifiquem periodicamente se existem chaves expostas no código da aplicação. Algumas opções incluem:

Não armazene chaves e segredos para qualquer tipo de ambiente em ficheiros de configuração de aplicações ou pipelines de integração contínua e entrega contínua (CI/CD). Os programadores devem utilizar os Serviços Ligados do Visual Studio ou ficheiros apenas locais para aceder às credenciais.

Lista de verificação de segurança

Veja o conjunto completo de recomendações.

Lista de verificação de segurança