Gestione degli accessi di un cluster di base del servizio Azure Kubernetes per PCI-DSS 3.2.1 (parte 6 di 9)

Questo articolo descrive le considerazioni relative a un cluster servizio Azure Kubernetes (AKS) configurato in base allo standard Pci-DSS 3.2.1 di Payment Card Industry Data Security Standard (PCI-DSS 3.2.1).

Questo articolo fa parte di una serie. Leggere l'introduzione.

Kubernetes ha il controllo degli accessi in base al ruolo nativo che gestisce le autorizzazioni per l'API Kubernetes. Esistono diversi ruoli predefiniti con autorizzazioni o azioni specifiche per le risorse Kubernetes. Servizio Azure Kubernetes (AKS) supporta i ruoli predefiniti e i ruoli personalizzati per il controllo granulare. Queste azioni possono essere autorizzate (o negate) a un utente tramite RBAC di Kubernetes.

Questa architettura e l'implementazione non sono progettate per fornire controlli sull'accesso fisico alle risorse o ai data center locali. Uno dei vantaggi dell'hosting della rete CDE in Azure, invece della piattaforma perimetrale o nel data center, consiste nel fatto che la limitazione dell'accesso fisico è già gestita tramite la sicurezza del data center di Azure. Non ci sono responsabilità per l'organizzazione nella gestione dell'hardware fisico.

Implementare misure di controllo di accesso avanzate

Requisito 7 — Limitare l'accesso ai dati di titolari di carte al personale autorizzato per motivi professionali

Supporto per le funzionalità dell'AKS

AKS è completamente integrato con Microsoft Entra ID come provider di identità.

Non è necessario gestire identità utente e credenziali separate per Kubernetes. È possibile aggiungere utenti di Microsoft Entra per RBAC di Kubernetes. Questa integrazione consente di assegnare ruoli agli utenti di Microsoft Entra. Usando le identità di Microsoft Entra, è possibile usare un'ampia gamma di ruoli predefiniti, ad esempio visualizzatore, writer, amministratore del servizio e amministratore del cluster. È anche possibile creare ruoli personalizzati per un controllo più granulare.

Per impostazione predefinita, RBAC di Azure è impostato su nega tutto l'accesso, quindi non è possibile accedere a una risorsa senza autorizzazioni concesse. AKS limita l'accesso SSH ai nodi del ruolo di lavoro di AKS e usa i criteri di rete AKS per controllare l'accesso ai carichi di lavoro nei pod.

Per maggiori informazioni, consultare la sezione Usare RBAC di Azure per l'autorizzazione Kubernetes e Proteggere il cluster con Criteri di Azure.

Responsabilità

Requisito	Responsabilità
Requisito 7.1	Limitare l'accesso ai componenti di sistema e ai dati dei titolari di carte solo alle persone che hanno bisogno di tale accesso per motivi professionali.
Requisito 7.2	Stabilire un sistema di controllo di accesso per i componenti dei sistemi, che limiti l'accesso in base alle informazioni necessarie a un utente e sia impostato su "Nega tutto" se non specificamente consentito.
Requisito 7.3	Assicurarsi che i criteri di sicurezza e le procedure operative per la limitazione dell'accesso ai dati di titolari di carte siano documentati, applicati e noti a tutte le parti interessate.

Requisito 7.1

Limitare l'accesso ai componenti di sistema e ai dati dei titolari di carte solo alle persone che hanno bisogno di tale accesso per motivi professionali.

Responsabilità

Ecco alcune considerazioni:

• Assicurarsi che l'implementazione sia allineata ai requisiti dell'organizzazione e ai requisiti di conformità sulla gestione delle identità.
• Ridurre al minimo le autorizzazioni permanenti in particolare per gli account di impatto critico.
• Seguire il principio dell'accesso con privilegio minimo. Fornire un accesso sufficiente per completare l'attività.

Requisito 7.1.1

Definire le esigenze di accesso per ogni ruolo,tra cui:

• Componenti di sistema e risorse dati necessari a ogni ruolo per accedere alla propria funzione lavorativa
• Livello di privilegio necessario (ad esempio, utente, amministratore e così via) per accedere alle risorse.

Responsabilità

Definire i ruoli in base alle attività e alle responsabilità necessarie per i componenti nell'ambito e l'interazione con le risorse di Azure. È possibile iniziare con categorie generali, ad esempio:

• L'ambito può essere costituito da gruppi di gestione, sottoscrizioni o gruppi di risorse di Azure
• Criteri di Azure per il carico di lavoro o la sottoscrizione
• Operazioni del contenitore
• Gestione dei segreti
• Pipeline di compilazione e distribuzione

Anche se la definizione di ruoli e responsabilità per tali aree potrebbe essere associata alla struttura del team, concentrarsi sul requisito del carico di lavoro. Ad esempio, determinare chi è responsabile della sicurezza, dell'isolamento, della distribuzione e dell'osservabilità. Di seguito sono riportati alcuni esempi.

