A propos de l'architecture OCI et des meilleures pratiques

EU Sovereign Cloud offre les fonctionnalités uniques suivantes aux clients OCI :

  • Protection des données via la protection des services et la réplication des données
  • Accéder aux modèles via la mise en réseau virtuelle
  • Modèles de sécurité via IAM
  • Auditer la modélisation et la gouvernance de la conformité

Chacun de ces modèles fournit des mécanismes spécifiques qui offrent aux clients la possibilité de renforcer la souveraineté de leur environnement cloud.

Protection des données

La protection des données au sein du cloud souverain de l'UE est abordée sous plusieurs angles différents :

  • Accès : limitation de l'accès aux données afin d'empêcher toute utilisation non autorisée.
  • Réplication de données intra-UE : établissement de copies de données dans deux emplacements physiques (régions) différents tout en restant dans les limites de l'UE.
  • Le chemin de réplication ne quitte pas l'UE : la connexion de réplication entre les régions est entièrement contenue dans la transmission de données de l'UE entre les régions du cloud souverain de l'UE se trouve sur une épine dorsale dédiée établie pour le cloud souverain de l'UE et ne quitte pas l'UE pendant le transit.
  • Clés de cryptage locales : le stockage et le cryptage des données sont gérés soit par des clés générées par le cloud souverain de l'UE gérées au sein de l'UE, soit par des clés fournies par le client. Les clés fournies par le client sont stockées dans un service de gestion des clés (KMS) qui réside physiquement dans l'UE et est entièrement contrôlé par le client.
  • Autorités de certification locales : avec le service OCI Certificates, les locataires peuvent effectuer toutes les actions associées à l'émission et à la gestion des certificats. Cela inclut l'importation d'une autorité de certification racine tierce (CA) qui peut être distribuée en interne aux ressources au sein du cloud souverain de l'UE, sans passer par Internet. Ces certificats peuvent ensuite être appliqués à SSL et à d'autres utilisations pour établir un chiffrement fort et vérifiable localement entre les sites.

Introduction à la protection des données

Pour commencer à utiliser les méthodes de protection des données, procédez comme suit :

  • Utilisez les piles Oracle Cloud pour créer une infrastructure normalisée dans deux régions de données du cloud souverain de l'UE.
  • Créez une liaison inter-région pour l'infrastructure à l'aide de passerelles de routage dynamique afin de connecter les réseaux de région en toute sécurité.
  • Etablissez la réplication entre les deux sites à l'aide d'outils tels que Data Guard, la réplication inter-région Object Storage et les outils de réplication basés sur les applications pour protéger les données hébergées dans le cloud souverain de l'UE.
  • Créez un coffre OCI dans le cloud souverain de l'UE pour les clés et les clés secrètes critiques et répliquez le coffre dans la deuxième région de données.
  • Téléchargez des certificats vers le service OCI Certificates et utilisez l'adresse de service pour le chargement et la validation des certificats.

Répliquer les données vers un autre emplacement

L'une des stratégies les plus courantes pour assurer la protection des données consiste à répliquer les données vers un autre emplacement pour un stockage à long terme à l'aide d'un site chaud/chaud.

Idéalement, la réplication se produit sur une liaison aussi directe que possible à la source et pourrait être utilisée à la fois pour la protection des données et les communications inter-sites afin d'optimiser le coût de la liaison. Dans le cas de l'UE, la liaison de données elle-même ne devrait pas avoir un chemin permettant aux données de quitter l'UE.


La description de mad-fra-region.png suit
Description de l'image mad-fra-region.png

mad-fra-region-oracle.zip

EU Sovereign Cloud propose des mécanismes de protection des données et des services OCI qui peuvent vous aider à répondre aux exigences de réplication et de transit des données. Oracle a établi les régions de données du cloud souverain de l'UE avec une parité de service qui vous permet de mettre en miroir l'implémentation du stockage et des applications. Le stockage et les applications peuvent être répliqués vers l'autre région de données du cloud souverain de l'UE via un lien de base dédié, avec la certitude que les capacités et les services disponibles sont identiques. Cette épine dorsale dédiée est également utilisée pour la gestion du trafic entre les régions du cloud souverain de l'UE et une grande partie de la bande passante est disponible pour une utilisation par les locataires dans le cloud souverain de l'UE. Dans tous les cas, le trafic de données client qui circule sur cette épine dorsale est à la fois isolé des autres domaines et régions qui ne font pas partie du cloud souverain de l'UE.

