Considerazioni sulla sicurezza per Red Hat Enterprise Linux in Azure

Questo articolo descrive considerazioni e consigli per implementare la sicurezza nell'ambiente Red Hat Enterprise Linux (RHEL). Per garantire la sicurezza per i sistemi RHEL, usare un approccio destinato a più aree. La sicurezza richiede che tutti i team interagiscono per proteggere i carichi di lavoro. I prodotti o le piattaforme distribuiti non possono garantire esclusivamente la sicurezza per l'ambiente in uso.

Implementare e rispettare un processo rigoroso che comprende componenti comportamentali, amministrativi e di progettazione. Quando si distribuisce RHEL in una zona di destinazione di Azure, è necessario valutare diversi fattori di sicurezza. Per creare un ambiente cloud sicuro e resiliente, implementare un approccio strategico che applica meccanismi di sicurezza di Azure e Red Hat.

Considerazioni relative alla progettazione

Per garantire la sicurezza per i sistemi RHEL, in Azure o altrove, assicurarsi di iniziare con il contenuto verificato e convalidato. Negli ambienti cloud moderni, i file binari e il codice possono provenire da un'ampia gamma di origini. Come prima considerazione per la distribuzione, proteggere la supply chain del software.

Protezione avanzata delle immagini

È possibile trovare immagini in Azure Marketplace e sezioni offerte di prodotti privati in cui Red Hat o Red Hat Limited in Europa, Medio Oriente e Africa (EMEA) pubblica il record. Red Hat e Microsoft verificano e convalidano queste immagini per garantire l'integrità dell'origine e fornire configurazioni predefinite sicure per le istanze del sistema operativo RHEL.

Per soddisfare i requisiti di sicurezza del runtime dell'organizzazione per il carico di lavoro di destinazione, configurare correttamente le istanze compilate da queste immagini. Per semplificare le misure di sicurezza, usare le immagini pubblicate da Red Hat da Azure Marketplace per distribuire i sistemi RHEL. Seguire le indicazioni di Red Hat per le specifiche di sistema e di immagine per il carico di lavoro. Per ridurre la superficie di attacco, iniziare con un'immagine RHEL minima ottimizzata per Azure. Non è necessario creare e configurare tutte le istanze di questa immagine di base. Per soddisfare vari requisiti di protezione avanzata, è consigliabile usare componenti componibili per creare immagini specifiche del carico di lavoro.

È anche possibile usare le procedure GitOps per sviluppare pipeline di immagini. Questo approccio è una metodologia superiore. Queste pipeline layerranno i componenti componibili, definiti come codice di configurazione, nell'immagine iniziale per produrre le immagini del carico di lavoro.

Per usare in modo efficace le immagini, implementare le considerazioni seguenti:

• Creare un'immagine di base con protezione avanzata che sia conforme al modello con privilegi minimi per fornire una solida base.

• Configurare il software e la sicurezza a livello insieme per promuovere il riutilizzo e seguire le procedure consigliate standard per l'ambiente operativo e DevSecOps.

• Usare modelli di composizione per le immagini per ridurre le attività di test e qualificazione e ridurre i costi di manutenzione.

• Usare i modelli di composizione per aumentare la flessibilità e accelerare il tempo di recapito per i nuovi carichi di lavoro.

• Automatizzare il processo di compilazione, test e recapito delle immagini per il modello.

Aggiornare le immagini

È anche consigliabile aggiornare regolarmente le immagini. Le istanze temporanee hanno probabilmente un'immagine più aggiornata perché in genere vengono distribuite da un'immagine corrente. È tuttavia consigliabile aggiornare regolarmente le istanze permanenti usando un sistema di applicazione di patch centrale. Questo passaggio consente di esaminare la condizione dei sistemi con patch nell'ambiente in uso. Quando si riduce al minimo la variabilità della distribuzione, il monitoraggio del rumore viene ridotto ed è possibile identificare le anomalie in modo più accurato e rapido. Questo approccio aumenta il tasso di successo delle attività di rilevamento e correzione automatizzate.

