Meilleures pratiques

Le nombre total de règles autorisées sur un compte est limité. Vous pouvez utiliser quelques stratégies pour éviter d'atteindre la limite et pour réduire le temps passé à gérer les accès pour les identités dans votre compte (utilisateurs, ID de service ou profils sécurisés) :

• Utilisez le principe du moindre privilège et affectez uniquement l'accès qui est nécessaire. Ainsi, vous garantissez que les identités dans votre compte ne peuvent effectuer que les actions que vous autorisez. Par exemple, plutôt que le propriétaire du compte partageant ses données d'identification, qui, par défaut, leur donne un accès d'Administrateur et de Gestionnaire sur toutes les ressources de leur compte, créez de nouvelles règles pour les utilisateurs qui ont besoin d'accéder au compte et à chaque instance de service (et ses clés associées).
• Ajoutez des ressources à un groupe de ressources pour réduire davantage le nombre de règles requises. Par exemple, une équipe peut travailler sur un projet qui utilise des ressources spécifiques dans votre compte. Ajoutez les membres de l'équipe à un groupe d'accès ou un profil sécurisé avec une règle qui n'octroie l'accès qu'aux ressources d'un groupe de ressources spécifique. Ainsi, il n'est pas nécessaire d'affecter une règle à chaque ressource pour chaque membre d'équipe. Pour plus d'informations sur l'affectation d'un accès à granularité fine, voir assign fine-grained access to a single key.
• Utilisez des groupes d'accès afin de simplifier la gestion des accès pour les identités qui nécessitent le même niveau d'accès. Vous pouvez configurer un groupe d'accès pour lequel une règle spécifique est définie, puis ajouter ces identités au groupe. Si les membres du groupe nécessitent un accès supplémentaire ultérieurement, il suffit de définir une nouvelle règle pour le groupe d'accès.
• Utilisez des étiquettes de gestion des accès pour contrôler l'accès aux ressources dans votre compte en fonction des besoins. En affectant l'accès uniquement aux ressources auxquelles sont associées des étiquettes spécifiques, vous évitez de nombreuses mises à jour de vos règles définies. Pour plus d'informations, voir Contrôle de l'accès aux ressources à l'aide d'étiquettes.
• Utilisez des profils sécurisés pour octroyer automatiquement aux utilisateurs fédérés et ressources de calcul l'accès à votre compte. Ainsi, les utilisateurs fédérés peuvent être mappés à un ou plusieurs profils sécurisés lors de la connexion en évaluant les attributs basés sur SAML pour déterminer les profils auxquels ils peuvent s'appliquer. L'utilisation de profils sécurisés pour les ressources de calcul permet d'éviter le stockage des données d'identification pour exécuter des applications, ainsi que la gestion et la rotation des données d'identification. Vous pouvez également ajouter des profils sécurisés aux groupes d'accès afin de tirer parti de l'ensemble de règles que vous avez déjà créées.
• Audit régulier qui peut gérer le contrôle d'accès et supprimer les ressources clés. Les erreurs et l'utilisation abusive par des utilisateurs disposant de droits élevés pouvant endommager votre compte, vos instances de service et les données protégées par des clés dans votre instance de service, vérifiez que l'accès approprié est maintenu en auditant les utilisateurs disposant de ces rôles. N'oubliez pas que toutes les nouvelles clés, les nouveaux fichiers de clés ou instances de service créés sont soumis par défaut aux définitions de rôle existantes. Si une nouvelle clé ne doit pas être accessible ou modifiée par un nouvel utilisateur affecté en tant que Gestionnaire de l'instance, cette restriction doit être spécifiquement affectée, car les gestionnaires d'instance ont accès à toutes les clés d'une instance par défaut, et peuvent notamment supprimer une clé.

Qu'est-ce qu'une bonne stratégie de groupe d'accès ?

Un groupe d'accès est une organisation d'utilisateurs, d'ID de service et de profils sécurisés dans un groupe auquel vous pouvez accorder le même accès IAM. Toutes les identités d'un groupe d'accès héritent du même accès.

Vous pouvez logiquement affecter un accès à vos groupes de ressources et aux ressources incluses en créant un groupe d'accès par niveau d'accès requis. Ensuite, vous pouvez mapper chaque groupe d'accès aux groupes de ressources précédemment créés. Par exemple, pour contrôler l'accès au projet CustApp, vous pouvez créer les groupes d'accès suivants :

• Auditor-Group
• Developer-Group
• Admin-Group

Pour Auditor-Group, affectez deux règles d'accès qui octroient les droits d'accès Afficheur aux ressources et aux groupes de ressources CustApp-Test et CustApp-Prod. Pour Developer-Group, affectez deux règles d'accès qui octroient les droits d'accès Editeur aux ressources et aux groupes de ressources CustApp-Dev et CustApp-Test. Pour Admin-Group, affectez trois règles d'accès qui octroient les droits d'accès Administrateur aux ressources et aux groupes de ressources CustApp.

