test

Guide de l'administrateur d'entreprise de Sun Identity Manager 8.1

Chapitre 12 Sécurité

Ce chapitre contient des informations sur les fonctionnalités de sécurité d'Identity Manager et détaille les étapes à suivre pour réduire encore les risques.

Lisez les rubriques suivantes pour en savoir plus sur la gestion de la sécurité des systèmes avec Identity Manager.

Fonctionnalités de sécurité

Identity Manager favorise une diminution des risques de sécurité grâce aux fonctionnalités suivantes :

De plus, l'architecture du système cherche à réduire dès que possible les risques de sécurité. Par exemple, une fois déconnecté, vous ne pouvez plus accéder aux pages visitées au préalable en utilisant la fonctionnalité Précédent de votre navigateur.

Limitation des sessions de connexion simultanées

Par défaut, un utilisateur Identity Manager peut avoir plusieurs sessions de connexion simultanées. Vous pouvez limiter les sessions simultanées à une session par application de connexion en ouvrant l'objet Configuration système pour le modifier (Édition des objets Configuration Identity Manager) et en éditant la valeur de l'attribut Configuration security.authn.singleLoginSessionPerApp. Cet attribut est un objet qui contient un attribut pour chaque nom d'application de connexion (par exemple, l'interface administrateur, l'interface utilisateur ou Identity Manager IDE). Remplacer sa valeur par true impose une unique session de connexion pour chaque utilisateur.

Dans ce cas, un utilisateur peut se connecter à plus d'une seule session, mais seule la dernière session de connexion demeure active et valide. Si l'utilisateur exécute une action dans une session invalide, il est automatiquement déconnecté de la session et celle-ci se termine.

Gestion des mots de passe

Identity Manager propose plusieurs niveaux de gestion de mots de passe :

Authentification d'intercommunication

L'authentification d'intercommunication permet d'accorder des droits d'accès utilisateur et administrateur par le biais de un ou plusieurs mots de passe différents.

Identity Manager gère l'authentification à travers l'implémentation des éléments suivants :

À propos des applications de connexion

Les applications de connexion définissent un ensemble de groupes de modules de connexion, qui définissent eux-mêmes l'ensemble et l'ordre des modules de connexion utilisés lorsqu'un utilisateur se connecte à Identity Manager. Chaque application de connexion comprend un ou plusieurs groupes de modules de connexion.

Au moment de la connexion, l'application de connexion vérifie son ensemble de groupes de modules de connexion. Si seul un groupe de modules de connexion est défini, il est utilisé et les modules de connexion qu'il contient sont traités dans l'ordre défini à l'intérieur du groupe. Si l'application de connexion comporte plusieurs groupes de modules de connexion définis, Identity Manager vérifie les règles de contrainte de connexion appliquées à chaque groupe de modules pour déterminer celui à traiter.

Règles de contrainte de connexion

Les règles de contrainte de connexion sont appliquées aux groupes de modules de connexion. Dans chacun des ensembles de groupes de modules d'une application de connexion, seul un groupe peut ne pas se voir appliquer de règle de contrainte de connexion.

Pour déterminer, dans un ensemble, celui des groupes de modules de connexion qui doit être traité, Identity Manager évalue la compatibilité du premier groupe de modules de connexion avec la règle de contrainte. Si ce premier groupe de modules de connexion respecte la règle, il est traité par Identity Manager. Si ce groupe ne respecte pas la règle, Identity Manager évalue tous les groupes de modules de connexion les uns après les autres jusqu'à ce que l'un des groupes soit conforme à la règle, ou qu'un groupe de modules de connexion auquel aucune règle de contrainte n'est appliquée soit évalué (et donc utilisé).

Remarque –

Si une application de connexion contient plus d'un groupe de modules de connexion, le groupe auquel aucune règle de contrainte n'est appliquée doit être placé en dernière position dans l'ensemble des groupes.

Exemple de règle de contrainte de connexion

L'exemple suivant est un exemple de règle de contrainte de connexion basée sur l'emplacement. La règle récupère l'adresse IP du demandeur dans l'en-tête HTTP, puis vérifie si elle se trouve sur le réseau 192.168. Si l'adresse IP contient la valeur 192.168, la règle retourne la valeur true et le groupe de modules de connexion est sélectionné.

Exemple 12–1 Règle de contrainte de connexion basée sur l'emplacement


<Rule authType=’LoginConstraintRule’ name=’Sample On Local Network’> 
<match> <ref>remoteAddr</ref> <s>192.168.</s> </match> 
<MemberObjectGroups> <ObjectRef type=’ObjectGroup’ name=’All’/> </MemberObjectGroups> 
</Rule>

Édition des applications de connexion

Dans la barre de menu, sélectionnez Sécurité -> Connexion pour accéder à la page Connexion.

La liste des applications de connexion affiche les éléments suivants :

Depuis la page Connexion, vous pouvez :

Pour éditer une application de connexion, sélectionnez-la dans la liste.

Définition des limites des sessions Identity Manager

La page Modifier une application de connexion vous permet de définir un délai d'attente (limite) pour chaque session de connexion à Identity Manager. Sélectionnez les heures, minutes et secondes, puis cliquez sur Enregistrer. Les limites établies s'affichent dans la liste des applications de connexion.

Vous pouvez définir des délais d'attente de session pour chaque application de connexion à Identity Manager. Lorsqu'un utilisateur se connecte à une application Identity Manager, la valeur de délai d'attente de session actuellement configurée est utilisée pour calculer la date et l'heure à venir auxquelles la session de l'utilisateur expirera pour être restée inactive. La date calculée est ensuite stockée avec la session Identity Manager de l'utilisateur de sorte à pouvoir être contrôlée à chaque fois qu'une demande est formulée.

Si un administrateur de connexion modifie la valeur du délai d'attente de session d'une application de connexion, la nouvelle valeur sera appliquée pour toutes les connexions futures. Les sessions existantes expireront sur la base de la valeur en vigueur au moment de la connexion de l'utilisateur.

Les valeurs définies pour le délai d'attente HTTP s'appliquent à toutes les applications Identity Manager et ont la priorité sur la valeur de délai d'attente de session de l'application de connexion.

Désactivation de l'accès aux applications

Dans les pages Créer une application de connexion et Modifier une application de connexion, vous pouvez sélectionner l'option Désactiver pour désactiver une application de connexion et empêcher par là les utilisateurs de se connecter. Si un utilisateur essaie de se connecter à une application désactivée, l'utilisateur est réacheminé sur une autre page indiquant que l'application est actuellement désactivée. Vous pouvez éditer le message qui s'affiche sur cette page en éditant le catalogue personnalisé.

Les applications de connexion restent désactivées jusqu'à ce que vous désélectionniez l'option. À titre de protection, vous ne pouvez pas désactiver la connexion de l'administrateur.

Édition des groupes de modules de connexion

La liste des groupes de modules de connexion affiche les éléments suivants :

Vous pouvez créer, éditer et supprimer des groupes de modules de connexion depuis la page Groupes de modules de connexion. Sélectionnez un groupe de modules de connexion dans la liste pour l'éditer.

Édition des modules de connexion

Saisissez les détails ou effectuez des sélections pour les modules de connexion comme indiqué ci-après (les options ne sont pas toutes disponibles pour tous les modules de connexion).

Cliquez sur Enregistrer pour enregistrer un module de connexion. Une fois le module enregistré, vous pouvez en choisir la position par rapport aux autres modules de connexion du groupe.

Attention – Attention –

Si la configuration de connexion d'Identity Manager permet de s'authentifier sur plusieurs systèmes, il est recommandé d'utiliser les mêmes ID utilisateur et mot de passe de compte sur tous les systèmes cibles de l'authentification Identity Manager.

Si les combinaisons ID utilisateur/mot de passe diffèrent, la connexion échoue sur tous les systèmes dont l'ID utilisateur et le mot de passe ne correspondent pas à ceux saisis dans le formulaire Identity Manager User Login.

Certains de ces systèmes peuvent avoir une stratégie de blocage qui impose un nombre limite d'échecs de connexion au-delà duquel le compte est verrouillé. Pour ces systèmes, les comptes utilisateur peuvent être verrouillés même si la connexion de l'utilisateur à travers Identity Manager continue à fonctionner.

L'Exemple 12–2 contient un pseudocode qui décrit les étapes suivies par Identity Manager pour mapper les ID utilisateur authentifiés vers les utilisateurs Identity Manager.

Exemple 12–2 Logique de traitement des modules de connexion


if an existing IDM user’s ID is the same as the specified user ID 

   if that IDM user has a linked resource whose resource name matches the 
   resource that was authenticated and whose accountId matches the resource 
   accountId returned by successful authentication (e.g. dn), then we have 
   found the right IDM user 

   otherwise if there is a LoginCorrelationRule associated with the 
   configured login module 

      evaluate it to see if it maps the login credentials to a single IDM 
      user 

      otherwise login fails 

   otherwise login fails 

if the specified userID does not match an existing IDM user’s ID 

   try to find an IDM user that has a linked resource whose resource 
   name matches the resource accountID returned by successful authentication 

     if found, then we have found the right IDM user 

     otherwise if there is a LoginCorrelationRule associated with the 
     configured login module 

         evaluate it to see if it maps the login credentials to a single 
         IDM user 

         otherwise login fails 

     otherwise login fails

Dans l'Exemple 12–2, le système essaie de trouver un utilisateur Identity Manager correspondant en utilisant les ressources reliées de l'utilisateur (informations sur les ressources). Si l'approche basée sur les informations sur les ressources échoue et qu'une règle loginCorrelationRule est configurée, le système essaie de trouver un utilisateur correspondant en utilisant cette règle.

Configuration de l'authentification pour les ressources communes

Si vous avez plusieurs ressources identiques sur le plan logique (par exemple, plusieurs serveurs de domaine Active Directory partageant une relation de confiance) ou plusieurs ressources résidant toutes sur le même hôte physique, vous pouvez spécifier que ces ressources sont des ressources communes.

Vous avez intérêt à déclarer les ressources communes car Identity Manager sait ainsi qu'il n'a à essayer et à s'authentifier qu'une fois auprès d'un groupe de ressources. Sinon, si un utilisateur saisit un mot de passe erroné, Identity Manager essaie le même mot de passe sur chaque ressource. Ceci peut entraîner le blocage du compte de l'utilisateur suite à de trop nombreux échecs de connexion, même si l'utilisateur n'a saisi qu'une fois le mot de passe erroné.

