Seguridad física para la soberanía de datos en el uso compartido de archivos empresariales
Soberanía de los datos suele discutirse en términos abstractos: jurisdicciones, marcos legales, derechos contractuales y declaraciones de cumplimiento. La seguridad física es donde esas abstracciones terminan. El hardware que almacena los datos confidenciales de tu organización está en una instalación que controlas o no lo está. Las claves criptográficas que protegen esos datos están en módulos de hardware que tú gestionas o no lo están. Cuando un dispositivo de almacenamiento llega al final de su vida útil, tu equipo lo destruye directamente o pasa por una cadena de custodia que no puedes verificar completamente.
Estos no son casos excepcionales. Son las preguntas operativas que distinguen la auténtica soberanía de los datos del mero cumplimiento superficial. Para los responsables de seguridad física, equipos de auditoría y CISOs encargados de la seguridad de centros de datos y hardware, la evaluación de una plataforma de uso compartido de archivos empresariales debe incluir cuatro preguntas clave: ¿dónde está el hardware?, ¿quién puede acceder físicamente?, ¿quién controla las claves criptográficas y en qué hardware?, ¿y qué ocurre con los medios de almacenamiento cuando deben destruirse? Este artículo responde a cada pregunta, analiza el panorama de certificaciones y estándares relevantes, y explica cómo el modelo de implementación define las respuestas.
Resumen Ejecutivo
Idea principal: La seguridad física en el uso compartido de archivos empresariales es una cuestión de modelo de implementación antes que de certificación del proveedor. Una implementación en las instalaciones coloca el hardware dentro de las instalaciones del cliente, haciendo que los controles de acceso físicos, la destrucción de medios y la operación de HSM dependan totalmente del cliente. Una implementación en la nube gestionada por el proveedor transfiere la responsabilidad de la seguridad física a los socios de centros de datos del proveedor, con certificaciones como BSI C5, ISO 27001, FedRAMP e IRAP que ofrecen garantías de terceros. Los clientes con los requisitos más altos de soberanía física —defensa, infraestructuras críticas, mercados financieros— deben considerar la implementación en las instalaciones como punto de partida, no como alternativa secundaria.
Por qué te interesa: El artículo 21 de NIS 2 exige a los operadores de servicios esenciales implementar medidas adecuadas de seguridad física y ambiental para los sistemas de información. Los controles del Anexo A de ISO 27001 (A.7, Controles físicos) aplican tanto a instalaciones gestionadas por el cliente como por el proveedor, pero la capacidad de verificación del cliente es fundamentalmente diferente según si el hardware le pertenece. BSI C5 y FedRAMP High incluyen familias de controles explícitos de protección física (PE), proporcionando evaluaciones estructuradas de terceros sobre la infraestructura gestionada por el proveedor. Entender qué controles corresponden a cada parte —y cómo verificarlos— es la tarea central de la debida diligencia en seguridad física.
5 Aspectos Clave
- La implementación en las instalaciones otorga al cliente soberanía física total sobre su infraestructura de archivos. Cuando el appliance de Kiteworks funciona en hardware que el cliente posee y gestiona, cada decisión de seguridad física —control de acceso, estándares de la instalación, monitoreo ambiental, gestión de visitantes— la toma el cliente. El proveedor no tiene acceso físico al hardware salvo que se le conceda explícitamente. Esta es la postura de soberanía física más robusta y es directamente verificable sin depender de certificaciones del proveedor.
- Los HSM gestionados por el cliente mantienen las claves de cifrado fuera del alcance del proveedor. Los módulos de seguridad de hardware ofrecen almacenamiento resistente a manipulaciones para las claves en hardware criptográfico dedicado. Cuando el HSM lo gestiona el cliente y cuenta con validación FIPS 140-3, el proveedor no puede acceder a las claves de cifrado sin importar su acceso administrativo a la capa de aplicación. El modelo Hold Your Own Key (HYOK), soportado por proveedores validados como SafeNet Luna Network HSM de Thales, permite que incluso en implementaciones alojadas la custodia de las claves permanezca en manos del cliente.
- El control sobre la destrucción de medios es un requisito de soberanía frecuentemente ignorado. ¿Quién destruye los medios de almacenamiento, bajo qué procedimiento y con qué evidencia? En una implementación en las instalaciones, el cliente controla directamente la destrucción de medios —sin cadena de custodia del proveedor, sin depender de certificados de terceros, sin programación de destrucción que requiera coordinación con el proveedor. En implementaciones en la nube, la responsabilidad recae en el proveedor y se acredita mediante certificaciones como BSI C5 e ISO 27001.
- Los procedimientos de ceremonia de claves son tan importantes como el hardware HSM. Un HSM validado FIPS 140-3 ofrece resistencia física a manipulaciones, pero la seguridad de la clave depende de la ceremonia de generación: cómo se creó la clave, quién la generó, bajo qué controles y con qué registro de auditoría. Ceremonias formales y documentadas bajo control del cliente complementan el hardware HSM y son requeridas por marcos como NIST SP 800-57 y PCI DSS.
- La certificación de instalaciones en la nube por parte del proveedor aporta garantía, no control. BSI C5 Tipo 2, ISO 27001, FedRAMP High e IRAP PROTECTED incluyen componentes de evaluación de seguridad física y ofrecen evidencia de terceros de que las instalaciones gestionadas por el proveedor cumplen los estándares definidos. Pero la certificación es una constatación de cumplimiento en un momento concreto, no un control en tiempo real. Las organizaciones que requieren control físico en tiempo real y verificable de forma independiente deben poseer el hardware.
Modelo de Implementación y Soberanía Física
Las preguntas sobre soberanía física no pueden responderse sin considerar el modelo de implementación. Si el hardware es propiedad del cliente en sus instalaciones, gestionado por el proveedor en una nube privada o funcionando en una nube pública depende de la elección de implementación —y esa elección determina todo el panorama de seguridad física. La mayoría de las evaluaciones de plataformas de uso compartido de archivos empresariales se centran en funciones y certificaciones sin resolver primero el modelo de implementación. Ese es el orden incorrecto.
En las Instalaciones: Control Físico Total del Cliente
En una implementación en las instalaciones, el appliance de Kiteworks funciona en hardware que el cliente posee e instala en una instalación que el propio cliente gestiona. El acceso físico al servidor, almacenamiento y hardware de red está completamente regido por el programa de seguridad física del cliente. El cliente decide qué personal está autorizado a entrar en la sala de servidores, qué monitoreo ambiental se utiliza, qué mecanismos de acceso físico multifactor protegen el equipo y qué sistemas de vigilancia cubren la instalación. Ninguna de estas decisiones corresponde al proveedor.
Esto es relevante por varias razones específicas que abordan directamente los marcos regulatorios. El artículo 21(2)(e) de NIS 2 exige «seguridad física y ambiental» como una de las medidas básicas para servicios esenciales. El Anexo A.7 de ISO 27001 (Controles físicos) incluye controles sobre áreas seguras, controles de entrada física, protección de oficinas y equipos, monitoreo de seguridad física y protección contra amenazas ambientales. Cuando el cliente opera el hardware, cada uno de estos controles está bajo su implementación y alcance de auditoría directa —verificable con evidencia de primera parte sin depender de declaraciones del proveedor.
El modelo en las instalaciones también determina quién puede realizar una inspección física no anunciada. Los reguladores y equipos de auditoría interna pueden entrar en las instalaciones del cliente en cualquier momento y verificar los controles físicos directamente. En una implementación en la nube, el acceso al centro de datos del proveedor para inspección física requiere coordinación previa, suele estar limitado a observación indirecta y puede requerir la facilitación del proveedor. Para organizaciones sujetas a requisitos de inspección supervisora —especialmente en servicios financieros, defensa e infraestructuras críticas— esto no es un detalle procedimental. Es una cuestión de derechos de auditoría.
Qué verificar: Confirma con el proveedor si la implementación en las instalaciones otorga a tu equipo acceso físico total al hardware del appliance —incluida la posibilidad de añadir o reemplazar controles físicos de seguridad en el propio hardware (por ejemplo, precintos antimanipulación). Comprende si el proveedor mantiene alguna vía de acceso remoto al appliance y bajo qué condiciones.
Infraestructura Gestionada por el Proveedor: Certificación como Garantía
Las implementaciones en la nube gestionadas por Kiteworks funcionan en instalaciones sujetas a evaluaciones estructuradas de seguridad física por terceros. BSI C5 (Catálogo de Criterios de Cumplimiento de Computación en la Nube) Tipo 2 cubre la seguridad física como componente explícito de su marco de control, incluyendo requisitos para controles de acceso físico, vigilancia, protección ambiental y manejo de medios. Un informe Tipo 2 aporta evidencia de efectividad operativa durante un periodo de evaluación —no solo adecuación de diseño en un momento puntual.
La certificación ISO 27001 aplica al sistema completo de gestión de seguridad de la información, incluidos los controles físicos y ambientales del Anexo A.7. ISO 27001:2022 amplió el anexo de controles físicos respecto a la edición 2013, añadiendo requisitos explícitos sobre política de escritorio limpio, ubicación de equipos y monitoreo de seguridad física. La certificación ISO 27001 de Kiteworks cubre sus operaciones de infraestructura en la nube.
Para cargas de trabajo gubernamentales australianas, la clasificación IRAP PROTECTED exige evaluación de seguridad física bajo el ISM (Manual de Seguridad de la Información) del Gobierno de Australia, que incluye requisitos específicos para la seguridad física de instalaciones que procesan información PROTECTED. Para cargas de trabajo del gobierno de EE. UU. y sectores relacionados con defensa, el estado FedRAMP High In Process de Kiteworks implica evaluación de la familia de controles de Protección Física y Ambiental (PE) en el nivel High —uno de los conjuntos de controles de seguridad física más exigentes del marco federal estadounidense.
El punto clave es que estas certificaciones ofrecen evidencia estructurada y creíble de terceros sobre los controles de seguridad física en instalaciones gestionadas por el proveedor. No otorgan al cliente control directo sobre esos controles. Las organizaciones que requieren control —no solo garantía— necesitan el modelo de implementación en las instalaciones.
| Certificación / Marco | Cobertura de Seguridad Física | Tipo de Evaluación | Aplica a |
|---|---|---|---|
| BSI C5 Tipo 2 | Controles de acceso físico, protección ambiental, manejo de medios | Atestación de terceros, efectividad operativa durante un periodo | Nube gestionada por Kiteworks |
| ISO 27001 | Anexo A.7: Controles físicos (áreas seguras, entrada, protección de equipos) | Auditoría de certificación por terceros | Nube gestionada por Kiteworks |
| FedRAMP High In Process | Familia de controles PE (Protección Física y Ambiental) en nivel High | Evaluación 3PAO | Implementaciones en la nube del gobierno de EE. UU. |
| IRAP PROTECTED | Seguridad física según ISM del Gobierno de Australia | Evaluación de evaluador IRAP | Cargas de trabajo gubernamentales australianas |
| SOC 2 Tipo 2 | Criterios de disponibilidad y confidencialidad incluyen controles de acceso físico | Atestación de terceros, efectividad operativa | Nube gestionada por Kiteworks |
| En las instalaciones (no requiere certificación) | Definido por el cliente según sus propios estándares de centro de datos | Control de primera parte, directamente auditable | En las instalaciones gestionadas por el cliente |
Módulos de Seguridad de Hardware: Custodia de Claves y Soberanía Criptográfica
El cifrado en reposo protege los datos frente a accesos no autorizados en la capa de almacenamiento. Pero la protección solo llega hasta la seguridad de las claves de cifrado. Si el proveedor posee las claves —o puede acceder a ellas—, en principio podría descifrar los datos. Esa es la cuestión fundamental de soberanía criptográfica que resuelve la integración de HSM.
Un Módulo de Seguridad de Hardware es un dispositivo criptográfico dedicado diseñado para generar, almacenar y gestionar claves de cifrado en hardware resistente a manipulaciones. Los HSM se diferencian de la gestión de claves por software en que el material de la clave nunca existe en texto claro fuera del perímetro del HSM —las operaciones de clave (cifrado, descifrado, firma) ocurren dentro del dispositivo, y este está diseñado para destruir el material de la clave si detecta manipulación física. En entornos de alta seguridad, los HSM son el mecanismo esperado para la gestión de claves, no una mejora opcional.
Validación FIPS 140-3: El Estándar de Hardware para la Confianza Criptográfica
FIPS 140-3 (Federal Information Processing Standard 140-3) es el estándar estadounidense para la validación de módulos criptográficos, administrado conjuntamente por NIST y el Centro Canadiense para la Ciberseguridad. Sustituyó a FIPS 140-2 como estándar activo y está alineado con ISO/IEC 19790. FIPS 140-3 define cuatro niveles de seguridad —del 1 al 4—, cada uno con requisitos progresivamente más estrictos de resistencia física a manipulaciones.
El nivel 3 es el mínimo habitual para implementaciones empresariales de HSM en entornos regulados: exige evidencia de manipulación física, mecanismos de detección y respuesta que borren parámetros críticos de seguridad al detectar manipulación y autenticación basada en identidad. El nivel 4 añade resistencia a ataques ambientales y suele encontrarse en sistemas de pagos y clasificados.
Kiteworks admite integración con HSM gestionados por el cliente y validados en FIPS 140-3. El socio de integración documentado para implementaciones en las instalaciones es SafeNet Luna Network HSM de Thales (antes Gemalto), un módulo validado FIPS 140-3 ampliamente utilizado en servicios financieros regulados, gobierno, salud y defensa. SafeNet Luna HSM ofrece almacenamiento de claves resistente a manipulaciones, soporte formal para ceremonias de claves y registro de auditoría a nivel de hardware. El certificado de validación del HSM puede verificarse directamente en la base de datos CMVP de NIST, proporcionando evidencia independiente y verificable del nivel de garantía criptográfica del módulo.
Hold Your Own Key (HYOK): Custodia de Claves en Manos del Cliente
El modelo Hold Your Own Key es el patrón arquitectónico mediante el cual la custodia de las claves permanece completamente en manos del cliente, independientemente de dónde se ejecute la aplicación. En una configuración HYOK, la clave de cifrado nunca sale del HSM del cliente —o, más precisamente, la clave en texto claro nunca abandona el perímetro del HSM. Cuando la aplicación necesita descifrar datos, envía una solicitud de descifrado al HSM; el HSM realiza la operación y devuelve los datos descifrados (no la clave). La capa de aplicación del proveedor nunca accede al material de la clave.
Esta distinción es importante porque separa el acceso lógico (la aplicación del proveedor puede procesar datos) de la custodia de la clave (el proveedor no puede descifrar datos de forma independiente sin que el HSM del cliente esté disponible y la solicitud esté autorizada). Si el cliente retira el HSM del proceso de gestión de claves —por política, desconexión física o en respuesta a una orden legal— el proveedor no puede descifrar los datos, sin importar el acceso que tenga a la aplicación o al almacenamiento.
Kiteworks soporta HYOK para implementaciones en las instalaciones, donde el HSM está físicamente en las instalaciones del cliente y bajo control operativo total del cliente. Esta configuración ofrece la postura de soberanía criptográfica más robusta: el hardware que almacena las claves está en la instalación del cliente, gestionado por su equipo, sin vía de acceso remoto para el proveedor.
Ceremonia de Claves: Controles Procedimentales para la Generación de Claves
Una ceremonia de claves formal es el procedimiento documentado mediante el cual se genera una clave criptográfica, se divide (si se usa división de claves), se carga en un HSM y se activa bajo controles procedimentales que aseguran que ninguna persona tenga acceso completo al material de la clave en ningún momento. Los requisitos de ceremonia de claves están especificados en NIST SP 800-57 Parte 1 (Recomendación para la Gestión de Claves), PCI DSS Requisito 3.7 y varios estándares sectoriales.
La ceremonia es importante porque la seguridad de todas las operaciones criptográficas posteriores depende de la integridad del evento de generación de la clave. Una clave generada sin controles procedimentales —por un solo operador, sin testigos, sin documentación— no es más confiable que una clave gestionada por software en memoria de aplicación, sin importar cuán seguro sea el HSM que la almacena. La ceremonia es el ancla de confianza procedimental para todo el ciclo de vida de la clave.
En implementaciones de Kiteworks en las instalaciones, los procedimientos de ceremonia de claves se realizan completamente bajo control del cliente. El equipo del cliente define los requisitos procedimentales, selecciona participantes y testigos, determina si se aplica conocimiento dividido y control dual, y genera la documentación de auditoría. Esto es directamente auditable por el propio equipo de auditoría del cliente y por auditores externos —los registros de la ceremonia son evidencia de primera parte en manos del cliente, no una declaración del proveedor.
| Elemento de Gestión de Claves | Implementación en las Instalaciones | Implementación en la Nube del Proveedor |
|---|---|---|
| Operación de HSM | HSM gestionado por el cliente en sus instalaciones | Servicio de gestión de claves gestionado por el proveedor o integración HYOK del cliente; AWS KMS también soportado como opción externa de gestión de claves para implementaciones en la nube |
| Custodia de claves | Controlada por el cliente; el proveedor no tiene acceso | En manos del proveedor (por defecto) o HYOK del cliente |
| Validación FIPS 140-3 | HSM seleccionado por el cliente, verificable en CMVP | Infraestructura seleccionada por el proveedor, acreditada en certificaciones |
| Ceremonia de claves | Procedimiento controlado por el cliente, evidencia de primera parte | Gestionada por el proveedor, acreditada en informes de auditoría |
| Revocación de claves | Inmediata, iniciada por el cliente, sin intervención del proveedor | Coordinada con el proveedor; el tiempo depende de la arquitectura |
Destrucción de Medios: El Final del Ciclo de Vida de los Datos
La gestión del ciclo de vida de los datos termina con la destrucción de los medios de almacenamiento. La mayoría de los debates sobre seguridad empresarial se centran en el inicio y el medio del ciclo —cifrado en reposo, controles de acceso, registros de auditoría— y tratan la eliminación de medios como una nota procedimental. Para organizaciones sujetas a regulación de protección de datos o requisitos de manejo de información clasificada, esto es un error. La cuestión de quién destruye físicamente los medios, con qué método y con qué verificación es una cuestión de soberanía con implicaciones regulatorias y contractuales directas.
Destrucción Controlada por el Cliente en Implementaciones en las Instalaciones
Cuando el appliance de Kiteworks funciona en hardware propiedad del cliente, la destrucción de medios de almacenamiento está completamente bajo control del cliente. El equipo del cliente decide el método de destrucción —desmagnetización, trituración física, borrado criptográfico o una combinación—, ejecuta el procedimiento, presencia la destrucción y genera el certificado de eliminación. No se requiere intervención del proveedor, no hay necesidad de coordinación de agendas ni se introduce una cadena de destrucción de terceros.
Esto es especialmente relevante en dos escenarios regulatorios concretos. Primero, cuando los requisitos regulatorios obligan a que la destrucción de medios se realice dentro del perímetro de seguridad del cliente —común en defensa y entornos clasificados—, la implementación en las instalaciones es la única configuración que cumple el requisito. Segundo, cuando una investigación o proceso legal exige la interrupción inmediata de todas las operaciones sobre los medios, el equipo del cliente puede actuar sin demoras de coordinación con el proveedor.
El Anexo A.7.10 de ISO 27001 (Medios de almacenamiento) exige que los medios se gestionen durante todo su ciclo de vida, incluida la eliminación segura. El estándar no prescribe un método específico de destrucción, pero exige que la eliminación se realice de forma adecuada a la sensibilidad de la información almacenada. NIST SP 800-88 (Guía para la Sanitización de Medios) proporciona la referencia técnica más utilizada sobre métodos de destrucción y su aplicabilidad según tipo de medio y nivel de sensibilidad. En una implementación en las instalaciones, el cliente elige el método adecuado según la guía NIST SP 800-88 y lo aplica directamente.
Destrucción Gestionada por el Proveedor: Certificación y Cadena de Custodia
En implementaciones en la nube gestionadas por el proveedor, los medios de almacenamiento forman parte de la infraestructura del proveedor (o del proveedor de la nube). La destrucción de medios la realiza el proveedor o sus socios de centros de datos, acreditada mediante las certificaciones correspondientes. BSI C5 exige procedimientos documentados de manejo y destrucción de medios como parte de sus criterios de seguridad física. ISO 27001 cubre este aspecto en el Anexo A.7.10. La familia de controles PE de FedRAMP incluye controles de protección de medios (familia MP) que abordan la sanitización y eliminación.
Estas certificaciones ofrecen evidencia de terceros de que existen y se siguen procedimientos documentados de destrucción. No dan al cliente visibilidad directa sobre cuándo se destruye un medio concreto, qué medio contenía sus datos o qué método de destrucción se aplicó a su almacenamiento específico. Para la mayoría de las organizaciones reguladas, este nivel de garantía acreditada es suficiente. Para organizaciones con datos de máxima sensibilidad —datos clasificados, información no pública relevante, datos críticos de infraestructuras nacionales— la ausencia de control y verificación directa es una limitación real del modelo de implementación en la nube.
Qué verificar: Solicita al proveedor que especifique la cadena contractual y operativa de custodia para la eliminación de medios de almacenamiento. Confirma qué certificaciones cubren el centro de datos donde residen tus datos —no solo el portafolio general de certificaciones del proveedor. Pide la carta de atestación BSI C5 o ISO 27001 más reciente que cubra la instalación específica que procesa tus datos y verifica que la eliminación de medios esté dentro del alcance.
Responsabilidad Compartida: Qué Significa el Modelo en la Práctica
El modelo de responsabilidad compartida se discute ampliamente en el contexto de la seguridad en la nube, pero es especialmente importante para la seguridad física porque las responsabilidades son más claras en los extremos: completamente en las instalaciones o completamente en la nube. La ambigüedad surge en configuraciones híbridas y de co-ubicación, que es donde realmente se encuentran muchas implementaciones empresariales.
Comprender qué controles de seguridad física corresponden al cliente y cuáles al proveedor no es solo un ejercicio de cumplimiento —determina de dónde debe provenir tu evidencia de auditoría, qué controles debes probar en tus propias evaluaciones y dónde es más probable que surjan brechas en una inspección supervisora.
| Dominio de Seguridad Física | En las Instalaciones: Quién Controla | Nube del Proveedor: Quién Controla | Fuente de Evidencia |
|---|---|---|---|
| Acceso físico al centro de datos | Cliente | Proveedor / socio de centro de datos | Primera parte (en las instalaciones); BSI C5 / ISO 27001 (nube) |
| Controles ambientales de la sala de servidores | Cliente | Proveedor / socio de centro de datos | Primera parte (en las instalaciones); BSI C5 / ISO 27001 (nube) |
| Detección de manipulación de hardware | Cliente | Proveedor | Primera parte (en las instalaciones); atestación del proveedor (nube) |
| Operación de HSM y custodia de claves | Cliente | Proveedor (por defecto) o HYOK del cliente | Primera parte (en las instalaciones); certificado FIPS 140-3 / arquitectura HYOK (nube) |
| Destrucción de medios de almacenamiento | Cliente | Proveedor / socio de centro de datos | Primera parte (en las instalaciones); BSI C5 / ISO 27001 / FedRAMP PE (nube) |
| Acceso de visitantes y mantenimiento | Cliente | Proveedor / socio de centro de datos | Primera parte (en las instalaciones); BSI C5 / ISO 27001 (nube) |
Diferenciación de Kiteworks: Seguridad Física en Todos los Modelos de Implementación
Kiteworks ofrece un espectro de implementación que va desde completamente en las instalaciones hasta nube gestionada por el proveedor, con la postura de seguridad física variando a lo largo de ese espectro. A continuación se resumen los diferenciadores documentados de capacidad para seguridad física e integración HSM.
Modelo de Appliance en las Instalaciones
El appliance de Kiteworks está diseñado para funcionar en hardware propiedad del cliente dentro de sus propias instalaciones. No se trata de una co-ubicación ni de una nube privada alojada por Kiteworks —es hardware que el cliente adquiere, opera y controla físicamente. El appliance puede implementarse en centros de datos que el cliente gestiona bajo su propio ISO 27001, BSI IT-Grundschutz o programa sectorial de seguridad, otorgando al cliente soberanía física total sobre la implementación.
El control del cliente abarca la selección de hardware, los mecanismos de seguridad física aplicados al appliance (precintos antimanipulación, cierre de racks, tarjetas de acceso para la sala de equipos), la configuración de monitoreo ambiental y los procedimientos de destrucción de medios. El proveedor no tiene acceso físico al hardware en esta configuración —cualquier acceso remoto para soporte requiere autorización explícita del cliente y se rige por la política de acceso remoto del cliente.
Integración HSM con Proveedores Empresariales Líderes
Kiteworks soporta integración con SafeNet Luna Network HSM de Thales, un módulo de hardware validado FIPS 140-3 ampliamente implementado en sectores regulados. En implementaciones en las instalaciones, el HSM está físicamente en las instalaciones del cliente y opera bajo gestión total del cliente. La arquitectura HYOK garantiza que los procesos de la aplicación Kiteworks envían solicitudes criptográficas al HSM pero no reciben el material de la clave —solo el resultado de la operación criptográfica. Esto significa que el acceso a la capa de aplicación de Kiteworks —ya sea por credenciales comprometidas, sesión de soporte u orden legal dirigida al proveedor de software— no se traduce en capacidad de descifrado. Las claves están en hardware controlado por el cliente al que el proveedor no puede acceder.
Certificaciones para Infraestructura Gestionada por el Proveedor
Para organizaciones que utilizan implementaciones en la nube gestionadas por Kiteworks, la garantía de seguridad física se basa en el portafolio de certificaciones que cubre la infraestructura de centros de datos de Kiteworks. La atestación BSI C5 Tipo 2 proporciona la evidencia más detallada de seguridad física para organizaciones EMEA, con un periodo de evaluación que cubre la efectividad operativa y no solo el diseño. La certificación ISO 27001 cubre el sistema de gestión de seguridad de la información, incluidos los controles físicos. El estado FedRAMP High In Process indica que toda la familia de controles PE en el nivel High está bajo evaluación, representando el conjunto de controles de seguridad física más riguroso del gobierno de EE. UU. para servicios en la nube. La clasificación IRAP PROTECTED proporciona una garantía equivalente para cargas de trabajo gubernamentales australianas.
Estas certificaciones son evidencia acumulada de controles de seguridad física en instalaciones gestionadas por el proveedor, evaluadas de forma independiente por terceros cualificados. Son el mecanismo de garantía adecuado para organizaciones que han determinado que la infraestructura gestionada por el proveedor es el modelo de implementación correcto y necesitan verificación de terceros de que la seguridad física cumple los requisitos regulatorios y contractuales.
Conclusión
La seguridad física es la capa de la soberanía de los datos que no puede abstraerse mediante controles de software o certificaciones de cumplimiento. La cuestión de si el hardware que almacena datos confidenciales está en una instalación controlada por el cliente —y si las claves criptográficas que los protegen están en módulos de hardware gestionados por el cliente— tiene una respuesta operativa directa que depende del modelo de implementación, no del portafolio de certificaciones del proveedor. Para organizaciones donde la soberanía física es un requisito real y no solo un trámite de cumplimiento, el modelo de implementación en las instalaciones con integración HSM gestionada por el cliente ofrece la postura más robusta y directamente verificable disponible hoy en el uso compartido de archivos empresariales.
La tendencia regulatoria en EMEA, el sector federal de EE. UU. y Australia apunta a requisitos de seguridad física más explícitos, no menos —las disposiciones de servicios esenciales de NIS 2, la evolución de BSI C5 y la continuidad de la rigurosidad de FedRAMP en controles PE van en la misma dirección. Las organizaciones que establecen ahora controles de seguridad física claros y verificables por primera parte —mediante decisiones de modelo de implementación, arquitectura HSM y procedimientos de destrucción de medios— están construyendo la base de evidencia que las inspecciones supervisoras cada vez más esperarán ver documentada, no solo atestiguada.
Preguntas Frecuentes
¿Cuál es la diferencia entre FIPS 140-2 y FIPS 140-3 para la validación de HSM?
FIPS 140-3 es el estándar activo actual, que reemplaza a FIPS 140-2. Está alineado con ISO/IEC 19790 y añade requisitos más estrictos para la seguridad de software y firmware, mecanismos de autenticación y seguridad física en niveles superiores. Los módulos validados bajo FIPS 140-2 siguen siendo reconocidos, pero las nuevas validaciones utilizan FIPS 140-3. Para compras, verifica que los HSM estén actualmente listados en el CMVP (Cryptographic Module Validation Program) de NIST, ya sea en la lista activa o histórica.
¿Cómo protege Hold Your Own Key (HYOK) frente a órdenes legales gubernamentales dirigidas al proveedor de software?
HYOK separa la custodia de las claves de la custodia de la aplicación. Una orden legal que obligue al proveedor de software a dar acceso a los datos —o a la funcionalidad de la aplicación— no se extiende al hardware que el cliente opera en sus propias instalaciones. El proveedor no puede entregar claves que no posee. HYOK no protege frente a órdenes legales dirigidas al cliente, pero impide que una orden dirigida al proveedor eluda el cifrado controlado por el cliente.
¿Qué certificaciones cubren la seguridad física en las implementaciones en la nube de Kiteworks?
La atestación BSI C5 Tipo 2, la certificación ISO 27001, la evaluación FedRAMP High In Process de la familia de controles PE y la clasificación IRAP PROTECTED incluyen componentes de evaluación de seguridad física que cubren la infraestructura gestionada por Kiteworks. BSI C5 Tipo 2 ofrece la evidencia más granular de seguridad física para contextos EMEA, con evaluación de efectividad operativa durante un periodo, no solo revisión de diseño puntual.
¿Quién es responsable de la destrucción de medios de almacenamiento en una implementación de Kiteworks en las instalaciones?
El cliente es totalmente responsable. Las implementaciones en las instalaciones funcionan en hardware propiedad del cliente, por lo que el cliente controla todos los aspectos del ciclo de vida de los medios, incluida la sanitización y destrucción. El cliente elige el método de destrucción (según NIST SP 800-88 o equivalente), ejecuta la destrucción dentro de su propio perímetro de seguridad y genera la documentación de eliminación —sin intervención, coordinación ni cadena de custodia del proveedor.
¿Qué es una ceremonia de claves y por qué se requiere para implementaciones HSM?
Una ceremonia de claves es un procedimiento documentado y controlado para generar y cargar claves criptográficas en un HSM bajo controles que impiden que una sola persona tenga acceso total al material de la clave. Requerida por NIST SP 800-57 y PCI DSS, establece el ancla de confianza procedimental para todas las operaciones criptográficas posteriores. Sin una ceremonia formal, las propiedades de seguridad del hardware HSM no pueden realizarse plenamente, independientemente de su nivel de validación FIPS.