Exadata Cloud Infrastructure est géré conjointement par le client et Oracle, et est divisé en deux domaines de responsabilité.

Les clients contrôlent et surveillent l'accès aux services client, y compris l'accès réseau à leurs machines virtuelles (via les réseaux cloud virtuels OCI et les listes de sécurité OCI), l'authentification pour accéder à la machine virtuelle et l'authentification pour accéder aux bases de données exécutées dans les machines virtuelles. Oracle contrôle et surveille l'accès aux composants d'infrastructure gérée par Oracle et la sécurité des serveurs physiques. Le personnel d'Oracle n'est pas autorisé à accéder aux services client, machines virtuelles et bases de données client incluses, sauf lorsque les clients ne peuvent pas accéder à la machine virtuelle client.

Les clients accèdent aux bases de données Oracle exécutées sur Exadata Cloud Infrastructure via des réseaux cloud virtuels client et de sauvegarde vers les bases de données exécutées dans la machine virtuelle client, à l'aide de méthodes de connexion de base de données Oracle standard, telles qu'Oracle Net sur le port 1521. Les clients accèdent à la machine virtuelle exécutant les bases de données Oracle via des méthodes Oracle Linux standard, telles que le protocole SSH basé sur un jeton sur le port 22.

Fonctionnalités de sécurité offertes par Exadata Cloud Infrastructure.

• Sécurité physique d'Oracle Cloud

  Les centres de données Oracle Cloud respectent les normes de l'Uptime Institute et de la Telecommunications Industry Association (TIA) ANSI/TIA-942-A de niveau 3 (99,982 % de disponibilité) ou 4 (99,995 % de disponibilité), et suivent une méthodologie de redondance N2 ("N" comme "Need", c'est-à-dire "besoin") pour les opérations d'équipement critiques. Les centres de données hébergeant les services Oracle Cloud Infrastructure utilisent des sources d'alimentation redondantes et possèdent des générateurs de secours en cas de panne électrique généralisée. Les salles des serveurs sont étroitement surveillées au niveau de la température et de l'humidité de l'air, et disposent de systèmes d'extinction des incendies. Le personnel des centres de données est entraîné aux procédures de réponse aux incidents et d'escalade des incidents pour gérer les événements impactant la disponibilité et la sécurité susceptibles de survenir. Pour plus d'informations, reportez-vous au: guide de la sécurité d'Oracle Cloud Infrastructure. Pour plus d'informations sur la conformité des centres de données Oracle Cloud Infrastructure, reportez-vous à Conformité d'Oracle Cloud. Voir également : Pratiques de sécurité d'entreprise Oracle : Sécurité des données : Contrôles physiques et environnementaux.

• Contrôles d'accès au centre de données Oracle

  Pour fournir des systèmes sécurisés, les protocoles d'accès Oracle aux centres de données physiques incluent les éléments suivants :

  • L'accès physique aux installations des centres de données est limité à certains employés d'Oracle, sous-traitants et visiteurs autorisés.
  • Les employés d'Oracle, les sous-traitants et les visiteurs autorisés reçoivent des cartes d'identification qui doivent être portées sur les sites Oracle.
  • Les visiteurs doivent signer un registre, être accompagnés et/ou surveillés lorsqu'ils se trouvent sur les sites Oracle, et/ou sont tenus de respecter les conditions d'un accord de confidentialité avec Oracle.
  • La sécurité surveille la possession de clés/de cartes d'accès et la capacité d'accéder aux installations. Le personnel quittant Oracle doit restituer les clés/cartes et celles-ci sont désactivées au terme du contrat.
  • La sécurité autorise toutes les réparations et modifications effectuées sur les barrières de sécurité physiques ou les contrôles d'entrée sur les sites de service.
  • Oracle emploie à la fois des agents de sécurité présents sur site 24h/24 et 7j/7 et des agents de patrouille, selon le niveau de risque/protection de l'installation. Dans tous les cas, les officiers sont responsables des patrouilles, des réponses aux alertes et de l'enregistrement des incidents de sécurité.
  • Oracle a mis en place des systèmes électroniques de contrôle des accès gérés de manière centralisée avec fonction intégrée d'alarme de détection d'intrusion. Les journaux d'accès sont conservés pendant au moins six mois. En outre, la période de conservation des enregistrements de vidéosurveillance varie entre 30 et 90 jours au minimum, selon les fonctions et le niveau de risque de l'installation.

  Pour plus de détails sur les contrôles d'accès aux sites Oracle, reportez-vous à : Pratiques de sécurité d'entreprise Oracle : Oracle Access Control

