Deep Data Security

La mémoire de l'agent Oracle s'intègre à Oracle Deep Data Security (Deep Sec) pour appliquer l'autorisation de l'utilisateur final dans Oracle AI Database. Deep Sec est une fonctionnalité de sécurité : ses rôles de données, ses autorisations de données et ses contextes de sécurité utilisateur déterminent les lignes de mémoire gérées qu'une demande peut lire ou modifier.

Important : Traitez les API de cette page comme des interfaces d'administration de la sécurité et de sécurité des demandes. Utilisez des identités de base de données distinctes pour l'administration des stratégies, la propriété des schémas gérés et le regroupement des connexions d'exécution. Le compte de pool d'exécution ne doit pas disposer de privilèges directs qui fournissent un accès de secours aux tables de mémoire d'agent protégées.

La présentation de la sécurité des données profondes d'Oracle décrit le modèle d'autorisation de base de données. Pour un déploiement OCI IAM complet, reportez-vous à Application de l'isolation de la mémoire de l'utilisateur final avec Deep Data Security.

Modèle de sécurité

L'intégration de la mémoire d'agent prend en charge deux stratégies :

Police Accès efficace
UserOwnRowsDeepDataSecurityPolicy Lecture et écriture des lignes de mémoire d'agent de niveau utilisateur uniquement lorsque leur propriétaire correspond à ORA_END_USER_CONTEXT.username. Les lectures de liaison de mémoire nécessitent que les deux mémoires d'adresse soient lisibles sous les stratégies affectées ; les écritures de lien nécessitent que les deux mémoires d'adresse appartiennent à cet utilisateur.
GlobalMemoriesDeepDataSecurityPolicy Lisez les lignes de mémoire non ciblées dont user_id est NULL. Cette stratégie n'autorise pas les écritures ni l'accès aux mémoires ciblées d'un autre utilisateur. Elle expose un lien de mémoire lorsque les deux mémoires d'adresse sont lisibles sous les stratégies actives. Avec cette seule stratégie, les deux endpoints doivent être des mémoires globales ; lorsqu'ils sont associés à la stratégie de ligne propre, les liens entre une mémoire détenue et une mémoire globale sont également visibles.

Les objets de stratégie sont des sélections opaques pour les API d'administration. Leurs implémentations de table gérée, de rôle de données, d'accord de données et SQL restent privées afin que la mémoire de l'agent Oracle puisse faire évoluer son schéma de base de données en toute sécurité. Les sous-classes de stratégie personnalisées ne sont pas prises en charge. Utilisez l'une des deux classes de stratégie ci-dessus.

Les stratégies sont couvertes par la combinaison de owner_schema et memory_store_id. La création ou l'affectation d'une stratégie pour un emplacement de stockage ne l'affecte pas à un autre emplacement de stockage, y compris un emplacement de stockage ayant le même ID dans un schéma propriétaire différent.

La stratégie UserOwnRowsDeepDataSecurityPolicy limite également les écritures par colonne. Les utilisateurs finaux peuvent définir des colonnes d'identité et de propriété lors de l'insertion d'une ligne propriétaire, mais ne peuvent pas modifier ces colonnes ultérieurement. La stratégie accorde la surface d'écriture suivante :

Droits d'accès en écriture au niveau colonne pour UserOwnRowsDeepDataSecurityPolicy

Table gérée Colonnes insérables Colonnes pouvant être modifiées
Thread record_id, user_id, agent_id, metadata, runtime_config, runtime_state metadata, runtime_config, runtime_state
Récapitulatif du thread record_id, thread_id, user_id, agent_id, space_id, content, metadata, status content, metadata, status
Message record_id, thread_id, user_id, agent_id, message_role, content, timestamp, metadata, expires_at, status content, timestamp, metadata, expires_at
Document record_id, message_id, thread_id, user_id, agent_id, space_id, document_type, description, blob, timestamp, metadata, document_metadata, expires_at, status description, blob, timestamp, metadata, document_metadata, expires_at
Mémoire record_id, thread_id, user_id, agent_id, memory_type, content, timestamp, metadata, expires_at, status content, timestamp, metadata, expires_at, status
Lien mémoire relation_id, source_memory_id, source_memory_user_id, target_memory_id, target_memory_user_id, relation_type, opposite_relation_type, timestamp, metadata relation_type, opposite_relation_type, timestamp, metadata
Profil d'acteur utilisateur actor_id, actor_type, information, metadata, status information, metadata
Enregistrer des blocs source_id, source_record_type, source_emb_column, chunk_seq, chunk_text, thread_id, user_id, agent_id, status et embedding lorsque le magasin persiste, vecteurs status