Crypter les données

Le cryptage des données et/ou le stockage des clés de cryptage utilisées à diverses fins au sein d'un système particulier constituent également un aspect essentiel des stratégies de protection des données. Oracle fournit une solution KMS localisée qui gère les clés pouvant être utilisées pour le cryptage du stockage de données dans le cloud souverain de l'UE et stocke les clés pouvant être extraites par programmation pour une utilisation dans des applications ou par exemple des mécanismes de cryptage de données au niveau de l'instance.

Le service OCI Vault fournit cette fonctionnalité. Vault peut être implémenté en tant que KMS logiciel colocatif ou en tant que modules HSM dédiés. Dans les deux cas, Vault est exclusivement situé dans le domaine du cloud souverain de l'UE et Oracle n'a pas la possibilité d'accéder aux clés ou aux clés secrètes stockées dans le coffre logiciel ou dans le HSM dédié. Les activités de cryptage des données sont également situées exclusivement dans le cloud souverain de l'UE, chaque région conservant sa propre implémentation de coffre-fort indépendante. Les algorithmes de cryptage clés pris en charge par OCI Vault incluent AES (Advanced Encryption Standard), l'algorithme Rivest-Shamir-Adleman (RSA) et l'algorithme de signature numérique de courbe elliptique (ECDSA). Les clients peuvent créer et utiliser des clés symétriques AES et des clés asymétriques RSA pour le chiffrement et le déchiffrement, ou utiliser des clés asymétriques RSA ou ECDSA pour signer des messages numériques.

Crypter les connexions aux consommateurs de données

Il est également important de considérer non seulement le cryptage des données au repos, mais aussi la possibilité de crypter les connexions aux consommateurs de données, en particulier via des protocoles tels que HTTPS.

Dans de nombreux cas, les certificats x.509 sont gérés via des sources externes ou via des serveurs dédiés qui génèrent des certificats locaux à utiliser en interne. EU Sovereign Cloud offre le service OCI Certificates qui permet aux clients de créer des certificats locaux pour les applications internes et externes, d'importer des certificats groupés de certification tiers pour distribution et de gérer les certifications installées dans le service, telles que la rotation des clés. Toutes les tâches associées à la gestion des certificats (ajout, rotation, suppression, etc.) peuvent être effectuées à partir d'un service central entièrement situé dans le cloud souverain de l'UE.

Intégration à l'équilibreur de charge OCI

L'intégration au service OCI Load Balancer permet aux clients d'associer de manière transparente un certificat TLS émis ou géré par OCI Certificates à des ressources nécessitant des certificats. Les applications ou les serveurs qui ne sont pas intégrés au service Certificates peuvent fournir une structure d'API permettant d'extraire les certificats jugés appropriés par les stratégies IAM de location. La centralisation des certificats dans une source faisant autorité dans l'UE permet de gérer les certificats localement et garantit que les clients du cloud souverain de l'UE peuvent localiser le cryptage au sein de l'UE.

Modèle d'accès

Les mécanismes déjà intégrés à l'architecture OCI permettent également au cloud souverain de l'UE de fournir un filtrage efficace des paquets réseau, des contrôles d'accès, une connectivité dirigée et, en fin de compte, un moyen efficace de limiter l'accès aux ressources et applications déployées uniquement aux adresses réseau situées dans l'UE.

Introduction à Access Model

Pour commencer à implémenter rapidement un modèle d'accès, procédez comme suit :

  • Implémentez une conception de réseau cloud virtuel (VCN) à l'aide d'une approche de défense approfondie. Utilisez uniquement des sous-réseaux publics dans le VCN lorsque cela est nécessaire pour l'accès externe.
  • Créez une zone démilitarisée pour filtrer le trafic à l'aide de sous-réseaux publics et privés.
  • Utilisez le service OCI Network Firewalls (NFW) pour contrôler et surveiller l'accès aux sous-réseaux critiques, y compris tous les sous-réseaux publics.
  • Créez des listes de sécurité par sous-réseau pour restreindre l'accès intra-sous-réseau.
  • Implémentez des groupes de sécurité réseau à chaque instance/adresse pour contrôler étroitement la source d'accès.
  • Activez régulièrement les journaux de flux VCN pour auditer le trafic.
  • Implémentez le système de noms de domaine OCI (DNS) pour contrôler la résolution des adresses et filtrer les domaines DNS indésirables sans affecter les domaines acceptés.
  • Utilisez des connexions de point, telles que FastConnect et CPE Configuration, pour établir des backhauls administratifs qui n'utilisent pas le réseau Internet public.

