Documentazione di Oracle Cloud Infrastructure

Uso dell'autenticazione Kerberos

Il servizio di storage di file offre l'autenticazione Kerberos per fornire un'opzione di autenticazione sicura.

La sicurezza Unix di NFS v.3, che considera il client NFS attendibile come affidabile relativamente all'identità di un utente, fornisce solo la sicurezza di base. L'identità dell'utente in ogni chiamata NFS viene definita dal chiamante e l'identità non viene verificata da una terza parte attendibile.

Kerberos per NFSv3 offre un'autenticazione complessa sia per gli host che per gli utenti. Può anche offrire la prova dell'integrità dei dati, garantendo che i dati non vengano manomessi e proteggendo la privacy dei dati. Integrità dei dati e privacy dei dati non sono possibili con la sicurezza UNIX NFS v.3 senza installare software client specializzato o aprire più porte TCP.

  • Gli utenti e i servizi in una rete abilitata per Kerberos sono denominati Principals. Il nome principale Kerberos ha il formato primary/instance@realm. Per ulteriori informazioni, vedere la documentazione principale di MIT Kerberos.
  • Il Centro di distribuzione chiavi (KDC) autentica i principal ed emette ticket. Il KDC gestisce un elenco di principal e le relative password.
  • Un realm è costituito da tutti i principal supportati da un solo KDC.

Il servizio di storage di file supporta l'autenticazione Kerberos tramite RPCSEC_GSS (RFC2203) con le opzioni di sicurezza riportate di seguito.

  • Utilizzare la modalità KRB5 per l'autenticazione su NFS
  • Utilizzare la modalità KRB5I per l'autenticazione su NFS e l'integrità dei dati (modifica non autorizzata dei dati in transito)
  • Utilizzare la modalità KRB5P per l'autenticazione su NFS, l'integrità dei dati e la privacy dei dati (crittografia in transito)

Funzioni

Il supporto del servizio di storage di file di Kerberos include le funzioni riportate di seguito.

Cifratura in transito

È possibile utilizzare la modalità Kerberos KRB5P, che offre la privacy dei dati, in alternativa all'uso della cifratura TLS v.1.2 (Transport Layer Security). La cifratura TLS v.1.2 richiede l'installazione di un pacchetto denominato oci-fss-utils o l'uso di stunnel, a seconda del sistema operativo in uso. Il numero di connessioni NFS/TLS cifrate per una destinazione di accesso è limitato, ma l'uso di Kerberos con l'opzione KRB5P consente di utilizzare la cifratura in transito in una scala non possibile con NFS su TLS.

Kerberos e sicurezza per IP

La sicurezza per IP, impostata mediante le opzioni di esportazione NFS, è ragionevolmente sicura se gli indirizzi IP sono in OCI e se gli host sono sicuri. Kerberos per NFSv3 è in grado di garantire un livello di sicurezza superiore per ambienti o ambienti misti con host non attendibili.

È possibile configurare un blocco CIDR per richiedere l'autenticazione Kerberos e un altro per l'autenticazione NFS AUTH_SYS nella stessa esportazione. Qualsiasi client attivato dalla rete sicura non dovrebbe essere attivato con Kerberos, ma i client attivati dalla rete inaffidabile dovranno utilizzare Kerberos.

Ricerche LDAP e accesso anonimo

Se gli utenti dispongono di un'identità nel KDC, ma non sono presenti informazioni aggiuntive nel server LDAP oppure LDAP non è abilitato, l'operazione NFS può non riuscire o continuare. Il funzionamento in questi casi dipende dall'abilitazione o meno di LDAP per la destinazione di accesso e dall'accesso anonimo per l'esportazione.

L'accesso anonimo è disabilitato per impostazione predefinita. Qualsiasi richiesta NFS associata a un utente non trovato non riesce.

Se l'accesso anonimo è abilitato, le richieste associate a un utente non trovato nel server LDAP procedono con le opzioni UID squash e GID squash impostate nelle opzioni di esportazione. È possibile consentire l'accesso anonimo se il processo di attivazione utilizza un principal Kerberos del sistema che non esiste nel server LDAP e i diritti compressi consentono alle poche operazioni di sola lettura utilizzate dal client NFS di attivare il file system.

