ACWP State of the Art: Difference between revisions

From IHE Wiki
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...