Per mantenere controlli di accesso rigorosi, è consigliabile implementare un sistema centralizzato. Molti progetti open source e applicazioni commerciali off-the-shelf offrono semplici esempi di distribuzione che usano account locali o chiavi pubbliche distribuite localmente. Questi esempi possono fornire una configurazione sicura, ma man mano che il footprint del cloud si espande, lo sforzo per mantenere la configurazione localizzata, anche con l'automazione, può diventare problematico. Il carico di automazione aumenta in modo lineare con ogni istanza, ma la registrazione della sicurezza e il carico di monitoraggio possono aumentare a una velocità esponenziale. Queste modifiche generano un carico eccessivo sulle risorse di calcolo, archiviazione e analisi. Il controllo di accesso centralizzato riduce i punti di configurazione, riducendo così l'automazione e il carico di registrazione, riducendo al minimo le modifiche e semplificando il controllo mantenendo controlli rigorosi sull'accesso alle risorse.

Nelle aree in cui il carico di lavoro richiede la conformità agli standard di crittografia e alle baseline di conformità, è consigliabile usare funzionalità della piattaforma integrate che supportano standard aperti per garantire la compatibilità con i carichi di lavoro cloud. Red Hat e Microsoft rispettano e partecipano a organismi di standard globali e forniscono strumenti appropriati. Ad esempio, molti file di configurazione in un'istanza singola hanno una configurazione di crittografia crittografica per i servizi di sistema e le applicazioni. La varianza può verificarsi facilmente tra i sistemi all'interno di un carico di lavoro di destinazione e in una flotta. Per definire le misurazioni di conformità, è consigliabile usare standard aperti. Sia gli strumenti Red Hat che gli strumenti Microsoft usano formati di file standardizzati per fornire i dati di configurazione e vulnerabilità più recenti. Red Hat fornisce feed OVAL (Open Vulnerability and Assessment Language) aggiornati del team Red Hat Product Security per i componenti della piattaforma Red Hat.

Azure offre opportunità uniche per usare funzionalità specifiche del cloud e mantenere le procedure consigliate per la sicurezza e la conformità. Le funzionalità e i servizi di sicurezza all'interno dell'infrastruttura di Azure includono:

• Avvio attendibile per le macchine virtuali: BIOS e configurazione dell'istanza sicura. È possibile usare l'avvio attendibile per le macchine virtuali per proteggere il processo di avvio, garantendo l'avvio delle macchine virtuali con codice verificato.

• Crittografia dischi di Azure in Azure Key Vault: crittografare i dati inattivi. Per proteggere i dati inattivi, usare crittografia dischi di Azure in Key Vault per gestire chiavi e segreti di crittografia. Key Vault supporta due tipi di contenitori: insiemi di credenziali e pool di moduli di protezione hardware gestiti. È possibile archiviare chiavi, segreti e certificati supportati da HSM negli insiemi di credenziali.

• Microsoft Defender per il cloud: garantire il controllo centralizzato del sistema. Defender per il cloud può fornire un viewport centralizzato per la gestione unificata della sicurezza e la protezione dalle minacce.

Suggerimenti per la progettazione

Quando si progettano ambienti RHEL in Azure, sfruttare le funzionalità di sicurezza native di Red Hat e le funzionalità di sicurezza cloud di Azure per garantire una distribuzione affidabile, sicura ed efficiente. Iniziare con un'immagine avanzata e compilata con file binari convalidati noti. Le immagini RHEL in Azure Marketplace sono semplificate per le prestazioni e la sicurezza del cloud. Se si hanno requisiti di sicurezza specifici per l'azienda, è consigliabile iniziare con l'immagine personalizzata e con protezione avanzata compilata dai file binari di origine Red Hat. Red Hat Satellite può gestire e gestire codice Red Hat, Microsoft e partner o il codice dell'applicazione personalizzata. Satellite può convalidare il codice tramite credenziali e firme del contenuto gestito. RHEL verifica la coerenza e l'autenticità del software dall'origine al disco.

