Compartilhar via

Requisito 8 do Microsoft Entra ID e PCI-DSS

  • Artigo

Requisito 8: Identificar Usuários e Autenticar o Acesso aos Componentes do Sistema
Requisitos de abordagem definidos

8.1 Os processos e mecanismos para identificar usuários e autenticar o acesso aos componentes do sistema são definidos e compreendidos.

Requisitos de abordagem definidos por PCI-DSS Orientações e recomendações do Microsoft Entra
8.1.1 Todas as políticas de segurança e procedimentos operacionais identificados no Requisito 8 são:
Documentados
Mantidos atualizados
Em uso
Conhecidos por todas as partes afetadas		 Use as diretrizes e os links aqui contidos para produzir a documentação para atender aos requisitos com base na configuração do seu ambiente.
8.1.2 As funções e responsabilidades para a execução das atividades do Requisito 8 são documentadas, atribuídas e compreendidas. Use as diretrizes e os links aqui contidos para produzir a documentação para atender aos requisitos com base na configuração do seu ambiente.
Requisitos de abordagem definidos por PCI-DSS Orientações e recomendações do Microsoft Entra
8.2.1 Todos os usuários recebem uma ID exclusiva antes que o acesso aos componentes do sistema ou aos dados do titular do cartão seja permitido. Para aplicativos CDE que dependem do Microsoft Entra ID, a ID de usuário exclusiva é o atributo de nome principal do usuário (UPN). Preenchimento de UserPrincipalName do Microsoft Entra
8.2.2 Contas de grupo, compartilhadas ou genéricas, ou outras credenciais de autenticação compartilhada são usadas somente quando necessário em uma base de exceção e são gerenciadas da seguinte forma:
O uso da conta é impedido, a menos que seja necessário para uma circunstância excepcional.
O uso é limitado ao tempo necessário para a circunstância excepcional.
A justificativa comercial para uso é documentada.
O uso é explicitamente aprovado pela gerência
A identidade do usuário individual é confirmada antes que o acesso a uma conta seja concedido.
Cada ação tomada é atribuível a um usuário individual.		 Verifique se os CDEs que usam o Microsoft Entra ID para acesso ao aplicativo tenham processos para impedir contas compartilhadas. Crie-os como uma exceção que requer aprovação.
Para recursos CDE implantados no Azure, use identidades gerenciadas para recursos do Azure para representar a identidade da carga de trabalho, em vez de criar uma conta de serviço compartilhado. O que são identidades gerenciadas para recursos do Azure?
Se você não puder usar identidades gerenciadas e os recursos acessados estiverem usando o protocolo OAuth, use entidades de serviço para representar identidades de carga de trabalho. Conceda acesso com privilégios mínimos às identidades por meio de escopos OAuth. Os administradores podem restringir o acesso e definir fluxos de trabalho de aprovação para criá-los. O que são identidades de carga de trabalho?
8.2.3 Requisito adicional somente para prestadores de serviços: os prestadores de serviços com acesso remoto às instalações do cliente usam fatores de autenticação exclusivos para cada instalação do cliente. O Microsoft Entra ID tem conectores locais para habilitar recursos híbridos. Os conectores são identificáveis e usam credenciais geradas exclusivamente. Sincronização do Microsoft Entra Connect: Entender e personalizar a sincronização
Aprofundamento na sincronização na nuvem
Arquitetura de provisionamento de aplicativos locais do Microsoft Entra
Planejar o aplicativo de RH na nuvem para o provisionamento de usuários do Microsoft Entra
Instalar os agentes do Microsoft Entra Connect Health
8.2.4 Adição, exclusão e modificação de IDs de usuário, fatores de autenticação e outros objetos identificadores são gerenciados da seguinte forma:
Autorizado com a aprovação apropriada.
Implementado apenas com os privilégios especificados na aprovação documentada.		 O Microsoft Entra automatizou o provisionamento de contas de usuário de sistemas de RH. Use esse recurso para criar um ciclo de vida. O que é provisionamento controlado por RH?
O Microsoft Entra ID tem fluxos de trabalho de ciclo de vida para habilitar a lógica personalizada para processos de inclusão, movimentação e saída. O que são Fluxos de Trabalho do Ciclo de Vida?
O Microsoft Entra ID possui uma interface programática para gerenciar métodos de autenticação com o Microsoft Graph. Alguns métodos de autenticação, como o Windows Hello para Empresas e chaves FIDO2, exigem a intervenção do usuário para se registrar. Comece a usar a API de métodos de autenticação do Graph
Administradores e/ou automação gera a credencial de Senha de Acesso Temporária usando a API do Graph. Use essa credencial para integração sem senha. Configurar uma passagem de acesso temporária no Azure AD para registrar métodos de autenticação sem senha
8.2.5 O acesso de usuários encerrados foi revogado imediatamente. Para revogar o acesso a uma conta, desabilite as contas locais para contas híbridas sincronizadas do Microsoft Entra ID, desabilite as contas no Microsoft Entra ID e revogue os tokens. Revogar o acesso do usuário no Microsoft Entra ID
Use a Avaliação de Acesso Contínuo (CAE) para aplicativos compatíveis para ter uma conversa bidirecional com o Microsoft Entra ID. Os aplicativos podem ser notificados sobre eventos, como encerramento de conta e tokens rejeitados. Avaliação contínua de acesso
8.2.6 As contas de usuários inativos são removidas ou desabilitadas dentro de 90 dias de inatividade. Para contas híbridas, os administradores verificam a atividade no Active Directory e no Microsoft Entra ID a cada 90 dias. Para o Microsoft Entra ID, use o Microsoft Graph para localizar a última data de entrada. Tutorial: como gerenciar as contas de usuário inativas no Microsoft Entra ID
8.2.7 As contas utilizadas por terceiros para acesso, suporte ou manutenção de componentes do sistema via acesso remoto são gerenciadas da seguinte forma:
Habilitadas apenas durante o período de tempo necessário e desabilitadas quando não estiverem em uso.
O uso é monitorado para atividades inesperadas.		 O Microsoft Entra ID tem recursos externos de gerenciamento de identidade.
Use o ciclo de vida do convidado controlado com gerenciamento de direitos. Os usuários externos são integrados no contexto de aplicativos, recursos e pacotes de acesso, que você pode conceder por um período limitado e exigir revisões periódicas de acesso. As revisões podem resultar na remoção ou desabilitação da conta. Controle o acesso de usuários externos no gerenciamento de direitos
O Microsoft Entra ID gera eventos de risco no nível do usuário e da sessão. Saiba como proteger, detectar e responder a atividades inesperadas. O que é risco?
8.2.8 Se uma sessão do usuário estiver inativa por mais de 15 minutos, o usuário deverá se autenticar novamente para reativar o terminal ou a sessão. Use políticas de gerenciamento de ponto de extremidade com o Intune e o Gerenciamento de Ponto de Extremidade na Microsoft. Em seguida, use o Acesso Condicional para permitir o acesso de dispositivos compatíveis. Use as políticas de conformidade para definir regras para dispositivos gerenciados com o Intune
Se o seu ambiente CDE depender de objetos de política de grupo (GPO), configure o GPO para definir um tempo limite de ocioso. Configurar o Microsoft Entra ID para permitir o acesso de dispositivos ingressados de forma híbrida no Microsoft Entra. Dispositivos ingressados de forma híbrida no Microsoft Entra

