Remarque :

Configurer un modèle d'administrateur initial pour votre location Oracle Cloud

Introduction

La sécurité du cloud exige un modèle de responsabilité partagée. En tant que fournisseur cloud, Oracle est responsable de la fourniture de services de plate-forme et d'infrastructure sécurisés. En tant que propriétaire de la location, vous êtes responsable de la gestion et du contrôle de l'accès aux ressources que vous créez dans la location. Lorsque vous créez une location Oracle Cloud Infrastructure (OCI) pour la première fois, un compte utilisateur unique est membre du groupe d'administrateurs de la location, qui accorde un accès complet à l'ensemble de la location et à toutes les ressources qu'elle contient.

Lorsque vous commencez à ajouter d'autres administrateurs, à affecter des autorisations, à créer des ressources et à alimenter des données, il est important de penser à votre modèle de sécurité dès le début du processus afin de ne pas avoir à comprendre comment nettoyer les problèmes.

Le modèle de sécurité décrit dans ce tutoriel représente une conception générale et doit être adapté pour s'aligner sur les stratégies de sécurité et les approches de gestion de location spécifiques de votre organisation. Le modèle de stratégie Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) est extrêmement flexible et peut être facilement adapté ou modifié pour s'adapter à différentes conceptions.

Objectifs

Prérequis

Tâche 1 : configuration des paramètres de location initiaux

Afin de simplifier la création d'un modèle de référence pour l'accès à la location et de créer des rôles de haut niveau pour l'utilisation des ressources de niveau location dans OCI, les habilitations initiales peuvent être scriptées à l'aide de l'interface de ligne de commande OCI et exécutées à partir de Cloud Shell.

Un script de modèle qui crée des groupes et des instructions de stratégie pour l'ensemble de fonctionnalités d'accès de base suivant, ainsi qu'un niveau d'accès de référence pour tous les administrateurs OCI est fourni ci-dessous.

L'objectif de ces stratégies est de créer un ensemble initial de droits applicables à la plupart des clients. Des informations plus détaillées sur ces fonctionnalités d'accès spécifiques et les stratégies supplémentaires potentielles sont décrites dans les sections suivantes.

Ces groupes doivent être utilisés conjointement avec les rôles qui existent déjà dans les domaines d'identité OCI IAM, y compris les administrateurs de sécurité qui configurent les mécanismes d'authentification de l'environnement, ainsi que les administrateurs des utilisateurs pour la gestion de l'intégration et de l'affectation des utilisateurs. Les administrateurs d'utilisateurs ne sont peut-être pas requis dans les déploiements pour lesquels les utilisateurs sont gérés dans une solution de gestion des identités externe.

Si vous n'êtes pas familiarisé avec la syntaxe de stratégie OCI IAM, consultez la documentation OCI IAM pour comprendre la structure des instructions de stratégie.

Script d'accès de référence

Remarque : ce script s'applique uniquement aux environnements OCI avec des domaines IAM. Certaines locations plus anciennes peuvent ne pas avoir de domaines IAM dans leur environnement. Pour vérifier si votre environnement dispose de domaines IAM, suivez les instructions ici.

#!/bin/bash

#Update the below with details for the environment
tenancy_ocid=ocid1.tenancy.oc1..aaaaaaaa....

#Group names
tenancy_manager_group=TenancyManagers
pol_admin_group=PolicyAdmins
sec_admin_group=SecurityAdmin
sec_analyst_group=SecurityAnalysts

#All_Users_Policy
oci iam policy create -c $tenancy_ocid --name "All_Users_Policy" \
--description "General purpose permissions intended for all users of the tenancy." \
--statements "[\"allow any-user to inspect tag-defaults in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to inspect limits in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to inspect tenancies in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to inspect compartments in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to read policies in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to read objectstorage-namespaces in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to read announcements in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to use cloud-shell in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\"]"

#Tenancy Managers
oci iam group create --name $tenancy_manager_group \
--description "Group for Tenancy Managers for OCI, who can manage tenancy-level constructs, such as budgets and regions."

