Deep Data Security

Oracle Agent Memory lässt sich in Oracle Deep Data Security (Deep Sec) integrieren, um die Endbenutzerautorisierung in Oracle AI Database durchzusetzen. Deep Sec ist ein Sicherheitsfeature: Seine Datenrollen, Datenzugriffsberechtigungen und Endbenutzersicherheitskontexte bestimmen, welche verwalteten Speicherzeilen eine Anforderung lesen oder ändern kann.

Wichtig: Behandeln Sie die APIs auf dieser Seite als Schnittstellen für Sicherheitsadministration und Anforderungssicherheit. Verwenden Sie separate Datenbankidentitäten für Policy-Administration, Managed-Schema-Eigentümerschaft und Runtime Connection Pooling. Der Laufzeitpoolaccount darf keine direkten Berechtigungen haben, die Fallback-Zugriff auf geschützte Agent-Speichertabellen ermöglichen.

In Deep Data Security – Überblick von Oracle wird das Datenbankautorisierungsmodell beschrieben. Ein vollständiges OCI IAM-Deployment finden Sie unter Endbenutzerspeicherisolation mit umfassender Datensicherheit durchsetzen.

Sicherheitsmodell

Die Agent Memory-Integration unterstützt zwei Policys:

Police Effektiver Zugang
UserOwnRowsDeepDataSecurityPolicy Agent-Speicherzeilen mit Benutzergeltungsbereich nur lesen und schreiben, wenn ihr Eigentümer ORA_END_USER_CONTEXT.username entspricht. Für Memory-Link-Lesevorgänge müssen beide Endpunktspeicher unter den zugewiesenen Policys lesbar sein. Für Link-Schreibvorgänge müssen beide Endpunktspeicher zu diesem Benutzer gehören.
GlobalMemoriesDeepDataSecurityPolicy Lesen Sie nicht kopierte Speicherzeilen, deren user_id NULL ist. Diese Policy gewährt keine Schreibvorgänge oder keinen Zugriff auf die Speicherbereiche eines anderen Benutzers. Es wird ein Memory Link angezeigt, wenn beide Endpunktspeicher unter den aktiven Policys lesbar sind. Nur bei dieser Policy müssen beide Endpunkte globale Speicher sein. In Kombination mit der eigenen Zeilen-Policy sind auch Verbindungen zwischen einem eigenen Speicher und einem globalen Speicher sichtbar.

Policy-Objekte sind undurchsichtige Auswahlen für die Administrations-APIs. Die verwalteten Tabellen-, Data-Role-, Data-Grant- und SQL-Implementierungen bleiben privat, sodass Oracle Agent Memory sein Datenbankschema sicher weiterentwickeln kann. Benutzerdefinierte Policy-Unterklassen werden nicht unterstützt. Verwenden Sie eine der beiden oben genannten Policy-Klassen.

Policys gelten für die Kombination aus owner_schema und memory_store_id. Das Erstellen oder Zuweisen einer Policy für einen Speicher weist sie keinem anderen Speicher zu, einschließlich eines Speichers mit derselben ID in einem anderen Eigentümerschema.

Die Policy UserOwnRowsDeepDataSecurityPolicy begrenzt auch Schreibvorgänge nach Spalte. Endbenutzer können Identitäts- und Eigentümerspalten festlegen, wenn sie eine eigene Zeile einfügen. Diese Spalten können jedoch später nicht mehr geändert werden. Die Policy gewährt die folgende Schreiboberfläche:

Schreibberechtigungen auf Spaltenebene für UserOwnRowsDeepDataSecurityPolicy

Verwaltete Tabelle Einfügbare Spalten Aktualisierbare Spalte
Thread record_id, user_id, agent_id, metadata, runtime_config, runtime_state metadata, runtime_config, runtime_state
Threadübersicht record_id, thread_id, user_id, agent_id, space_id, content, metadata, status content, metadata, status
Nachricht record_id, thread_id, user_id, agent_id, message_role, content, timestamp, metadata, expires_at, status content, timestamp, metadata, expires_at
Dokument 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
Arbeitsspeicher record_id, thread_id, user_id, agent_id, memory_type, content, timestamp, metadata, expires_at, status content, timestamp, metadata, expires_at, status
Speicherlink 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
Benutzerdarstellerprofil actor_id, actor_type, information, metadata, status information, metadata
Blöcke aufzeichnen source_id, source_record_type, source_emb_column, chunk_seq, chunk_text, thread_id, user_id, agent_id, status und embedding, wenn der Speicher Vektoren enthält status

