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 à leurs services, y compris l'accès réseau à leurs machines virtuelles (au moyen des réseaux en nuage virtuels OCI et des listes de sécurité OCI), l'authentification pour accéder à la machine virtuelle et l'authentification pour accéder aux bases de données s'exécutant 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 du client, y compris les MV et les bases de données du client, sauf lorsque les clients ne sont pas en mesure d'accéder à leur MV.

Les clients accèdent aux bases de données Oracle s'exécutant sur Exadata Cloud Infrastructure au moyen de réseaux en nuage virtuels de client et de sauvegarde pour les bases de données s'exécutant dans la machine virtuelle du client à l'aide de méthodes de connexion standard à la base de données Oracle, telles qu'Oracle Net sur le port 1521. Le client peut accéder à la MV exécutant les bases de données Oracle au moyen de méthodes Oracle Linux standard, telles que la connexion SSH par jeton sur le port 22.

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

• Sécurité physique d'Oracle Cloud

  Les centres de données Oracle Cloud s'alignent sur les normes ANSI/TIA-942-A de niveau 3 (disponibilité de 99,982 %) ou de niveau 4 (disponibilité de 99,995 %) de l'Uptime Institute and Telecommunications Industry Association (TIA) et suivent une méthodologie de redondance N2 ("N" correspondant au besoin) pour le fonctionnement des équipements critiques. Les centres de données hébergeant les services Oracle Cloud Infrastructure utilisent des sources d'alimentation redondantes et disposent de générateurs de secours en cas de panne électrique généralisée. La température et l'humidité de l'air des salles de serveurs sont étroitement surveillées et des systèmes d'extinction d'incendie sont en place. Le personnel du centre de données est formé aux procédures de réponse aux incidents et d'escalade pour faire face aux événements de sécurité et de disponibilité qui peuvent survenir. Pour plus d'informations, voir : Guide sur la sécurité d'Oracle Cloud Infrastructure. Pour plus de détails sur la conformité du centre de données pour Oracle Cloud Infrastructure, voir Conformité pour Oracle Cloud. Voir aussi : Pratiques de sécurité d'entreprise d'Oracle : Sécurité des données : Contrôles physiques et environnementaux.

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

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

  • L'accès physique aux installations des centres de données est limité à certains employés d'Oracle, aux sous-traitants et aux visiteurs autorisés.
  • Les employés d'Oracle, les sous-traitants et les visiteurs autorisés reçoivent des cartes d'identification qu'ils doivent porter lorsqu'ils se trouvent dans les locaux d'Oracle.
  • Les visiteurs doivent signer un registre des visiteurs, être escortés ou observés lorsqu'ils se trouvent dans les locaux d'Oracle, ou être liés par les conditions d'un accord de confidentialité avec Oracle.
  • La sécurité surveille la possession des clés et des cartes d'accès, ainsi que la capacité d'accès. Le personnel qui quitte son emploi chez Oracle doit remettre ses clés et ses cartes d'accès sont désactivées à la cessation d'emploi.
  • La sécurité autorise toutes les réparations et les modifications des barrières de sécurité physique ou des contrôles d'entrée aux sites de service.
  • Oracle fait appel à des agents de sécurité sur site ou des patrouilleurs, 24 heures sur 24 et 7 jours sur 7, en fonction du niveau de risque et de protection de l'installation. Dans tous les cas, les agents sont responsables des patrouilles, de l'intervention en cas d'alarme et de l'enregistrement des incidents de sécurité.
  • Oracle a mis en place des systèmes de contrôle d'accès électroniques gérés de manière centralisée et dotés d'un système d'alarme anti-intrusion intégré. Les journaux d'accès sont conservés pendant au moins six mois. En outre, la période de conservation des vidéosurveillances et des enregistrements varie de 30 à 90 jours 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 d'Oracle, voir : Pratiques de sécurité d'entreprise d'Oracle : Oracle Access Control.

