Controllo della sicurezza: Gestione delle identità

  • Articolo

Identity Management illustra i controlli per stabilire controlli di identità e accesso sicuri usando sistemi di gestione delle identità e degli accessi, tra cui l'uso di Single Sign-On, autenticazioni complesse, identità gestite (e entità servizio) per le applicazioni, l'accesso condizionale e il monitoraggio delle anomalie degli account.

IM-1: Usare un sistema di autenticazione e identità centralizzato

CIS Controls v8 ID(s) ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
6.7, 12.5 AC-2, AC-3, IA-2, IA-8 7.2, 8.3

Principio di sicurezza: usare un sistema centralizzato di identità e autenticazione per gestire le identità e le autenticazioni dell'organizzazione per le risorse cloud e non cloud.

Linee guida di Azure: Azure Active Directory (Azure AD) è il servizio di gestione delle identità e dell'autenticazione di Azure. È consigliabile standardizzare in Azure AD per gestire l'identità e l'autenticazione dell'organizzazione in:

  • Risorse cloud Microsoft, ad esempio Archiviazione di Azure, Azure Macchine virtuali (Linux e Windows), applicazioni Azure Key Vault, PaaS e SaaS.
  • Risorse dell'organizzazione, ad esempio applicazioni in Azure, applicazioni di terze parti in esecuzione nelle risorse di rete aziendale e applicazioni SaaS di terze parti.
  • Le identità aziendali in Active Directory eseguendo la sincronizzazione con Azure AD per garantire una strategia di gestione delle identità coerente e centralizzata.

Per i servizi di Azure applicabili, evitare l'uso dei metodi di autenticazione locale e usare invece Azure Active Directory per centralizzare le autenticazioni del servizio.

Nota: non appena è tecnicamente fattibile, è necessario eseguire la migrazione di applicazioni basate su Active Directory locale ad Azure AD. Potrebbe trattarsi di una configurazione di Azure AD Enterprise Directory, Business to Business o Business to Consumer.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: AWS IAM (Identity and Access Management) è il servizio di gestione delle identità e dell'autenticazione predefinito di AWS. Usare AWS IAM per gestire l'identità e la gestione degli accessi di AWS. In alternativa, tramite AWS e Azure Single Sign-On (SSO), è anche possibile usare Azure AD per gestire l'identità e il controllo di accesso di AWS per evitare di gestire gli account duplicati separatamente in due piattaforme cloud.

AWS supporta single Sign-On che consente di collegare le identità di terze parti dell'azienda (ad esempio Windows Active Directory o altri archivi di identità) con le identità AWS per evitare di creare account duplicati per accedere alle risorse AWS.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: il sistema IAM (Identity and Access Management) di Google Cloud è il servizio di gestione delle identità e dell'autenticazione predefinito di Google Cloud usato per gli account Google Cloud Identity. Usare Google Cloud IAM per gestire l'identità e la gestione degli accessi GCP. In alternativa, tramite Google Cloud Identity e Azure Sigle Sign-On (SSO), è anche possibile usare Azure AD per gestire l'identità e il controllo di accesso di GCP per evitare di gestire gli account duplicati separatamente in un ambiente mutli-cloud.

Google Cloud Identity è il provider di identità per tutti i servizi Google. Supporta single Sign-On che consente di collegare le identità di terze parti dell'azienda (ad esempio Windows Active Directory o altri archivi di identità) con le identità di Google Cloud per evitare di creare account duplicati per accedere alle risorse GCP.

Nota: uso della sincronizzazione di Google Cloud Directory. Google offre uno strumento connettore che si integra con la maggior parte dei sistemi di gestione LDAP aziendali e sincronizza le identità in base a una pianificazione. Configurando un account di identità cloud e selezionando Google Cloud Directory Sync, è possibile configurare quali account utente, inclusi utenti, gruppi e profili utente, alias e altro ancora, verranno sincronizzati in base a una pianificazione tra il sistema di gestione delle identità locale e il sistema GCP.

Implementazione GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

IM-2: Proteggere i sistemi di identità e autenticazione

CIS Controls v8 ID(s) ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
5.4, 6.5 AC-2, AC-3, IA-2, IA-8, SI-4 8.2, 8.3

Principio di sicurezza: proteggere l'identità e il sistema di autenticazione come priorità elevata nella pratica di sicurezza cloud dell'organizzazione. I controlli di sicurezza comuni includono:

  • Limitare i ruoli e gli account con privilegi
  • Richiedere l'autenticazione avanzata per tutti gli accessi con privilegi
  • Monitorare e controllare le attività ad alto rischio