SELECT et DELETE restent de portée ligne. Les colonnes générées, de création et réservées telles que chunk_id, created_at et order_seq ne peuvent pas être insérées ou mises à jour par les utilisateurs finaux, sauf si elles sont explicitement répertoriées ci-dessus. La base de données vérifie également la présence d'insertions dans le prédicat de ligne. Par conséquent, le fait d'indiquer user_id comme insérable ne permet pas à un utilisateur final de créer une ligne appartenant à une autre identité. Lorsqu'une valeur UPDATE cible une colonne non modifiable d'une table qui octroie UPDATE sur d'autres colonnes, Deep Sec peut laisser la ligne inchangée en silence plutôt que générer une erreur. Les blocs d'enregistrement autorisent uniquement les mises à jour status. Le kit SDK remplace les modifications apportées à l'identité de bloc, au texte et à l'intégration de valeurs par des opérations de suppression et d'insertion. Les applications doivent utiliser les méthodes de mutation prises en charge par le kit SDK et ne doivent pas traiter l'exécution SQL directe seule comme la preuve qu'une valeur protégée a changé.

Utilisez les API d'administration dans l'ordre suivant :

  1. Créez la banque de mémoire de l'agent géré en tant que propriétaire de schéma.
  2. Appelez add_deep_data_security_policies() en tant qu'administrateur de sécurité.
  3. Appelez grant_agent_memory_policies() pour chaque groupe OCI IAM autorisé ou utilisateur final Deep Sec local.
  4. Lors de l'exécution, encapsulez chaque opération de mémoire d'agent dans OracleMemoryEndUserSecurityContext.
  5. Révoquez les affectations avant de supprimer les stratégies qui ne sont plus nécessaires.

Si les opérations d'exécution utilisent OracleDBEmbedder avec la valeur par défaut provider="database" et un modèle stocké dans Oracle AI Database, généralement un modèle ONNX, la stratégie octroie les autorisations ci-dessus aux tables de mémoire d'agent uniquement. Le rôle de données mis en correspondance du groupe IAM doit également avoir accès au modèle résidant dans la base de données. Configurez cet accès comme décrit dans Utiliser un modèle d'intégration dans la base de données avec Deep Sec avant de traiter les demandes.

OracleDBEmbedder peut également utiliser un fournisseur distant via DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDING. Cette configuration n'utilise pas de modèle résidant dans la base de données et ne nécessite pas SELECT ON MINING MODEL. Configurez séparément les informations d'identification Oracle et l'accès réseau du fournisseur distant. L'opération de mémoire de l'agent doit toujours être exécutée dans OracleMemoryEndUserSecurityContext.

Les appels d'administration valident les modifications apportées à la base de données avant de revenir. Pour connaître le rôle sous-jacent et les concepts d'octroi, reportez-vous à Configuration du contrôle d'accès aux données d'Oracle.

Vérifications d'utilisation du contexte

Le kit SDK rejette les combinaisons non sécurisées avant l'exécution du travail de l'application protégée :

Ces vérifications permettent de diagnostiquer un chemin d'exécution de kit SDK incorrect. Les autorisations d'accès aux données d'Oracle AI Database restent la limite d'autorisation et continuent à déterminer les lignes et les colonnes auxquelles un utilisateur final authentifié peut accéder.

Stratégies

classe oracleagentmemory.core.deepsec.DeepDataSecurityPolicy

Bases : object

Identifiez une stratégie de sécurité des données profondes de la mémoire d'agent Oracle prise en charge.

Les objets de stratégie sont des sélections opaques transmises aux fonctions d'administration de Deep Data Security. Instanciez UserOwnRowsDeepDataSecurityPolicy ou GlobalMemoriesDeepDataSecurityPolicy. Les détails d'implémentation des stratégies, notamment les tables gérées, les rôles de données, les autorisations d'accès aux données et le code SQL, restent privés de la mémoire de l'agent Oracle et peuvent changer d'une version à l'autre.

Cette classe n'est pas un point d'extension de stratégie personnalisée. Les sous-classes autres que les deux classes de stratégie fournies par la mémoire d'agent Oracle sont rejetées par les fonctions d'administration.

