• Accueil
  • Blog
  • PKI Considérations relatives à la conception de la fédération d'identité

PKI Considérations relatives à la conception de la fédération d'identité

Dans ce blog, nous allons explorer la possibilité de faire passer les entreprises au niveau supérieur en intégrant deux technologies de sécurité, PKI et Identity Federation.

Modèle d'entreprise : Partenariat mondial avec des entreprises locales indépendantes.

Exigence : Exploiter les technologies de l'information pour fournir un environnement professionnel sécurisé permettant de soutenir les ressources, la collaboration et le partage.

Objectif : Identifier et établir un espace de noms unique pour chaque entreprise locale du territoire, tout en établissant des relations de confiance entre ces espaces de noms disjoints afin de partager les ressources au-delà des frontières du territoire et de la sécurité.

Solution : Infrastructure à clé publique (PKI) avec identité fédérée.

Vue recommandée PKI :

Système de gestion des certificats (CMS)

Délivrance et gestion transparentes des certificats sur l'ensemble des appareils et des services

https://www.css-security.com/cms

Géré PKI

Une solution numérique et sécurisée puissante pour un coût inférieur à ce que vous auriez pu imaginer.

https://www.css-security.com/managedpki

Vue de l'infrastructure de la fédération d'identité recommandée :

L'approche de l'architecture, de la conception et de la mise en œuvre de la solution est décrite ci-dessous :

  • Construire une autorité de certification racine de confiance mondiale avec une hiérarchie d'autorités de certification à plusieurs niveaux pour prendre en charge l'infrastructure PKI à l'échelle mondiale, tout en mettant en œuvre des contraintes d'espace de noms de subordination pour restreindre la délivrance de certificats par les autorités de certification subordonnées au territoire dans le cadre de leur propre administration et gestion PKI à l'échelle locale.
  • Faciliter le mécanisme de liaison de bout en bout des espaces de noms entre le territoire, le monde et l'informatique en nuage pour permettre la fourniture/synchronisation des informations d'identité de base dans les espaces de noms liés à chaque magasin d'identité.
  • Lier le certificat à l'identifiant unique associé à l'espace de noms, et permettre la correspondance du certificat avec l'identité.
  • Mettre en œuvre des politiques d'émission de certificats (telles que le niveau d'assurance élevé ...) et des politiques d'utilisation des applications/clés (telles que la non-répudiation, la connexion par carte à puce ...) dans le contenu du certificat, la partie se fiant au certificat peut l'exploiter à des fins d'authentification/autorisation/contrôle d'accès sans avoir à réinventer la roue.
  • Tout aussi important, le STS (Security Token Service) peut traduire ces paramètres de politique du certificat en réclamations sous la forme d'un jeton de sécurité, délivré à la partie se fiant au certificat, qui peut également faire de même à des fins de contrôle d'accès. Les paramètres d'application des politiques de certification sont appliqués de bout en bout pendant toute la durée de vie du certificat.
  • Appliquer l'utilisation des clés uniquement à leur finalité. Par exemple, la non-répudiation est une utilisation très spécifique de la clé qui ne doit pas être surchargée. Elle implique au moins que la clé privée ne soit jamais exportée d'un endroit sûr, tel qu'une carte à puce, un TPM/une carte à puce virtuelle, un HSM, etc.
  • En raison de la nature de l'espace de noms disjoints entre les espaces globaux et les territoires, la plupart des clients Windows apparaissent comme des périphériques non joints à un domaine lorsqu'ils accèdent à des ressources globales ou étrangères. Windows 2012 R2, Windows 8.1 et les versions ultérieures prennent en charge l'inscription de certificats non joints à un domaine et le renouvellement basé sur une clé via CES/CEP.

keycomp-1