Partilhar via

Controlo de Segurança: Gestão de identidades

  • Artigo

A Gestão de Identidades abrange controlos para estabelecer uma identidade segura e controlos de acesso através de sistemas de gestão de identidades e acessos, incluindo a utilização de início de sessão único, autenticações fortes, identidades geridas (e principais de serviço) para aplicações, acesso condicional e monitorização de anomalias de conta.

IM-1: utilizar o sistema de autenticação e identidade centralizado

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
6.7, 12.5 AC-2, AC-3, IA-2, IA-8 7.2, 8.3

Princípio de segurança: utilize um sistema centralizado de identidade e autenticação para governar as identidades e autenticações da sua organização para recursos de cloud e não cloud.

Orientação do Azure: o Azure Active Directory (Azure AD) é o serviço de gestão de identidades e autenticação do Azure. Deve uniformizar em Azure AD para governar a identidade e autenticação da sua organização em:

  • Recursos da cloud da Microsoft, como o Armazenamento do Azure, Máquinas Virtuais do Azure (Linux e Windows), aplicações Azure Key Vault, PaaS e SaaS.
  • Os recursos da sua organização, como aplicações no Azure, aplicações de terceiros em execução nos recursos de rede empresarial e aplicações SaaS de terceiros.
  • As suas identidades empresariais no Active Directory através da sincronização para Azure AD para garantir uma estratégia de identidade consistente e gerida centralmente.

Para os serviços do Azure que se aplicam, evite a utilização de métodos de autenticação local e, em vez disso, utilize o Azure Active Directory para centralizar as autenticações do serviço.

Nota: assim que for tecnicamente viável, deve migrar aplicações baseadas em Active Directory no local para Azure AD. Pode ser uma configuração do Azure AD Enterprise Directory, Business to Business ou Business to Consumer.

Implementação do Azure e contexto adicional:

Orientação do AWS: O IAM do AWS (Gestão de Identidades e Acessos) é o serviço de gestão de autenticação e identidade predefinido do AWS. Utilize o IAM do AWS para governar a sua gestão de identidades e acessos do AWS. Em alternativa, através do AWS e do Azure Single Sign-On (SSO), também pode utilizar Azure AD para gerir a identidade e o controlo de acesso do AWS para evitar gerir contas duplicadas separadamente em duas plataformas na cloud.

O AWS suporta Sign-On único que lhe permite fazer a ponte entre as identidades de terceiros da sua empresa (como o Windows Active Directory ou outros arquivos de identidades) com as identidades do AWS para evitar criar contas duplicadas para aceder aos recursos do AWS.

Implementação do AWS e contexto adicional:

Orientação do GCP: o sistema IAM (Identity and Access Management) da Google Cloud é o serviço de gestão de identidades e autenticação predefinido da Google Cloud utilizado para contas do Google Cloud Identity. Utilize o IAM do Google Cloud para governar a sua gestão de identidades e acessos do GCP. Em alternativa, através do Google Cloud Identity e do Azure Sigle Sign-On (SSO), também pode utilizar Azure AD para gerir a identidade e o controlo de acesso do GCP para evitar gerir contas duplicadas separadamente num ambiente de mutli-cloud.

O Google Cloud Identity é o fornecedor de identidade de todos os serviços Google. Suporta Sign-On individuais que lhe permitem fazer a ponte entre as identidades de terceiros da sua empresa (como o Windows Active Directory ou outros arquivos de identidades) com identidades do Google Cloud para evitar criar contas duplicadas para aceder aos recursos do GCP.

Nota: utilizar o Google Cloud Directory Sync. A Google fornece uma ferramenta de conector que se integra com a maioria dos sistemas de gestão LDAP empresariais e sincroniza identidades com base numa agenda. Ao configurar uma conta de Identidade da Cloud e ao cantar o Google Cloud Directory Sync, pode configurar qual das suas contas de utilizador – incluindo utilizadores, grupos e perfis de utilizador, aliases e muito mais – irá sincronizar com base numa agenda entre o seu sistema de gestão de identidades local e o seu sistema GCP.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

IM-2: proteger sistemas de identidade e autenticação

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
5.4, 6.5 AC-2, AC-3, IA-2, IA-8, SI-4 8.2, 8.3