• Isolement du client et de l'hyperviseur

  L'hyperviseur est le logiciel qui gère les appareils virtuels dans un environnement en nuage, ainsi que 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 les instances de machine virtuelle et les hôtes physiques. Cela ajoute une complexité et une surcharge de calcul considérables dans l'hyperviseur. Les attaques de sécurité informatique de type PoC, telles que les attaques par évasion de machine virtuelle, ont mis en évidence le risque substantiel que peut représenter cette conception. Ces attaques exploitent la complexité de l'hyperviseur en permettant à un attaquant de "briser" une instance de machine virtuelle, d'accéder au système d'exploitation sous-jacent et de prendre le contrôle de l'hyperviseur. L'attaquant peut alors accéder à d'autres hôtes, parfois sans être détecté. Oracle Cloud Infrastructure réduit ce risque en découplant la virtualisation du réseau de l'hyperviseur.

  Pour répondre aux attaques potentielles, Oracle a mis en œuvre une architecture axée sur la sécurité à l'aide de la virtualisation de réseau isolé, élément fondamental de l'architecture de l'infrastructure Oracle Cloud. Cette architecture arrête les logiciels malveillants dans ses traces avec un SmartNIC conçu sur mesure pour isoler et virtualiser le réseau. La virtualisation de réseau isolé réduit les risques en limitant la surface d'attaque. Même si un acteur malveillant réussit une attaque par évasion de la machine virtuelle sur un seul hôte, l'architecture virtuelle est conçue pour que l'acteur ne puisse pas atteindre d'autres hôtes dans l'infrastructure en nuage. L'attaque est maîtrisée et restreinte à ce seul hôte. L'architecture de virtualisation de réseau isolé sécurisé est mise en œuvre dans chaque centre de données de chaque région. Chaque locataire Oracle Cloud Infrastructure bénéficie des avantages de cette architecture mettant la sécurité au premier plan.

  Figure 6-1 : La virtualisation de réseau isolé réduit les risques dans le nuage Oracle Génération 2

  
  Description de " La virtualisation de réseau isolé Figure 6-1 réduit le risque dans Oracle Generation 2 Cloud "
• Sécurité multilocataire

  Conformément à notre philosophie en matière de sécurité, à savoir la défense en profondeur, l'architecture multilocataire dispose d'un isolement complet.

  Il existe quatre catégories principales, avec plusieurs caractéristiques importantes dans chaque catégorie.

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

  Figure 6-2 : Isolement complet de l'architecture multilocataire

  
  Description de "Figure 6-2 de l'architecture d'isolement complète de Multitenant"

• Défense en profondeur : Exadata Cloud Infrastructure offre un certain nombre de contrôles pour assurer la confidentialité, l'intégrité et la disponibilité tout au long du service.

  Tout d'abord, Exadata Cloud Infrastructure est construit à 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). L'environnement d'exploitation de base est sécurisé, car l'image d'installation se limite aux seuls ensembles logiciels requis, les services inutiles sont désactivés et des paramètres de configuration sécurisés sont mis en oeuvre dans tout le système.

  En plus d'hériter de toute la puissance de la plate-forme mature d'Exadata Database Machine, car Exadata Cloud Infrastructure provisionne des systèmes pour les clients, d'autres choix de configuration par défaut sécurisés sont implémentés dans les instances de service. Par exemple, tous les espaces-table de base de données nécessitent un chiffrement transparent des données (TDE), une application rigoureuse des mots de passe pour les utilisateurs et les superutilisateurs initiaux de la base de données et une amélioration des règles de vérification et d'événement.

  Exadata Cloud Infrastructure constitue également un déploiement et un service complets, de sorte qu'il est soumis à des vérifications externes de normes telles que PCI, HIPPA et ISO27001. Ces exigences de vérification externe imposent des fonctions de service à valeur ajoutée supplémentaires telles que le balayage antivirus, l'alerte automatisée pour les modifications inattendues du système et les balayages de vulnérabilités quotidiens pour tous les systèmes d'infrastructure gérés par Oracle dans le parc.