Utiliser des listes de sécurité, des groupes de sécurité réseau et des pare-feu réseau

Les fonctionnalités des services OCI natifs tels que Network Firewall (NFW), Security Lists (SL) et Network Security Groups (NSG), combinées aux journaux de flux Virtual Cloud Network (VCN), fournissent des mécanismes solides pour empêcher et détecter les accès à partir de points d'origine hors UE.

L'une des principales méthodes permettant de garantir que des plages d'adresses IP publiques spécifiques à l'UE ont accès aux ressources consiste à utiliser une combinaison de SL, de NSG et de NFW. En arrière-plan, tous les accès aux instances/ressources attachées aux sous-réseaux OCI sont "refusés" par défaut. Cette stratégie empêche également les instances d'un même sous-réseau d'intercommunier. L'accès doit être explicitement accordé pour initier et répondre aux connexions par des ressources au sein d'un sous-réseau particulier ou entre des sous-réseaux du VCN. La principale façon d'y parvenir est par le biais des SL. Il s'agit de définitions au niveau du sous-réseau de la connectivité autorisée que l'on peut spécifier par protocole, port et plage CIDR. Les connexions situées en dehors des plages définies sont supprimées en mode silencieux. Les groupes de sécurité réseau effectuent certaines des mêmes tâches, mais sont appliqués à la couche de carte d'interface réseau virtuelle (VNIC) et non au sous-réseau dans son ensemble. En utilisant une combinaison de bibliothèques de services et de groupes de sécurité réseau, un client du cloud souverain de l'UE peut créer une zone d'accès restreint aux ressources qui accepte uniquement les adresses de plages d'adresses IP publiques de l'UE spécifiées. Si le client étend ces limites à des ressources individuelles, telles que les équilibreurs de charge, les instances Compute, les bastions, etc., un modèle d'accès ciblé peut être implémenté pour répondre aux besoins de l'organisation. Enfin, les groupes de sécurité réseau et les SL sont bidirectionnels, ce qui signifie que les règles de connectivité internes et externes peuvent être établies indépendamment les unes des autres. Avec cette fonctionnalité, même si une connexion entrante est établie, que ce soit par conception ou par une mauvaise configuration des règles entrantes, la connexion externe doit toujours être autorisée pour que la session complète soit établie.

Implémenter une "porte avant" pour les ressources sur les réseaux cloud virtuels

EU Sovereign Cloud propose également un service Network Firewall basé à Palo Alto qui permet la mise en œuvre d'une variété de services et de restrictions en tant que "porte d'entrée" pour les ressources trouvées sur les réseaux cloud virtuels, telles que :

  • Filtrage réseau avec conservation de statut

    Le filtrage de réseau avec état crée des règles de filtrage de réseau avec état qui autorisent ou refusent le trafic réseau en fonction de l'adresse IP source (IPv4 et IPv6), de l'adresse IP de destination (IPv4 et IPv6), du port et du protocole.

  • Filtrage d'URL personnalisée et de nom de domaine qualifié complet

    Le filtrage de nom de domaine qualifié complet et d'URL personnalisées restreint le trafic entrant et sortant à la liste indiquée de noms de domaine qualifiés complets, y compris les caractères génériques et les URL personnalisées.

  • Détection et prévention des intrusions (IDPS)

    IDPS (Intrusion Detection and Prevention) surveille votre réseau pour détecter toute activité malveillante et empêche le trafic réseau suspect d'atteindre le réseau interne.

  • Inspection SSL

    L'inspection SSL décrypte et inspecte le trafic crypté TLS avec la prise en charge d'ESNI pour les vulnérabilités de sécurité. ESNI (Encrypted Server Name Indication) est une extension TLSv1.3 qui crypte l'indication de nom de serveur (SNI, Server Name Indication) dans la procédure d'établissement de liaison TLS.

  • Inspection du trafic de sous-réseau intra-VCN

    L'inspection du trafic de sous-réseau intra-VCN achemine le trafic entre deux sous-réseaux VCN via un pare-feu réseau.

  • Inspection du trafic inter-VCN

    L'inspection du trafic inter-VCN achemine le trafic entre deux réseaux cloud virtuels via un pare-feu réseau.