• Decidere le configurazioni per la sicurezza delle applicazioni, RBAC di Kubernetes, i criteri di rete, i criteri di Azure e la comunicazione con altri servizi.
• Configurare e gestire Firewall di Azure, web application firewall (WAF), gruppi di sicurezza di rete (NSG) e DNS.
• Monitorare e correggere la sicurezza del server, applicazione di patch, configurazione e sicurezza degli endpoint.
• Stabilire la direzione per l'uso di RBAC, di Microsoft Defender per il cloud, della strategia di protezione dell'amministratore e di Criteri di Azure allo scopo di gestire le risorse di Azure.
• Identificare il team di monitoraggio e risposta degli eventi imprevisti. Analizzare e correggere gli eventi imprevisti di sicurezza usando un sistema SIEM (Security Information and Event Management) come Microsoft Sentinel o Microsoft Defender per il cloud.

Formalizzare quindi la definizione determinando il livello di accesso necessario per il ruolo in relazione al carico di lavoro e all'infrastruttura. Ecco una semplice definizione per scopi illustrativi.

Ruolo	Responsabilità	Livelli di accesso
Proprietari dell'applicazione	Definire e classificare in ordine di priorità le funzionalità in linea con i risultati aziendali. Comprendono in che modo le funzionalità influiscono sull'ambito della conformità del carico di lavoro e bilanciano la protezione e la proprietà dei dati dei clienti con gli obiettivi aziendali.	Accesso in lettura ai log e alle metriche generate dall'applicazione. Non sono necessarie autorizzazioni per accedere al carico di lavoro o al cluster.
Sviluppatori di applicazioni	Sviluppare l'applicazione. Tutto il codice dell'applicazione è soggetto a controlli di training e qualità che rispettano i processi di conformità, attestazione e gestione del rilascio. Potrebbe gestire le pipeline di compilazione, ma in genere non le pipeline di distribuzione.	Accesso in lettura agli spazi dei nomi Kubernetes e alle risorse di Azure che rientrano nell'ambito del carico di lavoro. Nessun accesso in scrittura per la distribuzione o la modifica di qualsiasi stato del sistema.
Operatori applicazioni (o SRE)	Comprendere in modo approfondito la codebase, l'osservabilità e le operazioni. Eseguire la valutazione e la risoluzione dei problemi del sito live. Insieme agli sviluppatori di applicazioni, migliorare la disponibilità, la scalabilità e le prestazioni dell'applicazione. Gestire la pipeline di distribuzione "last-mile" e gestire le pipeline di compilazione.	Privilegi elevati nell'ambito dell'applicazione che include spazi dei nomi Kubernetes correlati e risorse di Azure. Probabilmente hanno accesso permanente alle parti del cluster Kubernetes.
Proprietari dell'infrastruttura	Progettare un'architettura conveniente, inclusa la connettività e la funzionalità dei componenti. L'ambito può includere servizi cloud e locali. Decidere le funzionalità di conservazione dei dati, funzionalità di continuità aziendale e altre.	Accesso ai log della piattaforma e ai dati del centro di costo. Non è necessario alcun accesso all'interno del cluster.
Operatori dell'infrastruttura (o SRE)	Operazioni correlate al cluster e ai servizi dipendenti. Compilare, distribuire e avviare la pipeline per il cluster in cui viene distribuito il carico di lavoro. Impostare i pool di nodi di destinazione e i requisiti di ridimensionamento e scalabilità previsti. Monitorare l'integrità dell'infrastruttura di hosting dei contenitori e dei servizi dipendenti.	Accesso in lettura agli spazi dei nomi del carico di lavoro. Accesso con privilegi elevati per il cluster.
Criteri, proprietari della sicurezza	Avere competenze in materia di sicurezza o conformità alle normative. Definire criteri che proteggono la sicurezza e la conformità alle normative dei dipendenti aziendali, dei relativi asset e di quelli dei clienti dell'azienda. Funziona con tutti gli altri ruoli per garantire che i criteri vengano applicati e controllabili in ogni fase.	Accesso in lettura al carico di lavoro e al cluster. Accesso anche ai dati di log e controllo.
Operatori dei network	Allocazione della rete virtuale e delle subnet a livello aziendale. Configurazione e manutenzione di Firewall di Azure, WAF, NSG e configurazione DNS.	Privilegi elevati nel livello di rete. Nessuna autorizzazione di scrittura all'interno del cluster.

Requisito 7.1.2

Limitare l'accesso agli ID utente con privilegi ai privilegi minimi necessari per adempiere alle responsabilità professionali.

Responsabilità

In base alle funzioni del processo, cercare di ridurre al minimo l'accesso senza causare interruzioni. Ecco alcune procedure consigliate:

• Ridurre l'accesso richiesto da ogni identità. Un'identità deve avere un accesso sufficiente per completare l'attività.
• Ridurre al minimo le autorizzazioni permanenti, in particolare sulle identità a impatto critico che hanno accesso ai componenti nell'ambito.
• Aggiungere restrizioni aggiuntive, se possibile. Un modo consiste nel fornire l'accesso condizionale in base ai criteri di accesso.
• Eseguire una revisione e un controllo regolari di utenti e gruppi che hanno accesso alle sottoscrizioni, anche per l'accesso in lettura. Evitare di invitare identità esterne.

