Utilizzo di un modello di crittografia dei dati localizzato standard con un'applicazione ASP.NET MVC3

7

Mi è stato assegnato il compito di ringiovanire un'applicazione di risorse umane esistente da Access in ASP.NET. Si tratta di un'applicazione rigorosamente interna e non ho problemi a svilupparla nel nostro ambiente ASP.NET standard. Pone comunque i suoi problemi, sia dal punto di vista tecnico che etico.

L'app per le risorse umane sarà responsabile della memorizzazione dei dati retributivi dei dipendenti, per i quali non è appropriato per me, lo sviluppatore, vedere. Sono essenzialmente tre campi (fascia salariale, stipendio effettivo, commenti) e altri quattro valori, calcolati sul front-end.

Mi piacerebbe andare lungo il percorso di crittografia per crittografare questi dati: la crittografia con .NET Framework è molto facile da implementare. Potrei "tirare il mio", che come tutti sappiamo è una cattiva idea. Comunque mi stavo chiedendo se esistesse un modo più migliore di farlo. Ecco alcuni punti:

  1. Per i principianti, siamo tutti collegati allo stesso dominio.
  2. Ho sentito e letto sui certificati, possono essere utili qui? (X.509?)
  3. I dati verranno memorizzati nel nostro SQL Server locale, ovviamente i dati effettivi qui devono essere crittografati, quindi SQL Server può aiutarmi? Certificati ancora?
  4. Se un utente non ha il certificato appropriato, i dati possono essere nulli? (Non puoi vedere questo compagno!)
  5. Questo problema di crittografia non ha alcuna rilevanza per l'utilizzo del sistema tramite un modello di autorizzazioni.
posta Tom 04.08.2011 - 13:20
fonte

3 risposte

1

Questo mi sembra lo stesso problema dei dati delle carte di credito nei sistemi certificati pci. Tu come sviluppatore e in seguito gli amministratori di sistema e il personale di supporto non sono autorizzati a vedere i dati. Leggi in che modo le persone risolvono questo problema e dovrebbe risolvere il tuo.

Viene giù (una descrizione molto breve) per crittografare ogni riga con chiavi diverse e una chiave ambientale. La chiave ambientale deve essere memorizzata solo sui server delle app, la chiave per riga può essere archiviata nel database. In questo modo, qualcuno con solo accesso al database non può decrittografarlo, qualcuno con solo l'accesso ad appserver non può decrittografarlo. Assicurati che produzione e dev / test non stiano utilizzando le stesse chiavi ambientali. Quindi, un database di produzione che risale a dev o test per scopi di debug non può essere decodificato perché dev non conosce la chiave di produzione. È comunque possibile ripristinare tutti i dati nel database (backup di produzione scaricato per il test) con un singolo aggiornamento SQL (puntarlo su una singola chiave per riga e utilizzare la chiave di crittografia dello sviluppatore e impostare tutto sullo stesso valore crittografato).

Avere uno strumento per sostituire una chiave ambientale (decifrare con vecchio e crittografare con nuovi dati) se potrebbe essere compromessa (o se un dipendente che ha accesso ad esso lascia).

Ci sono molti siti con informazioni su questi standard e implementazioni pci. Leggi e otterrai sicuramente un'implementazione che potrebbe funzionare per il tuo problema.

L'algoritmo di crittografia di per sé non ha molta importanza, a patto che sia un metodo strong conosciuto

    
risposta data 03.12.2011 - 01:33
fonte
1

I tuoi commenti indicano che stai "scrivendo il sistema nella sua interezza, il che significa che ho accesso a tutto". Non puoi appoggiarti al tuo team IT qui?

  • Chiedi a un utente corrente del database di Access di crearne una copia e sostituire lo stipendio di tutti con $ 10.000 (ad esempio).
  • Sviluppa l'applicazione sulla tua workstation o su un server di sviluppo.
  • Fornisci un modello di sicurezza adeguato per garantire che gli utenti corretti (noti anche a te) possano vedere ciò che devono vedere
  • Fornire uno strumento per consentire a un utente amministrativo di inserire gli stipendi corretti
  • Ottieni l'IT per distribuire l'applicazione e abilitare qualcosa come TDE di SQL Server sulla versione di produzione

Inoltre, l'utilizzo di qualcosa come WIF o ADFS di Microsoft per fornire il single sign on è anche una buona idea dato che si indica che gli utenti si trovano nello stesso dominio.

    
risposta data 07.12.2011 - 14:17
fonte
0

Se vuoi solo nascondere i dati chiari dagli occhi - archivia le informazioni crittografate nel database e decrittali quando necessario. È possibile utilizzare l'alghoritm asimmetrico e archiviare la chiave privata nel file che può essere accessibile solo per diversi utenti. Questo approccio richiederebbe un codice aggiuntivo per cercare / ordinare / filtrare le informazioni, ma sarà sicuro.

    
risposta data 04.08.2011 - 15:22
fonte

Leggi altre domande sui tag