Documentation Oracle Cloud Infrastructure

Intégration aux tables d'application de base de données

Présentation : Intégrer Oracle Access Governance aux tables d'application de base de données

Oracle Access Governance peut être intégré aux tables d'application de base de données, ce qui permet l'orchestration des identités, y compris l'intégration des données d'identité (utilisateur) et le provisionnement des comptes.

Les tables d'application de base de données peuvent être définies en tant qu'applications personnalisées orientées base de données. En matière d'administration des identités, ces applications se caractérisent par les éléments suivants :
  • Les applications n'ont aucune API pour l'administration des identités
  • Chaque application peut avoir un ensemble différent de schémas pour les données d'identité, de compte et de droit d'accès
  • Le schéma d'application est inconnu d'Oracle Access Governance avant la configuration et l'exécution de l'intégration
  • Il n'existe pas de mapping direct entre les tables de base de données d'application et les entités Oracle Access Governance
  • Il n'existe pas de modèle commun d'organisation des données d'identité au sein du schéma d'application. Les données d'identité peuvent se trouver dans une seule table ou être réparties dans plusieurs tables.

L'intégration des tables d'application de base de données permet l'échange de données utilisateur entre une base de données client et Oracle Access Governance.

L'intégration de Database Application Tables prend en charge les éléments suivants :
  • Tables d'application de base de données en tant que source d'informations d'identité faisant autorité (de confiance) permettant le rapprochement des identités créées ou modifiées dans les tables de base de données.
  • Tables d'application de base de données en tant que système géré permettant le provisionnement des comptes d'application dans les tables de base de données.

Présentation de l'architecture d'intégration des tables d'application de base de données

L'intégration aux tables d'application de base de données vous permet d'extraire des données d'identité d'un système, de les transférer vers Oracle Access Governance et de les ingérer. Une fois qu'un système est connecté, vous pouvez effectuer des tâches et des opérations de provisionnement et de résolution, telles que créer, rapprocher, mettre à jour, supprimer, désactiver/activer, ajouter/supprimer des droits d'accès et ajouter/supprimer un groupe, qui sont ensuite reflétés dans le système géré.


Architecture DBAT

Figure 1. Architecture DBAT
L'intégration des tables d'application de base de données est implémentée à l'aide d'un type de connexion basé sur un agent. Cela signifie qu'aucune connexion directe n'est disponible. Par conséquent, une connexion indirecte est établie entre Oracle Access Governance et l'instance de base de données requise à l'aide de l'agent Access Governance. L'intégration des tables d'application de base de données prend en charge les modes suivants :
  • Si vous sélectionnez le mode de configuration Source faisant autorité lorsque vous configurez un système orchestré de tables d'application de base de données, Oracle Access Governance extrait les données d'identité de l'instance de base de données et les traite comme une source d'informations d'identité faisant autorité (de confiance).
  • Si vous sélectionnez le mode de configuration Systèmes gérés, Oracle Access Governance vous permet de gérer les comptes utilisateur dans la base de données cible. Cela permet le provisionnement de nouveaux comptes dans les instances de base de données client à partir d'Oracle Access Governance.

Afin d'identifier le schéma approprié pour votre intégration, l'intégration des tables d'application de base de données offre un repérage automatique des schémas. Il s'agit du processus d'identification du schéma de base de données sous-jacent qui contient vos données utilisateur. La prise en charge est assurée pour le schéma limité Day-0, et les modifications ultérieures du schéma utilisateur sont prises en charge par Day-N, ce qui vous permet de mettre à jour le schéma avec toutes les modifications apportées aux tables de base de données et de les appliquer au schéma repéré

Les détails des tables de base de données utilisateur pertinentes sont fournis lors de la création de l'agent. Les détails du schéma sont stockés dans un fichier de schéma situé avec l'agent. Les détails du schéma peuvent être mis à jour en modifiant directement ce fichier, si nécessaire.

La connexion à la base de données contenant vos tables utilisateur s'effectue via une connexion à la base de données JDBC. L'agent peut ainsi :
  • Repérer le schéma de votre application orientée base de données
  • Effectuer des cartons de données
  • Provisionner des comptes

Un chargement complet des données d'identité et de compte pertinentes est effectué dans Oracle Access Governance chaque fois que le chargement est exécuté. S'il s'agit de la première fois que le chargement est effectué, les structures d'identité et de compte pertinentes sont créées dans Oracle Access Governance, le cas échéant. Lors des exécutions de chargement de données suivantes, toutes les données sont chargées dans Oracle Access Governance et le processus d'inclusion met à jour toutes les modifications apportées depuis le dernier chargement de données dans les artefacts d'identité et de compte appropriés.