Requisito 7.1.3

Assegnare l'accesso in base alla classificazione e funzione lavorativa del singolo dipendente.

Responsabilità

Determinare le autorizzazioni in base ai compiti di lavoro chiaramente assegnati dell'individuo. Evitare parametri come il sistema o il tenure del dipendente. Concedere diritti di accesso a un singolo utente o a un gruppo.

Di seguito sono riportati alcuni esempi.

Classificazione processo	Ruolo
Un proprietario del prodotto definisce l'ambito del carico di lavoro e assegna priorità alle funzionalità. Bilancia la protezione e la proprietà dei dati dei clienti con gli obiettivi aziendali. Richiede l'accesso ai report, al centro di costo o alle dashboard di Azure. Non è necessario alcun accesso per le autorizzazioni a livello di cluster o cluster.	Proprietari dell'applicazione
Un software engineer progetta, sviluppa e in contenitori il codice dell'applicazione. Un gruppo con autorizzazioni di lettura permanenti all'interno di ambiti definiti in Azure (ad esempio Application Insights) e negli spazi dei nomi del carico di lavoro. Questi ambiti e autorizzazioni potrebbero essere diversi tra la preproduzione e gli ambienti di produzione.	Sviluppatore di applicazioni
Un tecnico dell'affidabilità del sito esegue la valutazione in tempo reale, gestisce le pipeline e configura l'infrastruttura dell'applicazione. Gruppo A con controllo completo all'interno degli spazi dei nomi allocati. Le autorizzazioni permanenti non sono necessarie. Gruppo B per le operazioni quotidiane sul carico di lavoro. Può avere autorizzazioni permanenti all'interno degli spazi dei nomi allocati, ma non hanno privilegi elevati.	Operatori applicazione
Un operatore del cluster progetta e distribuisce un cluster AKS affidabile e sicuro nella piattaforma. Responsabile della gestione del tempo di attività del cluster. Gruppo A con controllo completo all'interno degli spazi dei nomi allocati. Le autorizzazioni permanenti non sono necessarie. Gruppo B per le operazioni quotidiane sul carico di lavoro. Può avere autorizzazioni permanenti all'interno degli spazi dei nomi allocati, ma non hanno privilegi elevati.	Operatori dell'infrastruttura
Un tecnico di rete alloca le subnet e le reti virtuali a livello aziendale, locali alla connettività cloud e alla sicurezza di rete.	Operatori dell'infrastruttura

Requisito 7.1.4

Richiedere l'approvazione documentata delle parti autorizzate con la specifica dei privilegi obbligatori.

Responsabilità

Disporre di un processo gestito per approvare le modifiche apportate ai ruoli e alle autorizzazioni, inclusa l'assegnazione iniziale dei privilegi. Verificare che tali approvazioni siano documentate e disponibili per l'ispezione.

Requisito 7.2

Stabilire un sistema di controllo di accesso per i componenti dei sistemi, che limiti l'accesso in base alle informazioni necessarie a un utente e sia impostato su "Nega tutto" se non specificamente consentito.

Responsabilità

Dopo aver seguito il Requisito 7.1, è necessario avere valutato ruoli e responsabilità applicabili per l'organizzazione e il carico di lavoro. Tutti i componenti dell'architettura inclusi nell'ambito devono avere accesso limitato. Sono inclusi i nodi AKS che eseguono il carico di lavoro, l'archiviazione dei dati, l'accesso alla rete e tutti gli altri servizi che partecipano all'elaborazione dei dati del titolare della scheda (CHD).

In base ai ruoli e alle responsabilità, assegnare ruoli al controllo degli accessi in base al ruolo (RBAC) dell'infrastruttura. Questo meccanismo può essere:

• Il controllo degli accessi in base al ruolo di Kubernetes è un modello di autorizzazione Kubernetes nativo che controlla l'accesso al piano di controllo Kubernetes, esposto tramite il server API Kubernetes. Questo set di autorizzazioni definisce le operazioni che è possibile eseguire con il server API. Ad esempio, è possibile negare a un utente le autorizzazioni per creare o persino elencare i pod.
• RBAC di Azure è un modello di autorizzazione basato su ID Di Microsoft Entra che controlla l'accesso al piano di controllo di Azure. Si tratta di un'associazione del tenant di Microsoft Entra con la sottoscrizione di Azure. Con RBAC di Azure è possibile concedere le autorizzazioni per creare risorse di Azure, ad esempio reti, un cluster AKS e identità gestite.