• Moindre privilège

  Les normes de codage sécurisé d'Oracle exigent que les processus logiciels s'exécutent avec le niveau de privilège minimal pour mettre en oeuvre leurs fonctionnalités.

  Chaque processus et démon doit être exécuté en tant qu'utilisateur normal sans privilège, sauf si l'utilisateur peut prouver qu'il a besoin d'un niveau de privilège plus élevé. Cela permet de limiter les problèmes ou les vulnérabilités imprévus à l'espace des utilisateurs sans privilège et de ne pas compromettre un système entier.

  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 pour la maintenance ou le dépannage. Ce n'est qu'en cas de nécessité qu'ils utiliseront l'accès vérifié à des niveaux de privilège plus élevés pour résoudre un problème. La plupart des problèmes étant résolus par l'automatisation, nous utilisons également le principe du moindre privilège en n'autorisant pas les opérateurs humains à accéder à un système, sauf si l'automatisation est incapable de résoudre le problème.

• Vérification et responsabilisation

  Lorsque cela est nécessaire, l'accès au système est autorisé, mais tous les accès et toutes les actions sont consignés et suivis à des fins de responsabilisation.

  Les journaux de vérification Exadata Cloud Infrastructure sont contrôlés par Oracle et utilisés à des fins de surveillance de la sécurité et de conformité. Oracle peut partager les journaux de vérification pertinents avec les clients conformément aux pratiques de réponse aux incidents d'Oracle et à l'entente relative au traitement des données Oracle.

  Toutes les composantes de l'infrastructure disposent de capacités de vérification pour s'assurer que toutes les actions sont prises en compte. Les clients ont également la possibilité de configurer la vérification pour leur base de données et pour la configuration des machines virtuelles invitées et peuvent choisir de les intégrer à d'autres systèmes de vérification d'entreprise.

• Automatisation des opérations en nuage

  En éliminant les opérations manuelles requises pour provisionner, corriger, tenir à jour, dépanner et configurer les systèmes, la probabilité d'erreur est réduite.

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

  • Installation de programmes minimaux :

    Seuls les programmes nécessaires au fonctionnement d'un système efficace sont installés. Grâce à l'installation d'un ensemble plus restreint de programmes, la surface d'attaque du système d'exploitation est réduite et le système reste plus sûr.

  • Sécuriser la configuration :

    De nombreux paramètres de configuration non par défaut sont définis lors de l'installation afin de renforcer la sécurité du système et de son contenu. Par exemple, SSH est configuré pour n'écouter que sur certaines interfaces réseau, sendmail est configuré pour n'accepter que les connexions localhost, et de nombreuses autres restrictions similaires sont mises en place lors de l'installation.

  • Exécuter uniquement les services nécessaires :

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

• Surface d'attaque minimisée

  Dans le cadre de l'image renforcée, la surface d'attaque est réduite par l'installation et l'exécution des seuls logiciels nécessaires à la fourniture du service.

• Fonctions de sécurité supplémentaires activées (mots de passe grub, démarrage sécurisé)

  • Tirant parti des capacités d'image Exadata, ExaDB-D bénéficie de fonctionnalités intégrées à l'image de base telles que les mots de passe grub et le démarrage sécurisé, et de beaucoup d'autres.
  • Au moyen de la personnalisation, les clients peuvent souhaiter renforcer la sécurité de leur système avec des configurations supplémentaires.
• Méthodes d'accès sécurisé
  • Accès aux serveurs de bases de données par SSH à l'aide de codes de chiffrement forts. Les chiffrements faibles sont désactivés par défaut.
  • Accès aux bases de données par le biais de connexions Oracle Net chiffrées. Par défaut, nos services sont disponibles à l'aide de canaux chiffrés et un client Oracle Net configuré par défaut utilisera des sessions chiffrées.
  • Accès aux diagnostics au moyen de l'interface Web Exadata MS (https).
• Vérification et journalisation
  • Par défaut, la vérification est activée pour les opérations administratives et ces dossiers de vérification sont communiqués aux systèmes internes OCI pour vérification et génération d'alerte automatisées, le cas échéant.

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

Dans toutes les machines ExaDB-D, Oracle utilise et recommande une connexion SSH par jeton.

Il existe trois classes d'utilisateurs :

• Utilisateurs par défaut : Aucun privilège de connexion
  
