Schnittstellen: Security Levels und Authentifizierung

null Hinweis: Dieser Artikel ist "work in progress", die beschriebenen Sicherheitsfeatures für das DataGatewayServer sind auf unserer Entwicklungs-roadmap für Ende Q1/2024 und demnach noch nicht umgesetzt.

Grundsätzlich kann das HVS32 ohne Bedenken in Cloud-Umgebungen betrieben werden, sofern die Verbindung vom Vorsystem (ERP bzw. WMS, nachfolgend der Einfachheit halber nur ERP genannt) zum HVS32 in einem gemeinsamen, gesicherten, internen Netzwerk ist.
Wenn das Versandsystem HVS32 allerdings öffentlich erreichbar sein muss - also sich das Vorsystem (ERP/WMS) und das Versandsystem HVS32 nicht im gleichen Netzwerk (LAN, vLAN, vNET, private cloud) befinden - muss die Kommunikations-Verbindung der beiden Systeme abgesichert werden.
Dies impliziert, dass sowohl die Verbindung verschlüsselt als auch jede eingehende Verbindung authentifiziert und autorisiert werden muss.

Security Levels (Infrastruktur)

Zur Absicherung der Netzwerk-Brücke gibt es keine zu 100% perfekte oder sichere Lösung. Meist muss man sich für einen Kompromiss je nach Fall entscheiden. In der Infrastruktur können jedoch bereits diverse Security Levels implementiert werden, um die Sicherheit maßgeblich zu erhöhen.

LAN / vLAN / vNET / private cloud / VPN

Befinden sich die beiden Server in einem gemeinsamen Netzwerk, bzw. liegt eine gesicherte Netzwerk-Brücke via VPN zu Grunde, bietet dies grundlegend die beste Basis für eine sichere Datenkommunikation zwischen dem Vorsystem und dem Versandsystem HVS32.

S2S (Server-to-Server)

Bei einer ungesicherten Netzwerk-Brücke ist unbedingt darauf zu achten, dass die Kommunikation ausschließlich verschlüsselt und authentifiziert stattfindet.

Dead-End-Server

Da alle Verbindungen zum DGS (DataGatewayServer - Kommunikations-/Schnittstellen-Software) eingehend sind, kann als zusätzliche Sicherheitsmaßnahme der DGS auf einem separaten Server installiert werden, bei welchem alle ausgehenden Verbindungen via Firewall blockiert werden.

Authentifizierung

Authentifizierungs-Mechanismen können nur als "sicher" bezeichnet werden, wenn diese in Kombination mit anderen Sicherheits-Mechanismen wie HTTPS/SSL genutzt werden. Die Verschlüsselung ist mittels HTTPS unter Verwendung von TLSv1.2 oder TLSv1.3 (sofern vom Client unterstützt) möglich.
Die folgenden Authentifizierungs-Optionen beziehen sich ausschließlich auf die RESTv2 Schnittstelle

Basic Authentication

Die Basisauthentifizierung ist ein einfaches Authentifizierungsschema, welches in das HTTP-Protokoll integriert ist. Der Client sendet HTTP-Anfragen mit dem Autorisierungsheader, welcher Benutzername und Passwort enthält.

Der Benutzername und das Passwort muss im HTTP-Header mit dem Key Authorization übermittelt werden. Benutzername und Password müssen mit dem Prefix "Basic " und im Format "Benutzername:Passwort" als Base64 übergeben werden.

Beispiele:

Anfrage

In diesem Beispiel wird der Benutzer heidler mit dem Passwort Wolfschlugen verwendet.

POST <ENDPOINT> HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Basic aGVpZGxlcjpXb2xmc2NobHVnZW4=
Cache-Control: no-cache

Rückmeldung bei fehlgeschlagener Authentifizierung

Sollte die Authentifizierung aufgrund von falschem Benutzer / Passwort fehlschlagen, so wird der HTTP-Code 401 Unauthorized mit der Fehlermeldung "Unauthorized acces" im Body zurück gemeldet.

