Documentation Oracle Cloud Infrastructure

Présentation d'Oracle Operator Access Control

Découvrez comment contrôler, auditer et révoquer l'accès du personnel de service Oracle à votre infrastructure à l'aide d'Oracle Operator Access Control.

Qu'est-ce qu'Oracle Operator Access Control ?

Oracle Operator Access Control vous permet de gérer l'octroi, l'audit et la révocation de l'accès dont dispose Oracle sur votre infrastructure Exadata, votre infrastructure Exadata hébergeant une instance Oracle Autonomous Database sur Exadata Cloud@Customer et votre cluster de machines virtuelles Exadata Autonomous (machines virtuelles client déployées sur Oracle Autonomous Database on Exadata Cloud@Customer) administrés par Oracle, ainsi que d'obtenir des rapports d'audit sur toutes les actions effectuées par un opérateur, quasiment en temps réel.

Oracle Operator Access Control pour Exadata Cloud@Customer

Le service Oracle Exadata Cloud@Customer est un système à responsabilité partagée :
  • Vous êtes responsable des actions effectuées dans vos machines virtuelles, ainsi que de la gestion quotidienne des bases de données et des applications exécutées sur ces machines virtuelles.
  • Oracle est responsable des composants de l'infrastructure : alimentation, système d'exploitation Bare Metal, hyperviseurs, serveurs Exadata Storage Server et autres aspects de l'environnement d'infrastructure.

Toutefois, si des exigences réglementaires vous imposent d'auditer et de contrôler tous les aspects de la gestion du système, le modèle à responsabilité partagée pose problème. Vous devez prouver aux régulateurs que vous exercez un contrôle total sur vos systèmes et que vous les utilisez dans le respect des réglementations en matière de conformité.

Comment contrôler et auditer toutes les actions effectuées sur les composants de l'infrastructure par l'ensemble des opérateurs ou logiciels de vos systèmes ? Comment maintenir un même niveau d'audit et de contrôle d'accès sur les systèmes et fournir les enregistrements requis pour les audits réglementaires internes ou externes sur l'ensemble des systèmes ? Face à ces problèmes, Oracle propose la solution Oracle Operator Access Control qui permet d'empêcher les opérateurs Oracle d'avoir un accès illimité à vos systèmes.

Operator Access Control pour Oracle Autonomous Database sur Exadata Cloud@Customer

Operator Access Control a été étendu afin de fournir des contrôles pour les machines virtuelles client déployées sur Oracle Autonomous Database sur Exadata Cloud@Customer. Comme avec le contrôle d'accès d'opérateur pour l'infrastructure Exadata Cloud@Customer, les clients peuvent désormais imposer des contrôles d'accès d'opérateur Oracle sur les clusters de machines virtuelles Autonomous déployés sur Exadata Cloud@Customer.

La mise à disposition de la base de données autonome sur une infrastructure dédiée (dans OCI et Cloud@Customer) repose sur le principe selon lequel le client est l'"utilisateur" de la base de données et Oracle en est le "gestionnaire". Par "gestion", nous entendons les tâches standard d'administration de base de données, telles que les suivantes :
  • Provisionnement de ressources Autonomous Database
  • Sauvegarde de bases de données
  • Récupération d'une base de données
  • Application de patches et mise à niveau
  • Redimensionnement
  • Surveillance de l'état des services
  • Audit
  • Alertes et notifications

Le client n'a pas d'accès au système d'exploitation client ou aux journaux système, ni d'accès SYS/SYSTEM aux bases de données Conteneur. De plus, le client peut uniquement surveiller l'état et les performances des applications, ainsi que leur sécurité à tous les niveaux. Les opérateurs Oracle, quant à eux, disposent en tant que gestionnaires d'un accès complet à tous les composants, y compris un accès root à l'hyperviseur et aux machines virtuelles client.

Le modèle à responsabilité partagée pour les bases de données autonomes pose plusieurs défis opérationnels aux clients réglementés qui sont tenus de garder le contrôle sur l'ensemble des données et l'infrastructure, quel que soit le fournisseur et le modèle de déploiement (on-premise, hébergé ou cloud). Les clients réglementés subissent leur propre examen de conformité et formulent leurs propres directives de sécurité qui peuvent prendre des années pour durcir et mettre en pratique.

Cela est particulièrement vrai pour les clients professionnels d'Oracle, qui sont hautement réglementés et exécutent sur Oracle leurs systèmes les plus stratégiques et leurs applications les plus sensibles en matière de sécurité. Face à ces problèmes, Oracle propose la solution Oracle Operator Access Control qui permet d'empêcher les opérateurs Oracle d'avoir un accès illimité à vos systèmes.

Oracle Operator Access Control pour Oracle Cloud Infrastructure

Oracle Operator Access Control est un système d'audit de conformité qui vous permet de conserver des traces de gestion et d'audit précises de toutes les actions effectuées par un opérateur Oracle sur l'infrastructure.

Oracle Operator Access Control vous permet d'effectuer les actions suivantes :
  • Accorder l'accès à votre infrastructure, en précisant les utilisateurs autorisés à accéder à l'infrastructure, le moment où le système est accessible et la durée pendant laquelle le personnel Oracle peut accéder au système.
  • Afficher et enregistrer un rapport en temps quasi réel sur toutes les actions effectuées par un opérateur Oracle dans votre système.
  • Limiter l'accès à votre système, notamment les actions qu'un opérateur Oracle peut effectuer.
  • Révoquer l'accès, notamment l'accès précédemment accordé.

Operator Access Control pour Compute Cloud@Customer

L'infrastructure Compute Cloud@Customer est basée sur le principe selon lequel le client est l'"utilisateur"des machines virtuelles et des services qu'il crée et exécute sur l'infrastructure et Oracle est le"responsable" de l'infrastructure elle-même. Par "gestion", nous entendons des tâches standard telles que la mise à niveau, l'application de patches et la surveillance des composants d'infrastructure.

Le client n'a pas accès aux instances de système d'exploitation virtuel ou Bare Metal d'infrastructure sur les composants d'infrastructure, ni aux logiciels de gestion exécutés sur ces instances. Oracle Ops, en revanche, est le gestionnaire, dispose d'un accès complet à tous les composants, y compris un accès root à l'hyperviseur et à des serveurs de plan de contrôle.

Ce modèle pose plusieurs défis opérationnels aux clients réglementés qui sont tenus de garder le contrôle sur l'ensemble des données et l'infrastructure, quels que soient le fournisseur et le modèle de déploiement (sur site, hébergé ou cloud). Les clients réglementés subissent leur propre examen de conformité et formulent leurs propres directives de sécurité qui peuvent prendre des années pour renforcer et mettre en pratique. Cela est particulièrement vrai pour les clients professionnels d'Oracle, qui sont hautement réglementés et exécutent sur Oracle leurs systèmes les plus stratégiques et leurs applications les plus sensibles en matière de sécurité.

Operator Access Control a été étendu pour prendre en charge ces objectifs de conformité client et permettre à ces derniers d'intégrer leurs bases de données stratégiques dans Oracle Cloud afin que les clients contrôlent enfin l'accès à leurs systèmes dédiés.

Termes associés à Operator Access Control

Découvrez les termes utilisés avec Operator Access Control.

Opérateur : employé Oracle membre d'une location de groupe d'opérateurs (Ops) dans Oracle Cloud Infrastructure (OCI). Par exemple, il peut s'agir d'un employé Oracle du groupe Exadata Cloud@Customer_ops ou ExaCS_ops. La location de groupe Ops est un ensemble de locations dans OCI autorisées à administrer des contrôles d'opération. Les groupes Ops, et les opérateurs qui en sont membres, ne disposent d'aucun privilège par défaut autre que la possibilité de demander l'accès à l'infrastructure. Les groupes et l'appartenance aux groupes d'opérateurs sont strictement contrôlés par Oracle.

Utilisateur : utilisateur OCI de la location associée au système Exadata Cloud@Customer où se trouvent les contrôles.

Couche d'infrastructure Exadata : multiples couches de système d'exploitation ou physiques du système Exadata. Actuellement défini comme serveur de plan de contrôle, hôte, machine virtuelle invitée, serveurs de cellules, commutateurs et ILOM.

Action : ensemble nommé et prédéfini de commandes, de fichiers ou de réseaux accessibles sur une couche donnée. Oracle définit les actions.

Gestion des opérateurs : entité définie par le client, qui regroupe des actions préapprouvées et des actions nécessitant une approbation explicite du groupe d'approbation pour autoriser l'accès. Le groupe d'approbateurs est un groupe d'utilisateurs IAM standard qui contient l'ensemble des utilisateurs autorisés à approuver ou à révoquer l'accès.

Attributs d'opérateur : dans certains cas, le contrôle d'opérateur peut définir des critères pour les opérateurs autorisés à accéder à l'infrastructure.

Affectation d'un contrôle d'opérateur : processus par lequel un système Exadata Cloud@Customer est associé à un contrôle d'opérateur nommé. Un seul contrôle d'opérateur à la fois peut être appliqué sur un système Exadata Cloud@Customer. L'affectation peut être permanente ou limitée à une durée spécifique. Si aucun contrôle d'opérateur n'est affecté à un système Exadata Cloud@Customer, ce dernier est exécuté avec un contrôle d'opérateur par défaut qui autorise tous les accès requis pour les diagnostics et la maintenance.

Demande d'accès : processus par lequel un opérateur demande le droit d'accéder à une infrastructure Exadata identifiée. L'infrastructure Exadata est identifiée par l'OCID. La demande identifie l'action requise par l'opérateur.