Princípio de segurança: proteja o seu sistema de identidade e autenticação como uma prioridade elevada na prática de segurança na cloud da sua organização. Os controlos de segurança comuns incluem:

  • Restringir funções e contas com privilégios
  • Exigir autenticação forte para todos os acessos privilegiados
  • Monitorizar e auditar atividades de alto risco

Orientação do Azure: utilize a linha de base de segurança Azure AD e a Classificação de Segurança de Identidade do Azure AD para avaliar a sua postura de segurança de identidade Azure AD e remediar as lacunas de segurança e configuração. A Classificação de Segurança de Identidade do Azure AD avalia Azure AD para as seguintes configurações:

  • Utilizar funções administrativas limitadas
  • Ativar a política de risco do utilizador
  • Designar mais do que um administrador global
  • Ativar a política para bloquear a autenticação legada
  • Certifique-se de que todos os utilizadores podem concluir a autenticação multifator para acesso seguro
  • Exigir MFA para funções administrativas
  • Ativar a reposição de palavras-passe self-service
  • Não expirar palavras-passe
  • Ativar a política de risco de início de sessão
  • Não permitir que os utilizadores concedam consentimento a aplicações não geridas

Utilize Azure AD Identity Protection para detetar, investigar e remediar riscos baseados em identidades. Para proteger de forma semelhante o seu domínio Active Directory no local, utilize o Defender para Identidade.

Nota: siga as melhores práticas publicadas para todos os outros componentes de identidade, incluindo a sua Active Directory no local e quaisquer capacidades de terceiros e as infraestruturas (como sistemas operativos, redes, bases de dados) que os alojam.

Implementação do Azure e contexto adicional:

Orientação do AWS: utilize as seguintes melhores práticas de segurança para proteger o IAM do AWS:

  • Configurar as chaves de acesso de utilizador raiz da conta do AWS para acesso de emergência, conforme descrito em PA-5 (Configurar o acesso de emergência)
  • Siga os princípios de privilégios mínimos para atribuições de acesso
  • Tire partido dos grupos IAM para aplicar políticas em vez de utilizadores individuais.
  • Siga orientações de autenticação fortes na IM-6 (Utilizar controlos de autenticação fortes) para todos os utilizadores
  • Utilizar o SCP das Organizações do AWS (Política de Controlo de Serviços) e os limites de permissão
  • Utilizar o Assistente de Acesso IAM para auditar o acesso ao serviço
  • Utilizar o relatório de credenciais do IAM para controlar as contas de utilizador e o estado das credenciais

Nota: siga as melhores práticas publicadas se tiver outros sistemas de identidade e autenticação, por exemplo, siga a linha de base de segurança Azure AD se utilizar Azure AD para gerir a identidade e o acesso do AWS.

Implementação do AWS e contexto adicional:

Orientação do GCP: utilize as seguintes melhores práticas de segurança para proteger os serviços IAM e Identidade da Cloud do Google Cloud para as suas organizações:

  • Configure uma conta de super administrador para acesso de emergência ao seguir as recomendações na PA-5 ("Configurar o acesso de emergência").
  • Crie um endereço de e-mail de super administrador (como a conta de super administrador da Google Workspace ou da Cloud Identity) e esta conta não deve ser específica para um determinado utilizador caso seja necessária uma recuperação de emergência.
  • Siga os princípios de menor privilégio e separação de deveres
  • Evite utilizar a conta de super administrador para atividades diárias
  • Tire partido dos grupos do Google Cloud Identity para aplicar políticas em vez de aplicar políticas a utilizadores individuais.
  • Siga as orientações de autenticação fortes, conforme descrito em IM-6 ("Utilizar controlos de autenticação fortes") para todos os utilizadores com privilégios elevados.
  • Utilizar políticas de IAM para restringir o acesso aos recursos
  • Utilizar o Serviço de Política da Organização para controlar e configurar restrições nos recursos
  • Utilizar o registo de auditoria do IAM nos registos de Auditoria da Cloud para rever as atividades privilegiadas

Nota: siga as melhores práticas publicadas se tiver outros sistemas de identidade e autenticação, por exemplo, siga a linha de base de segurança Azure AD se utilizar Azure AD para gerir a identidade e o acesso do GCP.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

IM-3: Gerir identidades de aplicações de forma segura e automática

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
N/D AC-2, AC-3, IA-4, IA-5, IA-9 N/D