SELECT und DELETE bleiben im Zeilenbereich. Generierte, Erstellungszeit- und reservierte Spalten wie chunk_id, created_at und order_seq können von Endbenutzern nur eingefügt oder aktualisiert werden, wenn sie oben explizit aufgeführt sind. Die Datenbank prüft auch das Zeilenprädikat auf Einfügungen, sodass die Auflistung von user_id als einfügbar nicht erlaubt, dass ein Endbenutzer eine Zeile erstellt, die zu einer anderen Identität gehört. Wenn eine UPDATE auf eine nicht aktualisierbare Spalte in einer Tabelle abzielt, die UPDATE für andere Spalten erteilt, kann Deep Sec die Zeile unverändert lassen, anstatt einen Fehler auszulösen. Datensatz-Chunks erlauben nur status-Updates. Das SDK ersetzt Änderungen an Chunk-Identität, Text und Einbettungswerten durch Lösch- und Einfügevorgänge. Anwendungen sollten die unterstützten Mutationsmethoden des SDK verwenden und dürfen die direkte SQL-Ausführung nicht allein als Beweis dafür behandeln, dass sich ein geschützter Wert geändert hat.

Verwenden Sie die Administrations-APIs in folgender Reihenfolge:

  1. Erstellen Sie den verwalteten Agent-Speicherspeicher als Schemaeigentümer.
  2. Rufen Sie add_deep_data_security_policies() als Sicherheitsadministrator auf.
  3. Rufen Sie grant_agent_memory_policies() für jede autorisierte OCI-IAM-Gruppe oder jeden lokalen Deep Sec-Endbenutzer auf.
  4. Wrapping aller Agent-Speichervorgänge zur Laufzeit in OracleMemoryEndUserSecurityContext.
  5. Entziehen Sie Zuweisungen, bevor Sie Policys entfernen, die nicht mehr benötigt werden.

Wenn Laufzeitvorgänge OracleDBEmbedder mit dem Standard provider="database" und einem Modell verwenden, das in Oracle AI Database gespeichert ist, in der Regel ein ONNX-Modell, autorisiert die Policy oben nur Agent-Speichertabellen. Die zugeordnete Datenrolle der IAM-Gruppe muss auch Zugriff auf das datenbankresidente Modell haben. Konfigurieren Sie diesen Zugriff wie unter Datenbankinternes Einbettungsmodell mit Deep Sec verwenden beschrieben, bevor Sie Anforderungen bearbeiten.

OracleDBEmbedder kann auch einen Remoteprovider über DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDING verwenden. Diese Konfiguration verwendet kein datenbankresidentes Modell und erfordert nicht SELECT ON MINING MODEL. Konfigurieren Sie die Oracle-Zugangsdaten und den Netzwerkzugriff des Remoteproviders separat. Der Agent-Speichervorgang muss weiterhin in OracleMemoryEndUserSecurityContext ausgeführt werden.

Die Administrationsaufrufe schreiben ihre Datenbankänderungen vor der Rückkehr fest. Informationen zu den zugrunde liegenden Rollen- und Berechtigungskonzepten finden Sie in der Data Access Control-Konfiguration von Oracle.

Kontextbezogene Prüfungen

Das SDK lehnt unsichere Kombinationen ab, bevor geschützte Anwendungsarbeiten ausgeführt werden:

Diese Prüfungen diagnostizieren einen falschen SDK-Ausführungspfad. Oracle AI Database-Datenzugriffsberechtigungen bleiben die Autorisierungsgrenze und bestimmen weiterhin, auf welche Zeilen und Spalten ein authentifizierter Endbenutzer zugreifen kann.

Policys

Klasse oracleagentmemory.core.deepsec.DeepDataSecurityPolicy

Basis: object

Identifizieren Sie eine unterstützte Oracle Agent Memory Deep Data Security Policy.

Policy-Objekte sind undurchsichtige Auswahlen, die an die Administrationsfunktionen von Deep Data Security übergeben werden. Instanziieren Sie UserOwnRowsDeepDataSecurityPolicy oder GlobalMemoriesDeepDataSecurityPolicy. Details zur Policy-Implementierung, einschließlich verwalteter Tabellen, Datenrollen, Datenzugriffsberechtigungen und SQL, bleiben für Oracle Agent Memory privat und können sich zwischen Releases ändern.