La description de access-model-arch.png suit
Description de l'image access-model-arch.png

access-model-arch-oracle.zip

Dans le diagramme ci-dessus, il existe cinq scénarios :
  1. NFW rejette la connexion en fonction du jeu de règles défini par le client et la tentative de connexion est consignée.
  2. NFW accepte la connexion et achemine celle-ci vers l'instance appropriée du sous-réseau protégé. La SL autorise cette connexion à partir de ce sous-réseau, et le groupe de sécurité réseau de l'instance dispose d'une règle qui autorise les connexions à partir de NFW.
  3. L'instance du sous-réseau A tente de se connecter à une instance. Bien que la bibliothèque SL autorise les connexions à partir du sous-réseau A, le groupe de sécurité réseau de l'instance empêche la connexion.
  4. L'instance du sous-réseau A tente une autre connexion à une autre instance. Ici, la SL et le groupe de sécurité réseau permettent la connexion
  5. L'instance du sous-réseau B tente de se connecter à une instance. Le sous-réseau B n'a pas été autorisé à accéder au sous-réseau protégé. Aucune connexion n'est donc autorisée, quel que soit le groupe de sécurité réseau de l'instance.

Contrôler et déterminer la résolution de nom appropriée

En outre, la capacité de contrôler et de déterminer les sources de résolution de noms appropriées est un mécanisme qui peut déterminer la connectivité et fournir la résolution de noms et le relais d'une manière déterministe aux adresses DNS définies.

L'environnement de cloud souverain de l'UE hérite du service DNS OCI, ce qui vous permet de contrôler étroitement les deux adresses utilisées dans le cloud souverain de l'UE, ainsi que les sources vers lesquelles les demandes sont transmises. Pour ce faire, le service DNS OCI fractionne l'adresse du processus d'écoute DNS du transitaire, avec un moteur de règles intégré entre les deux. Cela vous permet de définir des règles définies sur la direction des demandes DNS, potentiellement à différents transitaires en fonction du domaine demandé. La demande de recherches de domaine déterminée comme étant en dehors de l'ensemble de règles ou la sélection de plusieurs transitaires pointant vers des sources DNS différentes, en fonction du résultat du moteur de règles, renvoie la réponse NX_DOMAIN pour les réacheminements NULL ciblés. Les clients peuvent être très délibérés sur la réponse de résolution DNS du cloud souverain de l'UE interne et du cloud souverain de l'UE externe et fournir un mécanisme de filtrage.


La description de valid-vs-invalid-dns-request.png suit
Description de l'illustration valide-vs-invalid-dns-request.png

valid-vs-invalid-dns-request-oracle.zip

Fournir aux clients du cloud souverain de l'UE un accès moins restreint à l'environnement

Les clients EU Sovereign Cloud peuvent avoir besoin d'un accès moins restreint à l'environnement que les consommateurs publics des services fournis par les propriétaires de locations EU Sovereign Cloud. Ce type d'accès est réalisé par les mêmes types de connexion directe que ceux du cloud public OCI.

  • FastConnect

    FastConnect est un lien direct de commutation d'étiquettes multiprotocole (MPLS) vers les points de présence du cloud souverain de l'UE. Ces liens ne sont partagés avec aucun autre consommateur du cloud souverain de l'UE et sont dédiés à la location particulière à laquelle ils sont affectés

  • CPE (Customer Premises Equipment)

    Le CPE est un modèle de connectivité VPN permettant aux clients d'implémenter une connectivité privée de type bureau à distance à faible bande passante vers le cloud souverain de l'UE sans avoir à investir dans l'infrastructure requise pour les liaisons MPLS dédiées.

Bien que les connexions soient directes, tous les mécanismes de contrôle d'accès restent en vigueur. Par conséquent, la connectivité sur une liaison FastConnect est toujours soumise aux ensembles de règles définis par les bibliothèques de services et les groupes de sécurité réseau et peut être surveillée par NFW, le tout avec des règles différentes, basées sur les sources/destinations de connexion, par rapport à celles appliquées aux ressources publiques. L'utilisation de l'un de ces types de connexion ou des deux permet aux locataires du cloud souverain de l'UE d'établir une connectivité différente, et la combinaison des méthodes de contrôle d'accès (SL, NSG) et de la NFW fournit un mécanisme pour contrôler et surveiller étroitement l'accès aux ressources de l'environnement.