• Isolement entre le client et l'hyperviseur

  L'hyperviseur est le logiciel qui gère les périphériques virtuels dans un environnement cloud, en se chargeant de la virtualisation des serveurs et des réseaux. Dans les environnements de virtualisation traditionnels, l'hyperviseur gère le trafic réseau, ce qui lui permet de circuler entre les instances de machine virtuelle, et entre instances de machine virtuelle et hôtes physiques. Cela ajoute une complexité et une surcharge de calcul considérables dans l'hyperviseur. Les simulations d'attaques de sécurité informatique, telles que les attaques d'échappement de machine virtuelle, ont mis en évidence le risque important qui peut découler de cette conception. Ces attaques exploitent la complexité de l'hyperviseur en permettant à un pirate informatique de "fractionner" une instance de machine virtuelle, d'accéder au système d'exploitation sous-jacent et de prendre le contrôle de l'hyperviseur. Le pirate peut alors accéder à d'autres hôtes, parfois sans être détecté. Oracle Cloud Infrastructure réduit ce risque en dissociant la virtualisation des réseaux de l'hyperviseur.

  Pour contrer les attaques potentielles, Oracle a implémenté une architecture axée sur la sécurité à l'aide de la virtualisation réseau isolée, élément fondamental de l'architecture de l'infrastructure Oracle Cloud. Cette architecture arrête les logiciels malveillants avec un SmartNIC personnalisé pour isoler et virtualiser le réseau. La virtualisation isolée des réseaux réduit les risques en limitant la surface d'exposition aux attaques. Même si un acteur malveillant réussit une attaque d'échappement de machine virtuelle sur un hôte unique, l'architecture virtuelle est conçue de sorte que l'acteur ne puisse pas atteindre les autres hôtes de l'infrastructure cloud. L'attaque est ainsi contenue sur un hôte. L'architecture de virtualisation réseau isolée sécurisée est implémentée dans chaque centre de données de chaque région. Chaque locataire Oracle Cloud Infrastructure bénéficie des avantages de cette architecture axée sur la sécurité.

  Figure 6-1 La virtualisation isolée des réseaux réduit les risques dans Oracle Generation 2 Cloud

  
  Description de la figure 6-1 La virtualisation isolée des réseaux réduit les risques dans Oracle Generation 2 Cloud
• Sécurité colocative

  Conformément à notre philosophie de sécurité "Défense renforcée", les instances colocatives possèdent une architecture d'isolement complète.

  Elle se compose de quatre grandes catégories, avec plusieurs caractéristiques importantes dans chaque catégorie.

  1. Mécanisme de contrôle d'accès
  2. Blocage des accès administrateur non autorisés
  3. Protection contre l'accès direct aux fichiers de données
  4. Isolement des ressources
  d

  Figure 6-2 Architecture d'isolement complète des instances colocatives

  
  Description de la figure 6-2 : Architecture d'isolement complète des environnements colocatifs

• Défense renforcée Exadata Cloud Infrastructure propose un certain nombre de contrôles afin de garantir la confidentialité, l'intégrité et la disponibilité dans l'ensemble du service.

  En premier lieu, Exadata Cloud Infrastructure est conçu à partir de l'image de système d'exploitation renforcée fournie par Exadata Database Machine (https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmsq/exadata-security-overview.html). Cela sécurise l'environnement d'exploitation central en limitant l'image d'installation aux packages logiciels requis, en désactivant les services inutiles et en implémentant des paramètres de configuration sécurisés dans l'ensemble du système.

  Les systèmes Exadata Cloud Infrastructure héritent non seulement de tous les points forts de la plate-forme aboutie d'Exadata Database Machine, mais, provisionnant des systèmes pour les clients, ils bénéficient également de choix de configuration par défaut sécurisés supplémentaires, implémentés dans les instances de service. Par exemple, tous les tablespaces de base de données exigent un cryptage transparent des données (TDE), l'application de mots de passe renforcés pour les superutilisateurs et les utilisateurs de la base de données initiale, et de meilleures règles d'audit et d'événement.

  Exadata Cloud Infrastructure représente par ailleurs une offre de service et de déploiement complète. Il est donc soumis à des audits externes standard tels que PCI, HIPAA et ISO27001. Ces exigences en matière d'audit externe imposent des fonctionnalités de service à valeur ajoutée supplémentaires telles que l'analyse antivirus, les alertes automatisées en cas de modification inattendue du système et les analyses de vulnérabilités quotidiennes pour tous les systèmes d'infrastructure gérés par Oracle du parc.

