ACWP State of the Art: Difference between revisions
Jump to navigation
Jump to search
| Line 4: | Line 4: | ||
===Principles of Secure Design=== | ===Principles of Secure Design=== | ||
* '''Economy of Mechanism:''' Das Berechtigungskonzept muss so einfach wie möglich sein. Es muss ein abgrenzbares Problem adressieren. | |||
* '''Complete Mediation:'''Jeder Zugriff auf eine Ressource muss durch das Access Management geschützt sein. Es darf (auch für Administratoren) keine Möglichkeit geben, am Access Management vorbei auf eine Ressource zuzugreifen. | |||
* '''Open Design:''' Die genutzten Mechanismen und Algorithmen müssen offen und überprüfbar sein. | |||
* '''Least-Common Mechanism:''' Zwischen Anwendungen bzw. Nutzern geteilte Objekte und Zustände der Ablaufumgebung sollten auf das notwendige Minimum reduziert werden . | |||
* '''Fail-Safe Defaults:''' Zugriffe, die nicht explizit als erlaubt verifiziert werden können, sind verboten. Privilegien werden immer nur zu einer initial leeren Menge von Berechtigungen hinzugefügt (opt-in statt opt-out). | |||
* '''Separation of Privilege:''' Schutzmechanismen sollten soweit als möglich auf der Erfüllung mehrerer unabhängiger Bedingungen basieren. | |||
* '''Least Privileges:''' Ein Nutzer/Prozess greift immer nur mit den Privilegien (Berechtigungen) auf eine Ressource zu, die für die Erfüllung der Aufgabe gerade ausreichend sind. | |||
* '''Privacy Consideration:''' Es sollte immer nur der Anteil eines Datensatzes herausgegeben werden, der für die Erfüllung der aktuellen Aufgabe zwingend benötigt wird. | |||
* '''Psychological Acceptability:''' Mechanismen der Zugriffskontrolle dürfen den Datenzugriff für berechtigte Nutzer nicht komplizierter und unvertretbar aufwendiger machen, als dies der Fall ohne Zugriffskontrolle wäre. | |||
* '''Reluctance to Trust:''' Externe Systeme müssen immer als unsicher angesehen werden, es sei denn, dass durch eine angemessene Sicherheitszertifizierung (z. B. nach Common Criteria [CC 3.1]) das Gegenteil angenommen werden kann. Die Zahl der Systemelemente, auf deren fehlerfreies und sicheres Funktionieren bei der Zugriffssicherung vertraut werden muss, sollte minimal sein. | |||
* '''Isolation:''' Die Zugriffskontrollfunktionen sollten von anderen Systemfunktionalitäten isoliert sein und besonders geschützt werden können. | |||
<p> | |||
References: | |||
* Saltzer, J. H.; Schroeder, M. D.: The Protection of Information in Computer Systems. Proceedings of the ACM. Vol. 63, Nr. 9. pp. 1278-1308. 1975. | |||
* Wallach, Dan; Balfanz, Dirk; Dean, Drew; Felten, Edward: Extensible Security Architectures for Java. In: Proc. 16th Symposium on Operating Systems Principles, October 1997, Saint-Malo, France. [[http://www.cs.princeton.edu/sip/pub/sosp97/paper.html]] | |||
* Benantar, Messaoud (Ed.): Access Control Systems. Springer. 2006. | |||
* Ferraiolo, David; Kuhn, Richard; Chandramouli, Ramaswamy: Role-Based Access Control. Artech House. 2. Auflage, 2007. | |||
* ''Build Security In''. Website of the US Department of Homeland Security. | |||
[[https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles.html]] | |||
===Paradigms: DAC, MAC, RBAC, ...=== | ===Paradigms: DAC, MAC, RBAC, ...=== | ||
===Policy Based Access Control (PEP, PDP, ...)=== | ===Policy Based Access Control (PEP, PDP, ...)=== | ||
Revision as of 15:16, 15 January 2009
IHE White Paper on Access Control
State of the Art
Principles of Secure Design
- Economy of Mechanism: Das Berechtigungskonzept muss so einfach wie möglich sein. Es muss ein abgrenzbares Problem adressieren.
- Complete Mediation:Jeder Zugriff auf eine Ressource muss durch das Access Management geschützt sein. Es darf (auch für Administratoren) keine Möglichkeit geben, am Access Management vorbei auf eine Ressource zuzugreifen.
- Open Design: Die genutzten Mechanismen und Algorithmen müssen offen und überprüfbar sein.
- Least-Common Mechanism: Zwischen Anwendungen bzw. Nutzern geteilte Objekte und Zustände der Ablaufumgebung sollten auf das notwendige Minimum reduziert werden .
- Fail-Safe Defaults: Zugriffe, die nicht explizit als erlaubt verifiziert werden können, sind verboten. Privilegien werden immer nur zu einer initial leeren Menge von Berechtigungen hinzugefügt (opt-in statt opt-out).
- Separation of Privilege: Schutzmechanismen sollten soweit als möglich auf der Erfüllung mehrerer unabhängiger Bedingungen basieren.
- Least Privileges: Ein Nutzer/Prozess greift immer nur mit den Privilegien (Berechtigungen) auf eine Ressource zu, die für die Erfüllung der Aufgabe gerade ausreichend sind.
- Privacy Consideration: Es sollte immer nur der Anteil eines Datensatzes herausgegeben werden, der für die Erfüllung der aktuellen Aufgabe zwingend benötigt wird.
- Psychological Acceptability: Mechanismen der Zugriffskontrolle dürfen den Datenzugriff für berechtigte Nutzer nicht komplizierter und unvertretbar aufwendiger machen, als dies der Fall ohne Zugriffskontrolle wäre.
- Reluctance to Trust: Externe Systeme müssen immer als unsicher angesehen werden, es sei denn, dass durch eine angemessene Sicherheitszertifizierung (z. B. nach Common Criteria [CC 3.1]) das Gegenteil angenommen werden kann. Die Zahl der Systemelemente, auf deren fehlerfreies und sicheres Funktionieren bei der Zugriffssicherung vertraut werden muss, sollte minimal sein.
- Isolation: Die Zugriffskontrollfunktionen sollten von anderen Systemfunktionalitäten isoliert sein und besonders geschützt werden können.
References:
- Saltzer, J. H.; Schroeder, M. D.: The Protection of Information in Computer Systems. Proceedings of the ACM. Vol. 63, Nr. 9. pp. 1278-1308. 1975.
- Wallach, Dan; Balfanz, Dirk; Dean, Drew; Felten, Edward: Extensible Security Architectures for Java. In: Proc. 16th Symposium on Operating Systems Principles, October 1997, Saint-Malo, France. [[1]]
- Benantar, Messaoud (Ed.): Access Control Systems. Springer. 2006.
- Ferraiolo, David; Kuhn, Richard; Chandramouli, Ramaswamy: Role-Based Access Control. Artech House. 2. Auflage, 2007.
- Build Security In. Website of the US Department of Homeland Security.
[[2]]
Paradigms: DAC, MAC, RBAC, ...
Policy Based Access Control (PEP, PDP, ...)
Standards (SAML, WS*, XACML, XSPA, ...)
Author's Note: Standards are discussed in greater depth in chapter 6. Therefore I would suggest to skip this issue here.
Discussion
place issues to be discussed among the editorial team here...
Change Requests
place your change requests here...
