Gestione della coppia di chiavi pubblica-privata su un ecosistema Windows

3

Ho pensato a come progettare un'infrastruttura per una delle nostre applicazioni aziendali con il seguente requisito:

  • I dati scritti da alcuni utenti possono essere letti solo da quell'utente e dal suo superiore e da una terza persona ancora da definire

Sto pensando di utilizzare una sorta di algoritmo asimmetrico, come RSA per la crittografia dei dati.

Possiamo generare una coppia di chiavi pubblica-privata per ciascun utente e archiviare la chiave pubblica di ciascuno in modo aperto su un database, ma come dovremmo gestire la chiave privata?

Se lasciamo che gli utenti gestiscano la loro chiave privata un giorno avremo un grosso mal di testa se uno di loro perde la chiave.

Se la chiave privata diventa pubblica in qualche modo, anche i dati diventerebbero pubblici, rendendo l'architettura non valida.

La nostra infrastruttura è strongmente orientata alla tecnologia Microsoft: tutte le applicazioni sono ASP.Net MVC3, la nostra dabatase è SQL Server 2005 e utilizziamo Active Directory per l'autenticazione dell'utente e i dati di base, come il numero di e-mail / telefono.

Come vorresti che architetti una soluzione per risolvere questo problema?

Bottom-line: questa non è un'applicazione bancaria o finanziaria, è una sorta di sistema di feedback personale a 360 gradi.

EDIT: Aggiunta di ulteriori requisiti, sperando di renderlo più chiaro:

  • Questo database sarà nell'ambiente di produzione, in cui gli sviluppatori non hanno accesso;
  • Una volta ripristinato il database, gli sviluppatori non dovrebbero essere in grado di recuperare i dati;
  • Il DBA non dovrebbe essere in grado di visualizzare i dati SELEZIONANDO le righe sulle tabelle;

EDIT 2: informazioni di Bounty. Bounty è andato alla risposta con più upvotes, anche se la mia opinione personale è che nessuna delle risposte fornite ha risolto correttamente la domanda. Per questo motivo, concedo la taglia ma non contrassegno la risposta come corretta.

    
posta Machado 02.08.2012 - 22:07
fonte

4 risposte

1

In realtà mi raccomando di non utilizzare uno schema di tipo di recupero chiavi come suggerisci. In generale, è complicato, difficile da mantenere e ci sono modi più semplici per raggiungere i tuoi obiettivi.

Schneier ha alcuni vecchi articoli sul recupero delle chiavi, con alcuni collegamenti incorporati a informazioni aggiuntive. Non discutono direttamente del tuo scenario, ma c'è un strong grado di pertinenza.
Ripristino delle chiavi
Key Recovery # 2

Invece, raccomanderei l'uso di un modello di accesso gerarchico.

Per semplicità, presumo che i commenti della recensione siano archiviati in una sorta di struttura del DB SQL.

Ogni voce verrà contrassegnata con due identificatori. Il primo è l'ID DB del dipendente, il secondo è un ID di gruppo. I gruppi saranno definiti in base ai reparti.

La tabella di accesso degli utenti terrà traccia dell'ID del dipendente ID (potrebbe anche essere la chiave primaria), quale ID di dipartimento il dipendente contribuisce e quale ID di reparto può leggere il dipendente.
L'ID del reparto "contribuisce a" sarà il reparto a cui appartiene il dipendente. Il campo ID reparto "in grado di leggere da" può essere impostato solo se l'utente è un supervisore o è la "terza parte da designare in un secondo momento".

Seleziona contro le voci di revisione 360 possono quindi essere unite contro la tabella di accesso degli utenti.

Quando i supervisori cambiano, tutto ciò che deve essere aggiornato è l'ID di reparto da cui possono leggere. Dato il tuo ambiente MS, dovrebbe essere abbastanza facile impostare un'attività pianificata per sincronizzare le informazioni di AD con l'accesso nella tabella di accesso degli utenti.

Un avvertimento : vale la pena notare che gli amministratori di database avranno accesso a tutte le informazioni. Metti un po 'di auditing / tracking per scoraggiare la loro curiosità. Avresti comunque un problema simile con uno schema di chiavi di crittografia, anche se potrebbe essere stata una persona diversa con quella capacità di aggirare le impostazioni di sicurezza.

Alcune letture aggiuntive sulla protezione del DB
Troverai i seguenti link di interesse per la tua particolare configurazione. Ho selezionato MS SQL 2005, ma le informazioni per altre versioni possono essere modificate con il menu a discesa nella parte superiore delle pagine.
Considerazioni sulla sicurezza del DB MSDN
Crittografia di una colonna
Backup / Ripristino sicurezza

Penso che sia importante tenere a mente il livello generale di sensibilità / sicurezza dell'applicazione. Hai detto che questo era per un feedback in stile 360, che considero necessario proteggere per prevenire imbarazzo / promuovere comunicazioni aperte. Una violazione dei dati non avrebbe effetti catastrofici sulla società.

Dato il valore relativamente basso e temporale dei dati, non dovresti avere troppi file di backup seduti intorno. Se le persone hanno paura che quello che hanno detto 3 anni fa tornerà a perseguitarli, aggireranno il processo di feedback e saranno meno che imminenti nelle loro recensioni.

Se hai paura di qualche lupo solitario nell'organizzazione che aprirà il feedback e poi diffonderà i bocconcini più succosi, allora temo che tu abbia problemi più grandi che non saranno risolti con la tecnologia. Come gestirlo non è OT per P.SE dato che la tecnologia generalmente non può risolvere i problemi del personale. Mettere in atto alcune restrizioni ragionevoli e far notare al CEO che violando volontariamente tali restrizioni è motivo di risoluzione.

    
risposta data 07.08.2012 - 22:09
fonte
0

Vorrei caricare le chiavi in una dll offuscata e utilizzare le informazioni sulla directory attiva per autenticare la chiave dell'utente. se fatto correttamente, l'utente non conoscerà mai la sua chiave e non potrà essere decompilata per scoprire le chiavi.

    
risposta data 07.08.2012 - 14:30
fonte
0

Solo un pensiero, potresti trovarti impantanato nel HOW e dimenticare il WHAT . Quello che vuoi è mantenere le recensioni anonime a chiunque tranne l'utente, la persona che lo supervisiona e un'altra persona (possibilmente un revisore dei conti di terze parti). Manterrei la chiave pubblica / privata come una opzione, ma non l'unica opzione. Sembra che tu abbia bisogno di creare una situazione grafica in cui le relazioni garantiscano determinati privilegi. Ho cercato di utilizzare qualcosa come Neo4j per un grafico sociale interno orientato al business. Potresti avere più fortuna nell'usare qualcosa di simile al tuo tradizionale database relazionale. Neo4j può essere interrogato da http / https (quindi puoi farlo da MVC). Sono un po 'nuovo a giocare con i database di grafici, ma sembrano promettenti per fare un sacco di cose di questo tipo.

    
risposta data 09.08.2012 - 00:17
fonte
-2

Abbiamo ciò che sembra un sistema simile. Abbiamo dovuto creare una tabella con nomi di login che corrispondessero all'Active Directory che specifica chi è chi è superiore. Se stai usando MVC3 con Windows Authenication dovresti essere in grado di vedere chi sta cercando chi. Ecco un esempio:

link

Una cosa da tenere a mente è che le persone vorranno fornire informazioni riservate sui superiori. Permetti di specificare il feedback 'solo per le risorse umane'.

    
risposta data 08.08.2012 - 18:58
fonte

Leggi altre domande sui tag