Si supponga di dover concedere le autorizzazioni agli operatori del cluster (mappati al ruolo dell'operatore dell'infrastruttura). Tutte le persone a cui sono assegnate le responsabilità dell'operatore dell'infrastruttura appartengono a un gruppo Microsoft Entra. Come stabilito nella versione 7.1.1, questo ruolo richiede il privilegio massimo nel cluster. Kubernetes dispone di ruoli RBAC predefiniti, ad esempio cluster-admin, che soddisfano tali requisiti. È necessario associare il gruppo Microsoft Entra per l'operatore dell'infrastruttura cluster-admin creando associazioni di ruoli. Ci sono due approcci. È possibile scegliere i ruoli predefiniti. In alternativa, se i ruoli predefiniti non soddisfano i requisiti( ad esempio, potrebbero essere eccessivamente permissivi), creare ruoli personalizzati per le associazioni.

L'implementazione di riferimento illustra l'esempio precedente usando RBAC di Kubernetes nativo. La stessa associazione può essere eseguita con RBAC di Azure. Per maggiori informazioni, consultare la sezione Controllare l'accesso alle risorse del cluster usando il controllo degli accessi in base al ruolo Kubernetes e le identità Microsoft Entra nel servizio Azure Kubernetes.

È possibile scegliere l'ambito di autorizzazione a livello di cluster o a livello di spazio dei nomi. Per i ruoli con ambito, ad esempio gli operatori dell'applicazione, le autorizzazioni vengono assegnate a livello di spazio dei nomi per il carico di lavoro.

Inoltre, i ruoli necessitano anche delle autorizzazioni RBAC di Azure in modo che siano in grado di svolgere le proprie attività. Ad esempio, l'operatore del cluster deve accedere a Monitoraggio di Azure tramite il portale. Pertanto, il ruolo dell'operatore dell'infrastruttura deve avere l'assegnazione del RBAC appropriato.

Oltre a persone e ruoli, le risorse di Azure e persino i pod all'interno del cluster hanno identità gestite. Queste identità necessitano di un set di autorizzazioni tramite RBAC di Azure e devono essere strettamente con ambito in base alle attività previste. Ad esempio, Gateway applicazione di Azure deve avere le autorizzazioni per ottenere segreti (certificati TLS) da Azure Key Vault. Non deve disporre delle autorizzazioni per modificare i segreti.

Ecco alcune procedure consigliate:

• Gestire documentazione meticolosa su ogni ruolo e sulle autorizzazioni assegnate, nonché le motivazioni. Mantenere chiare distinzioni sulle autorizzazioni JIT e sulle quali si trovano.

• Monitorare i ruoli per le modifiche, ad esempio nelle modifiche di assegnazione o nelle definizioni dei ruoli. Creare avvisi sulle modifiche, anche se previsto, per ottenere visibilità sulle intenzioni dietro le modifiche.

Requisito 7.2.1

Copertura di tutti i componenti di sistema

Responsabilità

Ecco alcune procedure consigliate per gestire le misure di controllo di accesso:

• Non ha accesso permanente. È consigliabile usare l'appartenenza al gruppo Just-In-Time AD. Questa funzione richiede Microsoft Entra Privileged Identity Management.

• Configurare i criteri di accesso condizionale in Microsoft Entra ID per il cluster. In questo modo vengono ulteriormente applicate restrizioni all'accesso al piano di controllo Kubernetes. Con i criteri di accesso condizionale, è possibile richiedere l'autenticazione a più fattori, limitare l'autenticazione ai dispositivi gestiti dal tenant di Microsoft Entra o bloccare tentativi di accesso non tipici. Applicare questi criteri ai gruppi di Microsoft Entra mappati ai ruoli Kubernetes con privilegi elevati.

  Nota

  Sia le scelte relative alla tecnologia JIT che alla tecnologia di accesso condizionale richiedono licenze P1 o P2 per Microsoft Entra ID.

• Disabilitare idealmente l'accesso SSH ai nodi del cluster. Questa implementazione di riferimento non genera dettagli di connessione SSH a tale scopo.

• Qualsiasi calcolo aggiuntivo, ad esempio jump box, deve essere accessibile dagli utenti autorizzati. Non creare account di accesso generici disponibili per l'intero team.

Requisito 7.2.2

Assegnazione dei privilegi ai singoli individui in base alla classificazione e funzione lavorativa.

Responsabilità

In base alla versione 7.1.3, ci saranno molti ruoli coinvolti nelle operazioni del cluster. Oltre ai ruoli standard delle risorse di Azure, è necessario definire l'extent e il processo di accesso.

Si consideri ad esempio il ruolo dell'operatore del cluster. Devono avere un playbook chiaramente definito per le attività di valutazione del cluster. Quanto è diverso l'accesso dal team del carico di lavoro? A seconda dell'organizzazione, potrebbero coincidere. Ecco alcuni punti da considerare:

• Come devono accedere al cluster?
• Quali origini sono consentite per l'accesso?
• Quali autorizzazioni devono avere nel cluster?
• Quando vengono assegnate queste autorizzazioni?

Assicurarsi che le definizioni siano documentate nella documentazione sulla governance, sui criteri e sui materiali di training relativi all'operatore del carico di lavoro e all'operatore cluster.

Requisito 7.2.3

Impostazione "Nega tutto" predefinita.