Scenari di richiesta NFS per le esportazioni abilitate per Kerberos
LDAP abilitato nella destinazione di accesso? Risposta LDAP Accesso anonimo abilitato? Esportazione squash abilitata? Richiesta NFS
Qualsiasi Qualsiasi Qualsiasi Sì (tutti)

Procede con l'impostazione di UID squash e GID squash nelle opzioni di esportazione. Nessuna lista di gruppi secondari.
Qualsiasi Qualsiasi Qualsiasi Sì (radice)

Procede con l'impostazione di UID squash e GID squash nelle opzioni di esportazione solo dopo una risposta LDAP riuscita in cui il nome utente è mappato a UID 0. Nessuna lista di gruppi secondari.

Se la risposta LDAP restituisce un UID diverso da 0, procede con l'UID, il GID e l'elenco di gruppi restituiti.
Sì Corrispondenza USERNAME Qualsiasi No Utilizza l'UID, il GID e la lista di gruppi secondari recuperati dal server LDAP.
Sì Nessuna corrispondenza USERNAME Sì No Procede con l'impostazione di UID squash e GID squash nelle opzioni di esportazione. Nessuna lista di gruppi secondari.
Sì Nessuna corrispondenza USERNAME No No Errore di autorizzazioni non riuscite.
Sì Errore LDAP diverso da nessun utente corrispondente Qualsiasi No Errore di autorizzazioni non riuscite.
No Non applicabile Sì No

Procede con l'impostazione di UID squash e GID squash nelle opzioni di esportazione.
No Non applicabile No No Errore di autorizzazioni non riuscite.
Nota

Le esportazioni abilitate per Kerberos utilizzano sempre Usa LDAP per la lista di gruppi quando l'opzione Abilita LDAP è abilitata sulla destinazione di accesso.

Per maggiori informazioni, vedere NFS Export Options.

Prerequisiti

Lo storage di file richiede diversi prerequisiti per utilizzare Kerberos per l'autenticazione.

I requisiti per utilizzare l'autenticazione Kerberos per utente includono:

  • Infrastruttura LDAP gestita dal cliente per mappare le identità Kerberos alle identità UNIX. Per ulteriori informazioni, vedere LDAP per i prerequisiti di autorizzazione.
  • Infrastruttura Kerberos gestita dal cliente, con un KDC come MIT o Microsoft Active Directory.
  • Server DNS in grado di risolvere il nome e l'indirizzo IP della destinazione di accesso. Sono necessarie sia le capacità di ricerca in avanti che inversa.
Questa immagine mostra l'infrastruttura gestita dal cliente e da OCI necessaria per l'autenticazione Kerberos.
  1. Comunicazione con un server KDC gestito dal cliente su porta TCP/UDP 88.
  2. Comunicazione sicura con una destinazione di accesso abilitata per Kerberos su porta NFS 2048/2049/2050 (cifrata a livello di opzione).
  3. Comunicazione con il servizio DNS tramite la porta 53 TCP/UDP.
  4. Comunicazione con il servizio LDAP gestito dal cliente sulla porta TCP configurata nel connettore in uscita. Il valore predefinito è la porta TCP 636.
  5. Dati cifrati in archivio nello storage di file.

Infrastruttura LDAP

Lo storage di file utilizza UID e GID per autorizzare l'accesso ai file. Lo storage di file utilizza LDAP per mappare le identità Kerberos a UID e GIDS. Per informazioni dettagliate sui requisiti dell'infrastruttura LDAP, vedere Prerequisiti per l'utilizzo di LDAP per l'autorizzazione.

Se lo storage di file non è in grado di cercare le informazioni di autorizzazione da LDAP, gli accessi NFS per il principal Kerberos potrebbero non riuscire. L'autenticazione Kerberos può essere utilizzata senza LDAP, ma tutte le principal Kerberos autenticate verrebbero trattate come anonime. Per ulteriori informazioni, vedere Ricerche LDAP e accesso anonimo.

