Condividi tramite

Informazioni generali sulla sicurezza aziendale e linee guida in Azure HDInsight

  • Articolo

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

Criteri

  • 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 dato il contesto della richiesta.
    • Ranger applica i criteri configurati per il servizio. Se i criteri ranger hanno esito negativo, il controllo di accesso viene posticipato 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, verificare la corrispondenza di proprietà o le autorizzazioni appropriate del file system (rwx).

  • 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à tutti i criteri ranger per tale servizio per ogni richiesta. Questa valutazione potrebbe avere un impatto sul tempo necessario per accettare il processo 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 XXXX dei dati di archiviazione, da assegnare direttamente all'utente in portale di Azure.

Autorizzazioni HDFS predefinite

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

Autenticazione URL

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à alcun criterio con granularità fine.

Gestire i log di controllo di Ranger

Per evitare che i log di controllo ranger consumino troppo spazio su disco nel nodo head 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 ranger-solr-configuration.Navigate to Services>Ranger>Configs>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 l'esecuzione giornaliera

I cluster ESP HDInsight sono configurati per Ranger per sincronizzare automaticamente gli utenti di ACTIVE Directory ogni ora. La sincronizzazione ranger è una sincronizzazione utente e può causare un carico aggiuntivo nell'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 Configurazione>ranger servizi>Ranger>Advanced>ranger-ugsync-site
  3. Impostare la proprietà ranger.usersync.sleeptimeinmillisbetweensynccycle su 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.

Criteri

  • 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 i criteri sono necessari 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 utente

  • 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.

Microsoft Entra Domain Services

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).
  • Se si limita il traffico in uscita, assicurarsi di aver letto il supporto del firewall in HDInsight

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 è 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 di utenti/gruppi con ambito

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 con ambito per ottenere prestazioni ottimali.

La sincronizzazione con ambito può essere modificata con selezioni di gruppi diverse o convertita in "Tutti" utenti e 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à univoce possono entrare in conflitto e rinominare. 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'ID entra locale deve essere abilitato tramite AD Connect
  • Microsoft Entra ID to Microsoft Entra Domain Services sync is automatic (latencies are under 20 minutes).
  • 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. Connessione SSH a 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. ssh to hn1 and repeat steps 1 - 3

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

Posizione degli oggetti computer

Ogni cluster è associato a una singola unità organizzativa. Viene effettuato il provisioning di un utente interno nell'unità organizzativa. Tutti i nodi sono aggiunti a un dominio nella stessa 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).

Configurazione e configurazione dell'autenticazione

Nome dell'entità 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 in una delle macchine virtuali del cluster per creare una scheda chiave 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 domande frequenti su HDInsight per determinare il valore SALT appropriato durante la creazione di una scheda chiave 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 usano identità gestite diverse per i cluster ADLS Gen2 e Microsoft Entra Domain Services, entrambi devono avere i ruoli proprietario dei dati dei BLOB di archiviazione e collaboratore di HDInsight Domain Services.
  • 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