Ces fonctionnalités d'accès permettent aux utilisateurs du cloud souverain de l'UE de créer des "jardins clos" de ressources à utiliser exclusivement au sein de l'UE, comme indiqué ici :


La description de walled-garden.png suit
Description de l'image walled-garden.png

jardin clos-oracle.zip

La NFW fournit la détection d'accès de premier niveau, le rejet et la prise en charge de la journalisation, les SL fournissant une restriction de second niveau sur l'accès aux ressources au sein d'un sous-réseau particulier. Les groupes de sécurité réseau limitent davantage l'accès ressource par ressource. Les SL et les groupes de sécurité réseau peuvent disposer d'ensembles de règles bidirectionnels qui limiteraient les plages d'adresses IP sortantes/de ports. Toutefois, dans ce cas particulier, les données, la maintenance et l'administration seraient fournies à la ressource de locataire via la connexion FastConnect, qui est également limitée par les groupes de sécurité réseau et les bibliothèques de niveau de service. Les ensembles de règles définis dans les deux fonctionnalités s'appliquent également aux connexions sur FastConnect. La résolution des connexions sortantes, soit pour le lancement, soit pour valider l'appartenance au domaine des connexions entrantes, est effectuée via une combinaison d'écouteurs/transmetteurs DNS qui pointent vers des sources de résolution DNS spécifiques. Ensemble, ces fonctionnalités permettent la création d'un portail de services d'accès contrôlé et public, avec une gestion et une maintenance des données effectuées "hors bande" et limitées à l'UE.

Modèle de sécurité

OCI utilise le service Identity and Access Management (IAM) pour assurer la sécurité de la gestion "du cloud". IAM veille à ce que les opérateurs des locations au sein d'un domaine particulier puissent être limités dans leurs actions au sein de la location.

Introduction au modèle de sécurité

Pour commencer à utiliser le modèle de sécurité, procédez comme suit :

  • Créez des modèles d'accès de sécurité pour "gérer le cloud"par rapport à ceux requis pour"gérer dans le cloud". Créez un petit nombre d'utilisateurs sécurisés dans Identity and Access Management (IAM) pour la gestion du cloud.
  • Implémentez la fédération des identités pour unifier l'accès organisationnel. Utilisez des groupes distincts pour le cloud souverain de l'UE au sein de la fédération pour limiter l'accès aux personnes basées dans l'UE.
  • Gardez les identités uniques entre les comptes EU Sovereign Cloud et non EU Sovereign Cloud IAM. Cela réduit la confusion des administrateurs lors de l'administration des environnements.
  • Créez des compartiments OCI pour les ressources provisionnées en fonction des limites fonctionnelles et organisationnelles.
  • Créez des domaines d'identité pour les sous-organisations afin d'auto-administrer leurs environnements locaux.
  • Créez un environnement "sous-souverain cloud" (sous-SC) avec Cloud Guard pour surveiller les stratégies IAM.

A propos du modèle de sécurité

Le service IAM n'est pas utilisé par le personnel OCI et n'est disponible pour lui lors d'aucune phase des opérations cloud. Toutes les actions restreintes par IAM sont appliquées au niveau de la location. Bien que le personnel d'OCI utilise un système de gestion des identités et des accès pour faire fonctionner le plan de contrôle, il ne fournit aucun accès de gestion ou opérationnel directement aux locations client.


Description de l'image security_structure_overview.png
Description de l'image security_structure_overview.png

security_structure_overview-oracle.zip

IAM ne couvre que le domaine dans lequel la location elle-même existe. Dans ce cas particulier, le cloud souverain de l'UE opère dans un seul domaine actuellement composé de régions physiquement situées au sein de l'UE. Ainsi, tous les comptes créés au sein des locations EU Sovereign Cloud ne peuvent fonctionner que sur la gestion des ressources au sein du domaine lui-même et ne peuvent fonctionner que sur les ressources au sein de l'UE. Les comptes utilisateur n'ont pas de contexte en dehors du domaine et, même si un utilisateur dispose d'informations d'identification d'utilisateur identiques dans un autre domaine, il n'y a pas de contexte entrant dans le cloud souverain de l'UE.

Les comptes d'opération cloud EU Sovereign Cloud sont totalement isolés au sein du domaine. La combinaison de l'architecture de domaine d'OCI, du support et des opérations des résidents de l'UE et de la structure de l'entité juridique de l'UE renforce de manière native l'isolement du domaine du cloud souverain de l'UE. Aucune configuration supplémentaire de l'utilisateur final n'est requise pour garantir que le cloud souverain de l'UE fonctionne indépendamment des autres domaines OCI.