8.3 A autenticação forte para usuários e administradores é estabelecida e gerenciada.

Para obter mais informações sobre os métodos de autenticação do Microsoft Entra que atendem aos requisitos do PCI, consulte: Suplemento de Informações: Autenticação Multifator.

Requisitos de abordagem definidos por PCI-DSS Orientações e recomendações do Microsoft Entra
8.3.1 Todo acesso do usuário aos componentes do sistema para usuários e administradores é autenticado por meio de pelo menos um dos seguintes fatores de autenticação:
Algo que você conhece, como uma senha ou frase secreta.
Algo que você possui, como um dispositivo de token ou cartão inteligente.
Características que você possui, como um elemento biométrico.		 O Microsoft Entra ID requer métodos sem senha para atender aos requisitos do PCI
Confira a implantação holística sem senha. Planejar uma implantação de autenticação sem senha no Microsoft Entra ID
8.3.2 A criptografia forte é usada para tornar todos os fatores de autenticação ilegíveis durante a transmissão e armazenamento em todos os componentes do sistema. A criptografia usada pelo Microsoft Entra ID é compatível com a Definição de Criptografia Forte do PCI. Considerações sobre a proteção de dados do Microsoft Entra
8.3.3 A identidade do usuário é verificada antes de modificar qualquer fator de autenticação. O Microsoft Entra ID exige que os usuários se autentiquem para atualizar seus métodos de autenticação usando autoatendimento, como o portal mysecurityinfo e o portal de redefinição de senha de autoatendimento (SSPR). Configurar as informações de segurança a partir de uma página de entrada
Política de Acesso Condicional comum: Proteção do registro de informações de segurança
Redefinição de senha self-service do Microsoft Entra
Os administradores com funções privilegiadas podem modificar os fatores de autenticação: Global, Senha, Usuário, Autenticação e Autenticação Privilegiada. Funções com privilégios mínimos por tarefa no Microsoft Entra ID. A Microsoft recomenda que você habilite o acesso e governança JIT, para acesso privilegiado usando o Microsoft Entra Privileged Identity Management
8.3.4 Tentativas de autenticação inválidas são limitadas por:
Bloquear a ID de usuário após não mais de 10 tentativas.
Definir a duração do bloqueio para um mínimo de 30 minutos ou até que a identidade do usuário seja confirmada.		 Implante o Windows Hello para Empresas em dispositivos Windows compatíveis com o hardware Trusted Platform Modules (TPM) 2.0 ou superior.
Para o Windows Hello para Empresas, o bloqueio está relacionado ao dispositivo. O gesto, PIN ou biometria desbloqueia o acesso ao TPM local. Os administradores configuram o comportamento de bloqueio com políticas de GPO ou do Intune. Configurações da Política de Grupo do TPM
Gerenciar o Windows Hello para Empresas em dispositivos no momento em que os dispositivos são registrados no Intune
Fundamentos do TPM
O Windows Hello para Empresas funciona para autenticação local no Active Directory e recursos de nuvem no Microsoft Entra ID.
Para chaves de segurança FIDO2, a proteção de força bruta está relacionada à chave. O gesto, PIN ou biometria, desbloqueia o acesso ao armazenamento de chaves local. Os administradores configuram o Microsoft Entra ID para permitir o registro de chaves de segurança FIDO2 de fabricantes que se alinham aos requisitos do PCI. Habilitar a entrada de chave de segurança sem senha