Diese Klasse ist kein benutzerdefinierter Policy-Erweiterungspunkt. Andere Unterklassen als die beiden von Oracle Agent Memory bereitgestellten Policy-Klassen werden von den Administrationsfunktionen abgelehnt.

Beispiele

Erstellen Sie das Policy-Set für Endbenutzerzeilen und nicht kopierte globale Speicher:

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

Klasse oracleagentmemory.core.deepsec.UserOwnRowsDeepDataSecurityPolicy

Basis: DeepDataSecurityPolicy

Zugriff auf Zeilen erteilen, deren Eigentümer der authentifizierte Endbenutzer ist

Diese Policy erteilt zeilenbezogene SELECT, spaltenbezogene INSERT und UPDATE und zeilenbezogene DELETE für benutzerdefinierte Daten. Verantwortlichkeit, Datensatztyp, generierte, Erstellungszeit und reservierte Spalten können nach dem Einfügen nicht mehr geändert werden. Datensatz-Chunks können eingefügt und gelöscht, aber nicht aktualisiert werden, da das SDK sie als vollständige Zeilen ersetzt. Die Policy erteilt auch den Registry-Lesevorgang, der zum Initialisieren eines Laufzeitspeichers erforderlich ist. Memory-Link SELECT folgt der gemeinsamen Endpunktsichtbarkeitsregel, während für Link INSERT, UPDATE und DELETE beide Endpunktspeicher zum Endbenutzer gehören müssen.

Beispiele

policy = UserOwnRowsDeepDataSecurityPolicy()

Klasse oracleagentmemory.core.deepsec.GlobalMemoriesDeepDataSecurityPolicy

Basis: DeepDataSecurityPolicy

Erteilen Sie Lesezugriff auf globale Erinnerungen und Verbindungen zwischen sichtbaren Erinnerungen.

Diese Policy erteilt SELECT für Speicherzeilen, deren user_id NULL ist, und erteilt dem Registry-Lesevorgang, der zum Initialisieren eines Laufzeitspeichers erforderlich ist. Die Memory-Link-Leseberechtigung zeigt einen Link an, wenn beide Endpunktspeicher vom Endbenutzer unter den zugewiesenen Deep Data Security-Policys lesbar sind. Nur mit dieser Richtlinie müssen beide Endpunkte globale Speicher sein; in Kombination mit der eigenen Zeilen-Policy ist auch eine Verbindung zwischen einem eigenen Speicher und einem globalen Speicher sichtbar. Es ermöglicht keine Schreibvorgänge oder keinen Zugriff auf die Speicherbereiche eines anderen Benutzers.

Beispiele

policy = GlobalMemoriesDeepDataSecurityPolicy()

Principals

Eine Zuweisung zielt entweder auf eine OCI-IAM-Gruppe ab, die im benutzerdefinierten Claim group des Zugriffstokens oder auf einen lokalen Deep Sec-Endbenutzer übertragen wird. OCI-IAM-Gruppeninformationen müssen als benutzerdefinierter Claim konfiguriert werden, bevor Oracle AI Database sie einer externen Datenrolle zuordnen kann. Siehe Benutzerdefinierte Claims für Gruppeninformationen in OCI IAM konfigurieren.

Klasse oracleagentmemory.core.deepsec.Principal

Basis: object

Basistyp, der angibt, wer Agent Memory Policy-Zuweisungen empfängt.

Principals sind die Sicherheitsidentitäten, die von grant_agent_memory_policies() oder revoke_agent_memory_policies() angestrebt werden. Der Principal identifiziert den Berechtigten, dessen Deep Data Security-Datenrollen oder -Daten den Zugriff auf einen bestimmten Agent-Speicherspeicher steuern. Unterstützte aktuelle Principal-Typen sind OCI-IAM-Gruppen und lokale DB-Endbenutzer.

Verwenden Sie OciGroupPrincipal für eine OCI-IAM-Gruppe oder LocalEndUserPrincipal für einen datenbankverwalteten Deep Data Security-Endbenutzer. Das Übergeben einer direkten Principal-Instanz an eine Administrationsfunktion wird nicht unterstützt.

Klasse oracleagentmemory.core.deepsec.OciGroupPrincipal

Basis: Principal

Identifizieren Sie eine OCI-IAM-Gruppe, die Agent-Speicher-Policys empfängt.

Klasse oracleagentmemory.core.deepsec.LocalEndUserPrincipal

Basis: Principal

Identifizieren Sie einen lokalen Deep Data Security-Endbenutzer, der Policys empfängt.

