Discretionary access control: differenze tra le versioni

Versione delle 23:10, 25 nov 2015

Versione delle 03:19, 11 feb 2018

Riga 1:

{{S|sicurezza informatica}}

Nell'ambitoIn dellacampo di [[sicurezza informatica]], il "controllo degli accessi di tipo discrezionale" o '''Discretionary Access Control''' ('''DAC)''') identificaè un meccanismotipo di controllo deglid'accesso accessidefinito alledalla risorse messe a disposizione da un [[sistema informatico]] definito dalla '':en:Trusted_Computer_System_Evaluation_Criteria|Trusted Computer System Evaluation Criteria'',]] nel"come qualeuna iforma soggettiper possiedonolimitare l'[[ownership]]accesso deglia oggetticontenuto daappartenente loroa creatisoggetti e possono concedere /o revocaregruppi. aI lorocontrolli discrezionesono alcunidiscrezionali privilegiin adquanto altriun soggetti.soggetto Incon un sistemadeterminato informaticopermesso neld'accesso qualeriesce èa realizzatatrasmettere unaquesti politicapermessi dia controlloqualsiasi deglialtro accessisoggetto di( tipoa DAC,meno l'autorizzazioneche degliquesto accessinon allesia risorsecoperto delda sistemauna èrestrizione basatadel sull'identità[[Mandatory degliAccess utentiControl|mandatory e/oaccess sul gruppo utenti di appartenenzacontrol)]]".

Il ''Discretionary Access Control'' è generalmente contrapposto al ''mandatory access control'' (MAC, chiamato anche ''non-discretionary access control''). Talvolta si dice che un sistema nel complesso abbia un controllo d’accesso “discrezionale” o “prettamente discrezionale” riferendosi alla mancanza del mandatory access control. D’altra parte, un sistema può presentare simultaneamente sia MAC che DAC, dove con DAC ci si riferisce all’accesso a risorse che i soggetti possono trasferirsi a vicenda, invece con MAC ci si riferisce a una seconda categoria di controllo d’accesso che impone dei vincoli alla prima.

== Implementazioni ==

Il significato del termine dato dal TCSEC non è molto chiaro in quanto la definizione del ''Discretionary Access Control'' della TCSEC non impone un concetto d’esecuzione. Ci sono almeno due tipi di implementazione: con il proprietario (come modello più esteso) e con le competenze.

'''<big>Con il proprietario</big>'''

Il termine DAS è comunemente usato in contesti che presuppongono che ogni oggetto abbia un proprietario che controlli il permesso d’accesso all’oggetto, probabilmente perché alcuni sistemi applicano il DAC usando l’impostazione del proprietario. Eppure, la definizione del TCSEC non dice nulla sui proprietari, quindi tecnicamente un sistema di controllo d’accesso non necessita un’impostazione del proprietario secondo la definizione del DAC della TCSEC.

I proprietari grazie a l’esecuzione del DAC hanno il potere di creare decisioni sulle politiche e/o designare caratteristiche di sicurezza. Un modello chiaro è l’[[:en:Filesystem_permissions#Traditional_Unix_permissions|Unix file mode]] che rappresenta scrittura, lettura ed esecuzione in ognuna delle 3 parti per ciascun Utente, Gruppo e Altri. (è simulato da un’altra parte che indica le caratteristiche aggiuntive).

'''<big>Con le competenze</big>'''

Un altro esempio sono i sistemi di capacità che delle volte vengono descritti come fornitori di controlli discrezionali dato che permettono ai soggetti di trasferire i loro accessi ad altri soggetti, nonostante la sicurezza basata sulla capacità non si riferisca principalmente sull’accesso ristretto “all’identità del soggetto” ( il sistema di capacità, generalmente, non permette che le autorizzazione siano trasferite “da un soggetto all’altro”; il soggetto che attende di aver approvato l’autorizzazione deve prima poter accedere alla risorsa, e il soggetto generalmente non deve avere accesso a tutte le risorse nel sistema).

== Voci Correlate ==

* [[Lista di controllo degli accessi]]

* [[Mandatory Access Control]]

* [[Role-based access control]]

* [[Capability]]

* [[XACML]]

== Note ==

# [[:en:Trusted_Computer_System_Evaluation_Criteria|''Trusted Computer System Evaluation Criteria'']]. United States Department of Defense. December 1985. DoD Standard 5200.28-STD. Archived from [http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html the original] on 2006-05-27.

# http://fedoraproject.org/wiki/Features/RemoveSETUID - Fedora 15 set to remove SETUID in favor of (Linux kernel) capabilities.

* P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. ''[https://web.archive.org/web/20070621155813/http://jya.com/paperF1.htm The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments]''. In Proceedings of the 21st National Information Systems Security Conference, pp. 303–14, Oct. 1998.

{{Portale|sicurezza informatica}}