Princípio de segurança: utilize identidades de aplicações geridas em vez de criar contas humanas para que as aplicações acedam a recursos e executem código. As identidades de aplicações geridas proporcionam benefícios, como a redução da exposição das credenciais. Automatize a rotação de credenciais para garantir a segurança das identidades.

Orientação do Azure: utilize identidades geridas do Azure, que podem autenticar-se nos serviços e recursos do Azure que suportam a autenticação Azure AD. As credenciais de identidade gerida são totalmente geridas, rodadas e protegidas pela plataforma, evitando credenciais codificadas em código fonte ou ficheiros de configuração.

Para serviços que não suportam identidades geridas, utilize Azure AD para criar um principal de serviço com permissões restritas ao nível do recurso. Recomenda-se configurar principais de serviço com credenciais de certificado e reverter para os segredos do cliente para autenticação.

Implementação do Azure e contexto adicional:

Orientação do AWS: utilize funções IAM do AWS em vez de criar contas de utilizador para recursos que suportam esta funcionalidade. As funções de IAM são geridas pela plataforma no back-end e as credenciais são temporárias e rodadas automaticamente. Isto evita a criação de chaves de acesso de longo prazo ou um nome de utilizador/palavra-passe para aplicações e credenciais codificadas em código fonte ou ficheiros de configuração.

Pode utilizar funções ligadas ao serviço anexadas com políticas de permissão predefinidas para acesso entre serviços do AWS em vez de personalizar as suas próprias permissões de função para as funções de IAM.

Nota: para serviços que não suportam funções de IAM, utilize chaves de acesso, mas siga as melhores práticas de segurança, como IM-8 Restringir a exposição de credenciais e segredos para proteger as suas chaves.

Implementação do AWS e contexto adicional:

Orientação do GCP: utilize contas de serviço geridas pela Google em vez de criar contas geridas pelo utilizador para recursos que suportam esta funcionalidade. As contas de serviço geridas pela Google são geridas pela plataforma no back-end e as chaves da conta de serviço são temporárias e rodadas automaticamente. Isto evita a criação de chaves de acesso a longo prazo ou um nome de utilizador/palavra-passe para aplicações e credenciais hard-coded hard-coding em ficheiros de código fonte ou de configuração.

Utilize a Inteligência de Políticas para compreender e reconhecer atividades suspeitas para contas de serviço.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

IM-4: Autenticar o servidor e os serviços

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
N/D IA-9 N/D

Princípio de segurança: autentique servidores e serviços remotos do lado do cliente para garantir que está a ligar-se a serviços e servidores fidedignos. O protocolo de autenticação de servidor mais comum é o Transport Layer Security (TLS), onde o lado do cliente (muitas vezes um browser ou dispositivo cliente) verifica o servidor ao verificar se o certificado do servidor foi emitido por uma autoridade de certificação fidedigna.

Nota: a autenticação mútua pode ser utilizada quando o servidor e o cliente se autenticam entre si.

Orientação do Azure: muitos serviços do Azure suportam a autenticação TLS por predefinição. Para serviços que não suportam a autenticação TLS por predefinição ou suportam a desativação do TLS, certifique-se de que está sempre ativado para suportar a autenticação de servidor/cliente. A aplicação cliente também deve ser concebida para verificar a identidade do servidor/cliente (ao verificar o certificado do servidor emitido por uma autoridade de certificação fidedigna) na fase de handshake.

Nota: serviços como o Gestão de API e o Gateway de API suportam a autenticação mútua TLS.

Implementação do Azure e contexto adicional:

Orientação do AWS: muitos serviços do AWS suportam a autenticação TLS por predefinição. Para serviços que não suportam a autenticação TLS por predefinição ou suportam a desativação do TLS, certifique-se de que está sempre ativado para suportar a autenticação de servidor/cliente. A aplicação cliente também deve ser concebida para verificar a identidade do servidor/cliente (ao verificar o certificado do servidor emitido por uma autoridade de certificação fidedigna) na fase de handshake.

Nota: serviços como o Gateway de API suportam a autenticação mútua TLS.

Implementação do AWS e contexto adicional:

Orientação do GCP: muitos serviços GCP suportam a autenticação TLS por predefinição. Para serviços que não suportam esta funcionalidade por predefinição ou suportam a desativação do TLS, certifique-se de que está sempre ativado para suportar a autenticação de servidor/cliente. A aplicação cliente também deve ser concebida para verificar a identidade do servidor/cliente (ao verificar o certificado do servidor emitido por uma autoridade de certificação fidedigna) na fase de handshake.