Quando si usano gli strumenti di gestione di Azure e Red Hat per sviluppare flussi di lavoro automatizzati, Red Hat consiglia di usare raccolte di Ansible Automation Platform certificate.

Assicurarsi che i flussi di lavoro:

• Generare, gestire e testare immagini di base e carico di lavoro.
• Testare e distribuire istanze temporanee.
• Test del ciclo di patch e recapito di istanze di macchine virtuali persistenti.
• Usare le pipeline di automazione. Le pipeline di automazione riducono significativamente il lavoro di gestione, garantiscono un'applicazione coerente dei criteri, migliorano il rilevamento delle anomalie e accelerano la correzione in tutte le zone di destinazione RHEL.

Prendere in considerazione anche l'uso di Azure Compute Gallery. È possibile compilare l'immagine Red Hat con tutti i meccanismi di sicurezza necessari usati nell'organizzazione e creare un'immagine di tale macchina virtuale. È quindi possibile condividere immagini conformi alla sicurezza tra sottoscrizioni e aree nell'ambiente Azure. È anche possibile usare il controllo delle versioni per un maggiore controllo granulare sulle immagini delle macchine virtuali. Questo approccio consente di unificare le patch di sicurezza delle istanze di calcolo e gli strumenti usati nell'ambiente.

Prendere in considerazione l'implementazione di Azure Update Manager come parte del processo di gestione degli aggiornamenti. Gestione aggiornamenti è un servizio unificato che è possibile usare per monitorare gli aggiornamenti nelle distribuzioni. Usare Gestione aggiornamenti per esaminare l'intera flotta di computer in Azure, in locale e in altri cloud.

Gestire identità e accessi

Per applicare centralmente criteri di accesso rigorosi, integrare Red Hat Identity Management (IdM). IdM usa trust e integrazioni openID Connect per consolidare l'implementazione nativa linux delle funzionalità seguenti in un modello di sicurezza aziendale senza sincronizzazione delle credenziali.

• Controllo degli accessi in base al ruolo
• Controllo degli accessi in base all'host
• Criteri di escalation dei privilegi
• Criteri di mapping utente SELinux
• Altri servizi Linux critici

Rispetto alle distribuzioni Linux tradizionali, questo approccio genera vantaggi, ad esempio:

• Controllo delle modifiche semplificato tramite punti di tocco di automazione ridotti.
• Riduzione del carico correlato alla registrazione e all'analisi.
• Conformità ai requisiti di controllo dell'autenticazione.
• Coerenza dei criteri.

IdM offre vantaggi per la gestione dei criteri di sicurezza linux centralizzati.

Red Hat consiglia di abilitare ed eseguire SELinux in tutte le istanze basate su RHEL, inclusi gli ambienti di sviluppo, test e produzione. Tutte le immagini e le installazioni prodotte da Red Hat possono eseguire SELinux in modalità di applicazione per impostazione predefinita. Quando si progettano distribuzioni di carichi di lavoro, è possibile eseguire SELinux in modalità permissiva per l'intera istanza o per i singoli servizi all'interno dell'istanza. I team di sviluppo, sicurezza e operazioni possono quindi determinare le caratteristiche di accesso delle applicazioni e usare i dati dei log di controllo con gli strumenti SELinux per generare criteri SELinux appropriati per il carico di lavoro di destinazione.

Gli strumenti di generazione dei criteri SELinux possono generare file di criteri basati su RPM da includere nei repository di contenuto per la distribuzione di immagini standardizzate. I team di sviluppo, sicurezza e operazioni possono fornire elementi upstream in modo iterativo all'interno della pipeline. Dopo il test determina che non vengono generate violazioni SELinux, è possibile impostare la configurazione SELinux per applicare la modalità. Violazioni SELinux generate durante la produzione indicano una deviazione significativa dal comportamento accettabile dell'applicazione. È consigliabile contrassegnarli e indagare su queste violazioni. Usare SELinux per offrire visibilità completa e gestione proattiva delle minacce.