Administration

Führen Sie diese Funktionen über eine dedizierte Verbindung zur Sicherheitsadministration aus. Für plattformübergreifende Agent-Speichertabellen benötigt dieser Account die anwendbaren Deep Sec-Administrationsberechtigungen, einschließlich CREATE ANY DATA GRANT, DROP ANY DATA GRANT und ADMINISTER ANY DATA GRANT, sowie die Berechtigung zum Erstellen und Löschen von Datenrollen. Erteilen Sie dem Laufzeitpoolkonto diese Berechtigungen nicht.

oracleagentmemory.core.deepsec.add_deep_data_security_policies

Erstellen Sie die Datenrollen und Datenzugriffsberechtigungen für Agent Memory Policys.

Die Policys haben einen Geltungsbereich von owner_schema und memory_store_id. Wenn Sie sie hinzufügen, wird die erforderliche Deep Data Security-Durchsetzung für ihre geschützten verwalteten Tabellen aktiviert. Das erneute Hinzufügen einer Policy ersetzt die vom Agent-Speicher verwaltete Datenrolle und erteilt die Berechtigungen mit der aktuellen Definition. Wiederholte Anrufe sind idempotent. Wenn Oracle einen Teil der Policy-DDL vor einer Unterbrechung festschreibt, repariert derselbe Aufruf die verwalteten Definitionen.

Diese Funktion schreibt die Verbindung vor der Rückgabe fest. Verwenden Sie eine dedizierte Verbindung zur Sicherheitsadministration anstelle einer Verbindung zu einem Schemaeigentümer oder einer Laufzeitanwendung.

Beispiele

Fügen Sie Zugriffs-Policys für eigene Zeilen und globale Speicher hinzu:

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

Entfernen Sie Deep Data Security-Policys für den Agent-Speicher.

Wenn Sie eine Policy-Rolle löschen, wird diese Rolle auch aus den Datenzugriffsberechtigungen und lokalen Endbenutzerzuweisungen entfernt. OCI-IAM-Zuweisungen, die als externe Datenzugriffsberechtigungen erstellt wurden, müssen zuerst mit revoke_agent_memory_policies() entfernt werden. Die obligatorische Durchsetzung von Datenzugriffsberechtigungen ist nur dann für eine verwaltete Tabelle deaktiviert, wenn keine Datenzugriffsberechtigungen für diese Tabelle verbleiben.

Diese Funktion schreibt die Verbindung vor der Rückgabe fest.

Beispiele

Entfernen Sie die eigene Zeilen-Policy:

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

Agent-Speicher-Policys auflisten, die derzeit in Oracle AI Database erstellt sind.

Beispiele

Konfigurierte Policy-Typen prüfen:

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

Erteilen Sie OCI-IAM-Gruppen oder lokalen Endbenutzern Agent-Speicher-Policys.

OCI-IAM-Gruppen werden durch extern zugeordnete Datenrollen dargestellt. Datenzugriffsberechtigungen für jede Policy werden direkt an diese zugeordnete Rolle angehängt, da Oracle AI Database nicht zulässt, dass extern zugeordnete Datenrollen lokal verwaltete Datenrollen erhalten.

Erstellen Sie jede Policy für den Zielspeicher mit add_deep_data_security_policies(), bevor Sie sie zuweisen. Diese Funktion schreibt die Verbindung vor der Rückgabe fest. Wiederholte Anrufe sind idempotent. Wenn Oracle einen Teil einer OCI-IAM-Zuweisung vor einer Unterbrechung festschreibt, werden durch Wiederholung desselben Aufrufs die fehlenden verwalteten Datenberechtigungen neu erstellt.

Beispiele

Erteilen Sie einer OCI-IAM-Gruppe Zugriff auf eigene Zeilen:

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

Entziehen Sie Agent-Speicher-Policys OCI-IAM-Gruppen oder lokalen Endbenutzern.

Das Prinzip selbst bleibt erhalten. Insbesondere bleibt die extern zugeordnete Datenrolle einer OCI-IAM-Gruppe für Zuweisungen aus diesem oder einem anderen Agent-Speicherspeicher verfügbar.

Der Widerruf ändert den Status der Datenbank-Policy und schreibt sie vor der Rückgabe fest, sodass nachfolgende geschützte Datenbankanweisungen die entzogene Policy nicht mehr erhalten. Dies unterscheidet sich davon, einen Benutzer aus einer OCI-IAM-Gruppe zu entfernen: Ein bereits ausgestelltes Zugriffstoken behält seinen eingebetteten Gruppenanspruch, bis dieses Token abläuft.