Keytab Kerberos

La tabella chiavi Kerberos memorizzata nel vault OCI deve essere un array di stringhe con codifica Base64 della struttura seguente: 

<principal, key version number, cipher type, symmetric key>

Ogni voce nella tabella chiavi può avere un solo principal e tale principal deve includere come istanza il nome dominio completamente qualificato (FQDN) della destinazione di accesso. Un principal può avere più voci con tipi di cifratura o cifrature diversi.

Ad esempio, se nfs/krb_mt1.fss_test.com@FSS_EXAMPLE.COM è il nome principale nella tabella chiavi, FSS_EXAMPLE.COM è il realm, fss_test.com è l'istanza e nfs è il nome principale. Il nome FQDN della destinazione di accesso in questo esempio deve essere krb_mt1.fss_test.com. Se si utilizza un server DNS gestito dal cliente, utilizzare questo nome FQDN nei comandi di attivazione.

Nota

Quando si utilizza il resolver Internet e VCN predefinito, il servizio di storage di file crea un FQDN combinando il nome host della destinazione di accesso con il FQDN della subnet in cui si trova la destinazione di accesso. Dopo la creazione, è possibile modificare il nome host nella pagina dei dettagli della destinazione di accesso. Per ulteriori informazioni, vedere Gestione delle destinazioni di accesso.

Lo storage di file supporta il seguente set di cifrature:

  • aes128-cts-hmac-sha256-128
  • aes256-cts-hmac-sha384-192
  • aes128-cts-hmac-sha1-96
  • aes256-cts-hmac-sha1-96
Nota

OCI File Storage supporta una dimensione massima della tabella chiavi Kerberos di 1024 byte.
Importante

Convalidare la tabella chiavi Kerberos prima di abilitare Kerberos per evitare un'indisponibilità causata da una tabella chiavi non valida. È possibile convalidare la tabella chiavi quando si configura o si rivede la configurazione Kerberos di una destinazione di accesso.

Quando si convalida la tabella chiavi Kerberos tramite la console, l'interfaccia CLI o l'API, il servizio di storage di file verifica quanto riportato di seguito.

  • Se la dimensione della tabella chiavi è superiore a 1024 byte
  • Il numero di versione della tabella chiavi non è 1281 o 1282
  • Se la tabella chiavi contiene voci nulle
  • Se la tabella chiavi contiene voci con nomi di principal diversi
  • Se la tabella chiavi contiene più di 12 voci, ovvero il numero massimo
  • Se il tipo di codifica della tabella di chiavi non è uno dei seguenti:
    • ETYPE_AES128_CTS_HMAC_SHA1_96
    • ETYPE_AES256_CTS_HMAC_SHA1_96
    • ETYPE_AES128_CTS_HMAC_SHA256_128
    • ETYPE_AES256_CTS_HMAC_SHA384_192
Nota

Una tabella chiavi estratta dal KDC in formato binario deve essere convertita in Base64 e quindi utilizzata per creare un segreto nel vault OCI. Assicurarsi di selezionare Base64 come formato del segreto quando si incolla nella tabella chiavi convertita.

Lo storage di file supporta la rotazione delle tabelle di chiavi utilizzando una tabella di chiavi di backup. Per ulteriori informazioni, vedere Tasti di rotazione.

Considerazioni e limitazioni

Quando si utilizza Kerberos per l'autenticazione dello storage di file, tenere presenti le informazioni e i limiti riportati di seguito.

  • Per l'autenticazione Kerberos per ciascun utente, lo storage di file richiede l'infrastruttura LDAP (Lightweight Directory Access Protocol) gestita dal cliente, incluso un server LDAP che supporta uno schema POSIX RFC2307.
  • Lo storage di file supporta una dimensione massima della tabella chiavi Kerberos di 1024 byte.

  • Lo storage di file supporta il seguente set di cifrature:

    • aes128-cts-hmac-sha256-128
    • aes256-cts-hmac-sha384-192
    • aes128-cts-hmac-sha1-96
    • aes256-cts-hmac-sha1-96
  • Si sconsiglia di attivare i file system con le opzioni rsize o wsize. Se si forniscono valori per queste opzioni, è possibile che vengano ridotti a 256 KB dallo storage di file quando si utilizza KRB5I o KRB5P.
  • Le prestazioni dello storage di file quando si utilizza la modalità di autenticazione Kerberos KRB5 equivalgono approssimativamente all'utilizzo dell'autenticazione AUTH_SYS. Le prestazioni diminuiscono significativamente quando si utilizza KRB5P e diminuiscono leggermente quando si utilizza KRB5I. Le prestazioni possono variare in base alla configurazione del client e al file system.

