En una institución pública, la seguridad no es una función técnica escondida en una sala de servidores. Es la condición que decide si un ciudadano va a confiar en un servicio digital, si un funcionario puede actuar sin temer por su propia responsabilidad y si una auditoría no va a frenar el siguiente proyecto. La seguridad en el sector público es el cimiento real de la confianza, no una formalidad atornillada al final de un despliegue.
Por nuestra experiencia, lo difícil no es comprar una herramienta, sino reunir identidades, accesos, registros, consentimientos y obligaciones del RGPD en un conjunto coherente y después mantenerlo durante años. Aunque tu institución no tenga un equipo de seguridad propio, nosotros aportamos esa competencia. La respaldamos con experiencia operando sistemas e infraestructura para la administración pública y trabajando en sistemas de seguridad, donde el control de accesos, la rendición de cuentas y la confidencialidad de los datos son un requisito y no un extra.
¿Por qué es la seguridad en una institución pública el cimiento de la confianza?
Una institución trata datos que un ciudadano no puede llevarse a otra parte: un número de identificación nacional, datos sobre salud o patrimonio. No hay una relación comercial de la que uno pueda marcharse, así que el listón de la responsabilidad está más alto que en una empresa cualquiera. Por eso tratamos la seguridad como una propiedad del sistema entero: lo que importa es a quién se le dio acceso y sobre qué base, si cada operación deja un rastro y si un incidente se puede reconstruir después. Cuando eso está en orden, una institución puede demostrar que controla sus datos, y esa clase de confianza es difícil de reconstruir tras una sola fuga.
¿Cómo gestionar la identidad y los accesos (IAM) en una institución?
El cimiento es la gestión de identidades y accesos (IAM), una respuesta clara a quién es quién en el sistema y qué puede hacer. Cuando el personal cambia, se mueve entre departamentos y usa muchos sistemas a la vez, sin ese orden los accesos se descontrolan rápido.
Diseñamos la capa de IAM en torno a unos cuantos mecanismos que reducen el riesgo de verdad:
- roles y permisos basados en la función (RBAC) en lugar de asignados a mano a personas concretas,
- el principio de mínimo privilegio, es decir, exactamente el acceso que exige la tarea y nada más,
- autenticación multifactor (MFA) e inicio de sesión a través de una fuente central de identidad (SSO, federación), para que las contraseñas no se multipliquen,
- revocación automática de los accesos cuando alguien cambia de rol o se va, conectada con el sistema de RR. HH.
Con esto, el acceso sigue al rol y no al historial laboral. El mínimo privilegio es la clave: ningún acceso por defecto y cada ampliación es una decisión deliberada, con un responsable y una fecha de caducidad. Una cuenta comprometida no le abre entonces al atacante el sistema entero, solo la porción asignada a ese rol.
¿Cómo construir un rastro de auditoría y políticas de retención de datos?
La rendición de cuentas empieza por un rastro de auditoría, un registro innegable de quién hizo qué con qué datos y cuándo. En el sector público esto no es una comodidad, sino una prueba en caso de inspección, reclamación ciudadana o procedimiento judicial. Por eso construimos el registro para que cubra lecturas y modificaciones de datos sensibles, cambios de permisos y operaciones administrativas, con los propios registros protegidos frente a manipulaciones.
De la mano van las políticas de retención. Los datos guardados «por si acaso» para siempre son a la vez un riesgo y un incumplimiento del principio de limitación del plazo de conservación. Por eso definimos cuánto vive cada categoría de datos y de registros, cuándo se archiva y cuándo se borra de forma definitiva, y automatizamos esos ciclos para que el cumplimiento no dependa de que alguien se acuerde de hacer limpieza.
¿Cómo gestionar los consentimientos y los datos personales bajo el RGPD?
El RGPD en la administración pública tiene su propio carácter: la base del tratamiento suele ser una disposición legal o una misión pública, y no el consentimiento. Allí donde sí hace falta consentimiento, sin embargo, hay que recogerlo de forma deliberada, versionarlo y poder revocarlo, y el sistema tiene que mostrar sobre qué base y con qué finalidad trata un registro dado. Aquí nos centramos en los mecanismos que materializan los derechos de la ciudadanía y los deberes del responsable del tratamiento:
- un registro de actividades de tratamiento ligado a las funciones reales del sistema, no llevado aparte en una hoja de cálculo,
- la atención de los derechos de las personas interesadas (acceso, rectificación, supresión, portabilidad), disponible tanto en lo procedimental como en lo técnico,
- minimización y seudonimización allí donde la tarea no necesita los datos completos,
- vinculación de los consentimientos a las finalidades, para que retirar un consentimiento detenga de verdad ese tratamiento.
Así el cumplimiento del RGPD es un producto de cómo funciona el sistema y no documentación añadida a posteriori.
¿Por qué necesita una institución revisiones periódicas de protección de datos?
La seguridad no es un estado al que llegas y que marcas como hecho. La ley, las personas, las integraciones y las amenazas cambian, así que un montaje que hace un año era estanco puede tener huecos hoy. Por eso tratamos las revisiones de protección de datos como un ritmo constante y no como una reacción a una inspección: verificamos periódicamente los permisos concedidos, analizamos los registros en busca de patrones inusuales, comprobamos que las políticas de retención estén al día y probamos los procedimientos de respuesta a incidentes. Una revisión así detecta la deriva antes de que se convierta en un incidente.
¿Cómo abordamos el cumplimiento (marcos nacionales, NIS2)?
Las instituciones públicas se mueven por una red densa de requisitos. Los marcos nacionales de interoperabilidad fijan estándares de, entre otras cosas, seguridad de la información y disponibilidad de los sistemas, mientras que la directiva NIS2 sube el listón de la gestión de riesgos, la notificación de incidentes y la responsabilidad de la dirección.
No los tratamos como listas de verificación separadas. La mayoría se reducen a los mismos fundamentos: control de accesos, rendición de cuentas, gestión de riesgos y capacidad de responder a un incidente. Si esos están sólidos, cumplir con la siguiente norma consiste sobre todo en documentar lo que ya funciona y no en rehacer el sistema. Aquí asesoramos en términos generales y apoyamos la implantación técnica, dejando la interpretación jurídica a los juristas de la institución.
¿Qué competencias de seguridad aportamos a una institución?
Este es el corazón de nuestro modelo: aunque no tengas un departamento de seguridad propio, aportamos a las personas y a las competencias que hacen el trabajo. Cubrimos roles concretos, ajustados a la fase del proyecto y a los huecos de tu lado:
- ingenieros de IAM e identidad que diseñan los roles, el SSO, el MFA y la integración con la fuente de RR. HH.,
- arquitectos de seguridad que atan autenticación, cifrado, registro y retención en un modelo coherente,
- desarrolladores familiarizados con los requisitos del sector público, que escriben código pensando en la auditabilidad y en la protección de datos,
- apoyo en cumplimiento que traduce los requisitos de los marcos y de NIS2 en funcionalidades y configuraciones concretas.
No ponemos precio a «la seguridad en general», solo a las competencias que de verdad necesitas.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia que entiende la realidad de la administración y la exigencia de rendir cuentas:
- verificamos las competencias antes de empezar y damos forma al equipo en torno a la institución, no «por si acaso»,
- nos apoyamos en la experiencia operando sistemas e infraestructura para el sector público y en proyectos donde la seguridad y el control de accesos eran el núcleo de la solución,
- nos enchufamos a los procedimientos y herramientas que ya tiene la institución en vez de imponer nuestro mundo, y trabajamos en una franja horaria cercana, así que las revisiones y la respuesta a incidentes van sin retraso.
Lo más habitual es que lo entreguemos como software a medida construido por nuestro equipo y, donde hay que completar rápido una competencia concreta, como refuerzo de equipo.
¿Por dónde empezar con la seguridad y el cumplimiento?
Empieza por una respuesta honesta a dos preguntas: quién tiene hoy acceso a los datos y sobre qué base, y si puedes reconstruir lo que pasó con ellos. Si cualquiera de las dos respuestas es «no del todo», ahí está el mayor riesgo y ahí es donde empezamos: por el IAM y el rastro de auditoría, y solo después cerramos la retención, los consentimientos y el cumplimiento. Las diferencias entre los modelos de colaboración las tratamos en nuestro artículo sobre modelos de colaboración en TI.
¿Quieres poner en orden la seguridad y el cumplimiento de tu institución? Hablemos - ajustamos las competencias y el enfoque a tus sistemas y requisitos.
Refuerza con nosotros la seguridad y el cumplimiento de tu institución