Microsoft Entra ID e PCI-DSS Requisito 8
Requisito 8: Identificar usuários e autenticar o acesso aos componentes
do sistema Requisitos de abordagem definidos
8.1 São definidos e compreendidos processos e mecanismos para identificar utilizadores e autenticar o acesso aos componentes do sistema.
Requisitos de abordagem definidos pelo 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: Documentado Mantido atualizado Em uso Conhecido por todas as partes afetadas |
Use as orientações 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 realização de atividades no Requisito 8 são documentadas, atribuídas e compreendidas. | Use as orientações e os links aqui contidos para produzir a documentação para atender aos requisitos com base na configuração do seu ambiente. |
8.2 A identificação do utilizador e as contas relacionadas para utilizadores e administradores são rigorosamente geridas ao longo do ciclo de vida de uma conta.
Requisitos de abordagem definidos pelo PCI-DSS | Orientações e recomendações do Microsoft Entra |
---|---|
8.2.1 A todos os utilizadores é atribuído um ID único antes de ser permitido o acesso aos componentes do sistema ou aos dados do titular do cartão. | Para aplicativos CDE que dependem do Microsoft Entra ID, o ID de usuário exclusivo é o atributo UPN (nome principal do usuário). População do Microsoft Entra UserPrincipalName |
8.2.2 Contas de grupo, compartilhadas ou genéricas, ou outras credenciais de autenticação compartilhadas são usadas apenas quando necessário, em caráter 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 excecional. O uso é limitado ao tempo necessário para a circunstância excecional. A justificação comercial para a utilização está documentada. O uso é explicitamente aprovado pela gerência A identidade individual do usuário é confirmada antes que o acesso a uma conta seja concedido. Cada ação realizada é atribuível a um usuário individual. |
Certifique-se de que 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 geridas 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 às identidades acesso menos privilegiado 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 apenas para prestadores de serviços: Os prestadores de serviços com acesso remoto às instalações do cliente utilizam 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. Microsoft Entra Connect Sync: Compreender e personalizar a sincronização Aprofundamento da 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 A 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 ID automatizou o provisionamento de contas de usuário de sistemas de RH. Use esse recurso para criar um ciclo de vida. O que é o provisionamento orientado por RH? O Microsoft Entra ID tem fluxos de trabalho de ciclo de vida para habilitar a lógica personalizada para processos de marceneiro, movimentação e saída. O que são fluxos de trabalho do ciclo de vida? O Microsoft Entra ID tem 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 for Business e as chaves FIDO2, exigem a intervenção do usuário para se registrar. Introdução aos métodos de autenticação do Graph Os administradores de API e/ou a automação geram a credencial do Passe de Acesso Temporário usando a API do Graph. Use esta credencial para integração sem senha. Configurar um Passe de Acesso Temporário na ID do Microsoft Entra para registrar métodos de autenticação sem senha |
8.2.5 O acesso dos utilizadores terminados é imediatamente revogado. | Para revogar o acesso a uma conta, desative contas locais para contas híbridas sincronizadas a partir da ID do Microsoft Entra, desative contas na ID do Microsoft Entra e revogue 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 de rejeição. Avaliação contínua do acesso |
8.2.6 As contas de utilizador inativas são removidas ou desativadas no prazo de 90 dias após a inatividade. | Para contas híbridas, os administradores verificam a atividade no Ative Directory e no Microsoft Entra a cada 90 dias. Para Microsoft Entra ID, use o Microsoft Graph para localizar a última data de entrada. Como: Gerenciar contas de usuário inativas no Microsoft Entra ID |
8.2.7 As contas utilizadas por terceiros para aceder, suportar ou manter componentes do sistema através de acesso remoto são geridas da seguinte forma: Ativado apenas durante o período de tempo necessário e desativado quando não está a ser utilizado. O uso é monitorado para atividades inesperadas. |
O Microsoft Entra ID tem recursos externos de gerenciamento de identidade. Use o ciclo de vida do hóspede 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 avaliações podem resultar na remoção ou desativação da conta. Controlar 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. Aprenda a proteger, detetar e responder a atividades inesperadas. O que é o risco? |
8.2.8 Se uma sessão de usuário estiver ociosa 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 pontos finais com o Intune e o Microsoft Endpoint Manager. Em seguida, use o Acesso Condicional para permitir o acesso de dispositivos compatíveis. Usar políticas de conformidade para definir regras para dispositivos que você gerencia com o Intune Se seu ambiente CDE depender de objetos de política de grupo (GPO), configure o GPO para definir um tempo limite ocioso. Configure a ID do Microsoft Entra para permitir o acesso a partir de dispositivos associados híbridos do Microsoft Entra. Microsoft Entra dispositivos híbridos associados |
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 de PCI, consulte: Suplemento de informações: autenticação multifator.
Requisitos de abordagem definidos pelo PCI-DSS | Orientações e recomendações do Microsoft Entra |
---|---|
8.3.1 Todo o 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ê sabe, como uma senha ou frase secreta. Algo que você tem, como um dispositivo de token ou cartão inteligente. Algo que você é, como um elemento biométrico. |
O Microsoft Entra ID requer métodos sem senha para atender aos requisitos PCI Consulte 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 o armazenamento em todos os componentes do sistema. | A criptografia usada pelo Microsoft Entra ID é compatível com a definição PCI de Criptografia Forte. Considerações sobre 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 o autoatendimento, como o portal mysecurityinfo e o portal de redefinição de senha de autoatendimento (SSPR). Configurar informações de segurança a partir de uma página de início de sessão Política comum de Acesso Condicional: Protegendo o registro de informações de segurança Redefinição de senha de autoatendimento 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 menos privilegiadas por tarefa no Microsoft Entra ID. A Microsoft recomenda que você habilite o acesso e a governança JIT para acesso privilegiado usando o Microsoft Entra Privileged Identity Management |
8.3.4 As tentativas de autenticação inválidas são limitadas por: Bloquear o ID de utilizador 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 for Business para dispositivos Windows que ofereçam suporte a hardware Trusted Platform Modules (TPM) 2.0 ou superior. Para o Windows Hello for Business, 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 Intune. Configurações da Política de Grupo do TPM Gerenciar o Windows Hello for Business em dispositivos no momento em que os dispositivos se registram com o Intune Fundamentos do TPM O Windows Hello for Business funciona para autenticação local no Ative 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 PCI. Habilite o login sem chave de segurança sem senha Aplicativo Microsoft Authenticator Para mitigar ataques de força bruta usando o aplicativo Microsoft Authenticator, login sem senha, 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 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 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: Defina como um valor exclusivo para uso pela primeira vez e após a redefinição. Forçado a ser mudado imediatamente após o primeiro uso. |
Não aplicável ao Microsoft Entra ID. |
8.3.6 Se senhas/frases secretas forem usadas como fatores de autenticação para atender ao Requisito 8.3.1, elas atendem ao seguinte nível mínimo de complexidade: Um comprimento mínimo de 12 caracteres (ou SE o sistema não suportar 12 caracteres, um comprimento mínimo de oito caracteres). Contêm caracteres numéricos e alfabéticos. |
Não aplicável ao Microsoft Entra ID. |
8.3.7 Os indivíduos não podem 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 utilizadores, incluindo: Orientações sobre a seleção de fatores de autenticação forte. Orientações sobre como os utilizadores devem proteger os seus fatores de autenticação. Instruções para não reutilizar palavras-passe/frases secretas utilizadas anteriormente. Instruções para alterar palavras-passe/frases secretas se houver qualquer suspeita ou conhecimento de que a palavra-passe/frases secretas foram comprometidas e como comunicar o incidente. |
Documente políticas e procedimentos e, em seguida, comunique aos 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 é determinado automaticamente de acordo. |
Não aplicável ao Microsoft Entra ID. |
8.3.10 Requisito adicional apenas para prestadores de serviços: Se as palavras-passe/frases secretas forem utilizadas como o único fator de autenticação para o acesso do utilizador do cliente aos dados do titular do cartão (ou seja, em qualquer implementação de autenticação de fator único), são fornecidas orientações aos utilizadores do cliente, incluindo: Orientação para os clientes alterarem as suas palavras-passe/frases secretas periodicamente. Orientação sobre quando, e em que 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ços: 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 é determinado automaticamente de acordo. |
Não aplicável ao Microsoft Entra ID. |
8.3.11 Quando são utilizados fatores de autenticação, tais como tokens de segurança físicos ou lógicos, cartões inteligentes ou certificados: Os fatores são atribuídos a um utilizador individual e não partilhados entre vários utilizadores. 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 for Business, chaves de segurança FIDO2 e o aplicativo Microsoft Authenticator para entrar no telefone. Use cartões inteligentes baseados em pares de chaves públicas ou privadas 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 pelo PCI-DSS | Orientações e recomendações do Microsoft Entra |
---|---|
8.4.1 O MFA é implementado para todos os acessos que não sejam de console ao CDE para pessoal com acesso administrativo. | Use o Acesso Condicional para exigir autenticação forte para acessar recursos CDE. Defina políticas para direcionar uma função administrativa ou um grupo de segurança que represente o acesso administrativo a um aplicativo. Para acesso administrativo, use o Microsoft Entra Privileged Identity Management (PIM) para habilitar a ativação just-in-time (JIT) de funções privilegiadas. O que é Acesso Condicional? Modelos de acesso condicional Comece a usar o PIM |
8.4.2 A AMF é implementada para todos os acessos ao CDE. | Bloqueie o acesso a protocolos herdados que não suportam autenticação forte. Bloquear a autenticação legada com o Microsoft Entra ID com o Acesso Condicional |
8.4.3 A MFA é implementada para todo o acesso remoto à rede proveniente de fora da rede da entidade que possa aceder ou afetar o CDE da seguinte forma: Todo o acesso remoto por todo o pessoal, tanto utilizadores como administradores, proveniente de fora da rede da entidade. Todo o acesso remoto por terceiros e fornecedores. |
Integre tecnologias de acesso como rede virtual privada (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 pelo PCI-DSS | Orientações e recomendações do Microsoft Entra |
---|---|
8.5.1 Os sistemas de MFA são implementados da seguinte forma: O sistema de MFA não é suscetível a ataques de replay. Os sistemas de MFA não podem ser ignorados por nenhum usuário, incluindo usuários administrativos, a menos que especificamente documentados e autorizados pela gerência em uma base 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 recomendados do Microsoft Entra usam nonce ou challenges. Esses métodos resistem a ataques de repetição porque o Microsoft Entra ID deteta transações de autenticação repetidas. Os aplicativos Windows Hello for Business, FIDO2 e Microsoft Authenticator para entrada por telefone sem senha usam um nonce para identificar a solicitação e detetar tentativas de repetição. Use credenciais sem senha para usuários no CDE. A autenticação baseada em certificado usa desafios para detetar tentativas de repetição. Garantia do autenticador NIST nível 2 com ID do Microsoft Entra Garantia do autenticador NIST nível 3 usando o Microsoft Entra ID |
8.6 O uso de contas de aplicativos e sistemas e fatores de autenticação associados é rigorosamente gerenciado.
Requisitos de abordagem definidos pelo 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 login interativo, elas serão gerenciadas da seguinte forma: O uso interativo é impedido, a menos que seja necessário por uma circunstância excecional. O uso interativo é limitado ao tempo necessário para a circunstância excecional. A justificação comercial para a utilização interativa está documentada. O uso interativo é explicitamente aprovado pela gerência. A identidade individual do usuário é confirmada antes que o acesso à conta seja concedido. Cada ação realizada é atribuível a um usuário individual. |
Para aplicativos CDE com autenticação moderna e para recursos 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 Microsoft Entra: planejamento, provisionamento, ciclo de vida, monitoramento, revisões de acesso, etc. Governando as contas de serviço do Microsoft Entra Para proteger as contas de serviço do Microsoft Entra. Protegendo identidades gerenciadas no Microsoft Entra ID Protegendo entidades de serviço no Microsoft Entra ID Para CDEs com recursos fora do Azure que exigem acesso, configure federações de identidade de carga de trabalho sem gerenciar segredos ou entrada interativa. Federação de identidades de carga de trabalho Para permitir que os processos de aprovação e acompanhamento atendam aos requisitos, orquestre fluxos de trabalho usando o Gerenciamento de Serviços de TI (ITSM) e os bancos de dados de gerenciamento de configuração (CMDB) Essas ferramentas usam a API do MS Graph para interagir com o ID do Microsoft Entra e gerenciar a conta de serviço. Para CDEs que exigem contas de serviço compatíveis com o Ative 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 As senhas/frases secretas de qualquer aplicativo e conta do sistema que possam ser usadas para login interativo não são codificadas em scripts, arquivos de configuração/propriedade ou código-fonte personalizado 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 giradas na nuvem, o que impede o uso de segredos compartilhados, como senhas e senhas. 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 senhas. Se os certificados não forem viáveis, use o Azure Key Vault para armazenar segredos do cliente principal do serviço. Práticas recomendadas para usar o Cofre da Chave do Azure Para CDEs com recursos fora do Azure que exigem acesso, configure federações de identidade de carga de trabalho sem gerenciar segredos ou entrada interativa. Federação de identidades 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 orientações anteriores, use ferramentas de análise de código para detetar segredos codificados em arquivos de código e configuração. Detetar segredos expostos no código Regras de segurança |
8.6.3 As senhas/frases secretas para qualquer aplicativo e conta 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 construídas com complexidade suficiente apropriada para a frequência com que a entidade altera as senhas/senhas. |
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 define senhas aleatórias para entidades de serviço, gira-as regularmente e reage a eventos de risco. As equipes de operações de segurança podem revisar e corrigir relatórios gerados pelo Microsoft Entra, como identidades de carga de trabalho arriscadas. Protegendo identidades de carga de trabalho com o Microsoft Entra ID Protection |
Próximos passos
Os requisitos 3, 4, 9 e 12 do PCI-DSS não são aplicáveis ao Microsoft Entra ID, portanto, não há artigos correspondentes. Para ver todos os requisitos, acesse pcisecuritystandards.org: Site Oficial do PCI Security Standards Council.
Para configurar o Microsoft Entra ID para estar em conformidade com PCI-DSS, consulte os seguintes artigos.
- Orientação do Microsoft Entra PCI-DSS
- Requisito 1: Instalar e manter controles de segurança de rede
- Requisito 2: Aplicar configurações seguras a todos os componentes do sistema
- Requisito 5: Proteger todos os sistemas e redes contra software mal-intencionado
- Requisito 6: Desenvolver e manter sistemas e software seguros
- Requisito 7: Restringir o acesso aos componentes do sistema e aos dados do titular do cartão por necessidade de conhecimento da empresa
- Requisito 8: Identificar usuários e autenticar o acesso aos componentes do sistema (Você está aqui)
- Requisito 10: Registar e monitorizar todo o acesso aos componentes do sistema e aos dados do titular do cartão
- Requisito 11: Testar regularmente a segurança dos sistemas e redes
- Orientação de autenticação multifator PCI-DSS do Microsoft Entra