Beispiele

Eigenen Zeilenzugriff einer OCI-IAM-Gruppe entziehen:

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

Listen Sie Principals und Agent Memory Policys auf, die jedem Principal zugewiesen sind.

Beispiele

Policy-Zuweisungen auflisten:

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

Laufzeitsicherheitskontext

OracleMemoryEndUserSecurityContext legt den python-oracledb-Sicherheitskontext für Agent-Speichervorgänge fest. Der Kontext enthält das Endbenutzertoken und das Datenbankzugriffstoken. Oracle AI Database validiert sie und leitet aktive Datenrollen aus ihren Claims ab. Das SDK ordnet den Kontext jeder erworbenen physischen Verbindung zu und löscht ihn, bevor diese Verbindung an den Pool zurückgegeben wird.

Informationen zum Sicherheitsmodell finden Sie unter Endbenutzersicherheitskontext von Oracle und unter So verwaltet der Datenbankserver einen Endbenutzersicherheitskontext für Validierung, Rollenauflösung, Wiederverwendung von Verbindungen und Bereinigung von Kontexten.

Klasse oracleagentmemory.core.deepsec.OracleMemoryEndUserSecurityContext

Basis: object

Wenden Sie einen Oracle-Endbenutzersicherheitskontext auf Agent-Speichervorgänge an.

Wenn Sie diesen Kontextmanager eingeben, wird security_context für von Oracle unterstützte Agent-Speicherspeicher verfügbar, die im aktuellen Ausführungskontext verwendet werden. Jeder Datenbankvorgang wendet den Kontext an, nachdem seine physische Verbindung hergestellt wurde. Er überprüft, ob eine Endbenutzer-Identity aktiv ist, und löscht den Kontext, bevor die Verbindung freigegeben wird. Dieses Verhalten funktioniert sowohl mit direkten Verbindungen als auch mit Verbindungspools.

Der Geltungsbereich wird an erwartete asynchrone Agent-Speicheraufrufe propagiert. Aufruferaufgaben, die den Block with oder async with überleben, können den abgelaufenen Geltungsbereich nicht verwenden. Hintergrundspeicherextraktionsjobs, die innerhalb des Blocks akzeptiert werden, behalten einen privaten Snapshot bei, damit sie nach dem Beenden des Blocks abgeschlossen werden können.

Verwenden Sie eine neue oracledb.EndUserSecurityContext, wenn sich das Endbenutzer- oder Datenbankzugriffstoken ändert. Oracle AI Database leitet die aktivierten Datenrollen aus den Claims im angegebenen Token ab. Dieser Manager aktualisiert, entzieht oder prüft keine OAuth-Token.

Hinweise

Diese Klasse umfasst Oracle Agent-Speichervorgänge. Eine beliebige Verbindung, die direkt von Anwendungs-SQL außerhalb des SDK verwendet wird, wird nicht geändert. Die Verschachtelung wird unterstützt, einschließlich der Verschachtelung derselben Managerinstanz. Jeder Exit stellt den Kontext aus seinem übereinstimmenden Eintrag wieder her.

Beispiele

Von OAuth abgeleiteten Kontext auf synchrone Agent-Speichervorgänge anwenden:

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",
    )

Derselbe Manager unterstützt asynchrone Aufrufe:

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

Methode __aenter__ (asynchron)

Geben Sie den Geltungsbereich für erwartete Agent-Speichervorgänge ein.

Methode __aexit__ (asynchron)

Beenden Sie den asynchronen Geltungsbereich, ohne Block Exceptions zu unterdrücken.

Methode __enter__

Geben Sie den Geltungsbereich ein, und geben Sie diesen Kontextmanager zurück.

Agent-Speichervorgänge, die im aktuellen Ausführungskontext gestartet wurden, verwenden den Endbenutzersicherheitskontext dieses Managers bis zum Ende des Abgleichs.

Methode __exit__

Beenden Sie den Geltungsbereich, und verhindern Sie, dass geerbte Aufrufer-Aufgaben ihn wiederverwenden.

Jede Exception aus dem verwalteten Block wird unverändert propagiert.

oracleagentmemory.core.deepsec.get_end_user_username

Geben Sie den Endbenutzerbenutzernamen zurück, der an eine Oracle DB-Verbindung angehängt ist.

