cerca
TAPD 16 Marzo 2009
modifica cronologia stampa login logout

Wiki

UniCrema


Materie per semestre

Materie per anno

Materie per laurea


Help

Return to TAPD 16 Marzo 2009  (Edit)

Uni.TAPD160309 History

Hide minor edits - Show changes to output

Changed line 3 from:
(:title TAPD 16 Marzo 2009
to:
(:title TAPD 16 Marzo 2009:)
Added lines 2-3:

(:title TAPD 16 Marzo 2009
Added lines 7-15:
>>left bgcolor=#f5f9fc width=240px border='2px solid #cccccc' padding=5px<<
%center%'''Indice'''

# [[#s1|Controllo degli accessi basato sulle credenziali]]
# [[#s2|Regole di accesso a servizi]]

>><<

[[#s1]]
Changed lines 60-61 from:
!!Regole di accesso a servizi:
to:
[[#s2]]
!!Regole di accesso a servizi
Deleted lines 6-15:
>>left bgcolor=#f5f9fc width=240px border='2px solid #cccccc' padding=5px<<
%center%'''Indice'''

# [[#s1|Controllo degli Accessi]]
# [[#s2|Composizione di Politiche]]

>><<


[[#s1]]
Added lines 60-69:

!!Regole di accesso a servizi:

* regole prerequisiti: credenziali e dichiarazioni che il client deve dare per far si che la richiesta sia presa in considerazione.
* regole requisiti: credenziali e dichiarazioni che il client deve dare per far si che la richiesta sia garantita accettata.
* regole aggiuntive: per aver accesso a particolari features del servizio. Se non soddisfatte non compromettono in generale l'uso del servizio.

[vedere figura di pag. 61 delle slides]

Sui linguaggi logici in sviluppo si ragiona se supportare o meno le variabili.
Changed lines 17-18 from:
!!Dicevamo ...
to:
!!Controllo degli accessi basato sulle credenziali
Changed lines 43-59 from:
è necessario
to:
E' necessario un sistema di astrazione.

''Linguaggio di specificazione - requisiti:
deve avere il concetto di
*credenziali
*dichiarazioni
*autorità di certificazione
*costrutti matematici per i controlli (es. l'età)

''Trust Management:''
man mano che client e server dialogano con richieste e controrichieste (da parte di entrambi) prendono fiducia l'uno dell'altro.

Il server non deve dare tutta la politica in pasto all'utente.
Il server deve comunicare la politica facendo prima una valutazione parziale.
Ai client piacerebbe sapere che le informazioni che sta man mano dando saranno sufficienti per avere l'accesso.
Non faccio N step per poi scoprire all'ultimo che non ho diritto al servizio.
E' bene che il server dichiari prima le credenziali richieste : specificare le condizioni sufficienti per l'accesso.
Changed lines 38-39 from:
to:
''Servizi:''
* tipo di servizio
* sotto-servizi

I servizi posso essere raggruppati in classi.
è necessario
Changed lines 32-36 from:
''Credenziali
to:
''Credenziali:''
* nome della credenziale/tipo
* attributi

'''es: "dammi il numero di una carta di credito valida dove sia specificato il tuo nome". in questo caso non interessa il tipo di carta: Visa, Mastercard,...).'''
Deleted lines 34-91:
\\
'' "io devo fare 'la tal operazione', dimmi quello che ti serve come informazione per poterlo permettere"''

I Paradigmi tradizionali non sono più adatti.
Anche se non piacciono le autorizzazioni negative sono l'attuale unica soluzione alla gestione delle eccezioni.

'''Sistema di tipo aperto:''' ''io sistema non ti conosco, tu utente mi dai le informazioni man mano che occorrono.''
In caso di sistemi di tipo aperto, le autorizzazioni negative non vanno bene.
Vanno bene, invece, per sistemi chiusi: dove il sistema che gestisce gli accessi ha tutte le informazioni dell'utente memorizzate.
Va bene supportare le proprietà, ma che puntino sempre ad una certa gerarchia.
Devo avere risoluzione e decisione sui conflitti (+ e - ,se sono autorizzazzioni incomparabili, non si ha la risoluzione del conflitto).
Tutto questo può non bastare in alcune situazioni.
* composizione di politiche indipendenti (es. Segretaria; Legge Italiana, ...)

* ci si deve staccare dall'identificazione dell'utente (es. certificati anonimi)
''"tu vuoi che si soddisfi certe proprietà. io ho un'autorità che lo certifica ma non sai quali sono le proprietà in gioco."''

* importanza dello scopo per il rilascio di informazioni (es. per ricerche di mercato).

* sistemi di controllo degli accessi interattivi (dialogo interattivo sistema-utente durante le operazioni).

* avere una soluzione che sia un compromesso tra semplicità ed espressività di linguaggio per la specifica di politiche (es. XML per macchine, illeggibile <-> linguaggi logici, facili ma da implementare).

* contesto (dell'oggetto, del soggetto, ...).

* usi secondari delle info rilasciate rispetto al loro uso primario. vanno dichiarati.

[[#s2]]
!!Composizione di Politiche

La politica da imporre su una risorsa non è proveniente da un'unica autorità.
I linguaggi attuali per le autorizzazioni supportano le politiche multiple ma sono basati su specificazioni complete e monolitiche.
Si ha il problema di interferenze tra politiche.
Dopo la composizione, inoltre, le singole controparti non sono più autonome.

Non è detto che io possa effettivamente da ''n'' politiche trarne una sola.
Potrei non poter avere accesso completo alle regole della politica della singola autorità, poiché in presenza di blacklist confidenziali.

"ok, hai inglobato la mia politica nella politica globale, ma voglio ancora essere certo che le proprietà su cui avevo certezza prima ci sia ancora.
Persone a cui era certamente consentito l'accesso ad una risorsa e persone a cui certamente non era consentito: deve essere ancora così, voglio garanzie!"

Voglio che ogni politica rimanga indipendente e si competenza dell'autorità referente.
Quando però devo accedere voglio che le ''n'' politiche siano valutate composte.

"Se una politica fa uso di regole del tipo 'tutti possono fare tutto', la regola è limitata alle sole risorse di competenza dell'autorità della politica.
Es. se è riferita ad una directory, è valida solo a tutte le sotto-directory e la directory stessa".
Abbiamo restrizioni di target.

Su una richiesta, le varie politiche possono rispondere in 4 modi:

* SI
* NO
* NON APPLICABILE (non è del mio paradigma)
* NON HO NIENTE DI SPECIFICATO IN PROPOSITO (NON SO)

Si fa uso di linguaggi formali per avere garanzie.

'''Politica di tipo aperto:''' ''consento tutto tranne quello che è negato.''
Added lines 1-95:
[[Torna alla pagina di Tecniche Avanzate per la Protezione dei Dati -> TecnicheAvanzatePerLaProtezioneDeiDati]]

%titolo%''':: Tecniche Avanzate per la Protezione dei Dati ::'''

%center%%sottotitolo%Lezione 02 del 16 Marzo 2009

>>left bgcolor=#f5f9fc width=240px border='2px solid #cccccc' padding=5px<<
%center%'''Indice'''

# [[#s1|Controllo degli Accessi]]
# [[#s2|Composizione di Politiche]]

>><<


[[#s1]]
!!Dicevamo ...

''Situazione attuale:'' Oggi siamo su strutture multiple distribuite.

''Sistemi Aperti'': non conosco chi accede, controllo degli accessi basato su credenziali con l'ausilio di certificati digitali.

''Certificato digitale:'' dichiara l'identità, al portatore (indipendente dalla persona fisica), rilasciato da una specifica autorità.

In un sistema aperto con l'utilizzo di certificati è necessario una negoziazione: l'utente non vuole e non deve dichiarare al sistema tutte le sue proprietà e certificati in possesso. Il sistema ha regola per l'accesso, l'utente pone regole sul rilascio delle sue informazioni.
L'utente può fare delle controrichieste: "ok, ma le mie informazioni poi vengono crittografate?"

''Proprietà del client'':
* credenziali (certificano mie proprietà, firmate da autorità)
* dichiarazioni (proprietà specificate direttamente dall'utente e non certificate. vengono trattate diversamente)

''Credenziali


\\
'' "io devo fare 'la tal operazione', dimmi quello che ti serve come informazione per poterlo permettere"''

I Paradigmi tradizionali non sono più adatti.
Anche se non piacciono le autorizzazioni negative sono l'attuale unica soluzione alla gestione delle eccezioni.

'''Sistema di tipo aperto:''' ''io sistema non ti conosco, tu utente mi dai le informazioni man mano che occorrono.''
In caso di sistemi di tipo aperto, le autorizzazioni negative non vanno bene.
Vanno bene, invece, per sistemi chiusi: dove il sistema che gestisce gli accessi ha tutte le informazioni dell'utente memorizzate.
Va bene supportare le proprietà, ma che puntino sempre ad una certa gerarchia.
Devo avere risoluzione e decisione sui conflitti (+ e - ,se sono autorizzazzioni incomparabili, non si ha la risoluzione del conflitto).
Tutto questo può non bastare in alcune situazioni.
* composizione di politiche indipendenti (es. Segretaria; Legge Italiana, ...)

* ci si deve staccare dall'identificazione dell'utente (es. certificati anonimi)
''"tu vuoi che si soddisfi certe proprietà. io ho un'autorità che lo certifica ma non sai quali sono le proprietà in gioco."''

* importanza dello scopo per il rilascio di informazioni (es. per ricerche di mercato).

* sistemi di controllo degli accessi interattivi (dialogo interattivo sistema-utente durante le operazioni).

* avere una soluzione che sia un compromesso tra semplicità ed espressività di linguaggio per la specifica di politiche (es. XML per macchine, illeggibile <-> linguaggi logici, facili ma da implementare).

* contesto (dell'oggetto, del soggetto, ...).

* usi secondari delle info rilasciate rispetto al loro uso primario. vanno dichiarati.

[[#s2]]
!!Composizione di Politiche

La politica da imporre su una risorsa non è proveniente da un'unica autorità.
I linguaggi attuali per le autorizzazioni supportano le politiche multiple ma sono basati su specificazioni complete e monolitiche.
Si ha il problema di interferenze tra politiche.
Dopo la composizione, inoltre, le singole controparti non sono più autonome.

Non è detto che io possa effettivamente da ''n'' politiche trarne una sola.
Potrei non poter avere accesso completo alle regole della politica della singola autorità, poiché in presenza di blacklist confidenziali.

"ok, hai inglobato la mia politica nella politica globale, ma voglio ancora essere certo che le proprietà su cui avevo certezza prima ci sia ancora.
Persone a cui era certamente consentito l'accesso ad una risorsa e persone a cui certamente non era consentito: deve essere ancora così, voglio garanzie!"

Voglio che ogni politica rimanga indipendente e si competenza dell'autorità referente.
Quando però devo accedere voglio che le ''n'' politiche siano valutate composte.

"Se una politica fa uso di regole del tipo 'tutti possono fare tutto', la regola è limitata alle sole risorse di competenza dell'autorità della politica.
Es. se è riferita ad una directory, è valida solo a tutte le sotto-directory e la directory stessa".
Abbiamo restrizioni di target.

Su una richiesta, le varie politiche possono rispondere in 4 modi:

* SI
* NO
* NON APPLICABILE (non è del mio paradigma)
* NON HO NIENTE DI SPECIFICATO IN PROPOSITO (NON SO)

Si fa uso di linguaggi formali per avere garanzie.

'''Politica di tipo aperto:''' ''consento tutto tranne quello che è negato.''

----
[[Torna alla pagina di Tecniche Avanzate per la Protezione dei Dati -> TecnicheAvanzatePerLaProtezioneDeiDati]]