Sellado de Tiempo (TSA)
Para qué sirve esta pantalla
Un sello de tiempo cualificado es un token que una autoridad externa de sellado de tiempo RFC 3161 emite sobre una firma, de modo que más adelante alguien que no estuvo presente pueda probar cuándo se hizo esa firma. Esta pantalla contiene las dos mitades de ese acuerdo: la conexión con la autoridad — siete valores de configuración — y las anclas de confianza, los certificados de CA contra los que la plataforma valida los tokens devueltos, que son registros en una tabla propia y no valores.
Dentro de la superficie, Ajustes y Anclas de confianza son dos pestañas. Alrededor de ellas la superficie lleva las suyas: Configuración, Por tenant y Actividad para quien pueda leer la pista de auditoría.
Esta pantalla no decide si se sellan las firmas. Eso es una política, que se fija en Políticas de Plataforma y se afina por tenant; aquí haces que el sellado sea posible.
Qué debe existir antes
- El permiso de lectura de la configuración de plataforma, para los valores de conexión, y el permiso de lectura de las anclas de confianza, para la lista de anclas. Los roles integrados de administrador, auditor y visor de la plataforma tienen ambos.
- El permiso de escritura de la configuración de plataforma para cambiar un valor de conexión, y el tercer permiso, el de valores peligrosos, para el único valor que relaja una salvaguarda. Solo los tiene el superadministrador de plataforma.
- El permiso de gestión de anclas de confianza, para subir, retirar o eliminar una. Lo tiene el administrador; los roles de auditor y visor tienen solo la lectura.
- Para la pestaña Por tenant, el permiso de escritura de las anulaciones de conexión de sellado por tenant. Es un permiso propio, no el de escritura de la configuración de plataforma: lo tienen los roles integrados de administrador y operador de la plataforma, así que un operador gestiona la anulación de un tenant mientras todos los valores de conexión de Configuración son de solo lectura para él. La pestaña lee la anulación de un tenant solo con el permiso de lectura correspondiente, que tienen los roles de administrador, operador, auditor y visor; auditor y visor solo tienen esa lectura.
- Una autoridad a la que apuntar. El extremo debe ser una URL
https://absoluta a un anfitrión público enrutable: la plataforma rechazahttp, las direcciones de bucle local, privadas y de enlace local, y los nombres de anfitrión internos en el momento de guardar. - Al menos un ancla de confianza antes de que el sellado sirva de algo, porque un token que la plataforma no puede validar contra un ancla no es evidencia.
Decisiones que tomas aquí
La conexión
La conexión la forman siete valores. Habilitado es el interruptor principal y está desactivado de forma predeterminada. La URL del extremo direcciona la autoridad. El OID de política se copia literalmente en cada solicitud y se deja vacío salvo que la autoridad documente uno que sus suscriptores deban pedir: un OID que no acepte hace que responda con un estado no concedido y la operación de firma falla en lugar de caer hacia una firma sin sello.
El algoritmo de resumen es el que se usa para construir la huella de cada solicitud: SHA-256 (el predeterminado), SHA-384 o SHA-512. Elige uno que la autoridad admita: rechaza una solicitud construida con otro, y la siguiente firma requerida falla. Cuando se exige resistencia a ataques asistidos por computación cuántica, los mecanismos acordados del ECCG recomiendan un resumen de al menos 384 bits. Un cambio se aplica al siguiente sello; las firmas ya selladas conservan el suyo, y la auditoría registra el algoritmo que usó cada solicitud.
El tiempo de espera es un único plazo sobre todo el intercambio con la autoridad — la conexión, la negociación y la respuesta completa, por lento que llegue — y acota también la resolución del nombre de la autoridad. Acepta de 100 ms a 60 s, con 5 s de forma predeterminada.
Una respuesta de más de 1 MiB se rechaza sea cual sea el tiempo de espera; una real ocupa unos pocos kilobytes. La credencial de cliente autentica ante la autoridad cuando esta lo exige; es de solo escritura, la sella la plataforma y nunca se devuelve — y nada la valida contra la autoridad, así que guardarla no prueba que sea correcta.
El séptimo es el clasificado como peligroso: si se admite un token de sello cuyo estado de revocación del certificado no se pudo determinar. Está desactivado de forma predeterminada, lo que rechaza ese token y hace fallar la firma de forma cerrada. Activarlo registra como fiable un token emitido bajo un certificado que puede estar ya revocado, y la pista de auditoría no conserva ninguna marca de esa duda.
Activar el sellado, y el rechazo que protege a los tenants
Activa Habilitado solo cuando el extremo esté configurado y se haya comprobado que responde. En cuanto el modo de sellado de un tenant es requerido, toda firma, refirma y firma-y-cifrado de ese tenant falla de forma cerrada mientras no se pueda alcanzar la autoridad; así que habilitarlo contra una autoridad inalcanzable convierte una superficie de firma que funcionaba en una interrupción para esos tenants.
El sentido contrario está protegido. Desactivar Habilitado, o restablecer un valor a algo que deje la conexión sin capacidad de sellar, se rechaza mientras eso dejaría a un tenant, o al valor predeterminado del despliegue, obligado a sellar con ella. El rechazo indica a cuántos tenants afecta, y puedes continuar de todos modos confirmando con ese recuento. Los cambios en la conexión se aplican sin reiniciar.
Anclas de confianza
La pestaña Anclas de confianza lista cada ancla con su estado, quién la subió y cuándo, y una marca de aviso en un ancla activa a menos de 30 días de vencer. Añadir una son deliberadamente dos pasos: pegas o subes un certificado PEM o DER, o un archivo PKCS#12 o JKS con una contraseña opcional de solo escritura, la plataforma lo analiza sin efectos secundarios y eres tú quien elige cuáles de los certificados admisibles se confirman. Nada se confirma en silencio, y un certificado cuya huella ya esté almacenada se rechaza como duplicado descartando la subida entera.
Puede haber más de un ancla activa a la vez, y así es como se rota una CA: solapa el ancla entrante con la saliente para que la validación no tenga ningún hueco. Retirar saca un ancla de la validación y conserva la fila; se aplica el mismo rechazo anterior cuando retirarla dejaría a un tenant, o al valor predeterminado del despliegue, obligado a sellar sin nada contra lo que validar. Eliminar solo se ofrece sobre un ancla ya retirada. El historial del ancla no está en esta pestaña: está en la pestaña Actividad de la superficie, que sigue respondiendo por un ancla que ya se eliminó.
Por tenant
La pestaña Por tenant reemplaza la conexión entera para un tenant. Eliges el tenant en un selector, sin acceder a él. Un tenant sin anulación hereda la conexión del despliegue y el panel lo indica; darle una propia despliega el formulario completo de conexión, y revertir lo devuelve a la conexión del despliegue. Aquí la credencial también es de solo escritura: una existente se muestra como sin cambios y nunca se lee de vuelta, y dejarla en blanco es la forma de configurar una autoridad anónima. La conexión se envía entera de una vez, no campo por campo.
Los controles de la pestaña dependen del permiso de anulación por tenant indicado arriba, no del de escritura de la configuración de plataforma.
Cómo se relaciona con otras pantallas
Si un tenant debe, puede o no puede sellar se decide en las pantallas de políticas, no aquí — el modo del despliegue es DISABLED, OPTIONAL o REQUIRED, y solo con OPTIONAL elige cada tenant:
El resto del grupo, y el mapa que dibuja el estado de esta superficie junto al de las demás conexiones:
Dónde leer más
Estas páginas están en inglés: