El plan de migración por prioridades

Un plan de migración criptográfica empieza por una fase que no migra nada. En ella se completa el inventario, se construye o se extiende el servicio central con perfiles, se dejan los campos y los mensajes con sitio para tamaños mayores y se piden por escrito las fechas de los proveedores. Parece tiempo perdido, pero es lo que convierte cada migración posterior en un cambio de política en lugar de un proyecto aparte.

Después vienen las fases que sí cambian algoritmos, en un orden que no lo decide la comodidad sino el riesgo: primero lo que hoy se puede grabar y leer más tarde, después las firmas que deben seguir siendo creíbles muchos años, después el resto. Los simétricos y los resúmenes solo se revisan.

Lee criterios-del-comite.txt en el laboratorio.

Los criterios ordenan en dos niveles. Primero por clase: lo que se puede grabar hoy y leer después (P1) va antes que las firmas de vida larga (P2), y estas antes que el resto. Dentro de la clase, primero el mayor exceso, porque es el dato que más años quedaría expuesto. Y cuando dos iniciativas empatan, decide algo práctico: la que no espera a un tercero sin fecha puede empezar ya, y la otra puede quedarse bloqueada.

Lee cartera.txt con los criterios al lado.

Un plan no puede calendarizar lo que depende de algo sin fecha. Si una iniciativa necesita un firmware que el proveedor no ha comprometido por escrito, ponerla en la fase 1 solo traslada el problema: llegará la fecha, el firmware no estará y la fase quedará con un hueco que nadie previó. La regla del comité lo dice de forma directa: entra en una fase solo lo que tiene disponibles sus dependencias antes de que la fase empiece.

Lee borrador-fase-1.txt contra la cartera.

Con el orden claro, la capacidad decide dónde se corta. El comité fijó una regla estricta para no adelantar lo de menor prioridad: se llena la fase en orden y, en cuanto una iniciativa no cabe completa, el llenado se detiene. Lo que no puede entrar por sus dependencias no detiene nada: simplemente se salta.

Recorre la cartera en el orden de los criterios, salta lo que no cumple la regla de entrada y suma esfuerzos hasta que la siguiente no quepa.

La iniciativa bloqueada protege uno de los canales con más exceso. Dejarla fuera de la fase 1 es correcto, pero no basta con anotarla para la fase 2. El arquitecto pide la fecha por escrito, registra el riesgo con un dueño y una fecha de revisión, y estudia alternativas que no dependan de ese proveedor, como terminar las conexiones en otro equipo que ya cumpla el estándar. Lo que no hace es activar una función que se parece al estándar y no lo es.