• Moindre privilège

  Les normes de codage Oracle Secure Coding exigent que les processus logiciels soient exécutés au niveau de privilège minimal pour implémenter leurs fonctionnalités.

  Chaque processus ou démon doit s'exécuter en tant qu'utilisateur normal sans privilège, sauf s'il peut prouver qu'un niveau de privilège supérieur est requis. Les vulnérabilités ou problèmes imprévus sont ainsi circonscrits à l'espace des utilisateurs sans privilège, et ne compromettent pas l'intégralité du système.

  Ce principe s'applique également aux membres de l'équipe des opérations Oracle qui utilisent des comptes nommés individuels pour accéder à Exadata Cloud Infrastructure à des fins de maintenance ou de dépannage. Ceux-ci n'utilisent l'accès à des niveaux de privilège plus élevés (qui est soumis à audit) pour résoudre un problème que si cela est nécessaire. La résolution de la plupart des problèmes est automatisée. Nous employons donc également le paradigme du moindre privilège en ne permettant aux opérateurs d'accéder à un système que si l'automatisation ne permet pas de résoudre un problème.

• Audit et responsabilité

  Si nécessaire, l'accès au système est autorisé, mais l'ensemble des accès et actions sont consignés et suivis afin de définir les responsabilités.

  Les journaux d'audit Exadata Cloud Infrastructure sont contrôlés par Oracle, et utilisés à des fins de conformité et de surveillance de la sécurité. Oracle peut partager les journaux d'audit pertinents avec les clients dans le respect des pratiques de réponse aux incidents Oracle et de l'accord de traitement de données Oracle.

  Les fonctionnalités d'audit sont fournies pour tous les composants d'infrastructure afin de garantir la capture de toutes les actions. Les clients peuvent également configurer l'audit pour leur configuration de base de données et de machine virtuelle invitée, et choisir de l'intégrer à d'autres systèmes d'audit d'entreprise.

• Automatisation des opérations cloud

  La suppression des opérations manuelles requises pour provisionner, tenir à jour, dépanner et configurer les systèmes, et leur appliquer des patches, permet de réduire les risques d'erreur.

• Image de système d'exploitation renforcée

  • Installation du nombre minimal de packages :

    Seuls les packages nécessaires pour une exécution efficace du système sont installés. L'installation d'un plus petit ensemble de packages permet de réduire la surface d'exposition aux attaques du système d'exploitation et de préserver la sécurisation du système.

  • Configuration sécurisée :

    De nombreux paramètres de configuration autres que ceux par défaut sont définis au cours de l'installation pour améliorer la posture de sécurité du système et de son contenu. Par exemple, entre autres restrictions similaires, SSH est configuré pour écouter uniquement certaines interfaces réseau et Sendmail pour accepter uniquement les connexions de l'hôte local.

  • Exécution des services nécessaires uniquement :

    Tous les services éventuellement installés sur le système, mais non requis pour un fonctionnement normal, sont désactivés par défaut. Par exemple, si le service NFS est souvent configuré par les clients à diverses fins applicatives, il est désactivé par défaut car il n'est pas requis pour les opérations de base de données normales. Les clients peuvent choisir de configurer des services en fonction de leurs besoins.

• Surface d'exposition aux attaques réduite

  Dans le cadre de l'image renforcée, la surface d'exposition aux attaques est réduite grâce à l'installation et à l'exécution des seuls logiciels requis pour fournir le service.

• Fonctionnalités de sécurité supplémentaires activées (mots de passe GRUB, initialisation sécurisée)

  • En s'appuyant sur les fonctionnalités d'image Exadata, ExaDB-D bénéficie des nombreuses fonctionnalités intégrées à l'image de base, telles que les mots de passe GRUB et l'initialisation sécurisée.
  • La personnalisation permet en outre aux clients d'améliorer encore davantage la posture de sécurité grâce à d'autres configurations.
