Difference between revisions of "ACWP State of the Art"

From IHE Wiki
Jump to navigation Jump to search
Line 5: Line 5:
 
===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.  
+
* '''Economy of Mechanism:''' The used mechanism must be kept as simple as possible. It should also target a well-confined issue instead of trying to cover each and every eventuality.  
−
* '''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.
+
* '''Complete Mediation:''' Every access attempt must be explicitly safe-guarded through the access management mechanisms at all times. This also implies that there must be no possibility to avoid the access management (even for special roles/functions such as administrators) while accessing any resource.
−
* '''Open Design:''' Die genutzten Mechanismen und Algorithmen müssen offen und überprüfbar sein.
+
* '''Open Design:''' All algorithms and security mechanisms have to be openly available and fully check- and verifiable.
−
* '''Least-Common Mechanism:''' Zwischen Anwendungen bzw. Nutzern geteilte Objekte und Zustände der Ablaufumgebung sollten auf das notwendige Minimum reduziert werden .  
+
* '''Least-Common Mechanism:''' Mechanisms, system states and objects, which are capable of explicitly or implicitly granting access rights, should not be shared between different users and/or applications. For each individual user or application, a different mechanism or an instantiation of the same mechanism should be used.
−
* '''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).
+
* '''Fail-Safe Defaults:''' Addresses the principle that anything which is not allowed explicitly is denied by default. That means in practice, that any access attempt, which may not be explicitly and entirely verified as allowed, is automatically denied. Privileges are admitted exclusively to an initially empty set of rights (opt-in instead of opt-out).  
−
* '''Separation of Privilege:''' Schutzmechanismen sollten soweit als möglich auf der Erfüllung mehrerer unabhängiger Bedingungen basieren.
+
* '''Separation of Privilege:''' All security and safe-guarding mechanisms must ensure that multiple conditions, which exist independently from each other, are fully checked and validated before granting any rights.
−
* '''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.
+
* '''Least Privileges:''' Any identity should only be granted with the least set of access rights possible in order to complete its assigned function or task. If any right needs to be added to perform extraordinary duties, the right may be granted when actually required and discarded after the completion of the non-standard task.
−
* '''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:''' Mechanisms securing and safe-guarding access to a resource may not add unnecessary complexity to the user or complicate the user to execute the granted right of accessing that resource unjustifiably.
−
* '''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:''' External systems, individuals, users, and objects should be always considered as insecure. A certain level of trust in external elements may only be granted, when explicitly supported by adequate security certifications, such as Common Criteria [CC 3.1]. Furthermore, it is imperative to limit and minimise the amount of mechanisms, systems, and objects, which are to be fully trusted required for the access control/management.
−
* '''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.
+
* '''Privacy Consideration:''' Any identity should only have access to exactly that fraction or portion of the data, which is immediately required in order to fulfil its current task in its current role/function.  
−
* '''Isolation:''' Die Zugriffskontrollfunktionen sollten von anderen Systemfunktionalitäten isoliert sein und besonders geschützt werden können.
+
* '''Isolation:''' All access control/management mechanisms should be isolated from other systems, operated independently, and must be specially secured.
  
 
<p>
 
<p>
Line 22: Line 22:
 
* 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]]
 
* 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.
 
* Benantar, Messaoud (Ed.): Access Control Systems. Springer. 2006.
 +
* Bishop, Matt. Computer Security: Art and Science. Boston, MA: Addison-Wesley, 2003
 
* 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.[[https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles.html]]
 
* ''Build Security In''. Website of the US Department of Homeland Security.[[https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles.html]]

Revision as of 06:03, 19 January 2009

IHE White Paper on Access Control

State of the Art

