Fonctionnalités de sécurité dans Autonomous Database on Dedicated Exadata Infrastructure

Cet article décrit les principales fonctionnalités de sécurité dans Autonomous Database on Dedicated Exadata Infrastructure.

Notez que tout au long de cette section, le terme "vous" est généralement utilisé pour désigner tout administrateur de votre organisation qui a la responsabilité d'effectuer certaines tâches. Dans certains cas, c'est l'administrateur de parc, dans d'autres, c'est l'administrateur de base de données.

En plus des fonctionnalités de sécurité standard d'Oracle Database, telles que l'analyse des privilèges, le cryptage de réseau, les utilisateurs gérés centralement, les rôles d'application sécurisés, la protection transparente des données confidentielles, etc., Autonomous Database dédié ajoute Database Vault, Data Safe et d'autres fonctionnalités de sécurité avancées sans frais supplémentaires.

Vous pouvez voir les blocs de construction des principales fonctionnalités de sécurité d'Autonomous Database dédié décrites ci-dessous.

Conseil :

Dans l'image suivante, vous pouvez cliquer sur la fonctionnalité que vous souhaitez explorer plus avant.

Figure - Principales fonctionnalités de sécurité



Description de la figure Fonctions clés de sécurité

Rubriques connexes

Gestion de configurations

Basé sur Oracle Cloud Infrastructure, Autonomous Database fournit des configurations de sécurité standard renforcées afin que vous et votre équipe n'avez pas besoin de consacrer beaucoup de temps et d'argent à la gestion des configurations sur l'ensemble de votre parc de bases de données autonomes. Tous les comptes de service, tels que SYS et System, font l'objet d'une rotation tous les 90 jours. Pour plus d'informations, reportez-vous à Gestion de la configuration dans Autonomous Database.

Les mises à jour et les patches de sécurité sont appliqués automatiquement. Vous n'avez donc pas à vous préoccuper du maintien à jour de la sécurité. Ces fonctions protègent vos bases de données et vos données hautement sensibles contre les violations et les vulnérabilités coûteuses et potentiellement désastreuses au niveau de la sécurité. Pour plus de détails, reportez-vous à Maintenance de service d'une instance Autonomous Database dédiée.

Cryptage des données

Autonomous Database stocke toutes les données dans Oracle Database dans un format crypté. Seuls les utilisateurs et les applications authentifiés peuvent accéder aux données lorsqu'ils se connectent à la base de données.

Autonomous Database utilise un cryptage permanent qui protège les données au repos et en transit. Toutes les données stockées dans Oracle Cloud et les communications réseau avec Oracle Cloud sont cryptées par défaut. Vous ne pouvez pas désactiver le cryptage.

Pour plus de détails sur le cryptage des données et les clés de cryptage maître, reportez-vous à Cryptage des données dans Dedicated Autonomous Database.

Audit

Oracle Autonomous Database on Dedicated Exadata Infrastructure offre des fonctions d'audit puissantes qui vous permettent de savoir qui a fait quoi sur le service et sur des bases de données spécifiques. Grâce aux données de journal complètes, vous pouvez auditer et surveiller les actions réalisées sur les ressources afin de répondre à vos exigences en matière d'audit tout en réduisant les risques opérationnels et de sécurité.

Pour plus d'informations, reportez-vous à Audit des fonctionnalités dans Dedicated Autonomous Database.

Contrôle d'accès

Lors de la configuration de la fonctionnalité d'infrastructure Exadata dédiée, vous devez vous assurer que les utilisateurs cloud sont autorisés à employer et à créer uniquement les types de ressource cloud appropriés pour réaliser leur travail. Par ailleurs, vous devez faire en sorte que seul le personnel et les applications autorisés aient accès aux bases de données autonomes créées sur l'infrastructure dédiée. Sinon, vous risquez une consommation incontrôlée des ressources de l'infrastructure dédiée ou un accès inapproprié aux données stratégiques.

