Capítulo 13 — Identidad y acceso | Grado Seguridad de IA y aprendizaje automático

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Mapa de la lección

Lección 13 publicada. Mapa, ejemplo, EX037.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["13.1 Autenticación, autorización, contabilidad"]
  N2["13.2 Acceso basado en roles y en atributos"]
  N3["13.3 Delegación para agentes de IA"]
  N4["13.4 Contabilidad de las acciones de la IA"]
  N5["13.6b Revisar los permisos del agente"]
  N6["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX037"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["13.1 Autenticación, autorización, contabilidad"]
  N2["13.2 Acceso basado en roles y en atributos"]
  N3["13.3 Delegación para agentes de IA"]
  N4["13.4 Contabilidad de las acciones de la IA"]
  N5["13.6b Revisar los permisos del agente"]
  N6["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX037"]

[Resultados de aprendizaje]
    |
    v
[13.1 Autenticación, autorización, contabilidad]
    |
    v
[13.2 Acceso basado en roles y en atributos]
    |
    v
[13.3 Delegación para agentes de IA]
    |
    v
[13.4 Contabilidad de las acciones de la IA]
    |
    v
[13.6b Revisar los permisos del agente]
    |
    v
[Síntesis]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX037]

Resultados de aprendizaje

Usted podrá (1) explicar la autenticación, la autorización y la contabilidad; (2) diseñar acceso basado en roles y en atributos para aplicaciones de IA; (3) aplicar la delegación para que los agentes de IA actúen con los derechos limitados del usuario; y (4) evitar los problemas de confused deputy (agente confundido).

13.1 Autenticación, autorización, contabilidad

La autenticación prueba quién es alguien; la autorización decide qué puede hacer; la contabilidad registra lo que hizo. Una autenticación fuerte (multifactor) protege las cuentas; una autorización precisa limita el daño; la contabilidad permite investigar. En Ask Lumen, la autenticación es el inicio de sesión del paciente en el portal de la clínica; la autorización es la regla de que una reserva solo puede ser para ese paciente o para alguien de quien sea cuidador registrado; la contabilidad es el registro que vincula cada reserva con la conversación y la sesión que la produjeron. Una debilidad en cualquiera de las tres socava las demás: unos registros perfectos no ayudan si la herramienta de reservas nunca comprobó quién lo pedía.

13.2 Acceso basado en roles y en atributos

Los roles (paciente, recepcionista, clínico) agrupan permisos. Los atributos (clínica, relación con el paciente, hora) los afinan. La herramienta de reservas de Ask Lumen debe comprobar «¿es quien lo pide el paciente o su cuidador registrado, para esta clínica?» en lugar de «¿puede reservar el servicio del chatbot?». La segunda pregunta es la equivocada porque el servicio del chatbot siempre puede; formularla convierte los amplios derechos del servicio en derechos de todos. Atributos como la clínica y la relación de cuidador permiten que la regla siga las situaciones reales sin crear un rol nuevo para cada una.

13.3 Delegación para agentes de IA

Cuando un agente de IA actúa, debe usar un token delegado por el usuario con alcance y vida útil limitados, de modo que nunca pueda hacer más que ese usuario. Una cuenta de servicio potente convierte cualquier manipulación del modelo en una escalada de privilegios: el problema del confused deputy, en el que se engaña a un componente de confianza para que haga mal uso de su autoridad. Un token delegado lleva la identidad del paciente, así que el sistema de citas puede aplicar directamente los derechos del paciente. Su corta vida útil limita el daño si se filtra a través de un registro o de una llamada a herramientas manipulada.

13.4 Contabilidad de las acciones de la IA

Registre qué usuario, qué conversación, qué propuesta del modelo y qué aprobación llevaron a cada acción. Sin esta cadena, los incidentes no pueden explicarse. La cadena de una reserva podría decir: sesión de paciente 7f2, conversación c-118, propuesta del modelo a las 10:14:03 de reservar en la clínica C3 en una fecha dada, comprobación de políticas superada, confirmación del paciente a las 10:14:20, identificador de reserva escrito. Si un paciente impugna después una reserva, puede mostrarse cada paso. Si el modelo propuso algo que la política bloqueó, también queda registrado, lo que ayuda a detectar intentos de manipulación.

13.5 Ejemplo resuelto (caso sintético de LCH)

Ask Lumen reservaba citas mediante una cuenta de servicio autorizada a reservar para cualquier paciente. Rina mostró en el entorno de pruebas que un mensaje elaborado que nombraba el identificador de otro paciente sintético llevaba al modelo a proponer una reserva para ese paciente, que la cuenta de servicio ejecutaba. La corrección usó un token delegado por sesión vinculado al paciente que ha iniciado sesión (y a sus cuidadores registrados) y una comprobación de políticas que compara el paciente de la reserva con el sujeto del token. La prueba muestra directamente el confused deputy: el modelo no hizo nada mal según su propia lógica, y la cuenta de servicio hizo lo que tenía permitido hacer.

13.6 Errores y límites

Herramientas de IA que funcionan con cuentas de servicio amplias.
Autorización decidida por el modelo.
Falta de vínculos entre conversaciones y acciones en los registros.

Las cuentas de servicio amplias convierten cada inyección de instrucciones en una posible escalada de privilegios, como mostró el ejemplo resuelto. Dejar que el modelo decida la autorización pone la regla donde el texto puede discutirla. La falta de vínculos entre conversaciones y acciones deja a los investigadores sin poder decir qué mensaje causó qué reserva. Los tokens delegados, una comprobación de políticas externa y los identificadores de petición resuelven los tres, uno tras otro.

13.6b Revisar los permisos del agente

Cada trimestre, LCH enumera lo que la herramienta de reservas de Ask Lumen puede hacer realmente y lo compara con lo que necesita el chatbot. Una revisión descubrió que la cuenta de la herramienta también podía editar las agendas de los clínicos; se retiró ese derecho, y el acta de la revisión anota quién aprobó los permisos restantes. Los permisos tienden a crecer a medida que se añaden funciones, y nadie los retira salvo que una revisión lo pida. El derecho a editar agendas se había añadido para un piloto que terminó, y nadie había advertido que seguía concedido.

Ejercicios

EX037 — AAA. Defina autenticación, autorización y contabilidad con un ejemplo de Ask Lumen para cada una. Rúbrica: 3 = las tres correctas con ejemplos; 2 = dos; 1 = una; 0 = nada.
EX038 — Confused deputy. Explique el problema del confused deputy con el hallazgo de Rina. Rúbrica: 3 = cuenta de servicio de confianza mal utilizada a través de un modelo manipulado; 2 = parcial; 1 = vago; 0 = incorrecto.
EX039 — Política. Escriba la comprobación de políticas para las reservas. Rúbrica: 3 = booking.patient ∈ {token.subject} ∪ carers(token.subject) y clínica permitida; 2 = parcial; 1 = vago; 0 = nada.

Síntesis

Los controles de identidad deciden qué puede hacer un agente de IA y en nombre de quién. Los tokens delegados y acotados y las comprobaciones de políticas externas impiden que el modelo se convierta en un confused deputy.

Siga estudiando — capítulo 13 de 40

← Capítulo 12 (borrador) · Índice de capítulos del curso · Capítulo 14 (borrador) →