Abilitare le operazioni di sicurezza

La sicurezza è costantemente tra le principali preoccupazioni quando le aziende iniziano il processo di adozione del cloud.

Poiché lo sviluppo del cloud è rapido, il Chief Information Security Officer (CISO) e i team correlati spesso fanno domande sulla sicurezza prima che il primo carico di lavoro venga distribuito nel cloud. Le domande possono includere gli esempi riportati di seguito.

• Come facciamo a sapere se nel cloud si verificano configurazioni errate e attività rischiose?
• Come ridurre i tempi di risposta quando si verifica un incidente?
• Come applichiamo le best practice di sicurezza?
• In che modo integriamo le operazioni cloud nelle nostre procedure di sicurezza esistenti?
• Come possiamo rimanere aggiornati su nuovi servizi e best practice?
• Come manteniamo la conformità?

Per ulteriori informazioni, vedere La missione del CISO incentrato sul cloud.

Abilita team operazioni di sicurezza in anticipo

Una parte essenziale dell'onboarding su OCI è la collaborazione con i tuoi team di sicurezza all'inizio dell'iniziativa di adozione del cloud. Collabora con i tuoi team operativi e di piattaforma per includere le procedure di sicurezza cloud all'interno di tutte le operations.

Per la maggior parte delle organizzazioni, l'adozione del cloud comporta una curva di apprendimento elevata e un grande cambiamento culturale che si estende su più team. Coinvolgi i tuoi team di sicurezza informatica nelle prime fasi della fase di pianificazione e architettura, invece che in quella successiva, in modo da poter aiutare i team a modellare e allineare i processi con una comprensione comune delle caratteristiche e dei limiti dei servizi cloud. Con i primi feedback dei team di piattaforma e applicazioni, i processi di gestione della sicurezza hanno maggiori probabilità di essere un fattore abilitante e un protettore della tua iniziativa cloud, invece di un blocco tardivo.

Usare Cloud Guard

Cloud Guard è un servizio cloud nativo che consente di monitorare, identificare, ottenere e mantenere un livello di sicurezza elevato in Oracle Cloud. Utilizzare il servizio per esaminare le risorse OCI per individuare punti deboli nella sicurezza correlati alla configurazione e gli operatori e gli utenti OCI per le attività rischiose. Al momento del rilevamento, Cloud Guard può suggerire, assistere o intraprendere azioni correttive in base alla configurazione.

• Cloud Guard utilizza "ricette" del rilevatore e del rispondente gestite dall'utente o da Oracle. Le ricette sono combinazioni di regole che identificano o rispondono a condizioni diverse.
• Puoi indirizzare i compartimenti OCI con recipe del rilevatore in modo che Cloud Guard possa rilevare risorse configurate in modo errato e attività non sicure tra i tenant.
• Cloud Guard offre agli amministratori della sicurezza la visibilità necessaria per valutare e risolvere i problemi di sicurezza del cloud.
• Le incongruenze nella sicurezza possono essere risolte automaticamente con ricette di sicurezza pronte all'uso che consentono di ridimensionare le operazioni di sicurezza in modo rapido ed efficiente.
• È possibile integrare i dettagli dell'evento Cloud Guard, ad esempio la soglia del problema raggiunta o il problema rilevato, con i processi esistenti utilizzando il servizio Notifiche OCI. Ad esempio, le notifiche possono inviare messaggi Slack o e-mail o attivare l'automazione utilizzando funzioni OCI personalizzate.
• Le ricette gestite da Oracle forniscono una baseline eccellente perché OCI le mantiene aggiornate con le regole più recenti. Il team dei criteri di sicurezza (team verde) può modificare ulteriormente queste regole per soddisfare meglio le esigenze della tua organizzazione clonando le recipe gestite da Oracle per creare recipe gestite dall'utente, tra cui la disabilitazione di una regola, la revisione di un livello di rischio e così via.

Scegliere con attenzione l'area generazione report

Quando abiliti Cloud Guard, ti viene chiesto di scegliere un'area di reporting. Considera le seguenti conseguenze della scelta dell'area di reporting:

• L'area di generazione report selezionata esegue il commit dell'organizzazione per garantire la conformità a tutti i requisiti legali del paese in cui è ospitata l'area di generazione report.
• Dopo che Cloud Guard è stato abilitato, non è possibile modificare l'area di reporting senza disabilitare e riabilitare Cloud Guard.
• Tutte le personalizzazioni e i problemi esistenti, inclusa la cronologia, vengono persi quando si disabilita Cloud Guard e è necessario ripristinare manualmente tali personalizzazioni.
• Tutte le chiamate API, ad eccezione dei READ, devono essere effettuate nell'area di reporting. Assicurati di prendere la decisione migliore per la tua area di reporting prima di iniziare i passi per Abilita Cloud Guard.

Modalità di mapping delle destinazioni ai compartimenti

Se è necessario impostare le destinazioni per consentire a compartimenti diversi di essere monitorati in modo diverso, tenere presenti le linee guida riportate di seguito durante il mapping delle destinazioni ai compartimenti.