Approbation/Rejet d'une demande d'accès : processus par lequel un utilisateur habilité, tel que déterminé par le contrôle d'opérateur déployé sur l'infrastructure Exadata, peut accorder ou rejeter une demande d'accès.

Révocation d'une demande d'accès : un utilisateur habilité peut à tout moment révoquer une demande d'accès. Cette opération entraîne la suppression immédiate des sessions de l'opérateur connecté à l'infrastructure Exadata sur la base de cette demande d'accès.

Demande d'accès en cours de vérification : consiste à accuser réception d'une demande d'accès d'opérateur Oracle déclenchée et à informer le demandeur qu'elle est en cours de vérification.

Options de contrôle fournies par Oracle Operator Access Control

Vous créez des stratégies indiquant l'ensemble d'actions que les opérateurs peuvent exécuter sur l'infrastructure.

Les actions définissent les contraintes appliquées aux opérations que peut effectuer un opérateur Oracle sur l'infrastructure gérée par Oracle. Ces contraintes incluent le contrôle de l'exécution des commandes shell de système d'exploitation et des scripts Oracle. Les actions appliquent également des contraintes à la possibilité qu'ont les opérateurs Oracle d'exécuter des fichiers binaires et des scripts shell, et des scripts Perl ou Python dépassant la portée de la fonction définie par l'action. Lorsque vous accordez des droits d'accès via une action, chaque action effectuée par un opérateur Oracle est consignée. Vous pouvez auditer les journaux dans le cadre de votre stratégie d'exigences en matière de contraintes MAC.

Une stratégie est un ensemble d'actions que vous spécifiez pour appliquer des contraintes de contrôle d'accès obligatoire (MAC) à la possibilité qu'ont les opérateurs Oracle d'effectuer des opérations de maintenance sur vos systèmes. Voici la liste des contrôles d'accès spécifiques que vous pouvez appliquer via des actions afin de définir des stratégies :

  1. Configurez des contrôles d'opérateur pour la gestion des opérateurs Oracle :
    • Les contrôles d'opérateur permettent de restreindre les profils d'accès sur un type de ressource donné de votre location. Par exemple, vous pouvez configurer des stratégies distinctes pour des ressources telles que la machine virtuelle, le serveur de base de données d'infrastructure Oracle, le serveur de plan de contrôle ou le réseau InfiniBand. En outre, vous pouvez configurer des stratégies pour associer des contrôles d'accès à un groupe de ressources dans votre location.
    • Configurez un groupe d'administrateurs associé à un contrôle d'opérateur. Les membres de ce type de groupe peuvent approuver, modifier ou refuser des demandes d'accès sur une ressource où vous avez déployé un contrôle d'opérateur.
    • Configurez des actions pour l'accès aux ressources définies comme préapprouvées, qui ne requièrent pas la configuration d'un groupe d'administrateurs pour contrôler l'accès.
  2. Spécifiez une autorisation de demande obligatoire avant d'autoriser tout accès aux ressources. Par exemple :
    • Lorsqu'un ensemble d'actions sont marquées comme préapprouvées, toute demande d'accès spécifiant uniquement un sous-ensemble des actions est automatiquement approuvée et le personnel Oracle peut accéder aux composants d'infrastructure.
    • Lorsqu'une stratégie d'accès n'est pas définie comme préapprouvée, l'accès aux compartiments est refusé au personnel Oracle jusqu'à ce que vous accordiez explicitement des demandes d'accès.
  3. Révoquez l'accès à l'infrastructure préalablement accordé :
    • Des limites de temps automatiques révoquent tout accès accordé à une ressource. Lorsque vous accordez une demande d'accès, un ID utilisateur unique correspondant à l'accès octroyé pendant une durée limitée est attribué à l'opérateur Oracle. Une fois la limite atteinte, tout accès par Oracle au système associé à la demande d'accès approuvée est révoqué. Si l'opérateur Oracle a besoin de plus de temps, il peut soumettre une demande d'extension.
    • Révoquez manuellement l'accès qui a déjà été accordé pour une ressource avant l'expiration de cet accès.
  4. Auditez toutes les actions effectuées par l'opérateur sur les ressources :

    • Toutes les commandes et saisies au clavier exécutées par un utilisateur humain sont auditées. Vous obtenez un accès complet à tous les journaux d'audit Linux.

      Vous pouvez demander l'audit d'un opérateur Oracle spécifique sur le système.

      Remarque

      En tant que client Oracle, vous n'avez pas accès à l'identité de l'opérateur. Toutefois, le système Oracle Operator Access Control conserve des enregistrements de service des opérateurs. Oracle peut ainsi mettre en corrélation l'opérateur avec une demande d'accès spécifique accordée pour un service sur la location. Si vous soupçonnez une action malveillante et que vous avez besoin d'un audit, Oracle peut utiliser cette demande pour vérifier toutes les actions de l'opérateur spécifique qui a effectué les actions autorisées via une demande d'accès.

Mise en oeuvre d'actions dans Operator Access Control

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

Rubrique parent : Présentation d'Oracle Operator Access Control

Présentation de la mise en oeuvre des actions

Les actions Operator Access Control limitent les privilèges dont dispose l'opérateur pour exécuter des commandes, accéder aux ressources et modifier l'état du système.

Une action définit les droits d'accès, l'accès aux ressources et l'accès pour la modification du système accordés à un opérateur Oracle afin qu'il effectue un ensemble donné de tâches pour des fonctions administratives spécifiques sur une infrastructure Exadata se trouvant dans un environnement géré à l'aide d'Operator Access Control. Une action peut autoriser des commandes Oracle Linux ou des commandes de serveur de cellules.

Une action accorde l'accès aux ressources suivantes : les fichiers et le réseau. Les modifications système correspondent à une modification d'état au niveau du système d'exploitation ou du logiciel en cours d'exécution sur le système. La modification d'état est la conséquence des redémarrages ou des modifications de configuration.

La mise en oeuvre des actions repose sur des demandes d'accès approuvées, qui configurent une stratégie limitée dans le temps portant sur les modifications qu'un opérateur Oracle est autorisé à implémenter, comme défini par un ensemble d'actions accordées aux opérateurs. Chaque demande d'accès crée des informations d'identification utilisateur temporaires dans l'infrastructure Exadata. La stratégie d'accès que vous définissez repose sur les actions que vous approuvez dans la demande d'accès associée à l'utilisateur temporaire créé.