Aplicativo Microsoft Authenticator
Para mitigar os ataques de força bruta usando a entrada sem senha do aplicativo Microsoft Authenticator, habilite a correspondência de números e mais contexto.
O Microsoft Entra ID gera um número aleatório no fluxo de autenticação. O usuário o digita no aplicativo autenticador. O prompt de autenticação do aplicativo móvel mostra o local, o endereço IP da solicitação e o aplicativo da solicitação. Como usar a correspondência de números em notificações de MFA
Como usar o contexto adicional em notificações do Microsoft Authenticator
8.3.5 Se senhas/frases secretas forem usadas como fatores de autenticação para atender ao Requisito 8.3.1, elas serão definidas e redefinidas para cada usuário da seguinte forma:
Definidas como um valor exclusivo para uso pela primeira vez e após a redefinição.
Forçado a ser alterado imediatamente após o primeiro uso.		 Não aplicável ao Microsoft Entra ID.
8.3.6 Se senhas/senhas forem usadas como fatores de autenticação para atender ao Requisito 8.3.1, elas atenderão ao seguinte nível mínimo de complexidade:
Um comprimento mínimo de 12 caracteres (ou SE o sistema não suporta 12 caracteres, um comprimento mínimo de oito caracteres).
Conter caracteres numéricos e alfabéticos.		 Não aplicável ao Microsoft Entra ID.
8.3.7 As pessoas não têm permissão para enviar uma nova senha/frase secreta que seja igual a qualquer uma das últimas quatro senhas/frases secretas usadas. Não aplicável ao Microsoft Entra ID.
8.3.8 As políticas e procedimentos de autenticação são documentados e comunicados a todos os usuários, incluindo:
Diretrizes sobre a seleção de fatores de autenticação fortes.
Diretrizes sobre como os usuários devem proteger as credenciais de autenticação.
Instruções para não reutilizar senhas/frases secretas usadas anteriormente.
Instruções para alterar senhas/frases secretas se houver qualquer suspeita ou conhecimento de que as senhas/frases secretas foram comprometidas e como relatar o incidente.		 Documente políticas e procedimentos e comunique-se com os usuários de acordo com esse requisito. A Microsoft fornece modelos personalizáveis no Centro de Download.
8.3.9 Se senhas/frases secretas forem usadas como o único fator de autenticação para acesso do usuário (ou seja, em qualquer implementação de autenticação de fator único), então: as senhas/frases secretas são alteradas pelo menos uma vez a cada 90 dias,
OU
A postura de segurança das contas é analisada dinamicamente e o acesso em tempo real aos recursos é automaticamente determinado de acordo.		 Não aplicável ao Microsoft Entra ID.
8.3.10 Requisito adicional somente para provedores de serviços: se senhas/frases secretas forem usadas como o único fator de autenticação para o acesso do usuário do cliente aos dados do titular do cartão (ou seja, em qualquer implementação de autenticação de fator único), serão fornecidas orientações aos usuários do cliente, incluindo:
Diretrizes para que os clientes alterem suas senhas/frases secretas de usuário periodicamente.
Diretrizes sobre quando e sob quais circunstâncias as senhas/frases secretas devem ser alteradas.		 Não aplicável ao Microsoft Entra ID.
8.3.10.1 Requisito adicional apenas para provedores de serviço: se senhas/frases secretas forem usadas como o único fator de autenticação para acesso de usuário do cliente (ou seja, em qualquer implementação de autenticação de fator único), então:
As senhas/frases secretas são alteradas pelo menos uma vez a cada 90 dias,
OU
A postura de segurança das contas é analisada dinamicamente e o acesso em tempo real aos recursos é automaticamente determinado de acordo.		 Não aplicável ao Microsoft Entra ID.
8.3.11 Onde fatores de autenticação, como tokens de segurança físicos ou lógicos, cartões inteligentes ou certificados são usados:
Os fatores são atribuídos a um usuário individual e não compartilhados entre vários usuários.
Os controles físicos e/ou lógicos garantem que apenas o usuário pretendido possa usar esse fator para obter acesso.		 Use métodos de autenticação sem senha, como o Windows Hello para Empresas, chaves de segurança FIDO2 e o aplicativo Microsoft Authenticator para entrar no telefone. Use cartões inteligentes baseados em pares de chaves privadas ou públicas associadas aos usuários para evitar a reutilização.

