Mapa de la lección
Lección 06 publicada. Mapa, ejemplo, EX016.
flowchart TD
N0["Resultados de aprendizaje"]
N1["6.1 Conjuntos y relaciones"]
N2["6.2 Grafos"]
N3["6.3 Búsqueda en grafos"]
N4["6.4 Contar"]
N5["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX016"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["6.1 Conjuntos y relaciones"]
N2["6.2 Grafos"]
N3["6.3 Búsqueda en grafos"]
N4["6.4 Contar"]
N5["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX016"]
[Resultados de aprendizaje]
|
v
[6.1 Conjuntos y relaciones]
|
v
[6.2 Grafos]
|
v
[6.3 Búsqueda en grafos]
|
v
[6.4 Contar]
|
v
[Síntesis]
|
v
[Ejemplo resuelto] --> [Ejercicio EX016]
Resultados de aprendizaje
Usted podrá (1) usar conjuntos, relaciones y grafos para modelar sistemas; (2) expresar reglas de acceso como relaciones y comprobarlas; (3) encontrar en un grafo caminos desde entradas no confiables hasta acciones sensibles; y (4) contar posibilidades para juzgar si la fuerza bruta es viable.
6.1 Conjuntos y relaciones
Una regla de control de acceso es una relación entre sujetos, acciones y objetos: (paciente P, reservar, cita propia) está permitido; (paciente P, ver, historial de otro paciente) no lo está. Escribir las reglas como conjuntos de triples permitidos las hace comprobables por programa y deja a la vista los casos que faltan. Una vez que las reglas son un conjunto, un programa puede comprobar cada petición contra él y enumerar cualquier acción que no tenga ninguna regla. El primer intento de Rina descubrió que «cancelar» no tenía regla para pacientes que cancelan la cita de otra persona, algo que la política en prosa simplemente no mencionaba. Añadir una denegación explícita cerró la laguna, y el conjunto se convirtió en la referencia de sus comprobaciones de reservas.
6.2 Grafos
Un grafo tiene nodos y aristas. Dibuje un sistema de IA como un grafo dirigido: usuario → chatbot → modelo → herramienta de reservas → sistema de citas, más almacén de documentos → modelo. Un camino desde un nodo no confiable (una página web pública, un documento subido) hasta un nodo sensible (la herramienta de reservas) es una posible ruta de ataque. La inyección indirecta de instrucciones sigue exactamente esos caminos (Greshake et al., arXiv:2302.12173). Dibujar el grafo hizo visible una arista que el documento de arquitectura había pasado por alto: las organizaciones asociadas suben documentos al almacén que lee el modelo.
6.3 Búsqueda en grafos
La búsqueda en anchura encuentra todos los nodos alcanzables desde un nodo de partida. Ejecutarla desde cada nodo no confiable y comprobar si se alcanzan nodos sensibles es una comprobación de arquitectura sencilla y automatizable. El coste crece con el número de nodos y aristas, así que incluso los sistemas grandes pueden comprobarse en segundos. El valor está en mantener el grafo exacto: una nueva fuente de subidas o una nueva herramienta deben añadirse en cuanto existen, o la búsqueda dará un resultado limpio para un sistema que ya no se corresponde con él. Rina vuelve a ejecutar la comprobación cada vez que cambia el mapa de arquitectura y guarda la salida junto al mapa.
6.4 Contar
Si un código de reserva tiene 6 dígitos, hay 10⁶ posibilidades; a 10 intentos por segundo, un atacante necesita unas 28 horas para probarlas todas, así que los límites de frecuencia y los bloqueos importan. Contar convierte la intuición en números. Con un bloqueo tras cinco intentos fallidos, un atacante tiene cinco intentos por cuenta en lugar de un millón: una probabilidad de éxito de cinco entre un millón. La misma aritmética se aplica a adivinar identificadores de pacientes a través del chatbot: si los identificadores son cortos y secuenciales, enumerarlos es barato. Rina incluye estos cálculos en sus revisiones para que los ajustes de los límites de frecuencia se apoyen en números y no en impresiones.
6.5 Ejemplo resuelto (caso sintético de LCH)
Rina enumeró los nodos y las aristas de Ask Lumen e hizo a mano una comprobación de alcanzabilidad. Dos fuentes no confiables llegaban a la herramienta de reservas: el chat de pacientes (esperado, controlado por la autenticación) y las subidas de documentos de clínica por organizaciones asociadas (inesperado). Las subidas de los asociados podían contener texto con forma de instrucción que el modelo podría seguir. LCH añadió una revisión de los documentos de los asociados y mantuvo la herramienta de reservas detrás de una comprobación de políticas vinculada al paciente que ha iniciado sesión. El segundo camino explica por qué se mantuvieron ambos controles y no uno: la revisión reduce la probabilidad de texto hostil, y la comprobación de políticas limita su efecto.
6.6 Errores y límites
- Reglas de acceso escritas solo en prosa.
- Grafos que omiten almacenes de datos y subidas.
- Ignorar lo rápido que los ordenadores enumeran posibilidades.
Las reglas en prosa dejan casos sin definir, como mostró la regla de cancelación que faltaba. Los grafos que omiten las subidas y los almacenes de datos pierden justamente la ruta por la que la inyección indirecta de instrucciones llega a una herramienta. Subestimar la velocidad de enumeración lleva a límites débiles sobre códigos e identificadores; un código de seis dígitos sin límites de frecuencia cae en aproximadamente un día a solo diez intentos por segundo, y mucho más rápido con más.
Ejercicios
- EX016 — Relación. Escriba tres triples permitidos y dos prohibidos para Ask Lumen. Rúbrica: 3 = cinco triples razonables; 2 = cuatro; 1 = dos; 0 = nada.
- EX017 — Caminos. Nombre el camino inesperado que encontró Rina y un control. Rúbrica: 3 = subidas de asociados → modelo → reservas; revisión más política vinculada al paciente; 2 = solo el camino; 1 = vago; 0 = nada.
- EX018 — Contar. Un código de 4 dígitos a 5 intentos por segundo: ¿tiempo en el peor caso? Rúbrica: 3 = 10.000/5 = 2.000 s ≈ 33 min; 2 = desliz; 1 = método; 0 = nada.
Síntesis
Las estructuras discretas dan herramientas exactas —relaciones para las reglas, grafos para el flujo de datos, conteo para la viabilidad— que hacen visibles las debilidades de los sistemas de IA.
Siga estudiando — capítulo 06 de 40
← Capítulo 05 (borrador) · Índice de capítulos del curso · Capítulo 07 (borrador) →