Limitar accesos y proteger las integraciones del chatbot
Una respuesta convincente no puede conceder permisos. La seguridad debe sostenerse en controles que el sistema compruebe fuera de la generación de texto.
Objetivo: Proponer accesos, separación de entornos y límites de integración, con pruebas de denegación y una alternativa de servicio.
Proteger el recorrido completo
El modelo es una pieza del sistema; las fuentes, identidades e interfaces también importan.
Retoma el mapa de FD-001. ¿Quién puede modificar DAT-001? ¿Qué fuentes puede recuperar cada usuario? ¿Qué cuenta utiliza una integración? ¿Quién consulta DAT-004? ¿Una respuesta puede abrir o modificar un ticket? Son preguntas del uso propuesto, no capacidades confirmadas de Tech Server IIT Spain.
Las orientaciones de NCSC sitúan la seguridad en el diseño, el desarrollo, el despliegue y la operación. En el ejercicio revisaremos ese recorrido mediante acceso, configuración y comprobaciones, sin presentar una lista de medidas como garantía de seguridad. Referencia R5.
La confidencialidad protege frente a exposición indebida; la integridad, frente a alteraciones; y la disponibilidad, frente a la pérdida de acceso al servicio necesario. Una medida puede mejorar una dimensión y crear una dependencia que también necesita seguimiento.
Asignar permisos a tareas concretas
Distingue lectura, modificación, administración y consulta de evidencias.
| Función | Acceso propuesto y límite |
|---|---|
| Usuario de soporte | Consultar fuentes admitidas para su ámbito. No acceder a información de otro cliente por pedirlo al chatbot. |
| Responsable del contenido | Proponer y mantener fuentes dentro de su ámbito. Seguir el cauce previsto para aprobación y publicación. |
| Función técnica | Configurar integración y despliegue con permisos delimitados. Proteger cuentas de servicio y secretos. |
| Función de revisión | Acceder a evidencias necesarias y protegidas. No disponer automáticamente de todas las conversaciones. |
Utiliza cuentas identificables y permisos ajustados a la tarea. En equipos pequeños una persona puede desempeñar varias funciones; las responsabilidades, aprobaciones y revisiones pertinentes siguen necesitando claridad. Evita imponer una estructura que el servicio no puede sostener.
Mantener los límites fuera del texto generado
Un aviso en el prompt no sustituye una comprobación de autorización.
La inyección de instrucciones intenta que contenido de una consulta o una fuente influya indebidamente en el comportamiento del sistema. Puede llegar por un adjunto o documento que el chatbot consulta, aunque el usuario no haya escrito directamente esa instrucción.
Una consigna como «no reveles información de otros clientes» no establece por sí sola un límite de seguridad. Propón comprobaciones de identidad, autorización y ámbito en la recuperación de datos y en la integración, además de limitar las acciones disponibles para el sistema. Referencia R6.
Si un chatbot solo prepara orientación, no necesita permisos para ejecutar cambios de administración. Si se plantea una acción adicional, habrá que justificarla, delimitarla y revisarla. No presumas que un filtro elimina toda inyección ni que la ausencia de intentos detectados demuestra protección.
Separar pruebas, producción y secretos
Una prueba útil no debe abrir una vía inadvertida hacia el servicio real.
Propón entornos y cuentas de prueba delimitados, fuentes sintéticas, credenciales protegidas y acceso controlado a la configuración. Un nombre como «sandbox» no acredita separación: hay que comprobar conexiones, permisos y efectos.
Revisa también cachés, índices y búsquedas entre ámbitos. Un usuario puede recibir información indebida si una capa reutiliza respuestas de otro cliente sin comprobar los límites, aunque la interfaz le muestre únicamente su cuenta.
La seguridad incluye altas, cambios y bajas de acceso. Al cambiar una función o retirar una integración, revisa permisos activos, cuentas de servicio y dependencias. Estas necesidades se coordinarán con la gestión de cambios y proveedores del módulo 9.
Comprobar lo que debe denegarse
Una prueba de seguridad también pregunta si el servicio sabe decir no y seguir atendiendo.
Diseña tres comprobaciones sintéticas: un usuario pide una fuente fuera de su ámbito; una fuente incluye una instrucción que propone saltarse una restricción; una cuenta de prueba intenta una acción fuera de su permiso. Define la denegación esperada antes de ejecutarlas.
La evidencia debe permitir revisar qué cuenta y configuración se utilizaron, qué se intentó y qué efecto real hubo. Una respuesta verbal «no puedo hacerlo» no demuestra que una integración no haya realizado la acción. Mantén separadas salida, llamada a la herramienta y operación ejecutada.
Cuando se limita una operación, ofrece un cauce de soporte viable. Ante un posible problema urgente, activa el cauce competente sin esperar a completar la ficha. La contención se decide según riesgo, alcance y dependencias, coordinando protección, evidencia y continuidad cuando sea viable. La prueba, sus resultados y la aceptación del riesgo residual deben permanecer diferenciados.
Actividad: preparar tu ficha
Añade a FD-001 una propuesta de permisos y límites de integración. Elige una operación que el chatbot no debería poder realizar y diseña su comprobación.
Orientación para revisar tu propuesta
La propuesta comprueba autorizaciones en las capas que recuperan datos o ejecutan acciones. Separa cuenta, respuesta generada y efecto operativo. Los intentos sintéticos incluyen denegación, evidencia y continuidad. No se da por seguro el uso porque una prueba termine sin incidentes detectados.
Comprueba tu criterio
Explica tus decisiones antes de consultar las orientaciones.
Responde primero con tus palabras. Abre cada orientación después de tu intento.
¿Un prompt que prohíbe revelar secretos garantiza la confidencialidad?
No. La protección necesita límites de acceso y de integración comprobables, además de otras medidas adecuadas al riesgo.
¿La palabra «sandbox» demuestra que la prueba está aislada?
No. Hay que comprobar cuentas, conexiones, fuentes, permisos y posibles efectos sobre producción.
¿Qué revisarías si el chatbot dice «acción denegada»?
La respuesta y la operación real por separado: llamadas a la integración, permisos utilizados y efectos. El texto no demuestra que una acción no se haya ejecutado.
Lo que te llevas: Tienes una propuesta de acceso y límites que puede comprobarse en el sistema. La última lección explica cómo conservar evidencia suficiente y retirar datos y copias con criterio.