Deep Data Security wertet Datenzugriffsberechtigungen anhand des Endbenutzersicherheitskontexts aus, der an eine Datenbankverbindung angehängt ist. Dieser Helper liest das Attribut username aus diesem Kontext. Es wird nicht das Datenbankkonto zurückgegeben, mit dem die physische Verbindung hergestellt wird.

Beispiele

Prüfen Sie, ob eine Verbindung eine angehängte Endbenutzeridentität aufweist:

get_end_user_username(conn) is None
True

Auditing

Deep Sec verwendet Oracle AI Database Unified Auditing. Ein Datenbankadministrator kann einheitliche Audit-Policys für Deep Sec-Konfigurationsvorgänge erstellen, wie das Erstellen oder Löschen von Datenrollen und Datenzugriffsberechtigungen, das Erteilen oder Entziehen von Datenrollen sowie das Erstellen oder Löschen von Endbenutzer- und Endbenutzerkontexten. Auditdatensätze sind über UNIFIED_AUDIT_TRAIL verfügbar und können die Endbenutzeridentität und die Sicherheitskontext-ID für Aktivitäten enthalten, die unter einem Endbenutzersicherheitskontext ausgeführt werden.

Die Aktion CREATE END USER SECURITY CONTEXT zeichnet die Erstellung des Sicherheitskontexts auf. Oracle stellt fest, dass es viele Datensätze generieren kann und nicht in ACTIONS ALL enthalten ist. Geben Sie es explizit an, wenn dieses Lebenszyklusereignis auditiert werden muss. Wählen Sie Auditaktionen und Aufbewahrung gemäß den Sicherheits- und Complianceanforderungen des Deployments aus. SDK-Anwendungslogs sind diagnostisch und ersetzen nicht den Datenbankaudittrail.

Siehe Oracle Deep Data Security Operations auditieren und die offizielle Liste der Deep Sec Audititable-Aktionen.

Widerrufsfrist

Der Widerruf der Datenbank-Policy und die Entfernung der OCI IAM-Gruppenmitgliedschaft haben unterschiedliche Gültigkeitszeiten:

Administrative Aktion Gültigkeitszeit
Rufen Sie revoke_agent_memory_policies() an Die Funktion entfernt die speicherspezifische Datenbankzuweisung und Commits, bevor sie zurückgegeben wird. Nachfolgende geschützte Datenbankanweisungen erhalten diese Policy nicht mehr. Eine bereits ausgeführte Anweisung wird nicht rückwirkend storniert.
Benutzer aus der Berechtigtengruppe in OCI IAM entfernen Neu ausgegebene Zugriffstoken spiegeln die aktualisierte Mitgliedschaft wider. Ein Zugriffstoken, das bereits an den Benutzer ausgegeben wurde, enthält weiterhin den Claim group und kann die entsprechende Deep Sec-Datenrolle weiter autorisieren, bis dieses Token abläuft.

Der effektive obere Grenzwert für den reinen IAM-Widerruf ist daher die verbleibende Lebensdauer im exp-Claim des ausgegebenen Tokens. Die Lebensdauer des OCI-IAM-Zugriffstokens kann konfiguriert werden. Wenn keine Ressourcenanwendung, keine Benutzersession oder kein benutzerdefinierter Ablauf festgelegt ist, beträgt der dokumentierte Standardwert 3600 Sekunden. Anwendungen müssen ein abgelaufenes Token nicht mehr verwenden und ein neues Token abrufen, dessen Ansprüche die aktuelle Mitgliedschaft widerspiegeln.

Um einen dringenden Widerruf vorzunehmen, rufen Sie zuerst revoke_agent_memory_policies() auf, um die Datenbankzuweisung für nachfolgende Anweisungen sofort zu entfernen, und entfernen Sie dann den Benutzer aus der OCI-IAM-Gruppe. Weisen Sie die Datenbank-Policy nur dann erneut zu, wenn die Gruppe als Ganzes wieder Zugriff erhalten soll. Wenn nur ein Mitglied entfernt werden muss, während die Gruppe autorisiert bleibt, verlassen Sie sich auf den Tokenablauf oder verwenden Sie eine Deployment-spezifische kürzere Lebensdauer für das Zugriffstoken und eine erneute Authentifizierungs-Policy.

Siehe die Autorisierung mit der API verwalten und die Tabelle mit Tokenablauf von OCI IAM sowie die oben genannten Deep Sec-Lebenszyklusreferenzen zum Sicherheitskontext.