DPAPI funziona in realtà con 2 semplici chiamate di funzione: CryptProtectData e CryptUnprotectData .
Per farla breve, CryptProtectData ha due modalità di funzionamento: Utente o sistema. Se si utilizza la modalità utente (impostazione predefinita), i dati vengono crittografati utilizzando i dati di accesso utente correnti. Significa che puoi solo chiamare CryptUnprotectData con successo sugli stessi dati dallo stesso contesto utente di quello da cui hai chiamato CryptProtectData. (in modalità "sistema", qualsiasi processo in esecuzione su quella stessa macchina può decifrare i dati ma non da un altro sistema: non va bene quando i dati sono in un database).
Ciò significa che, se inizialmente hai crittografato i tuoi dati nel database del server SQL utilizzando un account utente AD specifico, sei permanentemente limitato a utilizzare questo utente per accedervi. (Questo potrebbe essere considerato un difetto o una caratteristica a seconda dell'applicazione).
Che cosa significa per te? Bene, a meno che tu non possa cambiare il modo in cui funziona l'applicazione o sei disposto a reimpostare completamente i dati crittografati, non puoi modificare l'identità utilizzata dal processo di applicazione web.
La buona notizia, tuttavia, è che questo non deve essere insicuro: se la tua applicazione Web è un'app ASP.NET e utilizza le stringhe di connessione memorizzate nel file web.config in un modo standard, puoi proteggerle usando anche DAPI ma questa volta con un delegato al sistema. Microsoft ha una spiegazione abbastanza lunga su come farlo .
Infine, c'è sempre il solito modo di morire con questo tipo di problemi: contatta gli sviluppatori dell'applicazione: sono quelli che possono dirti esattamente cosa è supportato e come. Se necessario, sono quelli che possono anche apportare le modifiche necessarie al loro sistema per raggiungere gli obiettivi di sicurezza che hai impostato.
Modifica: C'è un ulteriore elemento da tenere in considerazione nel tuo caso: quando usi DAPI, la chiave principale utilizzata per la crittografia è memorizzato nel profilo utente .
Ciò significa che, quando si utilizza un account utente virtuale (come quelli creati per l'utente durante l'esecuzione di un'app Web in AppPoolidentity ), DAPI non verrà permanentemente né ricaricato poiché non è stato creato alcun profilo effettivo e si verificherà il problema che si descrive: IISreset fa sì che l'applicazione perda la sua chiave di crittografia master perché non può persistere.
Per risolvere ciò, puoi passare a passare all'identità NetworkService per il tuo pool di applicazioni web. Perderai la segregazione dell'utente fornita dall'account virtuale ma, al di là di questo, dovrebbe funzionare allo stesso modo. Microsoft suggerisce anche di verificare la proprietà "LoadUserProfile" del pool di applicazioni Web ma dubito che cambiandolo risolverà il tuo problema da solo: prova, ma suppongo che dovrai usare anche NetworkService .