Implementa l'RBAC per la mia applicazione

Posso suggerire le seguenti opzioni in base alle informazioni fornite:

1. Definisci dominio dei dati (Nord America, Europa, ecc.) in base ai tuoi criteri e concedi ruoli solo all'interno di quel dominio. Ad esempio, concedere il ruolo 1 nel dominio dei dati A o nell'account S1. Abbastanza semplice, ma dipende dalla struttura dei dati.
2. Aggiungi condizioni aggiuntive nello stile ABAC , ovvero concedi o neghi l'accesso a un ruolo specifico in caso alcune condizioni sono vere (ad esempio, se l'utente ha autorizzato Regioni = Regione risorsa corrente) Questo approccio aggiunge complessità alla soluzione e alla sua matrice di sicurezza, ma le politiche ABAC sono molto potenti e possono coprire vari casi.

Questo è un problema comune per i fornitori di soluzioni globali.

Gli account e le aree geografiche non sono ulteriori "drill-down" nel contesto delle autorizzazioni e dell'RBAC, ma rappresentano invece aree di governance più ampie all'interno delle quali entrano in vigore gli schemi RBAC.

Gli account e le aree geografiche sono più importanti di qualsiasi ruolo / capacità specifici in qualsiasi applicazione specifica. Gli account implicano spesso un rapporto di custodia, la cui violazione può sottoporre la società a cause legali o multe e regole di accesso in cui possono essere distintivi e differenziati in modo univoco da quelli di altri account.

Allo stesso modo, le regioni geografiche implicano diversi regimi legali, con regole speciali a cui si deve aderire che superino qualsiasi politica o approccio aziendale particolare.

Dato che le aziende di solito (anche se non sempre) coprono le regioni, il modello usuale è considerare i conti come il livello più alto. Qualsiasi account cliente specificato può avere più regioni in cui il cliente ha una presenza legale. In ciascuna di queste regioni, quindi, all'interno dell'account, può essere assegnato uno specifico schema RBAC agli utenti rilevanti per l'account.

In altre parole, un singolo utente dovrebbe avere ruoli univoci, esplicitamente enumerati per ogni regione in ciascun account. L'utente X può avere il ruolo 1 (con funzionalità D1 e A1) per l'account S1 nella regione Z, ma il ruolo 2 con funzionalità D2, T2 e A2 per l'account S1 nella regione Y e un insieme diverso per l'account S2 nelle regioni Z e Y .

Funzionalità di accesso: = ruoli Ruoli: = attributi Attributi: = proprietario dell'account, tipo di conto, regione, unità aziendale, *

OK, quindi dove è il problema quando si utilizzano corrispondenze esatte sul set di attributi? Cioè tutto nella regione C può utilizzare la funzionalità FA. Bene, dipende dal fatto che l'azienda stia bene con l'accesso non intenzionale ma legittimo e la responsabilità con il suo uso. Se si imposta l'accesso basato sul ruolo in cui non si elencano esplicitamente i titolari di account white, accertarsi di disporre di una traccia di accounting che registri tutti gli usi da parte dei titolari dell'account. Inoltre, se l'uso inappropriato ma legittimo provoca danni, evidenzia che il programma funziona secondo le specifiche e dispone di registri adeguati per determinare l'attribuzione dell'utente. Hanno anche una catena di chi consente l'accesso a cosa.