Microsoft Entra ID e PCI-DSS Requisito 10
Requisito 10: Registrar e monitorar todo o acesso aos componentes do sistema e aos dados
do titular do cartão Requisitos de abordagem definidos
10.1 São definidos e documentados processos e mecanismos de registo e monitorização de todos os acessos aos componentes do sistema e aos dados do titular do cartão.
| Requisitos de abordagem definidos pelo PCI-DSS | Orientações e recomendações do Microsoft Entra |
|---|---|
| 10.1.1 Todas as políticas de segurança e procedimentos operacionais identificados no Requisito 10 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. |
| 10.1.2 As funções e responsabilidades para a realização de atividades no Requisito 10 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. |
10.2 Os registos de auditoria são implementados para apoiar a deteção de anomalias e atividades suspeitas, bem como a análise forense de eventos.
| Requisitos de abordagem definidos pelo PCI-DSS | Orientações e recomendações do Microsoft Entra |
|---|---|
| 10.2.1 Os logs de auditoria estão ativados e ativos para todos os componentes do sistema e dados do titular do cartão. | Arquive os logs de auditoria do Microsoft Entra para obter alterações nas políticas de segurança e na configuração do locatário do Microsoft Entra. Arquive os logs de atividade do Microsoft Entra em um sistema de gerenciamento de eventos e informações de segurança (SIEM) para saber mais sobre o uso. Logs de atividade do Microsoft Entra no Azure Monitor |
| 10.2.1.1 Os logs de auditoria capturam todo o acesso individual do usuário aos dados do titular do cartão. | Não aplicável ao Microsoft Entra ID. |
| 10.2.1.2 Os logs de auditoria capturam todas as ações realizadas por qualquer indivíduo com acesso administrativo, incluindo qualquer uso interativo de contas de aplicativos ou sistemas. | Não aplicável ao Microsoft Entra ID. |
| 10.2.1.3 Os logs de auditoria capturam todo o acesso aos logs de auditoria. | No Microsoft Entra ID, não é possível apagar ou modificar logs. Os utilizadores privilegiados podem consultar os registos a partir do Microsoft Entra ID. Funções menos privilegiadas por tarefa no Microsoft Entra ID Quando os logs de auditoria são exportados para sistemas como o Espaço de Trabalho do Azure Log Analytics, contas de armazenamento ou sistemas SIEM de terceiros, monitore-os para acesso. |
| 10.2.1.4 Os logs de auditoria capturam todas as tentativas de acesso lógico inválidas. | O Microsoft Entra ID gera logs de atividade quando um usuário tenta entrar com credenciais inválidas. Ele gera logs de atividade quando o acesso é negado devido a políticas de Acesso Condicional. |
| 10.2.1.5 Os logs de auditoria capturam todas as alterações nas credenciais de identificação e autenticação, incluindo, entre outras: Criação de novas contas Elevação de privilégios Todas as alterações, adições ou exclusões de contas com acesso administrativo |
O Microsoft Entra ID gera logs de auditoria para os eventos neste requisito. |
| 10.2.1.6 Os logs de auditoria capturam o seguinte: Toda a inicialização de novos logs de auditoria e Todos iniciando, parando ou pausando os logs de auditoria existentes. |
Não aplicável ao Microsoft Entra ID. |
| 10.2.1.7 Os logs de auditoria capturam toda a criação e exclusão de objetos no nível do sistema. | O Microsoft Entra ID gera logs de auditoria para eventos nesse requisito. |
| 10.2.2 Os logs de auditoria registram os seguintes detalhes para cada evento auditável: Identificação do usuário. Tipo de evento. Data e hora. Indicação de sucesso e fracasso. Origem do evento. Identidade ou nome dos dados afetados, componente do sistema, recurso ou serviço (por exemplo, nome e protocolo). |
Consulte Logs de auditoria no ID do Microsoft Entra |
10.3 Os logs de auditoria são protegidos contra destruição e modificações não autorizadas.
| Requisitos de abordagem definidos pelo PCI-DSS | Orientações e recomendações do Microsoft Entra |
|---|---|
| 10.3.1 O acesso de leitura aos arquivos de logs de auditoria é limitado àqueles com uma necessidade relacionada ao trabalho. | Os utilizadores privilegiados podem consultar os registos a partir do Microsoft Entra ID. Funções com menos privilégios por função no Microsoft Entra ID |
| 10.3.2 Os arquivos de log de auditoria são protegidos para evitar modificações por indivíduos. | No Microsoft Entra ID, não é possível apagar ou modificar logs. Quando os logs de auditoria são exportados para sistemas como o Espaço de Trabalho do Azure Log Analytics, contas de armazenamento ou sistemas SIEM de terceiros, monitore-os para acesso. |
| 10.3.3 Os arquivos de log de auditoria, incluindo aqueles para tecnologias externas, são prontamente copiados para um servidor de log interno, central e seguro ou outra mídia difícil de modificar. | No Microsoft Entra ID, não é possível apagar ou modificar logs. Quando os logs de auditoria são exportados para sistemas como o Espaço de Trabalho do Azure Log Analytics, contas de armazenamento ou sistemas SIEM de terceiros, monitore-os para acesso. |
| 10.3.4 O monitoramento da integridade de arquivos ou mecanismos de deteção de alterações é usado em logs de auditoria para garantir que os dados de log existentes não possam ser alterados sem gerar alertas. | No Microsoft Entra ID, não é possível apagar ou modificar logs. Quando os logs de auditoria são exportados para sistemas como o Espaço de Trabalho do Azure Log Analytics, contas de armazenamento ou sistemas SIEM de terceiros, monitore-os para acesso. |
10.4 Os logs de auditoria são revisados para identificar anomalias ou atividades suspeitas.
| Requisitos de abordagem definidos pelo PCI-DSS | Orientações e recomendações do Microsoft Entra |
|---|---|
| 10.4.1 Os seguintes logs de auditoria são revisados pelo menos uma vez por dia: Todos os eventos de segurança. Logs de todos os componentes do sistema que armazenam, processam ou transmitem dados do titular do cartão (CHD) e/ou dados de autenticação confidenciais (SAD). Logs de todos os componentes críticos do sistema. Registos de todos os servidores e componentes do sistema que executam funções de segurança (por exemplo, controlos de segurança de rede, sistemas de deteção de intrusão/sistemas de prevenção de intrusões (IDS/IPS), servidores de autenticação). |
Inclua logs do Microsoft Entra neste processo. |
| 10.4.1.1 Mecanismos automatizados são usados para realizar revisões de log de auditoria. | Inclua logs do Microsoft Entra neste processo. Configure ações automatizadas e alertas quando os logs do Microsoft Entra forem integrados ao Azure Monitor. Implantar o Azure Monitor: alertas e ações automatizadas |
| 10.4.2 Os logs de todos os outros componentes do sistema (aqueles não especificados no Requisito 10.4.1) são revisados periodicamente. | Não aplicável ao Microsoft Entra ID. |
| 10.4.2.1 A frequência das revisões periódicas dos registos para todos os outros componentes do sistema (não definidas no requisito 10.4.1) é definida na análise de risco específica da entidade, que é realizada de acordo com todos os elementos especificados no requisito 12.3.1 | Não aplicável ao Microsoft Entra ID. |
| 10.4.3 São abordadas as exceções e anomalias identificadas durante o processo de revisão. | Não aplicável ao Microsoft Entra ID. |
10.5 O histórico do log de auditoria é mantido e está disponível para análise.
| Requisitos de abordagem definidos pelo PCI-DSS | Orientações e recomendações do Microsoft Entra |
|---|---|
| 10.5.1 Manter o histórico do log de auditoria por pelo menos 12 meses, com pelo menos os três meses mais recentes imediatamente disponíveis para análise. | Integre com o Azure Monitor e exporte os logs para arquivamento de longo prazo. Integrar logs do Microsoft Entra com logs do Azure Monitor Saiba mais sobre a política de retenção de dados de logs do Microsoft Entra. Retenção de dados do Microsoft Entra |
10.6 Os mecanismos de sincronização de tempo suportam configurações de tempo consistentes em todos os sistemas.
| Requisitos de abordagem definidos pelo PCI-DSS | Orientações e recomendações do Microsoft Entra |
|---|---|
| 10.6.1 Os relógios e a hora do sistema são sincronizados usando a tecnologia de sincronização de tempo. | Saiba mais sobre o mecanismo de sincronização de tempo nos serviços do Azure. Sincronização de tempo para serviços financeiros no Azure |
| 10.6.2 Os sistemas são configurados para o tempo correto e consistente da seguinte forma: Um ou mais servidores de tempo designados estão em uso. Apenas o(s) servidor(es) central(is) de hora designado(s) recebe(m) tempo de fontes externas. O tempo recebido de fontes externas baseia-se no Tempo Atómico Internacional ou no Tempo Universal Coordenado (UTC). O(s) servidor(es) de hora designado(s) aceita(m) atualizações de tempo somente de fontes externas específicas aceitas pelo setor. Quando há mais de um servidor de tempo designado, os servidores de tempo se igualam uns aos outros para manter o tempo preciso. Os sistemas internos recebem informações de tempo apenas do(s) servidor(es) de hora central designado(s). |
Saiba mais sobre o mecanismo de sincronização de tempo nos serviços do Azure. Sincronização de tempo para serviços financeiros no Azure |
| 10.6.3 As configurações de sincronização de tempo e os dados são protegidos da seguinte forma: O acesso aos dados de tempo é restrito apenas ao pessoal com uma necessidade comercial. Quaisquer alterações nas configurações de tempo em sistemas críticos são registradas, monitoradas e revisadas. |
O Microsoft Entra ID depende de mecanismos de sincronização de tempo no Azure. Os procedimentos do Azure sincronizam servidores e dispositivos de rede com servidores NTP Stratum 1-time sincronizados com satélites GPS (sistema de posicionamento global). A sincronização ocorre a cada cinco minutos. O Azure garante o tempo de sincronização dos anfitriões de serviço. Sincronização de tempo para serviços financeiros no Azure Os componentes híbridos no Microsoft Entra ID, como os servidores Microsoft Entra Connect, interagem com a infraestrutura local. O cliente possui a sincronização de tempo de servidores locais. |
10.7 Falhas em sistemas críticos de controle de segurança são detetadas, relatadas e respondidas prontamente.
| Requisitos de abordagem definidos pelo PCI-DSS | Orientações e recomendações do Microsoft Entra |
|---|---|
| 10.7.2 Requisito adicional apenas para prestadores de serviços: As falhas dos sistemas críticos de controlo de segurança são detetadas, alertadas e resolvidas prontamente, incluindo, entre outras, falhas dos seguintes sistemas críticos de controlo de segurança: Controlos de segurança da rede IDS/IPS Monitorização da integridade dos ficheiros (FIM) Soluções antimalware Controlos de acesso físico Controlos de acesso lógico Mecanismo de registo de auditoria Controlos de segmentação (se utilizados) |
O Microsoft Entra ID depende de mecanismos de sincronização de tempo no Azure. O Azure dá suporte à análise de eventos em tempo real em seu ambiente operacional. Os sistemas internos de infraestrutura do Azure geram alertas de eventos quase em tempo real sobre possíveis comprometimentos. |
| 10.7.2 As falhas dos sistemas críticos de controlo de segurança são detetadas, alertadas e resolvidas prontamente, incluindo, entre outras, falhas dos seguintes sistemas críticos de controlo de segurança: Controlos de segurança de rede IDS/IP Mecanismos de deteção de alterações Soluções antimalware Controles de acesso físico Controles de acesso lógico Mecanismos de registo de auditoria Controlos de segmentação (se utilizados) Mecanismos de revisão do log de auditoria Ferramentas automatizadas de teste de segurança (se usadas) |
Consulte o guia de operações de segurança do Microsoft Entra |
| 10.7.3 Falhas de quaisquer sistemas críticos de controles de segurança são respondidas prontamente, incluindo, mas não limitado a: Restauração das funções de segurança. Identificar e documentar a duração (data e hora do início ao fim) da falha de segurança. Identificar e documentar a(s) causa(s) da falha e documentar a remediação necessária. Identificar e resolver quaisquer problemas de segurança que surgiram durante a falha. Determinar se outras ações são necessárias como resultado da falha de segurança. Implementação de controles para evitar que a causa da falha volte a ocorrer. Retomar a monitorização dos controlos de segurança. |
Consulte o guia de operações de segurança do Microsoft Entra |
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
- Requisito 10: Registrar e monitorar todo o acesso aos componentes do sistema e aos dados do titular do cartão (Você está aqui)
- Requisito 11: Testar regularmente a segurança dos sistemas e redes
- Orientação de autenticação multifator PCI-DSS do Microsoft Entra