Sicherheit

Nach der erfolgreichen Authentifizierung eines Benutzers gibt der IAM-Service Autorisierungsinformationen zurück. Diese Autorisierungsinformationen dienen dann als Nachweis des Nutzungsrechts des aufgerufenen Dienstes (s. Autorisierung). Die tatsächliche Identität und Authentifizierungsinformationen des Benutzers spielen ab hier keine Rolle mehr und sind deshalb nicht Teil der Autorisierungsinformationen.

In der Regel erfolgt die Authentifizierung von Benutzern über eine zentrale Komponente der Systemlandschaft, in welche das IT-System eingebettet ist, dem IAM-Service. Die Authentifizierung darf auch lokal, d.h. vom IT-System selbst, durchgeführt werden, falls es beispielsweise nicht in eine Systemlandschaft eingebettet ist.

Für die zentrale Authentifizierung wird in der IsyFact ein OAuth 2.0 konformer IAM-Service verwendet.

Im aufgerufenen IT-System wird die Anfrage – je nach Schutzbedarf und Funktionalität – autorisiert. Zwingend wird das Vorhandensein sowie die Authentizität und Gültigkeit der mit der Anfrage mitgegebenen Autorisierungsinformationen geprüft. In IsyFact ist eine feingranulare Autorisierung vorgesehen: Im Benutzerverzeichnis sind zu einem Benutzer die ihm zugewiesenen Rollen in der Systemlandschaft verknüpft und Bestandteil der Autorisierungsinformationen aus dem IAM-Service. Anhand dieser Rollen aus den Autorisierungsinformationen weist das IT-System einem Aufruf anwendungsspezifische Rechte zu und prüft diese gegen die für die Nutzung des angefragten Service benötigten Rechte. xref: Wie genau Rollen und Rechte spezifiziert werden, beschreibt das Konzept Security im Kapitel Rollen und Rechte.

Ein Sicherheitszertifikat ist ein digitales Dokument, das die Identität einer Entität (Service oder Website) bestätigt und zur Absicherung der Kommunikationspartner auf der Transportschicht eingesetzt werden kann. Für den Einsatz eines Sicherheitszertifikates wird eine Public Key Infrastructure (PKI) benötigt. Hierbei besitzt jede Entität ein Schlüsselpaar mit einem öffentlichen und privaten Schlüssel, um ein Entitätsbezogenes Zertifikat zu erstellen, das mittels des privaten Schlüssels signiert wird. Der Identitätsbeweis einer Entität erfolgt dann durch die Signatur-Validierung mit dem öffentlichen Schlüssel, der entweder zuvor schon zwischen den beteiligten Kommunikationspartner ausgetauscht wurde oder erst direkt vor der Validierung beim Besitzer des Zertifikats abgeholt wird. Für die konkrete Umsetzung der Absicherung der Kommunikationsstrecke sind die Vorgaben der jeweiligen Security, die gegebene Infrastruktur und die Tatsache, dass sich diese verändern, zu beachten (Vgl. Versionierung). Welche Maßnahmen für eine sichere Kommunikation realisiert werden, ist mit dem jeweiligen Partner, der einen Service bereitstellt, abzustimmen.

Für alle implementierten Authentifizierungs- und Verschlüsselungsverfahren werden jedoch die folgenden Festlegungen getroffen:

Der Service-Consumer soll die Verbindung zu einem externen Service verschlüsselt per HTTPS aufbauen. Der Aufbau einer transportverschlüsselten Verbindung via HTTPS basiert immer auf einer zertifikatsbasierten Authentifizierung der beteiligten Entitäten.

Bei einer verschlüsselten Verbindung weist sich der externe Service mit einem Server-Zertifikat aus. Zur Überprüfung ist ein TrustStore erforderlich, der vertrauenswürdige Zertifikate enthält. Diese dienen der Validierung eingehender Zertifikate und stellen die Integrität der Gegenstelle sicher.

Für höhere Sicherheit wird mTLS empfohlen. Dabei authentifiziert sich zusätzlich der Service-Consumer mit seinem Client-Zertifikat, das in einem KeyStore samt privatem Schlüssel (und ggf. Zertifikatskette) abgelegt ist (siehe Zertifikatsbasierte Client-Authentifizierung). Damit wird die eigene Identität nachgewiesen.

Ein PKCS#12-Keystore speichert die privaten Schlüssel und die zugehörigen Zertifikate der eigenen Komponente. Der TrustStore dagegen enthält ausschließlich die Zertifikate, die für die Authentifizierung der Kommunikationspartner dienen.