Nota: serviços como o Balanceamento de Carga na Cloud suportam a autenticação mútua TLS.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

IM-5: Utilizar o início de sessão único (SSO) para o acesso à aplicação

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
12.5 IA-4, IA-2, IA-8 N/D

Princípio de segurança: utilize o início de sessão único (SSO) para simplificar a experiência do utilizador para autenticar recursos, incluindo aplicações e dados em serviços cloud e ambientes no local.

Orientação do Azure: utilize Azure AD para o acesso à aplicação de carga de trabalho (destinado ao cliente) através de Azure AD início de sessão único (SSO), reduzindo a necessidade de contas duplicadas. Azure AD fornece gestão de identidades e acessos aos recursos do Azure (no plano de gestão, incluindo a CLI, o PowerShell, o portal), aplicações na cloud e aplicações no local.

Azure AD também suporta o SSO para identidades empresariais, como identidades de utilizador empresarial, bem como identidades de utilizadores externos de utilizadores de terceiros fidedignos e utilizadores públicos.

Implementação do Azure e contexto adicional:

Orientação do AWS: utilize o AWS Cognito para gerir as acessos às cargas de trabalho das aplicações destinadas ao cliente através do início de sessão único (SSO) para permitir que os clientes criem a ponte entre as identidades de terceiros de diferentes fornecedores de identidade.

Para aceder ao SSO aos recursos nativos do AWS (incluindo acesso à consola do AWS ou gestão de serviços e acesso ao nível do plano de dados), utilize o AWS Sigle Sign-On para reduzir a necessidade de contas duplicadas.

O SSO do AWS também lhe permite fazer a ponte entre identidades empresariais (como identidades do Azure Active Directory) com identidades do AWS, bem como identidades de utilizadores externos de utilizadores de terceiros e utilizadores públicos fidedignos.

Implementação do AWS e contexto adicional:

Orientação do GCP: utilize o Google Cloud Identity para gerir o acesso à aplicação de carga de trabalho com acesso ao cliente através do Início de Sessão Único da Identidade do Google Cloud, reduzindo a necessidade de contas duplicadas. O Google Cloud Identity fornece gestão de identidades e acessos ao GCP (no plano de gestão, incluindo a CLI do Google Cloud, o acesso à consola), aplicações na cloud e aplicações no local.

O Google Cloud Identity também suporta o SSO para identidades empresariais, como identidades de utilizadores empresariais do Azure AD ou do Active Directory, bem como identidades de utilizadores externos de utilizadores terceiros e públicos fidedignos. Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

IM-6: utilizar controlos de autenticação fortes

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
6.3, 6.4 AC-2, AC-3, IA-2, IA-5, IA-8 7.2, 8.2, 8.3, 8.4

Princípio de segurança: impor controlos de autenticação fortes (autenticação sem palavra-passe forte ou autenticação multifator) com o seu sistema de gestão de identidade e autenticação centralizado para todo o acesso aos recursos. A autenticação baseada apenas em credenciais de palavra-passe é considerada legada, uma vez que é insegura e não suporta métodos de ataque populares.

Ao implementar uma autenticação forte, configure primeiro administradores e utilizadores privilegiados para garantir o nível mais elevado do método de autenticação forte, seguido rapidamente pela implementação da política de autenticação forte adequada a todos os utilizadores.

Nota: se a autenticação baseada em palavra-passe legada for necessária para aplicações e cenários legados, certifique-se de que são seguidas as melhores práticas de segurança de palavras-passe, como requisitos de complexidade.

Orientação do Azure: Azure AD suporta controlos de autenticação fortes através de métodos sem palavra-passe e autenticação multifator (MFA).

  • Autenticação sem palavra-passe: utilize a autenticação sem palavra-passe como método de autenticação predefinido. Existem três opções disponíveis na autenticação sem palavra-passe: Windows Hello para Empresas, início de sessão no telemóvel da aplicação Microsoft Authenticator e chaves de segurança FIDO2. Além disso, os clientes podem utilizar métodos de autenticação no local, como smart cards.
  • Autenticação multifator: a MFA do Azure pode ser imposta a todos os utilizadores, selecionar utilizadores ou ao nível por utilizador com base em condições de início de sessão e fatores de risco. Ative a MFA do Azure e siga Microsoft Defender para recomendações de gestão de identidades e acessos da cloud para a configuração da MFA.

