Le service Delegate Access Control permet aux clients Oracle Exadata Database Service on Cloud@Customer et Oracle Exadata Database Service on Dedicated Infrastructure de s'abonner aux services de maintenance et de support de machine virtuelle et de base de données, de déléguer l'accès aux fournisseurs de services et de contrôler le moment où ces fournisseurs de services peuvent accéder aux ressources de machine virtuelle et de base de données.

Figure 1-1 Workflow de contrôle d'accès délégué

Les opérateurs délégués sont spécifiques aux équipes de support pour les services auxquels les machines virtuelles et les bases de données sont abonnées. Les services disponibles sont les suivants :

• Support client Oracle Database Cloud
• Opération Oracle Database Cloud
• Déploiement de systèmes de production Oracle et prise en charge de l'infrastructure
• Programme clients stratégiques pour les plates-formes cloud de base de données

Grâce au contrôle d'accès délégué, les fournisseurs de support peuvent fournir des services gérés à l'aide d'outils complets et robustes basés sur la plate-forme OCI. Les clients peuvent garder le contrôle sur le moment où les délégués du fournisseur de services peuvent accéder aux ressources client dans leur location et sur les actions qui peuvent être effectuées. Les entreprises qui gèrent des ressources sur plusieurs locataires peuvent utiliser le contrôle d'accès délégué pour rationaliser les tâches de gestion.

Le contrôle d'accès délégué permet aux clients Oracle Exadata Database Service on Cloud@Customer et Oracle Exadata Database Service on Dedicated Infrastructure de :

• Exécuter un "abonnement de délégation" auprès des fournisseurs de support enregistrés, ce qui leur permet de prendre le contrôle des ressources spécifiques appartenant au client. Cela garantit une gestion efficace et efficiente par le fournisseur de support.
• Déléguer l'accès à leurs machines virtuelles Exadata (via SSH et API) à un fournisseur de support sans avoir à tenir à jour les identités de fournisseur de support dans le client IAM.
• Affichez toutes les ressources déléguées et les fournisseurs de support technique spécifiques pouvant accéder à la ressource.
• Conservez le contrôle des portées de délégation et des privilèges accordés à l'opérateur de fournisseur de support lorsqu'il accède à la ressource déléguée.
• Empêcher les opérateurs du fournisseur de support d'accéder à la ressource déléguée en dehors de la stratégie de contrôle de délégation définie par le client.
• Limitez la durée d'accès à une heure prédéfinie.
• Auditez toutes les actions effectuées par l'opérateur du fournisseur de support sur les ressources déléguées.

Le contrôle d'accès délégué permet aux agents du fournisseur de support de :

• Accédez à des systèmes délégués appartenant au client (via SSH et API) sans avoir à gérer leur identité dans l'IAM du client.
• Découvrez quelles ressources ont été déléguées au fournisseur de support par un client.

Découvrez les termes utilisés avec le contrôle d'accès délégué.

• Abonné : locataire client propriétaire de la ressource et souhaitant déléguer la gestion des aspects de la ressource à un autre locataire dans OCI.
• Fournisseur de service : locataire auquel l'accès à la ressource sera délégué afin de la gérer de manière temporaire. Il existe deux types de fournisseur de services
  1. Opérateurs de service cloud : ils peuvent accéder aux ressources déléguées pour résoudre les problèmes. Pendant les activités de maintenance, les actions effectuées sur les composants d'infrastructure peuvent parfois avoir un impact négatif sur les processus en cours d'exécution sur la machine virtuelle. Actuellement, si de tels problèmes surviennent, Oracle doit en informer le client par e-mail (ou par une autre forme de communication) via le contact de support technique, ce qui peut être un processus lent et retarder la résolution des problèmes de plus d'une journée.

     Pour accélérer ce processus, un workflow similaire à Operator Access Control peut être implémenté. Cela permettrait aux opérateurs de service cloud de soumettre des demandes d'accès pour la machine virtuelle du client. L'accès accordé via ce workflow est limité à la portée définie de la délégation et aux privilèges spécifiés, ce qui garantit que les opérateurs ne peuvent pas accéder à la base de données du client.

     Pour plus d'informations sur Operator Access Control, reportez-vous à Présentation d'Oracle Operator Access Control.

  2. Opérateurs de support Oracle : l'organisation de support Oracle possède une vaste expertise dans le dépannage des problèmes d'application de patches et de performances avec les logiciels de base de données. Beaucoup de nos clients de renom préfèrent déléguer l'accès à leurs machines virtuelles Exadata pour des exercices trimestriels d'application de patches. En outre, Oracle Platinum Support ou Advanced Customer Support (ACS) est souvent engagé à la demande pour résoudre les problèmes.
     Dans ces scénarios, les ingénieurs ACS peuvent avoir besoin d'accéder aux machines virtuelles du client pour effectuer diverses tâches :

     • Application de patches trimestrielle : les clients souhaitent souvent déléguer la responsabilité de l'application de patches à leurs machines virtuelles (système d'exploitation ou base de données, Grid Infrastructure) aux ingénieurs ACS.
     • Dépannage à la demande : en cas de problème, l'ACS peut avoir besoin d'accéder à la base de données du client avec différents niveaux de privilège :
       • Privilège faible : accès limité aux vues de performances et de dictionnaire de données nécessaires pour résoudre les problèmes liés aux performances ou d'autres problèmes de base de données.
       • Privilège modéré : accès qui inclut la possibilité d'appliquer des patches au système.

     Cet accès structuré garantit que les ingénieurs ACS peuvent résoudre efficacement les problèmes tout en respectant les limites opérationnelles et de sécurité du client.