Avec les ressources communes, si un utilisateur s'authentifie auprès d'une ressource commune, Identity Manager essaie automatiquement et mappe l'utilisateur vers les ressources restantes du groupe de ressources communes. Par exemple, un compte utilisateur Identity Manager peut être lié à un compte de ressource pour la ressource AD-1. Le groupe de modules de connexion, cependant, peut définir que les utilisateurs doivent s'authentifier auprès de la ressource AD-2.

Si AD-1 et AD-2 sont définies comme des ressources communes (dans ce cas, dans le même domaine de confiance), si l'utilisateur réussit à s'authentifier auprès d'AD-2, Identity Manager peut mapper également l'utilisateur vers AD-1 en trouvant le même ID de compte utilisateur sur la ressource AD-1.

Attention – Attention –

Toutes les ressources listées dans un groupe de ressources communes doivent également être incluses dans la définition du module de connexion. Si une liste complète des ressources communes ne figure pas dans la définition du module de connexion, cette fonctionnalité ne se comportera pas correctement.

Les ressources communes peuvent être définies dans l'objet Configuration système (Édition des objets Configuration Identity Manager) en utilisant le format suivant.

Exemple 12–3 Configuration de l'authentification pour les ressources communes 


<Attribute name=’common resources’> 
<Attribute name=’Common Resource Group Name’> 
<List> 
<String>Common Resource Name</String> 
<String>Common Resource Name</String> 
</List 
</Attribute> </Attribute>

Configuration de l'authentification des certificats X509

Utilisez les informations et procédures suivantes pour configurer l'authentification des certificats X509 pour Identity Manager.

Prérequis pour la configuration