Exemples

Créez l'ensemble de stratégies pour les lignes de l'utilisateur final et les mémoires globales non ciblées :

policies = [
    UserOwnRowsDeepDataSecurityPolicy(),
    GlobalMemoriesDeepDataSecurityPolicy(),
]

classe oracleagentmemory.core.deepsec.UserOwnRowsDeepDataSecurityPolicy

Bases : DeepDataSecurityPolicy

Accordez l'accès aux lignes appartenant à l'utilisateur final authentifié.

Cette stratégie octroie SELECT de niveau ligne, INSERT et UPDATE de niveau colonne et DELETE de niveau ligne aux données appartenant à l'utilisateur. La propriété, le type d'enregistrement, les colonnes générées, de création et réservées ne peuvent pas être modifiés après insertion. Les blocs d'enregistrement peuvent être insérés et supprimés mais ne peuvent pas être mis à jour car le kit SDK les remplace par des lignes complètes. La stratégie accorde également la lecture du registre nécessaire pour initialiser une banque d'exécution. Le lien de mémoire SELECT suit la règle de visibilité d'adresse partagée, tandis que les liens INSERT, UPDATE et DELETE nécessitent que les deux mémoires d'adresse appartiennent à l'utilisateur final.

Exemples

policy = UserOwnRowsDeepDataSecurityPolicy()

classe oracleagentmemory.core.deepsec.GlobalMemoriesDeepDataSecurityPolicy

Bases : DeepDataSecurityPolicy

Accorder l'accès en lecture aux mémoires globales et aux liens entre les mémoires visibles.

Cette stratégie accorde SELECT aux lignes de mémoire dont user_id est NULL et accorde la lecture du registre nécessaire à l'initialisation d'une banque d'exécution. Son autorisation de lecture de liaison de mémoire expose un lien lorsque les deux mémoires d'adresse sont lisibles par l'utilisateur final sous les stratégies Deep Data Security affectées. Avec cette seule politique, les deux points d'extrémité doivent donc être des mémoires globales ; combiné avec la politique de ligne propre, un lien entre une mémoire détenue et une mémoire globale est également visible. Il ne permet pas d'écrire ou d'accéder aux mémoires d'un autre utilisateur.

Exemples

policy = GlobalMemoriesDeepDataSecurityPolicy()

Principaux

Une affectation cible un groupe OCI IAM transféré dans la demande personnalisée group du jeton d'accès ou un utilisateur final Deep Sec local. Les informations de groupe OCI IAM doivent être configurées en tant que réclamation personnalisée pour qu'Oracle AI Database puisse les mettre en correspondance avec un rôle de données externe. Reportez-vous à Configuration de demandes personnalisées pour les informations de groupe dans OCI IAM.

classe oracleagentmemory.core.deepsec.Principal

Bases : object

Type de base identifiant les destinataires des affectations de stratégie de mémoire d'agent.

Les ID utilisateur sont les identités de sécurité ciblées par grant_agent_memory_policies() ou revoke_agent_memory_policies(). Le principal identifie le bénéficiaire dont les rôles de données Deep Data Security ou les autorisations de données contrôlent l'accès à une banque de mémoire d'agent spécifique. Les types de principal en cours pris en charge sont les groupes OCI IAM et les utilisateurs finals de base de données locaux.

Utilisez OciGroupPrincipal pour un groupe OCI IAM ou LocalEndUserPrincipal pour un utilisateur final Deep Data Security géré par base de données. La transmission d'une instance Principal directe à une fonction d'administration n'est pas prise en charge.

classe oracleagentmemory.core.deepsec.OciGroupPrincipal

Bases : Principal

Identifiez un groupe OCI IAM qui reçoit les stratégies de mémoire d'agent.

classe oracleagentmemory.core.deepsec.LocalEndUserPrincipal

Bases : Principal

Identifier un utilisateur final Deep Data Security local recevant des stratégies.

Administration

Exécutez ces fonctions via une connexion d'administration de la sécurité dédiée. Pour les tables de mémoire d'agent inter-schéma, ce compte requiert les privilèges d'administration Deep Sec applicables, notamment CREATE ANY DATA GRANT, DROP ANY DATA GRANT et ADMINISTER ANY DATA GRANT, ainsi que l'autorisation de créer et de supprimer des rôles de données. N'accordez pas ces privilèges au compte de pool d'exécution.