Vous pouvez accorder les droits d'accès Administrateur sur tout ce que contient un compte en créant un groupe d'accès et en lui affectant deux règles. Pour créer la première règle, sélectionnez Tous les services activés pour l'identité et l'accès dans Compte avec le rôle de plateforme administrateur et le rôle de service de gestionnaire. Pour créer la deuxième règle, sélectionnez Tous les services de gestion de compte avec le rôle Administrateur affecté.

Rôles de plateforme

• Administrateur : Possède tous les droits sur un objet particulier et ses objets "enfant" (par exemple, les clés sont des objets enfant d'instances), y compris le droit d'inviter de nouveaux utilisateurs et d'affecter des rôles sur l'objet (seuls les administrateurs peuvent affecter des rôles). Notez que les administrateurs ne disposent pas de rôles de service par défaut. Ils peuvent toutefois s'affecter des rôles.
• Éditeur : Peut afficher, créer et supprimer des instances au niveau du compte, mais ne peut pas inviter de nouveaux utilisateurs. A une utilisation limitée pour les objets au sein d'une instance de service, tels que les clés, au-delà de la possibilité de les afficher.
• Opérateur : Peut afficher des instances au niveau du compte, mais ne peut pas les modifier. A une utilisation limitée pour les objets au sein d'une instance de service, tels que les clés, au-delà de la possibilité de les afficher.
• Afficheur : peut afficher des instances au niveau du compte, mais ne peut pas les modifier. A une utilisation limitée pour les objets au sein d'une instance de service, tels que les clés, au-delà de la possibilité de les afficher.

Les rôles de plateforme doivent être affectés sur un compte entier, sur des instances de service particulières ou au sein d'objets à l'intérieur d'une instance de service.

Énumère les rôles de gestion de la plateforme tels qu'ils s'appliquent à Key Protect

Action	Afficheur	Editeur	Opérateur	Administrateur
Afficher les instances Key Protect
Créer des instances d'Key Protect
Supprimer des instances d'Key Protect
Inviter de nouveaux utilisateurs et gérer les règles d'accès

Alors qu'un rôle au niveau du compte donne à un utilisateur des droits particuliers sur les instances de service par défaut, des rôles peuvent également être affectés sur une instance de service particulière. Par exemple, un compte Éditeur (qui peut afficher, créer et supprimer des instances, mais pas affecter des rôles) peut être désigné un Administrateur d'une instance de service particulière, avec la possibilité d'affecter des rôles dans cette instance de service.

Les rôles de service peuvent être appliqués aux trois objets de première classe d'une instance de service : l'instance dans son ensemble, des clés particulières et des fichiers de clés. Tout comme les rôles de compte disposent de droits sur les instances par défaut, les gestionnaires d'instances ont par défaut des droits sur les clés et les fichiers de clés. Toutefois, ces droits peuvent être affectés avec une plus grande granularité si nécessaire, par exemple en donnant à un utilisateur le rôle Gestionnaire sur une clé ou un fichier de clés particulier et un niveau d'autorisation moindre sur l'instance dans son ensemble.

Les rôles de service peuvent être affectés par instance ou pour toutes les instances d'un compte.

Rôles des instances de service

Notez que les droits inclus dans les rôles sont additifs. Un Gestionnaire, par exemple, dispose de tous les droits d'accès qu'un Lecteur, plus d'autres droits. L'exception est le rôle KeyPurge, qui inclut l'action kms.secrets.purge qui ne fait pas partie d'un autre rôle et doit donc être définie explicitement.

• Gestionnaire : Possède tous les droits sur un objet particulier (par exemple, le gestionnaire d'une clé peut encapsuler, désencapsuler et supprimer la clé, et détient le droit exclusif de lire et mettre à jour des règles Key Protect telles que dualAuthDelete, allowedNetwork, allowedIP, entre autres).
• **Auteur **: Possède la plupart des droits du gestionnaire concernant l'utilisation d'un objet (y compris la possibilité d'extraire une clé et ses métadonnées), mais il ne peut généralement pas supprimer ou désactiver l'objet.
• Lecteur : Peut utiliser l'objet (par exemple, les lecteurs de clés peuvent encapsuler et désencapsuler une clé), mais ne peut pas créer, supprimer ou modifier l'objet.
• ReaderPlus : Possède les mêmes droits que le lecteur, avec la capacité supplémentaire de récupérer le contenu d'une clé standard.
• KeyPurge : Peut purge des clés au bout de quatre heures.
• KmipAdapterManager: Possède tous les droits nécessaires pour gérer l'accès aux ressources régies par le protocole KMIP

Le tableau suivant montre le lien entre rôles d'accès au service et autorisations dans Key Protect.

Répertorie les rôles d'accès au service applicables aux principales ressources d' Key Protect

Action	Lecteur	ReaderPlus	Auteur	Responsable	KeyPurge	KmipAdapterManager
Créer une clé
Importer une clé
Extraire une clé
Extraire des métadonnées de clé
Extraire le total d'une clé
Répertorier les clés
Répertorier des versions de clé
Encapsuler une clé
Désencapsuler une clé
Réencapsuler une clé
Effectuer la rotation d'une clé
Désactiver une clé
Activer une clé
Planifier la suppression d'une clé
Annuler la suppression d'une clé
Supprimer une clé
Restaurer une clé
Correctif d'une clé
Clés de synchronisation
Purger les clés après quatre heures

Répertorie les rôles d'accès au service applicables aux ressources du trousseau « Key Protect »

Action	Lecteur	ReaderPlus	Auteur	Responsable	KeyPurge	KmipAdapterManager
Créer un fichier de clés
Répertorier des fichiers de clés
Supprimer un fichier de clés

Répertorie les rôles d'accès au service tels qu'ils s'appliquent aux ressources de stratégie d' Key Protect

Action	Lecteur	ReaderPlus	Auteur	Responsable	KeyPurge	KmipAdapterManager
Définir des règles de clé
Répertorier les règles de clé
Définir des règles d'instance
Répertorier les règles d'instance

Répertorie les rôles d'accès au service applicables aux ressources de jetons d'importation

Action	Lecteur	ReaderPlus	Auteur	Responsable	KeyPurge	KmipAdapterManager
Créer un jeton d'importation
Extraire un jeton d'importation

Répertorie les rôles d'accès au service applicables aux ressources d'enregistrement d' Key Protect

Action	Lecteur	ReaderPlus	Auteur	Responsable	KeyPurge	KmipAdapterManager
Création d'un enregistrement[^services-1]
Répertorier les enregistrements d'une clé
Répertorier les enregistrements de toute clé
Mise à jour d'un enregistrement[^services-2]
Remplacer un enregistrement[^services-3]
Supprimer un enregistrement[^services-4]

Le rôle KeyPurge confère uniquement la possibilité de purger les clés et doit être considéré comme un complément d'autres rôles d'accès au service, tels que Gestionnaire.

Répertorie les rôles d'accès au service applicables aux principales ressources d' Key Protect

Action	Lecteur	ReaderPlus	Auteur	Responsable	KeyPurge	KmipAdapterManager
Liste des adaptateurs KMIP
Créer un adaptateur KMIP
Récupérer un adaptateur KMIP
Supprimer un adaptateur KMIP
Liste des objets KMIP d'un adaptateur KMIP
Récupérer un objet KMIP à partir d'un adaptateur KMIP
Supprimer un objet KMIP d'un adaptateur KMIP
Liste des certificats clients d'un adaptateur KMIP
Ajouter un certificat client à un adaptateur KMIP
Récupérer un certificat client d'un adaptateur KMIP
Supprimer un certificat client d'un adaptateur KMIP

Les rôles Rédacteur, Lecteur et ReaderPlus n'ont pas accès au protocole KMIP.

Rôles et règles Cloud Identity and Access Management

Bien que la console Key Protect permette aux utilisateurs un contrôle d'accès à granularité fine à l'aide de ces rôles, il peut être utile de se rappeler que ces rôles sont associés à des règles Cloud Identity and Access Management :

• nom de service (pour Key Protect, toujours kms)
• ID d'instance de service
• ID de fichier de clés
• type de ressource (seul key est pris en charge)
• ID ressource
• ID de compte (doit toujours être indiqué dans la règle)

Voici un exemple de règle renvoyée par l'API IAM :

"resources": [
    {
        "attributes": [
            {
                "name": "accountId",
                "value": "$ACCOUNT_ID",
            },
            {
                "name": "serviceName",
                "value": "kms",
            },
            {
                "name": "resourceType",
                "value": "key",
            },
            {
                "name": "resource",
                "value": "$KEY_ID",
            },
            {
                "name": "keyRing",
                "value": "$KEY_RING_ID",
            }
        ]
    }
]

Toute combinaison de ces attributs peut être appliquée dans une règle. Si cette règle est associée au rôle d'administrateur, cela signifie que tout user/service id/access group auquel cette règle s'applique peut créer une règle qui s'applique à une sous-ressource de celle concernée. En d'autres termes, tous les utilisateurs sous-administrateurs ne peuvent avoir qu'un accès égal (exactement les mêmes attributs que ceux indiqués sur leur règle) ou inférieur (exactement les mêmes attributs que ceux indiqués sur leur règle plus les attributs supplémentaires indiqués) à celui de l'administrateur parent.