Documentation sur Oracle Cloud Infrastructure

Utilisation de l'authentification Kerberos

Le service File Storage offre une authentification Kerberos pour fournir une option d'authentification forte.

La sécurité NFS v.3 pour Unix, qui fait confiance au client NFS pour être honnête au sujet de l'identité d'un utilisateur, fournit uniquement une sécurité de base. L'identité de l'utilisateur dans chaque appel NFS est définie par l'appelant, et l'identité n'est pas vérifiée par un tiers de confiance.

Kerberos pour NFSv3 offre une authentification forte pour les hôtes et les utilisateurs. Il peut également offrir une preuve de l'intégrité des données, s'assurer que les données ne sont pas altérées et protéger la confidentialité des données. L'intégrité des données et la confidentialité des données ne sont pas possibles avec la sécurité NFS v.3 UNIX sans installer un logiciel client spécialisé ou ouvrir plus de ports TCP.

  • Les utilisateurs et les services d'un réseau activé pour Kerberos sont appelés principaux. Un principal Kerberos a la forme primary/instance@realm. Pour plus d'informations, voir la documentation sur le principal MIT Kerberos.
  • Le centre de distribution des clés authentifie les principaux et émet des tickets. Le KDC tient à jour une liste des principaux et de leurs mots de passe.
  • Un domaine se compose de tous les principaux pris en charge par un KDC.

Le service File Storage prend en charge l'authentification Kerberos au moyen de RPCSEC_GSS (RFC2203) avec les options de sécurité suivantes :

  • Utiliser le mode KRB5 pour l'authentification sur NFS
  • Utiliser le mode KRB5I pour l'authentification sur NFS et l'intégrité des données (modification non autorisée des données en transit)
  • Utiliser le mode KRB5P pour l'authentification sur NFS, l'intégrité des données et la confidentialité des données (chiffrement en transit)

Fonctions

La prise en charge de Kerberos par le service File Storage comprend les fonctions suivantes.

Cryptage en transit

Vous pouvez utiliser le mode Kerberos KRB5P, qui offre la confidentialité des données, au lieu d'utiliser le chiffrement TLS v.1.2 (Transport Layer Security). Le chiffrement TLS v.1.2 nécessite l'installation d'un paquet appelé oci-fss-utils ou l'utilisation de stunnel, selon votre système d'exploitation. Le nombre de connexions NFS/TLS chiffrées pour une cible de montage est limité, mais l'utilisation de Kerberos avec l'option KRB5P vous permet d'utiliser le chiffrement en transit à une échelle qui n'est pas possible avec NFS sur TLS.

Kerberos et sécurité par IP

La sécurité par adresse IP, définie à l'aide des options d'exportation NFS, est raisonnablement sécurisée si les adresses IP se trouvent dans OCI et que les hôtes sont approuvés. Kerberos pour NFSv3 peut fournir un niveau de sécurité plus élevé pour les environnements mixtes ou les environnements avec des hôtes non approuvés.

Vous pouvez configurer un bloc CIDR pour qu'il nécessite Kerberos et un autre pour l'authentification NFS AUTH_SYS sur la même exportation. Tous les clients montés à partir du réseau approuvé n'auraient pas besoin de monter avec Kerberos, mais les clients montés à partir du réseau non approuvé devraient utiliser Kerberos.

Consultations LDAP et accès anonyme

Lorsque les utilisateurs ont une identité dans le KDC, mais qu'aucune information supplémentaire dans le serveur LDAP ou LDAP n'est pas activé, l'opération NFS peut échouer ou continuer. Dans ces cas, le comportement dépend de l'activation ou non de LDAP pour la cible de montage et de l'accès anonyme pour l'exportation.

L'accès anonyme est désactivé par défaut. Toute demande NFS associée à un utilisateur introuvable échoue.

