REVIEWITDocumentación
ConceptoAl día · verificada el 30 agosto 2026

SEAL — el perímetro criptográfico de confianza

Traducción automática, aún no revisadaEsta página fue traducida por un modelo a partir de la versión francesa, que es la que da fe. Leer la versión francesa.

01El perímetro criptográfico de confianza #sec_af09b142

SEAL es el servicio que concentra las operaciones criptográficas sensibles de REVIEWIT: conservar las referencias de secretos, derivar valores, firmar sellos, gobernar las generaciones de claves y autorizar su destrucción. Los módulos de negocio le solicitan una operación; no obtienen la materia secreta que la hace posible.

Esta frontera evita que cada aplicación invente su propio almacenamiento de claves, sus formatos de recibos y sus reglas de rotación. El cofre subyacente protege los secretos; SEAL añade la doctrina REVIEWIT: aislamiento por tenant, capacidades autorizadas, ciclo de vida, prueba de operación y estado de autoridad.

SEAL no decide sobre una certificación, un derecho o una duración de retención. Aplica una operación criptográfica previamente autorizada y devuelve un resultado o un recibo verificable.

02La clave no sale, el resultado sí #sec_3b5f0896

Un consumidor manipula una referencia estable, nunca un secreto en claro. Para firmar un encabezado de Audit Trail, SEAL hace usar la clave en su perímetro y devuelve la firma. Para el sign-off, deriva los azares necesarios para las pruebas de inclusión sin devolver el secreto de atestación.

Esta regla reduce fuertemente las vías de exposición: ninguna clave privada viaja en la memoria de una aplicación de negocio, en sus parámetros o en sus registros. También facilita el cambio de proveedor de cofre, ya que los consumidores dependen de una capacidad y no de una API propietaria.

Las operaciones están aisladas por uso. Una clave de sello de auditoría, una clave de firma documental y un secreto de derivación de atestación pertenecen a dominios diferentes. Reutilizar la misma clave porque las tres operaciones «firman algo» mezclaría responsabilidades y duraciones incompatibles.

03Generaciones, rotación y destrucción #sec_52bf3522

Un secreto posee una clase y generaciones. La política de clase decide si una rotación está permitida, a qué cadencia y con qué validaciones.

Algunos valores son voluntariamente no rotativos. El secreto que ha participado en un compromiso de atestación debe permanecer estable: reemplazarlo haría imposibles las pruebas futuras. Una nueva generación puede servir para las siguientes atestaciones, pero la antigua permanece disponible mientras una atestación viva dependa de ella.

La destrucción sigue la regla inversa: debe ser fácil de solicitar cuando es legítima, difícil de anular e imposible mientras subsista una dependencia protegida. El estado de autoridad impide un retorno silencioso a una generación revocada o destruida.

SEAL distingue así la duración de negocio y el ciclo criptográfico. La retención puede hacer que una generación sea elegible para la destrucción; no la destruye directamente ni elude los controles de gobernanza.

04Autorizar la operación, no solo el llamante #sec_6d9b6b65

El control recae sobre la identidad del solicitante, el tenant, la capacidad solicitada y el estado actual de la autoridad. Una aplicación autorizada a derivar un valor no recibe automáticamente el derecho a firmar, hacer rotar o destruir una clave.

Los actos humanos más sensibles pueden requerir una elevación TrustGate y una doble validación. Las operaciones de servicio repetitivas siguen un régimen adaptado a su naturaleza, con identidades de máquinas, capacidades mínimas y recibos. Una operación no mutante no se trata artificialmente como una operación de gobernanza, pero sigue siendo limitada y observable.

Los roles de producto no son suficientes para administrar la cuenta de autoridad. La separación de poderes se extiende a las políticas de IAM y a la cadena de explotación: la persona capaz de alterar el almacenamiento de pruebas no debe, por sí sola, poder producir un sello que enmascare esa alteración.

05Recibos, recuperación y estado degradado #sec_40421e1a

Las operaciones que modifican el estado son idempotentes. Una solicitud «obtener o crear» con la misma identidad lógica encuentra la misma generación; un reinicio no fabrica dos secretos concurrentes. Los recibos permiten al consumidor y a la auditoría vincular la solicitud, la decisión de autoridad y el resultado sin exponer el valor secreto.

La auditoría permanece proporcionada. Una derivación que afecta a miles de elementos se rastrea por lote o por tramo, no por valor elemental. El sistema prueba que una construcción ha tenido lugar sin inundar la pista.

En situación degradada, SEAL falla de manera cerrada para una operación criptográfica que no puede garantizar. El módulo llamante puede conservar un estado de recuperación, pero nunca debe presentar como sellado o firmado lo que no lo está. Las operaciones de lectura o servicio ya explícitamente autorizadas no se convierten, por ello, en puertas de eludir la gobernanza.

06En resumen #sec_f94675c2

SEAL proporciona a REVIEWIT una única frontera para proteger, autorizar y probar sus operaciones criptográficas. Las aplicaciones utilizan capacidades, no claves; las generaciones siguen sus dependencias; las operaciones sensibles respetan la separación de poderes; y ningún resultado se presenta como sellado cuando la autoridad no ha podido garantizarlo.

Esc
↑↓ navegar↵ abrirVer todos los resultados →