Se a autenticação baseada em palavra-passe legada ainda for utilizada para autenticação Azure AD, tenha em atenção que as contas apenas na cloud (contas de utilizador criadas diretamente no Azure) têm uma política de palavra-passe de linha de base predefinida. E as contas híbridas (contas de utilizador provenientes de Active Directory no local) seguem as políticas de palavras-passe no local.

Para aplicações e serviços de terceiros que possam ter IDs e palavras-passe predefinidos, deve desativar ou alterá-los durante a configuração inicial do serviço.

Implementação do Azure e contexto adicional:

Orientação do AWS: o IAM do AWS suporta controlos de autenticação fortes através da autenticação multifator (MFA). A MFA pode ser imposta a todos os utilizadores, selecionar utilizadores ou ao nível por utilizador com base em condições definidas.

Se utilizar contas empresariais de um diretório de terceiros (como o Windows Active Directory) com identidades do AWS, siga as respetivas orientações de segurança para impor uma autenticação forte. Veja a Documentação de Orientação do Azure para este controlo se utilizar Azure AD para gerir o acesso do AWS.

Nota: para aplicações de terceiros e serviços AWS que podem ter IDs e palavras-passe predefinidos, deve desativar ou alterá-los durante a configuração inicial do serviço.

Implementação do AWS e contexto adicional:

Orientação do GCP: o Google Cloud Identity suporta controlos de autenticação fortes através da autenticação multifator (MFA). A MFA pode ser imposta a todos os utilizadores, selecionar utilizadores ou ao nível por utilizador com base em condições definidas. Para proteger as contas de superdmin da Identidade da Cloud (e área de trabalho), considere utilizar chaves de segurança e o Programa de Proteção Avançada do Google para obter a máxima segurança.

Se utilizar contas empresariais de um diretório de terceiros (como o Windows Active Directory) com identidades do Google Cloud, siga as respetivas orientações de segurança para impor uma autenticação forte. Veja a Documentação de Orientação do Azure para este controlo se utilizar Azure AD para gerir o acesso ao Google Cloud.

Utilize Identity-Aware Proxy para estabelecer uma camada de autorização central para aplicações acedidas por HTTPS, para que possa utilizar um modelo de controlo de acesso ao nível da aplicação em vez de depender de firewalls ao nível da rede.

Nota: para aplicações de terceiros e serviços GCP que possam ter IDs e palavras-passe predefinidos, deve desativar ou alterá-los durante a configuração inicial do serviço.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

IM-7: Restringir o acesso a recursos com base nas condições

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
3.3, 6.4, 13.5 AC-2, AC-3, AC-6 7.2

Princípio de segurança: valide explicitamente os sinais fidedignos para permitir ou negar o acesso dos utilizadores aos recursos, como parte de um modelo de acesso de confiança zero. Os sinais a validar devem incluir uma autenticação forte da conta de utilizador, análise comportamental da conta de utilizador, fiabilidade do dispositivo, associação de utilizadores ou grupos, localizações e assim sucessivamente.

Orientação do Azure: utilize Azure AD acesso condicional para controlos de acesso mais granulares com base em condições definidas pelo utilizador, como exigir inícios de sessão de utilizadores de determinados intervalos de IP (ou dispositivos) para utilizar a MFA. Azure AD Acesso Condicional permite-lhe impor controlos de acesso nas aplicações da sua organização com base em determinadas condições.

Defina as condições e critérios aplicáveis para Azure AD acesso condicional na carga de trabalho. Considere os seguintes casos de utilização comuns:

  • Exigir a autenticação multifator para utilizadores com funções administrativas
  • Exigir a autenticação multifator para tarefas de gestão do Azure
  • Bloquear inícios de sessão para utilizadores que tentam utilizar protocolos de autenticação legados
  • Exigir localizações fidedignas para Azure AD registo de Multi-Factor Authentication
  • Bloquear ou conceder acesso a partir de localizações específicas
  • Bloquear comportamentos de início de sessão de risco
  • Exigir dispositivos geridos pela organização para aplicações específicas

Nota: os controlos de gestão de sessões de autenticação granular também podem ser implementados através de Azure AD política de acesso condicional, como a frequência de início de sessão e a sessão persistente do browser.

Implementação do Azure e contexto adicional:

Orientação do AWS: crie uma política de IAM e defina condições para controlos de acesso mais granulares com base em condições definidas pelo utilizador, como exigir inícios de sessão de utilizadores de determinados intervalos de IP (ou dispositivos) para utilizar a autenticação multifator. As definições de condição podem incluir condições individuais ou múltiplas, bem como lógicas.

As políticas podem ser definidas a partir de seis dimensões diferentes: políticas baseadas em identidade, políticas baseadas em recursos, limites de permissões, políticas de controlo de serviço (SCP) das Organizações do AWS, Listas de Controlo de Acesso (ACL) e políticas de sessão.

Implementação do AWS e contexto adicional:

Orientação do GCP: crie e defina Condições de IAM para controlos de acesso baseados em atributos mais granulares com base em condições definidas pelo utilizador, como exigir inícios de sessão de utilizadores de determinados intervalos de IP (ou dispositivos) para utilizar a autenticação multifator. As definições de condição podem incluir condições individuais ou múltiplas, bem como lógica.

As condições são especificadas nos enlaces de função da política de permissão de um recurso. Os atributos de condição baseiam-se no recurso pedido (por exemplo, o seu tipo ou nome) ou em detalhes sobre o pedido, por exemplo, o carimbo de data/hora ou o endereço IP de destino.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

IM-8: Restringir a exposição de credenciais e segredos

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
16.9, 16.12 IA-5 3.5, 6.3, 8.2

Princípio de segurança: certifique-se de que os programadores de aplicações processam credenciais e segredos de forma segura:

  • Evite incorporar as credenciais e os segredos nos ficheiros de código e configuração
  • Utilizar o cofre de chaves ou um serviço de arquivo de chaves seguro para armazenar as credenciais e os segredos
  • Procure credenciais no código fonte.

Nota: isto é geralmente regido e imposto através de um ciclo de vida de desenvolvimento de software seguro (SDLC) e processo de segurança de DevOps.

Orientação do Azure: ao utilizar uma identidade gerida não é uma opção, certifique-se de que os segredos e credenciais são armazenados em localizações seguras, como o Azure Key Vault, em vez de os incorporar nos ficheiros de código e configuração.

Se utilizar o Azure DevOps e o GitHub para a sua plataforma de gestão de código:

  • Implemente o Analisador de Credenciais do Azure DevOps para identificar as credenciais no código.
  • Para o GitHub, utilize a funcionalidade de análise de segredos nativos para identificar credenciais ou outra forma de segredos no código.

Os clientes, como Funções do Azure, serviços de Aplicações do Azure e VMs, podem utilizar identidades geridas para aceder ao Azure Key Vault de forma segura. Veja Controlos de Proteção de Dados relacionados com a utilização do Azure Key Vault para gestão de segredos.

Nota: o Azure Key Vault fornece rotação automática para serviços suportados. Para segredos que não podem ser rodados automaticamente, certifique-se de que são rodados manualmente periodicamente e removidos quando já não estiverem a ser utilizados.

Implementação do Azure e contexto adicional:

Orientação do AWS: ao utilizar uma função IAM para acesso à aplicação não é uma opção, certifique-se de que os segredos e credenciais são armazenados em localizações seguras, como o AWS Secret Manager ou o Arquivo de Parâmetros do Systems Manager, em vez de os incorporar nos ficheiros de código e configuração.

Utilize o Revisor de CodeGuru para a análise de código estático que pode detetar os segredos codificados no código fonte.

Se utilizar o Azure DevOps e o GitHub para a sua plataforma de gestão de código:

  • Implemente o Analisador de Credenciais do Azure DevOps para identificar as credenciais no código.
  • Para o GitHub, utilize a funcionalidade de análise de segredos nativos para identificar credenciais ou outras formas de segredos no código.

Nota: o Gestor de Segredos fornece rotação automática de segredos para serviços suportados. Para segredos que não podem ser rodados automaticamente, certifique-se de que são rodados manualmente periodicamente e removidos quando já não estiverem a ser utilizados.

Implementação do AWS e contexto adicional:

Orientação do GCP: ao utilizar uma conta de serviço gerida pela Google para acesso à aplicação não é uma opção, certifique-se de que os segredos e credenciais são armazenados em localizações seguras, como o Gestor de Segredos do Google Cloud, em vez de os incorporar nos ficheiros de código e configuração.

