Considerazioni sulla gestione delle identità e degli accessi per Red Hat Enterprise Linux in Azure
Questo articolo descrive le considerazioni sulla gestione delle identità e degli accessi (IAM) per la distribuzione dell'acceleratore di zona di destinazione di Azure Red Hat Enterprise Linux (RHEL). IAM è una parte fondamentale delle impostazioni di sicurezza dell'organizzazione. Il sistema operativo RHEL e le applicazioni in esecuzione devono usare le identità esterne per ridimensionare le operazioni. Progettare attentamente l'implementazione IAM del cloud ibrido per garantire un'integrazione e una gestione uniformi del panorama dell'istanza nel cloud di Azure. Red Hat e Microsoft collaborano per garantire l'integrazione nativa tra RHEL, Windows Server Active Directory e Microsoft Entra Privileged Identity Management (PIM).
Considerazioni relative alla progettazione
Implementare queste considerazioni di progettazione e consigli per creare un piano IAM che soddisfi i requisiti dell'organizzazione per la distribuzione di Azure RHEL.
In generale, una distribuzione RHEL in un ambiente cloud ibrido deve:
- Usare un'autorità di identità Linux centralizzata che si integra con il sottosistema di sicurezza del sistema operativo, dove possibile per aumentare l'efficienza operativa e la visibilità del controllo di accesso. Usare un'autorità di gestione delle identità Linux centralizzata in modo che sia possibile:
- Gestire l'autorizzazione specifica dell'host per il sistema operativo Linux.
- Ottenere coerenza tra distribuzioni ibride.
- Delegare l'autenticazione a origini esterne.
- Semplificare il processo di verifica del controllo di accesso.
- Garantire l'uniformità.
- Accelerare il processo di implementazione.
- Migliorare il framework di sicurezza di un'infrastruttura Linux cloud ibrida.
- Applicare i criteri in modo uniforme a più istanze contemporaneamente. Usare questo approccio in modo che non sia necessario usare l'automazione per modificare ogni istanza dell'infrastruttura quando si verifica una modifica.
- Supportare il controllo di accesso a livello di istanza centralizzato, sicuro e differenziato usando il controllo degli accessi basato su host, la delega e altre regole.
- Gestire centralmente le regole di escalation dei privilegi a livello di sistema nell'autorità di identità. Applicare questo criterio in modo coerente tra singole istanze e gruppi di istanze all'interno dell'ambiente.
- Supportare o fornire funzionalità moderne di strumenti di automazione per testare e implementare in modo coerente le configurazioni di sicurezza in diversi sistemi. È consigliabile progettare l'automazione della sicurezza in una distribuzione cloud ibrida fin dall'inizio.
- Supportare l'integrazione delle funzionalità legacy per l'accesso Single Sign-On (SSO) legacy per semplificare i carichi di migrazione, mantenere la coerenza delle operazioni di sicurezza e supportare le integrazioni moderne per le distribuzioni basate sul cloud.
Implementare l’autenticazione
Le distribuzioni Linux tendono a implementare ambienti di autenticazione utente locale a livello di sistema operativo. L'autenticazione e l'autorizzazione a livello di sistema, la proprietà dell'oggetto, le autorizzazioni per gli oggetti e le integrazioni dell'applicazione sono basate su questo modello. Le applicazioni del sistema operativo usano queste identità in molti modi. Ad esempio:
- I processi dell'applicazione vengono eseguiti in alcune identità utente.
- I processi dell'applicazione creano o accedono a file attribuiti a utenti e gruppi specifici.
- Un set di gruppi a cui appartiene un utente viene corretto quando esegue l'accesso. Le modifiche di appartenenza vengono applicate solo alle nuove sessioni.
- Il flusso di autenticazione e autorizzazione di un utente è direttamente associato alla sessione di accesso attiva in seguito all'autenticazione.
In precedenza, le sessioni della shell avviate dall'utente basate su queste identità erano i principali mezzi di interazione con le applicazioni in Linux. Con il passaggio alle interfacce utente orientate al Web, ai dispositivi mobili e al cloud, le applicazioni che usano questo modello di consumo di identità sono meno comuni.
Attualmente, queste identità sono in genere un meccanismo di supporto quando si eseguono applicazioni o servizi isolati in un sistema operativo. Le identità a livello di applicazione non devono necessariamente corrispondere agli utenti a livello di sistema. Tuttavia, l'identità a livello di sistema è ancora fondamentale per eseguire e proteggere in modo efficiente un'infrastruttura Linux eseguita su larga scala in un ambiente cloud.
Per distribuzioni cloud di piccole dimensioni o distribuzioni pilota, queste metodologie IAM tradizionali offrono un modo semplice per iniziare. Con la scalabilità di un ambiente, questi meccanismi sono più difficili da gestire, anche se si usa l'automazione. Con l'aumentare del numero di punti di tocco, aumenta anche il volume dei dati di configurazione, i dati di registrazione, i dati di deriva e l'analisi richiesta. Per gestire questa complessità, è possibile centralizzare IAM.
È possibile usare vari strumenti che forniscono sicurezza centralizzata all'interno di un ambiente Linux. Assicurarsi che lo strumento soddisfi i requisiti aziendali e tecnici. RHEL include un elenco generale di compatibilità software per la sicurezza. È possibile integrare la sicurezza a livello di applicazione usando Microsoft Entra ID nativo di Azure, soluzioni software open source commerciali come Okta, SailPoint o JumpCloud o soluzioni di progetto open source come Keycloak. Esistono anche diverse soluzioni di sicurezza a livello di sistema operativo. È possibile distribuire diverse soluzioni commerciali e progetti software open source nel cloud.
Consigli di progettazione per Red Hat Identity Management
Questa sezione descrive le raccomandazioni di progettazione per IAM nelle zone di destinazione di Azure per RHEL quando si usa Red Hat Identity Management (IdM) e Red Hat SSO. Questi servizi sono allineati al modello di adozione standard di Cloud Adoption Framework per Azure e Red Hat Infrastructure. Le raccomandazioni estendono i principi usati per implementare una distribuzione cloud ibrida.
Red Hat IdM offre un modo centralizzato per gestire archivi di identità, autenticazione, criteri e autorizzazione in un dominio basato su Linux. Red Hat IdM si integra in modo nativo con Windows Server Active Directory e Microsoft Entra ID ed è incluso in RHEL. Se si estende il Active Directory locale ad Azure, è possibile trarre vantaggio dalla funzionalità di attendibilità di Windows Server Active Directory nativa di Red Hat IdM. Analogamente, se si adotta l'ID Microsoft Entra o si usa un provider di identità alternativo, è possibile usare Red Hat IdM e Red Hat SSO per una perfetta integrazione. Red Hat SSO è un'implementazione aziendale supportata del progetto open source Keycloak. Viene fornito senza costi aggiuntivi con varie sottoscrizioni di Red Hat, tra cui Red Hat Ansible Automation Platform. Red Hat consiglia di implementare Red Hat IdM all'interno della distribuzione RHEL in Azure. Il diagramma seguente illustra una distribuzione della sottoscrizione di gestione RHEL.
I componenti IAM per la distribuzione di Red Hat in Azure usano il modello di scalabilità delle sottoscrizioni per fornire controllo e isolamento aggiuntivi agli strumenti di gestione. I sistemi primari e i sistemi di replica Red Hat IdM e le istanze di Red Hat SSO risiedono in una sottoscrizione di Red Hat Management con altri strumenti. La sottoscrizione fornisce gruppi di risorse che è possibile usare in tutta l'implementazione per fornire servizi localizzati e disponibilità elevata.
Il diagramma seguente illustra un'architettura di distribuzione di zona Red Hat IdM.
Il diagramma seguente illustra una distribuzione a disponibilità elevata di Red Hat IdM tra aree e zone di disponibilità.
Questa architettura include server IdM all'interno di ogni area che vengono replicati tra loro e in una replica nascosta. Esistono almeno due collegamenti di replica tra aree. Le repliche nascoste fungono da punti di backup perché è possibile portarle offline come backup completi senza influire sulla disponibilità.
I client IdM possono bilanciare il carico e il failover tra i server IdM in base all'individuazione dei record del servizio o tramite un elenco di server nel file sssd.conf . Non usare il bilanciamento del carico esterno o le configurazioni a disponibilità elevata con IdM.
Prendere in considerazione le raccomandazioni di progettazione critiche seguenti per la distribuzione di Red Hat IdM.
Implementare l'automazione dell'infrastruttura come codice (IaC) per le operazioni di distribuzione, configurazione e giorno 2 di Red Hat IdM. Per automatizzare Red Hat IdM, è possibile usare la raccolta Ansible certificata redhat.rhel_idm tramite Ansible Automation Hub. Per automatizzare l'accesso Single Sign-On di Red Hat, è possibile usare la raccolta Di Ansible certificata redhat.sso .
Implementare il supporto dell'identità aziendale e dell'applicazione. Comprendere quali servizi sono esposti dalle istanze e quali servizi richiedono l'autenticazione a livello di sistema operativo e a livello di applicazione. Usare Red Hat IdM per implementare la sicurezza a livello di sistema operativo, le regole di controllo degli accessi in base all'host e le regole di gestione dell'escalation dei privilegi, ad esempio sudo. È anche possibile usare Red Hat IdM per eseguire il mapping dei criteri SELinux e mappare le identità per i sistemi legacy. Usare l'accesso Single Sign-On di Red Hat per integrare origini di autenticazione aziendali con applicazioni basate sul Web.
Usare la gestione centralizzata delle identità per la risposta alle minacce. È possibile invalidare o ruotare immediatamente le credenziali compromesse tra distribuzioni su scala cloud.
Determinare il percorso di integrazione iniziale per i provider di identità nativi di Azure, ad esempio Windows Server Active Directory e Microsoft Entra ID. Red Hat IdM supporta diverse opzioni di integrazione. È possibile aggiungere e rimuovere integrazioni all'interno di IdM, ma è consigliabile valutare i requisiti esistenti, gli effetti della migrazione e il costo della modifica nel tempo.
Configurare le distribuzioni primarie e le distribuzioni di repliche Red Hat IdM per ridurre le latenze e assicurarsi che non vi sia un singolo punto di errore nella replica. Le distribuzioni geografiche delle istanze RHEL influiscono sull'infrastruttura Red Hat IdM. È possibile usare Red Hat IdM per distribuire più repliche Red Hat IdM, che offrono prestazioni migliorate, bilanciamento del carico, failover e disponibilità elevata. Le distribuzioni possono essere costituite da un massimo di 60 repliche. Le distribuzioni di repliche devono garantire che i sistemi si estendono su domini di errore. Gestire gli aggiornamenti della replica IdM di Red Hat tramite automazione per garantire la coerenza della replica. Usare topologie di replica consigliate da Red Hat.
Assicurarsi di configurare correttamente la configurazione dell'attendibilità di Active Directory di Windows Server e la configurazione DNS (Domain Name System). Quando si configura Red Hat IdM e Windows Server Active Directory, sia i server Active Directory locale che i server Red Hat IdM devono risiedere nei propri domini DNS o sottodomini. Questo requisito è dovuto ai record del servizio Kerberos e all'individuazione del servizio Kerberos. Cloud Adoption Framework consiglia la risoluzione DNS IP privata per le istanze basate su Azure.
Configurare l'integrazione di Red Hat Satellite per Red Hat IdM per automatizzare le attività di gestione, ad esempio zone DNS in avanti e inversa, registrazione host e generazione e registrazione di chiavi Secure Shell (SSH) all'interno di Red Hat IdM. Red Hat IdM offre un servizio DNS integrato. Combinare questa integrazione con l'attendibilità di Active Directory di Windows Server in modo che gli utenti di Windows Server Active Directory possano accedere facilmente ai sistemi e ai servizi RHEL tramite SSO.
Eseguire il backup delle risorse di Red Hat IdM. In genere, si distribuisce Red Hat IdM in una configurazione di replica multi-main autogestito, ma è anche necessario assicurarsi di disporre di backup di dati e di sistema appropriati. Usare repliche nascoste Red Hat IdM per implementare backup offline completi senza interrompere la disponibilità del servizio. Usare Backup di Azure per la funzionalità di backup crittografata.
Avere un'autorità di certificazione esterna (CA), ca aziendale o ca partner firmare il certificato radice Red Hat IdM quando si distribuisce RHEL con la CA integrata.
Integrare i servizi Red Hat Identity con altri prodotti Red Hat. Red Hat IdM e Red Hat SSO si integrano con Ansible Automation Platform, OpenShift Container Platform, OpenStack Platform, Satellite e strumenti di sviluppo.
Usare la guida alla pianificazione di Identity Management per pianificare l'infrastruttura e integrare i servizi per la distribuzione di Red Hat IdM. Vedere la guida specifica per la versione del sistema operativo di RHEL in cui si prevede di distribuire Red Hat IdM.
Consigli di progettazione per la gestione delle identità nativa di Azure
Usare le macchine virtuali RHEL di Azure con Microsoft Entra ID per limitare i diritti utente e ridurre al minimo il numero di utenti con diritti di amministratore. Limitare i diritti utente per proteggere l'accesso alla configurazione e ai segreti. Per altre informazioni, vedere Ruoli predefiniti di Azure per il calcolo.
Seguire il principio dei privilegi minimi e assegnare le autorizzazioni minime necessarie agli utenti per le attività autorizzate. Concedere l'accesso completo e l'accesso JUST-In-Time solo in base alle esigenze. Usare Microsoft Entra PIM e IAM nelle zone di destinazione di Azure.
Usare le identità gestite per accedere alle risorse RHEL protette da Microsoft Entra ID senza dover gestire i segreti per i carichi di lavoro eseguiti in Azure.
Prendere in considerazione l'uso di Microsoft Entra ID come piattaforma di autenticazione principale e un'autorità di certificazione per SSH in una macchina virtuale Linux.
Proteggere le informazioni riservate, ad esempio chiavi, segreti e certificati. Per altre informazioni, vedere Cloud Adoption Framework per la crittografia e la gestione delle chiavi in Azure.
Implementare l'accesso SSO usando Windows Server Active Directory, Microsoft Entra ID o Active Directory Federation Services (AD FS). Scegliere il servizio in base al tipo di accesso. Usare l'accesso Single Sign-On in modo che gli utenti possano connettersi alle applicazioni RHEL senza un ID utente e una password dopo che il provider di identità centrale li autentica correttamente.
Usare una soluzione, ad esempio LaPS (Local Administrator Password Solution), per ruotare spesso le password di amministratore locale. Per altre informazioni, vedere Valutazione della sicurezza: Utilizzo di Microsoft LAPS.