Per definire i ruoli controllo degli accessi in base al ruolo assegnati ai computer RHEL, comprendere i ruoli e le responsabilità del team. I team pertinenti potrebbero richiedere l'accesso con privilegi elevati alle macchine virtuali. Prendere in considerazione collaboratore macchina virtuale, lettore di macchine virtuali e ruoli simili per accedere alle macchine virtuali. Prendere in considerazione l'accesso JUST-In-Time se non è necessario l'accesso permanente. Prendere in considerazione le identità gestite se il sistema RHEL deve eseguire l'autenticazione con Azure. Le identità gestite assegnate dal sistema offrono maggiore sicurezza rispetto alle entità servizio e sono associate alla risorsa della macchina virtuale. Oltre ai ruoli controllo degli accessi in base al ruolo, prendere in considerazione l'accesso condizionale per gli utenti che devono accedere all'ambiente Azure. Usare l'accesso condizionale per limitare l'accesso utente all'ambiente Azure in base alla posizione, all'indirizzo IP e ad altri criteri.

Usare il software antivirus

Assicurarsi di disporre del software antivirus appropriato nel computer RHEL. Prendere in considerazione l'onboarding Microsoft Defender per endpoint in Linux per la protezione dalle vulnerabilità più recenti. Tenere presente che non è consigliabile abilitare Defender per il cloud Standard nei computer RHEL usati per ospitare i database SAP. Assicurarsi che ogni computer e carico di lavoro RHEL possa eseguire il software di endpoint-protection.

Gestire i segreti

Red Hat consiglia di impostare criteri di crittografia a livello di sistema in tutte le istanze ove possibile. È possibile caratterizzare le distribuzioni cloud in base alla diversità. I team del carico di lavoro scelgono librerie, linguaggi, utilità e provider di crittografia personalizzati per soddisfare le esigenze delle proprie soluzioni. L'implementazione degli standard, il factoring dei componenti dell'applicazione, la componibilità e altre tecniche possono ridurre la variabilità, ma è possibile configurare le impostazioni di crittografia per applicazioni e servizi in più posizioni all'interno di una determinata istanza.

Per configurare in modo sensibile i nuovi componenti, è necessario un impegno significativo e spesso una conoscenza crittografica approfondita. I criteri di crittografia non aggiornati o configurati in modo non corretto creano rischi. Un criterio di crittografia a livello di sistema allinea la configurazione dei sottosistemi di crittografia principali, che copre i protocolli Transport Layer Security (TLS), Internet Protocol Security (IPSec), DOMAIN Name System Security Extensions (DNSSEC) e Kerberos. Un criterio PREDEFINITO crittografico A livello di sistema RHEL implementa una configurazione conservativa che elimina un'intera classe di minacce disabilitando i protocolli di comunicazione legacy, ad esempio TLS v1.1 e versioni precedenti. I criteri FUTURE e FIPS forniscono configurazioni più rigide. È anche possibile creare criteri personalizzati.

È possibile incorporare gli strumenti di controllo e conformità del sistema RHEL. Concentrarsi sull'analisi e la correzione automatizzate allineate agli standard del settore.

• Il daemon di controllo RHEL viene controllato e viene eseguito il journal del daemon di registrazione centrale. Monitoraggio di Azure può inserire dati da auditd e journald per monitorare gli eventi di sicurezza del sistema RHEL e alimentare Microsoft Sentinel o altri servizi siem (Security Information and Event Management).

• I sistemi RHEL che devono soddisfare la conformità di Defense Information Systems Agency Security Implementation Guide (DISA-STIG) richiedono l'utilità Advanced Intrusion Detection Environment (AIDE). È consigliabile registrare l'output aide in Azure.