Linee guida di Azure: usare la baseline di sicurezza di Azure AD e azure AD Identity Secure Score per valutare il comportamento di sicurezza delle identità di Azure AD e correggere le lacune di sicurezza e configurazione. Azure AD Identity Secure Score valuta Azure AD per le configurazioni seguenti:

  • Usare ruoli amministrativi limitati
  • Attivare i criteri di rischio utente
  • Designare più di un amministratore globale
  • Abilitare i criteri per bloccare l'autenticazione legacy
  • Assicurarsi che tutti gli utenti possano completare l'autenticazione a più fattori per l'accesso sicuro
  • Richiedere l'autenticazione a più fattori per i ruoli amministrativi
  • Abilitare la reimpostazione self-service delle password
  • Non scadere le password
  • Attivare i criteri di rischio di accesso
  • Non consentire agli utenti di concedere il consenso alle applicazioni non gestite

Usare Azure AD Identity Protection per rilevare, analizzare e correggere i rischi basati sull'identità. Per proteggere in modo analogo il dominio di Active Directory locale, usare Defender per identità.

Nota: seguire le procedure consigliate pubblicate per tutti gli altri componenti di identità, inclusi i Active Directory locale e le funzionalità di terze parti e le infrastrutture (ad esempio sistemi operativi, reti, database) che li ospitano.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: usare le procedure consigliate per la sicurezza seguenti per proteggere AWS IAM:

  • Configurare le chiavi di accesso utente radice dell'account AWS per l'accesso di emergenza come descritto in PA-5 (Configurare l'accesso di emergenza)
  • Seguire i principi dei privilegi minimi per le assegnazioni di accesso
  • Sfruttare i gruppi IAM per applicare i criteri anziché i singoli utenti.
  • Seguire le linee guida per l'autenticazione avanzata in IM-6 (Usare controlli di autenticazione avanzata) per tutti gli utenti
  • Usare AWS Organizations SCP (Service Control Policy) e i limiti delle autorizzazioni
  • Usare Access Advisor IAM per controllare l'accesso al servizio
  • Usare il report delle credenziali IAM per tenere traccia degli account utente e dello stato delle credenziali

Nota: seguire le procedure consigliate pubblicate se si dispone di altri sistemi di identità e autenticazione, ad esempio seguire la baseline di sicurezza di Azure AD se si usa Azure AD per gestire l'identità e l'accesso di AWS.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni su GCP: usare le procedure consigliate per la sicurezza seguenti per proteggere i servizi Google Cloud IAM e Cloud Identity per le organizzazioni:

  • Configurare un account amministratore con privilegi avanzati per l'accesso di emergenza seguendo le raccomandazioni in PA-5 ("Configurare l'accesso di emergenza").
  • Creare un indirizzo di posta elettronica amministratore con privilegi avanzati (come account amministratore con privilegi avanzati di Google Workspace o Cloud Identity) e questo account non deve essere specifico per un determinato utente nel caso in cui sia necessario un ripristino di emergenza.
  • Seguire i privilegi minimi e la separazione dei principi dei compiti
  • Evitare di usare un account amministratore con privilegi avanzati per le attività quotidiane
  • Sfruttare i gruppi di identità Google Cloud per applicare criteri invece di applicare criteri a singoli utenti.
  • Seguire le linee guida per l'autenticazione avanzata, come descritto in IM-6 ("Usare controlli di autenticazione avanzata") per tutti gli utenti con privilegi elevati.
  • Usare i criteri IAM per limitare l'accesso alle risorse
  • Usare il servizio Criteri di organizzazione per controllare e configurare i vincoli sulle risorse
  • Usare la registrazione dei controlli IAM nei log di controllo cloud per esaminare le attività con privilegi

Nota: seguire le procedure consigliate pubblicate se sono presenti altri sistemi di identità e autenticazione, ad esempio seguire la baseline di sicurezza di Azure AD se si usa Azure AD per gestire l'identità e l'accesso GCP.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

IM-3: Gestire le identità dell'applicazione in modo sicuro e automatico

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
N/D AC-2, AC-3, IA-4, IA-5, IA-9 N/D

Principio di sicurezza: usare le identità dell'applicazione gestite anziché creare account umani per le applicazioni per accedere alle risorse ed eseguire codice. Le identità dell'applicazione gestite offrono vantaggi come la riduzione dell'esposizione delle credenziali. Automatizzare la rotazione delle credenziali per garantire la sicurezza delle identità.

Linee guida di Azure: usare identità gestite di Azure, che possono eseguire l'autenticazione nei servizi e nelle risorse di Azure che supportano l'autenticazione di Azure AD. Le credenziali di identità gestite sono completamente gestite, ruotate e protette dalla piattaforma, evitando le credenziali hardcoded nel codice sorgente o nei file di configurazione.

Per i servizi che non supportano le identità gestite, usare Azure AD per creare un'entità servizio con autorizzazioni limitate a livello di risorsa. È consigliabile configurare le entità servizio con le credenziali del certificato e tornare ai segreti client per l'autenticazione.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: usare i ruoli IAM di AWS anziché creare account utente per le risorse che supportano questa funzionalità. I ruoli IAM vengono gestiti dalla piattaforma nel back-end e le credenziali vengono temporanee e ruotate automaticamente. Ciò consente di evitare di creare chiavi di accesso a lungo termine o un nome utente/password per le applicazioni e le credenziali hardcoded nel codice sorgente o nei file di configurazione.

È possibile usare ruoli collegati al servizio collegati ai criteri di autorizzazione predefiniti per l'accesso tra i servizi AWS anziché personalizzare le autorizzazioni di ruolo per i ruoli IAM.

Nota: per i servizi che non supportano i ruoli IAM, usare le chiavi di accesso, ma seguire la procedura consigliata per la sicurezza, ad esempio IM-8 Limitare l'esposizione delle credenziali e dei segreti per proteggere le chiavi.

Implementazione di AWS e contesto aggiuntivo:

Linee guida per GCP: usare gli account del servizio gestito da Google anziché creare account gestiti dall'utente per le risorse che supportano questa funzionalità. Gli account del servizio gestito da Google vengono gestiti dalla piattaforma nel back-end e le chiavi dell'account del servizio sono temporanee e ruotate automaticamente. Ciò consente di evitare di creare chiavi di accesso a lungo termine o un nome utente/password per le applicazioni e le credenziali hardcoded hardcoded nel codice sorgente o nei file di configurazione.

Usare Intelligence dei criteri per comprendere e riconoscere attività sospette per gli account del servizio.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

IM-4: Autenticare server e servizi

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
N/D IA-9 N/D

Principio di sicurezza: autenticare server e servizi remoti dal lato client per assicurarsi di connettersi a server e servizi attendibili. Il protocollo di autenticazione server più comune è Transport Layer Security (TLS), dove il lato client (spesso un browser o un dispositivo client) verifica il server verificando che il certificato del server sia stato rilasciato da un'autorità di certificazione attendibile.

Nota: l'autenticazione reciproca può essere usata quando il server e il client autenticano l'uno all'altro.

Linee guida di Azure: molti servizi di Azure supportano l'autenticazione TLS per impostazione predefinita. Per i servizi che non supportano l'autenticazione TLS per impostazione predefinita o supportano la disabilitazione di TLS, assicurarsi che sia sempre abilitata per supportare l'autenticazione server/client. L'applicazione client deve essere progettata anche per verificare l'identità server/client (verificando il certificato del server rilasciato da un'autorità di certificazione attendibile) nella fase handshake.

