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 manuseio 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 que não sã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 

Prazo Definição
Certificados Arquivos digitais que contêm as chaves públicas para criptografia ou descriptografia.
Credenciais Informações usadas para verificar a identidade do editor 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 sejam incluídos.
Criptografia 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 gerenciada Uma identidade atribuída a recursos e gerenciada pelo Azure.
Não secreto Informações que não prejudicam a postura de segurança da carga de trabalho se vazarem.
Rotação O processo de atualização regular de segredos para que, se forem comprometidos, estejam 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 desnecessário para não segredos e que podem 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 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?.

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 nas 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 rígidos.

  • A rotação secreta é 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 o repúdio e minimizar a exposição desnecessária às informações.

Gerenciar segredos de carga de trabalho

Se possível, evite criar segredos. Encontre maneiras de delegar 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 apropriado de permissão. Eduque desenvolvedores, administradores e outras pessoas relevantes sobre a importância do gerenciamento de segredos e das melhores práticas de 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 de forma independente 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 for comprometida, é mais fácil revogar ou alternar essa chave sem afetar outros consumidores.

Essas diretrizes se aplicam a diferentes ambientes. 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, certifique-se de criar várias chaves para oferecer suporte a vários clientes.

Para obter mais informações, consulte Recomendações de 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 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 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 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 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é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 necessários. 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 criar 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 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 o gerenciamento 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.

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 OAuth 2.0 em nome de.

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 visualizando os registros de acesso. Os processos de rotação secreta 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 da conta.

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

Use segredos de carga de trabalho com segurança

Como gerador ou operador de segredos, 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 com 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 é comprometida ou vazada e precisa ser regenerada sob demanda. Considere as seguintes práticas recomendadas de segurança ao usar segredos:

Evitar codificação

Não codifique 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 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 relação a 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 detectem periodicamente segredos expostos no código do aplicativo e criem artefatos. Você pode adicionar essas ferramentas como ganchos de pré-confirmação do Git que verificam as credenciais antes da implantação das confirmações do código-fonte. Revise 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 por pares.

Observação

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

Responder à rotação secreta

Como proprietário da carga de trabalho, você precisa entender o plano e as políticas de rotação de segredos para poder incorporar novos segredos com o mínimo de interrupção para os usuários. Quando um segredo é girado, pode haver uma janela em que 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 uma 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 aos proprietários de credenciais quando 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 segredos ao 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 de segredo para inserir segredos no código do aplicativo ou na configuração em tempo de execução, o que impede que os 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 certa.

Integre o controle de acesso baseado em identidade. A 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 de acesso.

Implemente 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 as credenciais.

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.

Lista de verificação de segurança