Description de l'image iam-2-user.png ci-après
Description de l'image iam-2-user.png

iam-2-utilisateur-oracle.zip

IAM propose à la fois des comptes locaux, gérés au sein du domaine, et des comptes fédérés liés à Identity Cloud Service (IDCS) ou à d'autres mécanismes de fédération SAML2. L'accès aux composants de déploiement et de gestion de votre location EU Sovereign Cloud peut être étroitement contrôlé et n'autoriser que les comptes approuvés comme étant basés sur l'UE à gérer l'environnement. En outre, étant donné qu'il s'agit d'un système de gestion de compte fédéré, la même fédération utilisée pour le cloud souverain de l'UE peut être utilisée pour accéder aux ressources de calcul déployées dans la location. Cela signifie créer un environnement unifié dans lequel une méthode d'accès entièrement auditable peut être déployée à la fois pour la gestion "du cloud"et pour les ressources"dans le cloud".


La description de idp-vs-iam.png suit
Description de l'image idp-vs-iam.png

idp-vs-iam-oracle.zip

Outre les fonctionnalités de compte fédéré, EU Sovereign Cloud permet de créer des domaines d'identité (ID) dans la location. Un ID est essentiellement le partitionnement de l'espace IAM, avec un ensemble secondaire d'administrateurs désignés qui n'ont pas de visibilité sur la couche supérieure du domaine et peuvent créer leur propre ensemble de stratégies d'accès et contrôler leurs propres ressources. Le propriétaire de niveau supérieur de la location peut toujours influencer le contrôle de la ressource globale et de l'administration IAM. La combinaison de l'ID avec un compartiment de niveau supérieur (non racine) permettrait aux membres d'un ID de créer un environnement complet qui ne connaît aucun des environnements qui l'entourent. Avec cet ensemble d'outils, une organisation au sein de l'UE pourrait créer ce que nous appellerons un environnement "sous-SC". C'est-à-dire un environnement qui gère les propriétés de la location d'origine, mais qui permet la création d'un environnement secondaire avec ses propres stratégies et restrictions d'appartenance.

Le concept du sous-SC est décrit plus en détail dans les études de cas illustratives ci-dessous. L'environnement de sous-service peut également être limité, contrôlé et audité en implémentant Cloud Guard dans la location. Lorsqu'elle est appliquée dans ce cas, Cloud Guard peut empêcher les compartiments affectés à un sous-service et contrôlés par un ensemble d'utilisateurs définis dans un domaine d'identité d'effectuer des actions qui seraient contraires à la protection continue des données hébergées et/ou à l'exécution d'actions qui enfreindraient les stratégies de sécurité dans l'environnement. Outre Cloud Guard, EU Sovereign Cloud propose des zones de sécurité, qui fournissent des ensembles de stratégies basés sur des compartiments qui peuvent être appliqués uniformément. Les zones de sécurité peuvent être, et sont souvent, implémentées pour augmenter les configurations Cloud Guard.

L'état, le contenu et l'inventaire du service EU Sovereign Cloud ne sont pas annoncés en dehors du domaine.

Audit et gouvernance

Les fonctionnalités et capacités du cloud souverain de l'UE fournissent des mesures actives pour s'assurer que le personnel de l'UE gère l'environnement et que les données sont protégées et restent au sein de l'UE. Toutefois, en l'absence de mécanismes permettant d'examiner ces mesures et de documenter le respect de ces mesures, il est difficile de fournir des assurances à des entités extérieures.

Introduction à l'audit et à la gouvernance

Pour commencer les activités d'audit et de gouvernance, procédez comme suit :

  • Utilisez le service OCI Audit pour surveiller et générer des actions d'application des modèles de gouvernance et de conformité.
  • Implémentez le service OCI Logging Analytics pour effectuer des analyses avancées sur les données générées par le service OCI Audit.
  • Créez des stratégies à l'aide de Threat Intelligence et de Cloud Guard pour empêcher de manière proactive les actions et les accès par des acteurs indésirables.
  • Utilisez le service OCI Tagging pour créer un espace de noms de balise correspondant à la structure organisationnelle et/ou aux modèles de coût. Balisez toutes les ressources avec des paires clé/valeur à partir des espaces de noms à des fins d'audit et/ou de refacturation.
  • Configurez des quotas dans les locations et les compartiments afin d'éviter une consommation de ressources fastidieuse.
  • Utilisez les services OCI Budgets et Cost Analysis pour prévoir, surveiller et contrôler les coûts.

