Implementazione del controllo delle autorizzazioni per le risorse dati correlate

1

Immagina un modello di dati di un'azienda elettrica e della città che alimenta. L'azienda ha diversi dipartimenti che gestiscono almeno un quartiere ciascuno nella città. Il database aziendale include informazioni per le case in ogni quartiere, i contatori installati a casa, la cronologia di fatturazione, ecc. Qualsiasi dipendente in un dipartimento può accedere e visualizzare tutti i diversi tipi di dati, ma possono solo visualizzare i dati per quartieri che il loro dipartimento gestisce. Schema di esempio:

Dipartimenti

  • ID
  • Nome

Quartieri

  • ID
  • Nome

DepartmentsToNeighborHoods (LinkTable)

  • DepartmentID
  • NeighborhoodID

I dipendenti

  • ID
  • Nome
  • ID reparto (chiave esterna)

Case

  • ID
  • Indirizzo
  • NeighborhoodID (chiave esterna)

Metri

  • ID
  • HomeID (chiave esterna)

Dato questo modello di dati, sto tentando di implementare un'interfaccia riposante in cui i dipendenti possono estrarre dati ma solo risorse all'interno del proprio dipartimento. Ad esempio, se un dipendente desidera accedere alla cronologia di fatturazione in una determinata casa, può farlo solo se quella casa si trova in un quartiere gestito dal dipartimento del dipendente.

L'unico modo in cui posso pensare a ciò è implementando una funzione di autorizzazioni che controlla se un utente può accedere a una particolare risorsa dato il suo id utente. Una possibile implementazione (pseudocodice):

getMeterDetails(meterID, employeeID) {
    permissionQuery = "
        select 1
        from Meters
            join Homes on Homes.ID = Meters.HomeID
            join Neighborhoods on NeighborHoods.ID = Homes.NeighborHoodID
            join DepartmentsToNeighborhoods as DTN on DTN.NeighborhoodID = Neighborhoods.ID
            join Employees on  Employees.DepartmentID = DTN.DepartmentID
        where Meters.ID = ?
            and Employees.ID = ?
    "

    result = db.runQuery(permissionsQuery, meterID, employeeID)

    if (result == 1) {
        return MeterModel.get(meterID);
    }
    else {
        return ERROR_VALUE;
    }
}

Il problema generale è che voglio limitare l'accesso a particolari risorse basate sull'appartenenza a un'altra risorsa lontana. Il mio metodo attuale richiede che venga eseguita una query di database aggiuntiva ogni volta che viene richiesta una risorsa. Devo anche scrivere query di autorizzazione personalizzate per ciascuna risorsa che espongo perché ognuna utilizza un diverso insieme di relazioni per determinare se l'attuale dipendente può accedere a questa particolare risorsa. C'è un metodo migliore che posso usare per implementare questo tipo di controllo dei permessi?

    
posta Copernicus 31.10.2017 - 16:38
fonte

1 risposta

3

Ecco una risposta più lunga alla tua domanda. La sfida che stai colpendo è che hai dei requisiti di autorizzazione con più parametri / dimensioni. Desideri definire autorizzazioni che non dipendono semplicemente dall'identità, ruolo o gruppo di un utente, ma anche dai dati a cui stanno ottenendo l'accesso e, ancora più importante, la relazione tra gli utenti e i dati.

Il quadro di autorizzazione più diffuso là fuori è qualcosa chiamato RBAC o controllo degli accessi basato sui ruoli. L'RBAC è stato formalizzato dal NIST, l'Istituto nazionale degli standard e della tecnologia . La sfida, nel tuo caso, con RBAC, è che è incentrata sull'identità, poiché in essa prende in considerazione solo i parametri dell'utente (ruolo, gruppo). Potresti definire un ruolo, ad es. manager che verrebbe assegnato a un'autorizzazione, ad es. %codice%. Ma non è abbastanza per te.

Per risolvere il problema, il NIST ha presentato un nuovo modello chiamato ABAC (Attribute Based Access Control) . In ABAC, ora puoi utilizzare più metadati / parametri. Ad esempio, puoi prendere in considerazione:

  • identità di un utente, ruolo, titolo del lavoro, ubicazione, dipartimento, data di nascita ...
  • tipo di risorsa (contatore), posizione, proprietario, valore, reparto ...
  • informazioni contestuali ad es. ora del giorno
  • l'azione che l'utente sta tentando sulla risorsa

Tutti questi sono chiamati attributi . Gli attributi sono il fondamento di ABAC, da cui il nome. Puoi assemblare questi attributi in norme . Le politiche sono un po 'come la salsa segreta di ABAC. Le politiche possono concedere e negare l'accesso. Ad esempio:

  • Un dipendente può visualizzare un contatore se il dipendente e il contatore si trovano nella stessa regione
  • Nega accesso alle letture dei contatori tra le 17:00 e le 8:00.

Le politiche possono essere utilizzate per esprimere scenari avanzati, ad es.

  • segregazione del dovere
  • vincoli basati sul tempo (vedi sopra)
  • controllo dell'accesso basato sulle relazioni (vedi sopra)
  • regole di delega ad es. delegare l'accesso di Bob al contatore di Alice.

Sono disponibili 2 sintassi principali per scrivere le politiche:

  • la lingua abbreviata per l'autorizzazione ( ALFA )
  • l'eXtensible Access Control Markup Language ( XACML )

ABAC include anche un'architettura per definire in che modo le politiche verranno valutate e applicate.

L'architetturacontieneiseguenticomponenti:

  • ilPolicyEnforcementPoint(PEP):questoèilcomponentecheproteggel'API/l'applicazionechesidesideraproteggere.IlPEPintercettailflusso,loanalizzaeinviaunarichiestadiautorizzazionealPDP(vedisotto).Quindiriceveunadecisione(Permit/Nega)cheimpone.
  • ilPuntodidecisionepolitica(PDP)riceveunarichiestadiautorizzazione(ades.Alicepuòvisualizzareilcontatore#123?)elovalutarispettoall'insiemedicritericoncuièstatoconfigurato.AllafineraggiungeunadecisionecherimandaalPEP.Duranteilprocessodivalutazione,ilPDPpotrebberichiedereulteriorimetadati,ades.iltitolodilavorodiunutente.Atalfine,puòrivolgersiaipuntidiinformazionesuicriteri(PIP)
  • ilPolicyInformationPoint(PIP)èl'interfacciatraPDPeoriginidatisottostanti,ades.unLDAP,undatabase,unservizioRESTchecontienemetadatisuutenti,risorseoaltro.ÈpossibileutilizzareiPIPperrecuperareleinformazionichepotrebberoesserenecessariealPDPinfasediesecuzione,ades.unpunteggiodirischio,laposizionediunmisuratoreoaltro.

Implementazioni

Sonodisponibilidiverseimplementazioniopen-sourceecommerciali.Adesempio Axiomatics Policy Server (commerciale - che è dove lavoro). Troverai l'intero elenco online .

    
risposta data 01.11.2017 - 21:00
fonte

Leggi altre domande sui tag