Gestione delle autorizzazioni nei gruppi gerarchici

1

Attualmente sto scrivendo un'applicazione web per la nostra piccola azienda che originariamente era stata pianificata per organizzare gli appuntamenti in modo più efficiente, visualizzando la struttura dei nostri clienti e pianificando automaticamente i tour che originariamente significavano che il nostro staff ha bisogno di accedervi.

Tuttavia, poiché abbiamo quindi costruito la nostra struttura, potremmo quindi utilizzarla anche per fornire ai clienti informazioni (ad esempio, caricare file per scaricare, leggere o compilare alcuni moduli). Questo significa anche che dobbiamo dare loro login e permessi.

La nostra struttura del cliente è come visualizzata qui (semplificata):

Unproblemaèchenontuttiidipendentidialcunideinostriclientihannoindirizzie-mail(loso,incredibilenel2016manonpossocambiarloquindidevolavorarci)quindinonpossousaree-mailcomeidentificatoreunivocoperunaccesso.

Quindilamiaideaeradiconnetteregliaccessiaigruppiinquestoalberoedareadognivoceinquestoalberounidentificatoreunivoco(adesempio,ilcliente1ottieneCUST1)chedeveessereinseritoinuncampodiinputaggiuntivonelmodulodiaccessocheciconsenteutilizzarenomiutentepiùvolte(unavoltaperclienteinvecediunavoltaintotale).

Questosignificacheogniaccessoèconnessoalgruppofissoone.Iclientinondevonovedersi,quindicostruiscol'alberoperogniaccesso,quindiunmembrodi"cliente 3" vede solo il ramo 1 e il ramo 2 e tutto quanto segue.

Tuttavia, ora il vero problema: oggi mi è stato detto che ci sono casi in cui si desidera che un utente veda Office 3 e Office 2 ma non Office 1 e 4 e persino autorizzazioni differenti per ciascun gruppo avere accesso a (es .: vedere appuntamenti in ufficio 3 e vedere appuntamenti e file in ufficio 2).

Inizialmente avevo pianificato qualcosa del genere: metti gli utenti con le autorizzazioni "leggi i file" e "compila i moduli" in "ufficio 1" e il gioco è fatto.

Un'idea che ho è quella di dividere completamente quei gruppi e permessi. Ad esempio, tutti i dipendenti del cliente 1 saranno membri del cliente 1 senza autorizzazioni, indipendentemente dal ramo o dall'ufficio a cui appartengono e quindi in un secondo passaggio vengono assegnate le autorizzazioni per ciascun gruppo / nodo all'interno del cliente. Ma sono abbastanza insicuro su come gestire casi come "un nuovo ufficio viene aggiunto al ramo 1".

C'è qualche buon consiglio? Voglio dire che normalmente i gruppi sono piatti ma i gruppi gerarchici con possibili autorizzazioni differenti sembrano un po 'complicati.

    
posta Broco 23.09.2016 - 16:41
fonte

1 risposta

2

Come notato nei commenti, è probabile che si desideri il controllo degli accessi basato sui ruoli. Diventa un po 'più complicato quando i ruoli possono essere assegnati a diversi livelli di una gerarchia.

Alcune cose da considerare:

  • Utilizzare un identificativo utente interno estratto da identificatori esterni protegge dalle modifiche di indirizzo email, id utente, nome, ecc.
  • Limita i privilegi amministrativi allo stesso livello o sotto.
  • Evita di richiedere più ruoli per eseguire un'azione; qualcuno con il privilegio di pianificare un appuntamento dovrebbe ricevere appuntamenti di visualizzazione senza un ruolo aggiuntivo.
  • Le persone della tua azienda avranno bisogno di accedere a tutti i dati delle aziende; considera un ruolo di superviewer per il tuo staff.
  • L'amministrazione dei privilegi richiederà una pianificazione. Una chiara comprensione di chi può garantire quali ruoli è importante.
  • Vuoi che gli utenti siano in grado di concedere temporaneamente i loro ruoli a qualcun altro? Quali restrizioni si applicano.
  • Anche la rimozione tempestiva dei privilegi è importante.
  • Non sembra che si applichi nel tuo caso, ma ci sono privilegi che si escludono a vicenda?
  • Considerare la scadenza dei ruoli e degli utenti inutilizzati? Ciò aumenterà la tua sicurezza, ma potrebbe richiedere più supporto.
  • Cerca di limitare il numero di ruoli; concedere tutte le autorizzazioni richieste dal ruolo anziché aggiungere ruoli aggiuntivi.

I privilegi standard tendono ad essere gerarchici: leggi, + aggiorna / crea, + cancella o leggi / approva. I ruoli di approvazione sono di solito almeno parzialmente esclusivi con aggiornamento / creazione / eliminazione. Nessuno non è un privilegio. L'utilizzo di valori crescenti per codificare per aumentare i privilegi di solito funziona. I ruoli di approvazione sono problematici in questo caso, ma il mio arriva con limiti come approvare < A $ 250.

I ruoli sono una raccolta di privilegi, probabilmente solo uno. Possono privilegiare la gestione in modo molto più semplice e garantire agli utenti tutti i privilegi necessari per svolgere il proprio lavoro.

I privilegi possono riguardare i moduli. Considerare i ruoli che richiedono i privilegi di cui sopra dal modulo. I moduli spesso corrispondono a ruoli (organizzativi). Tuttavia, è normale che un ruolo basato su moduli implichi almeno l'accesso in lettura ad altri dati dei moduli.

Non preoccuparti dei ruoli che concedono l'accesso a moduli non contrattati da un cliente. L'accesso al modulo di controllo da parte del cliente / cliente, a seconda dei casi, non da parte dell'utente. Questo crea profondità nel tuo framework di sicurezza. (Diventa anche un punto vendita se la sicurezza non crea un lungo periodo di setup / stabilizzazione quando si aggiungono nuovi moduli.)

    
risposta data 24.09.2016 - 18:52
fonte

Leggi altre domande sui tag