La sécurisation de l'accès aux données et aux bases de données qui les contiennent comprend plusieurs types de contrôle d'accès. Pour plus de détails, reportez-vous à Contrôle d'accès au sein d'une instance Autonomous Database dédiée.

Gestion des certificats

Lorsqu'un client tente de se connecter à une instance Autonomous Database via un service de connexion de base de données TCPS (TCP sécurisé), Oracle Autonomous Database on Dedicated Exadata Infrastructure utilise l'authentification TLS 1.2 et TLS 1.3 standard basée sur un certificat pour authentifier la connexion. Cependant, TLS 1.3 n'est pris en charge que sur Oracle Database 23ai ou version ultérieure. Que le client tente de se connecter via un service TCPS ou TCP, son accès à la base des données est limité par les droits d'accès du client que le client utilise pour se connecter.

Certificat auto-signé géré par Oracle

Par défaut, Autonomous Database utilise des certificats signés automatiquement. Un certificat autosigné est un certificat de sécurité généré par le système.

Génération de certificat

Les certificats autosignés gérés par Oracle sont générés automatiquement lors du provisionnement d'un cluster de machines virtuelles Exadata Autonomous et s'appliquent à toutes les bases de données créées dans ce cluster.

Gestion des certificats

Les certificats autosignés sont générés et associés automatiquement à un AVMC. Cependant, vous devez télécharger le portefeuille client Autonomous Database avant de vous connecter aux bases de données. Avec les certificats autosignés, la connexion à des bases de données sans portefeuille n'est pas une option. Pour obtenir des instructions sur le téléchargement d'un portefeuille pour votre base de données, reportez-vous à Téléchargement des informations d'identification client.

Selon les exigences, l'un des types de certificat suivants est associé à votre AVMC :
  • Certificat SSL de base de données : certificat SSL pour les connexions client de base de données.
  • Certificat SSL ORDS : certificat SSL pour les applications Application Express (APEX).
Rotation du certificat

Pour répondre aux besoins de conformité en matière de sécurité de votre organisation, vous pouvez effectuer une rotation des certificats auto-signés gérés par Oracle à l'aide de l'API ou de la console Oracle Cloud Infrastructure (OCI). Pour obtenir des instructions détaillées, reportez-vous à Gestion des certificats de sécurité pour une ressource de cluster de machines virtuelles Exadata Autonomous. C'est ce qu'on appelle la rotation des certificats.

Pour les ressources de cluster de machines virtuelles Exadata Autonomous nouvellement provisionnées, les certificats autosignés gérés par Oracle ont une validité de 13 mois à compter de leur création. La rotation d'un certificat SSL à l'aide de la console ou de l'API entraîne la rotation des certificats côté serveur et côté client et réinitialise leur validité à 13 mois. Lorsqu'une rotation de certificat côté serveur ou côté client géré par Oracle n'est pas effectuée avant son expiration, Oracle effectue automatiquement une rotation et génère de nouveaux portefeuilles.

Dans le cas des certificats SSL de base de données, la rotation des certificats n'invalide pas immédiatement le certificat existant.

Dans les deux semaines suivant la rotation du certificat, vous pouvez vous connecter à vos bases de données à l'aide du portefeuille client Autonomous Database que vous avez téléchargé avant ou après la rotation du certificat.

Après deux semaines de rotation du certificat :

  • Le portefeuille de base de données téléchargé avant la rotation du certificat n'est pas valide et ne peut pas être utilisé pour se connecter à vos bases de données.
  • Le portefeuille de base de données téléchargé dans les deux semaines suivant la rotation du certificat reste actif et peut être utilisé pour se connecter à vos bases de données.
  • Tout nouveau portefeuille de base de données téléchargé après deux semaines à partir de la rotation de certificat peut être utilisé pour se connecter à vos bases de données.

Parlons-en avec un exemple :

