Microsoft Entra ID e il Requisito 8 dello standard PCI-DSS
Requisito 8: Identificare gli utenti e autenticare l'accesso ai componenti di sistemaRequisiti di approccio definiti da
8.1 I processi e i meccanismi per identificare gli utenti e autenticare l'accesso ai componenti di sistema sono definiti e compresi.
Requisiti di approccio definiti dallo standard PCI-DSS | Indicazioni e consigli per Microsoft Entra |
---|---|
8.1.1 Tutti i criteri di sicurezza e le procedure operative identificate nel Requisito 8 sono: Documentati Mantenuti aggiornati In uso Noti a tutte le parti interessate |
Usare le indicazioni e i collegamenti qui riportati per produrre la documentazione per soddisfare i requisiti in base alla configurazione dell'ambiente. |
8.1.2 Ruoli e responsabilità per l'esecuzione di attività nel Requisito 8 sono documentati, assegnati e riconosciuti. | Usare le indicazioni e i collegamenti qui riportati per produrre la documentazione per soddisfare i requisiti in base alla configurazione dell'ambiente. |
8.2 L'identificazione utente e gli account correlati per utenti e amministratori vengono gestiti rigorosamente durante il ciclo di vita di un account.
Requisiti di approccio definiti dallo standard PCI-DSS | Indicazioni e consigli per Microsoft Entra |
---|---|
8.2.1 A tutti gli utenti viene assegnato un ID univoco prima che l’accesso ai componenti di sistema o ai dati dei titolari sia consentito. | Per le applicazioni CDE che si basano su Microsoft Entra ID, l'ID utente univoco è l'attributo User Principal Name (UPN). Popolamento UserPrincipalName di Microsoft Entra |
8.2.2 I gruppi, gli account condivisi o generici o altre credenziali di autenticazione condivisa vengono usati solo quando necessario in base alle eccezioni e vengono gestiti come segue: L'uso dell'account viene impedito a meno che non sia necessario per una circostanza eccezionale. L'uso è limitato al tempo necessario per la circostanza eccezionale. La motivazione aziendale per l'uso è documentata. L'uso viene approvato in modo esplicito dalla gestione L’identità utente individuale viene confermata prima di concedere l'accesso a un account. Ogni azione eseguita è attribuibile a un singolo utente. |
Assicurarsi che i CDE che usano Microsoft Entra ID per l'accesso alle applicazioni dispongano di processi per impedire gli account condivisi. Crearli come eccezione che richiede l'approvazione. Per le risorse CDE implementate in Azure, usare le identità gestite per le risorse di Azure per rappresentare l'identità dei carichi di lavoro, anziché creare un account del servizio condiviso. Informazioni sulle identità gestite per le risorse di Azure? Se non è possibile usare le identità gestite e le risorse a cui si accede usano il protocollo OAuth, usare le entità servizio per rappresentare le identità dei carichi di lavoro. Concedere alle identità l'accesso con privilegi minimi tramite ambiti OAuth. Gli amministratori possono limitare l'accesso e definire workflow di approvazione per crearli. Che cosa sono le identità dei carichi di lavoro? |
8.2.3 Requisito aggiuntivo solo per i provider di servizi: i provider di servizi con accesso remoto all'ambiente locale dei clienti usano fattori di autenticazione univoci per ogni ambiente locale dei clienti. | Microsoft Entra ID include connettori locali per abilitare le funzionalità ibride. I connettori sono identificabili e usano credenziali generate in modo univoco. Microsoft Entra Connect Sync: comprendere e personalizzare la sincronizzazione Approfondimento sulla sincronizzazione cloud Architettura di provisioning di applicazioni locali di Microsoft Entra Pianificare l’applicazione cloud delle risorse umane per il provisioning utenti di Microsoft Entra Installare gli agenti di Microsoft Entra Connect Health |
8.2.4 L'aggiunta, l'eliminazione e la modifica di ID utente, fattori di autenticazione e altri oggetti identificatori vengono gestiti come segue: Autorizzato con l'approvazione appropriata. Implementato con solo i privilegi specificati per l'approvazione documentata. |
Microsoft Entra ID ha automatizzato il provisioning degli account utente dai sistemi delle risorse umane. Usare questa funzionalità per creare un ciclo di vita. Che cos'è il provisioning basato su risorse umane? Microsoft Entra ID include flussi di lavoro del ciclo di vita per abilitare la logica personalizzata per i processi joiner, mover e leaver. Che cosa sono i flussi di lavoro del ciclo di vita? Microsoft Entra ID ha un'interfaccia programmatica per gestire i metodi di autenticazione con Microsoft Graph. Alcuni metodi di autenticazione, ad esempio le chiavi Windows Hello for Business e FIDO2, richiedono l'intervento dell'utente per la registrazione. Introduzione ai metodi di autenticazione di API Graph Gli amministratori e/o l’automazione generano le credenziali pass di accesso temporaneo usando API Graph. Usare questa credenziale per l'onboarding senza password. Configurare un Pass di accesso temporaneo in Microsoft Entra ID per registrare i metodi di autenticazione senza password |
8.2.5 L'accesso per gli utenti terminati viene revocato immediatamente. | Per revocare l'accesso a un account, disabilitare gli account locali per gli account ibridi sincronizzati da Microsoft Entra ID, disabilitare gli account in Microsoft Entra ID e revocare i token. Revocare l'accesso utente in Microsoft Entra ID Usare Valutazione continua dell'accesso (CAE) per le applicazioni compatibili per avere una conversazione bidirezionale con Microsoft Entra ID. Le app possono ricevere notifiche di eventi, ad esempio la terminazione dell'account e rifiutare i token. Valutazione continua dell'accesso |
8.2.6 Gli account utente inattivi vengono rimossi o disabilitati entro 90 giorni di attività. | Per gli account ibridi, gli amministratori controllano l'attività in Active Directory e Microsoft Entra ogni 90 giorni. Per Microsoft Entra ID, usare Microsoft Graph per cercare l'ultima data di accesso. Come gestire gli account utente inattivi in Microsoft Entra ID |
8.2.7 Gli account usati da terze parti per accedere, supportare o mantenere componenti di sistema tramite accesso remoto vengono gestiti come indicato di seguito: Abilitati solo durante il periodo di tempo necessario e disabilitato quando non sono in uso. L'uso viene monitorato per attività impreviste. |
Microsoft Entra ID include funzionalità esterne di gestione delle identità. Usare il ciclo di vita gestito da guest con la gestione entitlement. Gli utenti esterni vengono caricati nel contesto di app, risorse e pacchetti di accesso, che è possibile concedere per un periodo limitato e per cui è possibile richiedere verifiche di accesso periodiche. Le revisioni possono comportare la rimozione o la disabilitazione dell'account. Gestire l'accesso per gli utenti esterni nella gestione entitlement Microsoft Entra ID genera eventi rischiosi a livello di utente e sessione. Informazioni su come proteggere, rilevare e rispondere ad attività impreviste. Che cos'è il rischio? |
8.2.8 Se una sessione utente è inattiva per più di 15 minuti, è necessario che l'utente effettui di nuovo l'autenticazione per riattivare il terminale o la sessione. | Usare i criteri di gestione degli endpoint con Intune e Microsoft Endpoint Manager. Usare quindi l'accesso condizionale per consentire l'accesso da dispositivi conformi. Usare i criteri di conformità per impostare le regole per i dispositivi gestiti con Intune Se l'ambiente CDE si basa su oggetti Criteri di gruppo (GPO), configurare il GPO per impostare un timeout di inattività. Configurare Microsoft Entra ID per consentire l'accesso dai dispositivi ibridi aggiunti a Microsoft Entra. Dispositivi ibridi aggiunti a Microsoft Entra |
8.3 Viene stabilita e gestita l'autenticazione dettagliata per utenti e amministratori.
Per altre informazioni sui metodi di autenticazione di Microsoft Entra che soddisfano i requisiti PCI, consultare: Supplemento informativo: Multi-Factor Authentication.
Requisiti di approccio definiti dallo standard PCI-DSS | Indicazioni e consigli per Microsoft Entra |
---|---|
8.3.1 Tutti gli accessi utente ai componenti di sistema per utenti e amministratori vengono autenticati tramite almeno uno dei fattori di autenticazione seguenti: Qualcosa che l’utente conosce, ad esempio una password o una passphrase. Qualcosa in possesso dell'utente, ad esempio un dispositivo token o una scheda contestuale. Qualcosa che l'utente è, ad esempio un elemento biometrico. |
Microsoft Entra ID richiede metodi senza password per soddisfare i requisiti PCI Vedere la distribuzione olistica senza password. Pianificare una distribuzione dell'autenticazione senza password in Microsoft Entra ID |
8.3.2 La crittografia avanzata viene usata per rendere leggibili tutti i fattori di autenticazione durante la trasmissione e l'archiviazione su tutti i componenti di sistema. | La crittografia usata da Microsoft Entra ID è conforme alla definizione di crittografia avanzata di PCI. Considerazioni sulla protezione dei dati personali di Microsoft Entra |
8.3.3 L'identità utente viene verificata prima di modificare qualsiasi fattore di autenticazione. | Microsoft Entra ID richiede agli utenti di eseguire l'autenticazione per aggiornare i metodi di autenticazione usando il servizio autonomo, ad esempio il portale mysecurityinfo e il portale di reimpostazione della password self-service (SSPR). Configurare le informazioni di sicurezza da una pagina di accesso Criteri di accesso condizionale comuni: proteggere la registrazione delle informazioni di sicurezza Reimpostazione della password self-service di Microsoft Entra Gli amministratori con ruoli privilegiati possono modificare i fattori di autenticazione: globali, delle password, degli utenti, di autenticazione e dell’autenticazione privilegiata. Ruoli con privilegi minimi per task in Microsoft Entra ID. Microsoft consiglia di abilitare l'accesso JIT e la governance, per l'accesso privilegiato tramite Microsoft Entra Privileged Identity Management |
8.3.4 I tentativi di autenticazione non validi sono limitati da: Blocco dell'ID utente dopo non più di 10 tentativi. Impostare la durata del blocco su un minimo di 30 minuti o fino a quando non viene confermata l'identità dell'utente. |
Implementare Windows Hello for Business per dispositivi Windows che supportano i Trusted Platform Module (TPM) hardware 2.0 o versione successiva. Per Windows Hello for Business, il blocco è correlato al dispositivo. Il gesto, il PIN o la biometria sblocca l'accesso al TPM locale. Gli amministratori configurano il comportamento di blocco con oggetto Criteri di gruppo o Intune. Impostazioni dei criteri di gruppo TMP Gestire Windows Hello for Business sui dispositivi quando i dispositivi si iscrivono con Intune Nozioni fondamentali su TPM Windows Hello for Business works per l’autenticazione locale per Active Directory and risorse cloud su Microsoft Entra ID. Per le chiavi di sicurezza FIDO2, la protezione con forza bruta è correlata alla chiave. Il gesto, il PIN o la biometria sblocca l'accesso all'archiviazione locale delle chiavi. Gli amministratori configurano Microsoft Entra ID per consentire la registrazione delle chiavi di sicurezza FIDO2 da parte dei produttori in linea con i requisiti PCI. Abilitare l'accesso con chiave di sicurezza senza password App Microsoft Authenticator Per mitigare gli attacchi di forza bruta usando l’accesso senza password dell’app Microsoft Authenticator, abilitare la corrispondenza numerica e più contesto. Microsoft Entra ID genera un numero casuale nel flusso di autenticazione. L'utente lo digita nell'app di autenticazione. Il prompt di autenticazione dell'app per dispositivi mobili mostra il percorso, l'indirizzo IP della richiesta e l'applicazione della richiesta. Come usare la corrispondenza dei numeri nelle notifiche MFA Come usare il contesto aggiuntivo nelle notifiche di Microsoft Authenticator |
8.3.5 Se le password/passphrase vengono usate come fattori di autenticazione per soddisfare il Requisito 8.3.1, vengono impostate e ripristinate per ogni utente come indicato di seguito: Impostare su un valore univoco per l'uso per la prima volta e dopo il ripristino. Modifica forzata subito dopo il primo utilizzo. |
Non applicabile a Microsoft Entra ID. |
8.3.6 Se le password/passphrase vengono usate come fattori di autenticazione per soddisfare il Requisito 8.3.1, soddisfano il livello minimo di complessità seguente: Lunghezza minima di 12 caratteri (o SE il sistema non supporta 12 caratteri, lunghezza minima di otto caratteri). Devono contenere caratteri sia alfabetici sia numerici. |
Non applicabile a Microsoft Entra ID. |
8.3.7 Agli individui non è consentito l'invio di una nuova password/passphrase uguale a una delle ultime quattro password/passphrase usate. | Non applicabile a Microsoft Entra ID. |
8.3.8 I criteri e le procedure di autenticazione vengono documentati e comunicati a tutti gli utenti, tra cui: Indicazioni sulla selezione di fattori di autenticazione dettagliata. Indicazioni su come gli utenti devono proteggere i propri fattori di autenticazione. Istruzioni per non riutilizzare le password/passphrase utilizzate in precedenza. Istruzioni per modificare password/passphrase in caso di sospetto o consapevolezza che le password/passphrase sono state compromesse e come segnalare l'incidente. |
Documentare criteri e procedure, quindi comunicare con gli utenti in base a questo requisito. Microsoft fornisce modelli personalizzabili nell'Area download. |
8.3.9 Se le password/passphrase vengono usate come unico fattore di autenticazione per l'accesso utente (ovvero, in qualsiasi implementazione di autenticazione a singolo fattore): le password/passphrase vengono modificate almeno una volta ogni 90 giorni, OPPURE La postura di sicurezza degli account viene analizzata in modo dinamico e l'accesso in tempo reale alle risorse viene determinato automaticamente di conseguenza. |
Non applicabile a Microsoft Entra ID. |
8.3.10 Requisito aggiuntivo solo per i provider di servizi: se le password/passphrase vengono usate come unico fattore di autenticazione per l'accesso utente dei clienti ai dati dei titolari (ovvero in qualsiasi implementazione di autenticazione a fattore singolo), vengono fornite indicazioni agli utenti dei clienti, tra cui: Indicazioni per i clienti per modificare periodicamente le password utente o le passphrase. Indicazioni su quando e in quali circostanze occorre modificare le password/passphrase. |
Non applicabile a Microsoft Entra ID. |
8.3.10.1 Requisito aggiuntivo solo per i provider di servizi: se le password/passphrase vengono usate come unico fattore di autenticazione per l'accesso utente del cliente (ovvero, in qualsiasi implementazione di autenticazione a singolo fattore): Le password/passphrase vengono modificate almeno una volta ogni 90 giorni, OPPURE La postura di sicurezza degli account viene analizzata in modo dinamico e l'accesso in tempo reale alle risorse viene determinato automaticamente di conseguenza. |
Non applicabile a Microsoft Entra ID. |
8.3.11 Dove vengono usati fattori di autenticazione come token di sicurezza fisici o logici, schede contestuali o certificati: I fattori vengono assegnati a un singolo utente e non vengono condivisi tra più utenti. I controlli fisici e/o logici assicurano che solo l'utente desiderato possa usare tale fattore per ottenere l'accesso. |
Usare i metodi di autenticazione senza password, come Windows Hello for Business, le chiavi di sicurezza FIDO2 e l'app Microsoft Authenticator per l’accesso con il telefono. Usare schede contestuali basate su coppie di chiavi pubbliche o private associate agli utenti per impedire il riutilizzo. |
8.4 La Multi-Factor Authentication (MFA) viene implementata per proteggere l'accesso all'ambiente dei dati del titolare (CDE)
Requisiti di approccio definiti dallo standard PCI-DSS | Indicazioni e consigli per Microsoft Entra |
---|---|
8.4.1 L’MFA viene implementata per tutti gli accessi no-console nel CDE per il personale con accesso amministrativo. | Usare l'accesso condizionale per richiedere l'autenticazione dettagliata per accedere alle risorse CDE. Definire i criteri per applicare un ruolo amministrativo o un gruppo di sicurezza che rappresenta l'accesso amministrativo a un'applicazione. Per l'accesso amministrativo, usare Microsoft Entra Privileged Identity Management (PIM) per abilitare l'attivazione Just-In-Time (JIT) dei ruoli con privilegi. Che cos'è l'accesso condizionale? Modelli di accesso condizionale Iniziare a usare PIM |
8.4.2 L’MFA viene implementata per tutti gli accessi nel CDE. | Bloccare l'accesso ai protocolli legacy che non supportano l'autenticazione dettagliata. Bloccare l'autenticazione legacy con Microsoft Entra ID con l'accesso condizionale |
8.4.3 L’MFA viene implementata per tutti gli accessi alla rete remota provenienti dall'esterno della rete dell'entità che possono accedere o influire sul CDE come indicato di seguito: Tutti gli accessi remoti da parte di tutto il personale, sia di utenti sia di amministratori, provenienti dall'esterno della rete dell'entità. Tutti gli accessi remoti di terze parti e fornitori. |
Integrare tecnologie di accesso come la rete privata virtuale (VPN), desktop remoto e punti di accesso alla rete con Microsoft Entra ID per l'autenticazione e l'autorizzazione. Usare l'accesso condizionale per richiedere l'autenticazione dettagliata per accedere alle applicazioni di accesso remoto. Modelli di accesso condizionale |
8.5 I sistemi di Multi-Factor Authentication (MFA) sono configurati per impedire l'uso improprio.
Requisiti di approccio definiti dallo standard PCI-DSS | Indicazioni e consigli per Microsoft Entra |
---|---|
8.5.1 I sistemi MFA vengono implementati come segue: Il sistema MFA non è soggetto ad attacchi reply. I sistemi MFA non possono essere ignorati dagli utenti, inclusi gli utenti amministratori, a meno che non siano documentati in modo specifico e autorizzati dalla gestione in base a un'eccezione, per un periodo di tempo limitato. Vengono usati almeno due tipi diversi di fattori di autenticazione. L'esito positivo di tutti i fattori di autenticazione è necessario prima che l'accesso sia concesso. |
I metodi di autenticazione Microsoft Entra consigliati usano test o nonce. Questi metodi resistono agli attacchi replay perché Microsoft Entra ID rileva le transazioni di autenticazione oggetto di replay. L'app Windows Hello for Business, FIDO2 e l’app Microsoft Authenticator per l'accesso tramite telefono senza password usano un nonce per identificare la richiesta e rilevare i tentativi di replay. Usare le credenziali senza password per gli utenti nel CDE. L'autenticazione basata su certificati usa i test per rilevare i tentativi di replay. Livello 2 di garanzia dell'autenticatore NIST con Microsoft Entra ID Livello 3 di garanzia dell'autenticatore NIST con Microsoft Entra ID |
8.6 L'uso di account di applicazioni e sistemi e dei fattori di autenticazione associati è gestito in modo rigoroso.
Requisiti di approccio definiti dallo standard PCI-DSS | Indicazioni e consigli per Microsoft Entra |
---|---|
8.6.1 Se gli account usati dai sistemi o dalle applicazioni possono essere usati per l'accesso interattivo, vengono gestiti come segue: L'uso interattivo viene impedito a meno che non sia necessario per una circostanza eccezionale. L'uso interattivo è limitato al tempo necessario per le circostanze eccezionali. La motivazione aziendale per l'uso interattivo è documentata. L'uso interattivo viene approvato in modo esplicito dalla gestione. L'identità utente individuale viene confermata prima che l'accesso all'account sia concesso. Ogni azione eseguita è attribuibile a un singolo utente. |
Per le applicazioni CDE con autenticazione moderna e per le risorse CDE implementate in Azure che usano l'autenticazione moderna, Microsoft Entra ID ha due tipi di account del servizio per le applicazioni: identità gestite ed entità servizio. Informazioni sulla governance degli account del servizio Microsoft Entra: pianificazione, provisioning, ciclo di vita, monitoraggio, verifiche di accesso e così via. Governance degli account del servizio Microsoft Entra Per proteggere gli account del servizio Microsoft Entra. Protezione delle identità gestite in Microsoft Entra ID Protezione delle entità servizio in Microsoft Entra ID Per CDE con risorse esterne ad Azure che richiedono l'accesso, configurare le federazioni di identità dei carichi di lavoro senza gestire segreti o accessi interattivi. Federazione delle identità dei carichi di lavoro Per abilitare l'approvazione e il rilevamento dei processi per soddisfare i requisiti, orchestrare i flussi di lavoro tramite Gestione dei servizi IT (ITSM) e database di gestione della configurazione (CMDB). Questi strumenti usano MS Graph API per interagire con Microsoft Entra ID e gestire l'account del servizio. Per CDE che richiedono account di servizio compatibili con Active Directory locale, usare account del servizio gestito di gruppo (GMSA) e account del servizio gestito autonomi (sMSA), account computer o account utente. Protezione degli account dei servizi locali |
8.6.2 Le password/passphrase per qualsiasi applicazione e account di sistema che possono essere usate per l'accesso interattivo non sono hard-coded in script, file di configurazione/proprietà o codice sorgente bespoke e personalizzato. | Usare account di servizio moderni, ad esempio identità gestite di Azure ed entità servizio che non richiedono password. Viene effettuato il provisioning delle credenziali delle identità gestite di Microsoft Entra e viene effettuata la loro rotazione nel cloud; ciò impedisce l'uso di segreti condivisi, ad esempio password e passphrase. Quando si usano identità gestite assegnate dal sistema, il ciclo di vita è associato al ciclo di vita sottostante delle risorse di Azure. Usare le entità servizio per usare i certificati come credenziali; ciò impedisce l'uso di segreti condivisi, ad esempio password e passphrase. Se i certificati non sono fattibili, usare Azure Key Vault per archiviare i segreti client dell'entità servizio. Procedure consigliate per l'uso di Azure Key Vault Per CDE con risorse esterne ad Azure che richiedono l'accesso, configurare le federazioni di identità dei carichi di lavoro senza gestire segreti o accessi interattivi. Federazione delle identità dei carichi di lavoro Implementare l'accesso condizionale per le identità dei carichi di lavoro per controllare l'autorizzazione in base alla posizione e/o al livello di rischio. Accesso condizionale per le identità dei carichi di lavoro Oltre alle indicazioni precedenti, usare gli strumenti di analisi del codice per rilevare segreti hard-coded nei file di configurazione e di codice. Rilevare i segreti esposti nel codice Regole di sicurezza |
8.6.3 Le password/passphrase per qualsiasi applicazione e account di sistema sono protette dall'uso improprio, come indicato di seguito: Le password/passphrase vengono modificate periodicamente (con la frequenza definita nell'analisi dei rischi mirata dell'entità, eseguita in base a tutti gli elementi specificati nel Requisito 12.3.1) e in caso di sospetto o di conferma della compromissione. Le password/passphrase vengono costruite con una complessità sufficiente appropriata per la frequenza con cui l'entità modifica le password/passphrase. |
Usare account di servizio moderni, ad esempio identità gestite di Azure ed entità servizio che non richiedono password. Per le eccezioni che richiedono entità servizio con segreti, ciclo di vita astratto dei segreti con flussi di lavoro e automazione che impostano password casuali sulle entità servizio, le fanno ruotare regolarmente e reagiscono agli eventi di rischio. I team delle operazioni per la sicurezza possono esaminare e correggere i report generati da Microsoft Entra, ad esempio identità dei carichi di lavoro rischiose. Protezione delle identità dei carichi di lavoro con Microsoft Entra ID Protection |
Passaggi successivi
I requisiti PCI-DSS 3, 4, 9 e 12 non sono applicabili a Microsoft Entra ID, pertanto non esistono articoli corrispondenti. Per visualizzare tutti i requisiti, passare a pcisecuritystandards.org: Sito ufficiale del Consiglio per gli standard di sicurezza PCI.
Per configurare Microsoft Entra ID in modo che sia conforme a PCI-DSS, vedere gli articoli seguenti.
- Linee guida per Microsoft Entra PCI-DSS
- Requisito 1: Installare e mantenere i controlli di sicurezza di rete
- Requisito 2: Applicare configurazioni sicure a tutti i componenti di sistema
- Requisito 5: Proteggere tutti i sistemi e le reti da software dannosi
- Requisito 6: sviluppare e gestire sistemi e software sicuri
- Requisito 7: limitare l'accesso ai componenti di sistema e ai dati dei titolari da parte del personale per motivi professionali
- Requisito 8: identificare gli utenti e autenticare l'accesso ai componenti di sistema (Al momento l’utente si trova in questo passaggio)
- Requisito 10: registrare e monitorare tutti gli accessi ai componenti di sistema e ai dati dei titolari
- Requisito 11: Testare regolarmente la sicurezza dei sistemi e delle reti
- Materiale sussdiario per Microsoft Entra PCI-DSS Multi-Factor Authentication