oci iam policy create -c $tenancy_ocid --name "Tenancy_Managers_Policy" \
  --description "Policy statements which define the 'Tenancy Manager' role, which allows for managing tenancy-level configuration and objects." \
  --statements "[\"define tenancy usage-report as ocid1.tenancy.oc1..aaaaaaaaned4fkpkisbwjlr56u7cj63lf3wffbilvqknstgtvzub7vhqkggq\", \
                \"allow group ${tenancy_manager_group} to read usage-report in tenancy\", \
                \"allow group ${tenancy_manager_group} to read resource-availability in tenancy\", \
                \"allow group ${tenancy_manager_group} to manage quotas in tenancy\", \
                \"allow group ${tenancy_manager_group} to manage tenancies in tenancy\", \
                \"allow group ${tenancy_manager_group} to manage objectstorage-namespaces in tenancy\", \
                \"allow group ${tenancy_manager_group} to manage buckets in tenancy where request.operation = 'UpdateNamespaceMetadata'\", \
                \"allow group ${tenancy_manager_group} to manage usage-budgets in tenancy\", \
                \"allow group ${tenancy_manager_group} to manage organizations-family in tenancy\", \
                \"allow group ${tenancy_manager_group} to {AUDIT_CONFIGURATION} in tenancy\", \
                \"endorse group ${tenancy_manager_group} to read objects in tenancy usage-report\"]"

#Policy Admins
oci iam group create --name $pol_admin_group \
--description "Group for Policy Administrators for OCI, who create and maintain IAM Policies and supporting resources."

oci iam policy create -c $tenancy_ocid --name "Policy_Admins_Policy" \
--description "Policy statements which define the 'Policy Admin' role, who create and maintain IAM Policies and supporting resources." \
--statements "[\"allow group ${pol_admin_group} to inspect groups in tenancy\", \
              \"allow group ${pol_admin_group} to read users in tenancy\", \
              \"allow group ${pol_admin_group} to manage groups in tenancy where target.group.name != 'Administrators'\", \
              \"allow group ${pol_admin_group} to manage compartments in tenancy\", \
              \"allow group ${pol_admin_group} to manage dynamic-groups in tenancy\", \
              \"allow group ${pol_admin_group} to manage domains in tenancy where request.permission != 'DOMAIN_RESOURCES_ADMINISTER'\", \
              \"allow group ${pol_admin_group} to manage network-sources in tenancy\", \
              \"allow group ${pol_admin_group} to manage policies in tenancy\", \
              \"allow group ${pol_admin_group} to manage tag-namespaces in tenancy\", \
              \"allow group ${pol_admin_group} to manage iamworkrequests in tenancy\"]"

#Security Admin
oci iam group create --name $sec_admin_group \
--description "Group for Security Admins for OCI, who can manage Cloud Guard and Data Safe"

oci iam policy create -c $tenancy_ocid --name "Security_Admins_Policy" \
  --description "Policy statements which define the 'Security Admin' role, which allows for managing Cloud Guard and Data Safe." \
  --statements "[\"allow group ${sec_admin_group} to inspect groups in tenancy\", \
                \"allow group ${sec_admin_group} to read repos in tenancy\", \
                \"allow group ${sec_admin_group} to manage cloud-guard-family in tenancy\", \
                \"allow group ${sec_admin_group} to manage data-safe in tenancy\"]"

#Security Analyst
oci iam group create --name $sec_analyst_group \
--description "Group for Security Analysts for OCI, which provides read access to resources in the tenancy, and the ability to use Cloud Guard"

