Sonntag, 19. Juni 2022

Gedanken zur Referenz-Architektur des IIoT

Referenzarchitekturen bilden die Grundlage für Best Practices und die Wiederverwendung der Architekturmuster.  Das Industrial Internet Consortium (IIC) hat die Notwendigkeit der Referenzarchitektur erkannt und die Industrial Internet Reference Architecture (IIRA) veröffentlicht. Diese dreistufige Architekutr bietet verschiedene Standpunkte, die auf die verschiedenen Interessensgruppen ausgerichtet sind. IIC definiert die Referenzarchitektur als das Ergebnis der Anwendung von Architekturprinzipien auf eine Klasse von Systemen.

Dies dient als Orientierungshilfe , da die Architekten die gemeinsamen architektonischen Probleme analysieren und lösen. Der daraus resultierende IIRA stellt dann eine Vorlage für die Verwendung in der konkreten Architektur von industriellen Internet-Systemen dar.

IIoT-Projekte und Architekturlösungen können sehr komplex sein. Ein bewährter Ansatz zu Lösung komplexer Problemstellungen ist die Zerlegung in seine Subsysteme. 

Die IIRA ist eine auf Standards basierende offene Architektur für IIoT-Systeme. Die IIRA maximiert ihren Wert durch die breite Anwendbarkeit in der Branche , um die Interoperabilität voranzutreiben, anwendbare Technologien abzubilden und die Technologie - und Standardentwicklung zu lenken. Die Beschreibung und Darstellung der Architektur ist generisch und auf einen hohen Abstraktionsniveau, um die erforderliche breite Anwendbarkeit in der Industrie zu unterstützen.

Bei der Betrachtung komplexer Systeme, wie sie von IIoT-Systemen erwartet werden, sind viele Akteure beteiligt. Die Systemkomplexität erfordert einen Rahmen , um die Anliegen der Stakeholder zu ermitteln und in geeignete Kategorien einzuordnen. Ein solcher Rahmen ermöglicht eine systematische Bewertung solcher Systeme sowie die für die Planung und den Aufbau solcher Systeme erforderliche Lösung.


Vergleich von RAMI 4.0 mit IIRA

Die Referenzarchitekturen RAMI 4.0 und IIRA beschreiben den logischen Aufbau von Gesamtsystemen und Prozessen im Umfeld des IIoT. Der Fokus liegt dabei auf der einheitlichen Definition von Abstraktionsebenen und semantischen Zusammenhängen. Beide Architekturen berücksichtigen dabei verschiedene Aspekte und strukturieren des Gesamtsystem hierarchisch mit Schichten.

Es gibt darüber hinaus zwischen den beiden Architekturen in Teilbereichen vielfach Gemeinsamkeiten , aber von Grundsatz her unterscheiden sich beide Architekturen doch erheblich. In der Tabelle sind die wesentlichen Unterschiede zwischen den beiden Referenzarchitekturen aufgeführt.

Dienstag, 14. Juni 2022

Meine Gedanken zur Trinität - Authentisierung - Authentifizierung - Authorisierung

 Authentisierung;     „Wer bin ich?

 Authentifizierung:  Wer sind Sie?

Authorisierung;       Was darf ich?

Das Bezeichne ich als die Trinität, ich werde versuchen diese drei wichtigen Teile zu beschreiben.

Authentisierung

Unter Authentisierung versteht man den Nachweis der eigenen Identität. Dabei kann es sich um die Identität einer Person oder auch um die eines Computerprogramms handeln.

Im Allgemeinen kann man Authentisierungsmerkmalen in folgende drei Kategorien einteilen:

1. persönliches Wissen
2. persönlicher Besitz
3. biometrisches Merkmal

Unter 1 fallen die im Computerumfeld üblichen Passwörter , aber auch die Persönliche Identifikationsnummer (PIN) , Diese Merkmale haben mehrer Nachteile: So eignen sie sich beispielsweise nicht für sehr vergessliche Menschen. Außerdem können sie ausspioniert werden, auch ohne dass das Opfer es bemerkt.

Zu den Authentisierungsmerkmalen , die man besitzt (2) , zählen solche Dinge wie Fido Hardware Token , SSL - Zertifikate, JSON Web Token usw.
Der Nachteil der Merkmale der Kategorie 2 ist, dass man sie entwenden kann.

