Riesco a vedere da dove provenga la tua preoccupazione per la migrazione, tuttavia è leggermente fuorviante.
In effetti, le migrazioni del database degli utenti tra IAM e provider di autenticazione sono comuni.
Iniziamo con il mandato GDPR.
Non ci dovrebbe essere alcun modo per qualsiasi attore di minacce esterne di accedere ai dati dei tuoi utenti su entrambi i lati. E, se lo facessero, sarebbe inutile perché il tuo algoritmo di hashing non è disponibile per loro.
Nonostante tu abbia rispettato questa decisione, il tuo team potrebbe teoricamente accedere a questo database di utenti ed estrarli in testo normale in qualsiasi momento, semplicemente in virtù dell'accesso ai tuoi ambienti e della conoscenza delle chiavi di crittografia.
Pertanto, una migrazione non crea nuove minacce per le PII violate.
Come ottenere questo?
Quindi, se il tuo team o il venditore hanno qualche modo per conoscere il meccanismo salt / hash da (a), dovresti essere in grado di usarlo come meccanismo secondario su (b) e migrare l'elenco crittografato di utenti (password e tutto) nella nuova soluzione.
E se ipotizziamo quanto segue:
- Il tuo team agirà con integrità
- Qualsiasi fornitore agirà con integrità
- Non esporre i dati al mondo (bucket S3) durante la migrazione ...
Dovresti essere bravo!
Attiva la modifica
Ad un livello elevato posso pensare a un paio di opzioni come esportazione CSV, migrazione del database o uno script per pompare il DB esistente e aggiornare ogni record nella soluzione aggiornata.
La mia preferenza personale sarebbe quella di eseguire una migrazione completa del DB alla soluzione aggiornata, quindi una modifica separata per migrare il meccanismo di hashing.
Suggerisco di coinvolgere quel venditore per il suggerimento su come avvicinarsi al meglio a questo.