Nota: i servizi come Gestione API e gateway API supportano l'autenticazione reciproca TLS.

Implementazione di Azure e contesto aggiuntivo:

Linee guida AWS: molti servizi AWS supportano l'autenticazione TLS per impostazione predefinita. Per i servizi che non supportano l'autenticazione TLS per impostazione predefinita o supportano la disabilitazione di TLS, assicurarsi che sia sempre abilitata per supportare l'autenticazione server/client. L'applicazione client deve essere progettata anche per verificare l'identità server/client (verificando il certificato del server rilasciato da un'autorità di certificazione attendibile) nella fase handshake.

Nota: i servizi come il gateway API supportano l'autenticazione reciproca TLS.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: molti servizi GCP supportano l'autenticazione TLS per impostazione predefinita. Per i servizi che non supportano questa funzionalità per impostazione predefinita o supportano la disabilitazione di TLS, assicurarsi che sia sempre abilitata per supportare l'autenticazione server/client. L'applicazione client deve essere progettata anche per verificare l'identità server/client (verificando il certificato del server rilasciato da un'autorità di certificazione attendibile) nella fase handshake.

Nota: i servizi come Il bilanciamento del carico cloud supportano l'autenticazione reciproca TLS.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

IM-5: Usare l'accesso Single Sign-On (SSO) per l'accesso alle applicazioni

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
12.5 IA-4, IA-2, IA-8 N/D