oracleagentmemory.core.deepsec.add_deep_data_security_policies

Créez les rôles de données et les autorisations d'accès aux données pour les stratégies de mémoire d'agent.

Les stratégies sont ciblées sur owner_schema et memory_store_id. Leur ajout permet l'application obligatoire de Deep Data Security sur leurs tables gérées protégées. Le fait de rajouter une stratégie remplace son rôle de données géré par la mémoire de l'agent et lui accorde la définition en cours. Les appels répétés sont idémpotents. Si Oracle valide une partie du DDL de stratégie avant une interruption, une nouvelle tentative d'appel répare les définitions gérées.

Cette fonction valide la connexion avant de revenir. Utilisez une connexion d'administration de sécurité dédiée plutôt qu'une connexion d'application d'exécution ou de propriétaire de schéma.

Exemples

Ajoutez des stratégies d'accès à la mémoire propre et globale :

add_deep_data_security_policies(
    connection,
    owner_schema="MY_OWNER_SCHEMA",
    memory_store_id="MEMORY",
    policies=[
        UserOwnRowsDeepDataSecurityPolicy(),
        GlobalMemoriesDeepDataSecurityPolicy(),
    ],
)

oracleagentmemory.core.deepsec.remove_deep_data_security_policies

Supprimez les stratégies de sécurité des données approfondies de la mémoire de l'agent.

La suppression d'un rôle de stratégie enlève également ce rôle de ses autorisations de données et de ses affectations d'utilisateur final local. Les affectations OCI IAM créées en tant qu'autorisations de données externes doivent d'abord être enlevées avec revoke_agent_memory_policies(). L'application obligatoire des autorisations d'accès aux données est désactivée pour une table gérée uniquement lorsqu'aucune autorisation d'accès aux données ne reste sur cette table.

Cette fonction valide la connexion avant de revenir.

Exemples

Supprimez la stratégie de ligne propre :

remove_deep_data_security_policies(
    connection,
    owner_schema="MY_OWNER_SCHEMA",
    memory_store_id="MEMORY",
    policies=[UserOwnRowsDeepDataSecurityPolicy()],
)

oracleagentmemory.core.deepsec.list_deep_data_security_policies

Répertoriez les stratégies de mémoire d'agent actuellement créées dans Oracle AI Database.

Exemples

Examinez les types de stratégie configurés :

policies = list_deep_data_security_policies(
    connection,
    owner_schema="MY_OWNER_SCHEMA",
    memory_store_id="MEMORY",
)
[type(policy).__name__ for policy in policies]
['UserOwnRowsDeepDataSecurityPolicy']

oracleagentmemory.core.deepsec.grant_agent_memory_policies

Accordez des stratégies de mémoire d'agent aux groupes OCI IAM ou aux utilisateurs finaux locaux.

Les groupes OCI IAM sont représentés par des rôles de données mis en correspondance en externe. Les autorisations d'accès aux données pour chaque stratégie sont attachées directement à ce rôle mis en correspondance car Oracle AI Database n'autorise pas les rôles de données mis en correspondance en externe à recevoir des rôles de données gérés localement.

Créez chaque stratégie pour la banque cible avec add_deep_data_security_policies() avant de l'affecter. Cette fonction valide la connexion avant de revenir. Les appels répétés sont idémpotents. Si Oracle valide une partie d'une affectation OCI IAM avant une interruption, le fait de réessayer le même appel recrée les octrois de données gérées manquants.

Exemples

Accordez un accès de ligne propre à un groupe OCI IAM :

grant_agent_memory_policies(
    connection,
    memory_store_id="MEMORY",
    owner_schema="MY_OWNER_SCHEMA",
    principals=[OciGroupPrincipal("ORACLEAGENTMEMORY_USERS")],
    policies=[UserOwnRowsDeepDataSecurityPolicy()],
)

oracleagentmemory.core.deepsec.revoke_agent_memory_policies

Révoquez les stratégies de mémoire d'agent des groupes OCI IAM ou des utilisateurs finaux locaux.

Le principal lui-même est préservé. En particulier, le rôle de données mis en correspondance en externe d'un groupe OCI IAM reste disponible pour les affectations à partir de cette banque de mémoire d'agent ou d'une autre.