• Abonnement aux délégations : une ressource ne peut être déléguée à un fournisseur qu'une fois que le client s'est abonné à un service publié offert par ce fournisseur. Actuellement, les fournisseurs pris en charge sont les suivants :
  • Support client Oracle Database Cloud
  • Opération Oracle Database Cloud
  • Déploiement de systèmes de production Oracle et prise en charge de l'infrastructure
  • Programme clients stratégiques pour les plates-formes cloud de base de données
• Contrôle des délégations : cette stratégie de contrôle régit la gestion de l'accès à une ressource déléguée. Il détermine si l'accès est accordé automatiquement ou nécessite un workflow d'approbation spécifique. Les contrôles de délégation doivent être associés à au moins un abonnement de délégation. La stratégie inclut l'application des types d'accès suivants à la ressource déléguée :
  • Accès à l'API Database Cloud Service
  • Accès SSH
  • Accès à l'automatisation
  • Accès à la commande à la demande au niveau de la machine virtuelle distante
• Ressource déléguée : ressource régie par le contrôle de délégation défini par le client, auquel le fournisseur peut accéder. Une ressource déléguée doit être associée à un seul contrôle de délégation.
• Demande d'accès aux ressources déléguées : un opérateur de fournisseur de services doit lancer une demande d'accès pour pouvoir accéder à une ressource déléguée. Cette demande doit être approuvée par un approbateur, ou elle peut être automatiquement approuvée en fonction de la définition du contrôle de délégation. Une demande d'accès est toujours adressée à l'abonné par le fournisseur de services.
• Approbateur de demande d'accès : un approbateur est un utilisateur de la location d'abonné autorisé à approuver une demande d'accès émise par un opérateur de fournisseur de services. Si des niveaux d'approbation supplémentaires sont requis pour la demande d'accès, ils peuvent être configurés lors de la création d'un contrôle de délégation.
• Action fournisseur de services (alias Action : ensemble prédéfini nommé de commandes, de fichiers ou d'autorisations d'accès réseau pouvant être accordées sur une ressource spécifique, tel que défini par le contrôle d'accès délégué.

Le programme Clients stratégiques pour les plates-formes cloud de base de données est un fournisseur Oracle Service conçu pour faciliter la gestion proactive des services et des opérations pour les clusters de machines virtuelles ExaDB-C@C et ExaDB-D et les bases de données.

Le processus commence par le lancement par l'équipe Oracle d'une demande d'accès à l'aide de l'action DLGT_MGMT_CMD_ACCESS pour un noeud de cluster de machines virtuelles, Grid Infrastructure et des bases de données spécifiques. Une fois que le client a approuvé la demande d'accès aux ressources déléguées, l'équipe Oracle effectue les activités de recouvrement à l'aide d'Autonomous Health Framework (AHF). Le processus n'est pas intrusif, ce qui garantit que les systèmes client restent pleinement opérationnels et non affectés. Conformément aux stratégies IAM, il applique un contrôle d'accès basé sur les rôles avec des privilèges minimaux pour protéger les environnements client. Toutes les actions sont consignées pour assurer la transparence et faciliter les audits détaillés.

Ces services proactifs garantissent qu'Oracle dispose des informations nécessaires sur les systèmes du client pour prendre en charge efficacement les activités planifiées. En identifiant à l'avance les problèmes potentiels, Oracle aide les clients à atténuer les risques et à maintenir des performances opérationnelles optimales. Le Programme des clients stratégiques met l'accent sur la planification collaborative, l'intervention en temps opportun et la transparence, contribuant à une plus grande fluidité des opérations des clients et à une infrastructure de base de données plus résiliente.

Vérifiez les prérequis pour configurer et exécuter le contrôle d'accès délégué.

• Types d'installation : cluster de machines virtuelles client dans Exadata Database Service on Cloud@Customer (ExaDB-C@C) et Exadata Database Service on Dedicated Infrastructure (ExaDB-D)
  Remarque
  
  Exadata Database Service on Dedicated Infrastructure (ExaDB-D) avec sous-réseau utilisant IPv6 n'est pas pris en charge en raison de la limitation de l'adresse privée.
• Modèle de système Oracle Exadata : X8 et versions supérieures
• Versions d'Oracle Database : Oracle Database versions 11.2.0.4 et supérieures pour les contrôles de journal, de sauvegarde et de configuration
• système d'exploitation de machine virtuelle client : Oracle Linux 7 et versions supérieures,
• Engagement du fournisseur de services : avant de créer les abonnements de délégation dans le service de contrôle d'accès délégué, contactez les fournisseurs de services souhaités contractuellement pour vous abonner à leurs services :
  • Support client Oracle Database Cloud
  • Opération Oracle Database Cloud
  • Déploiement de systèmes de production Oracle et prise en charge de l'infrastructure
  • Programme clients stratégiques pour les plates-formes cloud de base de données
• Exigences en matière de liste d'autorisation dans le pare-feu/la passerelle client :
  • Format d'URL : https://dactlhe.exacc.$LONGREGIONNAME.oci.$TOPLEVELDOMAIN

    Remplacez $LONGREGIONNAME par le nom de la région OCI (par exemple, us-ashburn-1).

    Remplacez $TOPLEVELDOMAIN par le domaine de région OCI (par exemple, oraclecloud.com).

    Par exemple, le format d'URL de la région ashbhurn sera https://dactlhe.exacc.us-ashburn-1.oci.oraclecloud.com

  • Port sortant à autoriser : 443
• Règle de sécurité réseau permettant d'autoriser SSH au cluster de machines virtuelles pour ExaDB-C@C et ExaDB-D

  Assurez-vous que SSH (port 22) est autorisé sur le sous-réseau client du cluster de machines virtuelles pour ExaDB-C@C et ExaDB-D. Cela peut être fait à l'aide d'un groupe de sécurité réseau ou d'une liste de sécurité dans votre VCN. En outre, si la stratégie Zero Trust Packet Routing est activée pour votre cluster de machines virtuelles, assurez-vous que le trafic SSH est autorisé à la fois dans les directions entrante et sortante.

  Voici un exemple de stratégie Zero Trust Packet Routing autorisant l'accès SSH au sein du sous-réseau client d'un cluster de machines virtuelles cloud :

  • database:Prod-VMCluster représente la valeur et la clé d'attribut de sécurité du cluster de machines virtuelles cloud.
  • network:vm-cluster-vcn représente la clé et la valeur de l'attribut de sécurité pour le VCN.
  • 10.10.1.0/24 est le bloc CIDR pour le sous-réseau client du cluster de machines virtuelles cloud.

  in network: vm-cluster-vcn VCN allow '10.10.1.0/24' to connect to database:Prod-VMCluster endpoints with protocol='tcp/22'
  in network: vm-cluster-vcn VCN allow database:Prod-VMCluster endpoints to connect to '10.10.1.0/24' with protocol='tcp/22'
  

  Cette stratégie garantit le trafic SSH bidirectionnel (port 22) entre le bloc CIDR spécifié et le cluster de machines virtuelles, en appliquant un accès sécurisé et restreint à l'aide des principes de confiance zéro.

• Règle de sécurité réseau permettant au cluster de machines virtuelles ExaDB-C@C et ExaDB-D de se connecter à d'autres services OCI

  Assurez-vous que le cluster de machines virtuelles ExaDB-C@C et ExaDB-D peut se connecter à d'autres services OCI à l'aide de la passerelle de service OCI au port 443. Cela peut être fait à l'aide d'un groupe de sécurité réseau ou d'une liste de sécurité dans votre VCN. En outre, si la stratégie Zero Trust Packet Routing est activée pour votre cluster de machines virtuelles, assurez-vous que le trafic osn-services-ip-addresses est autorisé dans les directions entrante et sortante.

  Voici un exemple de stratégie Zero Trust Packet Routing permettant d'autoriser le trafic osn-services-ip-addresses dans le sous-réseau client d'un cluster de machines virtuelles cloud :

  • database:Prod-VMCluster représente la valeur et la clé d'attribut de sécurité du cluster de machines virtuelles cloud.
  • network:vm-cluster-vcn représente la clé et la valeur de l'attribut de sécurité pour le VCN.
  • osn-services-ip-addresses est l'adresse IP du réseau Oracle Service (OSN).

  in network: vm-cluster-vcn VCN allow osn-services-ip-addresses to connect to database:Prod-VMCluster endpoints with protocol='tcp/443'
  in network: vm-cluster-vcn VCN allow database:Prod-VMCluster endpoints to connect to osn-services-ip-addresses with protocol='tcp/443'

  Cette stratégie garantit que le trafic bidirectionnel sur le port 443 entre le service OCI et le cluster de machines virtuelles cloud est autorisé explicitement, en appliquant un accès sécurisé et restreint conformément aux principes de confiance zéro.

• Stratégies IAM pour le contrôle d'accès délégué
  • Applicable à la fois à ExaDB-C@C et à ExaDB-D

    Pendant la maintenance du cluster de machines virtuelles, l'approbation de votre demande d'accès peut être retardée. La sélection de l'option "Approuver automatiquement les demandes d'accès pendant la fenêtre de maintenance" lors de la création d'un contrôle de délégation permet l'approbation automatique pendant la fenêtre de maintenance planifiée afin d'accélérer le processus d'approbation. Lorsque les opérateurs de fournisseur de services émettent une demande d'accès, Delegate Access Control doit vérifier si le cluster de machines virtuelles est en mode de maintenance ou non pour approuver automatiquement la demande.

    Pour autoriser Delegate Access Control à extraire des informations telles que l'état de cycle de vie, le nom d'affichage et l'ID de compartiment du cluster de machines virtuelles, du répertoire de base de base de données et de la base de données, créez la stratégie suivante :

    allow any-user TO inspect database-family IN compartment <your compartment> where ALL {
          request.principal.type='dlgtmgmtdelegationcontrol' }

    <your compartment> est le compartiment des bases de données et clusters de machines virtuelles ExaDB-C@C et ExaDB-D à régir par le contrôle d'accès délégué.

    Il arrive que le contrôle d'accès délégué publie des messages au client via OCI Notification Service (ONS) sur le sujet ONS indiqué lors de la création du contrôle de délégation :

    1. lorsqu'une demande d'accès est en attente d'approbation
    2. lorsqu'une prolongation de durée d'une demande d'accès est en attente d'approbation
    3. lorsqu'un opérateur a répondu à une demande d'informations supplémentaires sur une demande d'accès
    Pour autoriser le contrôle d'accès délégué à publier des messages sur le sujet ONS indiqué dans le contrôle de délégation, créez la stratégie suivante :

    allow any-user TO use ons-topics IN compartment <your compartment> where ALL { request.principal.type='dlgtmgmtdelegationcontrol' }

    <your compartment> est le compartiment du sujet ONS indiqué dans les contrôles de délégation.

  • Applicable à ExaDB-D

    Le contrôle d'accès délégué accédera aux machines virtuelles dans le cluster de machines virtuelles cloud à l'aide de SSH via l'accès privé. Une paire de clés SSH est générée dans le coffre OCI du client indiqué lors de la création du contrôle de délégation. La clé publique SSH est ensuite ajoutée au cluster de machines virtuelles cloud.

    Pour autoriser Delegate Access Control à lire les adresses IP privées des machines virtuelles dans le cluster de machines virtuelles cloud afin de créer l'adresse privée, créez la stratégie suivante :

    allow any-user TO {PRIVATE_IP_READ} IN compartment <your compartment> where ALL { request.principal.type='dlgtmgmtdelegationcontrol' }

    <your compartment> est le compartiment du sous-réseau client du cluster de machines virtuelles cloud.

    Pour autoriser Delegate Access Control à créer les adresses privées sur les machines virtuelles du cluster de machines virtuelles cloud, créez la stratégie suivante :

    allow any-user to use virtual-network-family IN compartment <your compartment> where ALL { request.principal.type='dlgtmgmtdelegationcontrol' }

    <your compartment> est le compartiment du sous-réseau client du cluster de machines virtuelles cloud.

    Pour autoriser Delegate Access Control à lire la clé SSH dans OCI Vault afin d'accéder aux machines virtuelles dans le cluster de machines virtuelles cloud, créez la stratégie suivante :

    allow any-user TO read secret-bundles IN compartment <your compartment> where ALL { request.principal.type='dlgtmgmtdelegationcontrol' }

    <your compartment> est le compartiment du coffre OCI indiqué lors de la création du contrôle de délégation.

• Stratégies IAM pour l'utilisateur client
  Les droits d'accès suivants doivent être accordés à tous les utilisateurs Delegate Access Control en tant que membre de <your group> :

  allow group <your group> to read delegation-management-service-providers in tenancy

  allow group <your group> to read delegation-management-service-provider-actions in tenancy

  allow group <your group> to read delegation-management-work-requests in compartment <your compartment>

  <your compartment> est le compartiment des ressources de contrôle d'accès délégué.

  L'utilisateur qui créera, mettra à jour et supprimera les abonnements de délégation doit disposer des droits d'accès suivants en tant que membre de <your group> :

  allow group <your group> to manage delegation-subscriptions in tenancy

  Les abonnements de délégation ne sont pas liés à un compartiment spécifique. Ils sont créés et gérés dans le compartiment racine.

  L'utilisateur qui créera, mettra à jour et supprimera des contrôles de délégation doit disposer des droits d'accès suivants en tant que membre de <your group> :

  • Pour gérer les ressources Delegate Access Control :

    allow group <your group> to manage delegation-controls in compartment <your compartment>

    <your compartment> est le compartiment des contrôles de délégation.

  • Pour créer et stocker la paire de clés SSH dans OCI Vault afin d'accéder aux machines virtuelles dans le cluster de machines virtuelles cloud ExaDB-D, procédez comme suit :

    allow group <your group> to manage secret-family in compartment <your compartment>

    <your compartment> est le compartiment du coffre OCI indiqué dans le contrôle de délégation.

  • Afin de disposer du droit d'accès USE pour le cluster de machines virtuelles ExaDB-C@C et le cluster de machines virtuelles cloud ExaDB-D, procédez comme suit :

    allow group <your group> to USE database-family in compartment <your compartment>

    <your compartment> est le compartiment du cluster de machines virtuelles ExaDB-C@C et du cluster de machines virtuelles cloud ExaDB-D.

  L'utilisateur qui approuvera, rejettera, révoquera et demandera plus d'informations sur la demande d'accès aux ressources déléguées doit disposer des droits d'accès suivants en tant que membre de <your group> :

  allow group <your group> to use delegated-resource-access-requests in compartment <your compartment>

  <your compartment> est le compartiment des demandes d'accès aux ressources déléguées, qui est le même compartiment que le contrôle de délégation associé.

Découvrez comment appliquer des contrôles aux opérations qu'un opérateur de fournisseur de services peut effectuer dans votre environnement.

• Présentation de la mise en oeuvre des actions
  Les actions de fournisseur de services dans le contrôle d'accès délégué limitent les privilèges dont dispose un opérateur lors de l'exécution de commandes, de l'accès aux ressources et de la modification de l'état du système.
• Action : diagnostics de système de machine virtuelle
  Les diagnostics de système de machine virtuelle, identifiés comme DLGT_MGMT_SYS_DIAG, permettent aux fournisseurs de service d'obtenir un accès SSH aux clusters de machines virtuelles du client avec un accès en lecture aux fichiers journaux et de diagnostic. Cette action empêche l'accès aux informations sensibles, aux modifications de configuration système, aux redémarrages système et au système d'audit.
• Action : maintenance du système de machine virtuelle
  La maintenance du système de machine virtuelle, identifiée comme DLGT_MGMT_SYS_MAINT_ACCESS, permet aux fournisseurs de service d'obtenir un accès SSH aux clusters de machines virtuelles avec des privilèges limités.
• Action : accès complet à la machine virtuelle
  L'accès complet à la machine virtuelle, identifié comme DLGT_MGMT_FULL_ACCESS, permet aux fournisseurs de service d'obtenir un accès complet aux clusters de machines virtuelles des clients.
• Action : accès aux commandes de machine virtuelle
  L'accès aux commandes de machine virtuelle, identifié comme DLGT_MGMT_CMD_ACCESS, permet aux fournisseurs de service d'exécuter un ensemble prédéfini de commandes sur les clusters de machines virtuelles à l'aide des API REST. Les opérateurs ne sont pas autorisés à accéder SSH aux clusters de machines virtuelles.
• Action : accès au journal de machine virtuelle
  L'accès au journal de machine virtuelle, identifié comme DLGT_MGMT_LOG_ACCESS, permet aux fournisseurs de service de collecter les journaux générés par les outils DBaaS, les journaux de base de données et les fichiers trace sur les clusters de machines virtuelles.
• Action : accès à l'API Database Cloud Service (DBaaS)
  L'accès à l'API Database Cloud Service (DBaaS), identifié comme étant DLGT_MGMT_DBAAS_API_ACCESS, permet aux fournisseurs de service d'accéder à un ensemble prédéfini d'API OCI Database Cloud Service pour lancer l'application de patches ou d'autres opérations de base de données pour le compte des clients.