Principio di sicurezza: usare l'accesso Single Sign-On (SSO) per semplificare l'esperienza utente per l'autenticazione alle risorse, tra cui applicazioni e dati tra servizi cloud e ambienti locali.

Linee guida di Azure: usare Azure AD per l'accesso alle applicazioni del carico di lavoro (cliente) tramite l'accesso Single Sign-On (SSO) di Azure AD, riducendo la necessità di account duplicati. Azure AD fornisce la gestione delle identità e dell'accesso alle risorse di Azure (nel piano di gestione, tra cui l'interfaccia della riga di comando, PowerShell, il portale), le applicazioni cloud e le applicazioni locali.

Azure AD supporta anche l'accesso SSO per le identità aziendali, ad esempio identità utente aziendali, nonché identità utente esterne provenienti da utenti di terze parti attendibili e utenti pubblici.

Implementazione di Azure e contesto aggiuntivo:

Linee guida di AWS: usare AWS Cognito per gestire gli acccess ai carichi di lavoro delle applicazioni con accesso Single Sign-On (SSO) per consentire ai clienti di collegare le identità di terze parti da provider di identità diversi.

Per l'accesso SSO alle risorse native di AWS (incluso l'accesso alla console AWS o l'accesso a livello di piano dati e di piano dati), usare AWS Sigle Sign-On per ridurre la necessità di account duplicati.

AWS SSO consente anche di collegare identità aziendali (ad esempio identità di Azure Active Directory) con identità AWS, nonché identità utente esterne da utenti di terze parti attendibili e utenti pubblici.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni su GCP: usare Google Cloud Identity per gestire l'accesso all'applicazione del carico di lavoro per i clienti tramite l'accesso Single Sign-On di Google Cloud Identity, riducendo la necessità di account duplicati. Google Cloud Identity offre la gestione delle identità e degli accessi a GCP (nel piano di gestione, tra cui l'interfaccia della riga di comando di Google Cloud, l'accesso alla console), le applicazioni cloud e le applicazioni locali.

Google Cloud Identity supporta anche l'accesso SSO per identità aziendali, ad esempio identità utente aziendali da Azure AD o Active Directory, nonché identità utente esterne da utenti di terze parti attendibili e utenti pubblici. Implementazione GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

IM-6: Usare controlli di autenticazione avanzata

CIS Controls v8 ID(s) ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
6.3, 6.4 AC-2, AC-3, IA-2, IA-5, IA-8 7.2, 8.2, 8.3, 8.4

Principio di sicurezza: applicare controlli di autenticazione avanzata (autenticazione complessa senza password o autenticazione a più fattori) con il sistema di gestione centralizzato delle identità e dell'autenticazione per tutti gli accessi alle risorse. L'autenticazione basata sulle credenziali password da sola è considerata legacy, perché non è sicura e non si basa sui metodi di attacco più diffusi.

Quando si distribuisce l'autenticazione avanzata, configurare prima gli amministratori e gli utenti con privilegi, per garantire il livello più elevato del metodo di autenticazione avanzata, seguito rapidamente dall'implementazione dei criteri di autenticazione avanzata appropriati a tutti gli utenti.

Nota: se per le applicazioni e gli scenari legacy è necessaria l'autenticazione basata su password legacy, assicurarsi che vengano seguite le procedure consigliate per la sicurezza delle password, ad esempio i requisiti di complessità.

Linee guida di Azure: Azure AD supporta controlli di autenticazione avanzata tramite metodi senza password e multi-factor authentication (MFA).

  • Autenticazione senza password: usare l'autenticazione senza password come metodo di autenticazione predefinito. Sono disponibili tre opzioni per l'autenticazione senza password: Windows Hello for Business, l'accesso tramite telefono dell'app Microsoft Authenticator e le chiavi di sicurezza FIDO2. Inoltre, i clienti possono usare metodi di autenticazione locali, ad esempio smart card.
  • Autenticazione a più fattori: Azure MFA può essere applicato a tutti gli utenti, selezionare gli utenti o a livello di utente in base a condizioni di accesso e fattori di rischio. Abilitare Azure MFA e seguire Microsoft Defender per le raccomandazioni sulla gestione delle identità e degli accessi cloud per la configurazione di MFA.