• Méthodes d'accès sécurisé
  • Accès aux serveurs de base de données via SSH à l'aide de cryptages cryptographiques renforcés. Les cryptages faibles sont désactivés par défaut.
  • Accès aux bases de données via des connexions Oracle Net cryptées. Par défaut, les services sont accessibles à l'aide de canaux cryptés et un client Oracle Net configuré par défaut utilise des sessions cryptées.
  • Accès aux diagnostics via l'interface Web MS Exadata (HTTPS).
• Audit et journalisation
  • Par défaut, l'audit est activé pour les opérations d'administration. Les enregistrements d'audit sont communiqués aux systèmes internes OCI pour révision et alerte (si nécessaire) automatisées.

Plusieurs comptes utilisateur gèrent régulièrement les composants d'Exadata Cloud Infrastructure. Ces utilisateurs sont requis et ne peuvent pas être modifiés.

Sur toutes les machines ExaDB-D, Oracle utilise et recommande une connexion SSH basée sur un jeton.

Il existe trois classes d'utilisateurs :

• Utilisateurs par défaut : aucun privilège de connexion
  
• Utilisateurs par défaut disposant d'un accès à un shell restreint
  Ces utilisateurs permettent d'accomplir une tâche définie avec une connexion à un shell restreint. Ces utilisateurs ne doivent pas être enlevés car, dans ce cas, la tâche définie échouerait.
• Utilisateurs par défaut disposant de droits de connexion
  Ces utilisateurs dotés de privilèges permettent d'accomplir la plupart des tâches dans le système. Ces utilisateurs ne doivent jamais être modifiés ni supprimés car cela aurait un impact significatif sur le système en cours d'exécution.

Outre toutes les fonctionnalités Exadata décrites dans Fonctions de sécurité d'Oracle Exadata Database Machine, les paramètres de sécurité suivants sont également applicables aux instances Exadata Cloud Infrastructure.

• Déploiement de base de données personnalisé avec des paramètres autres que ceux par défaut.
  La commande host_access_control permet de configurer les paramètres de sécurité Exadata :

  • Implémentation de stratégies relatives au vieillissement et à la complexité des mots de passe
  • Définition de stratégies de verrouillage de compte et d'expiration de session
  • Restriction de l'accès root distant
  • Restriction de l'accès au réseau à certains comptes
  • Implémentation d'une bannière d'avertissement de connexion
• account-disable : désactive un compte utilisateur lorsque certaines conditions configurées sont remplies.
• pam-auth : paramètres PAM divers pour les modifications de mot de passe et l'authentification par mot de passe.
• rootssh : ajuste la valeur PermitRootLogin dans /etc/ssh/sshd_config, ce qui permet d'autoriser ou de refuser la connexion via SSH de l'utilisateur root.
  • Par défaut, PermitRootLogin est défini sur no.
  • "PermitRootLogin=without-password" est requis afin que l'automatisation du cloud puisse effectuer certaines opérations de gestion du cycle de vie. La désactivation de la connexion racine entraîne l'échec de cette fonctionnalité du service.
• session-limit : définit le paramètre * hard maxlogins dans /etc/security/limits.conf, qui est le nombre maximal de connexions pour tous les utilisateurs. Cette limite ne s'applique pas aux utilisateurs avec uid=0.

  Valeur par défaut : * hard maxlogins 10. Il s'agit de la valeur sécurisée recommandée.