La révocation modifie l'état et la validation de la stratégie de base de données avant le renvoi, de sorte que les instructions de base de données protégées suivantes ne reçoivent plus la stratégie révoquée. Cette opération est distincte de la suppression d'un utilisateur d'un groupe OCI IAM : un jeton d'accès déjà émis conserve sa demande de groupe imbriquée jusqu'à ce que ce jeton expire.

Exemples

Révoquez l'accès de ligne propre à un groupe OCI IAM :

revoke_agent_memory_policies(
    connection,
    memory_store_id="MEMORY",
    owner_schema="MY_OWNER_SCHEMA",
    principals=[OciGroupPrincipal("ORACLEAGENTMEMORY_USERS")],
    policies=[UserOwnRowsDeepDataSecurityPolicy()],
)

oracleagentmemory.core.deepsec.list_agent_memory_granted_policies

Répertoriez les principaux et les stratégies de mémoire d'agent affectés à chaque principal.

Exemples

Répertoriez les affectations de stratégie :

assignments = list_agent_memory_granted_policies(
    connection,
    memory_store_id="MEMORY",
    owner_schema="MY_OWNER_SCHEMA",
)
len(assignments) >= 0
True

Contexte de sécurité d'exécution

OracleMemoryEndUserSecurityContext étend le contexte de sécurité python-oracledb aux opérations de mémoire d'agent. Le contexte contient le jeton d'utilisateur final et le jeton d'accès à la base de données. Oracle AI Database les valide et dérive les rôles de données actifs de leurs demandes. Le kit SDK associe le contexte à chaque connexion physique acquise et l'efface avant de renvoyer cette connexion au pool.

Reportez-vous au contexte de sécurité de l'utilisateur final d'Oracle pour le modèle de sécurité et à la section How the Database Server Manages an End-User Security Context pour la validation, la résolution des rôles, la réutilisation des connexions et le nettoyage du contexte.

classe oracleagentmemory.core.deepsec.OracleMemoryEndUserSecurityContext

Bases : object

Appliquez un contexte de sécurité utilisateur final Oracle aux opérations de mémoire d'agent.

Si vous entrez dans ce gestionnaire de contexte, security_context est disponible pour les banques de mémoire d'agent sauvegardées par Oracle utilisées dans le contexte d'exécution en cours. Chaque opération de base de données applique le contexte après l'acquisition de sa connexion physique, vérifie qu'une identité d'utilisateur final est active et efface le contexte avant de libérer la connexion. Ce comportement fonctionne à la fois avec les connexions directes et les pools de connexions.

La portée est propagée aux appels de mémoire d'agent asynchrones en attente. Les tâches d'appel qui survivent au bloc with ou async with ne peuvent pas utiliser la portée expirée. Les travaux d'extraction de mémoire d'arrière-plan acceptés dans le bloc conservent un instantané privé afin qu'ils puissent se terminer après la sortie du bloc.

Utilisez une nouvelle valeur oracledb.EndUserSecurityContext lorsque l'utilisateur final ou le jeton d'accès à la base de données change. Oracle AI Database dérive les rôles de données activés des demandes dans le jeton fourni ; ce gestionnaire n'actualise, ne révoque ni n'inspecte les jetons OAuth.

Notes

Cette classe étend les opérations de mémoire d'agent Oracle. Elle ne modifie pas une connexion arbitraire utilisée directement par SQL d'application en dehors du kit SDK. L'imbrication est prise en charge, y compris l'imbrication de la même instance de gestionnaire. Chaque sortie restaure le contexte à partir de son entrée correspondante.

Exemples

Appliquez un contexte dérivé d'OAuth aux opérations de mémoire d'agent synchrone :

import oracledb
from oracleagentmemory.core.deepsec import (
    OracleMemoryEndUserSecurityContext,
)
user_context = oracledb.create_end_user_security_context(
    end_user_identity=end_user_token,
    database_access_token=database_access_token,
)
with OracleMemoryEndUserSecurityContext(user_context):
    memory_store.add(
        ["Remember this preference."],
        record_type="memory",
    )

Le même gestionnaire prend en charge les appels asynchrones :

async with OracleMemoryEndUserSecurityContext(user_context):
    await memory_store.add_async(
        ["Remember this preference."],
        record_type="memory",
    )

method __aenter__ (async)

Entrez la portée des opérations de mémoire d'agent en attente.

method __aexit__ (async)

Quittez la portée asynchrone sans supprimer les exceptions de bloc.