HTTP/1.1 401 Unauthorized
Www-authenticate: Basic realm="Restricted Area"
Date: Mon, 26 Feb 2024 09:00:44 GMT
Content-type: application/json
Content-length: 19
 
Unauthorized access

Digest Access Authentication

HTTP Digest Access Authentication ist ein Authentifizierungsmechanismus, der in das HTTP-Protokoll integriert ist und dazu dient, die Sicherheit von Webanwendungen zu erhöhen. Im Gegensatz zur einfachen Basisauthentifizierung überträgt Digest Access Authentication keine Benutzernamen und Passwörter im Klartext, sondern verwendet kryptografisch sichere Methoden.
Bei der Digest-Authentifizierung sendet der Client eine Anfrage an den Server, der daraufhin eine "Nonce" (eine einmalige Zufallszahl) zurückgibt. Der Client kombiniert diese Nonce mit Benutzername, Passwort, Anfrage-Methode und URI und erstellt einen "Digest" (Prüfzusammenstellung). Dieser Digest wird dann an den Server gesendet.
Der Server kann den Digest überprüfen, indem er denselben Algorithmus auf der Serverseite anwendet und die berechneten Werte vergleicht. Da der Digest mit Hilfe der Nonce und kryptografisch sicheren Techniken erstellt wird, schützt die Digest-Authentifizierung effektiv vor Angriffen wie Passwortdiebstahl und MitM-Angriffen.

API Keys

Die API-Key-Authentifizierung ist eine einfache Methode zur Sicherung von API-Zugriffen. Bei dieser Authentifizierungsmethode erhält der Benutzer einmalig einen eindeutigen API-Schlüssel (API-Key). Dieser Schlüssel wird dann bei jeder API-Anfrage im Header mit gesendet.
Der Server überprüft den empfangenen API-Schlüssel, um sicherzustellen, dass die Anfrage von einem autorisierten Benutzer oder einer autorisierten Anwendung stammt.
Der API-Schlüssel muss sicher aufbewahrt werden, um unbefugten Zugriff zu verhindern. Außerdem ist es wichtig, den API-Schlüssel regelmäßig zu zu aktualisieren, um die Sicherheit zu gewährleisten.

OAuth 2.0

Client Credentials

OAuth 2.0 Client Credentials ist eine Authentifizierungs-Methode im OAuth 2.0-Protokoll, die es einer Anwendung ermöglicht, sich beim Authorization Server (Authentifizierungsserver) zu authentifizieren. Dies ist besonders nützlich für den Zugriff von Anwendungen auf APIs ohne Benutzerbeteiligung und eignet sich gut für server-seitige Kommunikation zwischen Diensten.
Das ERP wird am Server registriert und erhält eine eindeutige Client-ID und ein Client Secret.
Inital wird dann von dem ERP eine HTTP-POST-Anfrage an den Authorization Server gesendet, welche die Client-Anmeldeinformationen (Client ID und Client Secret) beinhaltet. Im Response wird ein Access-Token und ein Refresh-Token zurück gemeldet.
Das ERP sendet nun für die Authentifizierung bei jeder Anfrage das Access-Token im Authorization Header der HTTP-Anfragen mit. Wenn das Access-Token abgelaufen ist, kann mit dem Refresh-Token ein neuer Access-Token angefragt werden. Im Falle einer mehrfachen Nutzung eines Refresh-Tokens werden automatisch alle Refresh-Tokens und Access-Tokens gesperrt.
Das Client Secret muss sicher aufbewahrt werden, um unbefugten Zugriff zu verhindern. Außerdem ist es wichtig, das Client Secret regelmäßig zu zu aktualisieren, um die Sicherheit weiter zu erhöhen.

Authorization Code

Diese Authentifizierungs-Methode ist ausschließlich über das Authentifzierungssystem IRIS Cloudsystem möglich.