Cómo se gobierna la seguridad en Opendome, qué controles operan sobre los datos de cliente y qué queda documentado de cada acceso. Esta página resume el sistema de gestión; la documentación completa y sus evidencias están en el portal de confianza.
La seguridad de Opendome se gestiona mediante un SGSI alineado con ISO/IEC 27001:2022 y con los criterios de SOC 2, con un conjunto de políticas aprobadas formalmente y sujetas a revisión periódica.
Órgano de gobierno del SGSI, formado por los tres socios-directores. Aprueba en sesión documentada con quórum de dos de los tres miembros; las decisiones de mayor alcance requieren unanimidad. Cada política lleva acta de aprobación.
Responsable de la operación diaria del sistema: mantenimiento del registro de riesgos, gestión de incidentes, evaluación de terceros y atención de las consultas de seguridad y privacidad.
Políticas, riesgos, incidentes, vulnerabilidades y excepciones se registran en un sistema de gestión de cumplimiento único. Toda excepción aprobada consta con responsable y fecha de caducidad.
Por el tamaño del equipo no existe segregación estricta de funciones. El control compensatorio es la supervisión colegiada: toda decisión relevante requiere el acuerdo de al menos dos de los tres miembros del Consejo y queda registrada. Se declara así porque es la situación real, y porque un auditor lo preguntará.
La diferencia relevante entre una política de seguridad y una arquitectura segura es que la primera describe una intención y la segunda impone un comportamiento. Los cuatro controles siguientes son propiedades del sistema, no ajustes.
Los datos de cada cliente residen en un entorno aislado. No hay almacenamiento compartido entre clientes ni posibilidad de acceso cruzado por error de configuración de una consulta.
Toda lectura de datos atraviesa la capa semántica y su punto de aplicación de políticas, que opera en modo fail-closed: ante cualquier duda o fallo, deniega. Ningún backend de datos ni modelo de inferencia se expone directamente.
La consecuencia operativa es deliberada: una caída degrada hacia «sin acceso», nunca hacia «acceso no gobernado».
Cada acceso queda registrado: qué identidad consultó qué dato, con qué propósito, en qué momento, y si intentó operar fuera de su ámbito. El registro no depende de que alguien active una opción.
El consumo de modelos de lenguaje se canaliza por una pasarela gobernada, lo que reduce la superficie expuesta. La naturaleza personal de un dato se declara en la capa semántica; no se infiere automáticamente.
El acceso a sistemas y a datos se concede por necesidad de conocer, se revisa periódicamente y se revoca de forma efectiva.
| Identidad | Inicio de sesión único sobre un proveedor de identidad propio, con autenticación multifactor obligatoria mediante TOTP y claves WebAuthn. |
| Autorización | Principio de mínimo privilegio y necesidad de conocer. El acceso a producción es nominativo y trazable. |
| Secretos | Custodiados en un gestor dedicado, con acceso protegido por MFA. Todo secreto expuesto se considera comprometido y se rota: retirar el commit no se acepta como remediación. |
| Cifrado | En tránsito mediante TLS y en reposo. Cifrado de disco completo en todos los puestos de trabajo. |
| Puestos | Dispositivos personales autorizados bajo política documentada: cifrado de disco completo, protecciones del sistema activas, firma de software verificada y prohibición de desactivar los mecanismos de seguridad del sistema operativo. |
| Bajas | La revocación de accesos forma parte del procedimiento de salida y comprende la revocación de credenciales, no solo su borrado. |
El software que se despliega debe poder acreditar de dónde viene y qué contiene. Es especialmente relevante en un producto de código abierto, donde el cliente puede comprobarlo por su cuenta.
Todo cambio de código pasa por revisión de otra persona y por los controles automáticos de la canalización. La urgencia no exime de revisión: una corrección crítica sigue el mismo flujo.
Análisis de dependencias y análisis estático de código, generación de inventario de componentes y firma criptográfica de los artefactos. Las versiones se fijan explícitamente; no se despliegan etiquetas móviles.
Los entornos de desarrollo, pruebas y demostración usan siempre datos sintéticos. No se emplean datos reales de cliente fuera de producción, y las credenciales no se reutilizan entre entornos.
Las vulnerabilidades —de dependencias, de análisis estático o comunicadas externamente— se registran con severidad, responsable y plazo. El parcheo se prioriza por severidad, y una vulnerabilidad crítica explotable en producción se trata como incidente.
Cuando no existe corrección disponible o el riesgo se considera asumible, la aceptación temporal requiere aprobación del Consejo de Seguridad y se registra como excepción trazable con fecha de caducidad. Una excepción sin fecha es una vulnerabilidad olvidada.
Todo incidente se clasifica por severidad en el triaje. La severidad determina los plazos de respuesta y el nivel de escalado, y se reajusta conforme se conoce el alcance real. Ante la duda, se clasifica al alza.
| Severidad | Descripción | Activación |
|---|---|---|
| S1 · Crítica | Brecha confirmada o inminente con impacto en datos de cliente, en el aislamiento entre entornos, o caída total de producción | Coordinador y Consejo de Seguridad al completo, de inmediato |
| S2 · Alta | Impacto significativo en seguridad o servicio, sin brecha de datos confirmada | Coordinador y al menos un miembro del Consejo, en horas |
| S3 · Media | Impacto limitado o potencial, mitigable sin urgencia extrema | Coordinador; informe al Consejo en la siguiente reunión |
| S4 · Baja | Anomalía menor o evento sospechoso bajo investigación | Coordinador; registro y seguimiento |
Detección, triaje, contención, erradicación, recuperación y análisis posterior. La contención limita el daño sin destruir evidencia; la recuperación se realiza desde infraestructura declarada como código, verificando la integridad de los artefactos antes de declarar el cierre.
Las violaciones de seguridad de datos personales se notifican a la autoridad de control sin dilación indebida y, de ser posible, en un plazo no superior a 72 horas. Cuando Opendome actúa como encargado, la notificación al cliente responsable es inmediata.
El análisis posterior a los incidentes de mayor severidad se realiza sin atribución de culpa, centrado en el sistema y el proceso.
Los controles que sostienen el servicio operan hoy; los hitos de certificación tienen fecha. Publicar ambos con claridad es más útil para quien evalúa que presentarlos sin matices.
El detalle de controles, políticas y evidencias, así como el estado actualizado de cada uno, se publica en trust.opendome.eu. El reparto de responsabilidades entre Opendome y el cliente en cada modelo de despliegue se detalla en la matriz de responsabilidad compartida.
Opendome agradece la comunicación responsable de vulnerabilidades en su sitio web, sus servicios o su software, y se compromete a acusar recibo e informar del estado de su tratamiento.
Contact: mailto:security@opendome.eu
Expires: 2027-05-06T23:59:59.000Z
Preferred-Languages: es, ca, enPublicado también en /.well-known/security.txt conforme al RFC 9116. No están autorizadas las pruebas que degraden el servicio, accedan a datos de terceros, alteren información o impliquen ingeniería social. Condiciones completas en el aviso legal.
Sesión técnica para revisar la arquitectura de control de acceso, el modelo de despliegue aplicable y la documentación que necesita vuestro equipo de seguridad para completar su evaluación.
Solicitar reunión técnicaGuía técnica de 43 páginas: Despliega una IA segura, manteniendo la soberanía y gobernanza del dato con el patrón Data Lake multimodal + Dome de seguridad.
Descargar el whitepaper"El agente tiene guardrails, así que los datos están protegidos." Esa frase mezcla dos cosas que operan en planos distintos. Los guardrails vigilan lo que el agente dice; no gobiernan a lo que accede. Solo un control de acceso estructural y reproducible protege el dato, porque no es estadístico: es determinista.
tus datos, tu negocioEl software propietario que una empresa usa a diario ya está construido, por dentro, sobre open source. Los hyperscalers edifican sus productos sobre código abierto. No es la opción arriesgada, sino la base más sólida y auditada para una infraestructura de datos soberana.
Agentes AINo hay estrategia de IA empresarial sin centralizar, relacionar, describir y proteger los datos. No son cuatro buenas ideas entre las que elegir. Son cuatro condiciones, y faltar una invalida el resto.
Ver todos los recursos