Monitorare e integrare ansible Automation Platform per identificare, inviare avvisi e correggere i file di sistema critici.

Usare componenti gratuiti a livello di sistema operativo in tutte le istanze RHEL basate su Azure.

• Applicare i criteri di esecuzione del codice: usare il daemon fapolicyd per limitare le applicazioni che possono essere eseguite nell'istanza di RHEL.

• Gestire il traffico in ingresso e in uscita dell'istanza: usare firewall con i gruppi di sicurezza di rete di Azure per gestire in modo efficace il traffico verso nord e verso sud verso le macchine virtuali.

• Gestire centralmente la configurazione tramite l'automazione: usare la metodologia GitOps per garantire una gestione coerente della configurazione durante la distribuzione e continuamente attraverso le operazioni quotidiane dei carichi di lavoro RHEL.

• Implementare la modalità di conformità FIPS per i carichi di lavoro per enti pubblici: assicurarsi che le istanze RHEL designate vengano eseguite in modalità FIPS per rispettare gli standard di crittografia. Usare le offerte di conformità di Azure per un comportamento di conformità completo.

• Eseguire sempre SELinux: usare SELinux in modalità permissiva per identificare i profili di accesso al carico di lavoro e garantire i criteri appropriati per eseguire SELinux in modalità di applicazione nelle macchine virtuali RHEL. SELinux riduce significativamente la superficie di attacco sulle applicazioni e sui servizi eseguiti in Azure.

Registrare i server RHEL in Red Hat Insights tramite Red Hat Satellite. Red Hat Insights sfrutta l'analisi del database di risoluzione dei problemi di Red Hat. Insights usa questa analisi per identificare e generare in modo proattivo correzioni per problemi di distribuzione e configurazione prima di influire sulle operazioni. Questa strategia migliora la postura di sicurezza e l'efficienza operativa. Ogni sottoscrizione RHEL include Insights. Tutte le sottoscrizioni basate su cloud RHEL includono una sottoscrizione Red Hat Satellite. In alternativa, è possibile acquistare una sottoscrizione Red Hat Satellite con le sottoscrizioni RHEL di Cloud Access.

Configurare la rete

È possibile applicare gruppi di sicurezza di rete a livello di interfaccia di rete o a livello di subnet. È consigliabile il livello di subnet, a meno che non siano necessari requisiti specifici per un gruppo di sicurezza di rete a livello di interfaccia di rete. Questo approccio semplifica la gestione delle comunicazioni di rete. È possibile usare i gruppi di sicurezza delle applicazioni per consentire la comunicazione delle applicazioni, che segmenta in modo olistico la comunicazione tra subnet. Determinare l'approccio più adatto allo scenario e assicurarsi che i computer RHEL dispongano dell'accesso appropriato a Internet per i repository necessari. Potrebbe essere necessario consentire gli URL dell'elenco per questi repository negli ambienti più bloccati. Gli endpoint privati assicurano che l'unico traffico che una risorsa di Azure possa ricevere per impostazione predefinita è il traffico proveniente dalla rete di Azure, incluse le connessioni dall'ambiente locale, se si dispone di un gateway di Azure.

Implementare strumenti SIEM o SOAR

Prendere in considerazione Microsoft Sentinel per strumenti di orchestrazione, automazione e risposta (SOAR) di sicurezza o strumenti SIEM per i sistemi RHEL. Microsoft Sentinel usa l'intelligenza artificiale per adattare il modo in cui rileva le minacce al sistema. È possibile automatizzare le risposte agli attacchi tramite runbook. Usare Microsoft Sentinel per il rilevamento proattivo delle minacce, la ricerca delle minacce e la risposta alle minacce.

Prendere in considerazione il confidential computing

RHEL include un'immagine riservata per alcune opzioni del sistema operativo RHEL. Prendere in considerazione i casi d'uso del confidential computing.

Passaggi successivi

• Gestione e monitoraggio per RHEL in Azure