Utilize a extensão Google Cloud Code no IDE (ambiente de desenvolvimento integrado), como o Visual Studio Code, para integrar segredos geridos pelo Secret Manager no seu código.

Se utilizar o Azure DevOps ou o GitHub para a sua plataforma de gestão de código:

  • Implemente o Analisador de Credenciais do Azure DevOps para identificar as credenciais no código.
  • Para o GitHub, utilize a funcionalidade de análise de segredos nativos para identificar credenciais ou outras formas de segredos no código.

Nota: configure agendas de rotação para segredos armazenados no Gestor de Segredos como melhor prática.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

IM-9: Proteger o acesso do utilizador às aplicações existentes

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
6.7, 12.5 AC-2, AC-3, SC-11 N/D

Princípio de segurança: num ambiente híbrido, onde tem aplicações no local ou aplicações na cloud não nativas com autenticação legada, considere soluções como o mediador de segurança de acesso à cloud (CASB), o proxy de aplicações, o início de sessão único (SSO) para governar o acesso a estas aplicações para os seguintes benefícios:

  • Impor uma autenticação forte centralizada
  • Monitorizar e controlar atividades de utilizador final de risco
  • Monitorizar e remediar atividades de aplicações legadas de risco
  • Detetar e impedir a transmissão de dados confidenciais

Orientação do Azure: proteja as suas aplicações na cloud no local e não nativas através da autenticação legada ao ligá-las a:

  • Azure AD Proxy de Aplicações e configurar a autenticação baseada em cabeçalhos para permitir o acesso de início de sessão único (SSO) às aplicações para utilizadores remotos, ao mesmo tempo que valida explicitamente a fiabilidade dos utilizadores remotos e dos dispositivos com Azure AD Acesso Condicional. Se necessário, utilize uma solução de perímetro de Software-Defined (SDP) de terceiros que possa oferecer funcionalidades semelhantes.
  • Microsoft Defender for Cloud Apps, que serve um serviço de mediador de segurança de acesso à cloud (CASB) para monitorizar e bloquear o acesso dos utilizadores a aplicações SaaS de terceiros não aprovadas.
  • Os controladores e redes de entrega de aplicações de terceiros existentes.

Nota: as VPNs são normalmente utilizadas para aceder a aplicações legadas e, muitas vezes, têm apenas controlo de acesso básico e monitorização de sessão limitada.

Implementação do Azure e contexto adicional:

Orientação do AWS: siga as orientações do Azure para proteger as suas aplicações na cloud no local e não nativas através da autenticação legada ao ligá-las a:

  • Azure AD Proxy de Aplicações e configurar com base em cabeçalhos para permitir o acesso de início de sessão único (SSO) às aplicações para utilizadores remotos, ao mesmo tempo que valida explicitamente a fiabilidade de utilizadores e dispositivos remotos com o Acesso Condicional Azure AD. Se necessário, utilize uma solução de perímetro de Software-Defined (SDP) de terceiros que possa oferecer funcionalidades semelhantes.
  • Microsoft Defender for Cloud Apps, que serve como um serviço de mediador de segurança de acesso à cloud (CASB) para monitorizar e bloquear o acesso dos utilizadores a aplicações SaaS de terceiros não aprovadas.
  • Os controladores e redes de entrega de aplicações de terceiros existentes

Nota: as VPNs são normalmente utilizadas para aceder a aplicações legadas e, muitas vezes, têm apenas controlo de acesso básico e monitorização de sessão limitada.

Implementação do AWS e contexto adicional:

Orientação do GCP: utilize o Proxy do Google Cloud Identity-Aware (IAP) para gerir o acesso a aplicações baseadas em HTTP fora do Google Cloud, incluindo aplicações no local. O IAP funciona com cabeçalhos assinados ou a API de Utilizadores num ambiente padrão do Motor de Aplicações. Se necessário, utilize uma solução de perímetro de Software-Defined de terceiros (SDP), que pode oferecer funcionalidades semelhantes.

Também tem a opção de utilizar Microsoft Defender for Cloud Apps que serve como um serviço de mediador de segurança de acesso à cloud (CASB) para monitorizar e bloquear o acesso do utilizador a aplicações SaaS de terceiros não aprovadas.

Nota: as VPNs são normalmente utilizadas para aceder a aplicações legadas e, muitas vezes, têm apenas controlo de acesso básico e monitorização de sessão limitada.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):