Si l'accès anonyme est activé, les demandes associées à un utilisateur introuvable sur le serveur LDAP poursuivent avec l'UID séquentiel et l'IDG séquentiel définis dans les options d'exportation. Vous pouvez autoriser un accès anonyme si le processus de montage utilise un principal Kerberos système qui n'existe pas sur votre serveur LDAP et que les droits écrasés autorisent les quelques opérations en lecture seule utilisées par le client NFS pour monter le système de fichiers.

Scénarios de demande NFS pour les exportations activées pour Kerberos
LDAP activé sur la cible de montage? Réponse LDAP Accès anonyme activé? Exportation de squash activée? Demande NFS
Peu importe Peu importe Peu importe Oui (toutes)

L'UID séquentiel et l'IDG séquentiel sont définis dans les options de l'exportation. Aucune liste de groupes secondaires.
Peu importe Peu importe Peu importe Oui (racine)

L'UID séquentiel et l'IDG séquentiel sont définis dans les options de l'exportation uniquement après une réponse LDAP réussie où le nom d'utilisateur est mappé à l'UID 0. Aucune liste de groupes secondaires.

Si la réponse LDAP retourne un UID qui n'est pas 0, procède avec l'UID, l'IDG et la liste de groupes retournés.
Oui Correspondance de USERNAME Peu importe Non Utilise l'UID, l'IDG et la liste de groupes secondaires extraits du serveur LDAP.
Oui Aucun nom d'utilisateur ne correspond Oui Non L'UID séquentiel et l'IDG séquentiel sont définis dans les options de l'exportation. Aucune liste de groupes secondaires.
Oui Aucun nom d'utilisateur ne correspond Non Non Échec avec erreur d'autorisation.
Oui Erreur LDAP autre qu'aucun utilisateur correspondant N'importe quelle Non Échec avec erreur d'autorisation.
Non Non applicable Oui Non

L'UID séquentiel et l'IDG séquentiel sont définis dans les options de l'exportation.
Non Non applicable Non Non Échec avec erreur d'autorisation.
Note

Les exportations activées pour Kerberos utilisent toujours Utiliser LDAP pour la liste de groupes lorsque l'option Activer LDAP est activée sur la cible de montage.

Pour plus d'informations, voir Options d'exportation NFS.

Préalables

Le service de stockage de fichiers nécessite plusieurs préalables pour utiliser Kerberos pour l'authentification.

Les exigences d'utilisation de l'authentification Kerberos par utilisateur sont les suivantes :

  • Infrastructure LDAP gérée par le client pour mapper les principaux Kerberos aux identités UNIX. Pour plus d'informations, voir Préalables pour l'autorisation LDAP.
  • Infrastructure Kerberos gérée par le client, avec un KDC tel que MIT ou Microsoft Active Directory.
  • Serveur DNS qui peut résoudre le nom et l'adresse IP de la cible de montage. Les fonctions de consultation aval et inversée sont requises.
Cette image présente l'infrastructure gérée par le client et gérée par OCI nécessaire pour l'authentification Kerberos.
  1. Communication avec un serveur KDC géré par le client sur le port TCP/UDP 88.
  2. Communication sécurisée avec une cible de montage prenant en charge Kerberos sur le port NFS 2048/2049/2050 (chiffré en option).
  3. Communication avec le service DNS sur le port TCP/UDP 53.
  4. Communication avec le service LDAP géré par le client sur le port TCP configuré dans le connecteur sortant. La valeur par défaut est le port TCP 636.
  5. Données chiffrées au repos dans le service de stockage de fichiers.

Infrastructure LDAP

Le service de stockage de fichiers utilise des UID et des GID pour autoriser l'accès aux fichiers. Le service de stockage de fichiers utilise LDAP pour mapper les principaux Kerberos aux UID et GIDS. Pour des exigences détaillées en matière d'infrastructure LDAP, voir Préalables à l'utilisation de LDAP pour l'autorisation.