La mise en oeuvre des actions relève généralement du système d'exploitation. Une stratégie de mise en oeuvre des actions est créée pour une instance du système d'exploitation, par exemple dans tous les hôtes, dans les serveurs de cellules et dans les serveurs de plan de contrôle. Les actions octroyées avec une stratégie sont enlevées dès que la demande d'accès n'est plus valide, c'est-à-dire lorsqu'elle est fermée (la tâche d'administration étant terminée), révoquée ou arrivée à expiration.

La mise en oeuvre des actions peut être appliquée à d'autres infrastructures, telles qu'un système d'exploitation, ou à d'autres logiciels, tels que cellcli.

Actions Operator Access Control : Infrastructure Exadata

Les actions définissent les opérations qu'un opérateur peut effectuer sur l'infrastructure Exadata Cloud@Customer. Ces dernières se limitent à l'hôte, au serveur de cellules et aux serveurs de plan de contrôle.

Les actions sont applicables à l'ensemble de l'infrastructure Exadata Cloud@Customer. Elles contrôlent les actions de l'opérateur Oracle sur plusieurs couches d'Exadata Cloud@Customer. Les couches contrôlées dans la version en cours sont les serveurs de cellules, le domaine de gestion (hôte) et les serveurs de plan de contrôle. Les actions sont organisées en fonction des exigences, ce qui conduit à la demande d'actions et à l'impact critique que ces actions peuvent générer.

Les actions traduisent les droits d'accès Oracle Linux sur le système Exadata Cloud@Customer cible. Les droits d'accès sont classés selon les privilèges sur le système de fichiers, privilèges d'exécution de commande et privilèges su ou sudo. Les actions sont classées en fonction de la nature de la modification pouvant être effectuée par l'opérateur sur le système Exadata Cloud@Customer.

  • Action : serveur de plan de contrôle (CPS) uniquement
    Le serveur de plan de contrôle (CPS) uniquement, identifié comme INFRA_CPS_ONLY, est destiné à être utilisé uniquement pour diagnostiquer et résoudre les problèmes CPS. Le personnel d'Oracle ne peut pas accéder aux composants au-delà du CPS, notamment aux serveurs de cellules et au système d'exploitation hôte (Dom0).
  • Action : diagnostic système
    Le diagnostic système, identifié comme INFRA_DIAG, est destiné à être utilisé pour diagnostiquer tout problème dans la couche d'infrastructure Exadata Cloud@Customer.
  • Action : maintenance du système avec privilèges de redémarrage
    La maintenance du système avec privilèges de redémarrage, identifiée comme INFRA_UPDATE_RESTART, est destinée à être utilisée pour les scénarios d'accès d'opérateur qui nécessitent une modification de la configuration système ou un redémarrage du système.
  • Action : maintenance du système avec accès aux données / privilèges de contrôle de machine virtuelle
    La maintenance du système avec accès aux données / privilèges de contrôle de machine virtuelle, identifiée comme INFRA_HYPERVISOR, est destinée à être utilisée pour les scénarios de diagnostic et de maintenance nécessitant la gestion des machines virtuelles sur l'hôte.
  • Action : accès complet au système
    L'accès complet au système, identifié comme INFRA_FULL, autorise l'accès aux comptes root sur les composants d'infrastructure.

Rubrique parent : Mise en oeuvre d'actions dans Operator Access Control

Action : serveur de plan de contrôle uniquement

Le serveur de plan de contrôle (CPS) uniquement, identifié comme INFRA_CPS_ONLY, est destiné à être utilisé uniquement pour diagnostiquer et résoudre les problèmes CPS. Le personnel d'Oracle ne peut pas accéder aux composants au-delà du CPS, notamment aux serveurs de cellules et au système d'exploitation hôte (Dom0).

Tableau 1-1 Actions autorisées avec INFRA_CPS_ONLY

Nom de l'action

Serveur de plan de contrôle uniquement
Identifiant de l'action

INFRA_CPS_ONLY
Privilèges d'opérateur

Privilèges utilisateur Linux : autres que root

Possibilité d'utiliser su pour root : non

chroot jail : Oui

Possibilité d'utiliser su pour : aucune

Utilisateur sudo + liste de commandes : limité à la liste fournie ci-dessus

Privilèges de serveur de cellules : non

Système d'exploitation de l'hôte (Dom0) : non

Privilèges réseau : non

Liste des commandes exécutables :

Ces commandes peuvent être exécutées directement à partir de l'invite Bash.

  • Alias :
    • sudols
    • sudocp
    • sudocat
    • sudotail
    • sudohead
    • sudovi
    • sudorm
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Commandes spéciales prises en charge :
    • rootexec /root/alarm_detail.sh
    • rootexec /root/alerthistory.sh
    • rootexec /root/blackout.sh
    • rootexec /root/quarantine_ack.sh
    • rootexec /root/stateless_ack.sh
    • rootexec /root/stateless_alert.sh
    • rootexec /etc/keepalived/manual-switchover.sh

Répertoires et fichiers avec accès explicite en lecture et en écriture :

  • Lecture et écriture :
    • /u01/
    • /opt/oci/exacc/
  • Lecture seule :
    • /var/log/
    • /opt/oracle.cellos/
    • /usr/local/nessus/results/
    • /opt/nessus/var/nessus/logs/

Commandes spéciales du contrôle d'accès d'opérateur :

Commandes Cage permettant d'afficher ou de modifier (lire, lire/écrire) les fichiers ou répertoires mentionnés ci-dessus :

  • sudols
  • sudocp
  • sudocat
  • sudotail
  • sudohead
  • sudovi
  • sudorm
Action : diagnostic système

Le diagnostic système, identifié comme INFRA_DIAG, est destiné à être utilisé pour diagnostiquer tout problème dans la couche d'infrastructure Exadata Cloud@Customer.

Le diagnostic consiste à lire des journaux, à exécuter des diagnostics et à surveiller des commandes. Cette action vise également à résoudre les problèmes liés aux agents de diagnostic dans le système Exadata Cloud@Customer. La correction implique le redémarrage des démons de diagnostic avec des paramètres potentiellement modifiés.

Remarque

L'action de diagnostic système ne présente aucun risque d'exposition des données client et de faible disponibilité.
L'action de diagnostic système permet de réaliser les opérations suivantes :
  • L'opérateur peut utiliser cat, grep, etc. pour lire les fichiers journaux du système d'exploitation, du logiciel d'infrastructure et du logiciel d'orchestration cloud.
  • L'opérateur peut exécuter des commandes de diagnostic Oracle Linux telles que top et netstat.
  • Sur les serveurs de cellules, l'opérateur peut en outre exécuter des commandes cellcli pour obtenir des informations de diagnostic.
  • L'opérateur peut accéder à l'infrastructure d'orchestration cloud sur le serveur de plan de contrôle et la gérer. Il a la possibilité de redémarrer tous les démons du serveur de plan de contrôle.

Tableau 1-2 Actions autorisées avec INFRA_DIAG

Nom de l'action

Diagnostic système
Identifiant de l'action

INFRA_DIAG
Privilèges d'opérateur

Privilèges utilisateur Oracle Linux : autres que root.

Possibilité d'utiliser su pour root : non

chroot jail : Oui

Possibilité d'utiliser su pour :
  • Cellule : cellmonitor
  • Hôte : dbmmonitor
  • Serveur de plan de contrôle :
    • ecra
    • exawatcher
    • dbmsvc
Exécution en tant qu'utilisateur root :
  • cat
  • head
  • tail
  • cp pour les fichiers de /var/log/*
  • Serveur de plan de contrôle (CPS) : systemctl

Privilèges de serveur de cellules : rôle de surveillance de cellule.

Droits d'accès réseau : possibilité d'un accès SSH à tous les hôtes, serveurs de cellules et serveurs de plan de contrôle. Le nom utilisateur est identique pour tous ces éléments.

Liste des commandes exécutables :

  • Serveur de plan de contrôle (Alias) : ces commandes peuvent être exécutées directement à partir de l'invite Bash.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Serveur de cellules (Alias) : ces commandes peuvent être exécutées directement à partir de l'invite Bash.
    • cellcli : commandes en lecture seule
    • sundiag.sh
    • sosreport
    • lspci
    • imageinfo
    • imagehistory
  • Hôte (alias) : ces commandes peuvent être exécutées directement à partir de l'invite Bash.
    • dbmcli : commandes en lecture seule
    • sundiag.sh
    • sosreport
    • virsh : seules les options de liste
    • xm : seules les options de liste
    • docker
    • podman
    • imageinfo
    • imagehistory

Répertoires et fichiers avec accès explicite en lecture et en écriture :

  • Serveur de plan de contrôle :
    • Lecture et écriture : /u01/
    • Lecture seule :
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Commandes spéciales Operator Access Control : commandes Cage permettant d'afficher ou de modifier (lire, lire/écrire) les fichiers ou répertoires mentionnés ci-dessus.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Hôte :
    • Lecture et écriture : Aucun
    • Lecture seule : /var/log/
    • Commandes spéciales Operator Access Control : commandes Cage permettant d'afficher ou de modifier (lire, lire/écrire) les fichiers ou répertoires mentionnés ci-dessus.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    Les répertoires suivants sont mis en correspondance en mode lecture-écriture pour l'exécution des outils. Toutefois, les opérateurs Oracle ne disposent pas d'un accès direct à ces derniers.
    • /var
    • /opt/oracle
  • Serveur de cellules :
    • Lecture et écriture : Aucun
    • Lecture seule : /var/log/
    • Commandes spéciales Operator Access Control : commandes Cage permettant d'afficher ou de modifier (lire, lire/écrire) les fichiers ou répertoires mentionnés ci-dessus.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    Les répertoires suivants sont mis en correspondance en mode lecture-écriture pour l'exécution des outils. Toutefois, les opérateurs Oracle ne disposent pas d'un accès direct à ces derniers.

    • /var
    • /opt/oracle
Action : maintenance du système avec privilèges de redémarrage

La maintenance du système avec privilèges de redémarrage, identifiée comme INFRA_UPDATE_RESTART, est destinée à être utilisée pour les scénarios d'accès d'opérateur qui nécessitent une modification de la configuration système ou un redémarrage du système.

Les scénarios INFRA_UPDATE_RESTART sont généralement destinés à la maintenance. Toutefois, il peut exister des scénarios de diagnostic dans lesquels cette action est également requise. Les modifications de la configuration système impliquent des modifications de la configuration au niveau du réseau, du matériel, du système d'exploitation (par exemple, montages, inodes, ulimits) ou du logiciel d'orchestration cloud. Le redémarrage du système permet à l'opérateur Oracle de redémarrer le système d'exploitation (hôte, serveur de cellules), des sous-systèmes spécifiques, tels que le réseau, et des disques cellule.

Attention :

N'oubliez pas que l'action Maintenance du système avec privilèges de redémarrage permet de redémarrer les composants d'infrastructure (serveurs de base de données, serveurs de stockage et serveurs de plan de contrôle) et empêche l'accès aux machines virtuelles client, aux données client et au service d'audit d'infrastructure.
Action de maintenance du système avec privilèges de redémarrage :
  • Elle permet à l'opérateur Oracle d'effectuer des activités de maintenance du système avec des privilèges root. L'opérateur ne peut pas devenir root, mais peut exécuter des commandes de maintenance en tant que root.
  • Elle n'autorise pas l'opérateur à modifier les paramètres d'audit ni à accéder aux journaux d'audit. Toutefois, cette action permet à l'opérateur de mettre hors ligne l'ensemble du système Exadata Cloud@Customer.
  • Elle permet aux opérateurs de modifier la configuration du système d'exploitation via des modifications permanentes. Par exemple, l'opérateur Oracle est autorisé à modifier /etc/ parameters.
  • Elle permet à l'opérateur Oracle de démarrer des processus de démon et de gérer les disques cellule à l'aide du privilège d'administration de cellule cellcli sur les serveurs de cellules.
  • Permet à l'opérateur Oracle d'accéder à l'infrastructure d'orchestration cloud sur le serveur de plan de contrôle et de la gérer. Il a la possibilité de redémarrer tous les démons du serveur de plan de contrôle.

Héritage : tous les privilèges du diagnostic système

Tableau 1-3 Actions autorisées avec INFRA_UPDATE_RESTART

Nom de l'action

Maintenance du système avec privilèges de redémarrage
Identifiant de l'action

INFRA_UPDATE_RESTART
Privilèges d'opérateur

Identiques à ceux du diagnostic système + privilèges suivants :

Possibilité d'utiliser su pour root : non

chroot jail : Oui

Possibilité d'utiliser su pour :
  • exawatcher
  • dbmsvc
  • dbmadmin
  • dbmmonitor sur l'hôte
Exécution en tant qu'utilisateur root :
  • restart
  • ip
  • ifconfig
  • lspci

Privilèges de serveur de cellules : celladmin dans le serveur de cellules

Droits d'accès réseau : possibilité d'un accès SSH à tous les hôtes, serveurs de cellules et serveurs de plan de contrôle. Le nom utilisateur est identique sur toutes ces couches.

Liste des commandes exécutables :

  • Serveur de plan de contrôle (Alias) : ces commandes peuvent être exécutées directement à partir de l'invite Bash.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Serveur de cellules (Alias) : ces commandes peuvent être exécutées directement à partir de l'invite Bash.
    • reboot
    • sundiag.sh
    • cellcli : toutes les commandes
    • lspci
    • imageinfo
    • imagehistory
    • ethtool
    • ipmitool
    • ipmitool_interactive (identique à ipmitool, peut être utilisé lorsque tty est requis)
  • Hôte (alias) : ces commandes peuvent être exécutées directement à partir de l'invite Bash.
    • reboot
    • dbmcli : toutes les commandes
    • sundiag.sh
    • virsh : seules les options de liste
    • xm : seules les options de liste
    • docker
    • podman
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport

Répertoires et fichiers avec accès explicite en lecture et en écriture :

  • Serveur de plan de contrôle :
    • Lecture et écriture : /u01/
    • Lecture seule :
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Commandes spéciales Operator Access Control : commandes Cage permettant d'afficher ou de modifier (lire, lire/écrire) les fichiers ou répertoires mentionnés ci-dessus.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Hôte :
    • Lecture et écriture : Aucun
    • Lecture seule : /var/log/
    • Commandes spéciales Operator Access Control : commandes Cage permettant d'afficher ou de modifier (lire, lire/écrire) les fichiers ou répertoires mentionnés ci-dessus.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    Les répertoires suivants sont mis en correspondance en mode lecture-écriture pour l'exécution des outils. Toutefois, les opérateurs Oracle ne disposent pas d'un accès direct à ces derniers.
    • /var
    • /opt/oracle
    • /home/dbmadmin
  • Serveur de cellules :
    • Lecture et écriture : Aucun
    • Lecture seule : /var/log/
    • Commandes spéciales Operator Access Control : commandes Cage permettant d'afficher ou de modifier (lire, lire/écrire) les fichiers ou répertoires mentionnés ci-dessus.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    Les répertoires suivants sont mis en correspondance en mode lecture-écriture pour l'exécution des outils. Toutefois, les opérateurs Oracle ne disposent pas d'un accès direct à ces derniers.
    • /var
    • /opt/oracle
    • /home/celladmin/
Action : maintenance du système avec accès aux données/privilèges de contrôle de machine virtuelle

La maintenance du système avec accès aux données / privilèges de contrôle de machine virtuelle, identifiée comme INFRA_HYPERVISOR, est destinée à être utilisée pour les scénarios de diagnostic et de maintenance requérant la gestion des machines virtuelles sur l'hôte.

L'action System Maintenance with Data access/VM Control Privileges est destinée à être utilisée pour les scénarios de diagnostic et de maintenance nécessitant la gestion des machines virtuelles sur l'hôte. Toutes les données sur la machine virtuelle invitée sont traitées comme des données client. Etant donné que la gestion des machines virtuelles implique la possibilité d'accéder à leurs données, cette action peut exposer les données à un risque. Toutefois, cette action ne donne aucun accès aux clés TDE des données stockées dans les serveurs de cellules. La gestion des machines virtuelles est requise en cas de problèmes avec l'infrastructure logicielle des machines virtuelles ou lorsqu'une configuration de machine virtuelle doit être modifiée. La configuration implique l'aspect externe des machines virtuelles, comme les réseaux connectés, les disques attachés ou les ressources allouées (UC, mémoire).

Remarque

La maintenance du système avec des privilèges d'accès aux données/ de contrôle de machine virtuelle empêche l'accès au sous-système d'audit d'infrastructure.
Action System Maintenance with Data Access/VM Control Privileges :
  • Elle permet à l'opérateur d'exécuter des commandes de gestion Xen/KVM avec des privilèges root. L'opérateur ne peut pas devenir root. Cette action s'applique uniquement à l'hôte.
  • Elle hérite des privilèges de l'action de maintenance du système avec privilèges de redémarrage.
  • Elle ne permet pas à l'opérateur de modifier les paramètres de système d'exploitation de l'hôte ou des serveurs de cellules. Toutefois, cela permet à l'opérateur d'arrêter la machine virtuelle invitée et de modifier de manière significative la configuration de la machine virtuelle invitée.

Héritage : tous les privilèges de la maintenance du système avec redémarrage.

Tableau 1-4 Actions autorisées avec INFRA_HYPERVISOR

Nom de l'action

Maintenance du système avec accès aux données/privilèges de contrôle de machine virtuelle
Identifiant de l'action

INFRA_HYPERVISOR
Privilèges d'opérateur

Identiques à ceux de la maintenance du système avec redémarrage + privilèges suivants :

Privilèges utilisateur Oracle Linux : autres que root.

Possibilité d'utiliser su pour root : non

chroot jail : Oui

Possibilité d'utiliser su pour celladmin dans le serveur de cellules

Exécution en tant qu'utilisateur root :
  • /usr/sbin/xm
  • /usr/sbin/xentop
  • /usr/sbin/virsh

Privilèges de serveur de cellules : celladmin

Droits d'accès réseau : possibilité d'un accès SSH à tous les hôtes, serveurs de cellules et serveurs de plan de contrôle. Le nom utilisateur est identique pour tous ces éléments.

Liste des commandes exécutables :

  • Serveur de plan de contrôle (Alias) : ces commandes peuvent être exécutées directement à partir de l'invite Bash.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Serveur de cellules (Alias) : ces commandes peuvent être exécutées directement à partir de l'invite Bash.
    • cellcli : toutes les commandes
    • lspci
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport
    • reboot
    • sundiag.sh
    • ipmitool
    • ipmitool_interactive (identique à ipmitool, peut être utilisé lorsque tty est requis)
  • Hôte (alias) : ces commandes peuvent être exécutées directement à partir de l'invite Bash.
    • dbmcli : toutes les commandes
    • sundiag.sh
    • virsh : toutes les options
    • xm : toutes les options
    • virsh_interactive : toutes les options (comme virsh, peuvent être utilisées lorsque tty est requis)
    • xm_interactive : toutes les options (comme xm, peuvent être utilisées lorsque tty est requis)
    • xentop : toutes les options
    • vm_maker : toutes les options
    • docker
    • docker_interactive (identique à docker, peut être utilisé lorsque tty est requis)
    • podman
    • podman_interactive (identique à podman, peut être utilisé lorsque tty est requis)
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport
    • ipmitool
    • ipmitool_interactive (identique à ipmitool, peut être utilisé lorsque tty est requis)
    • ops_console.sh

Répertoires et fichiers avec accès explicite en lecture et en écriture :

  • Serveur de plan de contrôle :
    • Lecture et écriture : /u01/
    • Lecture seule :
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Commandes spéciales Operator Access Control : commandes Cage permettant d'afficher ou de modifier (lire, lire/écrire) les fichiers ou répertoires mentionnés ci-dessus.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Hôte :
    • Lecture et écriture : Aucun
    • Lecture seule : /var/log/
    • Commandes spéciales de contrôle d'accès d'opérateur : commandes Cage permettant d'afficher ou de modifier (lire, lire/écrire) les fichiers ou répertoires mentionnés ci-dessus.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    Les répertoires suivants sont mis en correspondance en mode lecture-écriture pour l'exécution des outils. Toutefois, les opérateurs Oracle ne disposent pas d'un accès direct à ces derniers.

    • /var
    • /opt/oracle
    • /home/dbmadmin
  • Serveur de cellules :
    • Lecture et écriture : Aucun
    • Lecture seule : /var/log/
    • Commandes spéciales Operator Access Control : commandes Cage permettant d'afficher ou de modifier (lire, lire/écrire) les fichiers ou répertoires mentionnés ci-dessus.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    Les répertoires suivants sont mis en correspondance en mode lecture-écriture pour l'exécution des outils. Toutefois, les opérateurs Oracle ne disposent pas d'un accès direct à ces derniers.

    • /var
    • /opt/oracle
    • /home/celladmin/
Action : accès complet au système

L'accès complet au système, identifié comme INFRA_FULL, permet d'accéder aux comptes root sur les composants d'infrastructure.

L'action d'accès complet au système doit être utilisée lorsque l'accès complet à l'infrastructure Exadata Cloud@Customer est requis. L'accès est toujours limité aux couches de machine virtuelle non invitée. L'accès complet signifie ici les privilèges root sur chaque instance de système d'exploitation du système Exadata Cloud@Customer, à l'exception des machines virtuelles invitées.

Remarque

L'action Accès complet au système permet à l'opérateur de devenir l'utilisateur root sur l'infrastructure. Cela permet à l'opérateur d'accéder et de modifier tout registre de mémoire, tout fichier, tout périphérique et le sous-système d'audit.

Tableau 1-5 Actions autorisées avec INFRA_FULL

Nom de l'action

Accès complet au système
Identifiant de l'action

INFRA_FULL
Privilèges d'opérateur

Privilèges utilisateur Linux : autres que root

Possibilité d'utiliser su pour root : non

chroot jail : Non

Répertoires accessibles en lecture : tous

Fichiers accessibles en lecture : tous

Répertoires accessibles en écriture : tous

Fichiers accessibles en écriture : tous

Liste des commandes exécutables : toutes

Possibilité d'utiliser su pour root via sudo

Utilisateur sudo + liste de commandes : aucune restriction

Privilèges de serveur de cellules : root et celladmin

Droits d'accès réseau : possibilité d'un accès SSH à tous les hôtes, serveurs de cellules et serveurs de plan de contrôle. Le nom utilisateur est identique pour tous ces éléments. De plus, connexion à root directement sur l'hôte et sur le serveur de cellules à l'aide d'exassh.

Actions Operator Access Control : cluster de machines virtuelles Autonomous

Outre l'accès complet au système, utilisez les cages d'accès limité, Diagnostics et Maintenance, pour afficher les journaux et effectuer les tâches liées aux services.

Rubrique parent : Mise en oeuvre d'actions dans Operator Access Control

Action : accès complet au système du cluster de machines virtuelles Exadata Autonomous

L'accès complet au système du cluster de machines virtuelles Exadata Autonomous, identifié comme AVM_FULL, doit être utilisé rarement si aucun des privilèges d'accès inférieurs ne peut résoudre le problème.

L'action Accès complet au système de cluster de machines virtuelles Exadata Autonomous est destinée à être utilisée lorsque l'accès complet aux machines virtuelles invitées est requis. L'accès complet signifie ici les privilèges root pour les machines virtuelles invitées.

Remarque

L'action d'accès complet au système présente des risques extrêmes, et potentiellement persistants, en matière de disponibilité et d'exposition des données. Cette action permet également d'exclure l'export des journaux d'audit du système.

Tableau 1-6 Actions activées avec AVM_FULL

Nom de l'action

Accès complet au système
Identifiant de l'action

AVM_FULL
Privilèges d'opérateur

Privilèges utilisateur Linux : autres que root

Possibilité d'utiliser su pour root : non

Mise en cage avec chroot : non

Répertoires accessibles en lecture : tous

Fichiers accessibles en lecture : tous

Répertoires accessibles en écriture : tous

Fichiers accessibles en écriture : tous

Liste des commandes exécutables : toutes

Possibilité d'utiliser su pour root via sudo

Utilisateur sudo + liste de commandes : aucune restriction

Action : diagnostics du système de cluster de machines virtuelles Exadata Autonomous

Les diagnostics système de cluster de machines virtuelles Exadata Autonomous, identifiés par AVM_SYS_DIAG, doivent être utilisés pour visualiser les journaux.

L'action de diagnostic du système de cluster de machines virtuelles Exadata Autonomous est destinée à être utilisée pour visualiser les journaux. Un profil en lecture seule, qui permet un accès en lecture seule non privilégié au système. Cette action permet de déterminer les éventuels problèmes liés au système d'exploitation et au logiciel qui s'y exécute. La plupart des commandes non-root sont disponibles dans ce mode. Aucune commande privilégiée n'est disponible dans cette action. Les opérateurs ne sont pas autorisés à utiliser sudo en tant qu'opérateurs oracle, opc ou grid, mais ils disposent d'un ensemble de commandes répertoriées dans une liste blanche qu'ils peuvent exécuter en tant qu'utilisateur d'opérateur dynamique.

Tableau 1-7 Actions activées avec AVM_SYS_DIAG

Nom de l'action

Diagnostics du système de cluster de machines virtuelles Exadata Autonomous
Identifiant de l'action

AVM_SYS_DIAG
Portée

Machine virtuelle invitée
Privilèges d'opérateur

Privilèges utilisateur Linux : autres que root

Can su to root, oracle, opc, grid : Non

Mise en cage avec chroot : oui

Répertoires accessibles en lecture :
  • /proc
  • /sys
  • /tmp
  • /usr/lib64
  • /usr/bin
  • /usr/etc
  • /usr/include
  • /usr/lib
  • /usr/libexec
  • /usr/local
  • /usr/share
  • /opt/nessus
  • /usr/java
  • /var
  • /u01
  • /u02
  • /acfs01
  • /opt/oracle/dcs/log
  • /opt/oracle.ExaWatcher/archive

Répertoires accessibles en écriture : /tmp

Emplacements lisibles de journal d'application restreints :
  • /etc/oratab
  • /opt/oracle/dcs/log
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /u02/oracle.ahf
  • /u02/app/oracle/diag/rdbms
  • /opt/oracle.ExaWatcher/archive
Fichiers de configuration lisibles :
  • /etc/oratab
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /etc/hosts

Accès réseau sortant : aucun

Commandes du système d'exploitation sur liste noire :
  • dd
  • kdumpctl
  • ipcrm
  • ipcmk

Liste des commandes exécutables : les commandes ls, cat et tail sont prises en charge dans les emplacements où l'utilisateur dynamique opctl ne dispose pas d'un accès en lecture

Limiter l'accès de l'opérateur à une base de données Conteneur Autonomous spécifique approuvée par le client

Limitez l'accès à un ACD spécifique dans un cluster de machines virtuelles autonomes dans les cages de diagnostic et de maintenance.

Les opérateurs peuvent indiquer s'ils ont besoin des éléments suivants :

  • Accès SSH uniquement au cluster de machines virtuelles autonome sans accès SQL aux bases de données Conteneur Autonomous. Dans ce cas, tous les accès SQL aux bases de données Conteneur Autonomous sont bloqués.
  • Accès SSH au cluster de machines virtuelles autonomes et accès SQL aux bases de données Conteneur Autonomous. S'ils sélectionnent les deux, ils doivent sélectionner une ou plusieurs ACD.

Le client reçoit une demande d'approbation avec les détails auxquels les opérateurs demandent l'accès. De cette façon, le client peut être assuré que les opérateurs auront accès au bon ACD. Une fois que le client a approuvé la demande d'accès, les opérateurs n'ont accès au code SQL qu'aux bases de données Conteneur Autonomous pour lesquelles ils ont été approuvés.

L'attribut Request Reason affiche les ACD auxquels les opérateurs demandent l'accès.

Action : maintenance du système de cluster de machines virtuelles Exadata Autonomous

La maintenance du système de cluster de machines virtuelles Exadata Autonomous, identifiée comme AVM_SYS_MAINT, doit être utilisée pour effectuer des modifications liées au service.

L'action de maintenance du système de cluster de machines virtuelles Exadata Autonomous est destinée à être utilisée pour effectuer des modifications liées au service. Cette action permet de démarrer et d'arrêter des services, et d'exécuter des vérifications de l'état des services. La plupart des commandes associées au service sont disponibles dans ce mode. L'opérateur aura accès aux journaux, mais ne pourra pas accéder à su pour oracle, opc ou grid.

Tableau 1-8 Actions activées avec AVM_SYS_MAINT

Nom de l'action

Maintenance du système du cluster de machines virtuelles Autonomous Exadata
Identifiant de l'action

AVM_SYS_MAINT
Portée

Machine virtuelle invitée
Privilèges d'opérateur

Privilèges utilisateur Linux : autres que root

Can su to root, oracle, opc, grid : Non

Mise en cage avec chroot : oui

Répertoires accessibles en lecture :
  • /proc
  • /sys
  • /tmp
  • /usr/lib64
  • /usr/bin
  • /usr/etc
  • /usr/include
  • /usr/lib
  • /usr/libexec
  • /usr/local
  • /usr/share
  • /opt/nessus
  • /usr/java
  • /var
  • /u01
  • /u02
  • /acfs01
  • /opt/oracle/dcs/log
  • /opt/oracle.ExaWatcher/archive

Répertoires accessibles en écriture : aucun

Emplacements lisibles de journal d'application restreints :
  • /etc/oratab
  • /opt/oracle/dcs/log
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /u02/oracle.ahf
  • /u02/app/oracle/diag/rdbms
  • /opt/oracle.ExaWatcher/archive
Fichiers de configuration lisibles :
  • /etc/oratab
  • /etc/crontab
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /etc/hosts

Accès réseau sortant : aucun

Commandes du système d'exploitation sur liste noire :
  • dd
  • kdumpctl
  • ipcrm
  • ipcmk

Alias de commande : {"job_manager" : "/var/opt/oracle/adbd/apps/job_manager/job_manager.py", "backup_api" : "/var/opt/oracle/bkup_api/bkup_api", "service_driver" : "/var/opt/oracle/pylib/DBAAS/service_driver.py"}

Liste des commandes exécutables : l'exécution des commandes liées au service est disponible telle quelle, mais sans passer à l'utilisateur oracle ou grid. L'exécution des scripts est prise en charge via des alias sans passer à l'utilisateur oracle ou grid.

Reportez-vous aux exemples fournis ci-dessous.

  • crsctl status resource adbd_archive_log_ilkzdar1
  • crsctl check cluster -all
  • crsctl stat res -t
  • crsctl stat res ora.asm -t
  • srvctl status service -db ilkzdar1_cdg1hw
  • srvctl status database -d hr5zxn5l_cdg1bg
  • srvctl status instance -i hr5zxn5l1 -d hr5zxn5l_cdg1bg
  • tfactl blackout add -targettype host -timeout 2h -reason "Testing maint cage" -c
  • dgmgrl
  • asmcmd lsdsk -p

    (Non autorisé en raison d'un accès possible à la console système)

  • sysresv

    (Non autorisé en raison d'options de suppression des ressources ipc)

  • SQL*Plus est limité aux requêtes sélectionnées. Le passage à oracle ou grid n'est pas pris en charge.

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ execsql ORACLE_UNQNAME is required.Check /etc/oratab opctl_avm_maint_user01@atpd-exa-suzzm1:~$

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ cat /etc/oratab | grep -v '^\s*$\|^\s*\#' ownwdhci_iad2pn:/u02/app/oracle/product/19.0.0.0/db1916_0_wc139_cl_atksxzha_096_0105:Y +ASM1:/u02/app/19.0.0.0/grid1916_0_wc140_cl_atksxzha_096_1334:Y ay5sq1qf_iad2bp:/u02/app/oracle/product/19.0.0.0/db1916_0_wc141_cl_atksxzha_096_0214:Y dhb2br6k_iad22z:/u02/app/oracle/product/19.0.0.0/db1916_0_wc142_cl_atksxzha_096_0416:Y v001zhgm_iad2zs:/u02/app/oracle/product/19.0.0.0/db1916_0_wc143_cl_atksxzha_096_0419:Y drmgiyo6_iad277:/u02/app/oracle/product/19.0.0.0/db1916_0_wc138_cl_atksxzha_096_0033:Y fflilzax_iad2km:/u02/app/oracle/product/19.0.0.0/db1916_0_wc145_cl_atksxzha_096_0411:Y gytjhr9o_iad2tt:/u02/app/oracle/product/19.0.0.0/db1916_0_wc144_cl_atksxzha_096_0411:Y dqk29prh_iad2hc:/u02/app/oracle/product/19.0.0.0/db1916_0_wc146_cl_atksxzha_096_0416:Y utynogge_iad2p8:/u02/app/oracle/product/19.0.0.0/db1916_0_wc147_cl_atksxzha_096_1213:Y my06yvoe_iad2km:/u02/app/oracle/product/19.0.0.0/db1916_0_wc149_cl_atksxzha_096_1218:Y nfcteuzf_iad2j9:/u02/app/oracle/product/19.0.0.0/db1916_0_wc148_cl_atksxzha_096_1216:Y opctl_avm_maint_user01@atpd-exa-suzzm1:~$

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ execsql utynogge_iad2p8

    SQL*Plus: Release 19.0.0.0.0 - Production on Thu Oct 6 06:32:11 2022 Version 19.16.0.1.0 Copyright (c) 1982, 2020, Oracle. All rights reserved. Last Successful login time: Thu Oct 06 2022 06:29:09 +00:00 Connected to: Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production Version 19.16.0.1.0 SQL> SELECT INSTANCE_NAME, STATUS, DATABASE_STATUS FROM V$INSTANCE; INSTANCE_NAME STATUS DATABASE_STATUS ---------------- ------------ ----------------- utynogge1 OPEN ACTIVE SQL> SELECT sys_context('userenv','instance_name') FROM dual; SYS_CONTEXT('USERENV','INSTANCE_NAME') -------------------------------------------------------------------------------- utynogge1 SQL> !whoami SP2-0738: Restricted command "! (HOST)" not available SQL> !ls -ltr SP2-0738: Restricted command "! (HOST)" not available SQL>

Scripts à exécuter comme suit avec des alias.
  • /var/opt/oracle/adbd/apps/job_manager/job_manager.py --get_status adbd_archive_log_ilkzdar1

    A exécuter en tant que : job_manager --get_status adbd_archive_log_ilkzdar1

  • /var/opt/oracle/pylib/DBAAS/service_driver.py --dbname=hr5zxn5l_cdg1bg

    A exécuter en tant que : service_driver --dbname=hr5zxn5l_cdg1bg

  • /var/opt/oracle/bkup_api/bkup_api --dbname ilkzdar1 list jobs

    A exécuter en tant que : backup_api --dbname ilkzdar1 list jobs

Limiter l'accès de l'opérateur à une base de données Conteneur Autonomous spécifique approuvée par le client

Limitez l'accès à un ACD spécifique dans un cluster de machines virtuelles autonomes dans les cages de diagnostic et de maintenance.

Les opérateurs peuvent indiquer s'ils ont besoin des éléments suivants :

  • Accès SSH uniquement au cluster de machines virtuelles autonome sans accès SQL aux bases de données Conteneur Autonomous. Dans ce cas, tous les accès SQL aux bases de données Conteneur Autonomous sont bloqués.
  • Accès SSH au cluster de machines virtuelles autonomes et accès SQL aux bases de données Conteneur Autonomous. S'ils sélectionnent les deux, ils doivent sélectionner une ou plusieurs ACD.

Le client reçoit une demande d'approbation avec les détails auxquels les opérateurs demandent l'accès. De cette façon, le client peut être assuré que les opérateurs auront accès au bon ACD. Une fois que le client a approuvé la demande d'accès, les opérateurs n'ont accès au code SQL qu'aux bases de données Conteneur Autonomous pour lesquelles ils ont été approuvés.

L'attribut Request Reason affiche les ACD auxquels les opérateurs demandent l'accès.

Actions Operator Access Control : Compute Cloud@Customer

Parfois, les opérateurs autorisés doivent accéder aux ressources pour mettre à niveau Compute Cloud@Customer, dépanner ou aider à résoudre un problème.

Rubrique parent : Mise en oeuvre d'actions dans Operator Access Control

Action : accès complet à l'infrastructure Compute Cloud@Customer

L'accès complet à l'infrastructure Compute Cloud@Customer est identifié comme CCC_SYS_ADMIN_FULL_ACCESS.

Tableau 1-9 Actions activées avec CCC_SYS_ADMIN_FULL_ACCESS

Nom de l'action

Accès complet au système
Identifiant de l'action

CCC_SYS_ADMIN_FULL_ACCESS
Privilèges d'opérateur

Privilèges utilisateur Linux : autres que root

Possibilité d'utiliser su pour root : non

Mise en cage avec chroot : non

Répertoires accessibles en lecture : tous

Fichiers accessibles en lecture : tous

Répertoires accessibles en écriture : tous

Fichiers accessibles en écriture : tous

Liste des commandes exécutables : toutes

Possibilité d'exécuter su dans : root via sudo et d'exécuter toutes les commandes en tant qu'utilisateur root

Limites d'Operator Access Control

Operator Access Control est une solution conçue pour l'audit et la conformité des accès Oracle. Il ne s'agit pas d'une solution de conformité à usage général.

Operator Access Control audite uniquement les utilisateurs autorisés créés dans le contexte d'une demande d'accès associée à un contrôle d'accès d'opérateur Oracle. Voici une liste d'exemples d'actions de contrôle et d'audit de conformité qu'Operator Access Control ne couvre pas.

  • Operator Access Control contrôle uniquement les couches appartenant à Oracle. Par exemple, Operator Access Control contrôle l'accès au serveur de base de données Exadata physique et au serveur Exadata Storage Server.
  • Operator Access Control ne contrôle pas les actions d'automatisation, y compris celles exécutées en tant que root ou en tant qu'autre utilisateur d'automatisation disposant de privilèges élevés, et l'accès d'automatisation reposant sur un proxy.
  • Operator Access Control permet uniquement des contrôles au niveau d'actions définies. Les actions elles-mêmes contrôlent l'accès à une application au niveau du système d'exploitation.
  • Operator Access Control n'est pas un service d'audit général. Il audite uniquement les utilisateurs autorisés créés dans le contexte d'une demande d'accès associée à un contrôle d'opérateur.
  • Operator Access Control contrôle uniquement les différentes couches des systèmes Exadata Cloud@Customer. Il ne permet pas de contrôler les entités externes d'Oracle Cloud Infrastructure, telles que les commutateurs, ou les autres logiciels de plan de contrôle.

Rôles fonctionnels de location client pour Operator Access Control

Pour mettre en place le contrôle d'accès d'opérateur, vous devez configurer des stratégies de contrôle d'accès et établir des groupes d'utilisateurs responsables de la gestion et de la surveillance de l'accès à l'infrastructure.

Rubrique parent : Présentation d'Oracle Operator Access Control

Création de contrôles d'opérateur pour les administrateurs de stratégie

Les administrateurs de stratégie sont les utilisateurs autorisés à configurer des stratégies de contrôle d'opérateur (appelées contrôles d'opérateur).

Dans le cadre de la création d'un contrôle d'accès d'opérateur sur l'infrastructure, la première étape consiste à créer des administrateurs de stratégie de contrôle d'opérateur qui développent et créent l'ensemble de contrôles d'opérateur à utiliser pour les administrateurs de parc de locations.

En règle générale, lorsque vous créez des contrôles d'opérateur, vous divisez l'infrastructure Exadata en groupes de contrôles d'accès reposant sur plusieurs dimensions :

  • Importance pour l'entreprise : systèmes critiques, moins critiques, de développement
  • Sécurité ou conformité : systèmes ayant des besoins spécifiques en matière de conformité ou autre
  • Groupes d'utilisateurs : groupes d'utilisateurs (généralement dotés du rôle d'administrateur de parc) devant s'occuper d'un ensemble de systèmes Exadata

Voici quelques exemples de groupes d'utilisateurs responsables d'un ensemble de systèmes Exadata :

  • Services verticaux, dont les applications dépendent d'un ensemble de systèmes Exadata.
  • Systèmes partagés entre plusieurs services, dont l'administration est assurée par un service informatique.

Généralement, vous créez des compartiments dans votre infrastructure en fonction de critères d'importance, de conformité réglementaire et de gestion des groupes d'utilisateurs. Les compartiments constituent en effet les limites administratives logiques dans Oracle Cloud Infrastructure. Chaque compartiment est habituellement associé à un groupe d'utilisateurs disposant de privilèges de gestion sur le compartiment. C'est pourquoi l'administrateur de stratégie doit créer autant de contrôles d'opérateur que de compartiments contenant des infrastructures Exadata.

En plus des contrôles d'opérateur spécifiques des compartiments, vous devez également créer une stratégie supplémentaire, appelée DEFAULT_OPERATOR_CONTROL, utilisable lors de la création d'ensembles de systèmes Exadata dans de nouveaux compartiments, pour lesquels vous pouvez créer un autre ensemble d'administrateurs.

Approbation des demandes d'accès d'opérateur

Découvrez comment configurer un régime Identity and Access Management (IAM) à l'aide de stratégies Oracle Operator Access Control afin de gérer les approbations de contrôle d'opérateur.

Les administrateurs de location des contrôles d'opérateur d'un système Oracle Cloud sont membres du groupe d'administrateurs des contrôles d'opérateur. Vous recevez des demandes de contrôle d'opérateur relatives à l'accès à Oracle Cloud Infrastructure. Pour répondre aux exigences de conformité réglementaire, vous pouvez régir l'accès à l'infrastructure. Vous pouvez indiquer que certaines actions ont toujours le statut Approuvé automatiquement et que d'autres doivent recevoir une approbation pour qu'Oracle puisse effectuer des opérations de maintenance du système dans la location. Lorsque vous accordez l'accès à votre système, il est automatiquement limité à une durée standard. Vous pouvez également indiquer que les opérations doivent avoir lieu dans une période spécifique.

Exemple 1-1 Contrôles d'opérateur pour une stratégie Oracle Cloud Infrastructure IAM

Vous pouvez définir des contrôles détaillés pour les droits d'accès accordés sur le système.

Par exemple, supposons que vous disposiez de deux groupes de systèmes Exadata Cloud dans un compartiment dont vous êtes l'administrateur de location. Dans le cadre de votre stratégie IAM, vous avez créé deux ensembles distincts de systèmes Exadata : toutes les configurations de stratégie d'opérateur sont définies comme préapprouvées pour le premier groupe de systèmes et aucune stratégie d'opérateur n'est configurée comme préapprouvée pour le second.

Vous avez également créé deux groupes d'utilisateurs : PRE_APPROVED_POLICY_USERS et EXPLICIT_APPROVED_POLICY_USERS. Les groupes de contrôles d'opérateur sont identifiés par le balisage que vous fournissez : l'espace de noms optctl comporte deux groupes de contrôles d'opérateur. Le premier est identifié par la balise pre-approved-exacc. Le second groupe est identifié par la balise explicit-approved-exacc. Vous disposez donc globalement d'un ensemble de serveurs dont toutes les actions sont préapprouvées et d'un autre dont aucune action n'est préapprouvée.

Ensuite, dans votre compartiment, supposons que vous ayez défini un ensemble de ressources Exadata Cloud, chacune représentant un niveau autorisé d'actions :

  • system_diag spécifie les droits d'accès relatifs aux actions permettant de diagnostiquer tout problème dans la couche d'infrastructure Exadata Cloud@Customer, par exemple la lecture des journaux, l'exécution des diagnostics et la surveillance des commandes. Vous accordez aux membres de cette stratégie l'action INFRA_DIAG.
  • system_main spécifie les droits d'accès relatifs aux actions permettant d'effectuer des opérations de diagnostic et de maintenance du système, mais également le redémarrage du système. Vous accordez aux membres de cette stratégie l'action INFRA_UPDATE_RESTART, mais l'autorisation est définie sur Indiquer une autorisation.
  • system_all octroie des privilèges d'administration système complets, y compris l'utilisation sans restriction de sudo. Vous accordez aux membres de cette stratégie l'action INFRA_FULL. Aucun groupe de stratégies n'a été créé avec cette action.

Concernant les ressources pour lesquelles vous avez configuré la stratégie system_diag, vous avez marqué comme préapprouvées toutes les activités d'administration autorisées par l'action. Vous avez indiqué que les membres du groupe PRE_APPROVED_POLICY_USERS disposaient d'un accès permettant d'utiliser system_diag avec le statut Préapprouvé dans la location.

Supposons ensuite qu'un opérateur Oracle appartenant au groupe PRE_APPROVED_POLICY_USERS demande l'accès à un serveur, mais avec l'action INFRA_UPDATE_RESTART car une action de maintenance requiert un redémarrage. L'opérateur Oracle doit toujours demander l'accès pour l'action permettant à un opérateur de redémarrer le système dans le cadre d'une action de maintenance. Vous accordez l'accès à la stratégie system_main, mais toutes les actions qui nécessitent cet accès doivent faire l'objet d'une approbation.

A tout moment, vous pouvez, en tant qu'administrateur, révoquer l'accès à l'opérateur, quelle que soit l'approbation ou l'appartenance à un groupe existante. Si vous supprimez un opérateur Oracle d'un groupe, il n'a plus accès au système.

Audit de l'accès d'opérateur

Découvrez comment les journaux sont capturés et comment vous pouvez auditer les activités d'opérateur.

Remarque

Les journaux d'audit sont collectés à l'aide du sous-système auditd du noyau Linux. Pour ajouter des règles Operator Access Control afin de collecter les journaux, vous devez redémarrer le système Exadata après la première affectation d'un contrôle d'opérateur. Vous n'avez pas besoin de redémarrer le système Exadata lors des affectations suivantes.

Etendue des journaux d'audit capturés

Le service de contrôle d'accès d'opérateur consigne les actions effectuées par l'opérateur sur un système contrôlé. Les journaux sont capturés pour deux grandes catégories.
  • Journaux des événements de cycle de vie
  • Journaux de commandes

La première concerne les événements de cycle de vie et la seconde les commandes exécutées par l'opérateur sur les hôtes cible.

Journaux des événements de cycle de vie

Le service Operator Access Control capture les événements de connexion et de déconnexion uniquement pour les utilisateurs autorisés du service Operator Access Control et ne capture pas les événements de connexion d'automatisation.

Journaux de commandes

Le service Operator Access Control capture toutes les commandes exécutées par les utilisateurs autorisés sur un shell. Il capture l'entrée de commande sans occultation et ne capture pas la sortie de commande. Il capture également toutes les commandes shell exécutées à l'aide de scripts shell.

Par exemple, le service Operator Access Control capture la commande suivante : 
netstat -an | grep 8080
En outre, les commandes exécutées à l'aide du script shell searchlog.sh dans ce cas sont également capturées.
./searchlog.sh –process "cellservice"
Les journaux de commandes incluent les commandes exécutées par un utilisateur même après une commande su. Par exemple, après la connexion, si l'utilisateur autorisé auth_user_123 exécute les commandes suivantes, le service Operator Access Control les capture toutes.
su - celladmin
tail -n 10 /var/log/messages

Enregistrement de frappe

En outre, les journaux de commandes peuvent également être capturés sous la forme d'un journal de frappe. L'enregistrement de frappe capture toutes les séquences de touches utilisées par les opérateurs sur leurs ordinateurs. L'enregistrement de frappe n'a pas beaucoup d'applications pratiques, mais est parfois requis par les exigences réglementaires.

Eléments non consignés

Le service Operator Access Control ne consigne pas les commandes d'automatisation ni les événements de cycle de vie. Bien que ce service journalise toutes les commandes envoyées directement au shell ou via l'appel de scripts shell, il ne journalise pas les actions effectuées par les exécutables binaires. Par conséquent, si un opérateur se connecte au serveur de cellules, puis entre dans un shell cellcli, les journaux capturent uniquement les commandes de shell cellcli. Le service Operator Access Control ne consigne pas les commandes exécutées dans cellcli.

Format des journaux d'audit

Les journaux d'audit sont formatés en tant que texte JSON. Les journaux d'audit sont classés en deux parties : données brutes et données interprétées. Les données brutes ne sont pas compréhensibles en dehors du contexte de l'ordinateur Linux où le journal a été capturé. Par exemple, les données brutes ne font pas référence aux noms utilisateur Linux, mais à des identificateurs internes. La mise en correspondance de l'identificateur avec l'utilisateur ne peut être effectuée que sur l'ordinateur Linux où le journal a été capturé.

Outre l'interprétation, le format définit également le contexte en fournissant dans les journaux l'ID de demande d'accès.

Journaux des événements de cycle de vie

Les deux exemples suivants montrent le format du journal d'audit pour les événements de cycle de vie. Les exemples présentent un événement de connexion et un événement de déconnexion. Le nom utilisateur employé pour la connexion est "USERNAME".

Exemple 1-2 Journal des événements de connexion

{
"layer": "CPS",
"req_auth_id": "1",
"srchost": "dhcp-10-191-235-63.vpn.example.com",
"res": "success'",
"desthost": "10.191.235.63",
"pid": "89736",
"tty": "/dev/pts/2",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:22 2020",
"raw_data": "type=USER_LOGIN msg=audit(10/29/2020 03:20:22.091:10777414) : pid=89736 uid=root auid=USERNAME ses=75141 msg='op=login id=USERNAME exe=/usr/sbin/sshd hostname=dhcp-10-191-235-63.vpn.example.com addr=10.191.235.63 terminal=/dev/pts/2 res=success' \n",
"event": "login",
"loginid": "USERNAME"
}

Exemple 1-3 Journal des événements de déconnexion

{
"layer": "CPS",
"req_auth_id": "1",
"srchost": "dhcp-10-191-235-63.vpn.example.com",
"res": "success'",
"desthost": "10.191.235.63",
"pid": "90456",
"tty": "ssh",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:35 2020",
"raw_data": "type=USER_LOGOUT msg=audit(10/29/2020 03:20:35.855:10777438) : pid=90456 uid=root auid=USERNAME ses=75142 msg='op=login id=USERNAME exe=/usr/sbin/sshd hostname=dhcp-10-191-235-63.vpn.example.com addr=10.191.235.63 terminal=ssh res=success' \n",
"event": "logout",
"loginid": "USERNAME"
}

Journaux de commandes

Les journaux de commandes sont plus détaillés. Ils fournissent des informations sur la commande, ses paramètres et l'utilisateur réel l'ayant exécutée. Les commandes présentent également une hiérarchie : pour l'exécution d'un script shell, bash -c sera tout d'abord consigné, puis les commandes de script.

Exemple 1-4 Exécution de commande

{
"layer": "CPS",
"req_auth_id": "1",
"title": "ls\u0000/",
"raw_data": "type=PROCTITLE msg=audit(10/29/2020 03:20:29.418:10777424) : proctitle=ls / \ntype=PATH msg=audit(10/29/2020 03:20:29.418:10777424) : item=1 name=/lib64/ld-linux-x86-64.so.2 inode=1182648 dev=f9:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL \ntype=PATH msg=audit(10/29/2020 03:20:29.418:10777424) : item=0 name=/usr/bin/ls inode=1189225 dev=f9:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL \ntype=CWD msg=audit(10/29/2020 03:20:29.418:10777424) : cwd=/ \ntype=EXECVE msg=audit(10/29/2020 03:20:29.418:10777424) : argc=2 a0=ls a1=/ \ntype=SYSCALL msg=audit(10/29/2020 03:20:29.418:10777424) : arch=x86_64 syscall=execve success=yes exit=0 a0=0xfff6d0 a1=0xff42d0 a2=0xfff960 a3=0x7ffc1dd337e0 items=2 ppid=90474 pid=90764 auid=USERNAME uid=USERNAME gid=USERNAMg euid=USERNAME suid=USERNAME fsuid=USERNAME egid=USERNAMg sgid=USERNAMg fsgid=USERNAMg tty=pts2 ses=75141 comm=ls exe=/usr/bin/ls key=(null) \n",
"args": [],
"rec_id": "10777424",
"tty": "pts2",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:29 2020",
"loginid": "USERNAME"
}

Le titre du champ indique la commande exécutée. Les données brutes fournissent beaucoup plus d'informations.

Fréquence de collecte

Le service Operator Access Control collecte les journaux au fur et à mesure des événements, indique un délai et propage régulièrement les journaux vers le service de journalisation. Il tente de propager les journaux toutes les 30 secondes.

Accès aux journaux d'audit

Vous pouvez accéder aux journaux d'audit via le service de journalisation. Pour plus d'informations, reportez-vous à Présentation de Logging.

Le format JSON indiqué dans la section 2 est disponible dans le service de journalisation. Utilisez votre location pour accéder au service de journalisation. Les journaux sont publiés dans le compartiment où le contrôle d'opérateur a été créé. Les journaux sont balisés avec le contrôle d'opérateur.

Stratégies de conservation des journaux d'audit

Les journaux d'audit sont conservés dans la location de l'utilisateur. Par conséquent, le service Operator Access Control ne contrôle pas la durée de vie des journaux d'audit. Vous pouvez contrôler la durée de la période de conservation. Toutefois, si ce service n'a pas pu propager les journaux vers la location de l'utilisateur, il tente de les conserver autant que le permettent les configurations Exadata. La période de conservation est considérable : au moins plusieurs jours.

Transmission des journaux d'audit Operator Access Control aux systèmes SIEM

Vous pouvez choisir de transmettre les journaux d'audit Operator Access Control directement d'Exadata Cloud@Customer aux systèmes de gestion des informations et des événements de sécurité (SIEM) de votre centre de données.

Pour améliorer la gestion de la sécurité, vous pouvez transmettre les journaux d'audit au service OCI Logging et aux systèmes SIEM de vos centres de données. Syslog sur TCP est utilisé pour la transmission des journaux d'audit aux systèmes SIEM.

Rubrique parent : Présentation d'Oracle Operator Access Control

Déploiement d'un serveur Syslog dans le centre de données

Pour recevoir des journaux d'audit d'Exadata Cloud@Customer, déployez un serveur Syslog dans votre centre de données. Vous pouvez utiliser le serveur Syslog de votre choix. La plupart des systèmes Linux sont fournis avec rsyslog.

Vous pouvez transmettre les journaux d'audit vers un seul serveur Syslog pour chaque système Exadata Cloud@Customer cible. Oracle prend uniquement en charge la communication sécurisée et utilise TLS pour assurer la sécurité de la transmission. Le serveur de plan de contrôle se connecte au serveur Syslog et fournit tous les journaux d'audit via TCP sécurisé. Pour établir la sécurisation entre le serveur de plan de contrôle et le serveur Syslog, utilisez un fichier de certificat d'autorité de certification de serveur Syslog au format PEM. L'extension de fichier doit être .pem, .cer ou .crt. Pour plus d'informations sur la configuration, reportez-vous à Exemple de configuration de serveur Syslog.

Le journal contient des éléments déjà décrits dans le chapitre Gestion et recherche de journaux à l'aide d'Operator Access Control. Le format doit être compatible avec les analyseurs de journal syslog et audit-d. Reportez-vous à l'exemple de journal d'audit.

L'envoi des journaux d'audit aux systèmes SIEM s'effectue au mieux des possibilités. Le serveur de plan de contrôle effectue plusieurs tentatives d'envoi des journaux en cas de panne réseau, mais des paquets peuvent être supprimés automatiquement du fait de seuils. Dans ce cas, les journaux affichés via le service OCI Logging sont la référence.

Remarque

Pour transmettre des journaux d'audit, vous devez affecter indéfiniment (Toujours affecté) au moins un contrôle d'opérateur au système Exadata Cloud@Customer.

Exemple de configuration de serveur Syslog

Pour savoir comment configurer le serveur Syslog de votre choix, utilisez cet exemple.

Avant de tenter de configurer le serveur Syslog, vous devez être prêt à effectuer les opérations suivantes :
  1. Ouverture d'un port réseau pour la réception de journaux distants
    Remarque

    Les règles sortantes du serveur Syslog doivent être ouvertes pour le port Syslog. Par exemple, si le port 6514 est utilisé pour Syslog, la règle de sécurité sortante doit être en place afin d'autoriser le trafic à atteindre Syslog à partir du cluster de machines virtuelles Autonomous.
  2. Activation du cryptage sur le serveur Syslog pour la communication à distance
  3. (Facultatif) Génération et transfert d'un certificat racine pour une communication sécurisée
Remarque

L'exemple ci-dessous permet de configurer un serveur rsyslog (v 8.24) sur un ordinateur avec Oracle Linux 7. La configuration est généralement disponible dans le fichier /etc/rsyslog.conf. Seules les sections pertinentes sont traitées dans cet exemple.

Dans cet exemple, le port d'écoute est 10514. Plusieurs sources sont disponibles sur Internet pour vous aider à crypter le trafic Syslog. La documentation sur le cryptage du trafic Syslog avec TLS (SSL) [version abrégée] - rsyslog 8.18.0.master constitue une bonne référence. 

# rsyslog configuration file (8.24.0 - /etc/rsyslog.conf - Oracle Linux 7)
# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# If you experience problems, then see http://www.rsyslog.com/doc/troubleshoot.html

#### MODULES $ModLoad imuxsock # provides support for local system logging (e.g. via logger command)# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 10514

...# certificate files
$DefaultNetstreamDriverCAFile /var/gnutls1/ca.pem
$DefaultNetstreamDriverCertFile /var/gnutls1/cert.pem
$DefaultNetstreamDriverKeyFile /var/gnutls1/key.pem$ModLoad imtcp # load TCP listener$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode
$InputTCPServerStreamDriverAuthMode anon # client is NOT authenticated
#$InputTCPServerStreamDriverAuthMode x509/name # client is NOT authenticated
$InputTCPServerRun 10514 # start up listener at port 10514
...

Test de la connectivité entre le serveur de plan de contrôle et le serveur Syslog

Assurez-vous que vous avez fourni une adresse IP ou un nom d'hôte valide pour le serveur Syslog.

Le serveur Syslog doit pouvoir recevoir des journaux d'un client Syslog et être accessible à partir d'Exadata Cloud@Customer. Pour vérifier votre configuration, suivez cette procédure.
  1. Pour vérifier que le serveur Syslog peut recevoir des journaux, exécutez la commande nc vers le serveur et le port Syslog, à partir de n'importe quel hôte du réseau ayant accès au serveur Syslog.
    nc syslog server host syslog port
  2. Pour vous assurer que le chemin entre Exadata Cloud@Customer et le serveur Syslog est valide, envoyez une commande ping à l'adresse IP du serveur de plan de contrôle Exadata Cloud@Customer. Pour obtenir l'adresse IP du serveur de plan de contrôle, contactez l'administrateur réseau.

Exemples de journaux d'audit

En tant qu'administrateur, consultez des exemples de journaux d'audit reçus du serveur de plan de contrôle en toute sécurité.

Lorsque vous transmettez des journaux au serveur Syslog, de nombreux en-têtes et le formatage JSON sont omis. Les exemples suivants illustrent la nature des données expédiées via Syslog.

Exemple 1-5 1

Apr 12 07:38:22 scaqar05dv0511m opctl: type=USER_LOGIN msg=audit(04/12/2021 07:38:05.752:1742859) : 
pid=65327 
uid=root 
auid=830916abb78e4157b9e45b641e34fcf6 ses=32770 
msg='op=login id=830916abb78e4157b9e45b641e34fcf6 
exe=/usr/sbin/sshd 
hostname=localhost.localdomain 
addr=127.0.0.1 
terminal=/dev/pts/3 res=success'

Exemple 1-6 2

Apr 12 07:38:22 scaqar05dv0511m opctl: type=USER_LOGOUT msg=audit(04/12/2021 07:38:08.802:1742867) : 
pid=65327 
uid=root 
auid=830916abb78e4157b9e45b641e34fcf6 
ses=32770 
msg='op=login 
id=830916abb78e4157b9e45b641e34fcf6 exe=/usr/sbin/sshd 
hostname=? 
addr=? 
terminal=/dev/pts/3 res=success'