Fonctions de sécurité dans le service de base de données autonome sur une infrastructure Exadata dédiée
Cet article décrit les principales fonctions de sécurité dans Autonomous Database sur une infrastructure Exadata dédiée.
Notez que dans cette section, le terme " vous " est généralement utilisé pour désigner tout administrateur de votre organisation qui a la responsabilité d'exécuter certaines tâches. Dans certains cas, c'est l'administrateur du parc, dans d'autres, c'est l'administrateur de la base de données.
En plus des fonctions de sécurité standard d'Oracle Database, telles que l'analyse des privilèges, le chiffrement de 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 sensibles, etc., Autonomous Database dédiée ajoute Database Vault, Data Safe et d'autres fonctions de sécurité avancées sans frais supplémentaires.
Les composants de base des principales fonctions de sécurité d'Autonomous Database dédié sont présentés ci-dessous.
Conseil :
Dans l'image suivante, vous pouvez cliquer sur la fonction que vous souhaitez explorer davantage.Figure - Principales fonctions de sécurité
Gestion des configurations
Fondé sur Oracle Cloud Infrastructure, Autonomous Database fournit des configurations de sécurité standard et renforcées pour que vous et votre équipe n'ayez pas besoin de consacrer trop de temps et d'argent à la gestion des configurations pour 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. Reportez-vous à Gestion des configurations dans Autonomous Database pour en savoir plus.
Les correctifs et les mises à jour de sécurité sont appliqués automatiquement, vous n'avez donc pas à vous soucier de maintenir la sécurité à jour. Ces fonctionnalités protègent vos bases de données et vos données hautement sensibles contre les vulnérabilités et les violations de sécurité coûteuses et potentiellement désastreuses. Pour plus de détails, voir Maintenance du service d'Autonomous Database dédié.
Chiffrement des données
Les bases de données autonomes stockent toutes les données dans un format chiffré dans Oracle Database. 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 le chiffrement permanent qui protège les données au repos et en transit. Toutes les données stockées et les communications réseau avec Oracle Cloud sont chiffrées par défaut. Le chiffrement ne peut pas être désactivé.
Reportez-vous à la section Chiffrement des données dans Autonomous Database dédié pour plus de détails sur le chiffrement des données et les clés de chiffrement principales.
Vérification
Oracle Autonomous Database on Dedicated Exadata Infrastructure offre des fonctions de vérification performantes qui vous permettent d'assurer le suivi des opérations effectuées sur le service et sur des bases de données spécifiques. Grâce aux données de journalisation complètes, vous pouvez vérifier et surveiller les actions effectuées sur vos ressources, ce qui vous permet de respecter les exigences de vérification tout en réduisant les risques liés à la sécurité et à l'exploitation.
Pour plus de détails, reportez-vous à la section Fonctions de vérification dans Autonomous Database dédié.
Contrôle de l'accès
Lors de la configuration de la fonction d'infrastructure Exadata dédiée, vous devez vous assurer que vos utilisateurs Oracle Cloud sont autorisés à utiliser et créer uniquement les types de ressource en nuage appropriés pour exécuter leurs tâches. De plus, vous devez vous assurer que seuls le personnel et les applications autorisés ont 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 d'infrastructure dédiée ou un accès inapproprié aux données critiques.
La sécurisation de l'accès à vos données et aux bases de données qui les contiennent implique plusieurs types de contrôle d'accès. Pour plus de détails, consultez Contrôle de l'accès dans Autonomous Database dédié.
Gestion des certificats
Lorsqu'un client tente de se connecter à une base de données Autonomous Database au moyen d'un service de connexion à la base de données TCPS (Secure TCP), Oracle Autonomous Database on Dedicated Exadata Infrastructure utilise l'authentification standard basée sur un certificat TLS 1.2 et TLS 1.3 pour authentifier la connexion. Toutefois, TLS 1.3 n'est pris en charge que sur Oracle Database 23ai ou une version ultérieure. Que le client tente de se connecter au moyen d'un service de connexion à la base de données TCPS ou TCP, son accès à la base de données est limité par les droits d'accès de l'utilisateur de base de données que le client utilise pour se connecter.
Certificat auto-signé géré par Oracle
Par défaut, Autonomous Database utilise des certificats auto-signés. Un certificat auto-signé est un certificat de sécurité généré par le système.
Les certificats auto-signés gérés par Oracle sont générés automatiquement lors du provisionnement d'une grappe de machines virtuelles Exadata autonome et s'appliquent à toutes les bases de données créées dans cette grappe de machines virtuelles autonome.
Les certificats auto-signés sont générés et associés automatiquement à une AVMC. Toutefois, vous devez télécharger le portefeuille de client Autonomous 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. Reportez-vous à Télécharger les données d'identification de client pour obtenir des instructions sur le téléchargement d'un portefeuille pour votre base de données.
- Certificat SSL de la base de données : Certificat SSL pour les connexions de client à la base de données.
- Certificat SSL ODS : Certificat SSL pour les applications Application Express (APEX).
Pour respecter les exigences de conformité de votre organisation en matière de sécurité, vous pouvez effectuer une rotation des certificats auto-signés gérés par Oracle à l'aide de la console ou de l'API Oracle Cloud Infrastructure (OCI). Pour obtenir des instructions étape par étape, voir Gérer les certificats de sécurité pour une ressource de grappe de machines virtuelles Exadata autonome. C'est ce qu'on appelle la rotation des certificats.
Pour les ressources de grappe de machines virtuelles Exadata autonome (AVMC) nouvellement provisionnées, les certificats auto-signé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'un certificat côté serveur ou côté client géré par Oracle n'est pas soumis à une rotation avant son expiration, Oracle les fait pivoter automatiquement 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 de 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 des certificats peut être utilisé pour se connecter à vos bases de données.
Parlons-en avec un exemple :
Considérez qu'un certificat SSL, par exemple C1, doit expirer et que vous avez 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 à la 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 après la rotation.
Vous pouvez également effectuer la rotation d'un certificat SSL de base de données dans les deux semaines suivant sa rotation la plus récente. Dans ce scénario, l'ancien certificat (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) attend 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 téléchargé après la première rotation jusqu'à deux semaines à partir de la deuxième rotation. Après l'achèvement de deux semaines à partir de la deuxième rotation, vous ne pouvez vous connecter à vos 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 à partir de la deuxième rotation ou plus tard.
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, attend son activation pendant deux semaines à compter de la deuxième rotation. Après deux semaines à compter de la deuxième rotation, le certificat résultant de la première rotation (C2) est également invalidé et tous 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 ODS, toutes les connexions d'application existantes seraient perdues avec la rotation du certificat et il vous est conseillé de redémarrer ORDS. La période tampon de deux semaines décrite ci-dessus ne s'applique pas lors de la rotation d'un certificat SSL ORDS.
Utiliser son propre certificat (BYOC)
L'option Utiliser son propre certificat (BYOC) vous permet d'utiliser votre certificat côté serveur signé par une autorité de certification avec vos Autonomous Database.
Pour utiliser votre propre certificat, vous devez d'abord créer le certificat à l'aide du service de certificats pour Oracle Cloud Infrastructure (OCI), comme indiqué dans Création d'un certificat. Ces certificats doivent être signés et être dans le format PEM, c'est-à-dire que leur extension de fichier doit être .pem, .cer ou .crt uniquement.
Après avoir créé le certificat côté serveur signé par l'autorité de certification, vous devez l'installer avec votre grappe de machines virtuelles autonome 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 à une grappe de machines virtuelles autonome est facilitée à partir de la boîte de dialogue Gérer les certificats de la console OCI. Dans cette boîte de dialogue, sélectionnez Utiliser votre propre certificat et sélectionnez le certificat que vous auriez créé précédemment dans la liste de sélection. Facultativement, vous pouvez également spécifier un certificat d'autorité de certification avec une autorité de certification et un ensemble d'autorité de certification. Pour obtenir des instructions étape par étape, voir Gérer les certificats de sécurité pour une ressource de grappe de machines virtuelles Exadata autonome.
- Pour vous connecter à votre base de données à l'aide d'un portefeuille de base de données, vous devez d'abord télécharger les données d'identification de client à partir de la page Détails de la base de données à l'aide de la console OCI. Pour obtenir des instructions, voir Télécharger les données d'identification du client.
- Pour vous connecter à votre base de données sans portefeuille de 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 Module d'écoute dans les options avancées lors du provisionnement de la grappe de machines virtuelles autonome. Pour plus d'informations, voir Créer une grappe de machines virtuelles Exadata autonome.
- Le certificat côté serveur signé par l'autorité de certification est signé par une autorité de certification publique bien connue afin d'être approuvé par le système d'exploitation client par défaut.
Pour répondre aux besoins de conformité de votre organisation en matière de sécurité, vous pouvez effectuer la rotation des certificats côté serveur signés par une autorité de certification à l'aide de la console ou de l'API Oracle Cloud Infrastructure (OCI). Pour obtenir des instructions étape par étape, voir Gérer les certificats de sécurité pour une ressource de grappe de machines virtuelles Exadata autonome.
Vous devez effectuer une rotation avant leur date d'expiration, à défaut de quoi les bases de données de cette grappe de machines virtuelles autonome ne seront pas accessibles sur les ports TLS tant que vous n'aurez pas fourni un certificat valide. Toutefois, vous pouvez continuer d'accéder aux bases de données sur un port non TLS tel que 1521.
Événements de certificat
| Événement | Généré lorsque |
|---|---|
| sslcertificateexpiry.reminder | Une grappe de machines virtuelles Exadata autonome détermine qu'un portefeuille arrive à expiration dans moins de six (6) semaines. Cet événement est signalé une fois par semaine au maximum. Cet événement est déclenché lorsqu'une connexion qui utilise le portefeuille arrive à expiration. |
| sslcertificate.expired | Le certificat SSL expire. Tous les portefeuilles de base de données autonome associés à cette grappe de machines virtuelles Exadata autonome expireront. |
| sslcertificaterotation.reminder | Un certificat SSL a plus de 365 jours et recommande au client d'effectuer une rotation du certificat. Une fois qu'un certificat SSL a atteint 365 jours d'ancienneté, ce rappel est généré une fois par semaine jusqu'à ce que la rotation du certificat soit effectuée. |
| sslcertificate.rotated | La rotation du certificat SSL est effectuée manuellement (à l'aide de la console ou de l'API Oracle Cloud Infrastructure) ou automatiquement à son expiration. |
Conseil :
Abonnez-vous à ces événements à l'aide du service d'avis OCI pour les recevoir chaque fois qu'ils sont publiés. Pour plus de détails, voir Création d'un abonnement.Reportez-vous à Événements pour Autonomous Database sur une infrastructure Exadata dédiée pour obtenir la liste complète des événements Autonomous Database.
Protection des données
La protection des données est un aspect essentiel de la sécurité des données dans n'importe quelle base de données. Les comptes de base de données privilégiés sont l'une des voies les plus couramment utilisées pour accéder aux données des applications sensibles de la base de données. Alors que les utilisateurs privilégiés tels que les opérateurs ADMIN ou 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.
-
Oracle Database Vault est préconfigurée et prête à l'emploi dans Autonomous Database. Vous pouvez utiliser ses contrôles de sécurité performants pour limiter l'accès aux données applicatives à des utilisateurs de base de données privilégiés, ce qui réduit les risques de menaces internes et externes et permet de respecter les exigences de conformité communes.
Vous pouvez déployer des contrôles pour bloquer l'accès des comptes privilégiés aux données applicatives et contrôler les opérations sensibles dans la base de données. Vous pouvez configurer des chemins approuvés pour ajouter des contrôles de sécurité supplémentaires régissant l'accès aux données et les modifications de base de données. Grâce à l'analyse des privilèges et des rôles lors de l'exécution, vous pouvez améliorer la sécurité des applications existantes en mettant en oeuvre des privilèges minimaux et en réduisant le profil d'attaque des comptes de base de données. Database Vault sécurise les environnements de base de données existants de manière transparente, ce qui élimine les modifications d'application coûteuses et longues.
Oracle Database Vault répond principalement aux problèmes de sécurité de base de données suivants :-
Accès administrateur aux données d'application par compte privilégié : Bien que l'administrateur de base de données soit l'utilisateur le plus puissant et le plus fiable, cet administrateur 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 concernant les schémas d'application, les tables sensibles et les procédures stockées fournissent des contrôles pour empêcher les comptes privilégiés d'être exploités par des intrus et des initiés pour accéder aux données sensibles des applications. Pour plus de détails, voir Comment Oracle Database Vault protège les comptes d'utilisateur privilégiés dans le guide de l'administrateur d'Oracle Database 19c ou le guide de l'administrateur d'Oracle Database 23ai.
-
Séparation des fonctions pour l'accès aux données d'application : Les contrôles de séparation des fonctions d'Oracle Database Vault peuvent être personnalisés et les organisations 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 fonctions afin de minimiser les dommages à la base de données en cas de vol et d'utilisation d'un compte. Pour plus de détails, voir Comment Oracle Database Vault répond aux problèmes de consolidation de base de données dans le guide de l'administrateur d'Oracle Database 19c ou le guide de l'administrateur d'Oracle Database 23ai.
Avant d'utiliser Database Vault, consultez À quoi s'attendre après avoir activé Oracle Database Vault dans le guide de l'administrateur d'Oracle Database 19c ou le guide de l'administrateur d'Oracle Database 23ai pour comprendre l'incidence 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, voir Utiliser Oracle Database Vault pour gérer les privilèges des utilisateurs de base de données.Conseil :
Pour tester le processus de configuration de la chambre forte de base de données, exécutez le Laboratoire 1 : Protéger les données avec la chambre forte de base de données dans l'atelier Oracle Autonomous Database dédié aux administrateurs de sécurité. -
- PAM est également utilisé pour aider à sécuriser les données pour une utilisation autorisée par le client et pour aider à protéger les données contre les accès non autorisés, ce qui inclut la prévention de l'accès aux données du client par les opérations Oracle Cloud et les membres du personnel de soutien. Le contrôle de l'accès aux opérations d'Oracle garantit que les comptes d'utilisateur utilisés par le personnel d'exploitation et de soutien d'Oracle Cloud pour surveiller et analyser la performance ne peuvent pas accéder aux données des bases de données Autonomous Database. Pour plus d'informations, voir Gestion des accès privés.
Détection des données sensibles et masquage des données
-
Oracle Autonomous Database on Dedicated Exadata Infrastructure prend en charge l'intégration avec Oracle Data Safe pour vous aider à évaluer et à sécuriser vos bases de données. Oracle Data Safe vous permet de comprendre la sensibilité de vos données, d'évaluer les risques pour les données, de masquer les données sensibles, de mettre en oeuvre des contrôles de sécurité et de les surveiller, d'évaluer la sécurité des utilisateurs, de surveiller les activités des utilisateurs et de répondre aux exigences de sécurité des données dans vos bases de données.
Il fournit les fonctionnalités suivantes dans une console de gestion unique et conviviale :-
Évaluation de sécurité vous aide à évaluer la sécurité de la configuration de votre base de données.
-
Évaluation des utilisateurs vous aide à évaluer la sécurité des utilisateurs de base de données et à identifier ceux-ci.
-
Détection de données vous aide à rechercher les données sensibles dans votre base de données. Masquage de données permet de masquer les données sensibles de sorte que les données soient en sécurité hors production.
-
Vérification de l'activité vous permet de vérifier l'activité des utilisateurs dans votre base de données afin que vous puissiez surveiller l'utilisation de celle-ci et être averti si des activités inhabituelles sont détectées.
Pour utiliser Oracle Data Safe pour identifier et protéger les données sensibles et réglementées de votre Autonomous Database, vous devez enregistrer votre base de données auprès du service de sécurité des données. Après avoir enregistré votre base de données auprès du service de sécurité des données, vous pouvez accéder à la console directement à partir de la page de détails de votre Autonomous Database. Pour plus d'informations sur l'inscription de votre base de données, voir Inscrire une base de données dédiée auprès du service de sécurité des données ou la désinscrire.
-
-
Lorsqu'une interrogation émise par une application au moment de l'exécution retourne un jeu de résultats contenant des informations sensibles telles que des numéros de carte de crédit ou des ID personnels, l'expurgation des données Oracle peut vous aider à masquer les détails sensibles avant de retourner le jeu de résultats à l'application. Vous pouvez mettre en oeuvre des politiques pour l'occultation de données à l'aide de l'ensemble PL/SQL
DBMS_REDACT. Reportez-vous à DBMS_REDACT dans Informations de référence sur les ensembles et les types PL/SQL Oracle Database 19c ou Informations de référence sur les ensembles et les types PL/SQL Oracle Database 23ai.
Certification de conformité réglementaire
Autonomous Database sur une infrastructure Exadata dédiée respecte un large éventail de normes de conformité internationales et propres à l'industrie, notamment :
- FedRAMP High : Federal Risk and Authorization Management Program (régions gouvernementales des États-Unis uniquement)
- HIPAA (Health Insurance Portability and Accountability Act)
- ISO/IEC 27001:2013 : Organisation internationale de normalisation 27001
- ISO/IEC 27017:2015 : Code de bonne pratique pour les mesures de sécurité de l'information basé sur la norme ISO/IEC 27002 pour les services en 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 : La norme de sécurité de l'industrie des cartes de paiement est un ensemble d'exigences visant à garantir que toutes les sociétés 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 plus d'informations et pour obtenir la liste complète des certifications, voir Conformité d'Oracle Cloud.