A propos des services et fonctionnalités permettant de surveiller le respect de vos exigences de souveraineté des données

OCI offre des services et des fonctionnalités supplémentaires que les clients peuvent utiliser pour surveiller le respect des exigences de souveraineté des données de votre entreprise. Les contrôles et la gestion des coûts peuvent servir d'outil pour vérifier la conformité aux dépenses en ressources, détecter les menaces et s'assurer que les locations respectent les spécifications établies.

Les services OCI suivants peuvent être utilisés dans le cloud souverain de l'UE pour implémenter des stratégies d'audit et de gouvernance :
  • Audit

    OCI Audit enregistre l'heure, la source, la cible et le type d'action pour les services OCI disponibles dans le cloud souverain de l'UE. Des activités telles que la création d'instances de calcul, les opérations VCN et d'autres sont consignées pour permettre à des personnes désignées de surveiller et d'auditer l'environnement que vous avez configuré dans le cloud souverain de l'UE.

  • Logging Analytics

    Cette fonctionnalité permet au client de prendre les journaux collectés à l'aide du service Audit et de créer différentes vues et visualisations afin de répondre aux besoins de l'organisation. Les journaux d'autres sources peuvent également être ingérés afin de fournir une vue complète de l'environnement pour un audit et une analyse complets.

  • Threat Intelligence (avec Cloud Guard)

    Threat Intelligence s'appuie sur diverses sources et gère les données pour fournir des conseils pratiques en matière de détection et de prévention des menaces dans Cloud Guard et d'autres services OCI. Cloud Guard vous permet d'implémenter des actions standardisées ("recettes") capables de réagir de manière proactive aux menaces potentielles.

  • Balisage

    Alors que les entrées précédentes sont des mécanismes actifs pour prévenir, détecter et agir sur les menaces actives, d'autres éléments de l'audit et de la conformité se concentrent sur le suivi de l'utilisation et des coûts. EU Sovereign Cloud fournit des mécanismes permettant d'affecter des balises aux ressources lors du provisionnement et de corriger les valeurs et le format des balises avant leur affectation. Ces balises peuvent être interrogées via l'API, répertoriées dans le suivi des coûts et la facturation, et traitées à l'aide de stratégies IAM associées à des ressources et instances spécifiques. Utilisez Tagging pour affecter plusieurs balises à la même ressource et examiner l'utilisation des ressources sous différents angles. Par exemple, une ressource de calcul peut comporter une balise indiquant l'utilisation générale de la ressource, un groupe utilisant la ressource (par exemple, développement), un centre de coûts pour la ressource ou toute autre dimension susceptible de l'intéresser.

  • Quotas de compartiment

    Vous pouvez définir des quotas de ressource en fonction du compartiment dans lequel se trouve la ressource. Les quotas peuvent limiter le nombre et/ou la portée de la ressource définie dans la définition de quota à un compartiment, une région ou un domaine de disponibilité particulier.

  • Budgets

    Les budgets sont un outil qui permet aux clients de configurer des alertes en fonction d'une limite de dépenses actuelle, d'un plafond de dépenses prédictif ou des deux, en fonction de l'intention de l'alerte. Basez les alertes de budget sur les balises de suivi des coûts, le compartiment, la ressource ou les deux.

  • Analyse des coûts

    L'outil d'analyse des coûts vous aide à ventiler les coûts de consommation actuels entre les dimensions. Visualiser les coûts via une combinaison de vecteurs tels que la location, la région de cloud souverain pour l'UE, les compartiments et les balises de ressource, ainsi que sur les ressources, services et SKU spécifiques consommés. Les rapports peuvent être filtrés vers des ressources individuelles, le cas échéant. Vous pouvez également prévoir l'utilisation future en fonction des modèles de consommation passés à l'aide de cet outil. Les données sont extensibles aux tableaux de bord et accessibles via des API. Vous pouvez également planifier une exécution régulière d'un rapport sur les coûts et transmettre les résultats à un bucket de banque d'objets. Ces rapports peuvent être stockés pour référence historique et exportés vers un entrepôt de données pour analyse et traitement des tendances à long terme.