Se l'autenticazione basata su password legacy è ancora usata per l'autenticazione di Azure AD, tenere presente che gli account solo cloud (account utente creati direttamente in Azure) dispongono di un criterio password di base predefinito. E gli account ibridi (account utente provenienti da Active Directory locale) seguono i criteri delle password locali.

Per le applicazioni e i servizi di terze parti che possono avere ID e password predefiniti, è necessario disabilitarli o modificarli durante la configurazione iniziale del servizio.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: AWS IAM supporta controlli di autenticazione avanzata tramite l'autenticazione a più fattori (MFA). L'autenticazione a più fattori può essere applicata a tutti gli utenti, selezionare gli utenti o a livello di utente in base alle condizioni definite.

Se si usano account aziendali da una directory di terze parti (ad esempio Windows Active Directory) con le identità AWS, seguire le rispettive linee guida di sicurezza per applicare l'autenticazione avanzata. Se si usa Azure AD per gestire l'accesso a AWS, vedere Linee guida di Azure per questo controllo.

Nota: per le applicazioni di terze parti e i servizi AWS che possono avere ID e password predefiniti, è necessario disabilitarli o modificarli durante la configurazione iniziale del servizio.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni su GCP: Google Cloud Identity supporta controlli di autenticazione avanzata tramite l'autenticazione a più fattori (MFA). L'autenticazione a più fattori può essere applicata a tutti gli utenti, selezionare gli utenti o a livello di utente in base alle condizioni definite. Per proteggere gli account con privilegi avanzati di identità cloud (e area di lavoro), prendere in considerazione l'uso delle chiavi di sicurezza e del programma Google Advanced Protection per garantire la massima sicurezza.

Se si usano account aziendali da una directory di terze parti (ad esempio Windows Active Directory) con le identità di Google Cloud, seguire le rispettive linee guida sulla sicurezza per applicare l'autenticazione avanzata. Per questo controllo, vedere Linee guida di Azure se si usa Azure AD per gestire l'accesso a Google Cloud.

Usare Identity-Aware Proxy per stabilire un livello di autorizzazione centrale per le applicazioni a cui si accede tramite HTTPS, quindi è possibile usare un modello di controllo di accesso a livello di applicazione invece di basarsi sui firewall a livello di rete.

Nota: per le applicazioni di terze parti e i servizi GCP con ID e password predefiniti, è necessario disabilitarli o modificarli durante la configurazione iniziale del servizio.

Implementazione GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

IM-7: Limitare l'accesso alle risorse in base alle condizioni

CIS Controls v8 ID(s) ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
3.3, 6.4, 13.5 AC-2, AC-3, AC-6 7.2

Principio di sicurezza: convalidare in modo esplicito i segnali attendibili per consentire o negare l'accesso utente alle risorse, come parte di un modello di accesso senza attendibilità. I segnali da convalidare devono includere l'autenticazione avanzata dell'account utente, l'analisi comportamentale dell'account utente, l'attendibilità del dispositivo, l'appartenenza a utenti o gruppi, le posizioni e così via.

Linee guida di Azure: usare l'accesso condizionale di Azure AD per controlli di accesso più granulari in base alle condizioni definite dall'utente, ad esempio richiedere l'accesso utente da determinati intervalli IP (o dispositivi) per l'uso dell'autenticazione a più fattori. Accesso condizionale di Azure AD consente di applicare i controlli di accesso sulle app dell'organizzazione in base a determinate condizioni.

Definire le condizioni e i criteri applicabili per l'accesso condizionale di Azure AD nel carico di lavoro. Si considerino i casi d'uso comuni seguenti:

  • Obbligo di eseguire l'autenticazione a più fattori per gli utenti con ruoli amministrativi
  • Obbligo di eseguire l'autenticazione a più fattori per le attività di gestione di Azure
  • Blocco degli accessi per gli utenti che provano a usare protocolli di autenticazione legacy
  • Obbligo di usare posizioni attendibili per la registrazione ad Azure AD Multi-Factor Authentication
  • Blocco o concessione dell'accesso da specifiche posizioni
  • Blocco dei comportamenti di accesso rischiosi
  • Obbligo di usare dispositivi gestiti dall'organizzazione per specifiche applicazioni