• Tutti i compartimenti di una destinazione ereditano la configurazione di tale destinazione. Le impostazioni del rilevatore e della regola del rispondente per una destinazione si applicano al compartimento di livello superiore assegnato a tale destinazione e a tutti i compartimenti subordinati sottostanti nella gerarchia dei compartimenti. Se si desidera escludere alcuni compartimenti dal monitoraggio, creare le destinazioni sotto il livello radice e non includere il compartimento radice in alcuna destinazione.
• La destinazione definita all'interno di una destinazione esistente sostituisce la configurazione ereditata. All'interno di una destinazione esistente, è possibile assegnare un compartimento sotto il compartimento di livello superiore della destinazione a una nuova destinazione. È possibile modificare le impostazioni del rilevatore e della regola del rispondente per la nuova destinazione e tali impostazioni si applicano al compartimento di livello superiore assegnato a tale destinazione e a tutti i compartimenti subordinati sottostanti nella gerarchia dei compartimenti.

Decisioni chiave di progettazione

Di seguito sono riportate informazioni sulla decisione di progettazione chiave.

• Area di reporting di Cloud Guard, che non può essere modificata senza disabilitare Cloud Guard

• Definire la strategia iniziale di destinazione e di eccezione di livello superiore:

  • È consentito escludere qualsiasi compartimento dal monitoraggio di Cloud Guard, ad esempio una sandbox o PoC?

    In caso contrario, definire la destinazione iniziale nel compartimento radice per assicurarsi che l'intera tenancy sia sottoposta a monitoraggio senza eccezioni.

    In caso affermativo, creare la destinazione Cloud Guard nel compartimento non radice per consentire l'eccezione.

• Valutare le ricette di risposta e l'ambito di applicazione applicabile.

• Flusso operativo del monitoraggio Cloud Guard, ad esempio:
  • Chi può modificare ricette e destinazioni?
  • Chi deve eseguire le azioni correttive quando la risposta automatica non viene applicata?

Valuta e utilizza le zone di sicurezza con Cloud Guard

Cloud Guard rileva configurazioni errate e le zone di sicurezza aiutano a prevenire questi problemi.

Una zona di sicurezza viene creata associando un compartimento a una recipe della zona di sicurezza. Quando si creano e si aggiornano risorse in una zona di sicurezza, OCI convalida queste operazioni in base alla lista di criteri definiti nella recipe della zona di sicurezza. Se viene violato un criterio della zona di sicurezza, l'operazione viene negata. Tuttavia, anche le risorse esistenti create prima della zona di sicurezza potrebbero violare i criteri. Zone di sicurezza OCI si integra con Cloud Guard per identificare le violazioni dei criteri nelle risorse esistenti.

Oracle gestisce una singola recipe predefinita denominata Recipe di massima sicurezza, che include tutti i criteri di zona di sicurezza disponibili. Poiché i criteri della recipe di massima sicurezza sono relativamente rigidi e non personalizzabili, l'organizzazione deve prenderla in considerazione per i carichi di lavoro appropriati solo dopo aver valutato congiuntamente la zona di sicurezza con l'architetto dell'applicazione. Creare recipe di sicurezza personalizzate quando necessario.

Principi di sicurezza

In generale, i criteri delle zone di sicurezza sono in linea con i principi di sicurezza di base indicati di seguito.

• Le risorse in una zona di sicurezza non possono essere spostate in un compartimento esterno alla zona di sicurezza perché potrebbero essere meno sicure.
• Anche tutti i componenti necessari per una risorsa in una zona di sicurezza devono trovarsi nella stessa zona di sicurezza. Le risorse che non si trovano in una zona di sicurezza potrebbero essere vulnerabili e le risorse in una zona di sicurezza diversa possono avere un livello di sicurezza inferiore. Ad esempio, un'istanza di computazione in una zona di sicurezza non può utilizzare un volume di avvio che non si trova nella stessa zona di sicurezza.
• Le risorse in una zona di sicurezza non devono essere accessibili dalla rete Internet pubblica.
• Le risorse in una zona di sicurezza devono essere cifrate utilizzando chiavi gestite dal cliente.
• È necessario eseguire regolarmente e automaticamente il backup delle risorse in una zona di sicurezza.
• I dati in una zona di sicurezza sono considerati privilegiati e non possono essere copiati al di fuori della zona di sicurezza perché potrebbero essere meno sicuri.
• Le risorse in un'area di sicurezza devono utilizzare solo configurazioni e modelli approvati da Oracle. Per i dettagli, vedere Criteri delle zone di sicurezza

Relazione con le destinazioni Cloud Guard

• Quando si crea una zona di sicurezza per un compartimento secondario il cui compartimento padre si trova già in una zona di sicurezza, Cloud Guard esegue i task riportati di seguito.
  1. Crea una destinazione zona di sicurezza separata per il compartimento secondario.
  2. Aggiunge le ricette predefinite del rilevatore gestite da Oracle alla nuova destinazione della zona di sicurezza.
