Ciclo de Vida de Claves
Para qué sirve esta pantalla
Este es el mismo editor de ciclo de vida de claves que usa un administrador de tenant, abierto desde Políticas de Plataforma: dos cuadrículas de celdas ALLOW y DENY, una fila por operación y una columna por estado de la clave, para el identificador de la clave y para sus versiones de material. Qué significan las cuadrículas, cómo se lee cada celda frente al estado de una clave y qué contienen DEFAULT y STRICT se describe en la página del tenant y no se repite aquí:
El editor se abre en dos formas desde Políticas de Plataforma. Open editor en la tarjeta Key Lifecycle abre la política de ciclo de vida del despliegue, el techo contra el que se comprueba toda política de tenant. La celda Lifecycle de la fila de un tenant abre la política propia de ese tenant, con el nombre del tenant en la ruta de navegación. Esta página trata de lo que difiere en cada una.
Qué debe existir antes
Ambas formas se ofrecen solo en contexto de sistema; abrir cualquiera de ellas mientras estás dentro de un tenant te devuelve al panel de ese tenant.
- La forma de despliegue necesita el permiso de lectura de la política de ciclo de vida del despliegue para mostrar las cuadrículas, el permiso de escritura para DEFAULT, STRICT, las celdas y Save policy, y el permiso de eliminación para Reset to DEFAULT. Sin el permiso de lectura la pantalla indica que no tienes permiso para ver la política de ciclo de vida del despliegue.
- La forma de tenant usa los permisos de ciclo de vida del tenant, lectura, escritura y eliminación, exactamente como la propia pantalla del tenant. Un tenant que no se puede cargar se reporta como Could not load the lifecycle policy for this tenant, con una forma de volver.
Decisiones que tomas aquí
Fijar el techo
La política del despliegue no se comprueba contra nada: Save policy almacena ambas cuadrículas tal como están. Su resumen dice que un tenant solo puede poner ALLOW en una operación donde esta política también lo permite, y eso se aplica cuando un tenant guarda: una celda del tenant puesta en ALLOW donde esta política dice DENY, o donde esta política no tiene celda alguna, se rechaza con la lista de celdas infractoras. Un tenant siempre puede restringir.
Restringir una celda aquí no acota a un tenant que ya lleva una política propia. El servicio criptográfico aplica la política almacenada del tenant tal como está, y esta política solo donde el tenant no tiene ninguna; un tenant cuya política almacenada ahora supera el techo sigue operando bajo ella, y solo se le rechaza en su siguiente guardado.
Un cambio aquí se publica al servicio criptográfico antes de que el servidor responda, y el servicio criptográfico descarta todas las políticas que conserva en memoria al recibirlo, así que los tenants que heredan se evalúan con el nuevo techo desde su siguiente operación.
Un techo con menos filas que las plantillas
El editor muestra solo las filas que tiene la política almacenada, y una fila que el techo no declara es DENY en todas las columnas. Así que si el techo almacenado lleva menos filas que las plantillas integradas, todo tenant que pulse DEFAULT o STRICT es rechazado: la plantilla pide ALLOW en una fila que el techo no responde en absoluto.
Pulsa DEFAULT aquí, lo que carga la plantilla completa en las cuadrículas, y luego Save policy — o pulsa Reset to DEFAULT, que almacena la plantilla completa en un solo paso. Guardar un cambio de celda sobre una cuadrícula a la que le faltan filas no las añade.
Una instalación nueva no está en ese estado. La plataforma almacena la plantilla DEFAULT integrada como techo cuando un despliegue no tiene ninguna, así que una instalación recién creada arranca con todas las filas que las plantillas necesitan y sus tenants pueden aplicar DEFAULT y STRICT de inmediato.
Restablecer la política del despliegue
Reset to DEFAULT almacena la plantilla integrada DEFAULT como política del despliegue, en lugar de lo que estuviera almacenado antes, y el servidor responde con la política almacenada. El editor muestra las cuadrículas de DEFAULT de inmediato, la tarjeta de Políticas de Plataforma lee DEFAULT, y los tenants que heredan se evalúan con ella desde su siguiente operación.
Como hay una política almacenada, un guardado de tenant después de un restablecimiento se comprueba contra DEFAULT como cualquier otro guardado; nunca se rechaza por falta de techo. Deployment ceiling missing solo se responde donde no existe ninguna política de ciclo de vida del despliegue — una avería que conviene reportar, porque la plataforma almacena la plantilla DEFAULT como techo siempre que un despliegue no tiene ninguna.
Editar la política de un tenant
Abierto desde la tabla, el editor escribe la política propia de ese tenant con los permisos del tenant y las mismas reglas que la pantalla del tenant: un guardado se comprueba contra el techo, y las celdas rechazadas se listan como alias · DECRYPT on RETIRED. Reset to DEFAULT aquí elimina la política del tenant, de modo que el tenant sigue la política del despliegue, sea cual sea. La insignia nombra la política en vigor; no dice si el tenant hereda.
Cuándo surte efecto una política guardada
Un guardado del despliegue se escribe en la caché de políticas y se publica una invalidación en cuanto se confirma la transacción; un guardado de tenant expulsa la copia de ese tenant en el servicio criptográfico y se aplica en su siguiente operación. Al volver, la tarjeta Key Lifecycle puede mostrar el nombre de la plantilla anterior hasta cinco minutos, y la celda Lifecycle de un tenant hasta un minuto.
Cómo se relaciona con otras pantallas
Ambas formas se abren desde Políticas de Plataforma y vuelven a ella:
Un administrador de tenant edita la misma política de tenant en la propia pantalla del tenant, donde el techo que fijas aquí es contra lo que se mide un guardado rechazado:
Dónde leer más
Estas páginas están en inglés: