Condividi tramite

Informazioni generali sulla sicurezza aziendale e linee guida in Azure HDInsight

Quando si distribuisce un cluster HDInsight sicuro, esistono alcune procedure consigliate per semplificare la distribuzione e la gestione del cluster. Alcune informazioni e linee guida generali sono illustrate qui.

Uso di un cluster sicuro

  • Il cluster verrà usato da più utenti contemporaneamente.
  • Gli utenti hanno diversi livelli di accesso agli stessi dati.

Non necessario

  • Si eseguiranno solo processi automatizzati ,ad esempio un singolo account utente, un cluster standard è sufficientemente valido.
  • È possibile eseguire l'importazione dei dati usando un cluster standard e usare lo stesso account di archiviazione in un cluster protetto diverso in cui gli utenti possono eseguire processi di analisi.

Uso dell'account locale

  • Se si usa un account utente condiviso o un account locale, sarà difficile identificare chi ha usato l'account per modificare la configurazione o il servizio.
  • L'uso di account locali è problematico quando gli utenti non fanno più parte dell'organizzazione.

Ranger

Politiche

  • Per impostazione predefinita, Ranger usa Deny come criterio.

  • Quando l'accesso ai dati viene effettuato tramite un servizio in cui è abilitata l'autorizzazione:

    • Il plug-in di autorizzazione Ranger viene richiamato e viene fornito il contesto della richiesta.
    • Ranger applica i criteri configurati per il servizio. Se le politiche Ranger non vengono applicate, il controllo di accesso viene delegato al file system. Alcuni servizi come MapReduce controllano solo se il file o la cartella sono di proprietà dello stesso utente che invia la richiesta. Servizi come Hive verificano la corrispondenza di proprietà o le autorizzazioni appropriate del file system.

  • Per Hive, oltre ad avere le autorizzazioni per creare/aggiornare/eliminare le autorizzazioni, l'utente deve disporre rwxdelle autorizzazioni per la directory nell'archiviazione e in tutte le sottodirectory.

  • I criteri possono essere applicati ai gruppi (preferibilmente) anziché ai singoli utenti.

  • L'autorizzatore Ranger valuterà tutte le policy Ranger per tale servizio per ogni richiesta. Questa valutazione potrebbe influire sul tempo richiesto per accettare l'incarico o la query.

Accesso alle risorse di archiviazione

  • Se il tipo di archiviazione è WASB, non viene coinvolto alcun token OAuth.
  • Se Ranger ha eseguito l'autorizzazione, l'accesso all'archiviazione avviene usando l'identità gestita.
  • Se Ranger non ha eseguito alcuna autorizzazione, l'accesso all'archiviazione avviene usando il token OAuth dell'utente.

Spazio dei nomi gerarchico

Quando lo spazio dei nomi gerarchico non è abilitato:

  • Non sono presenti autorizzazioni ereditate.
  • Solo l'autorizzazione del file system che funziona è il ruolo di Azure Storage Data XXXX, da assegnare direttamente all'utente nel portale di Azure.

Autorizzazioni HDFS predefinite

  • Per impostazione predefinita, gli utenti non hanno accesso alla cartella / su HDFS (devono trovarsi nel ruolo di proprietario del blob di archiviazione per avere esito positivo).
  • Per la directory di staging per mapreduce e altri, viene creata una directory specifica per l'utente e vengono fornite le autorizzazioni sticky _wx. Gli utenti possono creare file e cartelle sotto, ma non possono esaminare altri elementi.

URL di autenticazione

Se l'autenticazione url è abilitata:

  • La configurazione conterrà i prefissi trattati nell'autenticazione url (ad esempio adl://).
  • Se l'accesso è per questo URL, Ranger verificherà se l'utente si trova nell'elenco consenti.
  • Ranger non verificherà nessuna delle politiche granulari.

Gestire i log di controllo di Ranger

Per evitare che i log di controllo di Ranger consumino troppo spazio su disco nel nodo principale hn0, è possibile modificare il numero di giorni per conservare i log.

  1. Accedere all'interfaccia utente di Ambari.
  2. Passare a Servizi>Ranger>Configs>Advanced>Advanced ranger-solr-configuration.
  3. Modificare "Max Retention Days" in 7 giorni o meno.
  4. Selezionare Salva e riavvia i componenti interessati per rendere effettiva la modifica.

Usare un database Ranger personalizzato

È consigliabile distribuire un database Ranger esterno da usare con il cluster ESP per garantire la disponibilità elevata dei metadati di Ranger, assicurando che i criteri siano disponibili anche se il cluster non è disponibile. Poiché un database esterno è gestito dal cliente, sarà anche possibile ottimizzare le dimensioni del database e condividere il database tra più cluster ESP. È possibile specificare il database Ranger esterno durante il processo di creazione del cluster ESP usando il portale di Azure, Azure Resource Manager, l'interfaccia della riga di comando di Azure e così via.

Impostare la sincronizzazione utente di Ranger per essere eseguita giornalmente

I cluster ESP HDInsight sono configurati per consentire a Ranger di sincronizzare automaticamente gli utenti di AD ogni ora. La sincronizzazione Ranger è una sincronizzazione utente e può causare un sovraccarico sull'istanza di AD. Per questo motivo, è consigliabile modificare l'intervallo di sincronizzazione utente ranger su 24 ore.

  1. Accedere all'interfaccia utente di Ambari.
  2. Passare a Servizi>Ranger>Configs>Avanzato>ranger-ugsync-site
  3. Impostare la proprietà ranger.usersync.sleeptimeinmillisbetweensynccycle a 86400000 (24h in millisecondi).
  4. Selezionare Salva e riavvia i componenti interessati per rendere effettiva la modifica.

Gruppi di risorse

Usare un nuovo gruppo di risorse per ogni cluster in modo da poter distinguere tra le risorse del cluster.

Gruppi di sicurezza di rete, firewall e gateway interno

  • Usare i gruppi di sicurezza di rete (NSG) per bloccare le reti virtuali.
  • Usare il firewall per gestire i criteri di accesso in uscita.
  • Usare il gateway interno che non è aperto alla rete Internet pubblica.

Microsoft Entra ID

Microsoft Entra ID (Microsoft Entra ID ) è il servizio di gestione delle identità e degli accessi basato sul cloud di Microsoft.

Politiche

  • Disabilitare i criteri di accesso condizionale usando i criteri basati sull'indirizzo IP. Ciò richiede che gli endpoint di servizio siano abilitati nelle reti virtuali in cui vengono distribuiti i cluster. Se si usa un servizio esterno per MFA (diverso da Microsoft Entra ID), i criteri basati sull'indirizzo IP non funzioneranno

  • AllowCloudPasswordValidation la politica è richiesta per gli utenti federati. Poiché HDInsight usa direttamente il nome utente/password per ottenere i token dall'ID Microsoft Entra, questo criterio deve essere abilitato per tutti gli utenti federati.

  • Abilitare gli endpoint di servizio se è necessario ignorare l'accesso condizionale usando indirizzi IP attendibili.

Gruppi

  • Distribuire sempre i cluster con un gruppo.
  • Usare Microsoft Entra ID per gestire le appartenenze ai gruppi (più semplice rispetto al tentativo di gestire i singoli servizi nel cluster).

Account degli utenti

  • Usare un account utente univoco per ogni scenario. Ad esempio, usare un account per l'importazione, usare un altro per eseguire query o altri processi di elaborazione.
  • Usare i criteri Ranger basati su gruppo anziché i singoli criteri.
  • Pianificare la gestione degli utenti che non devono più avere accesso ai cluster.

Servizi di dominio Microsoft Entra

Microsoft Entra Domain Services fornisce servizi di dominio gestiti, ad esempio l'aggiunta a un dominio, criteri di gruppo, LDAP (Lightweight Directory Access Protocol) e l'autenticazione Kerberos/NTLM completamente compatibile con Windows Server Active Directory.

Microsoft Entra Domain Services è necessario per consentire ai cluster sicuri di aggiungere un dominio. HDInsight non può dipendere da controller di dominio locali o controller di dominio personalizzati, perché introduce troppi punti di errore, condivisione delle credenziali, autorizzazioni DNS e così via. Per altre informazioni, vedere Domande frequenti su Microsoft Entra Domain Services.

Scegliere lo SKU corretto di Servizi di dominio Microsoft Entra

