ACWP State of the Art: Difference between revisions
Jump to navigation
Jump to search
| Line 23: | Line 23: | ||
* Benantar, Messaoud (Ed.): Access Control Systems. Springer. 2006. | * Benantar, Messaoud (Ed.): Access Control Systems. Springer. 2006. | ||
* Ferraiolo, David; Kuhn, Richard; Chandramouli, Ramaswamy: Role-Based Access Control. Artech House. 2. Auflage, 2007. | * 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. | * ''Build Security In''. Website of the US Department of Homeland Security.[[https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles.html]] | ||
[[https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles.html]] | |||
===Paradigms: DAC, MAC, RBAC, ...=== | ===Paradigms: DAC, MAC, RBAC, ...=== | ||
Revision as of 15:17, 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...