oci iam policy create -c $tenancy_ocid --name "Security_Analysts_Policy" \
  --description "Policy statements which define the 'Security Analyst' role, which allows for read access to the tenancy, and the ability to work with Cloud Guard." \
  --statements "[\"allow group ${sec_analyst_group} to read all-resources in tenancy\", \
                \"allow group ${sec_analyst_group} to read audit-events in tenancy\", \
                \"allow group ${sec_analyst_group} to read cloud-guard-family in tenancy\", \
                \"allow group ${sec_analyst_group} to use cloud-guard-config in tenancy\", \
                \"allow group ${sec_analyst_group} to manage cloud-guard-detectors in tenancy\", \
                \"allow group ${sec_analyst_group} to manage cloud-guard-problems in tenancy\", \
                \"allow group ${sec_analyst_group} to manage cloud-guard-detector-recipes in tenancy\", \
                \"allow group ${sec_analyst_group} to manage cloud-guard-managed-lists in tenancy\", \
                \"allow group ${sec_analyst_group} to manage cloud-guard-user-preferences in tenancy\"]"

Tâche 2 : mettre à jour le script

  1. Copiez le script dans un éditeur de texte pour effectuer les ajustements nécessaires avant de l'exécuter dans votre environnement.

  2. Mettez à jour la variable tenancy_ocid avec la valeur correcte pour votre location. L'OCID de location peut être obtenu à partir de la page Détails de location, disponible sur https://cloud.oracle.com/tenancy, ou en cliquant sur le nom de location dans le tableau de bord de la console OCI.

    Image de l'écran de présentation de la location, avec l'élément OCID mis en évidence

  3. Mettez à jour les noms de groupe si nécessaire. Les noms de groupe peuvent avoir besoin de s'aligner sur un schéma de dénomination, en particulier s'il est prévu de les alimenter à partir d'un système de gestion des identités externe.

  4. Vérifiez et mettez à jour les instructions de stratégie pour les aligner sur les exigences de votre organisation. Les modifications apportées à ces instructions de stratégie et les instructions de stratégie supplémentaires sont décrites dans les sections suivantes.

Comprendre le modèle d'autorisation

A un niveau élevé, la conception des droits implémentée par ce script divise les responsabilités de gestion de location en rôles plus restreints qui reflètent mieux les différents types d'administrateur qui peuvent exister dans votre environnement. Elle vise également à empêcher les utilisateurs opérant au niveau de la location de créer des ressources d'infrastructure en dehors des compartiments OCI dédiés.

La création des ressources dans les compartiments améliore la gouvernance de location, car les budgets et les quotas de ressource peuvent être configurés au niveau du compartiment. Il simplifie également le modèle de stratégie de gestion de ces ressources, car les compartiments peuvent être directement référencés dans ces stratégies.

Ce script est destiné à être conservateur, n'accordant qu'un ensemble minimal d'autorisations à chaque groupe. Selon la façon dont votre organisation compte utiliser OCI, des droits d'accès supplémentaires peuvent être requis. Les sections suivantes décrivent plus en détail les habilitations créées par le script et incluent des exemples de modifications potentielles.

Accès de référence via des stratégies "tous utilisateurs"

Dans OCI, les utilisateurs n'ont aucun accès, sauf si une stratégie a été configurée pour fournir cet accès. Pour faciliter la productivité des utilisateurs et fournir aux utilisateurs des informations pertinentes sur la location, le script crée un ensemble d'accès de référence pour tous les utilisateurs. Ces stratégies autorisent l'utilisation de cloud shell, ainsi que la lecture des annonces et la vérification des régions abonnées.

Les stratégies recommandées sont également conçues pour aider les utilisateurs à effectuer des demandes informées lorsqu'ils ont besoin d'un accès ou de ressources supplémentaires, en leur permettant de visualiser des objets qui peuvent limiter leur capacité à interagir avec la location, y compris les limites de service et les stratégies.

En général, il est recommandé d'utiliser le domaine d'identité OCI IAM par défaut pour la gestion des ressources OCI et d'interdire l'accès à la console OCI pour les utilisateurs qui s'authentifient via d'autres domaines d'identité. Ainsi, le script fourni limite l'accès aux utilisateurs qui s'authentifient via le domaine par défaut. Votre conception de sécurité peut prendre en charge l'utilisation de plusieurs domaines d'identité pour la gestion de l'accès OCI. Par exemple, vous pouvez disposer d'un domaine de production pour les administrateurs de production et d'un domaine hors production pour les administrateurs hors production. Dans ce cas, la condition des stratégies d'accès de référence peut être modifiée pour capturer chaque domaine, comme suit :