• ssh-macs : indique les algorithmes MAC (code d'authentification de message) disponibles.
  • L'algorithme MAC est utilisé dans la version 2 du protocole pour la protection de l'intégrité des données.
  • Valeurs par défaut : hmac-sha1, hmac-sha2-256, hmac-sha2-512 pour le serveur et le client.
  • Valeurs sécurisées recommandées : hmac-sha2-256, hmac-sha2-512 pour le serveur et le client.
• password-aging : définit ou affiche le principe actuel de vieillissement des mots de passe pour les comptes utilisateur interactifs.
  • -M : nombre maximal de jours pendant lequel un mot de passe peut être utilisé.
  • -m : nombre minimal de jours autorisé entre les modifications de mot de passe.
  • -W : nombre de jours avant expiration d'un mot de passe où un avertissement est émis.
  • Valeurs par défaut : -M 99999, -m 0, -W 7.
  • --strict_compliance_only-M 60, -m 1, -W 7
  • Valeurs sécurisées recommandées : -M 60, -m 1, -W 7.

Liste des processus exécutés par défaut sur la machine virtuelle client, également appelée domU, ou sur la machine virtuelle invitée et le système d'exploitation invité.

• Agent de machine virtuelle Exadata Cloud Infrastructure :

  Agent cloud pour la gestion des opérations de cycle de vie de base de données.

  • S'exécute en tant qu'utilisateur opc
  • La table de processus indique qu'il s'exécute en tant que processus Java avec des noms jar - dbcs-agent-VersionNumber-SNAPSHOT.jar et dbcs-admin-VersionNumver-SNAPSHOT.jar.
• Agent Oracle Trace File Analyzer :

  Oracle Trace File Analyzer (TFA) fournit un certain nombre d'outils de diagnostic dans un seul et même package, ce qui facilite la collecte d'informations de diagnostic sur la base de données et le clusterware Oracle et, par conséquent, la résolution des problèmes avec le support technique Oracle.

  • S'exécute en tant qu'utilisateur root
  • S'exécute en tant que démon initd (/etc/init.d/init.tfa)
  • Les tables de processus affichent une application Java (oracle.rat.tfa.TFAMain)
  • S'exécute en tant qu'utilisateurs root et exawatch.
  • S'exécute en tant que script en arrière-plan, ExaWatcher.sh et tous ses processus enfant s'exécutent en tant que processus Perl.
  • La table de processus affiche plusieurs applications Perl. ExaWatcher :
• Base de données et GI (clusterware):
  • S'exécute en tant qu'utilisateurs dbmsvc et grid
  • La table de processus affiche les applications suivantes :
    • oraagent.bin, apx_* et ams_* en tant qu'utilisateur grid,
    • dbrsMain et les applications Java - derbyclient.jar, weblogic.Server, en tant qu'utilisateur oracle.
• Serveur de gestion (MS) :

  Fait partie du logiciel d'image Exadata pour la gestion et la surveillance des fonctions d'image.

  • S'exécute en tant que dbmadmin.
  • La table de processus indique qu'il s'exécute en tant que processus Java.

• Sécurité réseau de machine virtuelle invitée
  
• Exigences de conformité
  

Fonctionnalités de sécurité de base de données par défaut activées et utilisées :

• Le cryptage transparent des données est utilisé pour les tablespaces de base de données créés par les outils Oracle Database Cloud.
  • CDB$ROOT : le tablespace des utilisateurs est crypté.
  • Bases de données pluggables : tous les tablespaces sont cryptés.
  • Le mot de passe de portefeuille est fourni lors de la création de la base de données initiale. Vous pouvez le modifier à l'aide de dbaascli. Les clients doivent modifier régulièrement ce mot de passe.
• Utilisateurs dans la base de données.
  • Aucun utilisateur supplémentaire n'est créé dans la base de données.
  • Après la création de la base de données, tous ses utilisateurs sont verrouillés, à l'exception de SYS, SYSTEM et DBSNMP.
  • L'audit est activé pour les opérations suivantes :
    • DATABASE LINK
    • PUBLIC DATABASE LINK
    • PUBLIC SYNONYM
    • DROP ANY PROCEDURE
    • PROCEDURE
    • ALTER SYSTEM
    • TRIGGER
    • CREATE DATABASE LINK
    • ALTER DATABASE LINK
    • CREATE PROCEDURE
    • ALTER SYSTEM
    • CREATE TRIGGER
    • CREATE ANY TRIGGER
    • SELECT ANY DICTIONARY
    • Base de données VERSION_11_2 : EXEMPT REDACTION POLICY
    • DB VERSION_12_1 ou DB VERSION_12_2 : BECOME USER
    • Base de données VERSION_12_1 : SESSION
    • Le profil DBAASSECURE est créé et défini comme profil par défaut pour le compte utilisateur de base de données.

• Cryptage SQL*Net natif pour toutes les connexions réseau : les paramètres sqlnet.ora pertinents définis par défaut dans Exadata Cloud Infrastructure sont les suivants :

  • SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)

  • SQLNET.ENCRYPTION_SERVER = requested

  • SQLNET.CRYPTO_CHECKSUM_SERVER = accepted

  • SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)

• Protocole TCPS proposé pour la connexion réseau à la base de données sur le port 2484 (wallet configuré dans /var/opt/oracle/dbaas_acfs/grid/tcps_wallets). Les paramètres sqlnet.ora pertinents définis dans Exadata Cloud Infrastructure par défaut sont les suivants :

  • SSL_CIPHER_SUITES = (SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
    SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384)

  • WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets)))

  • SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS = TRUE

  • SSL_VERSION = 1.2

