Puedo ver de dónde proviene su preocupación con respecto a la migración, sin embargo, está ligeramente equivocado.
De hecho, las migraciones de la base de datos de usuarios entre IAM y los proveedores de autenticación son habituales.
Comencemos con el mandato GDPR.
No debería haber ninguna manera para que un actor externo de amenazas acceda a los datos de sus usuarios en cualquier lado. Y, si lo hicieran, sería inútil porque su algoritmo hash no está disponible para ellos.
A pesar del hecho de que cumple con esta decisión, su equipo podría, en teoría, acceder a esta base de datos de usuarios y extraerlos en texto sin formato en cualquier momento, solo por el acceso a sus entornos y el conocimiento de las claves de cifrado.
Como tal, una migración no crea una nueva amenaza de PII infringida.
¿Cómo lograr esto?
Entonces, si su equipo o el proveedor tienen alguna forma de conocer el mecanismo de sal / hash de (a), debería poder usarlo como un mecanismo secundario en (b) y migrar la lista de usuarios cifrada (contraseñas) y todo) en la nueva solución.
Y si asumimos lo siguiente:
- Su equipo actuará con integridad
- Cualquier proveedor actuará con integridad
- No expone los datos al mundo (S3 bucket) durante la migración ...
¡Deberías ser bueno para ir!
Actuando el cambio
En un nivel alto, puedo pensar en un par de opciones, como una exportación CSV, una migración de base de datos o un script para bombear a través de su base de datos existente y actualizar cada registro en la solución actualizada.
Mi preferencia personal sería realizar una migración completa de la base de datos a la solución actualizada, luego un cambio por separado para migrar el mecanismo de hash.
Sugiero comprometer a ese proveedor para que sugiera la mejor manera de abordar esto.