• Non vengono apportate modifiche alla destinazione Cloud Guard esistente per il compartimento padre.
• Un singolo compartimento non può trovarsi in più zone di sicurezza e non può trovarsi in più destinazioni Cloud Guard.

Decisione progettazione chiave

• Valutare i criteri delle zone di sicurezza.
• Definire l'ambito applicabile, ad esempio moduli non collegati a Internet, e i processi di applicazione, ad esempio incorporati, all'inizio del ciclo di vita dello sviluppo per evitare il blocco del rollout nelle fasi successive.

Monitoraggio delle vulnerabilità con scansione regolare

OCI Vulnerability Scanning Service aiuta a migliorare il livello di sicurezza in OCI controllando regolarmente gli host per rilevare potenziali vulnerabilità. Il servizio genera report con metriche e dettagli sui risultati.

Il servizio di analisi delle vulnerabilità può identificare diversi tipi di problemi di sicurezza nelle istanze di computazione e nelle immagini dei contenitori:

• Le porte che vengono lasciate aperte involontariamente potrebbero essere un potenziale vettore di attacco alle risorse cloud o consentire agli hacker di sfruttare altre vulnerabilità.
• Pacchetti del sistema operativo che richiedono aggiornamenti e patch per risolvere le vulnerabilità.
• Configurazioni del sistema operativo che gli hacker potrebbero sfruttare.
• Benchmark standard di settore pubblicati dal Center for Internet Security (CIS).

Vulnerability Scanning verifica la conformità degli host ai benchmark di sezione 5 (Access, Authentication, and Authorization) definiti per Distribution Independent Linux.

Quando si crea un repository in Oracle Cloud Infrastructure Registry (noto anche come Container Registry), la scansione delle immagini è abilitata per impostazione predefinita nel repository. Ogni volta che un'immagine viene inviata al repository, viene eseguita la scansione delle vulnerabilità di sicurezza nel database CVE (Common Vulnerabilities and Exposures). Container Registry esegue automaticamente la nuova scansione delle immagini nel repository che sono state modificate dopo la scansione precedente.

Il team di sicurezza può anche utilizzare la recipe predefinita del rilevatore di configurazione in Cloud Guard per rilevare e rispondere alle vulnerabilità di sicurezza identificate dal servizio di analisi delle vulnerabilità.

Origini vulnerabilità

L'analisi delle vulnerabilità rileva le vulnerabilità nelle piattaforme seguenti e utilizza le origini delle vulnerabilità riportate di seguito.

Considerazioni

• Poiché la scansione di Windows non include dati OVAL, si consiglia di non fare affidamento esclusivamente su OCI Vulnerability Scanning per garantire che le istanze di Windows siano aggiornate e sicure.
• Non è consigliabile utilizzare il servizio Vulnerability Scanning per identificare i problemi nei sistemi DB (Virtual Machine) e quindi modificare il sistema operativo per risolvere ogni problema. Al contrario, segui le istruzioni per l'aggiornamento di un sistema DB e applicare gli aggiornamenti di sicurezza più recenti al sistema operativo.
• Non è possibile utilizzare il servizio di analisi delle vulnerabilità su host non creati direttamente con il servizio di computazione OCI, ad esempio Oracle Exadata Database Service on Dedicated Infrastructure o il servizio di database. Utilizzare le funzioni fornite con tali servizi per assicurarsi che gli host dispongano degli aggiornamenti di sicurezza più recenti.

Archiviazione log e integrazione SIEM

La registrazione è essenziale per gli analisti della sicurezza per scoprire potenziali violazioni della sicurezza o abusi interni delle informazioni.

Con Oracle Cloud Infrastructure Logging, gli analisti possono accedere ai log dalle risorse OCI, incluse le informazioni di diagnostica critiche che descrivono le prestazioni e l'accesso alle risorse. Il log è un singolo pannello di controllo altamente scalabile e completamente gestito per tutti i log nella tenancy.

Per impostazione predefinita, i log di controllo vengono conservati per 365 giorni. Con OCI Service Connector Hub, puoi archiviare i log nello storage immutabile più a lungo per soddisfare i requisiti di compliance per alcuni settori regolamentati. Utilizzando un pattern simile, i log possono integrarsi con informazioni di sicurezza di terze parti e strumenti di gestione degli eventi (SIEM), come Splunk e QRadar, utilizzando il servizio di streaming OCI.

Decisione progettazione chiave

• Periodo di archiviazione obbligatorio dei log: sono sufficienti 365 giorni? Oppure, è necessario conservarlo ulteriormente utilizzando lo storage immutabile?
• Necessità di un'integrazione SIEM esistente: è necessario eseguire l'integrazione con qualsiasi soluzione SIEM esistente?

Ulteriore lettura

• Guida alla progettazione per l'integrazione SIEM
• Implementare un sistema SIEM utilizzando una pipeline serverless che esporta i log di audit in Splunk
• Includi i log di Oracle Cloud Infrastructure in Microsoft Azure Sentinel utilizzando OCI Functions

Implementazione riferimento

• Area di destinazione di base Cloud Adoption Framework
• Proteggi i tuoi carichi di lavoro nel cloud utilizzando le zone di sicurezza