Une fois votre système orchestré configuré, vous pouvez provisionner des comptes à l'aide du moteur de provisionnement d'Oracle Access Governance, qui prendra toute demande de comptes ou de droits d'accès et le transmettra à l'agent et à la base de données cible. Le provisionnement prend en charge les opérations de création, de mise à jour et de révocation.

En cas de perte ou d'altération du fichier de schéma, l'intégration des tables d'application de base de données permet de récupérer le fichier de schéma. Cela est utile dans des scénarios tels qu'une panne d'agent ou la perte du fichier de schéma.

Présentation fonctionnelle de l'intégration des tables d'application de base de données

L'intégration des tables d'application de base de données prend en charge les cas d'utilisation, notamment la configuration du système orchestré, le chargement de données, la création et la révocation de comptes, la modification du mot de passe, ainsi que l'affectation et la suppression de rôles.

Fonctions d'intégration prises en charge

L'intégration des tables d'application de base de données à Oracle Access Governance prend en charge les fonctions suivantes :
  • Configurer le système orchestré
  • Charger des données
  • Créer compte
  • Affecter des droits d'accès
  • Retirer les autorisations
  • Modifier le mot de passe
  • Révoquer un compte

Pour plus d'informations sur les fonctions prises en charge, reportez-vous à Présentation fonctionnelle de l'intégration d'Oracle Access Governance.

Exemple de cycle de vie d'un compte

Prenons un exemple. Vous avez créé un système orchestré connecté à l'instance de base de données MyDBAT qui contient les données utilisateur de votre organisation. Le système orchestré est configuré pour les modes Source autorisée et Système géré. Sur le premier chargement de données, les données d'identité et de compte sont chargées dans Oracle Access Governance. A ce stade, les détails suivants sont créés dans Oracle Access Governance :
  • Une identité Oracle Access Governance est créée, par exemple MyAGIdentity, comprenant des données faisant autorité telles que le nom, l'adresse électronique et l'emplacement.
  • Un compte est créé dans Oracle Access Governance pour les rôles de tables d'application de base de données existants, par exemple DBATRole_Composer.
Nous avons maintenant les éléments suivants :
  • MyAGIdentity
    • MyDBATAccount
      • DBATRole_Composer

Après un certain temps, MyAGIdentity passe à un nouveau poste au sein de son organisation nécessitant le rôle de développeur. Un groupe d'accès DBATBundle_Developer est créé dans Oracle Access Governance, qui contient les droits d'accès de développement requis. Ce groupe d'accès peut être affecté suite à une stratégie, un rôle ou une demande. Supposons que l'utilisateur demande le groupe d'accès à l'aide de l'option Demander un nouvel accès. Lors de l'approbation, la demande déclenche une opération de provisionnement qui applique les modifications à MyDBAT, en affectant les rôles Database Application Tables correspondant aux droits d'accès contenus dans le groupe d'accès DBATBundle_Developer.

Nous avons maintenant les éléments suivants :
  • MyAGIdentity
    • MyDBATAccount
      • DBATRole_Composer
      • DBATBundle_Developer
D'autres comptes peuvent être mis en correspondance avec l'identité MyAGIdentity au fil du temps à partir d'autres systèmes gérés, ce qui nous donne un profil semblable au suivant :
  • MyAGIdentity
    • MyDBATAccount
    • MyOracleDBAccount
    • MyMSTeamsAccount

MyAGIdentity est alors requis pour modifier son mot d' passe. A l'aide de la fonctionnalité Mon accès dans la console Oracle Access Governance, ils modifient leur mot de passe, ce qui propage la modification vers MyDBAT à l'aide du provisionnement Oracle Access Governance.

MyAGIdentity devient alors un rôle, ce qui signifie qu'il n'a plus besoin d'un compte sur MyDBAT. Dans ce cas, une tâche de provisionnement de révocation de compte peut être générée en révoquant le compte de l'identité dans le cadre d'une vérification d'accès. Vous pouvez également enlever leur association aux rôles de base de données client enlevant l'identité du rôle ou de la stratégie Oracle Access Governance concerné. Dans les deux cas, cela entraînera une tâche de provisionnement qui révoquera le compte de la base de données client, ainsi que tous les rôles associés. Le profil ressemble maintenant à :
  • MyAGIdentity
    • MyOracleDBAccount
    • MyMSTeamsAccount

Si le système orchestré de tables d'application de base de données est configuré en mode Source faisant autorité et que vous rendez une identité inactive, l'identité MyAGIdentity est désactivée. Dans ce cas, une tâche de provisionnement sera générée et appliquée au système géré.

Nous avons maintenant les éléments suivants :
  • MyAGIdentity (Désactivé)