• Inscription de processus d'écoute distant : les processus d'écoute sont exécutés à partir du répertoire de base GI. Exadata Cloud Infrastructure déploie la version de Grid Infrastructure indiquée dans le document de support technique Oracle 2333222.1 (Exadata Cloud Service Software Versions). La configuration par défaut Exadata Cloud Infrastructure inclut le paramètre listener.ora VALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNET associé à REMOTE_REGISTRATION_ADDRESS_<SCANLISTENER>=<value> pour restreindre les inscriptions de processus d'écoute distant à des fins de sécurité.
• Intégration OCI Vault : la clé de cryptage TDE peut être stockée dans OCI Vault (système de gestion des clés). Pour plus d'informations et d'instructions sur la configuration des principaux, des coffres, etc., reportez-vous à Clés gérées par le client dans Exadata Cloud Infrastructure. Les types de coffre privé et partagé sont pris en charge pour l'intégration d'OCI Vault à Exadata Cloud Infrastructure. L'authentification utilisateur de base de données n'est pas intégrée à OCI Vault.

Sauvegardes de système d'exploitation/de machine virtuelle :

Oracle effectue une sauvegarde complète de la machine virtuelle invitée chaque semaine et conserve des copies de sauvegarde. Ces sauvegardes sont des clichés de disque complets de la machine virtuelle invitée (systèmes de fichiers de système d'exploitation locaux, et non groupes de disques ASM résidant sur le stockage Exadata). Cette sauvegarde est déclenchée à une heure prédéfinie chaque semaine. Les sauvegardes sont stockées localement dans Dom0. Les clients peuvent demander à Oracle de restaurer l'image de machine virtuelle invitée à partir de la sauvegarde la plus récente en enregistrant une demande d'assistance My Oracle Support (MOS). Oracle ne peut pas restaurer des fichiers spécifiques à partir de la sauvegarde d'image. Les clients doivent effectuer des sauvegardes au niveau des fichiers dans la machine virtuelle invitée s'ils ont besoin d'effectuer des restaurations de fichier unique.

Sauvegardes de base de données gérée :

• Sauvegarde complète hebdomadaire (niveau 0)
• Sauvegarde incrémentielle non simultanée quotidienne (niveau 1) sur un cycle de sept jours
• Sauvegardes automatiques quotidiennes à une heure spécifique définie lors du processus de création du déploiement de base de données

La période de conservation des sauvegardes varie de 30 jours (sur Object Storage) à 7 jours (sur le stockage local).

Cryptage :

• Object Storage et stockage local : cryptage de toutes les sauvegardes sur le stockage cloud
• Object Storage uniquement : cryptage de toutes les sauvegardes sur le stockage cloud

Toutes les sauvegardes peuvent être configurées via l'interface utilisateur CP ou l'API CP.

Toutes les sauvegardes sont cryptées à l'aide de la même clé maître que pour le cryptage transparent des données de portefeuille.

Seuls les outils automatisés sont autorisés à accéder aux machines virtuelles invitées à des fins d'automatisation du cycle de vie.

Prenons un cas d'emploi spécifique : impossible de démarrer la machine virtuelle invitée. Dans ce cas, les clients doivent accorder un droit d'accès à la machine virtuelle invitée à des fins de récupération. Les détails de traitement de ce scénario sont décrits dans la section "Workflows d'exception" du document Contrôles de sécurité Exadata Cloud Service.

Les clients contrôlent et surveillent l'accès aux services client, y compris l'accès réseau à leurs machines virtuelles invitées (via des VLAN de couche 2 et des pare-feu implémentés dans la machine virtuelle invitée), l'authentification pour accéder à la machine virtuelle invitée et l'authentification pour accéder aux bases de données exécutées dans les machines virtuelles invitées. Oracle contrôle et surveille l'accès aux composants d'infrastructure gérés par Oracle. Le personnel d'Oracle n'est pas autorisé à accéder aux services client, y compris les bases de données et les machines virtuelles invitées.

Informations d'identification personnelle Ces informations sont considérées comme confidentielles et sensibles. Elles doivent être protégées afin d'empêcher toute utilisation non autorisée, à des fins de respect de la réglementation, de responsabilité financière et de préservation de la réputation personnelle.

Vous devez configurer un ensemble de règles explicites pour empêcher l'affichage d'informations d'identification personnelle dans vos données.

Les règles Application Performance Monitoring par défaut masquent les informations d'identification personnelle dans les URL en reconnaissant les valeurs monétaires, les numéros de compte bancaire et les dates. Toutefois, les règles par défaut ne détectent que les informations d'identification personnelle évidentes et ne sont pas exhaustives. Vous devez évaluer les règles par défaut et les configurer davantage afin de vous assurer que des rapports appropriés sont générés dans votre environnement et de garantir qu'aucune information d'identification personnelle ne s'affiche dans vos données.

Pour plus d'informations, reportez-vous aux sections Hide Personally Identifiable Information et Security and Personally Identifiable Information.

Conservation de sauvegarde

Lorsque la fonctionnalité de sauvegarde automatique est activée, le service crée des sauvegardes incrémentielles quotidiennes de la base de données dans Object Storage. La première sauvegarde créée est une sauvegarde de niveau 0. Ensuite, des sauvegardes de niveau 1 sont créées chaque jour jusqu'au week-end suivant. Chaque week-end, le cycle se répète, en commençant par une nouvelle sauvegarde de niveau 0.

Si vous choisissez d'activer les sauvegardes automatiques, vous pouvez sélectionner l'une des périodes de conservation prédéfinies suivantes : 7 jours, 15 jours, 30 jours, 45 jours ou 60 jours. Le système supprime automatiquement les sauvegardes incrémentielles à la fin de la période de conservation choisie.

Pour plus d'informations, reportez-vous à Gestion de la sauvegarde et de la récupération de base de données sur Oracle Exadata Database Service on Dedicated Infrastructure.

Période de conservation du journal d'audit

Le service OCI Audit fournit les enregistrements des opérations d'API effectuées sur les services pris en charge sous la forme d'une liste d'événements de journal. Par défaut, les enregistrements du service Audit sont conservés pendant 365 jours.

Pour plus d'informations, reportez-vous à Durée de conservation du journal d'audit.

Conservation de journal de service

Les services Oracle Cloud Infrastructure, tels qu'API Gateway, Events, Functions, Load Balancing, Object Storage et les journaux de flux de réseau cloud virtuel, émettent des journaux de service. Chacun de ces services pris en charge dispose d'une ressource de journaux qui vous permet d'activer ou de désactiver la journalisation pour le service en question. Par défaut, les journaux sont conservés pendant 1 mois, mais la période peut être définie sur 6 mois au maximum.

Les groupes de journaux peuvent être utilisés pour limiter l'accès aux journaux sensibles générés par les services à l'aide de la stratégie IAM. Vous n'avez pas besoin de vous appuyer sur des hiérarchies de compartiments complexes pour sécuriser vos journaux. Par exemple, supposons que le groupe de journaux par défaut dans un même compartiment est l'emplacement où vous stockez les journaux pour l'ensemble de la location. Vous accordez l'accès au compartiment aux administrateurs de journaux avec la stratégie IAM, comme vous le feriez en temps normal. Toutefois, supposons que certains projets contiennent des informations d'identification personnelle et que seul un groupe donné d'administrateurs de journaux peut consulter ces journaux. Les groupes de journaux vous permettent de placer les journaux contenant des informations d'identification personnelle dans un groupe de journaux distinct, puis d'utiliser la stratégie IAM pour en limiter l'accès à certains administrateurs de journaux.

Pour plus d'informations, reportez-vous à Journaux de service et à Gestion des journaux et des groupes de journaux.

Certains problèmes ne peuvent être résolus que par la connexion d'Oracle à la machine virtuelle invitée du client.

Voici les situations dans lesquelles l'accès à la machine virtuelle invitée du client est requis, ainsi que les procédures recommandées pour accéder à cette machine virtuelle :

1. Situations dans lesquelles la base de données de départ n'est pas encore créée et le client n'a pas encore d'accès SSH à sa machine virtuelle invitée.Par exemple : demande de service ouverte par le client pour résoudre les problèmes qui l'empêchent de créer une base de données de départ. Dans ce cas, le client n'a jamais eu accès à la machine virtuelle invitée et aucune base de données n'a encore été créée. Par conséquent, aucune donnée client n'existe dans la machine virtuelle invitée.

   Conformément à la stratégie de sécurité associée au service ExaDB-D, le personnel d'Oracle ne peut pas accéder à la machine virtuelle invitée du client sans autorisation explicite de ce dernier. Pour se conformer à cette stratégie, Oracle exige l'obtention de l'autorisation du client pour accéder à la machine virtuelle invitée en posant la question suivante.

   "Afin qu'Oracle puisse résoudre le problème décrit dans cette demande de service, nous avons besoin de l'autorisation explicite du client nous permettant de nous connecter à sa machine virtuelle invitée. En nous autorisant explicitement à accéder à la machine virtuelle invitée, vous confirmez qu'aucune donnée confidentielle n'est stockée dans la machine virtuelle invitée du client ou dans les bases de données associées, et que l'équipe de sécurité du client autorise Oracle à accéder à la machine virtuelle invitée du client afin qu'Oracle puisse contribuer à résoudre ce problème. Ai-je votre autorisation explicite d'accéder à la machine virtuelle invitée ?"

   Après une réponse affirmative du client, le personnel du support technique Oracle peut se connecter à la machine virtuelle invitée du client pour résoudre le problème.

2. Situations dans lesquelles un certain nombre de bases de données existent dans le système client et le client a accès à la machine virtuelle invitée, mais le support technique doit se connecter à cette machine virtuelle pour résoudre l'un des nombreux problèmes

   Nous avons rencontré (les noeuds ne démarrent pas en raison de modifications sur la machine virtuelle invitée, par exemple des montages inexistants dans fstab, l'exécution de fsck, la modification de Hugepage / sysctl conf ou la sauvegarde lvm n'a pas abouti, fstab contient des entrées incorrectes pour les montages inexistants, le client a modifié les configurations sshd ou les droits d'accès dans le fichier /etc/ssh/sshd_config, etc.) ou simplement parce que le client veut qu'Oracle l'aide à résoudre le problème qu'il rencontre.

   Cette situation est plus sérieuse que la première car des données confidentielles peuvent être présentes dans la base de données ou le système de fichiers de la machine virtuelle invitée du client. Dans ce cas, notre personnel de support technique devra demander au client d'ouvrir une nouvelle demande de service explicite spécifiquement pour obtenir cette autorisation avec le titre et le contenu de demande de service suivants.

   Conformément à la stratégie de sécurité associée au service ExaDB-D, le personnel d'Oracle ne peut pas accéder à la machine virtuelle invitée du client sans autorisation explicite de ce dernier. Pour qu'Oracle se conforme à cette stratégie, nous devons vous demander d'ouvrir une nouvelle demande de service formulée exactement comme ci-dessous pour accorder à Oracle l'autorisation explicite d'accéder à la machine virtuelle invitée. Toute modification apportée à la formulation ci-dessous peut retarder la résolution de votre demande de service.

   Titre de la nouvelle demande de service : Demande de service accordant à Oracle l'autorisation explicite d'accéder à domU sur ExaDB-C@C avec le numéro de série AK AK99999999

   Contenu de la nouvelle demande de service : Nous ouvrons cette demande de service pour accorder explicitement à Oracle l'autorisation d'accéder à notre DomU afin que le support technique nous aide à résoudre le problème décrit dans la demande de service numéro 1-xxxxxxxx.

   Nous reconnaissons qu'en fournissant cette autorisation, nous comprenons qu'Oracle aura accès à TOUS LES FICHIERS présents dans DomU et convenons qu'aucun fichier

   confidentiel n'est stocké dans les systèmes de fichiers de DomU. En outre, nous convenons également que l'équipe de sécurité du client a autorisé Oracle à accéder à DomU pour le client

   afin de résoudre le problème décrit dans la demande de service ci-dessus.

   Après une réponse affirmative du client dans la demande de service ci-dessus, le personnel du support technique Oracle peut se connecter à la machine virtuelle invitée du client pour résoudre le problème.

Liste des responsabilités de l'équipe des opérations Oracle Cloud et des responsabilités du client pour diverses opérations par composant.

• Intégration KMS (clés HSM)
  Oracle Exadata Database Service on Dedicated Infrastructure s'intègre au service OCI Vault afin de protéger les données inactives de ses bases de données. Les utilisateurs ont désormais le contrôle nécessaire pour créer et gérer les clés maître TDE qui protègent vos bases de données Exadata dans OCI Vault.
• Utilisation d'algorithmes de cryptage autres que ceux par défaut pour le cryptage de tablespace TDE