Si le stockage de fichiers ne peut pas consulter les informations d'autorisation à partir de LDAP, les accès NFS pour le principal Kerberos échoueront probablement. L'authentification Kerberos peut être utilisée sans LDAP, mais tous les principaux Kerberos authentifiés seraient traités comme anonymes. Pour plus d'informations, voir Consultations LDAP et accès anonyme.

Onglet de clé Kerberos

Le fichier keytab Kerberos stocké dans la chambre forte OCI doit être un tableau de chaînes encodées en Base64 de la structure suivante : 

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

Chaque entrée du fichier keytab ne peut avoir qu'un seul principal, qui doit inclure le nom de domaine complet de la cible de montage en tant qu'instance. Un principal peut avoir plusieurs entrées avec différents types de chiffrement ou chiffrements.

Par exemple, si nfs/krb_mt1.fss_test.com@FSS_EXAMPLE.COM est le principal dans le keytab, FSS_EXAMPLE.COM est le domaine, fss_test.com est l'instance et nfs est l'instance principale. Le nom de domaine complet de la cible de montage dans cet exemple doit être krb_mt1.fss_test.com. Si vous utilisez un serveur DNS géré par le client, vous utiliserez ce nom de domaine complet dans les commandes de montage.

Note

Lors de l'utilisation du résolveur Internet et VCN par défaut, le service de stockage de fichiers construit un nom de domaine complet en combinant le nom d'hôte de la cible de montage et le nom de domaine complet du sous-réseau dans lequel la cible de montage se trouve. Après la création, le nom d'hôte peut être modifié dans la page des détails de la cible de montage. Voir Gestion des cibles de montage pour plus d'informations.

File Storage prend en charge le jeu de chiffrements suivant :

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

Le service de stockage de fichiers OCI prend en charge une taille maximale de 1024 octets pour le fichier keytab Kerberos.
Important

Validez le fichier keytab Kerberos avant d'activer Kerberos pour éviter une interruption de disponibilité causée par un fichier keytab non valide. Vous pouvez valider le fichier keytab lorsque vous configurez ou vérifiez la configuration Kerberos d'une cible de montage.

Lorsque vous validez le fichier keytab Kerberos au moyen de la console, de l'interface de ligne de commande ou de l'API, le service File Storage vérifie ce qui suit :

  • Si la taille du fichier keytab est supérieure à 1024 octets
  • Que le numéro de version du keytab n'est pas 1281 ou 1282
  • Si le keytab contient des entrées nulles
  • Si le keytab contient des entrées avec des noms principaux différents
  • Si le keytab a plus de 12 entrées, ce qui est le maximum
  • Si le type d'encodage keytab n'est pas l'un des suivants :
    • ETYPE_AES128_CTS_HMAC_SHA1_96
    • ETYPE_AES256_CTS_HMAC_SHA1_96
    • ETYPE_AES128_CTS_HMAC_SHA256_128
    • ETYPE_AES256_CTS_HMAC_SHA384_192
Note

Un keytab extrait du KDC en format binaire doit être converti en Base64, puis utilisé pour créer une clé secrète dans la chambre forte OCI. Assurez-vous de sélectionner Base64 comme format de la clé secrète lorsque vous collez le fichier keytab converti.

Le stockage de fichiers prend en charge la rotation du fichier keytab à l'aide d'un fichier keytab de sauvegarde. Pour plus d'informations, voir Rotation de clés.

Considérations et limites