8.4 A autenticação multifator (MFA) é implementada para proteger o acesso ao ambiente de dados do titular do cartão (CDE)

Requisitos de abordagem definidos por PCI-DSS Orientações e recomendações do Microsoft Entra
8.4.1 A MFA é implementada para todos os acessos fora do console ao CDE para funcionários com acesso administrativo. Use o Acesso Condicional para exigir autenticação forte para acessar recursos do CDE. Defina políticas para direcionar uma função administrativa ou um grupo de segurança que representa o acesso administrativo a um aplicativo.
Para acesso administrativo, use o Microsoft Entra Privileged Identity Management (PIM) para habilitar a habilitação just-in-time (JIT) de funções com privilégios. O que é Acesso Condicional?
Modelos de Acesso Condicional
Começar a usar o PIM
8.4.2 A MFA é implementada para todos os acessos ao CDE. Bloqueie o acesso a protocolos herdados que não dão suporte à autenticação forte. Bloquear a autenticação herdada com o Acesso Condicional do Microsoft Entra ID
8.4.3 A MFA é implementada para todo acesso remoto à rede originado de fora da rede da entidade que possa acessar ou impactar o CDE da seguinte forma:
Todo acesso remoto de todo o pessoal, usuários e administradores, originado de fora da rede da entidade.
Todo acesso remoto por terceiros e fornecedores.		 Integre tecnologias de acesso como rede privada virtual (VPN), área de trabalho remota e pontos de acesso de rede com o Microsoft Entra ID para autenticação e autorização. Use o Acesso Condicional para exigir autenticação forte para acessar aplicativos de acesso remoto. Modelos de acesso condicional