Quando si crea il dominio gestito, è possibile scegliere tra SKU diversi che offrono diversi livelli di prestazioni e funzionalità. Il numero di cluster ESP e altre applicazioni che utilizzano l'istanza di Servizi di dominio Microsoft Entra per le richieste di autenticazione determina quale SKU è appropriato per l'organizzazione. Se si nota un utilizzo elevato della CPU nel dominio gestito o se i requisiti aziendali cambiano, è possibile aggiornare lo SKU.

Istanza di Microsoft Entra Domain Services

  • Creare l'istanza con .onmicrosoft.com domain. In questo modo, non ci saranno più server DNS che servono il dominio.
  • Creare un certificato autofirmato per LDAPS e caricarlo in Microsoft Entra Domain Services.
  • Usare una rete virtuale con peering per la distribuzione di cluster (quando si dispone di un numero di team che distribuiscono cluster ESP HDInsight, questo sarà utile). In questo modo non è necessario aprire porte (NSG) nella rete virtuale con controller di dominio.
  • Configurare correttamente il DNS per la rete virtuale (il nome di dominio di Microsoft Entra Domain Services deve essere risolto senza voci di file host).
  • Assicurarsi di avere letto il supporto firewall di HDInsight se si limita il traffico in uscita.

Prendere in considerazione i set di repliche di Microsoft Entra Domain Services

Quando si crea un dominio gestito di Microsoft Entra Domain Services, si definisce uno spazio dei nomi univoco e due controller di dominio vengono quindi distribuiti nell'area di Azure selezionata. Questa distribuzione di controller di dominio (DCs) è nota come set di repliche. L'aggiunta di set di repliche aggiuntivi fornirà resilienza e garantirà la disponibilità dei servizi di autenticazione, che è fondamentale per i cluster Azure HDInsight.

Configurare la sincronizzazione limitata di utenti/gruppi

Quando si abilita Microsoft Entra Domain Services per il cluster ESP, è possibile scegliere di sincronizzare tutti gli utenti e i gruppi da Microsoft Entra ID o gruppi con ambito e i relativi membri. È consigliabile scegliere la sincronizzazione "Scoped" per ottenere prestazioni ottimali.

La sincronizzazione con ambito può essere modificata con selezioni di gruppi diverse o convertita in "Tutti gli utenti e i gruppi" se necessario. Non è possibile modificare il tipo di sincronizzazione da "All" a "Scoped" a meno che non si elimini e ricrea l'istanza di Microsoft Entra Domain Services.

Proprietà sincronizzate da Microsoft Entra ID a Microsoft Entra Domain Services

  • Microsoft Entra Connect esegue la sincronizzazione da locale a Microsoft Entra ID.
  • Microsoft Entra Domain Services esegue la sincronizzazione da Microsoft Entra ID.

Microsoft Entra Domain Services sincronizza periodicamente gli oggetti dall'ID Microsoft Entra. Il pannello Servizi di dominio Microsoft Entra nel portale di Azure visualizza lo stato di sincronizzazione. Durante ogni fase di sincronizzazione, le proprietà uniche possono entrare in conflitto e possono essere rinominate. Prestare attenzione al mapping delle proprietà da Microsoft Entra ID a Microsoft Entra Domain Services.

Per altre informazioni, vedere Popolamento di Microsoft Entra UserPrincipalName e Funzionamento della sincronizzazione di Microsoft Entra Domain Services.

Sincronizzazione dell'hash delle password

  • Le password vengono sincronizzate in modo diverso da altri tipi di oggetto. Solo gli hash delle password non reversibili vengono sincronizzati in Microsoft Entra ID e Microsoft Entra Domain Services
  • L'implementazione in locale di Microsoft Entra ID va abilitata tramite AD Connect
  • La sincronizzazione da Microsoft Entra ID a Microsoft Entra Domain Services è automatica (le latenze sono inferiori a 20 minuti).
  • Gli hash delle password vengono sincronizzati solo quando è presente una password modificata. Quando si abilita la sincronizzazione dell'hash delle password, tutte le password esistenti non vengono sincronizzate automaticamente perché vengono archiviate in modo irreversibile. Quando si modifica la password, gli hash delle password vengono sincronizzati.

Impostare la sincronizzazione LDAP di Ambari per l'esecuzione giornaliera

