De la seguridad informática clásica a la IA agéntica: evolución del control de acceso y autorización

Vídeo em Espanhol, publicado pelo canal OracleMania.

Sobre este contenido: El resumen, los puntos principales y los temas que aparecen a continuación se generan automáticamente a partir de la transcripción del vídeo. Reflejan el contenido, las opiniones, afirmaciones y predicciones presentadas en el vídeo y no representan una posición, validación o verificación de hechos por parte de IA Dots.

Resumen del vídeo

La charla aborda los retos de seguridad en la era de la inteligencia artificial agéntica, destacando cómo los agentes autónomos pueden explotar vulnerabilidades existentes. Se presenta el framework Oracle Deep Data Security (versión 23.3) y los 'cross table data grants' como una solución para aplicar controles de acceso granulares directamente en la base de datos y cumplir con el principio de mínimo privilegio.

Puntos principales

• A lo largo de la historia, la humanidad ha visto cada nueva tecnología (lenguaje, radio, televisión, calculadoras, e inteligencia artificial) como una amenaza.
• La inteligencia artificial agéntica se diferencia de las herramientas tradicionales por poseer 'agencia', es decir, la capacidad de tomar decisiones y aprender por sí misma.
• Los agentes de IA generan consultas SQL de forma dinámica, lo que complica el modelo de seguridad tradicional y exige un control más estricto.
• Oracle Deep Data Security introduce comandos como 'create end user', 'create data role' y 'create data grant' para gestionar la seguridad basada en entidades.
• Los 'cross table data grants' permiten heredar privilegios de tablas padre a tablas hijo, facilitando filtrar datos a nivel de filas o columnas sin requerir cláusulas WHERE manuales.
• El principio de mínimo privilegio en bases de datos es fundamental para asegurar que los agentes autónomos accedan estrictamente a los datos y acciones necesarios.

Temas

Seguridad en bases de datosInteligencia artificial agénticaOracle DatabasePrincipio de mínimo privilegioControl de acceso granularEvolución tecnológicaCross table data grants

Transcripción del vídeo

Texto de los subtítulos disponibles; puede contener errores.