Responsabilità

Quando si avvia la configurazione, iniziare con criteri senza attendibilità. Creare eccezioni in base alle esigenze e documentarle in dettaglio.

• Per impostazione predefinita, RBAC di Kubernetes implementa Nega tutto. Non eseguire l'override aggiungendo associazioni di ruolo del cluster altamente permissive che invertono l'impostazione nega tutto.

• Anche RBAC di Azure implementa Nega tutto per impostazione predefinita. Non eseguire l'override aggiungendo assegnazioni di controllo degli accessi in base al ruolo che invertono l'impostazione nega tutto.

• Tutti i servizi di Azure, inclusi Azure Key Vault e Registro contenitori di Azure, negano tutte le autorizzazioni per impostazione predefinita.

• Tutti i punti di accesso amministrativi, ad esempio un jump box, devono negare l'accesso nella configurazione iniziale. Tutte le autorizzazioni con privilegi elevati devono essere definite in modo esplicito per eseguire l'override della regola deny all.

Requisito 7.3

Assicurarsi che i criteri di sicurezza e le procedure operative per la limitazione dell'accesso ai dati di titolari di carte siano documentati, applicati e noti a tutte le parti interessate.

Responsabilità

È fondamentale mantenere una documentazione completa sui processi e sui criteri. Sono inclusi i criteri di RBAC di Azure e Kubernetes e i criteri di governance dell'organizzazione. Le persone che operano in ambienti regolamentati devono essere istruite, informate e incoraggiate a sostenere le garanzie di sicurezza. Questo è particolarmente importante per le persone che fanno parte del processo di approvazione dal punto di vista dei criteri.

Requisito 8 — Identificare e autenticare l'accesso ai componenti di sistema

Supporto per le funzionalità dell'AKS

Grazie all'integrazione di AKS e di Microsoft Entra, è possibile sfruttare le funzionalità di gestione delle identità e autorizzazione, tra cui gestione degli accessi, gestione degli oggetti identificatore e altri. Per maggiori informazioni, consultare la sezione Integrazione Microsoft Entra gestita da AKS.

Responsabilità

Requisito	Responsabilità
Requisito 8.1	Definire e implementare criteri e procedure per garantire una corretta gestione dell'identificazione degli utenti non consumatori e degli amministratori in tutti i componenti di sistema nel modo seguente:
Requisito 8.2	Oltre ad assegnare un ID univoco, garantire la corretta gestione dell'autenticazione degli utenti non clienti e amministratori in tutti i componenti di sistema adottando almeno uno dei metodi seguenti per autenticare tutti gli utenti:
Requisito 8.3	Proteggere tutti i singoli accessi amministrativi non da console e tutti gli accessi remoti al CDE tramite l'autenticazione a più fattori.
Requisito 8.4	Documentare e comunicare le procedure le procedure e i criteri di autenticazione a tutti gli utenti, incluse:
Requisito 8.5	Non usare ID e password di gruppo, condivisi o generici né altri metodi di autenticazione, come segue:
Requisito 8.6	Se vengono usati altri meccanismi di autenticazione (ad esempio, token di sicurezza fisici o logici, smart card, certificati e così via), l'uso di questi meccanismi deve essere assegnato come segue:
Requisito 8.7	L'accesso ai database contenenti dati dei titolari di carte (incluso l'accesso da parte di applicazioni, amministratori e tutti gli altri utenti) è limitato come segue:
Requisito 8.8	Assicurarsi che i criteri di sicurezza e le procedure operative per l'identificazione e l'autenticazione siano documentati, applicati e noti a tutte le parti interessate.

Requisito 8.1

Definire e implementare criteri e procedure per garantire una corretta gestione dell'identificazione degli utenti non consumatori e degli amministratori in tutti i componenti di sistema nel modo seguente:

• 8.1.1 Assegnare a tutti gli utenti un ID univoco prima di consentire l'accesso ai componenti di sistema o ai dati dei titolari di carte.
• 8.1.2 Controllare le operazioni di aggiunta, eliminazione e modifica di ID utente, credenziali e altri oggetti identificatore.
• 8.1.3 Revocare immediatamente l'accesso per gli utenti terminati.
• 8.1.4 Rimuovere/disabilitare gli account utente inattivi entro 90 giorni.
• 8.1.5 Gestire gli ID usati da terze parti per accedere, supportare o gestire i componenti di sistema tramite accesso remoto come segue:
  • Abilitati solo durante il periodo di tempo necessario e disabilitati se non in uso.
  • Monitorati se in uso.
• 8.1.6 Limitare i tentativi di accesso ripetuti bloccando l'ID utente dopo un massimo di sei tentativi.
• 8.1.7 Impostare la durata del blocco su un minimo di 30 minuti o finché un amministratore non abilita l'ID utente.
• 8.1.8 Se una sessione è stata inattiva per più di 15 minuti, è necessario che l'utente effettui di nuovo l'autenticazione per riattivare il terminale o la sessione.

Responsabilità

Ecco alcune considerazioni generali per questo requisito:

SI APPLICA A 8.1.1, 8.1.2, 8.1.3

Non condividere o riutilizzare le identità per parti funzionali diverse dell'ambiente CDE. Ad esempio, non usare un account del team per accedere ai dati o alle risorse del cluster. Assicurarsi che la documentazione dell'identità non sia chiara sull'uso degli account condivisi.

Estendere questa entità di identità alle assegnazioni di identità gestite in Azure. Non condividere identità gestite dall'utente tra le risorse di Azure. Assegnare a ogni risorsa di Azure la propria identità gestita. Analogamente, quando si usa Microsoft Entra Workload ID nel cluster AKS, assicurarsi che ogni componente nel carico di lavoro riceva la propria identità anziché usare un'identità estesa nell'ambito. Non condividere mai la stessa identità gestita tra ambienti di produzione e non di produzione.

Informazioni su Opzioni di accesso e identità per il servizio Azure Kubernetes (AKS).

SI APPLICA A 8.1.2, 8.1.3, 8.1.4

Usare Microsoft Entra ID come archivio identità. Poiché il cluster e tutte le risorse di Azure usano Microsoft Entra ID, la disabilitazione o la revoca dell'accesso di un'entità si applicano automaticamente a tutte le risorse. Se sono presenti componenti non supportati direttamente da Microsoft Entra ID, assicurarsi di disporre di un processo per rimuovere l'accesso. Ad esempio, le credenziali SSH per l'accesso a una jump box potrebbero essere rimosse in modo esplicito se l'utente non è più valido.

SI APPLICA A: 8.1.5

Sfruttare Microsoft Entra External ID progettato per ospitare account business-to-business (B2B) di terze parti, ad esempio fornitori e partner, come utenti guest. Concedere il livello di accesso appropriato usando criteri condizionali per proteggere i dati aziendali. Questi account devono avere autorizzazioni permanenti minime e date di scadenza obbligatorie. Per maggiori informazioni, consultare la sezione Collaborazione B2B con guest esterni per la forza lavoro.

L'organizzazione deve avere un modello chiaro e documentato di fornitore e accesso simile.

SI APPLICA A 8.1.6, 8.1.7, 8.1.8

Responsabilità

Microsoft Entra ID offre una funzionalità di blocco intelligente per bloccare gli utenti dopo i tentativi di accesso non riusciti. Il modo consigliato per implementare i blocchi è con i criteri di accesso condizionale di Microsoft Entra.

Implementare il blocco per i componenti che supportano funzionalità simili, ma non sono supportate con Microsoft Entra ID (ad esempio, computer abilitati per SSH, ad esempio un jump box). In questo modo si garantisce che i blocchi siano abilitati per impedire o rallentare l'abuso dei tentativi di accesso.

I nodi di AKS non sono progettati per l'accesso di routine. Bloccare l'accesso diretto SSH o Desktop remoto ai nodi del cluster. L'accesso SSH deve essere considerato solo come parte degli sforzi avanzati per la risoluzione dei problemi. L'accesso deve essere monitorato attentamente e ripristinato tempestivamente dopo il completamento dell'evento specifico. In questo caso, tenere presente che eventuali modifiche a livello di nodo possono causare il supporto del cluster.

Requisito 8.2

Oltre ad assegnare un ID univoco, verificare che la gestione dell'autenticazione utente sia appropriata per gli utenti non-consumer e gli amministratori in tutti i componenti di sistema utilizzando almeno uno dei metodi seguenti per autenticare tutti gli utenti: Un elemento conosciuto, come una password o passphrase, un elemento di cui si dispone, come un dispositivo token o una smart card, un elemento fisico, ad esempio un sistema biometrico.

• 8.2.1 Usando la crittografia avanzata, rendere illeggibili tutte le credenziali di autenticazione (ad esempio, password/frasi) durante la trasmissione e l'archiviazione in tutti i componenti di sistema.
• 8.2.2 Verificare l'identità dell'utente prima di modificare le credenziali di autenticazione, ad esempio eseguendo reimpostazioni della password, effettuando il provisioning di nuovi token o generando nuove chiavi.
• 8.2.3 Le password/phrase devono soddisfare quanto segue:
  • Richiedere una lunghezza minima di almeno sette caratteri.
  • Contenere caratteri sia alfabetici che numerici.
• 8.2.4 Modificare le password/passphrase dell'utente almeno una volta ogni 90 giorni.
• 8.2.5 Non consentire l'invio di una nuova password/phrase uguale a una delle ultime quattro password/phrase usate.
• 8.2.6 Impostare password/phrase per il primo utilizzo e dopo la reimpostazione su un valore univoco per ogni utente e modificarle immediatamente dopo il primo utilizzo.

Responsabilità

Configurare i Criteri di accesso condizionale in Microsoft Entra ID per il cluster. In questo modo vengono ulteriormente applicate restrizioni all'accesso al piano di controllo Kubernetes.

Diversi dei requisiti precedenti vengono gestiti automaticamente da Microsoft Entra ID. Di seguito sono riportati alcuni esempi.