Nota: i controlli di gestione delle sessioni di autenticazione granulari possono essere implementati anche tramite i criteri di accesso condizionale di Azure AD, ad esempio la frequenza di accesso e la sessione persistente del browser.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni di AWS: creare criteri IAM e definire condizioni per controlli di accesso più granulari in base a condizioni definite dall'utente, ad esempio richiedere accessi utente da determinati intervalli IP (o dispositivi) per l'uso dell'autenticazione a più fattori. Le impostazioni della condizione possono includere singole o più condizioni, nonché le logiche.

I criteri possono essere definiti da sei dimensioni diverse: criteri basati su identità, criteri basati sulle risorse, limiti delle autorizzazioni, criteri di controllo del servizio delle organizzazioni AWS (SCP), Controllo di accesso Lists (ACL) e criteri di sessione.

Implementazione di AWS e contesto aggiuntivo:

Linee guida per GCP: creare e definire condizioni IAM per controlli di accesso più granulari basati su attributi in base alle condizioni definite dall'utente, ad esempio richiedere l'accesso utente da determinati intervalli IP (o dispositivi) per l'uso dell'autenticazione a più fattori. Le impostazioni della condizione possono includere una o più condizioni e logica.

Le condizioni vengono specificate nelle associazioni di ruolo dei criteri di autorizzazione di una risorsa. Gli attributi della condizione sono basati sulla risorsa richiesta, ad esempio il tipo o il nome, o i dettagli sulla richiesta, ad esempio il timestamp o l'indirizzo IP di destinazione.

Implementazione GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

IM-8: Limitare l'esposizione delle credenziali e dei segreti

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
16.9, 16.12 IA-5 3.5, 6.3, 8.2

Principio di sicurezza: assicurarsi che gli sviluppatori di applicazioni gestiscono in modo sicuro le credenziali e i segreti:

  • Evitare di incorporare le credenziali e i segreti nei file di codice e configurazione
  • Usare l'insieme di credenziali delle chiavi o un servizio di archivio chiavi sicuro per archiviare le credenziali e i segreti
  • Cercare le credenziali nel codice sorgente.

Nota: questa operazione viene spesso regolamentata e applicata tramite un ciclo di vita di sviluppo software sicuro (SDLC) e un processo di sicurezza DevOps.

Linee guida di Azure: quando si usa un'identità gestita non è un'opzione, assicurarsi che i segreti e le credenziali vengano archiviati in posizioni sicure, ad esempio Azure Key Vault, anziché incorporarli nei file di codice e configurazione.

Se si usa Azure DevOps e GitHub per la piattaforma di gestione del codice:

  • Implementare Azure DevOps Credential Scanner per identificare le credenziali all'interno del codice.
  • Per GitHub, usare la funzionalità di analisi dei segreti nativa per identificare le credenziali o altre forme di segreti all'interno del codice.

I client come Funzioni di Azure, i servizi app di Azure e le macchine virtuali possono usare identità gestite per accedere in modo sicuro ad Azure Key Vault. Vedere Controlli di protezione dei dati correlati all'uso di Azure Key Vault per la gestione dei segreti.

Nota: Azure Key Vault fornisce la rotazione automatica per i servizi supportati. Per i segreti che non possono essere ruotati automaticamente, assicurarsi che vengano ruotati manualmente e eliminati periodicamente quando non sono più in uso.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: quando si usa un ruolo IAM per l'accesso alle applicazioni non è un'opzione, assicurarsi che i segreti e le credenziali vengano archiviati in posizioni sicure, ad esempio AWS Secret Manager o Systems Manager Parameter Store, anziché incorporarli nei file di codice e configurazione.

Usare CodeGuru Reviewer per l'analisi del codice statico che può rilevare i segreti hardcoded nel codice sorgente.

Se si usa Azure DevOps e GitHub per la piattaforma di gestione del codice:

  • Implementare Azure DevOps Credential Scanner per identificare le credenziali all'interno del codice.
  • Per GitHub, usare la funzionalità di analisi dei segreti nativa per identificare le credenziali o altre forme di segreti all'interno del codice.

Nota: Secrets Manager fornisce la rotazione automatica dei segreti per i servizi supportati. Per i segreti che non possono essere ruotati automaticamente, assicurarsi che vengano ruotati manualmente e eliminati periodicamente quando non sono più in uso.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni su GCP: quando si usa un account del servizio gestito da Google per l'accesso alle applicazioni non è un'opzione, assicurarsi che i segreti e le credenziali vengano archiviati in posizioni sicure, ad esempio Google Cloud Secret Manager anziché incorporarli nel codice e nei file di configurazione.

