ACWP State of the Art

From IHE Wiki
Jump to navigation Jump to search

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, ...

Prinzipiell lassen sich drei Grundparadigmen der Zugriffskontrolle unterscheiden:

  • Discretionary Access Control (DAC): Die Prüfung von Zugriffsberechtigungen erfolgt alleine auf Basis der Identität von Subjekten und ihrer Zugehörigkeit zu Gruppen. Subjekte, die Zugriffsrechte auf eine Ressource haben, können diese an andere Subjekte weitergeben. In einer häufig (z. B. in UNIX) implementierten eingeschränkten DAC-Variante wird das Konstrukt eines »Besitzers« (owner) einer Ressource genutzt, der als einzige Instanz Zugriffs¬rechte auf diese Ressource an andere Nutzer oder Gruppen vergeben kann. Hierbei kann bei einem reinen DAC-Modell nicht ausgeschlossen werden, dass einem Nutzer auf diesem Wege Zugriffsrechte (z. B. auf vertrauliche Dokumente) eingeräumt werden, die dieser regulär nicht besitzen darf.
  • Mandatory Access Control (MAC): Die Prüfung von Zugriffsrechten erfolgt anhand von Schutzstufen, Regeln und/oder Policies. Im einfachsten Fall (Multi-Level) werden Objekte Schutzstufen und Nutzer Vertrauensstufen zugeordnet. Über Regeln ist definiert, wie diese Stufen korrelieren und ob (und wie) Nutzer einer Vertrauensstufe Berechtigungen an Nutzer einer anderen Stufe vergeben können. Abwandlungen dieses Modells sind in den meisten der gängigen Betriebssysteme implementiert.
  • Role-Based Access Control (RBAC): Das RBAC-Modell löst sich weitgehend von den Konstrukten eines »Subjekts« und eines »Objekts« und definiert stattdessen Berechtigungen (permissions) von Rolleninhabern auf potenziell feingranulare Operationen. Rollen können hierarchisch definiert werden (hierarchical RBAC) und es können Regeln festgelegt werden, die Einschränkungen auf der Rollenzuweisung und der Berechtigungsvergabe definieren (constrained 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...