Pour prendre en charge l'authentification basée sur les certificats X509 dans Identity Manager, assurez-vous que l'authentification SSL bidirectionnelle (client et serveur) est configurée correctement. Du point de vue du client, cela signifie qu'un certificat d'utilisateur conforme X509 doit avoir été importé dans le navigateur (ou être disponible par le biais d'un lecteur de cartes à puce) et que le certificat de confiance doit être importé dans le keystore de certificats de confiance du serveur d'application Web.

Par ailleurs, le certificat client utilisé doit être activé pour l'authentification client.

ProcedurePour vérifier que l'option authentification client du certificat client utilisé est sélectionnée

  1. En utilisant Internet Explorer, sélectionnez Outils puis Options Internet.

  2. Sélectionnez l’onglet Contenu.

  3. Dans la zone Certificats, cliquez sur Certificats.

  4. Sélectionnez le certificat client puis cliquez sur Avancé.

  5. Dans la zone réservée au but du certificat, vérifiez que l'option Authentification client est sélectionnée.

Configuration de l'authentification basée sur les certificats X509 dans Identity Manager

ProcedurePour configurer l'authentification basée sur les certificats X509

  1. Connectez-vous à l'interface administrateur en tant que Configurator (ou avec des permissions équivalentes).

  2. Sélectionnez Configurer puis Connexion pour afficher la page Connexion.

  3. Cliquez sur Gérer les groupes de modules de connexion pour afficher la page Groupes de modules de connexion.

  4. Sélectionnez un groupe de modules de connexion dans la liste.

  5. Sélectionnez Module de connexion Certification X509 Identity Manager dans la liste Assigner le module de connexion. Identity Manager affiche la page Modifier un module de connexion.

  6. Définissez l'exigence de réussite de connexion.

    Les valeurs suivantes sont acceptables :

    • requis. Le module de connexion est requis pour la réussite de l'opération. Que l'opération réussisse ou non, l'authentification passe au module de connexion suivant de la liste. S'il n'y a pas d'autre module de connexion, l'ouverture de session administrateur réussit.

    • exigence. Le module de connexion est requis pour la réussite de l'opération. En cas de réussite, l'authentification passe au module de connexion suivant de la liste. Dans le cas contraire, l'authentification s'arrête.

    • suffisant. Le module de connexion n'est pas requis pour la réussite de l'opération. En cas de réussite, l'authentification ne passe pas au module de connexion suivant et l'administrateur est connecté. Dans le cas contraire, l'authentification passe au module de connexion suivant de la liste.

    • en option. Le module de connexion n'est pas requis pour la réussite de l'opération. Que l'opération réussisse ou non, l'authentification passe au module de connexion suivant de la liste.

  7. Sélectionnez une règle de corrélation de connexion. Il peut s'agir indifféremment d'une règle intégrée ou d'une règle de corrélation personnalisée (pour toute information sur la création de règles de corrélation personnalisées, voir la section suivante).

  8. Cliquez sur Enregistrer pour revenir à la page Modifier un groupe de modules de connexion.

  9. En option, triez de nouveau les modules de connexion (si plus d'un module de connexion est assigné au groupe de modules de connexion) et cliquez sur Enregistrer.

  10. Assignez le groupe de modules de connexion à une application de connexion s'il ne l'est pas déjà. Dans la page Groupes de modules de connexion, cliquez sur Revenir aux applications de connexion puis sélectionnez une application de connexion. Après avoir assigné un groupe de modules de connexion à l'application, cliquez sur Enregistrer.

    Remarque –

    Si l'option allowLoginWithNoPreexistingUser est définie sur la valeur true dans le fichier waveset.properties, vous serez invité lorsque vous configurerez le Module de connexion Certification X509Identity Manager à sélectionner une Règle de nom de nouvel utilisateur. Cette règle permettra de déterminer la façon dont seront nommés les nouveaux utilisateurs créés lorsqu'ils ne seront pas trouvés par la Règle de corrélation de connexion associée. La règle de nom de nouvel utilisateur a les mêmes arguments d'entrée disponibles que la Règle de corrélation de connexion. Elle retourne une unique chaîne constituée du nom d'utilisateur utilisé pour créer le nouveau compte utilisateur Identity Manager. Un exemple de règle de nom de nouvel utilisateur figure dans idm/sample/rules, sous le nom NewUserNameRules.xml.

Création et importation d'une règle de corrélation de connexion

Le Module de connexion Certification X509 d'Identity Manager utilise une règle de corrélation pour déterminer comment mapper les données de certificat vers l'utilisateur Identity Manager approprié. Identity Manager inclut une règle de corrélation intégrée, nommée Corréler via X509 Certificate SubjectDN.

Vous pouvez aussi ajouter vos propres règles de corrélation. À titre d'exemple, consultez LoginCorrelationRules.xml dans le répertoire idm/sample/rules.

Toute règle de corrélation doit respecter les directives suivantes :

Les arguments transmis aux règles de corrélation de connexion sont les suivants :

La convention de nommage pour les arguments de certificat transmis à la règle de corrélation de connexion est :

cert.field name.subfield name

Voici quelques exemples de noms d'arguments disponibles pour la règle :

La règle de corrélation de connexion, en utilisant les arguments transmis, retourne une liste de une ou plusieurs AttributeConditions. Celles-ci sont utilisées par le Module de connexion Certification X509Identity Manager pour trouver l'utilisateur Identity Manager associé.

Une exemple de règle de corrélation de connexion nommé LoginCorrelationRules.xml est inclus dans idm/sample/rules.

Après avoir créé une règle de corrélation personnalisée, vous devez l'importer dans Identity Manager. Depuis l'interface administrateur, sélectionnez Configurer puis Importer le fichier d’échange pour utiliser l'utilitaire d'importation de fichiers.

Test de la connexion SSL

Pour tester la connexion SSL, allez à l'URL de l'interface de l'application configurée en utilisant SSL (par exemple, https://idm007:7002/idm/user/login.jsp). Vous êtes averti que vous entrez dans un site sécurisé et êtes invité à préciser quel certificat personnel envoyer au serveur Web.

Diagnostic des problèmes

Signalez tous les problèmes liés à l'authentification utilisant des certificats X509 comme des messages d'erreur sur le formulaire de connexion.

Pour des diagnostics plus complets, activez le suivi sur le serveur Identity Manager pour les classes et niveaux suivants :

Si l'attribut de certificat client n'est pas nommé javaxservlet.request.X509Certificate dans la requête HTTP, vous recevrez un message indiquant que cet attribut est introuvable dans la requête HTTP.

ProcedurePour corriger un nom d'attribut de certificat client dans une requête HTTP

  1. Activez le suivi pour SessionFactory pour afficher la liste complète des attributs HTTP et déterminer le nom du certificat X509.

  2. Utilisez l'utilitaire de débogage d'Identity Manager (Page de débogage d'Identity Manager) pour éditer l'objet LoginConfig.

  3. Remplacez le nom de <AuthnProperty> dans <LoginConfigEntry> pour le Module de connexion Certification X509 Identity Manager par le nom correct.

  4. Enregistrez puis réessayez.

    Il est également possible que vous deviez supprimer puis ajouter de nouveau le Module de connexion Certification X509 Identity Manager dans l'application de connexion.

Utilisation et gestion du chiffrement

Le chiffrement est utilisé pour assurer la confidentialité et l'intégrité des données du serveur en mémoire et dans le référentiel, ainsi que celles de toutes les données transmises entre le serveur Identity Manager et la passerelle.

Les sections suivantes fournissent des informations supplémentaires sur l'utilisation et la gestion du chiffrement dans le serveur Identity Manager et la passerelle, et répondent aux questions relatives aux clés de chiffrement du serveur et de la passerelle.

Données protégées par chiffrement

Le tableau suivant indique les types de données qui sont protégés par chiffrement dans le produit Identity Manager ainsi que les codes utilisés pour protéger chaque type de données.

Tableau 12–1 Types de données protégés par chiffrement

Type de données  

RSAMD5 

Clé NIST Triple DES 168 bits (DESede/ECB/NoPadding) 

Clé PKCS#5 basée sur des mots de passe Crypto 56 bits (PBEwithMD5andDES) 

Clés de chiffrement du serveur 

 

Valeur par défaut 

Option de configuration 

Clés de chiffrement de la passerelle 

 

Valeur par défaut 

Option de configuration 

Mots du dictionnaire des stratégies 

Oui 

   

Mots de passe utilisateur 

 

Oui 

 

Historique des mots de passe utilisateur  

 

Oui 

 

Réponses de l'utilisateur 

 

Oui 

 

Mots de passe des ressources  

 

Oui 

 

Historique des mots de passe des ressources 

Oui 

   

Toute la charge utile entre le serveur et les passerelles 

 

Oui 

 

Foire Aux Questions relative aux clés de chiffrement du serveur

Vous trouverez dans les sections suivantes les réponses aux questions fréquemment posées sur la source, l'emplacement, la maintenance et l'utilisation des clés de chiffrement du serveur.

Question :

D'où viennent les clés de chiffrement du serveur ?

Réponse :

Les clés de chiffrement du serveur sont des clés Triple-DES symétriques de 168 bits.

Le serveur prend en charge les deux types de clés suivants :

Question :

Où les clés de chiffrement du serveur sont-elles conservées ?

Réponse :

Les clés de chiffrement du serveur sont des objets conservés dans le référentiel. Il peut y avoir de nombreuses clés de chiffrement de données dans tout référentiel.

Question :

Comment le serveur sait-il quelles clés utiliser pour le chiffrement et le rechiffrement des données chiffrées ?

Réponse :

Toute donnée chiffrée stockée dans le référentiel comporte un préfixe qui est l'ID de la clé de chiffrement du serveur qui a été utilisée pour la chiffrer. Lorsqu'un objet contenant des données chiffrées est lu en mémoire, Identity Manager utilise la clé de chiffrement de serveur associée au préfixe ID des données chiffrées à déchiffrer puis les rechiffre avec la même clé si les données sont modifiées.

Question :

Comment puis-je mettre à jour les clés de chiffrement du serveur ?

Réponse :

Identity Manager fournit une tâche appelée Gérer le chiffrement du serveur.

Cette tâche permet à un administrateur de sécurité autorisé d'effectuer plusieurs tâches de gestion de clés, notamment :

Pour plus d'informations sur l'utilisation de cette tâche, voir Gestion du chiffrement du serveur dans ce même chapitre.

Question :

Qu'arrive-t-il aux données chiffrées existantes si la clé de serveur « actuelle » est changée ?

Réponse :

Rien. Les données chiffrées existantes continueront à être déchiffrées ou rechiffrées avec la clé référencée par le préfixe ID des données chiffrées. Si une nouvelle clé de chiffrement du serveur est générée et définie comme étant la clé « actuelle », toutes les nouvelles données à chiffrer utiliseront cette nouvelle clé du serveur.

Pour éviter les problèmes liés à la cœxistence de plusieurs clés tout en maintenant un haut niveau d'intégrité des données, utilisez la tâche Gérer le chiffrement du serveur pour rechiffrer toutes les données chiffrées existantes avec la clé de chiffrement de serveur « actuelle ».

Question :

Que se passe-t-il quand vous importez des données chiffrées pour lesquelles aucune clé de chiffrement n'est disponible ?

Réponse :

Si vous importez un objet contenant des données chiffrées, mais que ces données ont été chiffrées avec une clé qui ne figure pas dans le référentiel dans lequel elles sont importées, ces données seront importées mais pas déchiffrées.

Question :

Comment les clés du serveur sont-elles protégées ?

Réponse :

Si le serveur n'est pas configuré pour utiliser le chiffrement basé sur les mots de passe (PBE) - PKCS#5 (défini dans l'objet Configuration système en utilisant l'attribut pbeEncrypt ou la tâche Gérer le chiffrement du serveur), la clé par défaut est utilisée pour chiffrer les clés du serveur. La clé par défaut est la même pour toutes les installations d'Identity Manager.

Si le serveur est configuré pour utiliser le chiffrement PBE, une clé PBE est générée à chaque fois que le serveur est démarré. La clé PBE est générée en fournissant un mot de passe, généré à partir d'un secret spécifique au serveur, au chiffrement PBEwithMD5andDES. La clé PBE est uniquement conservée dans la mémoire et n'est jamais persistante. De plus, la clé PBE est la même pour tous les serveurs partageant le même référentiel.

Pour activer le chiffrement PBE des clés du serveur, le chiffrement PBEwithMD5andDES doit être disponible. Identity Manager n'inclut pas par défaut ce chiffrement dans ses packages mais il s'agit d'un standard PKCS#5 disponible dans de nombreuses implémentations de fournisseurs JCE tels que ceux fournis par Sun et IBM.

Question :

Puis-je exporter les clés du serveur pour les stocker de manière sûre à l'extérieur ?

Réponse :

Oui. Si les clés du serveur sont chiffrées avec PBE, elle seront déchiffrées puis rechiffrées avec la clé par défaut avant d'être exportées. Ceci permettra de les importer sur le même ou sur un autre serveur à une date ultérieure, indépendamment de la clé PBE du serveur local. Si les clés du serveur sont chiffrées avec la clé par défaut, aucun traitement ne sera effectué avant leur exportation.

Lorsqu'elles sont importées sur un serveur configuré pour les clés PBE, les clés sont déchiffrées puis rechiffrées avec la clé PBE du serveur local si ce serveur est configuré pour le chiffrement par clés PBE.

Question :

Quelles sont les données chiffrées entre le serveur et la passerelle ?

Réponse :

Toutes les données (la charge utile) transmises entre le serveur et la passerelle sont chiffrées avec Triple-DES avec une clé symétrique par session serveur-passerelle générée de manière aléatoire de 168 bits.

Foire Aux Questions relative aux clés de passerelle

Vous trouverez dans les sections suivantes les réponses aux questions fréquemment posées sur la source, le stockage, la maintenance et la protection des clés de passerelle.

Question :

Quelle est la source des clés de passerelle employées pour chiffrer ou déchiffrer les données ?

Réponse :

À chaque fois qu'un serveur Identity Manager se connecte à une passerelle, le handshake initial génère une nouvelle clé Triple-DES aléatoire de 168 bits. Cette clé est utilisée pour chiffrer ou déchiffrer toutes les données transmises par la suite entre le serveur et cette passerelle. Une clé de session unique est générée pour chaque paire serveur/passerelle.

Question :

Comment les clés sont-elles distribuées aux passerelles ?

Réponse :

Les clés de session sont générées de manière aléatoire par le serveur puis échangées de manière sécurisée entre le serveur et la passerelle en étant chiffrées avec la clé maîtresse secrète partagée dans le cadre de l'handshake serveur-passerelle initial.

Lors du handshake initial, le serveur interroge la passerelle pour déterminer le mode que celle-ci prend en charge. La passerelle peut fonctionner dans les deux modes suivants :

Question :

Puis-je mettre à jour les clés de passerelle utilisées pour chiffrer ou déchiffrer la charge utile serveur-à-passerelle ?

Réponse :

Identity Manager fournit une tâche appelée Gérer le chiffrement du serveur qui permet à un administrateur de sécurité autorisé d'effectuer plusieurs tâches de gestion de clés et notamment de générer une nouvelle clé de passerelle « actuelle » et de mettre à jour toutes les passerelles avec cette clé de passerelle « actuelle ». Cette clé est celle utilisée pour chiffrer la clé par session utilisée pour protéger l'ensemble de la charge utile transmise entre le serveur et la passerelle. La clé de passerelle nouvellement générée sera chiffrée avec au choix la clé par défaut ou la clé PBE, selon la valeur de l'attribut pbeEncrypt dans l'objet Configuration système (Édition des objets Configuration Identity Manager).

Question :

Où les clés de passerelle sont-elles stockées sur le serveur, sur la passerelle ?

Réponse :

Sur le serveur, la clé de la passerelle est stockée dans le référentiel comme les clés du serveur. Sur la passerelle, la clé de la passerelle est stockée dans une clé de registre locale.

Question :

Comment les clés de la passerelle sont-elles protégées ?

Réponse :

La clé de la passerelle est protégée de la même façon que les clés du serveur. Si le serveur est configuré pour utiliser le chiffrement PBE, la clé de la passerelle sera chiffrée avec une clé générée par PBE. Si l'option est false, elle sera chiffrée avec la clé par défaut. Pour plus d'informations, voir Foire Aux Questions relative aux clés de chiffrement du serveur .

Question :

Puis-je exporter les clés de la passerelle pour les stocker de manière sûre à l'extérieur ?

Réponse :

La clé de la passerelle peut être exportée en utilisant la tâche Gérer le chiffrement du serveur comme les clés du serveur. Pour plus d'informations, voir Foire Aux Questions relative aux clés de chiffrement du serveur .

Question :

Comment les clés du serveur et de la passerelle sont-elles détruites ?

Réponse :

Pour détruire les clés du serveur et de la passerelle, vous devez les supprimer du référentiel du serveur. Vous remarquerez qu'aucune clé ne doit être supprimée tant qu'il reste des données du serveur chiffrées avec cette clé ou une passerelle reposant sur cette clé. Utilisez la tâche Gérer le chiffrement du serveur pour rechiffrer toutes les données du serveur avec la clé actuelle du serveur et pour synchroniser la clé actuelle de la passerelle avec toutes les passerelles pour assurer qu'aucune clé obsolète n'est encore utilisée avant sa suppression.

Gestion du chiffrement du serveur

La fonctionnalité de chiffrement du serveur d'Identity Manager permet de créer de nouvelles clés de chiffrement de serveur 3DES et de les chiffrer en utilisant le chiffrement 3DES, PKCS#5 ou AES (Advanced Encryption Standard). Seuls les utilisateurs ayant des capacités Administrateur de la sécurité peuvent exécuter la tâche Gérer le chiffrement du serveur, qui est configurée depuis la page Gérer le chiffrement du serveur.

ProcedurePour accéder à la page Gérer le chiffrement du serveur

Pour ouvrir la page Gérer le chiffrement du serveur :

  1. Sélectionnez Tâches du serveur > Exécuter des tâches.

  2. Dans la page Tâches disponibles qui s'affiche, cliquez sur Gérer le chiffrement du serveur pour ouvrir la page éponyme.

    Figure 12–1 Page Gérer le chiffrement du serveur

    Figure illustrant la page Gérer le chiffrement du serveur

ProcedurePour configurer le chiffrement du serveur

Utilisez cette page pour configurer le chiffrement du serveur et des objets, les clés de passerelle, les options de sauvegarde et le mode d'exécution.

  1. Saisissez un nom dans Nom de la tâche.

    Ce champ est par défaut Gérer le chiffrement du serveur. Vous pouvez entrer un autre nom de tâche si vous ne voulez pas utiliser le paramètre par défaut.

  2. Choisissez une ou plusieurs des options suivantes.

    Pour faire votre sélection :

    • Gérer le chiffrement du serveur. Choisissez cette option pour configurer le chiffrement du serveur.

      Les options supplémentaires suivantes s'affichent :

      • Chiffrement des clés de chiffrement serveur. Vous devez indiquer une méthode pour le chiffrement des clés de chiffrement du serveur. Les types de chiffrement peuvent être : Triple DES, PKCS#5 (DES), ou PKCS#5 (AES).

        Remarque –

        • Seuls les types de chiffrement instantiables sur votre système s'afficheront sur cette page. Par exemple, si votre système ne prend pas en charge PKCS#5 (AES), seuls Triple DES et PKCS#5 (DES) seront affichés.

        • Pour PKCS#5 (AES), vous devez télécharger et configurer les « Unlimited Strength Jurisdiction Policy Files » pour la JVM exécutant Identity Manager. Pour de plus amples détails, consultez la documentation de votre fournisseur Java.

          De plus, PKCS#5 (AES) requiert que vous installiez et configuriez le fichier jar Bouncy Castle JCE provider en fournisseur JCE pour la JVM exécutant Identity Manager. Ce fichier jar est packagé dans l'image d'installation d'Identity Manager et figure dans le répertoire wshome/WEB-INF/lib. Deux fichiers jar, bcprov-jdk15-137.jar et bcprov-jdk16-137.jar, sont fournis pour être utilisés avec les versions correspondantes de Java. Pour de plus amples détails, consultez la documentation de votre fournisseur Java et celle de Bouncy Castle.

      • Générer une nouvelle clé de chiffrement serveur et la définir en tant que clé de chiffrement serveur actuelle. Sélectionnez cette option pour générer une nouvelle clé de chiffrement de serveur. Toute donnée chiffrée générée après cette sélection sera chiffrée avec cette clé. La génération d'une nouvelle clé de chiffrement du serveur est sans effet sur la clé appliquée aux données chiffrées existantes.

      • Générez un nouveau mot de passe PBE aléatoire sécurisé. Sélectionnez cette option pour générer un nouveau mot de passe, basé sur un secret spécifique au serveur, à chaque fois que le serveur est démarré. Si vous ne sélectionnez pas cette option ou si votre serveur n'est pas configuré pour utiliser le chiffrement basé sur des mots de passe, Identity Manager utilisera la clé par défaut pour chiffrer les clés du serveur.

    • Gérer le chiffrement des objets. Choisissez cette option pour indiquer les types d'objets qui doivent être rechiffrés et la méthode de chiffrement à utiliser.

      • Chiffrement des types d’objets. Choisissez l'un des types de chiffrement affichés, au choix Triple DES (valeur par défaut), Clé de 256 bits AES, Clé de 192 bits AES ou Clé de 128 bits AES.

        Remarque –

        Pour AES avec des clés de 192 ou 256 bits, vous devez télécharger et configurer les « Unlimited Strength Jurisdiction Policy Files » pour la JVM exécutant Identity Manager. Pour de plus amples détails, consultez la documentation de votre fournisseur Java.

        Seuls les types de chiffrement instantiables sur votre système s'afficheront sur cette page. Par exemple, si votre système ne prend pas en charge les clés AES de 192 ou 256 bits utilisant les « Unlimited Strength Jurisdiction Policy Files », seules les options Triple DES et Clé de 128 bits AES sont affichées.

      • Sélectionnez les types d’objets à rechiffrer à l’aide de la clé de chiffrement serveur actuelle. Choisissez un ou plusieurs des types d'objets Identity Manager listés dans le tableau.

    • Gérer les clés de passerelle. Choisissez cette option pour spécifier le chiffrement de la passerelle.

      Les options suivantes s'affichent :

      • Sélectionner l'option de clé de passerelle. Choisissez l'une des options suivantes :

        • Générer une nouvelle clé et synchroniser toutes les passerelles. Choisissez cette option quand vous commencez à activer un environnement de passerelle sécurisé. Une nouvelle clé de passerelle est créée et communiquée à toutes les passerelles.

        • Synchroniser toutes les passerelles avec la clé de passerelle en cours. Sélectionnez cette option pour synchroniser toute nouvelle passerelle ou les passerelles qui n'ont pas communiqué la nouvelle clé de passerelle. Utilisez cette option si une passerelle ne fonctionnait pas lors de la synchronisation de toutes les passerelles avec la clé actuelle ou pour imposer une mise à jour de clé pour une nouvelle passerelle.

      • Type de clé de passerelle. Choisissez l'un des types de chiffrement affichés, qui peuvent être Triple DES, Clé de 256 bits AES, Clé de 192 bits AES ou Clé de 128 bits AES.

        Remarque –

        Pour AES avec des clés de 192 ou 256 bits, vous devez télécharger et configurer les « Unlimited Strength Jurisdiction Policy Files » pour la JVM exécutant Identity Manager. Pour de plus amples détails, consultez la documentation de votre fournisseur Java.

        Seuls les types de chiffrement instantiables sur votre système s'afficheront sur cette page. Par exemple, si votre système ne prend pas en charge les clés AES de 192 ou 256 bits en utilisant les « Unlimited Strength Jurisdiction Policy Files », seules les options Triple DES et Clé de 128 bits AES sont affichées.

    • Exporter les clés de chiffrement serveur pour sauvegarde. Choisissez cette option pour exporter les clés de chiffrement de serveur existantes dans un fichier formaté XML. Lorsque vous sélectionnez cette option, Identity Manager affiche un champ supplémentaire permettant de spécifier un chemin et un nom de fichier afin d'exporter les clés.

      Remarque –

      Sélectionnez cette option si vous utilisez le chiffrement PKCS#5 et choisissez de générer et définir une nouvelle clé de chiffrement de serveur. Il est également recommandé de stocker les clés exportées sur un support amovible qui sera conservé dans un endroit sécurisé (et non sur un réseau).

  3. Choisissez le Mode d’exécution.

    Vous pouvez exécuter cette tâche au premier ou en arrière-plan (paramètre par défaut).

    Remarque –

    Si vous choisissez de rechiffrer un ou plusieurs types d’objets avec une nouvelle clé, l’exécution de cette tâche peut être longue et il est préférable qu’elle s’exécute en arrière-plan.

  4. Lorsque vous avez terminé de configurer les options de cette page, cliquez sur Lancer.

Utilisation des types d'autorisations pour sécuriser les objets

En règle générale, vous utiliserez les permissions spécifiées dans une capacité AdminGroup pour accorder l'accès à un objectType Identity Manager tel qu'une configuration, une règle ou une TaskDefinition. Cependant, accorder l'accès à tous les objets d'un objectType Identity Manager au sein d'une ou plusieurs organisations contrôlées est parfois trop étendu.

L'utilisation de types d'autorisations (AuthType) permet de mieux définir ou restreindre l'accès à un sous-ensemble d'objets pour un objectType Identity Manager donné. Vous pouvez, par exemple, ne pas vouloir accorder aux utilisateurs l'accès à toutes les règles rentrant dans leur étendue de contrôle lors du remplissage des règles pour la sélection dans un formulaire utilisateur.

Pour définir un nouveau type d'autorisation, éditez l'objet Configuration AuthorizationTypes dans le référentiel d'Identity Manager et ajoutez un nouvel élément <AuthType>.

Cet élément requiert les deux propriétés suivantes :

Par exemple, pour ajouter un nouveau type d'autorisations Règle appelé Marketing Rule, qui étend Rule, vous devez définir ce qui suit :

<AuthType name=’Marketing Rule’ extends=’Rule’/>

Ensuite, pour activer le type d'autorisations à utiliser, vous devez le référencer dans deux endroits :

Voici des exemples de ces deux références. Dans le premier, une définition de capacité AdminGroup accorde l'accès à Marketing Rules.

Exemple 12–4 Définition de capacité AdminGroup 


<AdminGroup name=’Marketing Admin’>
  <Permissions>
    <Permission type=’Marketing Rule’ rights=’View,List,Connect,Disconnect/>
  </Permissions>
  <AdminGroups>
    <ObjectRef type=’AdminGroup’ id=’#ID#Account Administrator’/>
  </AdminGroups>
</AdminGroup>

Dans l'exemple suivant, une définition Rule permet aux utilisateurs d'accéder à l'objet puisqu'ils se sont vus octroyer l'accès à Rule ou Marketing Rule.

Exemple 12–5 Définition de Rule 


<Rule name=’Competitive Analysis Info’ authType=’Marketing Rule’>
 ...
</Rule>
Remarque –

Tous les utilisateurs auxquels des droits d'accès à un type d'autorisations ou à un type statique étendu par un type d'autorisations, ont été accordés, auront les mêmes droits sur les types d'autorisations enfants. Ainsi, en utilisant l'exemple précédent, tout utilisateur auquel des droits d'accès à Rule auront été accordé bénéficiera des mêmes droits d'accès pour Marketing Rule. L'inverse toutefois n'est pas vrai.

Pratiques de sécurité

En tant qu'administrateur Identity Manager, vous pouvez réduire encore les risques de sécurité pour vos comptes et données protégés en suivant les recommandations ci-après, lors de l'installation et par la suite.

Lors de l'installation

Pour réduire les risques de sécurité pendant l'installation :

Pendant l'utilisation

Pour diminuer les risques de sécurité pendant l'utilisation :

Si votre serveur d'application est conforme Servlet 2.2, le processus d'installation d'Identity Manager définit le délai d'attente des sessions HTTP sur une valeur par défaut de 30 minutes. Vous pouvez changer cette valeur en éditant la propriété. Il convient d'ailleurs de la définir sur une valeur inférieure pour renforcer la sécurité. Ne la définissez pas sur une valeur supérieure à 30 minutes.

ProcedurePour changer la valeur de délai d'attente des sessions

  1. Éditez le fichier web.xml, qui se trouve dans le répertoire idm/WEB-INF de la structure de répertoires de votre serveur d'application.

  2. Changez la valeur numérique dans les lignes suivantes :


    <session-config>  <session-timeout>30</session-timeout></session-config>