|
Wiki
UniCrema
Materie per semestre
Materie per anno
Materie per laurea
Help
|
|
Uni.ESP16aprile2008 History
Hide minor edits - Show changes to output
Changed line 66 from:
Per l'inconsistenza, ho due sostanziali soluzioni: to:
Per l'inconsistenza, ho queste soluzioni:
Added lines 1-105:
(:title ESP - Lezione del 27 germile 216:)
%titolo%'''Lezione del 27 germile 216 (16.4.2008)'''
[[Torna alla pagina di ESP -> ElementiSicurezzaPrivatezza]]
%sottotitolo%'''Politiche amministrative'''
Queste politiche servono per stabilire chi può concedere o revocare autorizzazioni. Nelle mandatorie, c'è 1 amministratore centrale che decide la classe dei '''soggetti''', e la classe degli oggetti dipende da chi la crea. Quindi, solo l'amministratore decide chi può fare cosa.
Ci sono comunque diversi paradigmi di politiche amministrative:
* '''centralizzata''': 1 amministratore
* '''gerarchica''': 1 amministratore, con delega ad altri utenti
* '''cooperativa''': diversi amministratori, e le auth devono essere rilasciate da tutti
Le più usate sono:
* '''ownership''': chi crea un oggetto ne è il proprietario, e dà lui i permessi agli altri su quell'oggetto
* '''decentralizzata''': non vuol dire cooperativa, ma vuol dire che diversi utenti fanno quello che vogliono nelle zone a loro dedicate, delegando etc.
I problemi riguardano soprattutto tenere traccia in modo chiaro di chi può fare che cosa, come gestire le deleghe, e che cosa accade quando un'autorizzazione viene revocata.
Con la '''delega ristretta''', si può decidere se i privilegi vanno dati in blocco, oppure possono essere dati in modo selettivo.
Per quanto riguarda la revoca, è il solito problema: A autorizza B, e B autorizza C. Poi ad A viene tolta dal Grande Capo l'autorizzazione. Che accade a B e C, a cui i poteri sono stati dati da A, il quale ormai non ne ha più?
La soluzione di questo problema dipende da come è organizzato il sistema. Nei '''DBMS''' in generale si sceglie se le revoche vadano a cascata, o no.
!!!DBMS
I DBMS relazionali che usano SQL usano una politica decentralizzata, combinata con il concetto di ownership: chi crea qualcosa, ne è l'admin.
Poi c'è la faccenda del GRANT:
GRANT SELECT ON TABLE brao TO ukulele WITH GRANT OPTION
Si decide cioè che permessi dare, su che oggetti, a chi, e si specifica, con la GRANT OPTION, se quell'utente potrà a sua volta rilasciare quei permessi a qualcun altro.
!!!DAC avanzate
Le DAC viste finora usavano una tripla (U,A,O) = Utente, Azione, Oggetto, ma sono poco espressive.
Quindi, si estende l'idea con una cosa così: (U, A, O, Condizione). La semantica di questa quadrupla è che il privilegio si applica all'utente SSE la condizione è soddisfatta.
Le condizioni possono essere di qualunque tipo: ora del giorno, amicizia con il padrone, il contesto e così via.
!!!Autorizzazioni per gruppi
Quando ci sono tanti utenti, non è molto comodo dover assegnare a ciascuno decine e decine di privilegi.
Si introduce quindi l'astrazione di una '''gerarchia''', definita su soggetti o oggetti o altri componenti, in cui i privilegi in cima alla gerarchia si propagano a tutti i "figli".
Posso anche decidere di non propagare automaticamente i privilegi, oppure subordinare dei privilegi alla presenza di altri privilegi, che magari dovrei ottenere da altri cammini gerarchici.
Ma c'è il problema che è difficile dare privilegi ad un solo utente, cioè tirarlo fuori dalla gerarchia per fargli fare qualcosa di specifico. Per intenderci, è inutile e magari rischioso autorizzare il lavavetri ad entrare nel Sancta Sanctorum, in genere riservato al Grande Capo, solo per pulire la bacheca.
E allora, si introducono delle '''eccezioni''', applicate direttamente ai nodi, che rappresentano, a seconda del tipo di gerarchia, un utente o un oggetto.
Autorizzazione positiva: (Utente, Azione, Oggetto, +)
Autorizzazione negativa: (Utente, Azione, AltroOggetto, -)
dove '''+''' significa il poter fare l'azione, '''-''' no.
Nelle '''politiche aperte''', le autorizzazioni specificano '''negazioni'''.\\
Nelle '''politiche chiuse''', invece, le autorizzazioni specificano '''permessi'''.
In una politica aperta uno può fare quello che gli deriva dalla gerarchia, a meno di eccezioni. Al contrario, in una politica chiusa, uno non può fare niente a meno di eccezioni. Le '''autorizzazioni negative''' permettono di esprimere sia politiche aperte, che chiuse.
Non è tutto rose e fiori. Ci sono dei problemi:
* '''inconsistenza''': se da una parte ad un utente viene un +, e dall'altra un -, chi vince?
* '''non completezza''': ci saranno oggetti senza + né -? Se sì, come mi comporto?
Per l'inconsistenza, ho due sostanziali soluzioni:
* '''Denials take precedence''' = vincono i NO, anche se sono in parità
* '''Most Specific Takes Precedence''' (MSTP) = vince l'autorizzazione più specifica
* '''Most Specific Along A Path Takes Precedence''' (MSAPTP) = si confrontano le più specifiche su ogni percorso di autorizzazione, per vedere chi vince.
Questi sono i modi per risolvere i '''conflitti''' tra autorizzazioni discordanti. Se decido che vincono sempre i + o i - in un conflitto, è semplice. Con le altre tecniche, un po' meno.
!!!MSTP
Devo prendere l'autorizzazione più specifica nella mia gerarchia, ed applicare quella.
Però, se diversi cammini portano allo stesso utente (o oggetto), e al nodo precedente uno dice + e l'altro dice -, chi vince?
(de)Càpita quindi che ci siano conflitti non risolvibili con la MSTP, anche se a prima vista sembra bella.
!!!MSAPTP
Qui devo valutare tutti i percorsi che si dipanano dal mio oggetto (o utente). Per '''ogni''' percorso che risale alla radice, vedo qual'è l'autorizzazione più specifica.
Se tutti sono d'accordo, il conflitto è risolto. Non lo è però quando non tutti i percorsi sono d'accordo, quindi nemmeno MSAPTP è perfetta.
!!!Strong VS Weak
Un altro sistema è quello di dire: ci sono autorizzazioni '''forti''' e autorizzazioni '''deboli''', e le auth forti vincono sempre su quelle deboli.
Nel caso invece di scontro tra due autorizzazioni deboli, si usa la MSAPTP.
Ma nemmeno questa è del tutto efficace:
* ci sono solo 2 livelli di priorità
* le autorizzazioni forti devono essere consistenti, se no non servono a nulla
Il secondo punto significa che se ho una forte contro una debole, so chi vince. Ma se ho una forte contro una forte, e dicono cose diverse, chi vince?
Si obbliga quindi l'amministratore a concedere le autorizzazioni forti in modo che non creino questi problemi di consistenza, ma allora questa tecnica non risolve in modo automatico tutti i conflitti...
!!!Altre politiche
'''Posizionale''': ho una lista ordinata di autorizzazioni. L'ultima data è quella che fa testo.
'''Grantor-Dependent''': dipende da chi mi ha dato l'autorizzazione.
'''Time-Dependent''': la priorità dipende da quando sono state concesse le autorizzazioni.
[[Torna alla pagina di ESP -> ElementiSicurezzaPrivatezza]]
|
|