méthode __enter__

Saisissez la portée et renvoyez ce gestionnaire de contexte.

Les opérations de mémoire d'agent démarrées dans le contexte d'exécution en cours utilisent le contexte de sécurité de l'utilisateur final de ce gestionnaire jusqu'à la sortie correspondante.

méthode __exit__

Quittez la portée et empêchez les tâches d'appel héritées de la réutiliser.

Toute exception du bloc géré est propagée sans modification.

oracleagentmemory.core.deepsec.get_end_user_username

Renvoie le nom utilisateur final attaché à une connexion Oracle DB.

Deep Data Security évalue les autorisations d'accès aux données à l'aide du contexte de sécurité de l'utilisateur final attaché à une connexion de base de données. Cette aide lit l'attribut username à partir de ce contexte. Il ne renvoie pas le compte de base de données utilisé pour établir la connexion physique.

Exemples

Vérifiez si une connexion est associée à une identité d'utilisateur final :

get_end_user_username(conn) is None
True

Audit

Deep Sec utilise l'audit unifié Oracle AI Database. Un administrateur de base de données peut créer des stratégies d'audit unifié pour les opérations de configuration Deep Sec, telles que la création ou la suppression de rôles de données et d'autorisations d'accès aux données, l'octroi ou la révocation de rôles de données, ainsi que la création ou la suppression de contextes utilisateur et utilisateur final. Les enregistrements d'audit sont disponibles via UNIFIED_AUDIT_TRAIL et peuvent inclure l'identité de l'utilisateur final et l'identificateur de contexte de sécurité pour l'activité effectuée sous un contexte de sécurité de l'utilisateur final.

L'action CREATE END USER SECURITY CONTEXT enregistre la création de contexte de sécurité. Oracle note qu'il peut générer de nombreux enregistrements et qu'il n'est pas inclus par ACTIONS ALL. Indiquez-le explicitement lorsque cet événement de cycle de vie doit être audité. Sélectionnez les actions d'audit et la conservation en fonction des exigences de sécurité et de conformité du déploiement. Les journaux d'application SDK sont des diagnostics et ne remplacent pas la trace d'audit de la base de données.

Reportez-vous à Audit des opérations de sécurité des données profondes d'Oracle et à la liste officielle des actions d'audit de sécurité profonde.

Contrat de temps de révocation

La révocation de stratégie de base de données et la suppression de l'appartenance à un groupe OCI IAM ont des dates d'effet différentes :

Action d'administration Heure de validité
Appelez revoke_agent_memory_policies() La fonction supprime l'affectation de base de données propre au magasin et effectue des validations avant de revenir. Les instructions de base de données protégées suivantes ne reçoivent plus cette stratégie. Une instruction déjà en cours d'exécution n'est pas annulée rétroactivement.
Enlever un utilisateur du groupe de bénéficiaires dans OCI IAM Les jetons d'accès nouvellement émis reflètent l'appartenance mise à jour. Un jeton d'accès déjà émis pour l'utilisateur contient toujours sa demande group et peut continuer à autoriser le rôle de données Deep Sec correspondant jusqu'à ce que ce jeton expire.

La limite supérieure effective pour la révocation uniquement IAM est donc la durée de vie restante dans la demande exp du jeton émis. La durée de vie du jeton d'accès OCI IAM est configurable. Lorsqu'aucune application de ressource, session utilisateur ou expiration personnalisée n'est définie, la valeur par défaut documentée est de 3600 secondes. Les applications doivent cesser de réutiliser un jeton expiré et obtenir un nouveau jeton dont les revendications reflètent l'appartenance actuelle.

Pour une révocation urgente, appelez d'abord revoke_agent_memory_policies() pour enlever immédiatement l'affectation de base de données pour les instructions suivantes, puis enlevez l'utilisateur du groupe OCI IAM. Réoctroyez la stratégie de base de données uniquement lorsque le groupe dans son ensemble doit retrouver l'accès. Si un seul membre doit être enlevé pendant que le groupe reste autorisé, comptez sur l'expiration du jeton ou utilisez une stratégie de réauthentification et une durée de vie de jeton d'accès plus courte propre au déploiement.

Reportez-vous aux sections Gestion de l'autorisation à l'aide de l'API et Table d'expiration de jeton d'OCI IAM, ainsi qu'aux références de cycle de vie de contexte de sécurité Deep Sec ci-dessus.