Die biometrischen Merkmale (3) gehören eigentlich auch zu den Dingen, die man besitzt. Sie haben aber den Vorteil, dass sie nicht so leicht zu entwenden sind. Zu diesen Merkmalen zählt man z.B. Aussehen,Stimme, Fingerabdruck, Augenhintergrund oder Unterschrift. Der Nachteil der biometrischen Merkmale liegt darin, dass Computer sie nicht besonders gut erkennen und verarbeiten können und dass die Authentisierung über diese Merkmale daher unter Umständen fehleranfällig ist.

Verwendung 

Alle drei Kategorien von Authentisierungsmerkmalen haben ihre Vor- und Nachteile . Idealerweise kombiniert man daher Merkmale verschiedener Kategorien, um die einzelnen Nachteile auszugleichen. Beispielsweise sind Geldgeschäfte mit einer EC-Karte (Merkmaltyp 2) nur durch zusätzliche Kenntnis einer PIN (Merkmaltyp 1) der durch leisten einer Unterschrift (Merkmaltyp 3) möglich. Auch die üblichen Token (Merkmaltyp 2) können nur in Kombination mit einer PIN (Merkmaltyp 1) benutzt werden.




Authentifizierung

Der Austausch der Informationen zwischen Benutzer und Webanwendung (Credentials der Session Token) erfolgt jeweils verschlüsselt und ist vor Manipulation geschützt. Jede Webanwendung welche eine vorherige Authentifizierung verlangt (Login) , hat auch ein Logout . 
Die Schritte sind im Einzelnen:

1. Der Benutzer möchte sich auf eine geschützte Webseite verbinden.
2. Die Anwendung stellt fest, dass für die geschützte Webseite eine Authentifizierung notwendig ist. Sie sendet dem Benutzer ein Formular zur Eingabe der Credentials.
3. Der Benutzer füllt das Formular aus (bei MFA können dies auch mehrere Formulare sein) und sendet es an die Anwendung.
4. Die Anwendung prüft gegen eine Verzeichnis, ob der Benutzer vorhanden , ob er für die entsprechenden Webseiten berechtigt ist (Authorisierung) und ob seine Credentials stimmen (Authentifizierung),
5. Ist soweit alles in Ordnung, wird dem Benutzer ein Session Token gesendet, welches für die aktuelle Session gültig ist.
6. Mithilfe des Session Token wird die Authentifizierung aufrechterhalten, ohne der Benutzer für jede Anfrage , welche er zur Webanwendung sendet, wieder authentifizieren muss.


Authorisierung


Die Autorisierung ist ein Synonym für die Zugriffskontrolle. Eng mit der Autorisierung verknüpft ist die Autditierbarkeit,mit deren Hilfe die Nutzung einer Ressource im Nachhinein überprüft werden kann. Eine Ressource kann im Kontext der Softwarearchitektur Daten meinen wie beispielsweise ein Dokument. Es kann sich aber auch um eine Geschäftsfunktion handeln, die geschützt werden soll. Es gibt hierfür zwei verschiedene Ansätze: den klassischen rollenbasierten Ansatz sowie die neuere , attributbasierte Ansätze ; den klassischen rollenbasierten Ansatz sowie die neuere , attributbasierte Authorisierung deren Vor- und Nachteile wie besprechen werden. Ein gängiges Dokument im Zusammenhang mit der Autorisierung ist das sogenannte Berechtigungskonzept , in dem sowohl die zu schützenden Ressourcen als auch die technische Strategie des Schutzes beschrieben stehen. Das Berechtigungskonzept heißt manchmal auch Rechte- und - Rollen-Konzept oder Access Control Policy. Die verschiedenen Konzepte und Prozesse rund um die Autorisierung stehen.

RBAC

Vorteile von RBAC

Der große Vorteil von RBAC ist der Determinismus; Man kann jederzeit leicht feststellen, wer auf welchen Ressourcen welche Berechtigungen besitzt. Dies macht das Berechtigungskonzept einfacher anpassbar und auch transparenter , da sich die Zusammenhänge leicht visualisierung lassen. Der Vorteil, die Auswirkungen von Änderungen im Vorfeld erkennen zu können, darf nicht unterschätzt werden. Daraus ergibt sich eine gute Auditierbarkeit des Systems auch für Business Owner. Für sie ist es einfach nachvollziehbar, welche Berechtigung er vergeben hat oder attestieren soll, da die Rollen klare Namen haben, die leicht verständlich sind. Generell gibt RBAC als einfacher als das ABAC-Modell, das wir weiter unten beschreiben.