8.5 Os sistemas de autenticação multifator (MFA) são configurados para evitar uso indevido.

Requisitos de abordagem definidos por PCI-DSS Orientações e recomendações do Microsoft Entra
8.5.1 Os sistemas da MFA são implementados da seguinte forma:
O sistema da MFA não é suscetível a ataques de repetição.
Os sistemas da MFA não podem ser ignorados por nenhum usuário, incluindo usuários administrativos, a menos que seja especificamente documentado e autorizado pela gerência em caráter de exceção, por um período de tempo limitado.
Pelo menos dois tipos diferentes de fatores de autenticação são usados.
O sucesso de todos os fatores de autenticação é necessário antes que o acesso seja concedido.		 Os métodos de autenticação do Microsoft Entra recomendados usam nonce ou desafios. Esses métodos resistem a ataques de repetição porque o Microsoft Entra ID detecta transações de autenticação repetidas.
O aplicativo Windows Hello para Empresa, FIDO2 e Microsoft Authenticator para entrada no telefone sem senha usa um nonce para identificar a solicitação e detectar tentativas de repetição. Use credenciais sem senha para usuários no CDE.
A autenticação baseada em certificado usa desafios para detectar tentativas de repetição.
Nível 2 de garantia do autenticador NIST com o Microsoft Entra ID
Nível 3 de garantia do autenticador NIST usando o Microsoft Entra ID

8.6 O uso de contas de aplicativo e de sistema e fatores de autenticação associados é estritamente gerenciado.

