Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Guide d'administration système : Services de sécurité |
Partie I Présentation de la sécurité
1. Services de sécurité (présentation)
Partie II Sécurité du système, des fichiers et des périphériques
2. Gestion de la sécurité de la machine (présentation)
3. Contrôle de l'accès aux systèmes (tâches)
4. Contrôle de l'accès aux périphériques (tâches)
5. Utilisation de l'outil de génération de rapports d'audit de base (tâches)
6. Contrôle de l'accès aux fichiers (tâches)
7. Utilisation d'Automated Security Enhancement Tool (Tâches)
Partie III Rôles, profils de droits et privilèges
8. Utilisation des rôles et des privilèges (présentation)
9. Utilisation du contrôle d'accès basé sur les rôles (tâches)
10. Contrôle d'accès basé sur les rôles (référence)
Partie IV Services cryptographiques
13. Structure cryptographique Oracle Solaris (présentation)
14. Structure cryptographique Oracle Solaris (tâches)
15. Structure de gestion des clés Oracle Solaris
Partie V Services d'authentification et communication sécurisée
16. Utilisation des services d'authentification (tâches)
19. Utilisation d'Oracle Solaris Secure Shell (tâches)
20. Oracle Solaris Secure Shell (référence)
21. Introduction au service Kerberos
22. Planification du service Kerberos
23. Configuration du service Kerberos (tâches)
24. Messages d'erreur et dépannage de Kerberos
25. Administration des principaux et des stratégies Kerberos (tâches)
26. Utilisation des applications Kerberos (tâches)
27. Service Kerberos (référence)
Terminologie spécifique à Kerberos
Terminologie spécifique à l'authentification
Fonctionnement du système d'authentification Kerberos
Interaction du service Kerberos avec le DNS et le fichier nsswitch.conf
Obtention de l'accès à un service à l'aide de Kerberos
Obtention d'informations d'identification pour le service d'octroi de tickets
Obtention d'informations d'identification pour un serveur
Obtention de l'accès à un service donné
Utilisation de la table gsscred
Différences notables entre Oracle Solaris Kerberos et MIT Kerberos
Partie VII Audit Oracle Solaris
28. Audit Oracle Solaris (présentation)
29. Planification de l'audit Oracle Solaris
30. Gestion de l'audit Oracle Solaris (tâches)
Les types de chiffrement identifient les algorithmes cryptographiques et le mode à utiliser lors d'opérations cryptographiques. Les types de chiffrement aes , des3-cbc-sha1 et rc4–hmac permettent de créer des clés à utiliser pour des opérations cryptographiques renforcées. Ces opérations renforcées améliorent la sécurité globale du service Kerberos.
Remarque - Dans les versions antérieures à la version Solaris 10 8/07, le type de chiffrement aes256-cts-hmac-sha1-96 peut être utilisé avec le service Kerberos si les packages Strong Cryptographic non fournis en standard sont installés.
Lorsqu'un client demande un ticket au KDC, le KDC doit utiliser des clés dont le type de chiffrement est compatible à la fois avec le client et le serveur. Bien que le protocole Kerberos permette au client de demander à ce que le KDC utilise certains types de chiffrement pour la partie de réponse du ticket du client, le protocole n'autorise pas le serveur à spécifier des types de chiffrement au KDC.
Remarque - Si le KDC maître installé n'exécute pas la version Solaris10, le KDC esclave doit être mis à niveau vers la version Solaris10 avant de mettre à niveau le KDC maître. Un KDC maître Solaris10 utilise les nouveaux types de chiffrement, ce qu'un esclave plus ancien n'est pas en mesure de faire.
Le tableau suivant répertorie certains des problèmes à prendre en compte avant de modifier les types de chiffrement.
Le KDC suppose que le premier key/enctype associé à l'entrée du serveur principal dans la base de données du principal est pris en charge par le serveur.
Sur le KDC, vous devez vous assurer que les clés générées pour le principal sont compatibles avec les systèmes sur lesquels le principal sera authentifié. Par défaut, la commande kadmin crée des clés pour tous les types de chiffrement pris en charge. Si les systèmes sur lesquels le principal est utilisé ne prennent pas en charge cette configuration par défaut des types de chiffrement, vous devez restreindre les types de chiffrement lors de la création d'un principal. Vous pouvez limiter les types de chiffrement par l'intermédiaire de l'indicateur -e dans kadmin addprinc ou en définissant le paramètre supported_enctypes dans le fichier kdc.conf sur ce sous-ensemble. Le paramètre supported_enctypes doit être utilisé lorsque la plupart des systèmes d'un domaine Kerberos prennent en charge un sous-ensemble de l'ensemble par défaut des types de chiffrement. Le paramètre supported_enctypes spécifie l'ensemble par défaut des types de chiffrement utilisés par kadmin addprinc lorsqu'il crée un principal pour un domaine particulier. En règle générale, il est préférable de contrôler les types de chiffrement utilisés par Kerberos à l'aide de l'une de ces deux méthodes.
Au moment de déterminer les types de chiffrement pris en charge par un système, pensez à la fois à la version de Kerberos exécutée sur le système et aux algorithmes cryptographiques pris en charge par l'application du serveur pour lequel un principal de serveur est en cours de création. Par exemple, lorsque vous créez un principal de service nfs/hostname, il est conseillé de limiter les types de chiffrement aux types pris en charge par le serveur NFS de l'hôte. Notez que dans la version Solaris10, tous les types de chiffrement Kerberos pris en charge le sont également par le serveur NFS.
Le paramètre master_key_enctype dans le fichier kdc.conf peut être utilisé pour contrôler le type de chiffrement de la clé principale qui chiffre les entrées dans la base de données du principal. N'utilisez pas ce paramètre si la base de données du principal KDC a déjà été créée. Le paramètre master_key_enctype peut être utilisé au moment de la création de la base de données afin de faire passer le type de chiffrement de la clé principale par défaut de des-cbc-crc à un type de chiffrement supérieur. Assurez-vous que tous les KDC esclaves prennent en charge le type de chiffrement choisi et qu'ils ont la même entrée master_key_enctype dans leur kdc.conf lorsque vous configurez les KDC esclaves. Assurez-vous également que le paramètre master_key_enctype est défini sur l'un des types de chiffrement dans supported_enctypes, si supported_enctypes est défini dans kdc.conf. Si l'une ou l'autre de ces situations n'est pas gérée correctement, le KDC maître peut ne pas être en mesure de travailler avec le KDC esclave.
Sur le client, vous pouvez contrôler les types de chiffrement demandés par le client lors de l'obtention de tickets du KDC par le biais de quelques paramètres dans krb5.conf. Le paramètre default_tkt_enctypes spécifie les types de chiffrement que le client est disposé à utiliser lorsqu'il demande un ticket d'octroi de tickets (TGT) au KDC. Le TGT est utilisé par le client pour acquérir d'autres tickets de serveur d'une manière plus efficace. L'effet du paramètre default_tkt_enctypes est de donner au client un contrôle sur les types de chiffrement utilisés pour protéger les communications entre le client et le KDC, lorsque le client demande un ticket de serveur via TGT (aussi appelé demande TGS). Notez que les types de chiffrement spécifiés dans default_tkt_enctypes doivent correspondre à au moins l'un des types de chiffrement de clé du principal dans la base de données du principal stockée sur le KDC. Dans le cas contraire, la demande TGS échoue. Dans la plupart des cas, il est préférable de ne pas définir default_tkt_enctypes car ce paramètre peut être une source de problèmes d'interopérabilité. Par défaut, le code client demande tous les types de chiffrement pris en charge et le KDC choisit les types de chiffrement en fonction des clés que le KDC trouve dans la base de données du principal.
Le paramètre default_tgs_enctypes restreint les types de chiffrement demandés par le client dans ses demandes TGS, qui sont utilisés pour l'acquisition de tickets de serveur. Ce paramètre restreint également les types de chiffrement utilisés par le KDC lors de la création de la clé de session partagée par le client et le serveur. Par exemple, si un client souhaite utiliser uniquement le chiffrement 3DES pour un NFS sécurisé, vous devez définir default_tgs_enctypes = des3-cbc-sha1. Assurez-vous que les principaux du client et du serveur ont une clé des-3-cbc-sha1 dans la base de données du principal. Comme avec default_tkt_enctype, il est sans doute préférable dans la plupart des cas de ne pas définir ce paramètre, car il peut provoquer des problèmes d'interopérabilité si les informations d'identification ne sont pas configurées correctement sur le KDC et le serveur.
Sur le serveur, vous pouvez contrôler les types de chiffrement acceptés par le serveur avec le paramètre permitted_enctypes de kdc.conf. De plus, vous pouvez spécifier les types de chiffrement utilisés lors de la création d'entrées keytab. Encore une fois, il est généralement préférable de ne pas utiliser l'une de ces méthodes pour contrôler les types de chiffrement et de laisser le KDC déterminer les types de chiffrement à utiliser, car le KDC ne communique pas avec l'application de serveur pour déterminer la clé ou le type de chiffrement à utiliser.