... where all{ request.domain.name in ('<prod_domain_name>, '<non-prod_domain_name>'), request.principal.type = 'user' }

Selon la conception de votre location, vous pouvez ajouter la stratégie suivante.

allow any-user to use tag-namespaces in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }

Cette stratégie permet à tous les utilisateurs d'appliquer, de mettre à jour ou d'enlever des balises définies pour les ressources qu'ils peuvent modifier. Cette opération peut être souhaitable si les propriétaires de ressources doivent pouvoir modifier des balises à des fins de suivi ou à des fins de gestion des accès. Il n'est peut-être pas souhaitable que votre conception utilise les valeurs par défaut des balises pour le suivi des coûts ou à d'autres fins.

Responsables de location

Les habilitations de gestionnaire de location sont destinées aux utilisateurs ayant une responsabilité de gouvernance pour la location, y compris la gestion des coûts et de la budgétisation, ainsi qu'aux régions auxquelles la location est abonnée.

Les stratégies créées par le script pour les gestionnaires de location peuvent nécessiter des ajustements mineurs pour permettre l'accès aux rapports d'utilisation. Le script utilise l'identificateur de location par défaut pour l'analyse des coûts, mais certaines locations peuvent utiliser un autre identificateur de location en fonction de leur statut. Si un gestionnaire de location ne parvient pas à accéder aux rapports d'utilisation, la stratégie doit être mise à jour pour utiliser les valeurs affichées dans la section des rapports d'utilisation de la console OCI, par exemple.

Image d'une page Rapports d'utilisation non autorisée, indiquant l'ID de location requis.

Administrateurs de règle

La capacité la plus importante pour faciliter l'abandon de l'utilisation du groupe Administrateurs est peut-être l'affectation des habilitations d'administration des stratégies. Ces habilitations sont utilisées par les administrateurs chargés de configurer les habilitations d'accès dans la location. Dans le modèle créé par le script fourni, les administrateurs de stratégie sont chargés de définir les habilitations, mais pas d'affecter des utilisateurs à ces groupes. Les habilitations de gestion des utilisateurs sont accordées via l'affectation du rôle Administrateurs des utilisateurs au sein du domaine IAM. Dans certains déploiements, les deux responsabilités peuvent être affectées à un seul administrateur, en fonction de la conception de la sécurité de votre organisation.

Remarque : l'habilitation d'administrateur de stratégie a une portée très limitée, mais comme elle peut être utilisée pour créer des stratégies qui accordent n'importe quel niveau d'accès dans l'environnement, y compris l'escalade de leur propre niveau d'accès, elle doit être considérée comme une habilitation hautement privilégiée.

Administrateurs de la sécurité

Le rôle d'administrateur de sécurité est destiné aux utilisateurs chargés de configurer les services de sécurité dans l'environnement, tels que Cloud Guard et Data Safe.

Vous pouvez également ajouter les instructions suivantes pour permettre aux administrateurs de sécurité de configurer l'alerte au niveau de la location :

allow group SecurityAdmins to manage cloudevents-rules in tenancy where target.compartment.id = '<tenancy_ocid>'
allow group SecurityAdmins to use metrics in tenancy

Les administrateurs de la sécurité peuvent ainsi configurer des alertes sur les événements qui se produisent au niveau de la location, y compris la connexion ou la création de problèmes Cloud Guard. Pour ces événements, une action telle qu'une notification doit être associée à ces événements afin d'être significative, mais cette action n'a pas besoin d'être dans le compartiment racine (location). Les services responsables de la gestion de ces événements peuvent plutôt se trouver dans un sous-compartiment utilisé à d'autres fins de sécurité. Par exemple, une stratégie telle que la suivante peut être ajoutée pour autoriser la configuration des notifications à des fins de sécurité :

allow group SecurityAdmins to manage ons-family in compartment security_resources

Analystes de sécurité

Le rôle Analyste de la sécurité est destiné aux utilisateurs chargés de vérifier les actions et les événements dans la location OCI. Pour examiner et valider les problèmes associés à Cloud Guard, un analyste de sécurité requiert un accès en lecture à l'ensemble de la location.

Tâche 3 : exécution du script à l'aide de Cloud Shell

Après avoir apporté les modifications requises au script, vous pouvez l'exécuter à l'aide de Cloud Shell dans la console OCI.

Remarque : Cloud Shell n'est pas requis, mais fournit un mécanisme simple d'exécution des scripts car il est préconfiguré avec l'interface de ligne de commande OCI et utilise le contexte d'authentification de l'utilisateur connecté.

  1. Ouvrez Cloud Shell à partir de l'icône Outils de développeur dans l'en-tête de la console OCI.

    Image du menu déroulant Outils de développement, avec l'option de menu "Cloud Shell" en surbrillance

    L'initialisation de Cloud Shell peut prendre un certain temps, surtout s'il s'agit du premier accès.

  2. Copiez le script mis à jour dans votre environnement Cloud Shell, par exemple à l'aide de vi :

    $vi policy_scaffold.sh

    Dans vi, appuyez sur i pour entrer en mode [INSERT], puis collez le contenu du script dans le fichier avant d'appuyer sur esc, puis sur :wq pour enregistrer et quitter.

  3. Rendez le script exécutable et exécutez-le pour créer les habilitations initiales.

    $chmod +x policy_scaffold.sh
$./policy_scaffold.sh

  4. Surveillez la sortie pour vous assurer que chaque objet de groupe et de stratégie est créé correctement. Les problèmes peuvent être résolus manuellement ou en modifiant puis en réexécutant des commandes d'interface de ligne de commande OCI individuelles à partir du script.

Tâche 4 : affecter des utilisateurs et sécuriser le groupe d'administrateurs

Une fois le script exécuté, les utilisateurs peuvent être affectés aux groupes créés, en leur accordant les habilitations associées.

Après avoir affecté quelques rôles d'administration, il est recommandé de limiter l'utilisation du groupe d'administrateurs OCI aux scénarios d'accès d'urgence. OCI nécessite l'affectation d'au moins un compte utilisateur au groupe d'administrateurs afin que vous puissiez récupérer l'accès à la location en cas de panne d'identité ou de mauvaise configuration. Dans le cas contraire, il serait possible de créer une situation dans laquelle aucun utilisateur ne peut affecter l'accès, et tous les administrateurs pourraient être bloqués de votre environnement.

Pour plus d'informations et de recommandations détaillées, reportez-vous à Gestion des comptes d'accès d'urgence dans Oracle Cloud Infrastructure.

Etapes suivantes

Après avoir créé un ensemble initial de rôles d'administration de location, ces rôles peuvent être utilisés comme base pour faciliter la création de rôles pour des projets individuels ou pour étendre les capacités de ces administrateurs principaux.

Le modèle utilisé ici comporte deux objectifs principaux. Tout d'abord, il permet aux administrateurs de l'environnement OCI d'être enlevés du groupe Administrateurs et de devenir des rôles plus étroitement adaptés à leurs responsabilités spécifiques. Deuxièmement, il empêche les utilisateurs disposant d'un accès au niveau de la location de créer des ressources d'infrastructure dans le compartiment racine. Lors de la création de stratégies supplémentaires, il est recommandé de conserver ce principe de conception et de créer uniquement des stratégies qui ciblent les compartiments sous la racine. Outre les avantages en matière de sécurité, cela permet également de simplifier le suivi des coûts et la gouvernance des projets.

Pour en savoir plus, consultez le guide de sécurité Oracle Cloud Infrastructure.

Remerciements

Ressources de formation supplémentaires

Explorez d'autres ateliers sur docs.oracle.com/learn ou accédez à davantage de contenu de formation gratuit sur le canal Oracle Learning YouTube. En outre, accédez à education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour consulter la documentation produit, consultez Oracle Help Center.