Nachteile von RBAC

Der Nachteil von RBAC ist, dass die Rollen und Ressourcen bekannt sein müssen , um Entscheidungen im Kontext fällen zu können. Dies ist insbesondere für einen Administrator bei der Verwaltung schwierig , aber auch für einen Business Owner, der nur seine Ressourcen kennt, aber nicht die Rollen. Zudem kann die Anzahl der Rollen schnell explodieren, wenn zu feingranular berechtigt werden soll. Es besteht hier insbesondere das substanzielle Risiko dass Servicesemantik in das Rollenkonzept auf Geschäftsebene schwappt und dieses komplizierter als nötig macht.

Häufig wird bei RBAC die Verwaltung von Subdomänen delegiert. Die Delegation ist für Stellvertreterregelungen im IAM zwar sehr wichtig , aber das Rollenmodell läuft dann Gefahr , sich an der Delegatinsstruktur zu orientieren und nicht am Geschäft . Wenn viele Rollen im Einsatz sind, so muss auch eine große Anzahl von Delegationene in der Rollenverwaltung erstellt und gewartet werden. Dies bedeutet schlicht Overhead und kostet Geld. Es gibt zu RBAC diverse Zusätze , welche die Delegation erleichtern (PBDM, CRBAC).

ABAC

ABAC erlaubt den Zugriff auf Ressourcen über domänenspezufischer Attribute beispielsweise die Funktion im Unternehmen oder das Alter. Diese können dann für die Autorisierung verwendet werden. Wichtig bei diesem Konzept ist, dass nicht nur der Nutzer diese Attibute hat, sondern auch die Resource , auf die zugegriffen werden soll. Mittels einfacher mathematischer Funktionen kann ein ABAC-System dann entscheiden, ob der Zugriff erlaubt ist oder nicht. Bei diesem Verfahren kann etwa ein Dokument mit dem Attribut „Finance“ versehen werden. Hat ein Benutzer dann das Attribut „Controller“, greift eine Regel, die den Zugriff erlaubt.


Vorteile ABAC

Der größte Vorteil der attributbasierte Zugriffskontrolle ist, dass einfache Regeln definiert werden können. Diese können sehr feingranular und kontextbezogen sein, was bei RBAC schwierig ist. Zudem können die Regeln durch die Architektur auch Attribute von Ressourcen und Benutzern auswerten, die gar nicht im IDM-System vorhanden sind., sondern über den PIP provisioning werden. Es hat sich außerdem gezeigt, dass die Regeln wenig Pflege benötigen, da sie keine Struktur brauchen. Dies ist bei RBAC anders, da sich die Struktur durch die Rollen auch ändern können, wenn sich die Organisation verändert.

Nachteile von RBAC

ABAC kann auch zu einer Regelexplosion führen, ähnlich wie die Rollenexplosion beim RBAC. Hierdurch ist es auch schwierig , die Symmetrie herzustellen und so herauszufinden, welche Berechtigungen ein Benutzer hat. Hier muss gegebenenfalls eine große Anzahl von Regeln ausgeführt werden. Und dies in der exakt gleichen Reihenfolge , wie es für den Benutzer selbst erfolgt. In der Folge kann es unmöglich sein, Risiken bei Zugriffen festzustellen.
ABAC-Systeme können auch langsam in der Durchführung von Authorisationen sein, da Daten von mehreren anderen Services zur Berechnung benötigt werden. Da diese Berechnungen durch das ABAC-System nicht kontrolliert werden können, können sie auch nicht vorberechnet oder zwischengespeichert werden.


Neben der Authentisierung sind auch die Begriffe Authorisierung und Zugriffskontrolle (Access Control) wesentlich für jedes Sicherheitskonzept.

Beim Vorgang der Authorisierung wird festgelegt, mit welchen Berechtigung User auf Ressourcen im Netzwerk zugreifen dürfen.