Controle de Segurança: Gerenciamento de identidades
Artigo
O Gerenciamento de Identidades abrange controles para estabelecer controles de acesso e identidade segura usando sistemas de gerenciamento de identidade e acesso, incluindo o uso de logon único, autenticações fortes, identidades gerenciadas (e princípios de serviço) para aplicativos, acesso condicional e monitoramento de anomalias de conta.
IM-1: usar um sistema centralizado de identidade e autenticação
ID(s) do CIS Controls v8
ID(s) do NIST SP 800-53 r4
ID(s) do PCI-DSS v3.2.1
6.7, 12.5
AC-2, AC-3, IA-2, IA-8
7.2, 8.3
Princípio de segurança: use um sistema centralizado de identidade e autenticação para controlar as identidades e autenticações da sua organização para recursos de nuvem e não nuvem.
Diretrizes do Azure: o Azure Active Directory (Azure AD) é o serviço de gerenciamento de identidade e autenticação do Azure. Você deve padronizar o Azure AD para controlar a identidade e autenticação da sua organização:
Recursos de nuvem da Microsoft, como Armazenamento do Azure, Azure Máquinas Virtuais (Linux e Windows), aplicativos Azure Key Vault, PaaS e SaaS.
Os recursos da sua organização, como aplicativos no Azure, aplicativos de terceiros em execução em seus recursos de rede corporativa e aplicativos SaaS de terceiros.
Suas identidades corporativas no Active Directory pela sincronização ao Azure AD para garantir uma estratégia de identidade consistente e gerenciada centralmente.
Para os serviços do Azure que se aplicam, evite o uso de métodos de autenticação local e, em vez disso, use o Azure Active Directory para centralizar suas autenticações de serviço.
Observação: assim que for tecnicamente viável, você deve migrar aplicativos baseados no Active Directory local para o Azure AD. Isso pode ser um diretório corporativo do Azure AD, uma configuração entre empresas ou configuração entre empresa e consumidor.
Diretrizes da AWS: o AWS IAM (Gerenciamento de Identidades e Acesso) é o serviço de gerenciamento de autenticação e identidade padrão da AWS. Use o AWS IAM para controlar o gerenciamento de identidade e acesso da AWS. Como alternativa, por meio do AWS e do SSO (Sign-On Único) do Azure, você também pode usar Azure AD para gerenciar a identidade e o controle de acesso do AWS para evitar o gerenciamento de contas duplicadas separadamente em duas plataformas de nuvem.
A AWS dá suporte a Sign-On único que permite que você faça a ponte entre as identidades de terceiros da sua empresa (como o Windows Active Directory ou outros repositórios de identidade) com as identidades da AWS para evitar a criação de contas duplicadas para acessar recursos da AWS.
Diretrizes do GCP: o sistema IAM (Gerenciamento de Identidades e Acesso) do Google Cloud é o serviço padrão de gerenciamento de identidade e autenticação do Google Cloud usado para contas do Google Cloud Identity. Use o IAM do Google Cloud para controlar o gerenciamento de identidade e acesso do GCP. Como alternativa, por meio do Google Cloud Identity e do SSO (Azure Sigle Sign-On), você também pode usar Azure AD para gerenciar a identidade e o controle de acesso do GCP para evitar o gerenciamento de contas duplicadas separadamente em um ambiente mutli-cloud.
O Google Cloud Identity é o provedor de identidade para todos os serviços do Google. Ele dá suporte a Sign-On únicos que permitem que você faça a ponte entre as identidades de terceiros da sua empresa (como o Windows Active Directory ou outros repositórios de identidade) com identidades do Google Cloud para evitar a criação de contas duplicadas para acessar recursos do GCP.
Observação: usando a Sincronização de Diretórios do Google Cloud. O Google fornece uma ferramenta de conector que se integra à maioria dos sistemas de gerenciamento LDAP corporativos e sincroniza identidades em um agendamento. Ao configurar uma conta de Identidade de Nuvem e cantar o Google Cloud Directory Sync, você pode configurar qual de suas contas de usuário , incluindo usuários, grupos e perfis de usuário, aliases e muito mais , será sincronizada em um agendamento entre seu sistema de gerenciamento de identidade local e seu sistema GCP.
IM-2: proteger os sistemas de identidade e autenticação
ID(s) do CIS Controls v8
ID(s) do NIST SP 800-53 r4
ID(s) do PCI-DSS 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 seu sistema de identidade e autenticação como uma alta prioridade na prática de segurança de nuvem da sua organização. Controles de segurança comuns incluem:
Restringir funções e contas com privilégios
Exigir autenticação forte para todo o acesso privilegiado
Monitorar e auditar atividades de alto risco
Diretrizes do Azure: use a linha de base de segurança do Azure AD e o Azure AD Identity Secure Score para avaliar sua postura de segurança de identidade Azure AD e corrigir lacunas de segurança e configuração.
O Azure AD Identity Secure Score avalia Azure AD para as seguintes configurações:
Usar funções administrativas limitadas
Ativar a política de risco do usuário
Designar mais de um administrador global
Habilite a política para bloquear a autenticação herdada
Verifique se todos os usuários podem realizar a autenticação multifator para o acesso seguro
Exigir MFA para funções administrativas
Habilitar a redefinição de senha por autoatendimento
Não expirar senhas
Ativar política de risco de entrada
Não permitir que os usuários concedam consentimento a aplicativos não gerenciados
Use Azure AD Identity Protection para detectar, investigar e corrigir riscos baseados em identidade. Para proteger de forma semelhante seu domínio Active Directory local, use o Defender para Identidade.
Observação: siga as práticas recomendadas publicadas para todos os outros componentes de identidade, incluindo seus Active Directory local e quaisquer recursos de terceiros, bem como as infraestruturas (como sistemas operacionais, redes, bancos de dados) que os hospedam.
Diretrizes da AWS: use as seguintes práticas recomendadas de segurança para proteger seu AWS IAM:
Configurar chaves de acesso de usuário raiz da conta do AWS para acesso de emergência, conforme descrito em PA-5 (Configurar acesso de emergência)
Siga os princípios de privilégios mínimos para atribuições de acesso
Aproveite os grupos de IAM para aplicar políticas em vez de usuários individuais.
Siga as diretrizes de autenticação forte no IM-6 (usar controles de autenticação fortes) para todos os usuários
Usar scp de organizações do AWS (Política de Controle de Serviço) e limites de permissão
Usar o Assistente de Acesso do IAM para auditar o acesso ao serviço
Usar o relatório de credenciais do IAM para rastrear contas de usuário e credenciais status
Observação: siga as práticas recomendadas publicadas se você tiver outros sistemas de identidade e autenticação, por exemplo, siga a linha de base de segurança do Azure AD se usar Azure AD para gerenciar a identidade e o acesso da AWS.
Diretrizes do GCP: use as seguintes práticas recomendadas de segurança para proteger seus serviços IAM do Google Cloud e Identidade de Nuvem para suas organizações:
Configure uma conta de super administrador para acesso de emergência seguindo as recomendações em PA-5 ("Configurar acesso de emergência").
Crie um endereço de email de super administrador (como a conta de superdministrador do Google Workspace ou identidade de nuvem) e essa conta não deve ser específica para um usuário específico no caso de uma recuperação de emergência ser necessária.
Seguir privilégios mínimos e separação de princípios de tarefas
Evite usar a conta de super administrador para atividades diárias
Aproveite os grupos do Google Cloud Identity para aplicar políticas em vez de aplicar políticas a usuários individuais.
Siga as diretrizes de autenticação forte, conforme descrito em IM-6 ("Usar controles de autenticação forte") para todos os usuários que têm privilégios elevados.
Usar políticas de IAM para restringir o acesso aos recursos
Usar o Serviço de Política da Organização para controlar e configurar restrições em recursos
Usar o log de auditoria do IAM nos logs de Auditoria de Nuvem para examinar atividades privilegiadas
Observação: siga as práticas recomendadas publicadas se você tiver outros sistemas de identidade e autenticação, por exemplo, siga a linha de base de segurança Azure AD se usar Azure AD para gerenciar a identidade e o acesso do GCP.
IM-3: gerenciar identidades de aplicativos de maneira segura e automática
ID(s) do CIS Controls v8
ID(s) do NIST SP 800-53 r4
ID(s) do PCI-DSS v3.2.1
N/D
AC-2, AC-3, IA-4, IA-5, IA-9
N/D
Princípio de segurança: use identidades de aplicativo gerenciado em vez de criar contas humanas para aplicativos acessarem recursos e executarem código. Identidades de aplicativos gerenciados fornecem benefícios como a redução da exposição de credenciais. Automatize a rotação de credenciais para garantir a segurança das identidades.
Diretrizes do Azure: use identidades gerenciadas do Azure, que podem ser autenticadas nos serviços e recursos do Azure que dão suporte à autenticação Azure AD. As credenciais de identidades gerenciadas são completamente gerenciadas, giradas e protegidas pela plataforma, evitando credenciais codificadas no código-fonte ou arquivos de configuração.
Para serviços que não dão suporte a identidades gerenciadas, use o Azure AD para criar uma entidade de serviço com permissões restritas no nível de recurso. É recomendável configurar as entidades de serviço com credenciais de certificado e retornar para os segredos do cliente para autenticação.
Diretrizes da AWS: use funções IAM do AWS em vez de criar contas de usuário para recursos que dão suporte a esse recurso. As funções IAM são gerenciadas pela plataforma no back-end e as credenciais são temporárias e giradas automaticamente. Isso evita a criação de chaves de acesso de longo prazo ou um nome de usuário/senha para aplicativos e credenciais codificadas em código-fonte ou arquivos de configuração.
Você pode usar funções vinculadas ao serviço anexadas com políticas de permissão predefinidas para acesso entre serviços da AWS em vez de personalizar suas próprias permissões de função para as funções de IAM.
Observação: para serviços que não dão suporte a funções de IAM, use 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 suas chaves.
Diretrizes do GCP: use contas de serviço gerenciadas pelo Google em vez de criar contas gerenciadas pelo usuário para recursos que dão suporte a esse recurso. As contas de serviço gerenciadas pelo Google são gerenciadas pela plataforma no back-end e as chaves da conta de serviço são temporárias e giradas automaticamente. Isso evita a criação de chaves de acesso de longo prazo ou um nome de usuário/senha para aplicativos e credenciais de codificação embutidas em código em código-fonte ou arquivos de configuração.
Use o Policy Intelligence para entender e reconhecer atividades suspeitas para contas de serviço.
Princípio de segurança: autentique servidores e serviços remotos do lado do cliente para garantir que você esteja se conectando a servidores e serviços confiáveis. O protocolo de autenticação de servidor mais comum é o TLS, em que o lado do cliente (geralmente um navegador ou dispositivo cliente) verifica o servidor, verificando se o certificado do servidor foi emitido por uma autoridade de certificação confiável.
Observação: a autenticação mútua pode ser usada quando o servidor e o cliente se autenticam.
Diretrizes do Azure: muitos serviços do Azure dão suporte à autenticação TLS por padrão. Para serviços que não dão suporte à autenticação TLS por padrão ou dão suporte à desabilitação do TLS, verifique se ele está sempre habilitado para dar suporte à autenticação de servidor/cliente. Seu aplicativo cliente também deve ser projetado para verificar a identidade do servidor/cliente (verificando o certificado do servidor emitido por uma autoridade de certificação confiável) no estágio de handshake.
Observação: serviços como Gerenciamento de API e Gateway de API dão suporte à autenticação mútua TLS.
Diretrizes da AWS: muitos serviços da AWS dão suporte à autenticação TLS por padrão. Para serviços que não dão suporte à autenticação TLS por padrão ou dão suporte à desabilitação do TLS, verifique se ele está sempre habilitado para dar suporte à autenticação de servidor/cliente. Seu aplicativo cliente também deve ser projetado para verificar a identidade do servidor/cliente (verificando o certificado do servidor emitido por uma autoridade de certificação confiável) no estágio de handshake.
Observação: serviços como o Gateway de API dão suporte à autenticação mútua TLS.
Diretrizes do GCP: muitos serviços GCP dão suporte à autenticação TLS por padrão. Para serviços que não dão suporte a isso por padrão ou dão suporte à desabilitação do TLS, verifique se ele está sempre habilitado para dar suporte à autenticação de servidor/cliente. Seu aplicativo cliente também deve ser projetado para verificar a identidade do servidor/cliente (verificando o certificado do servidor emitido por uma autoridade de certificação confiável) no estágio de handshake.
Observação: serviços como o Balanceamento de Carga de Nuvem dão suporte à autenticação mútua TLS.
IM-5: usar o SSO (logon único) para acessar o aplicativo
ID(s) do CIS Controls v8
ID(s) do NIST SP 800-53 r4
ID(s) do PCI-DSS v3.2.1
12.5
IA-4, IA-2, IA-8
N/D
Princípio de segurança: use o SSO (logon único) para simplificar a experiência do usuário para autenticação em recursos, incluindo aplicativos e dados em serviços de nuvem e ambientes locais.
Diretrizes do Azure: use Azure AD para acesso de aplicativo de carga de trabalho (voltado para o cliente) por meio de Azure AD SSO (logon único), reduzindo a necessidade de contas duplicadas. Azure AD fornece gerenciamento de identidade e acesso aos recursos do Azure (no plano de gerenciamento, incluindo CLI, PowerShell, portal), aplicativos de nuvem e aplicativos locais.
Azure AD também dá suporte ao SSO para identidades corporativas, como identidades de usuário corporativo, bem como identidades de usuários externos de terceiros confiáveis e usuários públicos.
Diretrizes da AWS: use a AWS Cognito para gerenciar as cargas de trabalho de aplicativos voltados para o cliente por meio do SSO (logon único) para permitir que os clientes conectem suas identidades de terceiros de diferentes provedores de identidade.
Para acesso de SSO aos recursos nativos da AWS (incluindo acesso ao console do AWS ou gerenciamento de serviços e acesso ao nível do plano de dados), use o AWS Sigle Sign-On para reduzir a necessidade de contas duplicadas.
O SSO do AWS também permite que você faça a ponte entre identidades corporativas (como identidades do Azure Active Directory) com identidades da AWS, bem como identidades de usuários externos de usuários públicos e de terceiros confiáveis.
Diretrizes do GCP: use o Google Cloud Identity para gerenciar o acesso ao aplicativo de carga de trabalho voltado para o cliente por meio do Logon Único do Google Cloud Identity, reduzindo a necessidade de contas duplicadas. O Google Cloud Identity fornece gerenciamento de identidade e acesso ao GCP (no plano de gerenciamento, incluindo a CLI do Google Cloud, o acesso ao console), aplicativos de nuvem e aplicativos locais.
O Google Cloud Identity também dá suporte ao SSO para identidades corporativas, como identidades de usuário corporativo de Azure AD ou Active Directory, bem como identidades de usuários externos de usuários públicos e de terceiros confiáveis.
Implementação do GCP e contexto adicional:
Princípio de segurança: imponha controles de autenticação fortes (autenticação forte sem senha ou autenticação multifator) com seu sistema centralizado de gerenciamento de identidade e autenticação para todo o acesso aos recursos. A autenticação baseada apenas em credenciais de senha é considerada herdada, pois não é segura e não resiste aos métodos de ataque populares.
Ao implantar a autenticação forte, configure os administradores e os usuários privilegiados primeiro, para garantir o nível mais alto do método de autenticação forte, rapidamente seguido pela distribuição da política de autenticação forte apropriada para todos os usuários.
Observação: se a autenticação baseada em senha herdada for necessária para aplicativos e cenários herdados, verifique se são seguidas as melhores práticas de segurança de senha, como os requisitos de complexidade.
Diretrizes do Azure: Azure AD dá suporte a controles de autenticação fortes por meio de métodos sem senha e MFA (autenticação multifator).
Autenticação sem senha: use a autenticação sem senha como o método de autenticação padrão. Há três opções disponíveis na autenticação sem senha: Windows Hello para Empresas, entrada por telefone do aplicativo Microsoft Authenticator e chaves de segurança FIDO2. Além disso, os clientes podem usar métodos de autenticação locais, como os cartões inteligentes.
Autenticação multifator : uma MFA do Azure pode ser imposta a todos os usuários, a usuários selecionados ou no nível por usuário com base nas condições de entrada e nos fatores de risco. Habilite a MFA do Azure e siga Microsoft Defender para recomendações de gerenciamento de acesso e identidade de nuvem para sua configuração de MFA.
Se a autenticação baseada em senha herdada ainda for usada para autenticação do Azure AD, lembre-se de que as contas somente na nuvem (contas de usuário criadas diretamente no Azure) têm uma política de senha de linha de base padrão. E as contas híbridas (contas de usuário provenientes do Active Directory local) seguem as políticas de senha locais.
Para aplicativos de terceiros e serviços que podem ter senhas e IDs padrão, você deve desabilitá-las ou alterá-las durante a configuração inicial do serviço.
Diretrizes da AWS: o AWS IAM dá suporte a controles de autenticação fortes por meio da MFA (autenticação multifator). A MFA pode ser imposta a todos os usuários, selecionar usuários ou no nível por usuário com base em condições definidas.
Se você usar contas corporativas de um diretório de terceiros (como o Windows Active Directory) com identidades AWS, siga as respectivas diretrizes de segurança para impor uma autenticação forte. Consulte as Diretrizes do Azure para esse controle se você usar Azure AD para gerenciar o acesso à AWS.
Observação: para aplicativos de terceiros e serviços da AWS que podem ter IDs e senhas padrão, você deve desabilitá-los ou alterá-los durante a configuração inicial do serviço.
Diretrizes do GCP: o Google Cloud Identity dá suporte a controles de autenticação fortes por meio da MFA (autenticação multifator). A MFA pode ser imposta a todos os usuários, selecionar usuários ou no nível por usuário com base em condições definidas. Para proteger as contas de superdministradores do Cloud Identity (e workspace), considere usar chaves de segurança e o Programa de Proteção Avançada do Google para segurança máxima.
Se você usar contas corporativas de um diretório de terceiros (como o Windows Active Directory) com identidades do Google Cloud, siga as respectivas diretrizes de segurança para impor uma autenticação forte. Consulte as Diretrizes do Azure para esse controle se você usar Azure AD para gerenciar o acesso ao Google Cloud.
Use Identity-Aware Proxy para estabelecer uma camada de autorização central para aplicativos acessados por HTTPS, para que você possa usar um modelo de controle de acesso no nível do aplicativo em vez de depender de firewalls de nível de rede.
Observação: para aplicativos de terceiros e serviços GCP que podem ter IDs e senhas padrão, você deve desabilitá-los ou alterá-los durante a configuração inicial do serviço.
IM-7: restringir o acesso aos recursos com base nas condições
ID(s) do CIS Controls v8
ID(s) do NIST SP 800-53 r4
ID(s) do PCI-DSS v3.2.1
3.3, 6.4, 13.5
AC-2, AC-3, AC-6
7.2
Princípio de segurança: valide explicitamente sinais confiáveis para permitir ou negar o acesso do usuário aos recursos, como parte de um modelo de acesso de confiança zero. Os sinais para validar devem incluir autenticação forte da conta do usuário, análise comportamental da conta do usuário, confiabilidade do dispositivo, associação de usuário ou grupo, localizações e assim por diante.
Diretrizes do Azure: use Azure AD acesso condicional para controles de acesso mais granulares com base em condições definidas pelo usuário, como exigir que logons de usuário de determinados intervalos de IP (ou dispositivos) usem a MFA. O acesso condicional do Azure AD permite que você imponha controles de acesso aos aplicativos da sua organização de acordo com determinadas condições.
Defina as condições e os critérios aplicáveis para o acesso condicional do Azure AD na carga de trabalho. Considere os seguintes casos de uso comuns:
Exigir a autenticação multifator para usuários com funções administrativas
Exigir a autenticação multifator para tarefas de gerenciamento do Azure
Bloquear entradas de usuários que tentam usar protocolos de autenticação herdados
Exigir localizações confiáveis para o registro da Autenticação Multifator do Azure AD
Bloquear ou permitir acesso em localizações específicas
Bloquear comportamentos de entrada de risco
Exigir dispositivos gerenciados pela organização para aplicativos específicos
Observação: os controles de gerenciamento de sessão de autenticação granular também podem ser implementados por meio de Azure AD política de acesso condicional, como frequência de entrada e sessão persistente do navegador.
Diretrizes da AWS: crie uma política de IAM e defina condições para controles de acesso mais granulares com base em condições definidas pelo usuário, como exigir que logons de usuário de determinados intervalos de IP (ou dispositivos) usem a autenticação multifator. As configurações de condição podem incluir uma ou várias condições, bem como lógicas.
As políticas podem ser definidas de seis dimensões diferentes: políticas baseadas em identidade, políticas baseadas em recursos, limites de permissões, SCP (política de controle de serviço) das Organizações da AWS, ACL (listas de Controle de Acesso) e políticas de sessão.
Diretrizes do GCP: crie e defina condições de IAM para controles de acesso mais granulares baseados em atributos com base em condições definidas pelo usuário, como exigir que logons de usuário de determinados intervalos de IP (ou dispositivos) usem a autenticação multifator. As configurações de condição podem incluir uma ou várias condições, bem como lógica.
As condições são especificadas nas associações de função da política de permissão de um recurso. Os atributos de condição são baseados no recurso solicitado, por exemplo, seu tipo ou nome, ou em detalhes sobre a solicitação, por exemplo, seu carimbo de data/hora ou endereço IP de destino.
IM-8: restringir a exposição de credenciais e segredos
ID(s) do CIS Controls v8
ID(s) do NIST SP 800-53 r4
ID(s) do PCI-DSS v3.2.1
16.9, 16.12
IA-5
3.5, 6.3, 8.2
Princípio de segurança: verifique se os desenvolvedores de aplicativos lidam com credenciais e segredos com segurança:
Evitar inserir as credenciais e os segredos no código e nos arquivos de configuração
Usar o cofre de chaves ou um serviço de armazenamento de chaves seguro para armazenar as credenciais e os segredos
Verificar se há credenciais no código-fonte.
Observação: isso geralmente é controlado e imposto por meio de um processo de segurança do DevOps e do SDLC (ciclo de vida de desenvolvimento de software seguro).
Diretrizes do Azure: ao usar uma identidade gerenciada não é uma opção, verifique se os segredos e credenciais são armazenados em locais seguros, como o Azure Key Vault, em vez de inseri-los nos arquivos de código e configuração.
Se você usar o Azure DevOps e o GitHub para sua plataforma de gerenciamento de código:
Implemente o verificador de credenciais do Azure DevOps para identificar as credenciais no código.
Para o GitHub, use o recurso de verificação de segredo nativo para identificar as credenciais ou outra forma de segredos dentro do código.
Clientes como o Azure Functions, os serviços e VMs dos Aplicativos Azure podem usar identidades gerenciadas para acessar de forma segura o Azure Key Vault. Confira os controles de proteção de dados relacionados ao uso do Azure Key Vault para o gerenciamento de segredos.
Observação: o Azure Key Vault fornece rotação automática para serviços com suporte. Para segredos que não podem ser girados automaticamente, verifique se eles são girados manualmente periodicamente e limpos quando não estão mais em uso.
Diretrizes da AWS: ao usar uma função IAM para acesso ao aplicativo não é uma opção, verifique se os segredos e credenciais são armazenados em locais seguros, como o Gerenciador de Segredos do AWS ou o Repositório de Parâmetros do Gerenciador de Sistemas, em vez de inseri-los nos arquivos de código e configuração.
Use o CodeGuru Reviewer para análise de código estático que pode detectar os segredos embutidos em código no código-fonte.
Se você usar o Azure DevOps e o GitHub para sua plataforma de gerenciamento de código:
Implemente o verificador de credenciais do Azure DevOps para identificar as credenciais no código.
Para o GitHub, use o recurso de verificação de segredo nativo para identificar as credenciais ou outras formas de segredos dentro do código.
Observação: o Gerenciador de Segredos fornece rotação automática de segredos para serviços com suporte. Para segredos que não podem ser girados automaticamente, verifique se eles são girados manualmente periodicamente e limpos quando não estão mais em uso.
Diretrizes do GCP: ao usar uma conta de serviço gerenciada pelo Google para acesso ao aplicativo não é uma opção, verifique se os segredos e credenciais são armazenados em locais seguros, como o Gerenciador de Segredos do Google Cloud, em vez de inseri-los nos arquivos de código e configuração.
Use a extensão do Google Cloud Code no IDE (ambiente de desenvolvimento integrado), como Visual Studio Code para integrar segredos gerenciados pelo Gerenciador de Segredos ao seu código.
Se você usar o Azure DevOps ou o GitHub para sua plataforma de gerenciamento de código:
Implemente o verificador de credenciais do Azure DevOps para identificar as credenciais no código.
Para o GitHub, use o recurso de verificação de segredo nativo para identificar as credenciais ou outras formas de segredos dentro do código.
Observação: configure agendas de rotação para segredos armazenados no Gerenciador de Segredos como uma prática recomendada.
IM-9: acesso seguro do usuário aos aplicativos existentes
ID(s) do CIS Controls v8
ID(s) do NIST SP 800-53 r4
ID(s) do PCI-DSS v3.2.1
6.7, 12.5
AC-2, AC-3, SC-11
N/D
Princípio de segurança: em um ambiente híbrido, em que você tem aplicativos locais ou aplicativos de nuvem não nativos usando autenticação herdada, considere soluções como CASB (agente de segurança de acesso à nuvem), proxy de aplicativo, SSO (logon único) para controlar o acesso a esses aplicativos para obter os seguintes benefícios:
Impor uma autenticação forte centralizada
Monitorar e controlar atividades arriscadas de usuário final
Monitorar e corrigir atividades arriscadas de aplicativos herdados
Detectar e impedir a transmissão de dados confidenciais
Diretrizes do Azure: proteja seus aplicativos de nuvem locais e não nativos usando a autenticação herdada conectando-os a:
Azure AD Proxy de Aplicativo e configurar a autenticação baseada em cabeçalho para permitir o acesso de SSO (logon único) aos aplicativos para usuários remotos, ao mesmo tempo em que valida explicitamente a confiabilidade de usuários remotos e dispositivos com acesso condicional Azure AD. Se necessário, use uma solução de perímetro de Software-Defined (SDP) de terceiros que possa oferecer funcionalidade semelhante.
Microsoft Defender para Aplicativos de Nuvem, que atende a um serviço CASB (agente de segurança de acesso à nuvem) para monitorar e bloquear o acesso do usuário a aplicativos SaaS de terceiros não aprovados.
Seus controladores e redes de entrega de aplicativos de terceiros existentes.
Observação: as VPNs geralmente são usadas para acessar aplicativos herdados e geralmente têm apenas controle de acesso básico e monitoramento de sessão limitado.
Diretrizes da AWS: siga as diretrizes do Azure para proteger seus aplicativos de nuvem locais e não nativos usando a autenticação herdada conectando-os a:
Azure AD Proxy de Aplicativo e configurar com base em cabeçalho para permitir o acesso de SSO (logon único) aos aplicativos para usuários remotos, ao mesmo tempo em que valida explicitamente a confiabilidade de usuários remotos e dispositivos com acesso condicional Azure AD. Se necessário, use uma solução de perímetro de Software-Defined (SDP) de terceiros que possa oferecer funcionalidade semelhante.
Microsoft Defender para Aplicativos de Nuvem, que serve como um serviço CASB (agente de segurança de acesso à nuvem) para monitorar e bloquear o acesso do usuário a aplicativos SaaS de terceiros não aprovados.
Seus controladores e redes de entrega de aplicativos existentes de terceiros
Observação: as VPNs geralmente são usadas para acessar aplicativos herdados e geralmente têm apenas controle de acesso básico e monitoramento de sessão limitado.
Diretrizes do GCP: use o Google Cloud Identity-Aware Proxy (IAP) para gerenciar o acesso a aplicativos baseados em HTTP fora do Google Cloud, incluindo aplicativos locais. O IAP funciona usando cabeçalhos assinados ou a API de Usuários em um ambiente padrão do Mecanismo de Aplicativo. Se necessário, use a solução do SDP (perímetro definido pelo software) de terceiros, que pode oferecer funcionalidade semelhante.
Você também tem a opção de usar Microsoft Defender para Aplicativos de Nuvem que serve como um serviço CASB (agente de segurança de acesso à nuvem) para monitorar e bloquear o acesso do usuário a aplicativos SaaS de terceiros não aprovados.
Observação: as VPNs geralmente são usadas para acessar aplicativos herdados e geralmente têm apenas controle de acesso básico e monitoramento de sessão limitado.
En este módulo, se examinan las distintas características proporcionadas en el ecosistema de Microsoft 365 para proteger el acceso de los usuarios, como las directivas de acceso condicional, la autenticación multifactor, la administración de contraseñas de autoservicio, las directivas de bloqueo inteligente y los valores predeterminados de seguridad.
Muestre las características de Microsoft Entra ID para modernizar las soluciones de identidad, implementar soluciones híbridas e implementar la gobernanza de identidades.