Il processo di sincronizzazione dei nuovi utenti LDAP con Ambari viene configurato automaticamente per l'esecuzione ogni ora. L'esecuzione di questa operazione ogni ora può causare un carico in eccesso sui nodi head del cluster e sull'istanza di AD. Per migliorare le prestazioni, è consigliabile modificare lo script /opt/startup_scripts/start_ambari_ldap_sync.py che esegue la sincronizzazione LDAP Ambari per l'esecuzione una volta al giorno. Questo script viene eseguito tramite un processo crontab e viene archiviato nella directory "/etc/cron.hourly/" nei nodi head del cluster.

Per eseguirlo una volta al giorno, seguire questa procedura:

  1. SSH su hn0
  2. Spostare lo script nella cartella giornaliera cron: sudo mv /etc/cron.hourly/ambarildapsync /etc/cron.daily/ambarildapsync
  3. Applicare la modifica nel processo crontab: sudo service cron reload
  4. Esegui ssh su hn1 e ripeti i passaggi da 1 a 3

Se necessario, è possibile usare l'API REST di Ambari per sincronizzare manualmente nuovi utenti e gruppi immediatamente.

Posizione degli oggetti del computer

Ogni cluster è associato a una singola unità organizzativa. Viene effettuato il provisioning di un utente interno nell'unità organizzativa. Tutti i nodi sono collegati allo stesso dominio nella medesima unità organizzativa.

Strumenti di amministrazione di Active Directory

Per altre informazioni, vedere Installare gli strumenti di gestione.

Risoluzione dei problemi

La creazione del cluster ha esito negativo ripetutamente

Motivi più comuni:

  • La configurazione DNS non è corretta. L'aggiunta a un dominio dei nodi del cluster ha esito negativo.
  • I gruppi di sicurezza di rete sono troppo restrittivi, impedendo l'aggiunta a un dominio.
  • Identità gestita non dispone di autorizzazioni sufficienti.
  • Il nome del cluster non è univoco nei primi sei caratteri (con un altro cluster attivo o con un cluster eliminato).

Impostazione e configurazione dell'autenticazione

Nome principale utente (UPN)

  • Usare caratteri minuscoli per tutti i servizi: gli UPN non fanno distinzione tra maiuscole e minuscole nei cluster ESP, ma
  • Il prefisso UPN deve corrispondere sia a SAMAccountName in Microsoft Entra Domain Services. La corrispondenza con il campo di posta elettronica non è obbligatoria.

Proprietà LDAP nella configurazione di Ambari

Per un elenco completo delle proprietà di Ambari che influiscono sulla configurazione del cluster HDInsight, vedere Installazione dell'autenticazione LDAP di Ambari.

Generare i campi chiave utente del dominio

Tutti i keytab del servizio vengono generati automaticamente durante il processo di creazione del cluster ESP. Per abilitare la comunicazione sicura tra il cluster e altri servizi e/o processi che richiedono l'autenticazione, è possibile generare una scheda chiave per il nome utente del dominio.

Usare ktutil su una delle VM del cluster per creare un keytab Kerberos.


ktutil
ktutil: addent -password -p <username>@<DOMAIN.COM> -k 1 -e aes256-cts-hmac-sha1-96
Password for <username>@<DOMAIN.COM>: <password>
ktutil: wkt <username>.keytab
ktutil: q

Se tenantName e DomainName sono diversi, è necessario aggiungere un valore SALT usando l'opzione -s. Controllare la pagina delle domande frequenti su HDInsight per determinare il valore SALT appropriato durante la creazione di un keytab Kerberos.

Rinnovo del certificato LDAP

HDInsight rinnova automaticamente i certificati per le identità gestite usate per i cluster con Enterprise Security Package (ESP). Tuttavia, esiste una limitazione quando vengono usate identità gestite diverse per Microsoft Entra Domain Services e ADLS Gen2 che potrebbero causare l'esito negativo del processo di rinnovo. Seguire le 2 raccomandazioni seguenti per assicurarsi di poter rinnovare correttamente i certificati:

  • Se si utilizzano identità gestite diverse per i cluster ADLS Gen2 e Microsoft Entra Domain Services, entrambi devono avere i ruoli Storage blob data Owner e HDInsight Domain Services Contributor assegnati.
  • I cluster HDInsight richiedono indirizzi IP pubblici per gli aggiornamenti dei certificati e altre operazioni di manutenzione, in modo che tutti i criteri che negano l'indirizzo IP pubblico nel cluster vengano rimossi.

Passaggi successivi

  • Last updated on