[música] [música] Bien, todos, eh muy bienvenidos a la cuarta charla del día de hoy. Eh tengo el honor de introducir un gran amigo y ex director, eh Ronald Vargas, desde Costa Rica. El día de hoy él le va a estar teniendo una muy interesante charla que dice de sobre seguridad y que de de seguro les será muy interesante a todos. Les digo también que cualquier pregunta o problema que tengan, por favor, lo dejen saber a través del chat. Y todas las preguntas ah que se hagan dirigidas a Ronald referente a la charla eh serán respondidas al final del evento. Bueno, sin más atraso eh los dejo con esta gran charla de nuestro amigo Ronald Vargas. Ronald, el salón es tuyo. Gracias Francisco y nuevamente muchas gracias por la invitación y y y y el volver a activar este tipo de actividades que que bastante nos hacía falta. Y bueno, que que quizás como tú dices, vamos a a la a lo que vinimos, que generalmente es lo que más le interesa a la a la gente. Eh si nos metemos en la cronología eh de los medios de comunicación que la humanidad ha utilizado en los últimos 2 millones de años. Eh, hay un caso supercurioso sobre con respecto a cuánto tiempo debe de pasar para que algo sea completamente sustituido por por algo. Eh, hace un casi 2 millones de años pasamos básicamente, eh, empezamos a comunicarnos los primeros, eh, se se los primeros seres humanos empezamos a comunicarnos a través de señas y prácticamente pasamos casi 2 millones de años única y exclusivamente utilizando señas para comunicarnos antes de empezar a utilizar algún tipo de lenguaje. Una vez que empezamos a utilizar los lenguajes, que fue aproximadamente hace unos 200,000 años atrás, pasaron nuevamente una gran cantidad de tiempo, no como cual principio en el uso de de señas y demás, pero sí pasaron casi 197,000 años antes de que empezáramos a comprender o a o a entendernos a través de de algún tipo de escritura. Para aproximadamente 1,000 millones antes de Cristo, eh, la humanidad empezó a utilizar las señales de humo como medio para poder transmitir ciertos mensajes cortos de un lado a otro y no fueron solamente los nativos eh americanos, sino también en Asia se se utilizó este medio y aproximadamente 200 años antes de Cristo empezamos a utilizar a los mensajeros para poder enviar eh comunicados de un lado a otro. Si yo brinco de esos 200 años antes de Cristo y brincamos hasta el año 1837, cuando aparece el primer telégrafo y se sustituye por completo todo este tema de utilizar mensajeros para poder mandar información, vamos a ver que el tiempo entre que cada una de las tecnologías aparecen se va disminuyendo considerablemente. Hoy en día, desde hace aproximadamente unos 12, 14 años atrás, empezamos a hablar mucho sobre temas de artificial y y empezamos a utilizar eh ya de alguna u otra forma este nuevo eh tipo de tecnología. Pero eh lo que es se hace curioso eh con respecto a esto es de que toda tecnología siempre que aparece de alguna u otra manera eh siempre causa mucho furor dentro de la humanidad. A principios del siglo XIX vemos como la gran revolución eh industrial, como la gente se manifestó en contra de las máquinas, porque la se habían desplazado de alguna u otra manera en sus trabajos por lo que las máquinas estaban empezando a hacer. Para el siglo XX em cerca de de de los años 30 de del siglo pasado eh hubo también manifestaciones grandes cuando la radio se cree se creía a sí mismo dueña y única eh fuente confiable eh en el tema de distribución de las noticias y cuando aparece la televisión lo ven como una amenaza y eh se crean bastantes enfrentamientos entre ambas tecnologías, entre la radio y la televisión como tal. Posteriormente, ya acercándonos más a la era moderna eh la televisión también de alguna u otra manera eh se vio como como una amenaza, no solamente para para el tema de hm como lo vimos del tema de la del de cómo comunicar noticias eh como se hacía anteriormente sino los profesores de los Estados Unidos vieron en la televisión eh un artefacto que de alguna u otra manera dañaba y atrasaba el el tema de de cómo eh se daba el aprendizaje eh a través de de de de o sea, cómo afectaba el aprendizaje de de las personas cuando de alguna u otra manera se metían dentro de esta tecnología. Ya en los años eh 70, a finales de la década de los 70, también vimos grandes manifestaciones en contra del uso de la energía nuclear. Y más recientemente, inclusive eh ya a mediados de hace 1986, 40 años, 40 años fue hace aproximadamente cuando yo eh salí de la secundaria. Eh los profesores se quejaban constantemente de que los alumnos utilizaban la calculadora y pidieron de alguna u otra manera que se prohibiera el uso de la calculadora en las clases para evitar eh eh que no aprendieran de forma manual en cómo realizar o cómo hacer cierto tipo de cálculos. Y eh más recientemente ya en el en en los tiempos eh postpandemia eh vimos cómo de alguna u otra manera la gran toda la gran industria de Hollywood eh de alguna u otra manera se vio o se sintió amenazada por el uso de inteligencia artificial, no solamente en el los temas de llegar y empezar a sustituir en algunas películas eh algunas porciones de actores eh sintéticos sino también en la parte de la generación de de guiones que le quitaba el trabajo eh directamente a los escritores. Entonces, siempre hemos visto de alguna u otra manera manera en las nuevas tecnologías una amenaza importante. Recientemente, hace unos 15 días, vi una noticia en donde eh un medio de noticias de Francia televisivo eh empezó a utilizar distintas eh herramientas, entre comillas, porque ahorita vamos a aclarar ese tema, de inteligencia artificial para poder simplificar y poder extraer información de distintas fuentes de datos y poder dar un un de alguna u otra manera un mejor servicio sobre so so sobre el sobre el el el el cubrir una nota específica. ¿Okay? Entonces, ¿cuál es el tema? Generalmente nosotros siempre nos preguntamos en términos de seguridad eh hasta dónde o cuál es la mejor forma en cómo llegar y cómo asegurar nuestra información. Sin embargo, hoy en día con las nuevas tecnologías y con las cosas que que salen constantemente, ¿okay? Eh llegamos a un punto en donde de alguna u otra manera inicialmente hemos olvidado un punto sumamente importante en temas de seguridad y que es un principio básico con respecto para podernos eh dar eh certeza de que el acceso a la información no está siendo eh brindada más allá de lo que realmente se requiere para poder hacer. Si yo llego y hiciera esta pregunta que cuál debería ser el principio fundamental desde una arquitectura de seguridad adecuada para una inteligencia artificial genética eh agéntica eh hay muchas muchos puntos de vista, inclusive hemos visto algunos casos eh documentados ya en los últimos meses de cómo los agentes de alguna u otra manera eh se han salido del canasto y han eh han empezado o han hecho cosas que no fueron para las cuales específicamente fueron creados. Y este es el punto más importante de esto. Muchas veces cuando uno se preguntaba en el pasado ¿cómo voy a hacer yo para que un usuario específico a través de una autorización, por ejemplo, de de una tabla donde se encuentra la información de cuentas pueda a través de esa misma autorización para un específico cliente y demás poder derivar eh a hacia abajo a nivel de jerarquía el acceso, por ejemplo, a los movimientos que están relacionados específicamente en esa tabla de de cuentas y para el código del cliente al cual él debería de poder tener acceso. Y de alguna u otra manera la IA nos está endosando una gran cantidad de retos nuevos en términos de seguridad con con esto que estamos hablando. Sin embargo, es eso es un un punto de vista eh muy personal. Creo que estamos más preocupados en aprender en cómo usar la inteligencia artificial antes de entenderlo. Y aquí hacemos un un pequeño eh una pequeña pausa porque eh hace poco estuve eh observando una charla muy interesante de de una persona que se llama Yuval Noah en en la Universidad de Oxford y él en su charla eh hm exponía el tema de que la inteligencia artificial no es una simple no es otra simple herramienta. Para eh para este señor, para Yuval, si hablamos de propiamente de temas de de la de de inteligencia artificial, él empieza cuestionando, haciendo una comparación muy frecuente entre lo que es una herramienta y de lo que es propiamente un ente agéntico. Y eh básicamente eh él llega y dice que muy frecuentemente pensamos en la inteligencia artificial como una tecnología equivalente a un automóvil, a un a una imprenta, a una máquina de vapor, eh a al internet o incluso a un arma nuclear. Para él existe una diferencia fundamental en que es en que las tecnologías anteriores, por extraordinarias que nos parezcan, por lo poderosas que sean, son simple y sencillamente herramientas. Una bomba atómica puede destruir una ciudad, pero no puede decidir por sí misma qué ciudad quiere destruir. Tampoco puede diseñar espontáneamente una bomba mejor que ella misma. Cuando utilizamos un coffee maker, una cafetera automática, ella puede ejecutar la secuencia compleja para poder crear el café, pero no puede reconsiderar el procedimiento, ni puede decidir inventar una forma distinta en cómo preparar un café. La inteligencia artificial introduce algo que es diferencia en todo esto, y es la agencia. Y eso es lo que lo separa de una herramienta normal y corriente. La agencia le da a la inteligencia artificial la capacidad de poder tomar decisiones, de poder aprender, de poder inventar soluciones y poder modificar el comportamiento de manera que sus propios creadores quizás no necesariamente anticiparon. Por eso eh temas de seguridad ahora se vuelve más complejo y y por el momento quizás la mejor eh o in la mejor forma en cómo brindar la información eh sea directamente en el lugar donde se consume, en ese caso directamente en la base de datos. Y eh si si lo hacemos de de esa manera, okay, podemos de alguna otra manera eh interpretar que la gente va a tener acceso a la base de datos. Sí, lo va a tener, pero nosotros tenemos que ver cómo el agente dispone exclusiva explícitamente de sus capacidades para poder determinar qué datos y bajo qué condiciones específicas tiene acceso, ¿okay? Entonces, vamos a va vamos a introducirnos un poquito de en en este tema y voy a hablar un poquito sobre lo que es la parte de eh seguridad profunda a nivel de se de de de la base de datos y de algunas características que tenemos para esto. Okay, entonces, sí, ciertamente la inteligencia artificial agéntica no necesariamente va a crear nuevas vulnerabilidades. Eso es un punto importante. Lo que pasa es que va a crear una nueva capacidad para poder descubrir, para poder combinar y para poder explotar auto autónomamente eh todas las vulnerabilidades ya existentes y eso cambia considerablemente el modelo conceptual de seguridad. Hasta ahora, el modelo mental que generalmente eh nosotros utilizamos, pensábamos en temas de de un modelo tradicional de seguridad, eh un atacante, una herramienta, una vulnerabilidad que que el atacante podía explotar a través de esa herramienta y eh el acceso a a los sistemas y a los datos como tal. Pero cuando hablamos de agentes de inteligencia artificial autónomos, empieza eh a a complicarse mucho este modelo, ¿okay? La diferencia parecía pequeña, pero arquitectónicamente es enorme. Cuando eh crear una imagen adaptada a esos conceptos sigue siendo eh una línea de definición que se viene utilizando generalmente eh bajo un concepto de de de seguridad tradicional. Eh en este caso eh dentro de la seguridad agéntica, tenemos que considerar aspectos humanos, aspectos del usuario final, a eh aspectos del agente de inteligencia artificial que se está conectando a la base de datos, las herramientas que utilizamos, los métodos de autorización, los las políticas de acceso a dichos datos y los datos eh eh como tal. La pregunta debe de de deja de ser específicamente "¿Puede esta identidad hacer una consulta, hacer un select?" Y pasa a ser, más que todo, "¿Cómo puede esta identidad, actuando mediante este agente específico, utilizar eh herramienta para este propósito y acceder precisamente a los datos y y ejecutar una operación. ¿Okay? Entonces, hoy les vengo a hablar un poquito sobre lo que es la seguridad en profundidad a nivel de datos de Oracle, Oracle Deep Data Security, y vamos a hablar específicamente sobre el la actualización, sobre la versión 23 26.3, el release update eh el el más reciente liberado de este framework que eh Oracle nos permite o que nos da a través de la base de datos, a través de de la versión 26 a 3D Oracle Database 26 ahí. ¿Y qué es lo que va a permitir ese framework? Ese framework me va a permitir a mí controlar el acceso a los datos directamente desde la base de datos, independientemente, ¿okay? Eso es un punto importante, de si quien los consume es una aplicación tradicional, un usuario, una herramienta analítica o un agente de inteligencia artificial. Y la versión es este Deep eh Data Security eh no es propia de la versión 23 26.3, ya existía en la 23 26.2, en el release update anterior, pero hay unas mejoras considerables en estos seis puntos que estamos viendo en la pantalla, que la base que la base de datos ha hecho. Y específicamente, si bien es cierto tenemos temas de multifactor, tenemos temas de eh de manejo de identi de de identificación a nivel de de login y de uso de roles y demás, quiero centrarme en la segunda opción que se muestra ahí, que es el cross table data eh grants. ¿Y por qué quiero centrarme acá? Porque es una forma en que nosotros vamos a poder tener la capacidad para cuando estemos interactuando con sistemas de inteligencia artificial poder limitar a nivel de la base de datos qué puede un agente leer y qué puede hacer o no hacer y evitar de alguna otra manera una interacción que sea excesiva ¿okay? Recordemos que básicamente las las formas de cómo atacar a una base de datos hoy en día han cambiado. Ahora se hace a través de prompts a través del uso de inteligencia artificial y de alguna otra manera yo puedo hackear eh a ciertas herramientas para que hagan cosas que no necesariamente era para lo cual fueron creadas entonces en este caso el Oracle Data Security aborda este problema aplicando una eh autorización granular a nivel de la base de datos y eh permitiendo de esta manera integrar todos los temas de controles en la base de datos según la identidad del usuario y el contexto de ejecución ¿okay? Entonces todos conocemos el concepto de mínimo privilegio y antes era muy sencillo poder trabajar con esto o sea cuando nosotros llegábamos y hablábamos básicamente brindábamos un privilegio a nivel de objeto y sabíamos que ese privilegio que estábamos dando a un usuario le permitía a un usuario hacer una consulta dentro de la base de datos pero si el usuario no tenía ese privilegio simple y sencillamente no lo podía accesar y basábamos cada vez que nosotros creamos un usuario dentro de la base de datos sabemos que ese usuario no tiene ningún gran ningún rol asociado. Nosotros somos los responsables de llegar e ir in eh eh agregando privilegios o otorgando privilegios de acceso con esta característica en 26A nacen unos componentes nuevos. Vamos a empezar por el hecho de que vamos a tener una nueva forma en cómo crear un usuario. Anteriormente nosotros creábamos un usuario a través de una sentencia create user con su nombre y ahora vamos a utilizar una eh un comando create and user. Y esos create and user van a poder tener accesos eh asociados roles de datos y privilegios a nivel de datos. ¿Okay? ¿Cuál es el cuál es la idea? Número uno, obtener seguridad basada en una entidad. La idea es que apliquemos políticas de autorización a niveles de filas, de columnas o de celdas directamente dentro de la base de datos según la identidad que haya sido eh verificada a nivel del usuario final. Poder obtener protección para inteligencia con agentes. En este caso, los agentes de IA van a generar y van a ejecutar consultas SQL de forma dinámica dentro de mi base de datos y vamos a evitar que una inyección de prompts o un agente con privilegios excesivos acceda o modifique información sensible que no le corresponde ver. Y el tercer punto es cómo vamos a crear una independencia lógica de la aplicación. La idea es que en lugar de confiar en que la aplicación eh eh eh eh eh o sea, en lugar de confiar en que la aplicación utilice un filtro X y eh de la y que la IA vaya a realizar acceso a una a una información restringida, vamos a imponer el principio [carraspeo] básico de mínimo privilegio directamente en el origen, en la base de datos. ¿Okay? Entonces, ¿cómo [carraspeo] se logra esto? Bueno precisamente la forma más rápida eh de de hacerlo, como les digo, es a través de Cross Table Data Grants. Y se los voy a mostrar a través de, de simples filminas, muy clásicas, ¿okay? Partamos del hecho de que vamos a tener el siguiente modelo. Tenemos tres tablas, tablas de clientes, tablas de cuentas y tablas de movimientos, ¿okay? Estamos hablando de tablas de, de cuentas de, por ejemplo, si fuera un, un modelo de algo más, lo más sencillo, que si fuera una entidad financiera, donde hay clientes, hay información de esas cuentas y los movimientos que están asociados, ¿okay? Entonces, el primer punto que vamos a tener en consideración es que vamos a tener tres nuevos comandos dentro del lenguaje de programación. Create End User, Create Data Role y Create Data Grant, ¿okay? ¿Cuál va a ser el comportamiento que yo quiero tener? Bueno, a la hora de crear el, el usuario, utilizo el Create End User, en este caso estamos creando dos usuarios, Ronald y María, ¿okay? Y eh, esta nueva sentencia, la base de datos va a permitir que esos End Users se puedan autentificar de forma directa dentro de la base de datos con un password, lo cual lo hace muy apropiado, eh, precisamente para temas de desarrollo, temas y, y demás, a, a nivel de, de temas de, de, de seguridad profunda. ¿Cuál es el comportamiento que yo quiero tener? Yo quiero que el usuario A, en este caso, Ronald, pueda consultar toda la información del cliente 100. Que además de eso, pueda consultar sus cuentas. Y que además pueda consultar los movimientos de esas cuentas, única y exclusivamente, ¿okay? Entonces, ¿qué es lo primero que vamos a hacer? Imaginemos que vamos a crear una aplicación que se llama, eh, My APP, que tiene una, un usuario de esquema normal y corriente, le damos privilegios de crear sesión, de tablas y le voy a dar un privilegio nuevo que es create data grant. Ese la ese es el nuevo privilegio que va a tener este usuario, ¿okay? Y eh luego creo unas tablas, creo las tablas de clientes, la tabla de cuentas, la tabla de movimientos. Como observan en la presentación, en esa filmina ¿okay? se encuentran definidas entidades de relación a nivel de la tabla de cuentas y de la tabla de de movimientos haciendo una referencia de llave foránea hacia el cliente ID eh en la tabla de de clientes y en la tabla de movimientos hacia la cuenta ID también en la misma tabla de cuentas. ¿Okay? Eso es para poder pegar una tabla con la otra, ¿okay? Entonces, mantenemos el modelo de entidad relación normal y corriente. Poblamos las tablas para poder eh poder tener información con la cual trabajar. ¿Okay? Y ahora sí tenemos lo siguiente. En sí, con esos insert tenemos básicamente que el cliente 100 ¿okay? es el dueño de la cuenta 1001 tiene dos movimientos, la cuenta 1002 tiene un tercer un solo movimiento la el cliente 200 tiene cuenta 2001, movimientos dos y la cuenta 2002 tiene un movimiento. ¿Okay? Y ahora vamos a crear los usuarios de Deep Sep, o sea, los usuarios que en este caso vendrían a utilizar los agentes de inteligencia artificial. ¿Okay? Entonces creamos el usuario Ronald con create and user y creamos el usuario María con create and user María. El primer paso es otorgarle a Ronald solamente privilegios para poder ver en la tabla de cliente aquellos clientes que únicamente sean o correspondan al al ID número 100. Entonces, a través de create datagram, yo le especifico eh en ese caso la política donde va a existir, en la política existe dentro del esquema, y en este caso es una política que le acabamos de poner un nombre N ahí aleatorio que se llama DG cliente Ronald, ¿okay? Y le digo, dentro de esa política, que a la hora que haga una consulta sobre la tabla de clientes del esquema my app my app. Donde eh al momento que que que Ronald haga esa consulta o como tal, ¿okay? Solamente pueda ver de la tabla de clientes del esquema my app, cuando el cliente ID sea 100. Y le asignamos con to esa eh datagram al usuario como tal. Y en el caso de María, hacemos lo mismo, pero únicamente en este caso le estamos dando privilegios dentro de la tabla para aquellos movimientos donde el ID del cliente sea igual a 200. ¿Okay? Entonces, ¿qué es lo que eh qué es lo que estamos expresando ahí? Básicamente lo que les acabo de decir, o sea, cuando yo hago un select con Ronald, voy a tener únicamente acceso al ID 100, y cuando lo haga con María al ID al ID 200. ¿Okay? Ahora, veamos a ver cómo se utiliza el cross table datagram. Yo ahora lo que quiero es que además de esos privilegios que hemos dado, ¿okay? Yo quiero que cuando alguno de los dos usuarios haga un select sobre una fila de clientes, pueda consultar las filas de las cuentas correspondientes a ese cliente. Y básicamente yo vuelvo a crear, en este caso, otra política, hago un create datagram con otro nombre, y caso se llama dege cuentas por cliente, okay, dege, dirección general o poli, eh lo que ustedes quieran ponerle, y le digo que cuando en este caso se haga una consulta sobre la tabla de cuentas, asocie que en este caso, que si yo tengo el privilegio de consulta sobre la tabla de clientes, yo pueda ver de la tabla de cuentas el ID específico que puedo ver en la tabla de clientes. O sea, vean cómo estamos amarrando la el gran que dimos anteriormente al gran a nivel de esta tabla, o sea, estamos haciendo dependencia que a la hora que ejecute o haga una consulta, no no le tenemos que volver a especificar específicamente sobre qué ID del cliente estamos obteniendo, si no lo heredamos del primer gran que inicialmente habíamos otorgado. Continuando en este caso, okay, lo que tenemos entonces es una relación en donde el el el usuario que ve los clientes del ID 100 en la tabla de clientes va a poder ver los movimientos o las cuentas del cliente ID 100 también en la tabla de cuentas. Y de igual manera manera para el segundo usuario, para María, que es el ID 200. Entonces, cuando yo hago un select sobre clientes, yo voy a derivar el código o el cliente ID sobre la tabla de cuentas. Okay. Y por último, recuerden que tenemos también una tabla de movimientos. Entonces, igual podemos hacer esa re- relación. Podemos crear una nueva política sobre la tabla de movimientos y le decimos que cuando alguien quiera hacer una consulta sobre la tabla de movimientos del esquema en my a- app, cuando alguien esté tenga el privilegio de consulta en la tabla de cuentas, ¿okay? O sea, debe tener privilegio de cuentas que se deriva de la de de lo que nosotros hicimos en la tabla de clientes, él valide que los movimientos que pueda observar sean única y exclusivamente los que estén asociados a la cuenta ID, ¿okay? Entonces, con esto pegamos con lo otro. Y viene la parte interesante, ¿cómo funciona esto? ¿Okay? Si lo vemos de esta manera, en forma resumida, explícitamente lo que estamos obteniendo a través de este conjunto de sentencias, es de que podamos tener un orden jerárquico en donde existe un objeto padre que tiene los grants iniciales, que en este caso es la tabla de clientes, ¿okay? Y los privilegios se van a evaluar a través de toda la cadena en la rutina de ejecución que vayamos a tener. Entonces, ¿qué pasa? Yo no tengo que hacer en este caso, ¿okay? Ya la cláusula where no es necesaria en este en a la hora de poder hacer una consulta. Si yo hago, como Ronald, hago un select asterisco sobre la tabla de clientes, [resoplido] única y exclusivamente la información que voy a poder ver es la que está asociada al cliente ID 100. Si yo [resoplido] hago el select sobre la tabla de cuentas, sin incluir ningún where, única y exclusivamente voy a ver filtrado aquellos movi- aquellas cuentas que estén asociadas directamente al cliente ID 100, ¿okay? Entonces, estamos accesando a la información con base a los grants, al al cross da- table data grant que anteriormente habíamos hecho, y la autorización en la tabla de de clientes se deriva o se hereda, en este caso, eh perdón, en la en En de cuentas se deriva de la tabla de clientes. ¿Okay? Veamos en la tabla de movimientos. Si el usuario Ronald ejecutara select va a hacer una proyección de la tabla de movimientos seleccionando ciertos campos, los puede ordenar normalmente sin ningún problema. El resultado que vamos a obtener siempre es que la información que vamos a ver son solamente de aquellas cuentas que están asociadas con el cliente ID que inicialmente eh lo a ver, lo habíamos visto. Por lo tanto, yo no voy a poder ver aquellas cuentas que no forman parte o que pertenecen a movimientos directamente del cliente 200. ¿Okay? ¿Qué pasa con María? Si María hace las mismas consultas que hace Ronald sin incluir un where va a encontrar o va a obtener distintos registros porque su scope es distinto al scope de Ronald. Tiene acceso directamente a un cliente distinto al que le habíamos eh otorgado privilegios a través de los grants iniciales que habíamos definido a nivel de la base de datos. ¿Okay? Entonces, la ventaja que tenemos acá es, como les digo, con este tipo de consultas y este este tema de seguridad que estamos haciendo acá, yo no voy a necesitar incluir ni definir una cláusula where para poder detectar o determinar quién es el usuario que tiene acceso a algo. Todo se controla directamente desde los grants que estoy generando. Eh un punto importante es que esto no es un simple foreign key, ¿okay? Acá hay una distancia muy importante entre lo que es el constraint de llave foránea y el acceso propiamente o la forma en que estamos haciendo la relación de seguridad a nivel de las tablas, ¿okay? Entonces, no hay que enredar o no existe una relación lógica directamente con una llave foránea eh para poder llegar y decir, "No es que lo que estamos definiendo es eso." No, es es totalmente distinto. ¿Okay? Ahora, se pueden hacer otras cosas más, se pueden mejorar considerablemente todas las condiciones o toda la eh la la forma del despliegue de la relación entre las tablas padre e hijo. Y podemos agregar condiciones adicionales. Yo podría, por ejemplo, eh agregarle un una columna más a la tabla de cuentas, en este caso, una columna que se llame estado, ¿okay? Y eh actualizar, digamos, eh que esa columna guarde si la cuenta está activa o si la cuenta eh está cerrada, por ejemplo. Y entonces, yo puedo, a través de una sentencia create or replace, o sea, no necesito borrar el grant, el data grant que había dado previamente, le puedo decir con create or replace, modificar una una definición de un grant que hayamos hecho sobre una sobre una tabla y le puedo decir que cuando, en el caso de la tabla de cuentas, cuando yo tenga otorgado el privilegio de consulta sobre la tabla de clientes, ¿okay? Además de validar que el cliente ID sea el mismo en ambas tablas, además de eso, única y exclusivamente yo pueda ver aquellas cuentas que se encuentren en estado activa o en estado activo. Entonces, vamos a tener dos criterios a la hora de la filtración de la información. Una, la la la parte de la consulta a través del select del cliente ID, y en la otra, en que la cuenta básicamente tiene que estar también en estado activo. ¿okay? Podemos restringir columnas del hijo. O sea, yo también puedo modificar una política y llegar e indicarle, en este caso, ¿okay? Que a la hora de que se haga un select, ¿okay? Yo pueda llegar y yo pueda seleccionar única y exclusivamente la tabla de, en este caso, de movimientos, la columna de movimiento, la de cuenta ID, la fecha y la descripción. De tal manera que si alguien intenta acceder a una columna, aún cuando conozca el diseño eh y el el eh con la información de metadatos de la tabla, ese usuario no va a poder hacer un select sobre una columna a la cual no tiene derecho. Entonces, vean de que ya no solamente estamos filtrando información a nivel de fila, a nivel de la relación con un código específico, sino también podemos eh limitar el acceso a nivel de una columna o a nivel de un grupo de columnas, es decir, solamente estas columnas son las cuales el usuario puede acces- acceder. ¿Okay? Eh También podríamos excluir información de carácter eh eh por ejemplo, sensible. Yo puedo llegar y dar un privilegio con un a eh concedido a nivel de del objeto de hijo, llegándole y diciéndole que, por ejemplo, que él puede llegar y puede seleccionar en la tabla de movimientos todas las columnas, excepto la columna de monto. Que es otra forma más más, digamos, eh más humana de poder determinar y decir qué datos quiero que esa eh que ese usuario de la tabla de movimientos no pueda ver no pueda seleccionar, guardando siempre la relación que habíamos establecido previamente. [resoplido] Eh También el privilegio que que se requiera eh o requerido del padre también puede ser por una columna. Yo puedo hacer una variante que es poner una condición when y en este caso yo le puedo llegar y decir eh por ejemplo al data gran que habíamos aplicado sobre la tabla de cuentas decirle que cuando se haga un select del cliente ID, ¿okay? y yo tenga privilegios en la tabla de de de clientes entonces yo pueda seleccionar eh en este caso que la autorización em si lo lo vemos así como como está aquí, va a depender específicamente de que el usuario posea un privilegio de consulta de select sobre el el cliente ID en la fila del padre. Si a la hora que yo llegué arriba le quité el privilegio sobre la la la columna cliente ID no va a ser posible que el usuario pueda generar esa consulta. ¿Okay? Entonces si yo restrinjo en la en el data gran que el usuario no accesa a la columna cliente ID en ese caso a la hora que haga la consulta sobre la tabla de cuentas si no tiene ese acceso no lo va a poder hacer. ¿Okay? Otro ejemplo asociado a eso eh es importante los privilegios del padre y el hijo no tienen que ser iguales eh esto amplifica bastante las cosas. Yo puedo llegar y decirle que eh a la hora de llegar y dar un a hacer una definición de un data gran sobre una tabla yo le digo que en este caso eh la tabla de movimientos va a tener cuando alguien eh haga eh un o sea si si tiene privilegios de select, insert y update cuando esté haciendo un insert y un update, yo lo haga eh basado en los privilegios de las tablas de de los grants que haya otorgado a nivel de la tabla de de cuentas, donde el movimiento de y la cuenta ID sea igual. Entonces, ¿qué es lo que significa esto? Si yo poseo insert más update sobre cuentas, entonces voy a tener select, insert y update sobre la tabla de movimientos. Así es como se se lee eso específicamente. Entonces, no no se requiere que todos los privilegios del padre y del hijo sean exactamente los mismos a la hora de la definición. [tos] Ya casi terminando, eh hay nuevas eh nuevas vistas del diccionario de la base de datos, donde yo puedo llegar y verificar directamente la información sobre los cross eh data data eh cross table data grants que haya que haya realizado, y puedo ver eh las dependencias, de quién depende directamente el nombre de cada uno de los grants y los tipos de privilegio que he otorgado en dicha política que haya definido. Eh también podemos consultar eh toda la información derivada de los de los hijos y de los padres a través de de de DBA data grants. Y básicamente, con con eso que acabamos de ver, intenté ajustarme lo más posible a al tiempo para no para no extenderme más. ¿Qué es lo que tenemos eh como reflexión final para para cerrar el tema de de esto inicialmente que estábamos viendo de esta pequeña parte de de este nuevo apartado eh de seguridad profunda a nivel de la base de datos. Eh la la inteligencia artificial nos está cambiando la premisa fundamental a nivel de seguridad. Ya no vamos a proteger solamente los datos, como lo hacíamos anteriormente, de de personas y aplicaciones, sino también vamos, de alguna u otra manera, eh tenemos que eh proteger eh los sis eh a los datos de los sistemas que son capaces de decidir y de poder actuar por sí mismos, como el como el caso de la de la agencia. Recuerden que la agencia tiene esa característica como tal. El Si nos basamos en el principio de mínimo privilegio, entonces se vuelve todavía mucho más importante en el tiempo de de la inteligencia artificial, porque ya no solamente nos basta con poder hacernos la pregunta de quién tiene acceso, sino ahora tenemos que preguntarnos, primero, ¿quién, mediante qué agente, utilizando qué herramienta, con qué propósito, sobre qué datos y para ejecutar exactamente qué tipo de acción es lo que requiere acceso el agente? Okay. Un agente no debería recibir todos los privilegios que podría llegar eh llegar, de alguna u otra manera, a necesitar, sino únicamente y estrictamente aquellos que sean necesarios para la acción que está realizando, durante el tiempo necesario y sobre los datos necesarios. Okay. Y existe, en consecuencia, especialmente esto es algo bastante importante, no podemos confiar exclusivamente en que el agente decida la forma correcta en que debe o no debe de hacer algo. Okay. La última barrera debe estar fuera de su capacidad de decisión y eh debe estar tan cerca del dato como sea posible y creo que a través de esta característica, haciéndolo a nivel de la base de datos, realmente es donde donde podemos eh tener mejor, mejor control de eso. Okay entonces. De alguna otra manera ya para finalizar, como les dije. En la era de la inteligencia artificial agéntica, la identidad. Eh, auten, eh, o sea, la, el, la identidad como dice ahí, eh. La identidad auténtica. El contexto explica. El mínimo privilegio nos ayuda a limitar. Y el dato se protege. A sí mismo. Quizás eh, la pregunta definitiva ya no sea. Confiemos en este agente, sino. Si mañana este agente toma una decisión que nunca anticipamos. Hasta donde le hemos permitido llegar. Y eh, así. Eh, con, con esa última frase. Quisiera cerrar eh, eh. Esta, esta cuarta presentación de, del día de hoy. Pero dando un, un pequeño vistazo a lo que ya podemos tener a, a la mano dentro de una base de datos Oracle ahí database 26 ahí. Para podernos eh, resguardar de, de aquel tipo de acciones en que los agentes hoy en día eh. Eh, pueden lle, llegar a ser sin que nosotros necesariamente le, le hayamos dado algún tipo de auten, de. De autoridad para poderlo hacer. Fran, no sé si. Si hay alguna pregunta, si alguien hizo alguna consulta. No he visto ninguna pregunta, pero si alguien tiene, por favor, póngala en el chat. Eh, veo que Mauricio Torrejón está escribiendo algo. Veamos. Eh, sí. Uno, entonces ahora el cross table data gran vendría a ser como construir permisología AM sobre un end user de una base de datos. Y dos, y por otro lado también podría enmascararse esta data en este nivel de cross table data gran Okay, eh vamos a ver porque estamos hablando de dos cosas distintas, ¿verdad? Si hablamos de disociación de datos, igual vamos a tener esa característica por otro lado, o sea, si un si una tabla ya tiene a nivel de disociación, tiene una máscara que no permite que dicha información sea visible se va a aplicar sea que haya un gran o un data gran, sea que no haya. Son dos dos niveles distintos, la disociación sigue estando presente porque es algo que se hace igual a nivel de capa de presentación, ¿okay? Entonces, sí se puede, digamos que sí podríamos de alguna otra manera eh combinar ambas ambas cosas. Y la primera que dice que vendría a ser eh vamos a ver cómo construir permisología y a sobre de una base de datos vamos a ver no no no dentro del contexto, la palabra permisología como como no no sé si me si me puedes eh aclarar eh ese esa consulta compañero Mauricio yo creo que se escribiéndonos ajá tengo vamos a ver si podemos ampliar ya está [carraspeo] aquí más grande ajá por ejemplo, en vez de aparecer mi nombre aparecería enmascarado como Juan Pérez ah no, no porque al final de cuentas estamos hablando de que somos usuarios normales y corrientes a nivel de la base de datos no es que estamos enmascarando a nadie, ¿verdad? La única diferencia es que el training user es el tipo de usuario que va a permitir poder yo otorgarle un datagram sobre eh ese usuario. A un usuario común, si yo hago un usuario a nivel de la base de datos con train user Ronald, no le puedo entregar o no le puedo derivar este tipo de privilegios. O sea, la diferencia eh clásica acá es no es que estamos representando, estamos escondiendo un usuario o generando que podamos tener un usuario con dos eh con con un mismo nombre, pero con dos sentidos distintos. O sea, que exista un train user Ronald y un eh train user Ronald. Train en y train eh no la base de datos lo va a permitir porque a nivel de la base de datos se ve como eh como un looking único, ¿verdad? No pueden haber dos dos usuarios con dos fines distintos o con dos definiciones distintas, uno como train user y el otro como train user. Entonces, no el término de enmascararse no a nivel de usuario no no no no lo no se no sería eso. Bien, aquí hay otra pregunta de Florentino. Estos cross table datagrams reemplazan por completo a las vistas de seguridad tradicionales para el DBA. No. No, es es veámoslo eso son dos cosas distintas de verdad. O sea, la la finalidad de de este tipo de seguridad es básicamente para hacerle frente, en este caso, al tema de que eh cuando yo llego y yo creo una aplicación okay veámoslo así de de una forma sencilla cuando creamos una una aplicación y creamos una pantalla y damos privilegios y roles sobre esa pantalla y en el acceso a los datos es difícil que ese comportamiento cambie porque la pantalla es está estática mientras que un agente dependiendo cómo haya sido construido el agente y los privilegios que tengan, aunque yo haya eh entrenado a la gente únicamente para hacer una consulta sobre la tabla de clientes y yo le pregunto a la gente y le digo a nivel de un pro, eh verifíquese a ver si yo puedo extraer o podemos modificar o traer más datos que estén ligados a los clientes, ese comportamiento yo no lo tengo en una pantalla. Entonces, si yo quisiera eh mejorar aún más los temas de acceso, eh en este caso la las mmm el tema de de de tradicional sigue estando eh ahí, o sea, no no es que se está sustituyendo, eso lo que viene es a ampliar en este caso el tema de cómo vamos a manejar la seguridad cuando haya una condición especial donde eh en este caso el usuario final, que es el agente, pueda tener la capacidad de poder eh ponerse creativo en la forma en cómo eh consulta la directamente los datos, ¿verdad? Pero siempre se mantendría en este caso eh la base de todos los otros controles que hayamos definido. Si yo aplico disociación, si aplico encriptación, si aplico eh eh bueno, mmm digamos que en algún momento inclusive estos datagrams vendrían a confundir a a los que somos un poquito más viejos con los temas de bases de datos eh eh ah eh vamos a ver, eh se me fue ahorita el que que estaba virtuales, que era algo que teníamos eh desde hace muchos años atrás en base de datos en Enterprise Edition, eh podría venir a confundir un poco, pero eh son cosas totalmente independientes, ¿verdad? O sea, no unas no sustituye a la otra. ¿Alguna otra pregunta? Parece que no. Bien, Ronald, muchas gracias por eh esta excelente presentación, como siempre. Aprovecho de mostrarle en pantalla que también tienen la posibilidad, en la página del evento, si se van hasta la parte abajo de la pantalla, van a llegar a una parte que, debajo de exhibitors, que dice interactuar y conectar con todos los attendis. Y ahí tiene una opción de cliquear de conec unirse a la conversación. Eso lo lleva a la página de la privada del evento, de la comunidad del evento, que le permite conversar con todas las personas, escribirle cosas a los speakers, hacer preguntas y también hacer networking, en caso quieran compartir cualquier cosa. Bien. En la página del evento normal, a partir de la próxima semana, cuando vayan a la agenda, va a van a poder ver todos los replays de todas las charlas que se presentaron esta semana. Con esto concluimos la cuarta charla del día de hoy. Quedan cuatro más el día de mañana y los invito a que participen sigan participando. Ronald, muchas gracias y gracias a todos también. Un gran saludo. Gracias, gracias, eh mi hermano. Feliz noche para todos. Igual, cuídense. Chao, chao.

Assistir ao vídeo original no YouTube

Assuntos: Inteligência artificial. Publicado no YouTube em 2026-10-27.

Seleção automática por assunto e idioma. O vídeo pertence ao canal de origem.