Lors de l'utilisation de Kerberos pour l'authentification de stockage de fichiers, tenez compte des informations et limites suivantes.

  • Pour l'authentification Kerberos par utilisateur, le stockage de fichiers nécessite l'infrastructure LDAP (Lightweight Directory Access Protocol) gérée par le client, notamment un serveur LDAP qui prend en charge un schéma POSIX RFC2307.
  • File Storage prend en charge une taille maximale du fichier keytab Kerberos de 1024 octets.

  • File Storage prend en charge le jeu de chiffrements suivant :

    • aes128-cts-hmac-sha256-128
    • aes256-cts-hmac-sha384-192
    • aes128-cts-hmac-sha1-96
    • aes256-cts-hmac-sha1-96
  • Le montage de systèmes de fichiers avec les options rsize ou wsize n'est pas recommandé. Si vous fournissez des valeurs pour ces options, elles peuvent être réduites à 256 Ko par le service de stockage de fichiers lorsque vous utilisez KRB5I ou KRB5P.
  • La performance du stockage de fichiers lors de l'utilisation du mode d'authentification Kerberos KRB5 équivaut à peu près à l'utilisation de l'authentification AUTH_SYS. La performance diminue considérablement lors de l'utilisation de KRB5P et diminue légèrement lors de l'utilisation de KRB5I. Les performances peuvent varier en fonction de la configuration du client et du système de fichiers.

Surveillance et alertes

Il est important de prendre rapidement conscience d'un problème lors de l'utilisation de l'authentification Kerberos avec l'autorisation LDAP. Si l'infrastructure Kerberos ou LDAP ne fonctionne pas correctement, les clients NFS pourraient perdre l'accès aux systèmes de fichiers de stockage de fichiers mis à disposition par le biais de ses exportations. Pour détecter de tels problèmes, nous vous recommandons de définir des alarmes sur les mesures de la cible de montage. Les alarmes peuvent vous alerter en quelques minutes sur les problèmes d'infrastructure.

Les alarmes créées à partir d'erreurs Kerberos, d'erreurs de connexion LDAP et d'erreurs de demande LDAP détectent les problèmes de connectivité entre les cibles de montage, les connecteurs sortants et l'infrastructure LDAP gérée par le client.

L'exemple d'interrogation suivant peut être utilisé pour créer une alarme pour les erreurs Kerberos :

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

L'exemple d'interrogation suivant peut être utilisé pour créer une alarme pour la connectivité LDAP :

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

Pour plus d'informations sur la surveillance des mesures et l'utilisation des alarmes, voir Aperçu de la surveillance. Pour plus d'informations sur les avis relatifs aux alarmes, voir Aperçu des avis.

Politique GIA requise

Le service de stockage de fichiers doit accéder au mot de passe du serveur LDAP et aux clés secrètes de chambre forte du keytab Kerberos de la cible de montage pour la configuration Kerberos. L'utilisateur qui configure la cible de montage et la cible de montage elle-même ont besoin d'un accès en lecture.

Politique de gestion des clés secrètes de chambre forte

Accordez à l'utilisateur ou au groupe qui crée les autorisations de clé secrète de la chambre forte. Pour plus d'informations, voir Gestion des clés secrètes de chambre forte.

Politique pour activer la configuration de la cible de montage

Accordez à l'utilisateur ou au groupe configurant Kerberos et LDAP sur des autorisations de cible de montage à l'aide d'une politique telle que :

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> }

L'utilisateur peut ainsi exécuter des commandes de stockage de fichiers qui lisent les clés secrètes du service de chambre forte et affichent des parties de la clé secrète pour validation. Le service de stockage de fichiers présente le principal, le numéro de version de la clé et les types de chiffrement à l'utilisateur qui configure la cible de montage pour la validation.

Politique permettant à une cible de montage d'extraire des clés secrètes

Le service File Storage nécessite la possibilité de lire les clés secrètes. Le service de stockage de fichiers utilise des principaux de ressource pour accorder à un jeu spécifique de cibles de montage l'accès à la clé secrète de la chambre forte. Il s'agit d'un processus en deux étapes, d'abord les cibles de montage qui ont besoin d'accès doivent être placées dans un groupe dynamique, puis le groupe dynamique est autorisé à lire les clés secrètes.

  1. Créez un groupe dynamique pour les cibles de montage avec une politique telle que :

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

    Si vous avez plusieurs règles dans le groupe dynamique, assurez-vous d'utiliser l'option Match any rules defined below.

  2. Créez une politique IAM qui donne au groupe dynamique de cibles de montage l'accès en lecture aux clés secrètes du service de chambre forte :

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