Supposons qu'un certificat SSL, par exemple C1, arrive à expiration et que vous ayez effectué une rotation de ce certificat le 1er février. Pendant deux semaines à partir du 1er février, que jusqu'au 14 février, l'ancien certificat (C1) est toujours disponible pour utilisation. Vous pouvez continuer à utiliser l'ancien certificat (C1) ou télécharger un nouveau portefeuille de base de données pour le certificat avec rotation (C2) pour vos connexions de base de données. Après deux semaines à partir du 1er février, c'est-à-dire à partir du 14 février, l'ancien certificat (C1) est invalidé et ne peut pas être utilisé pour les connexions à la base de données. Vous pouvez continuer à utiliser le portefeuille de base de données que vous avez téléchargé après la rotation du certificat (C2) au cours de ces deux semaines. Vous pouvez également télécharger un nouveau portefeuille de base de données et commencer à l'utiliser pour vos connexions de base de données après deux semaines de rotation.

Vous pouvez également effectuer une rotation d'un certificat SSL de base de données dans les deux semaines suivant sa dernière rotation. Dans ce scénario, l'ancien certificat (qui est sur le point d'être invalidé en raison de la première rotation) est désactivé immédiatement. Le certificat suivant (résultant de la première rotation) reste actif et un troisième certificat (résultant de la deuxième rotation) attendra l'activation pendant deux semaines à partir de la deuxième rotation. Tout portefeuille de base de données téléchargé avant la première rotation est invalidé peu après la deuxième rotation. Vous pouvez continuer à vous connecter à la base de données avec n'importe quel portefeuille de base de données téléchargé après la première rotation jusqu'à deux semaines après la deuxième rotation. Une fois la deuxième rotation terminée, vous ne pouvez vous connecter aux bases de données qu'à l'aide d'un portefeuille client téléchargé après la deuxième rotation, c'est-à-dire un portefeuille qui a été téléchargé dans les deux semaines suivant la deuxième rotation ou ultérieurement.

Dans l'exemple ci-dessus, si vous effectuez à nouveau la rotation du même certificat (C1) dans les deux semaines à partir du 1er février, le certificat subit une double rotation. Dans ce cas, l'ancien certificat (certificat avant la première rotation, c'est-à-dire C1) est invalidé immédiatement. Le certificat résultant de la première rotation (C2) reste actif et un troisième certificat résultant de la deuxième rotation, par exemple C3, attendra l'activation pendant deux semaines à partir de la deuxième rotation. Après deux semaines de la deuxième rotation, le certificat résultant de la première rotation (C2) est également invalidé et les portefeuilles de base de données téléchargés avant la deuxième rotation ne peuvent pas être utilisés pour les connexions de base de données. Vous pouvez continuer à utiliser le portefeuille de base de données que vous avez téléchargé après la rotation du certificat (C3) au cours de ces deux semaines. Vous pouvez également télécharger un nouveau portefeuille de base de données et commencer à l'utiliser pour vos connexions de base de données après deux semaines à compter de la deuxième rotation.

Dans le cas des certificats SSL ORDS, toutes les connexions d'application existantes sont perdues avec la rotation du certificat et il est conseillé de redémarrer ORDS. La période tampon de deux semaines décrite ci-dessus ne s'applique pas lorsque vous effectuez la rotation d'un certificat SSL ORDS.

Utilisation de votre propre certificat (BYOC)

Utilisation de votre propre certificat (BYOC) vous permet d'utiliser votre certificat côté serveur signé par une autorité de certification avec vos instances Autonomous Database.

Génération de certificat

Pour utiliser votre propre certificat, vous devez d'abord le créer à l'aide du service de certificat Oracle Cloud Infrastructure (OCI), comme indiqué dans Création d'un certificat. Ces certificats doivent être signés et au format PEM, c'est-à-dire que leur extension de fichier doit être .pem, .cer ou .crt uniquement.

Installation du certificat

Après avoir créé le certificat côté serveur signé par l'autorité de certification, vous devez l'installer avec votre AVMC afin que toutes les bases de données qui y sont créées puissent utiliser ce certificat pour des connexions sécurisées. L'association de votre certificat BYOC à un AVMC est facilitée à partir de la boîte de dialogue Gérer les certificats sur la console OCI. Dans cette boîte de dialogue, choisissez Apportez votre propre certificat et sélectionnez le certificat que vous auriez créé précédemment dans la liste de sélection. Vous pouvez également indiquer un certificat d'autorité de certification avec une autorité de certification et un package d'autorité de certification. Pour obtenir des instructions détaillées, reportez-vous à Gestion des certificats de sécurité pour une ressource de cluster de machines virtuelles Exadata Autonomous.

Gestion des certificats
Vous pouvez vous connecter à des instances Autonomous Database associées à un côté serveur signé par une autorité de certification avec ou sans portefeuille client Autonomous Database.
  • Pour vous connecter à la base de données à l'aide d'un portefeuille de base de données, vous devez d'abord télécharger les informations d'identification client à partir de la page Détails de la base de données à l'aide de la console OCI. Pour obtenir des instructions, reportez-vous à la section Download Client Credentials.
  • Pour vous connecter à la base de données sans portefeuille client, vous devez vous assurer que :
    • Les connexions TLS unidirectionnelles sont activées au niveau AVMC. Il s'agit d'un paramètre défini à l'aide du paramètre Processus d'écoute dans les options avancées lors du provisionnement de la console AVMC. Pour plus d'informations, reportez-vous à Création d'un cluster de machines virtuelles Exadata Autonomous.
    • Le certificat côté serveur signé par l'autorité de certification est signé par une autorité de certification publique connue de sorte qu'elle soit approuvée par le système d'exploitation client par défaut.
Rotation du certificat

Pour répondre aux besoins de conformité en matière de sécurité de votre organisation, vous pouvez effectuer la rotation des certificats côté serveur signés par une autorité de certification à l'aide de l'API ou de la console Oracle Cloud Infrastructure (OCI). Pour obtenir des instructions détaillées, reportez-vous à Gestion des certificats de sécurité pour une ressource de cluster de machines virtuelles Exadata Autonomous.

Vous devez effectuer une rotation avant leur date d'expiration, faute de quoi les bases de données de cette instance AVMC ne seront pas accessibles sur les ports TLS tant que vous n'aurez pas fourni un certificat valide. Toutefois, vous pouvez continuer à accéder aux bases de données sur un port non TLS tel que 1521.

Evénements de certificat

Les événements suivants sont publiés pour la gestion des certificats de sécurité :
Evénement Généré quand
sslcertificateexpiry.reminder Un cluster de machines virtuelles Exadata Autonomous détermine qu'un portefeuille va expirer dans moins de six (6) semaines. Cet événement est signalé au maximum une fois par semaine. Cet événement est déclenché lorsqu'une connexion utilise le portefeuille qui arrive à expiration.
sslcertificate.expired Le certificat SSL expire. Tous les portefeuilles Autonomous Database associés au cluster de machines virtuelles Exadata Autonomous expirent.
sslcertificaterotation.reminder Un certificat SSL date de plus de 365 jours. Il recommande au client d'effectuer une rotation de certificat. Lorsqu'un certificat SSL dépasse 365 jours, ce rappel est généré une fois par semaine jusqu'à ce qu'une rotation ait lieu.
sslcertificate.rotated La rotation du certificat SSL est effectuée manuellement (à l'aide de l'API ou de la console Oracle Cloud Infrastructure) ou automatiquement à son expiration.

Conseil :

Abonnez-vous à ces événements à l'aide du service OCI Notifications pour les recevoir chaque fois qu'ils sont publiés. Pour plus d'informations, voir Créer un abonnement.

Reportez-vous à Evénements pour Autonomous Database on Dedicated Exadata Infrastructure pour obtenir la liste complète des événements Autonomous Database.

Data Protection

La protection des données est un aspect essentiel de la sécurité des données dans toute base de données. Les comptes de base de données privilégiés sont l'un des chemins les plus couramment utilisés pour accéder aux données des applications sensibles de la base. Alors que les utilisateurs privilégiés tels qu'ADMIN ou les opérateurs Oracle ont besoin d'un accès large et illimité pour faciliter la maintenance de la base de données, le même accès crée également un point d'attaque pour accéder à de grandes quantités de données.

Autonomous Database vous permet d'implémenter Privileged Access Management (PAM) à l'aide des éléments suivants :

  • Oracle Database Vault est préconfiguré et prêt à l'emploi dans les instances Autonomous Database. Vous pouvez utiliser ses puissants contrôles de sécurité pour limiter l'accès aux données d'application par des utilisateurs de base de données privilégiés, ce qui réduit le risque de menaces internes et externes, et répond aux exigences de conformité courantes.

    Vous pouvez déployer des contrôles pour bloquer l'accès de comptes privilégiés aux données d'application et contrôler les opérations sensibles dans la base de données. Vous pouvez configurer des chemins sécurisés pour ajouter des contrôles de sécurité supplémentaires à l'accès autorisé aux données et aux modifications de base de données. Grâce à l'analyse d'exécution des privilèges et des rôles, vous pouvez améliorer la sécurité des applications existantes en implémentant les moindres privilèges requis et en réduisant le profil d'attaque des comptes de base de données. Database Vault permet de sécuriser les environnements de base de données existants de manière transparente, éliminant ainsi les modifications coûteuses et chronophages des applications.

    Oracle Database Vault répond principalement aux problèmes de sécurité de base de données suivants :

    • Accès de compte avec privilèges d'administration aux données d'application : bien que l'administrateur de base de données soit l'utilisateur le plus puissant et le plus fiable, il n'a pas besoin d'accéder aux données d'application résidant dans la base de données.

      Les domaines Oracle Database Vault entourant les schémas d'application, les tables confidentielles et les procédures stockées fournissent des contrôles permettant d'empêcher les intrus et les internes d'exploiter des comptes privilégiés pour accéder aux données d'application confidentielles. Pour plus d'informations, reportez-vous à Comment Oracle Database Vault protège les comptes utilisateur privilégiés dans le Guide de l'administrateur Oracle Database 19c ou le Guide de l'administrateur Oracle Database 23ai.

    • Séparation des responsabilités pour l'accès aux données d'application : la séparation des contrôles de responsabilité d'Oracle Database Vault peut être personnalisée et les entreprises disposant de ressources limitées peuvent affecter plusieurs responsabilités Oracle Database Vault au même administrateur, mais en utilisant des comptes distincts pour chaque rôle de séparation des responsabilités afin de minimiser les dommages causés à la base de données si un compte est volé et exploité. Pour plus d'informations, reportez-vous à How Oracle Database Vault Addresses Database Consolidation Concerns dans le Guide de l'administrateur Oracle Database 19c ou le Guide de l'administrateur Oracle Database 23ai.

    Avant d'utiliser Database Vault, reportez-vous à What to Expect After You Enable Oracle Database Vault dans le Guide de l'administrateur Oracle Database 19c ou le Guide de l'administrateur Oracle Database 23ai pour comprendre l'impact de la configuration et de l'activation de Database Vault.

    Pour plus d'informations sur la configuration et l'activation de Database Vault dans votre base de données autonome, reportez-vous à Utilisation d'Oracle Database Vault pour gérer les privilèges d'utilisateur de base de données.

    Conseil :

    Pour tester le processus de configuration de Database Vault, suivez l'exercice 1 sur la protection des données avec Database Vault dans l'atelier Oracle Autonomous Database Dedicated pour les administrateurs de la sécurité.
  • Le module PAM est également utilisé pour sécuriser les données à des fins d'utilisation autorisée par le client et pour protéger les données contre tout accès non autorisé, notamment en empêchant l'accès aux données client par les opérations Oracle Cloud et les membres du personnel de support. Oracle Operations Access Control garantit que les comptes utilisateur utilisés par le personnel en charge des opérations et du support technique Oracle Cloud pour surveiller et analyser les performances ne peuvent pas accéder aux données des instances Autonomous Database. Pour plus d'informations, reportez-vous à la section Gestion des accès privilégiés.

Repérage des données confidentielles et masquage des données

L'identification des données sensibles (telles que le numéro de carte de crédit, le numéro de sécurité sociale) et leur masquage ou leur occultation au besoin améliorent la protection des données et la sécurité globale des données.

  • Oracle Autonomous Database on Dedicated Exadata Infrastructure prend en charge l'intégration au service Oracle Data Safe pour vous aider à évaluer et à sécuriser vos bases de données. Oracle Data Safe vous permet de comprendre la confidentialité de vos données, d'évaluer les risques pour les données, de masquer les données confidentielles, d'implémenter et de surveiller les contrôles de sécurité, d'évaluer la sécurité utilisateur, de surveiller l'activité des utilisateurs et de répondre aux exigences en matière de conformité de sécurité des données dans vos bases de données.

    Il fournit l'ensemble de fonctionnalités suivant dans une console de gestion unique et facile à utiliser :

    • L'évaluation de la sécurité vous permet d'évaluer la sécurité de votre configuration de base de données.

    • L'évaluation des utilisateurs permet d'évaluer la sécurité de vos utilisateurs de base de données et d'identifier les utilisateurs à risque élevé.

    • Le repérage de données vous aide à trouver des données confidentielles dans votre base de données. Le masquage des données permet de masquer les données confidentielles pour que les données soient sécurisées dans des environnements hors production.

    • L'audit d'activité permet d'auditer l'activité utilisateur sur votre base de données afin de surveiller l'utilisation de la base de données et de générer des alertes en cas d'activités inhabituelles.

    Pour plus d'informations sur l'utilisation de Data Safe, reportez-vous à Présentation d'Oracle Data Safe dans Utilisation d'Oracle Data Safe.

    Pour utiliser Oracle Data Safe afin d'identifier et de protéger les données confidentielles et réglementées de votre instance Autonomous Database, vous devez inscrire cette dernière auprès de Data Safe. Après avoir inscrit la base de données auprès de Data Safe, vous pouvez accéder à la console Data Safe directement à partir de la page Détails de l'instance Autonomous Database. Pour plus d'informations sur l'inscription de la base de données, reportez-vous à Inscription ou annulation de l'inscription d'une base de données dédiée auprès de Data Safe.

  • Lorsqu'une requête émise par une application lors de l'exécution renvoie un ensemble de résultats contenant des informations sensibles telles que des numéros de carte de crédit ou des ID personnels, Oracle Data Redaction peut vous aider à masquer les détails sensibles avant de renvoyer l'ensemble de résultats à l'application. Vous pouvez implémenter des stratégies de protection par occultation des données à l'aide du package PL/SQL DBMS_REDACT . Reportez-vous à DBMS_REDACT dans le manuel Oracle Database 19c PL/SQL Packages and Types Reference ou Oracle Database 23ai PL/SQL Packages and Types Reference.

Certification de conformité réglementaire

Autonomous Database on Dedicated Exadata Infrastructure est conforme à un large éventail de normes de conformité internationales propres aux secteurs, telles que les suivantes :

  • FedRAMP - Niveau élevé (Federal Risk and Authorization Management Program) (régions du gouvernement des Etats-Unis uniquement)
  • HIPAA (Health Insurance Portability and Accountability Act)
  • ISO/IEC 27001:2013 - Organisation internationale de normalisation 27001
  • ISO/IEC 27017:2015 - Code de bonnes pratiques pour les contrôles de sécurité de l'information fondés sur l'ISO/IEC 27002 pour les services du nuage
  • ISO/IEC 27018:2014 - Code de bonnes pratiques pour la protection des informations personnelles identifiables (PII) dans l'informatique en nuage public agissant comme processeur de PII
  • PCI DSS (Payment Card Industry Data Security Standard) est un ensemble d'exigences visant à garantir que toutes les entreprises qui traitent, stockent ou transmettent des informations de carte de crédit disposent d'un environnement sécurisé.
  • SOC 1 (System and Organization Controls 1)
  • SOC 2 (System and Organization Controls 2)

Pour obtenir plus d'informations, ainsi que la liste complète des certifications, reportez-vous à Conformité d'Oracle Cloud.