Seguridad
Controle el acceso a los datos que utilizan los agentes A2A mediante la aplicación de políticas de seguridad y mecanismos de auditoría.
Política de VPD
Utilice políticas de base de datos privada virtual (VPD) para aplicar un control de acceso detallado basado en el contexto del agente. Las políticas de VPD permiten controlar el acceso de fila a los objetos de base de datos que utilizan los agentes A2A. Al procesar una solicitud A2A autenticada, Select AI define valores en el contexto de la aplicación A2A_AGENT_ACCESS_CONTEXT$. El atributo USER_IDENTITY identifica el usuario de base de datos asociado a la solicitud. El atributo TEAM_NAME identifica el equipo de agente de Select AI que gestiona la solicitud. Una política de VPD puede utilizar estos valores para controlar a qué filas puede acceder un agente. Para obtener más información, consulte Using Oracle Virtual Private Database to Control Data Access.
Por ejemplo, la política del ejemplo agrega una condición de nombre de equipo a las consultas en HR.EMPLOYEES. Devuelve filas solo cuando la solicitud utiliza el equipo REPORT_SUMMARY_AGENT_TEAM. Esta condición restringe el acceso por nombre de equipo, no por usuario de conexión. Para restringir el acceso del usuario de la base de datos, defina un predicado de política que compruebe USER_IDENTITY. Sustituya el nombre del equipo y los detalles de la tabla por valores para su entorno.
Valores de contexto disponibles:
SYS_CONTEXT('A2A_AGENT_ACCESS_CONTEXT$', 'USER_IDENTITY')
SYS_CONTEXT('A2A_AGENT_ACCESS_CONTEXT$', 'TEAM_NAME')Ejemplo: definición y aplicación de una política de VPD
-- Define VPD policy
CREATE OR REPLACE FUNCTION limit_access (v_schema IN VARCHAR2, v_objname IN VARCHAR2)
RETURN VARCHAR2 authid current_user AS
BEGIN
RETURN 'SYS_CONTEXT(''A2A_AGENT_ACCESS_CONTEXT$'', ''TEAM_NAME'') = ''REPORT_SUMMARY_AGENT_TEAM''';
END;
-- Apply policy on table
BEGIN
DBMS_RLS.ADD_POLICY(
object_schema => 'HR',
object_name => 'EMPLOYEES',
policy_name => 'POL',
policy_function => 'LIMIT_ACCESS');
END;
/Para obtener más información, consulte DBMS_RLS y SYS_CONTEXT.
Pista de Auditoría
Seleccione AI registra el acceso del agente A2A en la pista de auditoría unificada mediante una política de auditoría gestionada por Oracle. Esta auditoría por defecto no requiere que cree una política de auditoría personalizada para cada equipo. Una política personalizada agrega auditoría para las acciones de base de datos seleccionadas, como acciones SELECT en una tabla, cuando sus condiciones coinciden con el contexto de solicitud A2A. La pista de auditoría de Autonomous AI Database está disponible mediante la vista UNIFIED_AUDIT_TRAIL, que puede consultar para revisar la actividad auditada.
Puede definir políticas de auditoría personalizadas que utilicen el contexto de aplicación A2A_AGENT_ACCESS_CONTEXT$ para auditar el acceso de un equipo de agente de Select AI específico. En la expresión SYS_CONTEXT('A2A_AGENT_ACCESS_CONTEXT$', 'TEAM_NAME'), TEAM_NAME es el nombre de atributo de contexto. No sustituya TEAM_NAME. Sustituya solo el valor comparado, como 'REPORT_SUMMARY_AGENT_TEAM', por el nombre del equipo del agente. La política compara ese valor de contexto con el nombre real del equipo del agente, por ejemplo:
SYS_CONTEXT('A2A_AGENT_ACCESS_CONTEXT$', 'TEAM_NAME') =
'REPORT_SUMMARY_AGENT_TEAM'SYS_CONTEXT devuelve el valor del atributo con nombre del contexto de aplicación, y el contexto de aplicación de Oracle se suele utilizar con funciones de seguridad y aplicación de políticas como la VPD y la auditoría unificada.
En el siguiente ejemplo, se crea una política para acciones SELECT en HR.EMPLOYEES siempre que una solicitud A2A proporcione un nombre de equipo. Debido a que la condición comprueba solo que TEAM_NAME no es nulo, puede hacer coincidir las solicitudes de cualquier equipo. Para auditar un equipo específico, compare TEAM_NAME con el nombre de ese equipo, como se muestra anteriormente.
Ejemplo: creación de una política de auditoría
create audit policy MY_A2A_AGENT_ACCESS_AUDIT_POLICY
actions SELECT on HR.EMPLOYEES
when sys_context('A2A_AGENT_ACCESS_CONTEXT$', 'TEAM_NAME') is not null;Después de crear la política de auditoría personalizada, actívela con la sentencia AUDIT POLICY:
AUDIT POLICY MY_A2A_AGENT_ACCESS_AUDIT_POLICY;Oracle evalúa la política para las operaciones de coincidencia y escribe registros de auditoría unificados para la actividad que cumple las condiciones de la política. Estos registros aparecen a continuación en UNIFIED_AUDIT_TRAIL. Una política de auditoría unificada se aplica en la siguiente sesión de usuario para los usuarios que se están auditando. El acceso a los logs de auditoría depende de los privilegios de la base de datos y la configuración de seguridad. Para obtener más información, consulte CREATE AUDIT POLICY (Unified Auditing) y AUDIT (Unified Auditing).
La condición de política filtra las acciones por equipo, pero no agrega los valores de contexto al registro de auditoría. Para incluir USER_IDENTITY y TEAM_NAME en los registros de auditoría, configure la auditoría de contexto de aplicación:
AUDIT CONTEXT NAMESPACE A2A_AGENT_ACCESS_CONTEXT$
ATTRIBUTES USER_IDENTITY, TEAM_NAME;A continuación, consulte UNIFIED_AUDIT_TRAIL para revisar los registros coincidentes y sus valores de contexto capturados:
SELECT event_timestamp,
dbusername,
action_name,
object_schema,
object_name,
unified_audit_policies,
application_contexts
FROM unified_audit_trail
WHERE INSTR(unified_audit_policies,
'MY_A2A_AGENT_ACCESS_AUDIT_POLICY') > 0
ORDER BY event_timestamp DESC;Configuración de red para punto final privado
Si la base de datos utiliza un punto final privado, solo se puede acceder al punto final del servidor A2A desde la red virtual en la nube (VCN) configurada. Los clientes externos fuera de la VCN no se pueden conectar.
Formato de punto final:
https://{hostname_prefix}.adb.{region-identifier}.oraclecloudapps.com/adb/a2a/v1/{database-ocid}- Nota
-
hostname_prefix: valor definido o generado durante la configuración del punto final privado. -
region-identifier: región de Oracle Cloud. -
database-ocid: OCID de la base de datos de IA autónoma. Nota: Asegúrese de que el cliente que accede al servidor A2A esté desplegado en la misma VCN o tenga conectividad de red, por ejemplo, VPN.
Recupere hostname_prefix de la página de detalles de la base de datos en la consola de OCI.
Consulte Acceso de punto final privado para obtener más información.
Puede utilizar el agente A2A con una base de datos de IA autónoma activada para punto final privado solo cuando el agente de cliente A2A se ejecute en la misma VCN privada o tenga conectividad de red a la base de datos. Si el agente cliente A2A se ejecuta en otra nube o en un entorno externo, configure la red de acuerdo con las directrices de conectividad de esa plataforma para permitir la comunicación con Autonomous AI Database.
Por ejemplo, cuando configure una aplicación de Google Gemini Enterprise, siga las instrucciones de redes privadas de Google. Consulte Patrones de red privada de varios agentes en Google Cloud para obtener más información.
Nota
Nota: La activación del servidor MCP de Autonomous AI Database o del servidor Agent2Agent (A2A) no aprovisiona recursos informáticos adicionales, como máquinas virtuales independientes. Estas capacidades se incluyen como parte de Autonomous AI Database, mediante la asignación de recursos informáticos actual. El consumo de recursos se determina mediante la ejecución de herramientas (para MCP) u operaciones de agente (para A2A) en el entorno de base de datos existente.
Recomendaciones
-
Defina
object_listen el perfil Seleccionar AI solo con los objetos de base de datos necesarios. Consulte Atributos de perfil y Ejemplo: creación de un agente de análisis de películas con herramientas incorporadas para obtener más información. -
Enfoque de dos esquemas: este enfoque se utiliza principalmente para organizar y proteger el desarrollo de agentes de IA selectos, no para la configuración específica de A2A.
-
Utilice un esquema, por ejemplo
A2A_USER, para seleccionar objetos de agente de AI como agentes, equipos de agentes, tareas y herramientas. -
Utilice un esquema independiente, por ejemplo
SALES_USER, para las funciones PL/SQL y otros objetos de aplicación que soportan esos agentes.
-