Fonctionnalités de sécurité dans Autonomous AI Database sur une infrastructure Exadata dédiée

Cet article décrit les principales fonctionnalités de sécurité dans Autonomous AI 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.

Outre les fonctionnalités de sécurité standard d'Oracle AI Database, telles que l'analyse des privilèges, le cryptage réseau, les utilisateurs gérés de manière centralisée, les rôles d'application sécurisés, la protection transparente des données confidentielles et autres, une base de données autonome AI dédiée ajoute Database Vault, Data Safe et d'autres fonctionnalités de sécurité avancées sans frais supplémentaires.

Vous pouvez voir les composants de base des fonctionnalités de sécurité clés d'une base de données d'IA autonome dédiée illustrée 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ée sur Oracle Cloud Infrastructure, la base de données d'IA autonome fournit des configurations d'assurance standard renforcées afin que vous et votre équipe n'ayez pas à consacrer beaucoup de temps et d'argent à gérer les configurations sur l'ensemble du parc de base de données d'IA autonome. 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 configuration dans Autonomous AI 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 données hautement confidentielles contre des violations et des vulnérabilités coûteuses et potentiellement désastreuses du niveau de la sécurité. Pour plus d'informations, reportez-vous à Maintenance du service de la base de données IA autonome dédiée.

Cryptage des données

Autonomous AI 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 AI Database utilise le chiffrement 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 d'informations sur le cryptage des données et les clés de cryptage maître, reportez-vous à Cryptage des données dans une base de données IA autonome dédiée.

Audit

Oracle Autonomous AI Database on Dedicated Exadata Infrastructure offre des fonctions d'audit robustes qui vous permettent de suivre qui a effectué quelle étape sur le service et sur des bases d'informations 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 à Capacités d'audit dans une base de données IA autonome dédiée.

Contrôle d'accès

Lors de la configuration de la fonctionnalité d'infrastructure Exadata dédiée, vous devez vous assurer que l'utilisateur cloud est autorisé à employer et de créer uniquement les types de ressources cloud appropriés pour réaliser son travail. Par ailleurs, vous devez faire en sorte que seuls le personnel et les applications autorisés aient accès aux bases de données Autonomous AI 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 d'informations, reportez-vous à Contrôle d'accès au sein d'une base de données IA autonome dédiée.

Gestion des certificats

Lorsqu'un client tente de se connecter à une base de données Autonomous AI via un service de connexion de base de données TCPS (TCP sécurisé), Oracle Autonomous AI Database on Dedicated Exadata Infrastructure utilise l'authentification basée sur un certificat TLS 1.2 et TLS 1.3 standard pour authentifier la connexion. Cependant, TLS 1.3 n'est pris en charge que sur Oracle AI 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 AI Database utilise des certificats auto-signés. Un certificat auto-signé 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. Toutefois, vous devez télécharger le portefeuille client Autonomous AI Database avant de vous connecter à vos bases de données. Avec les certificats auto-signés, la connexion aux bases de données sans portefeuille n'est pas une option. Pour obtenir des instructions sur le téléchargement d'un portefeuille pour la 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 AI 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)

L'utilisation de votre propre certificat (BYOC) vous permet d'utiliser votre certificat côté serveur signé par l'autorité de certification avec vos bases de données IA autonomes.

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 bases de données AI autonomes associées à un serveur signé par une autorité de certification avec ou sans portefeuille client Autonomous AI 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 de base de données Autonomous AI associés à ce 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 AI Database sur une infrastructure Exadata dédiée pour obtenir la liste complète des événements de Autonomous AI 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 AI Database vous permet d'implémenter la gestion des accès privés (PAM) à l'aide des éléments suivants :

  • Oracle Database Vault est préconfiguré et prêt à être utilisé dans les bases de données d'IA autonomes. 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 AI Database Vault répond principalement aux problèmes de sécurité des bases 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 AI Database Vault relatifs aux schémas d'application, aux tables sensibles et aux procédures stockées fournissent des contrôles permettant d'empêcher l'exploitation de comptes privilégiés par des intrus et des initiés pour accéder aux données d'application sensibles. Pour plus d'informations, reportez-vous à Protection des comptes utilisateur privilégiés par Oracle AI Database Vault dans le Guide de l'administrateur Oracle Database 19c ou dans le Guide de l'administrateur Oracle Database 26ai.

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

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

    Pour obtenir des informations sur la façon de configurer et d'activer Database Vault dans votre base de données Autonomous AI, reportez-vous à Utilisation d'Oracle AI 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, exécutez l'atelier pratique 1 sur l'utilisation de la protection des données à l'aide de Database Vault dans l'atelier Oracle Autonomous AI Database Dedicated for Security Administrators.
  • 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é, ce qui inclut la prévention de l'accès aux données client par les opérations Oracle Cloud et les membres du personnel de support. Oracle Operations Access Control permet de s'assurer 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 bases de données AI autonomes. Pour plus d'informations, reportez-vous à 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 AI Database sur une infrastructure Exadata dédiée 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 d'évaluer la sensibilité de vos données, d'évaluer les risques liés aux données, de masquer ces données confidentielles, d'implémenter et de surveiller des contrôles de la sécurité, d'évaluer la sécurité utilisateur, de surveiller l'activité de l'utilisateur et de répondre aux exigences en matière d'application de la conformité des données des 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 sensibles et réglementées de votre base de données Autonomous AI, vous devez inscrire votre base de données auprès de Data Safe. Une fois la base de données inscrite auprès de Data Safe, vous pouvez accéder à la console Data Safe directement à partir de la page Détails de votre base de données AI autonome. Pour plus d'informations sur l'inscription de la base de données, reportez-vous à la section Inscription ou annulation d'inscription d'une base de données autonome AI dédiée auprès d'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, la protection par occultation Oracle 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 pour la protection par occultation à 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 26ai PL/SQL Packages and Types Reference.

Certification de conformité réglementaire

Autonomous AI Database on Dedicated Exadata Infrastructure répond à un large éventail de normes de conformité internationales et propres au secteur, notamment :

  • 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.