Requisitos de abordagem definidos por PCI-DSS Orientações e recomendações do Microsoft Entra
8.6.1 Se as contas usadas por sistemas ou aplicativos puderem ser usadas para logon interativo, elas serão gerenciadas da seguinte forma:
O uso interativo é impedido, a menos que seja necessário em uma circunstância excepcional.
O uso interativo é limitado ao tempo necessário para a circunstância excepcional.
A justificativa comercial para uso interativo está documentada.
O uso interativo é explicitamente aprovado pelo gerenciamento.
A identidade do usuário individual é confirmada antes que o acesso à conta seja concedido.
Cada ação tomada é atribuível a um usuário individual.		 Para aplicativos CDE com autenticação moderna e para recursos do CDE implantados no Azure que usam autenticação moderna, o Microsoft Entra ID tem dois tipos de conta de serviço para aplicativos: identidades gerenciadas e entidades de serviço.
Saiba mais sobre a governança da conta de serviço do Microsoft Entra: planejamento, provisionamento, ciclo de vida, monitoramento, revisões de acesso, etc. Controle de contas de serviço do Microsoft Entra
Para proteger as contas de serviço do Microsoft Entra. Proteção de identidades gerenciadas no Microsoft Entra ID
Proteção de entidades de serviço no Microsoft Entra ID
Para CDEs com recursos fora do Azure que exigem acesso, configure as federações de identidade de carga de trabalho sem gerenciar segredos ou entrada interativa. Federação de identidade de carga de trabalho
Para permitir que processos de aprovação e rastreamento atendam aos requisitos, orquestre os fluxos de trabalho usando o ITSM (Gerenciamento de Serviços de TI) e CMDB (bancos de dados de gerenciamento de configuração). Essas ferramentas usam a API do MS Graph para interagir com o Microsoft Entra ID e gerenciar a conta de serviço.
Para CDEs que exigem contas de serviço compatíveis com o Active Directory local, use contas de serviço gerenciado de grupo (GMSAs) e contas de serviço gerenciado autônomas (sMSA), contas de computador ou contas de usuário. Protegendo contas de serviço locais
8.6.2 Senhas/frases secretas para qualquer aplicativo e contas do sistema que podem ser usadas para logon interativo não são codificadas em scripts, arquivos de configuração/propriedade ou código-fonte sob medida e personalizado. Use contas de serviço modernas, como identidades gerenciadas do Azure e entidades de serviço que não exigem senhas.
As credenciais de identidades gerenciadas do Microsoft Entra são provisionadas e rotacionadas na nuvem, o que impede o uso de segredos compartilhados, como senhas e frases secretas. Ao usar identidades gerenciadas atribuídas pelo sistema, o ciclo de vida é vinculado ao ciclo de vida do recurso subjacente do Azure.
Use entidades de serviço para usar certificados como credenciais, o que impede o uso de segredos compartilhados, como senhas e frases secretas. Se os certificados não forem viáveis, use o Azure Key Vault para armazenar os segredos do cliente da entidade de serviço. Melhores práticas para usar o Azure Key Vault
Para CDEs com recursos fora do Azure que exigem acesso, configure as federações de identidade de carga de trabalho sem gerenciar os segredos ou entrada interativa. Federação de identidade de carga de trabalho
Implante o Acesso Condicional para identidades de carga de trabalho para controlar a autorização com base no local e/ou nível de risco. Acesso condicional para identidades de carga de trabalho
Além das diretrizes anterior, use as ferramentas de análise de código para detectar segredos embutidos em código em arquivos de código e configuração. Detecte os segredos expostos em código
Regras de segurança
8.6.3 As senhas/frases secretas de qualquer aplicativo e contas do sistema são protegidas contra uso indevido da seguinte forma:
As senhas/frases secretas são alteradas periodicamente (na frequência definida na análise de risco direcionada da entidade, que é realizada de acordo com todos os elementos especificados no Requisito 12.3.1 ) e mediante suspeita ou confirmação de comprometimento.
As senhas/frases secretas são criadas com complexidade suficiente apropriada para a frequência com que a entidade altera as senhas/frases secretas.		 Use contas de serviço modernas, como identidades gerenciadas do Azure e entidades de serviço que não exigem senhas.
Para exceções que exigem entidades de serviço com segredos, abstraia o ciclo de vida secreto com fluxos de trabalho e automações que definem senhas aleatórias para entidades de serviço, as alternam regularmente e reagem a eventos de risco.
As equipes de operações de segurança podem revisar e corrigir os relatórios gerados pelo Microsoft Entra, como identidades de carga de trabalho arriscadas. Proteger as identidades de carga de trabalho com o Microsoft Entra ID Protection

Próximas etapas

Os requisitos 3, 4, 9 e 12 do PCI DSS não são aplicáveis ao Microsoft Entra ID e, portanto, não há artigos correspondentes. Para ver todos os requisitos, acesse pcisecuritystandards.org: Site oficial do Conselho de Padrões de Segurança do PCI.

Para configurar o Microsoft Entra ID em conformidade com o PCI-DSS, confira os artigos a seguir.