sicurezza del sito basata sui ruoli - la condizione dei missili nucleari

7

Quindi sono in procinto di lavorare su parte del nostro nuovo sistema di sicurezza del sito basato sui ruoli e sono giunto alla condizione di "missile nucleare".

Il sistema si basa sull'idea di raggruppamento, con la possibilità per gli utenti di essere implicati in gruppi basati su gruppi correnti, in questo modo:

  • Tom è un maestro di torta principale

  • inserendolo nel gruppo Cake Maker, implica anche che si trovi nel gruppo dei fornai, quindi non ha bisogno di essere fisicamente inserito in quel gruppo.

  • Implicando di essere nel gruppo dei fornai, potrebbe essere inserito in qualsiasi altro sottogruppo di cottura.

  • Se Tom diventasse amministratore delegato della sua panetteria, sarebbe portato fuori dal gruppo di cottura e inserito nel gruppo CEO, il che implica che ha accesso a tutti i gruppi (cottura, pasticceria, ecc.). / p>

La condizione del "missile nucleare" è quindi: Io sono uno sviluppatore web, quindi ho bisogno di avere accesso a tutti i gruppi in modo da poter verificare varie condizioni e bug che possono verificarsi durante il ciclo di vita. Ma potrebbero anche esserci dati sensibili che non dovrei guardare, questo potrebbe appartenere al gruppo Risorse umane o al gruppo Finanza. Implementando il sistema di missili nucleari significherebbe per me accedere alle pagine in diretta, qualcuno del gruppo Risorse umane o gruppo di finanze dovrebbe fornire la propria password contemporaneamente al mio .. 2 campi password su una pagina.

Questa è una soluzione piuttosto divertente, ma non sono affatto convinto del tutto pratico. In che modo generalmente proteggete gli sviluppatori di sistemi non autorizzati da dati sensibili? hai hash qualcosa di sensibile e solo rivelare se la persona è effettivamente un membro del gruppo che appartiene ai dati.

ti interessa anche?

    
posta Jarede 24.01.2012 - 10:38
fonte

2 risposte

5

Una soluzione simile viene utilizzata per i casi di emergenza, spesso definita una soluzione "a vetro di rottura" e in genere richiede un account a livello di amministratore separato, con una password divisa in due metà e la documentazione su queste password conservata in cassastrong (di solito IT e una cassastrong per dirigenti)

Non penso che il tuo caso d'uso sia considerato di emergenza, dato che potrebbe accadere abbastanza spesso, quindi quello che trovi è molto più comune sono i controlli implementati a livello di personale, tra cui:

  • vetting più severo
  • registrazione di tutto ciò che gli utenti privilegiati fanno

Ciò consente al lavoro di continuare normalmente senza essere influenzato da controlli di sicurezza intrusivi, proteggendo allo stesso tempo l'azienda.

Ovviamente quanto sopra vale per gli sviluppatori che hanno accesso al live. Per gli sviluppatori che eseguono attività BAU, il metodo preferito è che abbiano solo dati sterilizzati. Prenderanno il database dell'account cliente, genereranno nomi e indirizzi sostitutivi e li useranno negli ambienti Dev, UAT, OAT e Pre-Prod in modo tale che gli sviluppatori non abbiano accesso all'ambiente live.

Negli ultimi 16 anni probabilmente posso contare il numero di organizzazioni che lo fanno sulle dita di una mano, quindi torna su e usa il controllo e la registrazione. Ci dispiace, ma è così che tende a funzionare.

    
risposta data 24.01.2012 - 13:04
fonte
3

La soluzione che ho incontrato più consisteva in un singolo strato di gruppi e, in quanto tale, nessuna ereditarietà di gruppo. Il problema sorge quando una persona appartiene a due o più gruppi con diritti in conflitto. Quindi hai la possibilità di scegliere tra andata e ritorno (esempio: accesso concesso & accesso negato) o viceversa.

Penso che sia il modo più semplice perché altrimenti potresti incontrare problemi con l'ereditarietà di gruppo (e sospetto che tu debba fornire un'interfaccia complessa per i gruppi di utenti mamaging, giusto?)

Ora, una cosa mi ha colpito nella tua domanda:

But there also might be sensitive data that I shouldn't be looking at, this might belong to the HR group or the Finance group

Indipendentemente dalla tua soluzione, dovresti lavorare su dati resi anonimi, non su dati reali. Se stai lavorando su una copia esatta di un database di produzione, il primo passo per te o (se sei fortunato ad averne uno) per l'amministratore del tuo database per fornirti una copia anonima del database. I numeri possono essere randomizzati, anche i nomi (ci sono database dei nomi disponibili online gratuitamente), ecc.

In questo modo, non devi preoccuparti di quale gruppo sei, potresti trovarti in tutti i possibili gruppi o in un supergruppo che eredita da tutti i gruppi, puoi testare in sicurezza la tua applicazione web sapendo che non sarà possibile imparare quanto viene pagato il tuo capo; -)

    
risposta data 24.01.2012 - 10:53
fonte

Leggi altre domande sui tag