Usare l'estensione Google Cloud Code nell'ambiente di sviluppo integrato (ambiente di sviluppo integrato) di Google Cloud Code per integrare i segreti gestiti da Secret Manager nel codice.

Se si usa Azure DevOps o GitHub per la piattaforma di gestione del codice:

  • Implementare Azure DevOps Credential Scanner per identificare le credenziali all'interno del codice.
  • Per GitHub, usare la funzionalità di analisi dei segreti nativa per identificare le credenziali o altre forme di segreti all'interno del codice.

Nota: configurare le pianificazioni di rotazione per i segreti archiviati in Secret Manager come procedura consigliata.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

IM-9: proteggere l'accesso utente alle applicazioni esistenti

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
6.7, 12.5 AC-2, AC-3, SC-11 N/D

Principio di sicurezza: in un ambiente ibrido, in cui sono disponibili applicazioni locali o applicazioni cloud non native usando l'autenticazione legacy, prendere in considerazione soluzioni come cloud access security broker (CASB), proxy dell'applicazione, Single Sign-On (SSO) per gestire l'accesso a queste applicazioni per i vantaggi seguenti:

  • Applicare un'autenticazione avanzata centralizzata
  • Monitorare e controllare le attività degli utenti finali rischiose
  • Monitorare e correggere le attività legacy di rischio
  • Rilevare e impedire la trasmissione dei dati sensibili

Linee guida di Azure: Proteggere le applicazioni cloud locali e non native usando l'autenticazione legacy connettendole a:

  • Azure AD Application Proxy e configurare l'autenticazione basata su intestazione per consentire l'accesso Single Sign-On (SSO) alle applicazioni per gli utenti remoti, convalidando in modo esplicito la attendibilità di utenti e dispositivi remoti con Accesso condizionale di Azure AD. Se necessario, usare una soluzione di Software-Defined Perimetrale (SDP) di terze parti che può offrire funzionalità simili.
  • Microsoft Defender for Cloud Apps, che serve un servizio CASB (Cloud Access Security Broker) per monitorare e bloccare l'accesso utente alle applicazioni SaaS non approvate.
  • I controller e le reti di recapito di applicazioni di terze parti esistenti.

Nota: le VPN vengono comunemente usate per accedere alle applicazioni legacy e spesso hanno solo il controllo di accesso di base e il monitoraggio limitato della sessione.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: seguire le indicazioni di Azure per proteggere le applicazioni cloud locali e non native usando l'autenticazione legacy connettendole a:

  • Azure AD Application Proxy e configurare la configurazione basata su intestazione per consentire l'accesso Single Sign-On (SSO) alle applicazioni per gli utenti remoti, convalidando in modo esplicito la attendibilità di utenti e dispositivi remoti con Accesso condizionale di Azure AD. Se necessario, usare una soluzione di Software-Defined perimetrale (SDP) di terze parti che può offrire funzionalità simili.
  • Microsoft Defender for Cloud Apps, che funge da servizio casB (Cloud Access Security Broker) per monitorare e bloccare l'accesso utente alle applicazioni SaaS non approvate.
  • Controller e reti di recapito di applicazioni di terze parti esistenti

Nota: le VPN vengono comunemente usate per accedere alle applicazioni legacy e spesso hanno solo il controllo di accesso di base e il monitoraggio limitato della sessione.

Implementazione di AWS e contesto aggiuntivo:

Linee guida per GCP: usare Google Cloud Identity-Aware Proxy (IAP) per gestire l'accesso alle applicazioni basate su HTTP all'esterno di Google Cloud, incluse le applicazioni locali. IAP usa intestazioni firmate o l'API Users all'interno di un ambiente standard del motore di app. Se necessario, usare una soluzione SDP (Perimeter) Software-Defined di terze parti che può offrire funzionalità simili.

È anche possibile usare Microsoft Defender for Cloud Apps che funge da servizio CASB (Cloud Access Security Broker) per monitorare e bloccare l'accesso utente alle applicazioni SaaS non approvate.

Nota: le VPN vengono comunemente usate per accedere alle applicazioni legacy e spesso hanno solo il controllo di accesso di base e il monitoraggio limitato della sessione.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):