Ignorer les liens de navigation | |
Quitter l'aperu | |
Administration d'Oracle Solaris : services de sécurité Oracle Solaris 11 Information Library (Français) |
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. Service d'analyse antivirus (tâches)
5. Contrôle de l'accès aux périphériques (tâches)
6. Utilisation de l'outil de génération de rapports d'audit de base (tâches)
7. Contrôle de l'accès aux fichiers (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. Attributs de sécurité dans Oracle Solaris (référence)
Partie IV Services cryptographiques
11. Structure cryptographique (présentation)
12. Structure cryptographique (tâches)
13. Structure de gestion des clés
Partie V Services d'authentification et communication sécurisée
14. Authentification des services réseau (tâches)
17. Utilisation de Secure Shell (tâches)
19. Introduction au service Kerberos
20. Planification du service Kerberos
21. Configuration du service Kerberos (tâches)
22. Messages d'erreur et dépannage de Kerberos
23. Administration des principaux et des stratégies Kerberos (tâches)
24. Utilisation des applications Kerberos (tâches)
25. 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 service 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 dans Oracle Solaris
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 Solaris 10, les KDC esclaves doivent être mis à niveau vers la version Solaris 10 avant de mettre à niveau le KDC maître. Un KDC maître Solaris 10 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 type de clé/chiffrement associé à l'entrée du principal du serveur 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 Solaris 10, 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 les KDC esclaves.
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.