Monitoraggio e allarmi

Quando si utilizza l'autenticazione Kerberos con autorizzazione LDAP, è importante venire a conoscenza di un problema rapidamente. Se l'infrastruttura Kerberos o LDAP non funziona correttamente, i client NFS potrebbero perdere l'accesso ai file system di storage di file resi disponibili tramite le relative esportazioni. Per individuare tali problemi, si consiglia di impostare gli allarmi sulle metriche della destinazione di accesso. Gli allarmi possono avvisarti dei problemi dell'infrastruttura in pochi minuti.

Gli allarmi creati in base agli errori Kerberos, agli errori di connessione LDAP e agli errori di richiesta LDAP rilevano problemi di connettività tra destinazioni di accesso, connettori in uscita e infrastruttura LDAP gestita dal cliente.

È possibile utilizzare la seguente query di esempio per creare un allarme per gli errori Kerberos:

KerberosErrors[1m]{resourceType = "mounttarget", mtResourceName = "<mount_target_name>", errorType != "keytab_load_success"}.max() >= 1

Per creare un allarme per la connettività LDAP è possibile utilizzare la seguente query di esempio:

LdapConnectionErrors[1m]{resourceType = "outboundconnector", mtResourceName = "<mount_target_name>", errorType != "success"}.max() >= 1

Per ulteriori informazioni sulle metriche di monitoraggio e sull'uso degli allarmi, vedere Panoramica del monitoraggio. Per informazioni sulle notifiche per gli allarmi, vedere Panoramica delle notifiche.

Criteri IAM necessari

Lo storage di file deve accedere alla password del server LDAP ed eseguire il MOUNT dei segreti vault della tabella chiavi Kerberos di destinazione per la configurazione Kerberos. L'utente che configura la destinazione di accesso e la destinazione di accesso devono disporre dell'accesso in lettura.

Criterio per gestire i segreti vault

Concedere all'utente o al gruppo che crea le autorizzazioni del segreto vault. Per ulteriori informazioni, vedere Gestione dei segreti vault.

Criterio per abilitare la configurazione della destinazione di accesso

Concedere all'utente o al gruppo la configurazione di Kerberos e LDAP su autorizzazioni di destinazione di accesso utilizzando un criterio come il seguente:

allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <Keytab_Secret_ID>, target.secret.id = <LDAP_Password_Secret_ID> }

Ciò consente all'utente di eseguire comandi di storage di file che leggono i segreti del vault e visualizzano parti del segreto per la convalida. Lo storage di file presenta il principal, il numero di versione della chiave e i tipi di cifratura per l'utente che configura la destinazione di accesso per la convalida.

Criterio che consente a una destinazione di accesso di recuperare i segreti

Il servizio di storage di file richiede la possibilità di leggere i segreti. Lo storage di file utilizza i principal delle risorse per concedere a un set specifico di destinazioni di accesso l'accesso al segreto del vault. Si tratta di un processo in due fasi, in primo luogo le destinazioni di accesso che richiedono l'accesso devono essere inserite in un gruppo dinamico, quindi al gruppo dinamico viene concesso l'accesso per leggere i segreti.

  1. Creare un gruppo dinamico per le destinazioni di accesso con un criterio, ad esempio:

    ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
    Nota

    Se nel gruppo dinamico sono presenti più regole, assicurarsi di utilizzare l'opzione Match any rules defined below.

  2. Creare un criterio IAM che fornisca al gruppo dinamico di destinazioni di accesso l'accesso in lettura ai segreti del vault:

    allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>