• Sicurezza della password

  Microsoft Entra ID fornisce funzionalità che applicano l'uso di password complesse. Ad esempio, le password vulnerabili che appartengono all'elenco globale di password escluse vengono bloccate. Questa non è una protezione sufficiente. Per creare un elenco di divieto specifico dell'organizzazione, è consigliabile aggiungere la funzionalità di protezione password di Microsoft Entra. Per impostazione predefinita, viene applicato un criterio password. Alcuni criteri non possono essere modificati e coprono alcuni dei requisiti precedenti. Questi includono la scadenza della password e i caratteri consentiti. Per l'elenco completo, consultare la sezione Criteri password di Microsoft Entra. Prendere in considerazione l'applicazione avanzata usando criteri di accesso condizionale, ad esempio quelli basati sul rischio utente, che rilevano coppie nome utente e password perse. Per maggiori informazioni, consultare la sezione Accesso condizionale: accesso condizionale basato sul rischio utente.

  Nota

  È consigliabile prendere in considerazione le opzioni senza password. Per altre informazioni, vedere Pianificare una distribuzione dell'autenticazione senza password in Microsoft Entra ID.

• Verifica dell'identità utente

  È possibile applicare i criteri di accesso condizionale per il rischio di accesso per rilevare se la richiesta di autenticazione è stata emessa dall'identità richiedente. La richiesta viene convalidata rispetto alle origini di Intelligence per le minacce. Tra cui password spraying e anomalie degli indirizzi IP. Per maggiori informazioni, consultare la sezione Accesso condizionale: accesso condizionale basato sul rischio di accesso.

Potrebbero essere presenti componenti che non usano Microsoft Entra ID, ad esempio l'accesso alle jump box con SSH. Per questi casi, usare la crittografia a chiave pubblica con almeno le dimensioni della chiave RSA 2048. Specificare sempre una passphrase. Disporre di un processo di convalida che tiene traccia delle chiavi pubbliche approvate note. I sistemi che usano l'accesso con chiave pubblica non devono essere esposti a Internet. L'accesso SSH deve invece essere consentito solo tramite un intermediario, ad esempio Azure Bastion, per ridurre l'impatto di una perdita di chiavi private. Disabilitare l'accesso diretto alle password e usare una soluzione alternativa senza password.

Requisito 8.3

Proteggere tutti i singoli accessi amministrativi non da console e tutti gli accessi remoti al CDE tramite l'autenticazione a più fattori. Nota: l'autenticazione a più fattori richiede l'uso di almeno due dei tre metodi di autenticazione. Per le descrizioni dei metodi di autenticazione, vedere il Requisito 8.2. L'uso di un fattore per due volte (ad esempio, l'uso di due password distinte) non viene considerato un'autenticazione a più fattori.

Responsabilità

Usare i criteri di accesso condizionale per applicare l'autenticazione a più fattori, in particolare sugli account amministrativi. Questi criteri sono consigliati in diversi ruoli predefiniti. Applicare questi criteri ai gruppi di Microsoft Entra mappati ai ruoli Kubernetes con privilegi elevati.

Questi criteri possono essere ulteriormente rafforzati con criteri aggiuntivi. Di seguito sono riportati alcuni esempi.

• È possibile limitare l'autenticazione ai dispositivi gestiti dal tenant di Microsoft Entra.
• Se l'accesso ha origine da una rete esterna alla rete del cluster, è possibile applicare l'autenticazione a più fattori.

Per altre informazioni, vedi:

• Accesso condizionale: richiedere l'autenticazione a più fattori per gli amministratori
• Accesso condizionale: richiedere dispositivi conformi nell'accesso condizionale
• Accesso condizionale: autenticazione a più fattori basata sul rischio di accesso

Requisito 8.4

Documentare e comunicare le procedure le procedure e i criteri di autenticazione a tutti gli utenti, incluse:

• Indicazioni sulla selezione di credenziali di autenticazione complesse
• Indicazioni su come gli utenti devono proteggere le proprie credenziali di autenticazione
• Istruzioni per non riutilizzare le password utilizzate precedentemente
• Istruzioni per modificare le password in caso di sospetta compromissione delle password.

Responsabilità

Gestire la documentazione sui criteri applicati. Nell'ambito del training sull'onboarding delle identità, fornire indicazioni per le procedure di reimpostazione delle password e le procedure consigliate dell'organizzazione sulla protezione degli asset.

Requisito 8.5

Non usare ID e password di gruppo, condivisi o generici né altri metodi di autenticazione, come segue:

• Gli ID utente generici sono disabilitati o rimossi.
• Non esistono ID utente condivisi per le attività di amministrazione del sistema e altre funzioni critiche.
• Gli ID utente condivisi e generici non vengono usati per gestire i componenti di sistema.

Responsabilità

Non condividere o riutilizzare le identità per parti funzionali diverse del cluster o dei pod. Ad esempio, non usare un account del team per accedere ai dati o alle risorse del cluster. Assicurarsi che la documentazione dell'identità non sia chiara sull'uso degli account condivisi.

Disabilitare gli utenti radice nell'ambiente CDE. Disabilitare l'utilizzo degli account locali Kubernetes in modo che gli utenti non possano usare l'accesso predefinito --admin ai cluster all'interno dell'ambiente CDE.

Requisito 8.6

Se vengono usati altri meccanismi di autenticazione (ad esempio, token di sicurezza fisici o logici, smart card, certificati e così via), l'uso di questi meccanismi deve essere assegnato come segue:

• I meccanismi di autenticazione devono essere assegnati a un singolo account e non vanno condivisi tra più account.
• Devono essere adottati controlli fisici e/o logici per assicurare che solo un determinato account possa usare tale meccanismo di accesso.

Responsabilità

Assicurarsi che tutto l'accesso all'ambiente CDE venga fornito nelle identità per utente e che venga esteso a qualsiasi token fisico o virtuale. Ciò include qualsiasi accesso VPN alla rete CDE, assicurandosi che l'accesso da punto a sito aziendale (se presente) usi certificati per utente come parte di tale flusso di autenticazione.

Requisito 8.7

L'accesso ai database contenenti dati dei titolari di carte (incluso l'accesso da parte di applicazioni, amministratori e tutti gli altri utenti) è limitato come segue:

• Tutti gli accessi, le query e le azioni dell'utente nei database vengono eseguiti tramite metodi programmatici.
• Solo gli amministratori del database hanno la possibilità di accedere o eseguire query direttamente sui database.
• Gli ID applicazione per le applicazioni di database possono essere usati esclusivamente dalle applicazioni e non da utenti singoli o altri processi non relativi alle applicazioni.

Responsabilità

Fornire l'accesso in base a ruoli e responsabilità. Le persone possono usare la propria identità, ma l'accesso deve essere limitato in base alle esigenze, con autorizzazioni permanenti minime. Gli utenti non devono mai usare le identità dell'applicazione e le identità di accesso al database non devono mai essere condivise.

Se possibile, accedere ai database dalle applicazioni tramite un'identità gestita. In caso contrario, limitare l'esposizione a stringa di connessione e credenziali. Usare i segreti Kubernetes per archiviare informazioni riservate invece di mantenerle facilmente individuate, ad esempio una definizione di pod. Un altro modo consiste nell'archiviare e caricare segreti da e verso un archivio gestito progettato per proteggere i dati, ad esempio Azure Key Vault. Con le identità gestite abilitate in un cluster di AKS, è necessario eseguire l'autenticazione in Key Vault per ottenere l'accesso.

Requisito 8.8

Assicurarsi che i criteri di sicurezza e le procedure operative per l'identificazione e l'autenticazione siano documentati, applicati e noti a tutte le parti interessate.

Responsabilità

È fondamentale mantenere una documentazione completa sui processi e sui criteri. Gestire la documentazione sui criteri applicati. Nell'ambito del training sull'onboarding delle identità, fornire indicazioni per le procedure di reimpostazione delle password e le procedure consigliate dell'organizzazione sulla protezione degli asset. Le persone che operano in ambienti regolamentati devono essere istruite, informate e incoraggiate a sostenere le garanzie di sicurezza. Questo è particolarmente importante per le persone che fanno parte del processo di approvazione dal punto di vista dei criteri.

Requisito 9 — Limitare l'accesso fisico ai dati di titolari di carte

Supporto per le funzionalità dell'AKS

Per questo requisito non sono disponibili funzionalità AKS applicabili.

Responsabilità

Questa architettura e l'implementazione non sono progettate per fornire controlli sull'accesso fisico alle risorse o ai data center locali. Per le considerazioni, consultare le linee guida nello standard ufficiale PCI-DSS 3.2.1.

Di seguito alcuni suggerimenti per l'applicazione di controlli tecnici:

• Ottimizzare i timeout della sessione in qualsiasi accesso alla console di amministrazione, ad esempio i jumpbox nell'ambiente CDE, per ridurre al minimo l'accesso.

• Ottimizzare i criteri di accesso condizionale per ridurre al minimo TTL nei token di accesso di Azure dai punti di accesso, ad esempio il portale di Azure. Per informazioni, vedere questi articoli:

  • Configurazione dei criteri di durata della sessione adattiva
  • Durate configurabili del token in Microsoft Identity Platform

• Per la rete CDE ospitata dal cloud, non ci sono responsabilità per la gestione dell'accesso fisico e dell'hardware. Si basano su controlli fisici e logici della rete aziendale.

• Ridurre al minimo l'esportazione dei backup CHD nelle destinazioni locali. Usare le soluzioni ospitate in Azure per limitare l'accesso fisico ai backup.

• Ridurre al minimo i backup in locale. Se necessario, tenere presente che la destinazione locale sarà nell'ambito del controllo.

Passaggi successivi

Tenere traccia e monitorare tutti gli accessi alle risorse di rete e ai dati di titolari di schede. Testare regolarmente sistemi e processi di sicurezza.