• Utilisateurs par défaut avec accès à l'interpréteur de commandes restreint
  Ces utilisateurs peuvent accomplir une tâche définie avec un accès à l'interpréteur de commandes restreint. Ces utilisateurs ne doivent pas être retirés car la tâche définie échouera s'ils sont supprimés.
• Utilisateurs par défaut avec autorisations de connexion
  Ces utilisateurs dotés de privilèges peuvent accomplir la plupart des tâches du système. Ces utilisateurs ne devraient jamais être modifiés ou supprimés car cela aurait une incidence significative sur le système en cours d'exécution.

En plus de toutes les fonctions Exadata expliquées dans les fonctions de sécurité d'Oracle Exadata Database Machine, les paramètres de sécurité suivants s'appliquent également aux instances Exadata Cloud Infrastructure.

• Déploiement de base de données personnalisé avec des paramètres non par défaut.
  La commande host_access_control sert à configurer les paramètres de sécurité Exadata :

  • Mise en oeuvre de politiques relatives à l'ancienneté et la complexité des mots de passe.
  • Définition des politiques de verrouillage de compte et de temporisation de session.
  • Restriction de l'accès racine distant.
  • Restriction de l'accès réseau à certains comptes.
  • Mise en oeuvre de la bannière d'avertissement de connexion.
• account-disable : Désactive un compte d'utilisateur lorsque certaines conditions configurées sont satisfaites.
• pam-auth : Divers paramètres PAM pour les modifications de mot de passe et l'authentification de mot de passe.
• rootssh: Ajuste la valeur PermitRootLogin dans /etc/ssh/sshd_config, ce qui permet ou refuse à l'utilisateur root de se connecter au moyen de SSH.
  • Par défaut, PermitRootLogin est réglé à no.
  • PermitRootLogin=sans mot de passe est requis pour que l'automatisation du nuage effectue certaines opérations de gestion du cycle de vie. La désactivation de la connexion racine entraînera 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 maximum de connexions pour tous les utilisateurs. Cette limite ne s'applique pas à un utilisateur avec uid=0.

  Valeur définie par défaut à * hard maxlogins 10, ce qui est la valeur sécurisée recommandée.

• ssh-macs : Spécifie les algorithmes MAC (Message Authentication Code) 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 pour hmac-sha1, hmac-sha2-256, hmac-sha2-512 pour le serveur et le client.
  • Valeurs recommandées sécurisées : hmac-sha2-256, hmac-sha2-512 pour le serveur et le client.
• password-aging : Définit ou affiche l'ancienneté du mot de passe courant pour les comptes d'utilisateurs interactifs.
  • -M : Nombre maximal de jours pendant lequel un mot de passe peut être utilisé.
  • -m : Nombre minimum de jours autorisés entre les modifications de mot de passe.
  • -W : Nombre de jours d'avertissement avant l'expiration d'un mot de passe.
  • Valeurs par défaut réglées à -M 99999, -m 0, -W 7
  • --strict_compliance_only-M 60, -m 1, -W 7
  • Valeurs recommandées sécurisées : -M 60, -m 1, -W 7

Liste des processus qui s'exécutent par défaut sur la machine virtuelle du client, également appelée DOMU, ou MV invitée et système d'exploitation invité

• Agent de machine virtuelle Exadata Cloud Infrastructure :

  Agent infonuagique pour le traitement des opérations du cycle de vie de la base de données.

  • S'exécute en tant qu'utilisateur opc
  • Le tableau des processus montre qu'il fonctionne comme un 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 ensemble, ce qui facilite la collecte d'informations de diagnostic sur la base de données et le clusterware Oracle, ce qui aide à résoudre les problèmes lors de la gestion d'Oracle Support.

  • S'exécute en tant qu'utilisateur root
  • S'exécute en tant que démon (/etc/init.d/init.tfa)
  • Les tableaux des 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 tout son processus enfant est exécuté en tant que processus Perl.
  • Le tableau des processus s'affiche sous la forme de plusieurs applications Perl. ExaWatcher :
• Base de données et GI (clusterware) :
  • S'exécute en tant qu'utilisateurs dbmsvc et grid
  • Le tableau des processus présente 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) :

  Partie du logiciel d'image Exadata pour gérer et surveiller les fonctions d'image.

  • S'exécute en tant que dbmadmin.
  • Le tableau des processus indique qu'il est en cours d'exécution en tant que processus Java.

