raccomandazioni relative alla sicurezza degli utenti / buone pratiche

Secondo la mia esperienza, utenti, gruppi e ruoli vanno bene (anche se i ruoli dei gruppi sembrano ridondanti), ma ciò che realmente semplifica la sicurezza è il concetto di privilegi.

if not currentUser.canDoThat():
    raise SomethingWrongGoingOn()
else:
   # do this
   # do that

Lo schema dei privilegi può essere tanto complesso quanto necessario.

class User(object):
    def canDoThat(self):
        for group in self.groups:
            if group.has_privilege(CAN_DO_THAT):
                return True
        return False

In tale schema il codice viene protetto con privilegi prevalentemente atomici definiti su rischi e riservatezza, mentre lo schema di privilegi user- > group- > può essere gestito da livelli più vicini all'interfaccia utente, o delegato a qualcosa di centralizzato come un LDAP / Repository AD.

In breve, custodisci il codice con query sui privilegi (il codice più semplice), pubblica i privilegi per modulo in modo che possano essere alias e sintetizzati su un set minimo e lasciare che un'autorità di autenticazione decida quale utente ha i privilegi.

Qual è la distinzione tra ruoli e gruppi nel tuo software? Molto spesso i due sono intercambiabili, ma senza sapere come li gestisci, non posso dire se puoi unirli.

Ora mi sembra che tu abbia già deciso un sistema basato su ACL. (Se non sapevi che questa era una decisione, consulta i sistemi di capacità per un approccio molto diverso sicurezza.) La tua domanda è come gestire le autorizzazioni.

Alcuni anni fa ho creato un interessante sistema di autorizzazioni che aveva alcune idee che potreste trovare interessanti. Aveva anche alcuni aspetti negativi. Lo descriverò e potrai decidere se prenderne in prestito qualcosa.

Il mio pensiero centrale era il seguente. I gruppi possono appartenere ai ruoli. I ruoli (e gli utenti) possono avere permessi. Tutte queste autorizzazioni possono essere distribuite su base temporanea o permanente. Se hai ottenuto l'autorizzazione in più modi, otterresti il permesso per il periodo di tempo più lungo possibile.

Prima il positivo. Gli utenti hanno trovato davvero facile gestire le autorizzazioni. Ad esempio, un'attività comune consisterebbe nel distribuire una prova gratuita a un'azienda. Per fare ciò hai preso i conti per quella società, ha detto che appartenevano alla società, e quindi ha dato l'iscrizione temporanea all'azienda nel ruolo di prova gratuita. Ecco! Più tardi, quando è uscito con un nuovo prodotto e volevamo aggiungerlo a ciò che le persone in prova gratuita hanno ottenuto, hanno appena aggiunto la nuova autorizzazione alla versione di prova gratuita e tutti hanno capito.

Ora il negativo. Concettualmente era veramente pulito. Ma ogni volta che veniva modificato un permesso, dovevo seguire la logica per capire tutte le modifiche ai permessi a cascata. Questo pezzo di logica era lento. Agli utenti non importava molto: distribuivano le autorizzazioni e facevano qualcos'altro mentre il sistema si spegneva. Ma mi ha causato mal di testa. Principalmente era la mia implementazione, e in parte era inerente al funzionamento del sistema. Nel nostro sistema avevamo migliaia di utenti con migliaia di autorizzazioni ciascuno. Tracciare quel casino di permessi per capire tutto ciò che è appena cambiato è stata una sfida. Se hai meno utenti (si spera non lo siano) o meno permessi per utente (molto probabilmente), si spera che questo sia meno un problema.

L'ho effettivamente implementato in un database. Ecco le tabelle necessarie per l'approccio che ho seguito:

user:
  id
  name
  ...

permission:
  id
  type
  name
  description

role:
  id
  // Only one of the following two is non-zero, and
  // there is a unique index on the pair.
  user_id
  permission_id
  name

role_permission:
  id
  role_id
  permission_id
  expires
  granting_role_id
  created
  created_by

Ora come ha funzionato? Ogni utente aveva un ruolo utente corrispondente. A tempo di esecuzione user si unisce a role , si unisce a role_permission (sbirciando se è scaduto), si unisce a permission per ottenere tutte le autorizzazioni dell'utente. (In pratica sul sito web per un controllo di autorizzazione avevamo sia l'utente che il permesso, e questa ricerca era abbastanza veloce.)

Nel pannello delle autorizzazioni potevi guardare un utente o un ruolo e mostrava tutte le autorizzazioni che quell'utente aveva direttamente, quando erano scadute (se mai) e il ruolo che le era stato assegnato (se non le concedeva direttamente ). È inoltre possibile aggiungere autorizzazioni, eventualmente con un periodo di tempo impostato. Molte di quelle possibili autorizzazioni legate a un ruolo di autorizzazione. (Ad esempio "prova gratuita".)

La parte divertente era la logica per tracciare la cascata di possibili cambiamenti quando veniva modificato un permesso. L'idea era che avrei eseguito una query cercando le autorizzazioni che dovevano essere revocate e quelle che dovevano essere aggiunte. Finché stavo cambiando le autorizzazioni, lo farei di nuovo. Ecco dove ho incontrato problemi di prestazioni.

Penso che se dovessi ricominciare da capo con quello che so ora, potrei risolvere quei problemi di prestazioni molto meglio di quello che ho fatto allora. Ma quella logica era sorprendentemente difficile da ottenere.

Buona fortuna per il tuo progetto. Spero che vedere come qualcuno ha affrontato un problema come questo può darti delle idee su come potresti volerlo fare anche tu.