Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Overview
Questa guida ti aiuta a determinare i requisiti di residenza dei dati per una distribuzione multicloud che utilizza soluzioni cloud security posture management (CSPM) e cloud workload protection platform (CWPP) in Microsoft Defender per il cloud.
Obiettivi di pianificazione della residenza dei dati
Identificare i requisiti di residenza dei dati per la distribuzione multicloud e comprendere come Defender per il cloud piani e agenti influiscono sulla posizione in cui vengono elaborati e archiviati i dati.
Inizia con la pianificazione della residenza dati
Quando proteggi asset tra le nuvole, identifica quali piani abilitare e se ciascuno richiede agenti.
Nell'ambito di questa analisi, identificare i requisiti regionali e legali per la gestione dei dati.
Considerazioni sull'agente per la residenza dei dati
Considera le implicazioni di residenza e gestione dei dati per gli agenti e le estensioni utilizzate da Defender per il cloud.
- CSPM: La funzionalità di gestione del comportamento di sicurezza cloud (CSPM) in Defender per il cloud è senza agente. Non sono necessari agenti per il funzionamento di CSPM.
- CWPP: Funzionalità CWPP (Cloud Workload Protection Platform) in Defender per il cloud possono richiedere agli agenti di raccogliere dati.
Considerazioni sulla residenza dei dati per Defender for Servers
Gli agenti vengono usati nel piano Defender per server come indicato di seguito:
- I cloud pubblici non di Azure si connettono ad Azure sfruttando il servizio Azure Arc .
- L'agente Azure Connected Machine viene installato nelle macchine multicloud di cui viene effettuato l'onboarding come macchine Azure Arc. Defender per il cloud deve essere abilitato nella sottoscrizione in cui si trovano i computer Azure Arc.
- Defender per il cloud sfrutta l'agente Connected Machine per installare le estensioni (ad esempio Microsoft Defender per endpoint) necessarie per la funzionalità di Defender per server.
Considerazioni sulla residenza dei dati per Defender for Containers
Defender per contenitori protegge le distribuzioni di contenitori multicloud in esecuzione in:
- Servizio Azure Kubernetes: servizio gestito da Microsoft per lo sviluppo, la distribuzione e la gestione di applicazioni in contenitori.
- Amazon Elastic Kubernetes Service (EKS) in un account AWS connesso - il servizio gestito di Amazon per eseguire Kubernetes su AWS senza dover installare, gestire e mantenere il proprio piano di controllo Kubernetes o i propri nodi.
- Google Kubernetes Engine (GKE) in un progetto GCP connesso: ambiente gestito di Google per la distribuzione, la gestione e il ridimensionamento delle applicazioni tramite l'infrastruttura GCP.
- Altre distribuzioni di Kubernetes: con Kubernetes abilitato per Azure Arc, che consente di collegare e configurare cluster Kubernetes in esecuzione ovunque, inclusi altri cloud pubblici e locali.
Defender per contenitori include componenti basati su sensori e senza agente.
- Raccolta senza agente dei dati del log di controllo Kubernetes: Amazon CloudWatch o GCP Cloud Logging raccoglie i dati del log di controllo e invia i dati a Defender per il cloud per un'ulteriore analisi.
- Raccolta senza agente per l'inventario Kubernetes: raccogli dati sui tuoi cluster Kubernetes e sulle relative risorse, ad esempio: namespace, deployment, pod e ingress.
- Kubernetes abilitato per i sensori: connette i cluster EKS e GKE ad Azure usando gli agenti Di Azure Arc, in modo che vengano considerati come risorse di Azure Arc.
- Sensore Defender: Un DaemonSet che raccoglie segnali dagli host tramite la tecnologia extended Berkeley Packet Filter (eBPF) e offre protezione in fase di esecuzione. L'estensione viene registrata con un'area di lavoro Log Analytics e usata come pipeline di dati. I dati del log di controllo kubernetes non vengono archiviati nell'area di lavoro Log Analytics.
-
Criteri di Azure per Kubernetes: le informazioni di configurazione vengono raccolte da Criteri di Azure per Kubernetes.
- Criteri di Azure per Kubernetes estende il webhook del controller di ammissione open source Gatekeeper v3 per Open Policy Agent.
- L'estensione si registra come hook Web per il controllo di ammissione di Kubernetes e consente di applicare criteri su larga scala, proteggendo i cluster in modo centralizzato e coerente.
Importante
La raccolta dei dati dei log di audit di Kubernetes utilizza il servizio di logging di Amazon EKS o di GCP nel cloud sorgente. Verificare il comportamento di archiviazione e trasferimento a livello di area per soddisfare i requisiti di privacy e residenza interna dell'organizzazione.
Considerazioni sulla residenza dei dati per Defender for Databases
Per il piano Defender for Databases in uno scenario multicloud, si usa Azure Arc per gestire database SQL Server in ambienti multicloud. L'istanza di SQL Server viene installata in una macchina virtuale o fisica connessa a Azure Arc.
- L'individuazione e la registrazione automatica di SQL Server devono essere impostate su Sì per consentire l'individuazione del database SQL nei computer.
- L'agente di Azure Connected Machine viene installato nei computer connessi ad Azure Arc.
- Il piano Defender per database deve essere abilitato nella sottoscrizione in cui si trovano i computer Azure Arc.
- È necessario eseguire il provisioning dell'agente di Log Analytics per Microsoft Defender SQL Server nei computer Azure Arc. Raccoglie le impostazioni di configurazione correlate alla sicurezza e i registri eventi dai computer.
Per le risorse AWS e GCP protette da Defender per il cloud, la localizzazione delle risorse è determinata direttamente da AWS e GCP.