Principles of Secure Design

  • Economy of Mechanism: The used mechanism must be kept as simple as possible. It should also target a well-confined issue instead of trying to cover each and every eventuality.
  • Complete Mediation: Every access attempt must be explicitly safe-guarded through the access management mechanisms at all times. This also implies that there must be no possibility to avoid the access management (even for special roles/functions such as administrators) while accessing any resource.
  • Open Design: All algorithms and security mechanisms have to be openly available and fully check- and verifiable.
  • Least-Common Mechanism: Mechanisms, system states and objects, which are capable of explicitly or implicitly granting access rights, should not be shared between different users and/or applications. For each individual user or application, a different mechanism or an instantiation of the same mechanism should be used.
  • Fail-Safe Defaults: Addresses the principle that anything which is not allowed explicitly is denied by default. That means in practice, that any access attempt, which may not be explicitly and entirely verified as allowed, is automatically denied. Privileges are admitted exclusively to an initially empty set of rights (opt-in instead of opt-out).
  • Separation of Privilege: All security and safe-guarding mechanisms must ensure that multiple conditions, which exist independently from each other, are fully checked and validated before granting any rights.
  • Least Privileges: Any identity should only be granted with the least set of access rights possible in order to complete its assigned function or task. If any right needs to be added to perform extraordinary duties, the right may be granted when actually required and discarded after the completion of the non-standard task.
  • Psychological Acceptability: Mechanisms securing and safe-guarding access to a resource may not add unnecessary complexity to the user or complicate the user to execute the granted right of accessing that resource unjustifiably.
  • Reluctance to Trust: External systems, individuals, users, and objects should be always considered as insecure. A certain level of trust in external elements may only be granted, when explicitly supported by adequate security certifications, such as Common Criteria [CC 3.1]. Furthermore, it is imperative to limit and minimise the amount of mechanisms, systems, and objects, which are to be fully trusted required for the access control/management.
  • Privacy Consideration: Any identity should only have access to exactly that fraction or portion of the data, which is immediately required in order to fulfil its current task in its current role/function.
  • Isolation: All access control/management mechanisms should be isolated from other systems, operated independently, and must be specially secured.

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.
  • Bishop, Matt. Computer Security: Art and Science. Boston, MA: Addison-Wesley, 2003
  • 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, ...)

Alle in kommerziellen Systemen umgesetzten Implementierungen dieser Modelle zur Zugangskontrolle basieren auf der in Abbildung 3 skizzierten Trennung von Policy Enforcement und Policy Decision [RFC 2753, RFC 3198, ISO-10181-3]:

  • Eine Policy ist eine Zusammenstellung von Regeln, die das Verhalten eines Systems steuern. Die im Kontext dieses Papiers betrachteten Sicherheits¬policies legen fest, welche Subjekte unter welchen Bedingungen mit welchen Operationen auf welche Objekte zugreifen dürfen.
  • Ein Policy Decision Point (PDP) kann eine Autorisierungsanfrage bezüglich eines Ressourcenzugriffs entscheiden. Hierzu wählt der PDP die zu der Anfrage passende Policy aus, ermittelt ggf. benötigte weitere Informationen (Attribute) und wendet die Policy auf die Anfrage an. Das Ergebnis ist eine Policy Decision, in der kodiert ist, ob der angefragte Zugriff zulässig ist oder nicht.
  • Ein Policy Enforcement Point (PEP) fängt Ressourcenzugriffe ab, leitet die Prüfung der Zulässigkeit des Zugriffs an den PDP weiter und setzt die Zugangsentscheidung des PDP gegenüber dem Anfragenden durch.

WPAC PEP PDP v01.png

XACML [XACML 1.0] definiert zwei weitere Akteure; den für die Verwaltung von Policies zuständigen Policy Administration Point (PAP) und Policy Information Points (PIP), über die ein PDP weitere Attribute zu Objekten und Subjekten abrufen kann, die für die Entscheidung über die Zulässigkeit eines Ressourcenzugriffs benötigt werden.

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

Retrieved from "http://wiki.ihe.net/index.php?title=ACWP_State_of_the_Art&oldid=28861"