• Sécurité du réseau pour la MV invitée
  
• Exigences de conformité
  

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

• Le chiffrement TDE est utilisé pour les espaces-tables de base de données créés par les outils Oracle Database Cloud.
  • CDB$ROOT : Espace-table des utilisateurs chiffré
  • Bases de données enfichables : Tous les espaces-tables chiffrés
  • Le mot de passe du portefeuille est fourni lors de la création de la base de données initiale. Les mots de passe de portefeuille peuvent être modifiés à l'aide de dbaascli. Les clients doivent modifier ce mot de passe périodiquement.
• Utilisateurs de 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 les utilisateurs de la base de données sont verrouillés, à l'exception de SYS, SYSTEM et DBSNMP.
  • La vérification est activée 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
    • DB VERSION_11_2 : EXEMPT REDACTION POLICY
    • DB VERSION_12_1 ou DB VERSION_12_2 : BECOME USER
    • DB VERSION_12_1 : SESSION
    • Le profil DBAASSECURE est créé et défini comme profil par défaut pour le compte d'utilisateur de base de données.

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

  • 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 offert pour la connexion réseau à la base de données sur le port 2484 (wallet configuré sous /var/opt/oracle/dbaas_acfs/grid/tcps_wallets. Les paramètres sqlnet.ora pertinents définis dans Exadata Cloud Infrastructure par défaut sont :

  • 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

• Enregistrement du module d'écoute distant : Les modules d'écoute s'exécutent à partir du répertoire de base GI. Le service Exadata Cloud Infrastructure déploie la version d'Oracle Grid Infrastructure spécifiée dans le document 2333222.1 d'Oracle Support (versions logicielles du service Exadata Cloud). La configuration par défaut pour Exadata Cloud Infrastructure inclut le paramètre listener.ora VALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNET combiné à REMOTE_REGISTRATION_ADDRESS_<SCANLISTENER>=<value> pour restreindre les inscriptions de module d'écoute distant à des fins de sécurité.
• Intégration du service de chambre forte pour OCI : La clé de chiffrement TDE peut être stockée dans le service de chambre forte pour OCI (un système de gestion de clés). Pour plus d'informations et d'instructions pour configurer les principaux, les chambres fortes, etc., voir Clés gérées par le client dans Exadata Cloud Infrastructure. Les types de chambre forte privée et partagée sont pris en charge pour l'intégration du service de chambre forte pour OCI pour Exadata Cloud Infrastructure. L'authentification de l'utilisateur de la base de données n'est pas intégrée au service de chambre forte pour OCI.

Sauvegardes du système d'exploitation et de la machine virtuelle :

Oracle effectue une sauvegarde complète de la machine virtuelle invitée toutes les semaines et gère une ou plusieurs copies de sauvegarde. Ces sauvegardes sont des instantanés complets de disque de la machine virtuelle invitée (systèmes de fichiers de système d'exploitation locaux, et non des groupes de disques ASM qui résident 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 la machine virtuelle invitée à partir de la sauvegarde la plus récente en soumettant une demande de service sur 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 de restaurer un seul fichier.

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

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

La période de conservation pour les sauvegardes varie de 30 jours (sur le stockage d'objets) à 7 jours (sur le stockage local)

Chiffrement :

• Stockage d'objets et stockage local : Toutes les sauvegardes vers le stockage en nuage sont chiffrées.
• Stockage d'objets seulement : Toutes les sauvegardes vers le stockage en nuage sont chiffrées.

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

Toutes les sauvegardes sont chiffrées avec la même clé principale que celle utilisée pour le chiffrement du portefeuille TDE.

Seuls les outils automatisés sont autorisés à accéder à la machine virtuelle invitée à des fins d'automatisation du cycle de vie.

Un cas d'utilisation spécifique se pose lorsque la machine virtuelle invitée ne peut pas démarrer. Dans ce cas, les clients doivent fournir une autorisation permettant d'accéder à la machine virtuelle invitée à des fins de récupération. Les détails relatifs à ce scénario sont décrits dans la section "Flux de travail d'exception" des contrôles de sécurité du service Exadata Cloud.

Les clients contrôlent et surveillent l'accès à leurs services, y compris l'accès réseau à leurs machines virtuelles invitées (au moyen des réseaux VLAN de couche 2 et des pare-feu mis en oeuvre dans la MV invitée), l'authentification pour accéder à la MV invitée et l'authentification pour accéder aux bases de données s'exécutant dans les MV 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 du client, y compris les MV et les bases de données.

Informations d'identification personnelle (PII) : Ces informations sont considérées comme confidentielles et sensibles et doivent être protégées afin d'empêcher toute utilisation non autorisée des informations personnelles à des fins de réglementation légale, de responsabilité financière et de réputation personnelle.

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

Les règles par défaut du service de surveillance de la performance des applications masquent les informations d'identification personnelle dans les URL en reconnaissant les valeurs monétaires, les numéros de compte bancaire et les dates. Les règles par défaut ne capturent toutefois que les informations d'identification personnelle évidentes et ne sont pas exhaustives. Vous devez évaluer les règles par défaut et configurer davantage de règles pour vous assurer que la production de rapports est correcte dans votre environnement et que les informations d'identification personnelle ne sont pas affichées dans vos données.

Pour plus d'informations, voir Masquer les informations d'identification personnelle et Sécurité et informations d'identification personnelle.

Conservation des sauvegardes

Lorsque vous activez la fonction Sauvegarde automatique, le service crée des sauvegardes incrémentielles quotidiennes de la base de données dans le service de stockage d'objets. La première sauvegarde créée est de niveau 0. Ensuite, des sauvegardes de niveau 1 sont créées chaque jour jusqu'à la fin de semaine suivante. Chaque fin de semaine, le cycle se répète, en commençant par une nouvelle sauvegarde de niveau 0.

Si vous activez les sauvegardes automatiques, vous pouvez sélectionner 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 vos sauvegardes incrémentielles à la fin de la période de conservation sélectionnée.

For more information, see Manage Database Backup and Recovery on Oracle Exadata Database Service on Dedicated Infrastructure

Période de conservation des journaux de vérification

Le service de vérification pour OCI fournit des 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 de vérification sont conservés pendant 365 jours.

Pour plus d'informations, voir Période de conservation des journaux de vérification

Conservation des journaux de service

Les services Oracle Cloud Infrastructure, tels que Passerelle d'API, Événements, Fonctions, Équilibrage de charge, Stockage d'objets et Journaux de flux de réseau en nuage virtuel émettent des journaux de service. Chacun de ces services pris en charge comporte une ressource Journaux qui vous permet d'activer ou de désactiver la journalisation pour ce service. Par défaut, la conservation des journaux est de 1 mois. Elle peut être réglée à 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 politique GIA. Vous n'avez pas besoin d'utiliser des hiérarchies de compartiment complexes pour sécuriser les journaux. Par exemple, supposons que vous stockiez les journaux pour l'ensemble de la location dans le groupe de journaux par défaut d'un seul compartiment. Vous accordez l'accès au compartiment aux administrateurs de journaux avec une politique GIA comme vous le feriez normalement. Toutefois, supposons que certains projets contiennent des informations d'identification personnelle (IIP) et que seul un groupe sélectionné d'administrateurs de journaux puisse voir ces journaux. Les groupes de journaux permettent de placer les journaux contenant des informations d'identification personnelle dans un groupe de journaux distinct, puis d'utiliser une politique GIA pour restreindre l'accès à tous les administrateurs de journaux sauf quelques-uns.

Pour plus d'informations, voir Journaux de service et Gestion des journaux et des groupes de journaux

Il arrive que certains problèmes ne puissent être résolus que si Oracle se connecte à la machine virtuelle invitée du client.

Voici les situations dans lesquelles l'accès à la machine virtuelle invitée du client est nécessaire et les procédures recommandées pour y accéder :

1. Cas où la base de données de démarrage n'est pas encore créée et où le client n'a pas encore d'accès SSH à sa machine virtuelle invitée. Par exemple, une demande de service ouverte par un client pour résoudre la raison pour laquelle il est incapable de créer une base de données de démarrage. 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 politique de sécurité associée au service ExaDB-D, il est interdit aux membres du personnel d'Oracle d'accéder à la machine virtuelle invitée du client sans l'autorisation expresse de ce dernier. Pour respecter cette politique, Oracle doit obtenir l'autorisation d'accéder à la machine virtuelle invitée en posant la question suivante.

   "Pour qu'Oracle puisse résoudre le problème décrit dans cette demande de service, nous avons besoin de l'autorisation explicite du client, ce qui nous permet de nous connecter à la machine virtuelle invitée. En nous accordant une autorisation explicite pour accéder à la machine virtuelle invitée, vous confirmez qu'il n'y a pas de données confidentielles stockées dans la machine virtuelle invitée du client ou dans les bases de données associées. L'équipe de sécurité du client autorise Oracle à accéder à la machine virtuelle invitée du client afin qu'Oracle puisse aider à résoudre ce problème. Ai-je votre autorisation explicite pour accéder à la MV invitée?"

   Après une réponse affirmative du client, le personnel de soutien d'Oracle peut se connecter à la machine virtuelle du client pour résoudre le problème.

2. Situations où un certain nombre de bases de données existe dans le système du client et où le client a accès à la MV invitée, mais où le soutien technique doit maintenant se connecter à la MV invitée pour résoudre un des nombreux cas possibles

   Nous avons rencontré (les noeuds ne démarrent pas en raison de modifications sur la machine virtuelle invitée, par exemple des montages non existants dans fstab, besoin d'exécuter fsck, modification de configuration Hugepage / sysctl ou sauvegarde lvm non terminée, fstab a des entrées incorrectes pour les montages non existants, le client a modifié les configurations ou autorisations sshd dans le fichier /etc/ssh/sshd_config, etc.) ou simplement parce que le client veut qu'Oracle l'aide à résoudre le problème auquel il est confronté.

   Ce cas est plus grave que le premier car il pourrait y avoir des données sensibles dans le système de fichiers ou la base de données de la machine virtuelle invitée du client. Dans ce cas, notre personnel de soutien sera tenu de demander au client d'ouvrir une nouvelle demande de service explicite pour obtenir cette autorisation avec le titre et le contenu de la demande de service suivant.

   Conformément à la politique de sécurité associée au service ExaDB-D, il est interdit aux membres du personnel d'Oracle d'accéder à la machine virtuelle invitée du client sans l'autorisation expresse de ce dernier. Pour qu'Oracle se conforme à cette politique, nous sommes tenus de vous demander d'ouvrir une nouvelle demande de service avec le libellé exact indiqué ci-dessous, en accordant à Oracle une autorisation explicite lui permettant d'accéder à la machine virtuelle invitée. Notez que toute modification apportée au libellé 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 au DomU d'ExaDB-C@C portant le numéro de série AK99999999

   Contenu de la nouvelle demande de service : Nous ouvrons cette demande de service pour accorder à Oracle une autorisation explicite d'accéder à notre DomU afin que le soutien puisse aider à résoudre le problème décrit dans la demande de service numéro 1-xxxxxxxx.

   Nous reconnaissons qu'en donnant cette autorisation, nous comprenons qu'Oracle aura accès à TOUS LES FICHIERS du DomU et nous acceptons qu'il n'y ait pas de fichiers confidentiels

   stockés dans l'un des systèmes de fichiers du DomU. De plus, nous convenons que l'équipe de sécurité du client a autorisé Oracle à accéder à son DomU

   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 de soutien d'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 d'Oracle Cloud et des responsabilités du client pour diverses opérations par composant

• Intégration de KMS (clés HSM)
  Oracle Exadata Database Service on Dedicated Infrastructure s'intègre au service de chambre forte OCI pour protéger les données au repos de ses bases de données. Les utilisateurs ont désormais la possibilité de créer et de gérer les clés TDE principales dans le service de chambre forte pour OCI qui protègent les bases de données Exadata.
• Utilisation d'algorithmes de chiffrement non par défaut pour TDE Tablespace Encryption