DE102019112485A1

DE102019112485A1 - Verfahren zum selektiven Ausführen eines Containers

Info

Publication number: DE102019112485A1
Application number: DE102019112485.9A
Authority: DE
Inventors: Michael Menth; Frederik Hauser; Mark Schmidt; Julian Rilli
Original assignee: Eberhard Karls Universitaet Tuebingen
Current assignee: Eberhard Karls Universitaet Tuebingen
Priority date: 2019-05-13
Filing date: 2019-05-13
Publication date: 2020-11-19
Also published as: EP3970337A1; WO2020229537A1; US20230006988A1

Abstract

Die Erfindung betrifft ein Verfahren zum selektiven Ausführen eines Containers, der eine Anwendung beinhaltet, wobei Benutzerauthentisierungsdaten durch eine Containermanagementkomponente erhalten und über einen Containerantragsteller an einen Autorisierungsserver weitergeleitet werden. Dieser sendet eine Autorisierungsantwort, basierend auf welcher entschieden wird, ob die Anwendung in dem Container ausgeführt werden darf.

Description

Die Erfindung betrifft ein Verfahren zum selektiven Ausführen eines Containers, der eine Anwendung beinhaltet.
Im Allgemeinen wird hierin das Problem betrachtet, Benutzern zu erlauben, spezielle Anwendungen auf verwalteten Hosts (Managed Hosts) auszuführen und ihnen Zugriff auf geschützte Netzwerkressourcen zu geben. Es ist im Stand der Technik zwar bekannt, Anwendungen in Containern auszuführen, um eine gewisse Trennung von anderen Anwendungen oder Betriebssystemkomponenten zu erreichen. Allerdings fehlt es bislang an weitergehenden Sicherheits- und Zugriffskontrollmechanismen.
Es ist deshalb eine Aufgabe der Erfindung, ein Verfahren zum selektiven Ausführen eines Containers, der eine Anwendung beinhaltet, bereitzustellen, welches im Vergleich zu bekannten Ausführungen alternativ oder verbessert ist. Dies wird erfindungsgemäß durch ein Verfahren nach Anspruch 1 erreicht. Vorteilhafte Ausgestaltungen können beispielsweise den Unteransprüchen entnommen werden. Der Inhalt der Ansprüche wird durch ausdrückliche Inbezugnahme zum Inhalt der Beschreibung gemacht.
Die Erfindung betrifft ein Verfahren zum selektiven Ausführen eines Containers, der eine Anwendung beinhaltet, wobei das Verfahren folgende Schritte aufweist:

- Empfangen von Benutzerauthentisierungsdaten durch eine Containermanagementkomponente,
- Weiterleiten der Benutzerauthentisierungsdaten an einen Containerantragsteller,
- Senden, durch den Containerantragsteller, einer Autorisierungsanforderung an einen Autorisierungsserver, wobei die Autorisierungsanforderung zumindest die Benutzerauthentisierungsdaten beinhaltet,
- Empfangen, durch den Containerantragsteller, einer Autorisierungsantwort von dem Autorisierungsserver, wobei die Autorisierungsantwort zumindest eine Freigabeinformation beinhaltet, welche entweder einen positiven oder einen negativen Wert annehmen kann,
- Weiterleiten der Autorisierungsantwort an die Containermanagementkomponente,
- Entscheiden, durch die Containermanagementkomponente, ob der Container auszuführen ist, wobei der Container auszuführen ist, wenn die Freigabeinformation einen positiven Wert hat, und wobei der Container nicht auszuführen ist, wenn die Freigabeinformation einen negativen Wert hat,
- nur wenn der Container auszuführen ist, Starten und Ausführen des Containers.

Das erfindungsgemäße Verfahren ermöglicht eine Autorisierung eines Benutzers durch einen Autorisierungsserver, welcher typischerweise zentral für eine Vielzahl von Benutzern zur Verfügung steht. Dadurch können unterschiedliche Benutzer zentral verwaltet werden, wobei Benutzer durch den Autorisierungsserver beispielsweise unter Zugriff auf Identity-Management-Server wie LDAP authentifiziert werden können. Es können Sicherheitsfunktionen wie insbesondere die Autorisierung oder Ausführungsverhinderung eines Containers bereitgestellt werden, welche bei Ausführungen nach dem Stand der Technik nicht möglich sind.
Eine Anwendung ist bei dem Verfahren typischerweise integraler Bestandteil eines Containers. Ein Container kann als Anwendung mit Abhängigkeiten betrachtet werden. Typischerweise wird dabei die Anwendung in dem Container ausgeführt, welcher eine geeignete Umgebung für die Anwendung darstellt. Andere Komponenten eines Betriebssystems sind dabei typischerweise durch den Container von der Anwendung abgekapselt. Beispielsweise kann der Container Schnittstellen bereitstellen, mittels welchen die Anwendung auf gewisse Ressourcen des Betriebssystems zugreifen kann. Damit können derartige Zugriffe gesteuert und bei fehlender Berechtigung unterbunden werden.
Benutzerauthentisierungsdaten können beispielsweise eine Kombination aus Benutzername und Passwort darstellen. Auch andere Ausführungen von Benutzerauthentisierungsdaten sind jedoch möglich. Die Benutzerauthentisierungsdaten können beispielsweise manuell über eine Benutzerschnittstelle eingegeben werden oder können aus einer automatischen oder halbautomatischen Benutzerauthentisierung stammen, beispielsweise mittels einer Karte oder einer Fingerabdruckerkennung, durch welche beispielsweise Benutzerauthentisierungsdaten aus einem hierfür angelegten Tresor oder sonstigem Speicher automatisiert ausgelesen werden können.
Die Containermanagementkomponente ist typischerweise eine Softwarekomponente, welche Verwaltungsaufgaben für den Container übernimmt und typischerweise außerhalb des Containers läuft. Sie kann den Container beispielsweise starten, anhalten und/oder ihm Ressourcen zuweisen. Der Containerantragsteller ist typischerweise eine Softwarekomponente, welche außerhalb des Containers läuft und mit externen Komponenten wie beispielsweise dem Autorisierungsserver direkt oder indirekt kommuniziert, um beispielsweise die beschriebenen Funktionalitäten auszuführen. Die Autorisierungsanforderung kann zusätzlich zu den Benutzerauthentisierungsdaten auch weitere Daten beinhalten, beispielsweise solche, welche weiter unten näher beschrieben werden. Die Autorisierungsantwort kann ebenfalls zusätzlich zu der Freigabeinformation noch weitere Informationen beinhalten, beispielsweise solche, welche weiter unten näher beschrieben werden. Die Freigabeinformation kann beispielsweise in Form eines Bits realisiert sein, welches zwei Zustände einnehmen kann, welche jeweils einem positiven bzw. negativen Wert zugeordnet sind. Das Starten des Containers mit der Anwendung kann insbesondere durch die Containermanagementkomponente veranlasst werden.
Es sei erwähnt, dass das Verfahren soweit bisher beschrieben grundsätzlich auf nur einer elektronischen Komponente wie beispielsweise einem Computer oder einem Host ausgeführt werden kann. Beispielsweise kann es auch in einem virtuellen Host ausgeführt werden, wie sie beispielsweise von großen Rechenzentren angeboten werden. Im Rahmen des Verfahrens wird dabei mit Komponenten kommuniziert, welche dazu extern sein können, beispielsweise mit dem Autorisierungsserver. Derartige Komponenten können sich beispielsweise im gleichen Netzwerk befinden und entsprechend über das Netzwerk miteinander kommunizieren. Nachfolgend werden auch Schritte beschrieben, welche auf externen Komponenten wie beispielsweise dem Autorisierungsserver durchzuführen sind. In diesem Fall sei verstanden, dass sich das Verfahren auf eine Anordnung bezieht, welche auch mehrere Komponenten beinhalten kann.
Gemäß einer bevorzugten Ausführung bestimmt der Autorisierungsserver die Freigabeinformation zumindest basierend auf den Benutzerauthentisierungsdaten. Dadurch kann sichergestellt werden, dass lediglich Benutzer, welche korrekte Benutzerauthentisierungsdaten haben, die Anwendung im Container ausführen können.
Beispielsweise kann der Autorisierungsserver die Benutzerauthentisierungsdaten mit einer Datenbank zugelassener Benutzer abgleichen.
Gemäß einer bevorzugten Ausführung enthält die Autorisierungsantwort zusätzlich eine Authentifizierungsinformation. Diese kann beispielsweise vom Autorisierungsserver oder einer damit zusammenarbeitenden Komponente erzeugt werden. Die Authentifizierungsinformation kann insbesondere für den Fall, dass die Freigabeinformation einen negativen Wert annimmt, der Benutzer also nicht autorisiert ist, eine Information darüber mitliefern, ob der Benutzer authentifiziert ist, also bekannt ist und sich mit einem korrekten Passwort ausgewiesen hat. Dies erlaubt es, dem Benutzer im Fall fehlender Autorisierung eine Rückmeldung über seine Authentifizierung zu geben. Beispielsweise können dadurch versehentliche Fehleingaben erkannt werden, da in diesem Fall ein Benutzer nicht authentifiziert wird. Dem Benutzer können auf diese Weise jedoch auch Rückmeldungen darüber gegeben werden, dass er zwar bekannt, jedoch nicht autorisiert ist, beispielsweise aufgrund fehlender Buchung oder sonstigen Berechtigungsproblemen.
Der Containerantragsteller kann insbesondere ein 802.1X Supplicant sein. Der Autorisierungsserver kann insbesondere ein 802.1X Autorisierungsserver sein. Die Containermanagementkomponente kann insbesondere ein Containermanagementdaemon sein. Dadurch kann auf bekannte Komponenten zur Authentifizierung und/oder Autorisierung von Benutzern zurückgegriffen werden, welche beispielsweise durch das bekannte IEEE 802.1X-System bereitgestellt werden. Eine Neuentwicklung solcher Komponenten oder ein zusätzliches Bereitstellen kann damit vorteilhafterweise vermieden werden. Insbesondere sind derartige Systeme häufig bereits in Einrichtungen wie Unternehmen oder Hochschulen vorhanden, um beispielsweise eine portbasierte Zugangskontrolle zu gewährleisten. Die Anpassung derartiger Systeme an das hierin beschriebene Verfahren erfordert typischerweise nur einen geringen Aufwand.
Gemäß einer bevorzugten Ausführung weist das Verfahren ferner folgenden Schritt auf:

- Erzeugen von Containerauthentisierungsdaten als Prüfsumme des Containers, wobei die Autorisierungsanforderung die Containerauthentisierungsdaten beinhaltet.

Dadurch kann zusätzlich zu den Benutzerauthentisierungsdaten, welche einen Benutzer eindeutig identifizieren sollen, auch der Container bzw. die Anwendung authentisiert werden. Dadurch kann beispielsweise verhindert werden, dass der Container oder die Anwendung ausgeführt werden, nachdem sie versehentlich oder bösartig verändert wurden. Die Prüfsumme kann insbesondere instantan bzw. ad hoc bei Ausführung des Verfahrens erstellt werden, so dass sie grundsätzlich aktuell ist und keine spätere Modifikation des Containers oder der Anwendung mehr erfolgen kann bzw. eine solche Modifikation erkannt werden würde und zu einer Verweigerung der Ausführung führen würde.
Bevorzugt bestimmt der Autorisierungsserver dabei die Freigabeinformation zumindest basierend auf den Containerauthentisierungsdaten. Dies kann insbesondere zusätzlich zu den Benutzerauthentisierungsdaten erfolgen. Der Autorisierungsserver könnte anhand der Containerauthentisierungsdaten, insbesondere anhand der Prüfsumme, eine eventuelle Modifikation des Containers oder der Anwendung erkennen und somit sicherstellen, dass die Anwendung nur dann ausgeführt wird, wenn sie nicht im Vergleich zu einer beabsichtigten Version verändert wurde. Insbesondere kann die Freigabeinformation den negativen Wert annehmen oder vom Autorisierungsserver auf den negativen Wert gesetzt werden, wenn der Autorisierungsserver anhand der Containerauthentisierungsdaten bestimmt, dass eine Veränderung der Anwendung oder des Containers vorliegt.
Die Autorisierungsantwort kann insbesondere eine Berechtigungsinformation beinhalten, wobei die Anwendung mit Rechten ausgeführt wird, welche basierend auf der Berechtigungsinformation festgelegt werden. Dies kann beispielsweise verwendet werden, um unterschiedlichen Benutzern, welche unterschiedliche Benutzerauthentisierungsdaten haben, unterschiedliche Rechte zuzuweisen. Beispielsweise kann bestimmten Benutzern der Zugriff auf bestimmte Ressourcen gewährt, anderen jedoch verwehrt werden. Die Berechtigungsinformation kann insbesondere vom Autorisierungsserver festgelegt werden, beispielsweise basierend auf den Benutzerauthentisierungsdaten und/oder den Containerauthentisierungsdaten.
Bevorzugt weist das Verfahren ferner folgenden Schritt auf:

- Zuweisen einer Netzwerkadresse zu dem Container.

Dadurch kann der Container eindeutig identifiziert werden, was es insbesondere ermöglicht, einen Datenstrom zu oder von diesem Container eindeutig von Datenströmen zu oder von anderen Containern oder anderen Komponenten abzugrenzen. Dies ermöglicht die Zuweisung von bestimmten Rechten für diesen Datenstrom. Bei der Netzwerkadresse kann es sich insbesondere um eine IPv6-Adresse handeln, wobei je nach Implementierung auch andere Adressen verwendet werden können.
Die Autorisierungsanforderung kann insbesondere über einen Containerauthentifikator zu dem Autorisierungsserver gesendet werden. Ebenso kann insbesondere die Autorisierungsantwort über den Containerauthentifikator von dem Autorisierungsserver empfangen werden. Der Containerauthentifikator ist dabei typischerweise eine zusätzliche Komponente, welche beispielsweise softwaremäßig und/oder hardwaremäßig von der Komponente, welche den Container ausführt, und dem Autorisierungsserver getrennt ist. Der Containerauthentifikator kann zusätzliche Aufgaben ausführen, welche weiter unten beispielhaft näher beschrieben werden. Insbesondere kann der Containerauthentifikator ein 802.1X Authenticator sein, was den Rückgriff auf ein bestehendes 802.1X-System vereinfacht und umfangreiche Neuentwicklungen vermeidet.
Bevorzugt weist das Verfahren ferner folgende Schritte auf:

- Erzeugen, durch den Containerauthentifikator, einer Netzwerkfreigabeinformation basierend auf der Autorisierungsanforderung und/oder der Autorisierungsantwort, und
- Senden, durch den Containerauthentifikator, der Netzwerkfreigabeinformation an eine Netzwerksteuerungskomponente,
- wobei die Netzwerksteuerungskomponente Datenverkehr zu und/oder von dem Container basierend auf der Netzwerkfreigabeinformation freigibt oder blockiert.

Dies ermöglicht eine Kontrolle des Datenverkehrs von und/oder zu dem Container, so dass auch der Datenverkehr abhängig von authentisierten und/oder autorisierten Benutzern gesteuert werden kann. Beispielsweise kann der Zugriff auf bestimmte Ressourcen oder bestimmte Arten von Datenverkehr für bestimmte Benutzer freigegeben, für andere jedoch gesperrt werden. Bei der Netzwerksteuerungskomponente kann es sich beispielsweise um eine Firewall oder einen SDN-Controller handeln, wobei die Netzwerksteuerungskomponente typischerweise softwaremäßig und/oder hardwaremäßig von den anderen bereits erwähnten und/oder nachfolgend erwähnten Komponenten unterscheidbar ist.
Der Containerauthentifikator kann bevorzugt die dem Container zugewiesene Netzwerkadresse an die Netzwerksteuerungskomponente senden. Die Netzwerksteuerungskomponente kann dann insbesondere den Datenverkehr basierend auf der Netzwerkadresse freigeben oder blockieren. Dies ist insbesondere sinnvoll, weil mittels der Netzwerkadresse der Container eindeutig identifiziert werden kann und somit Rechte für den Datenverkehr dieses Containers zuverlässig festgelegt und überwacht werden können.
Gemäß einer bevorzugten Ausführung ist der Container dazu konfiguriert, nur eine Anwendung auszuführen. Dies kann die Sicherheit weiter erhöhen, da jeder Container nur einer Anwendung zugeordnet ist und umgekehrt. Insbesondere können dadurch auch Container mit zugehörigen Anwendungen zentral bereitgestellt werden, wobei verhindert wird, dass Benutzer oder andere Personen zusätzliche Anwendungen in dem jeweiligen Container ausführen, welche eventuell gegen Richtlinien oder Sicherheitsbedürfnisse verstoßen.
Bevorzugt weist das Verfahren ferner folgenden Schritt auf:

- Herunterladen der Anwendung und/oder des Containers von einem Bereitstellungsserver.

Dadurch können Container und/oder zugehörige Anwendungen zentral bereitgestellt werden, beispielsweise innerhalb einer Einrichtung wie einem Unternehmen oder einer Bildungseinrichtung. Weiter bevorzugt ist der Container dazu konfiguriert, ausschließlich von dem Bereitstellungsserver heruntergeladene Anwendungen auszuführen. Dadurch kann sichergestellt werden, dass ausschließlich zugelassene Anwendungen ausgeführt werden, was Sicherheitsprobleme vermeiden kann. Insbesondere kann die Ausführung von ausschließlich zugelassenen Anwendungen und/oder Containern auch durch die weiter oben bereits erwähnte Prüfsumme und die dazugehörige Verarbeitung sichergestellt werden.
Bevorzugt sind die Autorisierungsanforderung und/oder die Autorisierungsantwort EAP-Nachrichten oder EAPoUDP-Nachrichten. Dabei kann auf das bekannte EAP-Protokoll zurückgegriffen werden, was zusätzlichen Verwaltungsaufwand oder Entwicklungsarbeit vermeidet. Derartige Nachrichten haben sich für die Ausführung des Verfahrens als vorteilhaft erwiesen.
Bei dem Container kann es sich insbesondere um einen Remote Application Container (RAC) handeln.
Die Erfindung betriff des Weiteren eine elektronische Einrichtung wie beispielsweise einen Computer, welche zum Ausführen eines erfindungsgemäßen Verfahrens konfiguriert ist. Die Erfindung betrifft außerdem ein nichtflüchtiges computerlesbares Speichermedium, welches Programmcode enthält, bei dessen Ausführung ein Prozessor ein erfindungsgemäßes Verfahren ausführt. Bezüglich des Verfahrens kann dabei jeweils auf alle hierin beschriebenen Ausführungen und Varianten zurückgegriffen werden.
Nachfolgend werden die hierin offenbarte Implementierung sowie Grundlagen hierzu mit Bezug auf die beigefügte Zeichnung beschrieben. Es sei erwähnt, dass die nachfolgende Beschreibung und die zugehörigen Figuren ähnlich sind zu einem Entwurf einer wissenschaftlichen Veröffentlichung, dessen Einreichung bei einem Journal oder einer Konferenz nach dem Anmeldetag dieser Anmeldung vorgesehen ist. Es zeigen:

1: Einen Vergleich von Systemvirtualisierung und Containervirtualisierung,
2: Eine Docker-Architektur,
3: Ein Port-basiertes Autorisierungsmodell von 802.1X,
4: Ein Kommunikationsbeispiel von Authentifizierung und Autorisierung basierend auf 802.1X,
5: Einen Vergleich von Protokollen,
6: Einen verwalteten Host, welcher eine RAC- und eine Betriebssystemanwendung ausführt,
7: Eine Anpassung von 802.1X für die Ausführung eines erfindungsgemäßen Verfahrens,
8: Ein Datenmodell,
9: Einen Datenfluss,
10: Einen weiteren Datenfluss,
11: Eine Testumgebung,
12: Eine Netzwerkkonfiguration von Docker in der Testumgebung,
13: Einen zweischrittigen Autorisierungsvorgang, und
14: Experimente zum Beurteilen der Kommunikation zwischen dem verwalteten Host, einem RAC und zwei Webservern.

Im Allgemeinen sei erwähnt, dass Container Virtualisierung auf Betriebssystemebene implementieren können. Sie stellen beispielsweise virtualisierte Betriebssystemumgebungen bereit, welche mit Bezug auf Hardwareressourcen und Sicherheit isoliert sind. Typischerweise teilen sie sich einen Betriebssystemkernel und können Bibliotheken beinhalten, welche benötigt werden, um eine oder mehrere beinhaltete Anwendungen auszuführen.
Container, welche im Rahmen des hierin beschriebenen Verfahrens verwendet werden können, können auch als xRAC bezeichnet werden. Dabei können beispielsweise nur spezielle Anwendungen mit ihren Abhängigkeiten und Konfigurationen in einem Container beinhaltet sein. Beispiele für Containerplattformen sind Docker, Kubernetes, systemd-nspawn, BSD Jails, Linux Containers, Windows Containers, Solaris Containers, Virtuozzo und rkt. Als besonders vorteilhaft für das hierin offenbarte Verfahren hat sich Docker erwiesen.
Virtualisierung erleichtert effiziente und flexible Verwendung von Hardwareressourcen, erhöht die Sicherheit durch Isolation und sorgt für Fehlertoleranz und Skalierbarkeit durch einfache Migrationsprozesse. Container haben im Vergleich zu kompletten Betriebssystemen zusätzlich die nachfolgend beschriebenen Vorteile. Aufgrund des geteilten Betriebssystems benötigen Container weniger CPU, Speicher und Festplattenressourcen. Containerbilder, auf Englisch als Container-Images bezeichnet, sind wesentlich kleiner, was eine Verteilung über zahlreiche Rezipienten erleichtert. Container vereinfachen eine Anwendungsverteilung. Anstatt einen Support für komplexe Kombinationen von Anwendungen, Abhängigkeiten und Benutzerkonfigurationen bereitstellen zu müssen, können Administratoren Container bereitstellen, welche vorab getestet sind. Außerdem haben Container keine Bootzeiten, was sie insbesondere für nur kurzzeitig benötigte Anwendungen vorteilhaft erscheinen lässt
1 vergleicht die Konzepte Containervirtualisierung und Systemvirtualisierung. Virtuelle Maschinen (VMs) in der Systemvirtualisierung werden typischerweise auf virtualisierten Hardwarekomponenten eines Hypervisor-Systems und emulierten Komponenten betrieben. Der Hypervisor kontrolliert Isolation mit Bezug auf Ressourcen und Sicherheit. VMs betreiben komplette Betriebssysteme, welche alle binären Komponenten und Datenbanken zum Ausführen von Anwendungen beinhalten.
Eine der am weitesten verbreiteten Containerplattformen ist derzeit Docker. 2 zeigt eine vereinfachte Übersicht der Dockerplattform und ihres Betriebs. Ein Host mit einem gemeinsamen Betriebssystem (OS = Operating System) beinhaltet den Docker CMD (Container Management Daemon), welcher Container und Containerbilder erzeugt und verwaltet. Containerbilder sind schreibgeschützte Vorlagen, welche Anwendungen mit ihren Abhängigkeiten wie beispielsweise Binärkomponenten, Datenbanken und Konfigurationen beinhalten. Container sind Laufzeitinstanzen, welche die schreibgeschützten Containerbilder durch eine beschreibbare Schicht erweitern. Deshalb können unterschiedliche Containerinstanzen ein gemeinsames Bild teilen. Dies führt zu Skalierbarkeit mit geringen Festplattenerfordernissen. Der Docker CMD wird durch den Docker Client über eine REST-Schnittstelle gesteuert. Der Docker Client kann in dem Host angeordnet sein, in welchem sich auch die Docker CMD befindet, oder auch in einem entfernten Host. Eine Docker-Befehlszeilenschnittstelle (CLI = Command Line Interface) ist ein Beispiel für eine Benutzersteuerung durch CLI-Aufrufe. Der Docker CMD kann mit Docker-Registern verbunden werden, die es Benutzern erlauben, Containerbilder hoch- oder herunterzuladen (push bzw. pull). Derartige Register sind entweder privat oder öffentlich verfügbar. Ein Docker Hub mit mehr als 100.000 Containerbildern ist ein Beispiel für das letztere. Gemeinsame Operationen sind build (1), pull (2) und run (3). Mit build können Benutzer individuelle Containerbilder erzeugen. Mit pull können Benutzer existierende Containerbilder von einem Docker-Register herunterladen, um Teil des lokalen Containerbildspeichers zu werden. Mit run können Containerbilder von dem lokalen Bildspeicher auf dem Hostsystem ausgeführt werden. Ein Docker-Register kann auch als Bereitstellungsserver bezeichnet werden.
Docker verwendet unterschiedliche Funktionen des Betriebssystemkernels zum Vorsehen von Isolation und Ressourcenimitierung, und unterstützt Speichertreiber wie beispielsweise AuFS, OverlayFS und ZFS, um ein Stacking eines Dateisystems zu ermöglichen. Ein Containerformat und eine Laufzeitumgebung von Docker wurden durch die Open Container Initiative als offene Industriestandards angenommen.
Containersicherheitsplattformen erweitern den Container Management Daemon (CMD) durch Sicherheitsfunktionen. Beispielsweise ermöglichen Twistlock und die Aqua Container Security-Plattform eine Laufzeitumgebung basierend auf Maschinenlernmechanismen zum permanenten Überwachen von Containern zum Detektieren von kompromittierendem Verhalten und spezielle Netzwerkfirewalls zum Filtern von Containerverkehr. Die Sysdig Secure-Plattform erlaubt das Formulieren von Servicevorgaben, zum Beispiel Vorgaben, welche auf Anwendungen, Containern, Hosts oder Netzwerkaktivitäten basieren. Die Plattform liefert Alarme und Aktionen basierend auf Verletzungen von Vorgaben, einer Ereignisprotokollierung und aktuellen Ereignissen. Der Atomicorp Secure Docker Kernel ist ein gehärteter Linux-Kernel, welcher sicherheitsrelevante Merkmale wie Ausbruchverhinderung, Speicherveränderungsverhinderung oder Verhinderung von direktem Benutzerzugriff durch den Kernel bereitstellt. Alle Plattformen fokussieren auf das Überwachen und Kontrollieren von möglicherweise nicht zuverlässigen Containern, welche auf einer geteilten Containerlaufzeitumgebung ausgeführt werden. Merkmale für Authentifizierung und Autorisierung (AA) von Benutzern, Containern und ihren Netzwerkflüssen sind jedoch nicht Teil dieser Plattformen.
Das Docker Authorization Framework ist seit der Version 1.10 Teil von Docker. Es erweitert den Docker CMD durch eine REST-Schnittstelle auf externe Plug-ins zur Autorisierung. Anfragen von dem Docker CMD, beispielsweise zum Starten eines Containers, werden auf ein Plug-in zur Autorisierung weitergeleitet, welches Mechanismen zum Entscheiden beinhaltet, ob die Anfrage erlaubt oder verwehrt wird. Das Docker Authorization Framework implementiert keine Sicherheitsfunktionen, aber liefert eine Basis zum Implementieren derartiger Sicherheitskonzepte. Das hierin offenbarte Verfahren erweitert dies noch.
Container liefern typischerweise Anwendungen oder Dienste ohne graphische Benutzerschnittstelle (GUI = Graphical User Interface), welche in einer Cloud oder auf einer Datencenter-Infrastruktur laufen. Beispiele sind Container, welche Web-Anwendungen beinhalten, mit ihren Bedürfnissen, zum Beispiel ein nginx-Webserver mit einer PHP-Laufzeit und MySQL-Datenbank.
Nachfolgend wird eine Beschreibung von 802.1X gegeben sowie eine Erläuterung, wie damit Authentifizierung und Autorisierung (AA) unterstützt werden kann. Ebenfalls wird EAPoUDP vorgestellt, was ein alternatives Protokoll zum Datenverkehr für AA in 802.1X darstellt. Es wird zusammengefasst, wie AA für Applikationen derzeit in der Praxis ausgeführt wird.
IEEE 802.1X führt portbasierte Netzwerkzugriffskontrolle in drahtgebunden Ethernet-Netzwerken ein. Trotzdem ist es heutzutage hauptsächlich von den drahtlosen 802.11-Netzwerken bekannt. Ein Beispiel ist eduroam, was einen Zusammenschluss von drahtlosen Campusnetzwerken von Universitäten darstellt. Teilnehmer können sich mit dem Internet verbinden, und zwar unabhängig davon, ob sie sich an ihrer Heimatuniversität oder an einer fremden Universität befinden.
3 zeigt die drei Komponenten von 802.1X und das Prinzip von portbasierter Netzwerkzugriffskontrolle. Ein Supplicant-System ist ein Netzwerk-Host, welcher den 802.1X Supplicant beinhaltet (802.1XS), ein Authentifikatorsystem beinhaltet einen 802.1X-Authentifikator (802.1XA) und steuert Netzwerkzugriff von Netzwerk-Hosts. Beispiele sind Zugriffsschalter bzw. Switches, welche Netzwerk-Hosts mit dem Hauptnetzwerk verbinden. Vor der Autorisierung kann das Supplicant-System den 802.1XA erreichen, jedoch nicht das Netzwerk. Ein 802.1XAS (Autorisierungsserver) ist vorliegend beispielsweise ein Authentifizierungs-, Autorisierungs- und Accounting-Server. Er speichert Authentisierungsdaten zum Überprüfen von Benutzeridentitäten und Autorisierungsdaten zum Erlauben von Zugriff auf das Netzwerk. Er authentisiert und/oder authentifiziert den 802.1XS und liefert Autorisierungsinformation zu dem 802.1XA.
802.1X erweitert das Extensible Authentication Protocol (EAP) und den Remote Authentication Dial-In User Service (RADIUS) zum Austauschen von AA-Daten. Beide sehen feste Anfrage- und Antwortschemata vor, und zwar zum Austauschen von AA-Daten. Das Diameter-Protokoll ist eine weniger verbreitete Alternative.
Authentisierungsdaten werden in Ethernet-Rahmen, auf Englisch Frames genannt, als EAP-over-LAN (EAPoLAN)-Kapselung zwischen dem 802.1XS und 802.1XA und als EAP-over-RADIUS (EAPoRADIUS) zwischen 802.1XA und 802.1X AS übertragen. 5 zeigt die Paketstruktur von EAPoL. Autorisierungsdaten werden in RADIUS-Rahmen zwischen dem 802.1XAS und 802.1XA übertragen.
Details von 802.1 X werden anhand eines vierschrittigen Vorgehens von AA gemäß 4 erklärt. In einem ersten Schritt (1) initialisiert 802.1XS die Authentisierung durch Senden einer EAPoL-Startnachricht zu dem 802.1XA. In einem zweiten Schritt frägt der 802.1XA die Identität von dem 802.1XS an (2a) und leitet sie zu dem 802.1XAS weiter (2b). RADIUS unterstützt große Domänen, welche mehrere hierarchisch organisierte RADIUS-Server beinhalten. Jede Identität ist mit einer Domäne verknüpft und dem RADIUS-Server dieser Domäne bekannt, so dass AA-Versuche in RADIUS-Infrastrukturen weitergeleitet werden können. In einem dritten Schritt (3) wird Authentifizierung durchgeführt, und zwar zwischen 802.1XS und 802.1XAS. Der Authentifikator entkapselt EAP-Pakete von EAPoL-Rahmen und kapselt sie wieder ein als EAPoRADIUS-Rahmen und umgekehrt. Die flexible Nachrichtenstruktur von EAP erlaubt die Verwendung von unterschiedlichen Authentifizierungsprozeduren. Einfache Ansätze tragen Identitätsinformation im Klartext oder einfache MD5-gehashte Passwörter, jedoch werden auch sicherere Authentifizierungsprozeduren wie EAP Tunneled TLS und EAP-TLS unterstützt. Der Authentifikator leitet nur EAP-Nachrichten durch. Deshalb müssen neue EAP-Typen nur auf dem 802.1XS und 802.1XAS implementiert werden, jedoch nicht in dem 802.1XA. In dem vierten Schritt kann der RADIUS-Server Autorisierungsdaten zu dem 802.1XA zurückliefern, und zwar nach erfolgreicher Authentisierung und Authentifizierung. Dies kann grob granular sein, zum Beispiel eine binäre Zugriffsentscheidung, ob das Supplicant-System Zugriff bekommt oder nicht, oder fein granular, zum Beispiel VLAN-Tags, welche für erwarteten Benutzerverkehr oder Filterregeln gesetzt werden, welche durch den Authentifikator angewendet werden. Der Authentifikator wendet die Autorisierungsdaten auf den bestimmten physikalischen Port des Switches an, zum Beispiel setzt er einen VLAN-Tag. Danach bestätigt der Authentifikator erfolgreiches AA zu dem Supplicant mit einer EAP-Erfolgsnachricht (4b).
EAPoUDP ist eine Variation von EAP, welche die Übertragung von EAP-Daten über UDP und IP erlaubt. 5 zeigt die zugehörige Paketstruktur im Vergleich mit EAPoL.
Im Gegensatz zu EAPoL kann EAPoUDP verwendet werden zum Authentifizieren von mehreren Anwendungen, welche auf einem Netzwerk-Host laufen. Auch können UDP-Pakete über jede Verbindungstechnologie übertragen werden, oder können sogar innerhalb von Multidomain-Netzwerken geroutet werden. EAPoUDP wurde als Internet-Draft eingeführt, welcher ohne Standardisierung in der PANA Working Group bei IETF im Jahr 2002 ausgelaufen ist.
802.1X ist spezialisiert auf portbasierte Zugriffskontrolle für Netzwerk-Hosts. In der Praxis ist AA für Anwendungen implementiert als Teil der Anwendungen oder unter Verwendung des Kerberos-AA-Protokolls.
Die meisten Netzwerkanwendungen implementieren eine Art von AA-Mechanismus. Beispiele sind Log-in-Formulare in einem Startbildschirm, wo Benutzer dazu aufgefordert werden, gültige Zugriffsinformationen einzugeben, um mit der Benutzung einer Anwendung zu beginnen. Andere Beispiele sind Client-Zertifikate, welche zusammen mit TLS verwendet werden, und eine Infrastruktur mit öffentlichem Schlüssel. Jedoch haben AA-Funktionalitäten, welche Teil der Anwendung sind, einen Einfluss, welcher auf die Client- und Serverseite der Netzwerkanwendung beschränkt ist. Weder der Start der Anwendung noch die Netzwerkinfrastruktur dazwischen kann gesteuert werden.
Kerberos ist ein Netzwerkauthentifizierungsprotokoll, welches unterschiedliche Authentifizierung für Clients und Server über ein unsicheres Netzwerk ermöglicht. Clients sind beispielsweise komplette Hosts, Benutzer oder Anwendungen; Server repräsentieren Hosts, welche bestimmte Netzwerkanwendungen bieten. Kerberos adaptiert Benutzertickets für die Authentifizierung von verschiedenen Netzwerkanwendungen. Kerberos muss durch Anwendungen auf Client- und Serverseite implementiert werden, was die Anwendung für ältere Anwendungen verhindert, welche nicht verwendet werden können.
FlowNAC fügt fein granulare SDN-Netzwerkzugriffskontrollsysteme unter Verwendung von 802.1X für AA von Anwendungen auf Netzwerk-Hosts ein. Dies ermöglicht unterschiedliche Versionen von AA für unterschiedliche Anwendungen auf einem Netzwerk-Host. Zum Ermöglichen von unterschiedlichem AA für unterschiedliche Anwendungen auf einem Netzwerk-Host werden EAPoL-over-EAPoLAN-Verkapselungen eingeführt. Wie in 5 in einem Vergleich von Datenpaketen für EAPoL, EAPoUDP und EAPoL in EAPoL dargestellt, fügt FlowNAC eine andere Variation von EAPoL ein. Ein EAPoL-in-EAPoL-Paketfeld identifiziert bis zu 64.000 unterschiedliche EAP-Prozesse, welche als verkapselte EAP-Nutzlast übertragen werden. Jedoch erfordert diese Abweichung vom alten 802.1X wesentliche Veränderungen von 802.1XS und 802.1XA. Das 802.1XS ist ein Teil eines Kernels eines Betriebssystems, und der 802.1XA ist Teil von Netzwerkswitches, so dass nur Open Source-Betriebssysteme und -Firmwares Modifikationen erlauben. Trotzdem ist es schwierig, die Modifikation in neuen Versionen des Betriebssystemkernels oder der Firmwarebilder auszuführen. Es wird vorliegend auf EAPoL gesetzt, d.h. AA-Datentransfer wird auf die Ethernet-Verbindung eingeschränkt. EAPoUDP kann grundsätzlich ebenfalls verwendet werden. Ebenso fügt FlowNAC weder IP-Adressen für Anwendungen ein noch wird der Start von Anwendungen durch AA eingeschränkt.
Nachfolgend werden RACs (Restricted Application Containers) und das hierin beschriebene Verfahren (xRAC) beschrieben. Außerdem wird der Betrieb der Steuerungskomponenten im Detail erklärt.
Restricted Application Containers (RACs) sind im Allgemeinen ausführbare Containerbilder (container images), welche eine einzige Anwendung, deren Abhängigkeiten und Konfigurationsdaten wie Programmeinstellungen und Softwarelizenzinformationen beinhalten. Wie aus 6 hervorgeht, werden RACs in einer Containerlaufzeitumgebung parallel zu betriebssystemeigenen Anwendungen ausgeführt. Der CMD steuert die Ausführung von RACs und liefert eine Schnittstelle für Benutzer zum Erzeugen, Löschen und Starten oder zum Anhalten von RACs. Jeder RAC hat eine eigene IPv6-Adresse, so dass der Verkehr in dem Netzwerk einfach identifiziert werden kann. RAC-Bilder werden beispielsweise durch Netzwerkadministratoren erzeugt und über RAC-Register verteilt. Sie werden beispielsweise entweder von derartigen Registern durch Benutzer heruntergeladen oder werden automatisch durch verwaltete Hosts synchronisiert.
In 7 ist ein Benutzer zu sehen, welcher auf einen Containermanagementdaemon (CMD) zugreifen kann. Der CMD befindet sich in einem verwalteten Host (managed host), in welchem sich des Weiteren ein Remote Application Container (RAC) sowie ein Containerantragsteller in Form eines 802.1XCS (Container Supplicant) befinden. Hierbei handelt es sich um entsprechende Softwaremodule. Zur Autorisierung ist ein dazu externer Autorisierungsserver 802.1XAS vorhanden, wobei dieser Benutzerdaten und gegebenenfalls auch Daten über zugelassene Anwendungen und/oder Container sowie zugehörige Prüfsummen speichert. Zwischen dem verwalteten Host bzw. dem darin enthaltenen 802.1XCS und dem Autorisierungsserver ist ein Containerauthentifikator vorhanden, welcher mit 802.1XCA bezeichnet ist. Des Weiteren ist eine Firewall FW vorhanden, welche Netzwerkverkehr von und zu dem verwalteten Host kontrolliert und steuert. Damit wird ein Zugriff insbesondere auf einen geschützten Server gesteuert, welcher untenstehend eingezeichnet ist.
xRAC sieht beispielsweise eine Ausführungs- und Zugriffskontrolle für RACs auf verwalteten Hosts vor. Ein RAC wird dabei vorzugsweise authentifiziert und autorisiert, und zwar bevor eine Ausführung erfolgt. 7 zeigt einen AA-Vorgang für RACs mit 802.1X. Zuerst versucht ein Benutzer, ein RAC über den CMD zu starten (1), und der CMD weist den 802.1XCS für die AA an (2). Nach der erfolgreichen Authentifizierung (3) und Autorisierung antwortet der 802.1XAS mit Autorisierungsdaten bzw. einer Autorisierungsantwort über den 802.1XCA (4) zu dem 802.1XCS (4a). Der 802.1XCS informiert den CMD darüber, dass der RAC gestartet werden soll (4b). Zusätzlich informiert der 802.1XCA Netzwerksteuerungselemente über den autorisierten RAC. In diesem Beispiel wird die Firewall FW konfiguriert, um einen Zugriff auf einen geschützten Server zu erlauben (4c). Andere Beispiele sind SDN-Controller, welche SDN-Switches programmieren. Nunmehr kommunizieren der autorisierte RAC, jedoch nicht der verwaltete Host oder andere RACs mit dem geschützten Server (5).
AA für RACs führt zwei zusätzliche Vorteile im Vergleich zu bekannter Anwendungsbereitstellung und Netzwerksicherheit ein. Zum einen schränkt AA für RACs eine RAC-Ausführung auf verwalteten Hosts auf vordefinierte RAC-Bilder und zugelassene Benutzer ein. Dies erlaubt Netzwerkbetreibern sicherzustellen, dass nur aktuelle und nicht modifizierte RAC-Bilder ausgeführt werden können. Dies verbessert Computer- und Netzwerksicherheit, da nur valide RAC-Bilder auf den verwalteten Hosts ausgeführt werden können. Zusätzlich sind Netzwerkbetreiber dazu in der Lage, RAC-Bilder auf verwaltete Hosts vorab zu verteilen, zum Beispiel durch Synchronisieren ihres Satzes von RAC-Bildern mit einer internen RAC-Ablage im Hintergrund. Benutzer haben dadurch alle verfügbaren RAC-Bilder auf verwalteten Hosts im Zugriff, sind jedoch nur dazu in der Lage, diese zu starten, nachdem sie durch AA autorisiert wurden. Schließlich hat jeder RAC eine global einheitliche IPv6-Adresse, welche verwendet werden kann, um Datenverkehr zu und von einem bestimmten RAC zu identifizieren. RAC-Autorisierungsdaten auf dem 802.1XAS beinhalten Informationen darüber, wie der Datenverkehr des RACs durch Netzwerkelemente gesteuert werden soll.
Insgesamt kann somit beispielsweise folgender Verfahrensablauf realisiert werden.
Zunächst werden von dem Containermanagementdaemon CMD als Containermanagementkomponente Benutzerauthentisierungsdaten von dem Benutzer empfangen. Die Benutzerauthentisierungsdaten werden an den Containerantragsteller 802.1XCS weitergeleitet. Dieser erzeugt eine Autorisierungsanforderung, welche die Benutzerauthentisierungsdaten beinhaltet. In einer bevorzugten Ausführung erzeugt er ferner eine Prüfsumme des Containers, wobei die Prüfsumme Containerauthentisierungsdaten darstellt, welche auch mit in die Autorisierungsanforderung aufgenommen werden.
Die Autorisierungsanforderung wird dann über den Containerauthentifikator 802.1XCA zu dem Autorisierungsserver 802.1XAS übertragen. Dieser gleicht sowohl die Benutzerauthentisierungsdaten wie auch die Prüfsumme mit entsprechenden Datenbanken ab. Dies wird als Authentifizierung bezeichnet. Kommt er zu einem positiven Ergebnis, d.h. die Benutzerauthentisierungsdaten sind einem berechtigten Benutzer zugeordnet und die Prüfsumme zeigt an, dass Container und/oder Anwendung nicht verändert wurden, erzeugt der Autorisierungsserver eine Autorisierungsantwort mit einer positiven Freigabeinformation und gegebenenfalls auch mit Berechtigungsinformationen. Die Autorisierungsantwort wird über den Containerauthentifikator 802.1XCA zu dem Containerantragsteller 802.1XCS zurückgesendet. Die Autorisierungsantwort wird dann an den Containermanagementdaemon CMD weitergeleitet, welcher basierend darauf ermittelt, ob eine Anwendung ausgeführt werden darf, und gegebenenfalls mit welchen Berechtigungen. Der Containermanagementdaemon startet bei entsprechend positiver Antwort die Anwendung und weist ihr die entsprechenden Berechtigungen zu. Sollte der Autorisierungsserver jedoch den Benutzer nicht authentifizieren können, oder sollte er den Benutzer zwar authentifizieren können, jedoch eine fehlende Berechtigung feststellen, so erzeugt der Autorisierungsserver eine Autorisierungsantwort mit einer negativen Freigabeinformation und sendet diese entsprechend zurück.
Des Weiteren wird nach erfolgtem Start der Anwendung dem Container RAC eine eindeutige Netzwerkadresse, beispielsweise eine IPv6-Adresse, zugewiesen. Diese Adresse wird der Firewall FW mitgeteilt. Des Weiteren teilt der Containerauthentifikator 802.1XCA der Firewall FW Netzwerkfreigabeinformationen bezüglich des Containers RAC mit. Die Firewall FW steuert dann Datenverkehr von und zu dem Container RAC in Abhängigkeit von den Netzwerkfreigabeinformationen und identifiziert den Container dabei anhand seiner IPv6-Adresse. Dadurch kann beispielsweise ein Zugriff auf den geschützten Server kontrolliert werden.
Die Autorisierungsanforderung von dem Containerantragsteller 802.1XCS zu dem Autorisierungsserver 802.1XAS beinhaltet somit insbesondere Benutzerauthentisierungsdaten (UAND) und Containerauthentisierungsdaten (CAND). Der Autorisierungsserver authentifiziert den Benutzer und verifiziert die Integrität des RAC-Bilds. Wenn das Bild valide ist und der Benutzer authentifiziert ist und wenn der Benutzer die Erlaubnis zum Ausführen des RAC hat, antwortet der Autorisierungsserver 802.1 X AS dem Containerauthentifikator 802.1XCA mit Autorisierungsdaten bzw. einer Autorisierungsantwort. Zum Ausführen der Entscheidung kann beispielsweise ein neues Datenmodell verwendet werden, welches in 8 dargestellt ist. Es weist beispielhaft Benutzerprofile (1), RAC-Profile (2) und Gruppen (3) auf, welche definieren, ob ein bestimmter Benutzer dazu ermächtigt ist, einen bestimmten RAC auszuführen. Benutzerprofile (1) beinhalten Benutzerauthentisierungsdaten (UAND), welche verwendet werden zum Authentisieren des Benutzers. Beispiele sind Zugangsdaten, beispielsweise Benutzername und Passwörter. RAC-Profile (2) beinhalten Containerauthentisierungsdaten (CAND) und Containerautorisierungsdaten (CAZD). Das erste wird verwendet zum Verifizieren der Integrität des RAC durch Berechnen der kryptographischen Hash-Funktion über das RAC-Bild. CAZD beinhaltet alle Berechtigungen eines RAC, zum Beispiel ob es durch den anfragenden Benutzer gestartet werden kann und ob es berechtigt ist, Netzwerkressourcen zu benutzen. Dies kann auch als Autorisierungsantwort bezeichnet werden. In dem dargestellten Beispiel ist es dem RAC erlaubt, spezifizierte Netzwerkressourcen zu benutzen. Die AA-Daten des beschriebenen Modells werden in dem Autorisierungsserver 802.1XAS gespeichert. Das Datenmodell ist ein Beispiel, welches einfach zur Unterstützung anderer Anforderungen erweitert werden kann. Der Containerantragsteller 802.1XCS authentifiziert RACs mit dem Autorisierungsserver 802.1XAS über den Containerauthentifikator 802.1XCA. Er sendet UAND und CAND zu dem Autorisierungsserver 802.1XAS und empfängt CAZD von dem Containerauthentifikator 802.1XCA.
9 illustriert den Vorgang für AA aus der Perspektive des Containerantragstellers 802.1XCS. Dieser läuft auf dem verwalteten Host, bietet eine Schnittstelle für den CMD und ist mit der IP-Adresse oder URL des Containerauthentifikators 802.1XCA konfiguriert, so dass er AA initiieren kann. In (1) frägt der Benutzer beim CMD an, einen bestimmten RAC auf dem verwalteten Host zu starten. Die Anfrage beinhaltet UAND. Der CMD frägt bei dem Containerantragsteller 802.1XCS an, ob dies dem Benutzer gestattet werden kann (2). Die Anfrage beinhaltet UAND und CAND, welche durch den CMD erhalten werden. Der Containerantragsteller 802.1XCS initiiert AA durch Etablieren einer EAPoUDP-Sitzung mit dem Containerauthentifikator 802.1XCA. Danach wird eine Autorisierung mit dem Autorisierungsserver 802.1XAS über den Containerauthentifikator 802.1XCA durchgeführt (3). Beispielsweise kann in älteren Ausführungen von 802.1X eine Backend-Authentifizierung über EAPoRADIUS durchgeführt werden, wobei Frontend-Autorisierung durch EAPoUDP ausgeführt wird. Im Fall einer erfolgreichen Autorisierung empfängt der Containerantragsteller 802.1X CS CAZD von dem Containerauthentifikator 802.1XCA (4). Dann erlaubt der Containerantragsteller 802.1XCS dem CMD, das RAC zu starten (5).
Der Containerauthentifikator 802.1XCA leitet AA-Daten zwischen dem Containerantragsteller 802.1XCS und dem Autorisierungsserver 802.1XAS weiter. Ferner informiert er Netzwerksteuerungselemente über autorisierte RACs.
In Schritt (1) von 10 werden zur Authentifizierung Authentisierungsdaten über EAP zwischen dem Containerantragsteller 802.1XCS und dem Autorisierungsserver 802.1X AS transportiert. Zwischen dem Containerantragsteller 802.1XCS und dem Containerauthentifikator 802.1XCA werden die EAP-Daten über UDP übertragen (EAPoUDP) und zwischen dem Containerauthentifikator 802.1XCA und dem Autorisierungsserver 802.1XAS werden sie über RADIUS übertragen. Somit ist es eine Aufgabe des Containerauthentifikators 802.1XCA, den Tunnel für EAP-Daten zu modifizieren. Ferner gibt nach der erfolgreichen Authentifizierung der Autorisierungsserver 802.1XAS CAZD über RADIUS zu dem Containerauthentifikator 802.1XCA zurück (2), welcher dann den Containerantragsteller 802.1XCS über die erfolgreiche Autorisierung informiert (3a). Während der konventionelle 802.1XA lediglich Ports auf einem Switch für autorisierte Geräte öffnet, informiert der Containerauthentifikator 802.1XCA allgemeine Netzwerksteuerungselemente über autorisierte RACs. Diese können Ports auf einem Switch, Firewalls (3b) oder SDN-Controller (3c) sein. Der Firewall wird dann derart programmiert, dass er allen ausgehenden Verkehr mit der IP-Adresse des RACs durchlässt und der SDN-Controller weist SDN-Switches an, jeglichen Verkehr mit der IP-Adresse des RACs durchzulassen, sofern entsprechende Berechtigungen erteilt wurden. Spezifischere Flussdeskriptoren werden typischerweise nicht benötigt, können aber implementiert werden.
Nachfolgend werden unterschiedliche Einsatzszenarien der hier offenbarten bzw. erfindungsgemäßen Vorgehensweise beschrieben.
Zunächst wird auf einem Webbrowser in Hochsicherheitsumgebungen eingegangen. Dies kann beispielsweise für Forschungseinrichtungen, staatliche Institutionen oder Krankenhäuser relevant sein, welche mit hochsensitiven Daten arbeiten und ihr internes Netzwerk vom Internet abschirmen müssen. Jedoch werden trotzdem Webbrowser für unterschiedliche Aktivitäten benötigt. Es wird vorgeschlagen, Webbrowser als RACs auf verwalteten Hosts einzusetzen. Die Isolation von RACs verhindert, dass bösartige Benutzer den Internetzugriff missbrauchen, um interne Informationen nach außen zu bringen oder das interne Netzwerk durch infektiöse Downloads kontaminieren. Die Netzwerkflusskontrolle von RACs stellt sicher, dass nur der Webbrowser das Internet erreichen kann. Wenn der Datenverkehr des RACs verschlüsselt ist, zum Beispiel bei DNS-Anfragen und Websitedaten, können Netzwerksteuerungselemente immer noch eine Paketfilterung basierend auf der IP-Adresse des RAC durchführen.
Des Weiteren wird auf Anwendungen eingegangen, welche mit vertraulichen Daten arbeiten, zum Beispiel betreffend Forschungsaktivitäten, medizinische Dokumentation oder öffentliche Stellen. Dabei muss häufig auf vertrauliche Daten von Servern zugegriffen werden. Wenn derartige Anwendungen als RACs auf verwalteten Hosts wie hierin beschrieben bereitgestellt werden, können nur legitime Benutzer auf diese Server zugreifen. Das Isolationsmerkmal des RACs verhindert, dass entfernte Hacker auf den Server zugreifen. Normalerweise bekommen sie einen Systemzugriff durch Gateways, welche durch einen Virus oder ein Trojanisches Pferd bereitgestellt werden, wobei derartige Schadsoftware üblicherweise über Browserdownloads oder E-Mail-Anhänge eingefangen wird, was mit RACs nicht möglich ist. Ferner können bösartige Benutzer von legitimen Anwendungen Hacker-Tools verwenden, um einen Zugriff zu dem Server zu erhalten und um Informationen davon preiszugeben, was nicht möglich ist in der digitalen Domäne mit einer isolierten Anwendung. Die Isolation von RACs verhindert, dass bösartige Benutzer oder Anwendungen den Server angreifen. Die Netzwerkflusskontrolle stellt sicher, dass der Server nur durch legitime RACs und Benutzer erreicht werden kann, jedoch nicht durch andere RACs oder den verwalteten Host selbst.
xRAC erweitert die Vorteile, welche allgemein von Virtualisierung und Containervirtualisierung bekannt sind und weiter oben beschrieben wurden. Zusätzlich kann xRAC garantieren, dass nur valide Container auf verwalteten Hosts ausgeführt werden, und dass sie nur durch legitime Benutzer verwendet werden können. Somit führt xRAC AA (Authentifizierung und Autorisierung) für Anwendungen ohne den Bedarf zur Modifizierung derselben aus, was ein besonderer Vorteil für ältere Anwendungen ist. Ferner kann der Containerauthentifikator 802.1XCA Netzwerksteuerungselemente derart konfigurieren, dass autorisierte RACs Zugriff auf geschützte Netzwerkressourcen haben. RACs ermöglichen diese Steuerung, weil jeglicher Netzwerkverkehr eines RAC durch eine einzige IPv6-Adresse identifiziert wird. Dies ist ein besonderer Vorteil, da in heutigen Netzwerken keine Information über legitimen Fluss besteht und zahlreiche Anwendungsflüsse die gleiche IP-Adresse haben können. Anwendungen können sogar aufgrund von Verschlüsselung unsichtbar sein. Somit wird durch xRAC eine Lösung für das gravierende Problem der Steuerung von legitimem Verkehr gegeben. xRAC ist dabei flexibel, da es softwaredefinierte Netzwerkzugriffssteuerung durch Interaktion mit anderen Netzwerksteuerungselementen implementiert. Insbesondere ist es nicht abhängig von spezifischen Technologien oder darauf eingeschränkt.
Nachfolgend wird ein Prototyp von Implementierungen von xRAC diskutiert.
11 zeigt eine Testumgebung. Der verwaltete Host führt RACs aus. Ein SDN-Switch verbindet den verwalteten Host, einen geschützten Webserver und einen öffentlichen Webserver und ist durch einen SDN-Controller gesteuert. Auf dem SDN-Controller läuft der 802.1XCA als SDN-Anwendung, welche mit einem 802.1XAS kommuniziert.
Dabei kann eine verschachtelte Virtualisierung eingesetzt werden, d.h. eine virtuelle Maschine (VM) verkapselt alle Teile der Testumgebung einschließlich des verwalteten Hosts. Dieser Ansatz erlaubt es, dass die gesamte Testumgebung auf andere Hardwareplattformen migriert wird. Vorliegend wurde für einen Test KVM-Hypervisor mit QEMU für hardwareassistierte Virtualisierung und libvirt für die Orchestrierung eingesetzt. Der verwaltete Host, beide Webserver und ein RADIUS-Server laufen als verschachtelte VMs mit Ubuntu 17.04. Ein Open vSwitch dient als SDN-Switch, welcher durch einen Ryu-SDN-Controller gesteuert wird.
Es wird vorliegend Docker in Version 17.05 als Containervirtualisierungsplattform zum Implementieren von RACs verwendet. Der Docker-CMD wird derart konfiguriert, dass jedes RAC eine weltweit eindeutige IPv6-Adresse bekommt, welche durch andere Netzwerkhosts erreichbar ist. 12 zeigt die angewandte Netzwerkkonfiguration. Es ist voreingestellt, dass RACs nur eine Link-Local-IPv6-Adresse erhalten. Deshalb wird ein festes IPv6-Subnetz mit routbaren Adressen für RACs aufgesetzt. Der verwaltete Host ist vorliegend mit dem IPv6-Subnetz 2001:db8::11:0/116 konfiguriert und die RACs erhalten eine IPv6-Adresse aus diesem Bereich. Der erste RAC erhält 2001:db8::11:1 und der zweite RAC erhält 2001:db8::11:2. Der Dockerdaemon fügt automatisch Routen zu einer Routing-Tabelle des Systems hinzu und ermöglicht IPv6-Forwarding, so dass jeglicher Verkehr zu dem IPv6-Subnetz über ein docker0-Interface geroutet werden kann. Um die RACs von anderen Netzwerk-Hosts erreichbar zu machen, wird vorliegend ein NDP Proxy Daemon verwendet. Er leitet L2-Adressauflösung für IPv6-Adressen der RACs weiter, d.h. er überwacht benachbarte Anfragen auf RAC-Adressen und antwortet mit einer MAC-Adresse des verwalteten Hosts. Danach werden Pakete empfangen, welche einen RAC adressieren, und durch den Docker-Host über das docker0-Gerät zu dem bestimmten RAC weitergeleitet.
Der 802.1X CS ist vorliegend als Plug-in für das Docker Authorization Framework implementiert, welches weiter oben beschrieben wurde. Das Plug-in ist in Python programmiert und verwendet eine Flask-Bibliothek zum Implementieren eines REST-Interfaces. 13 zeigt den Autorisierungsvorgang. In (1) frägt der Benutzer den CMD an, einen Container zu starten. Die Anfrage beinhaltet UAND, zum Beispiel bestehend aus einem Benutzernamen und einem Passwort. Das Docker Authorization Framework definiert einen zweistufigen Autorisierungsvorgang, wobei vorliegend lediglich der zweite Schritt benötigt wird. Die erste Autorisierungsanfrage (2) beinhaltet nur minimale Daten, zum Beispiel den Namen des RAC-Bilds. Da die vorliegende Implementierung lediglich auf dem zweiten Autorisierungsschritt basiert, korrespondiert der 802.1XCS zu einer Erlaubnis als Voreinstellung. Die zweite Autorisierungsanfrage (3) beinhaltet UAND und CAND. Der 802.1XCS führt Authentifizierung mit dem 802.1XAS durch den 802.1X CA wie obenstehend beschrieben durch (3). In (4) gibt der 802.1X AS CAZD zurück, welches zu dem 802.1 X CS im Fall einer erfolgreichen AA weitergeleitet wird.
Der 802.1X CA ist vorliegend als SDN-Anwendung für den Ryu-SDN-Controller programmiert. Der 802.1X A, welcher aus dem Stand der Technik bekannt ist, wird durch das Hinzufügen einer Unterstützung für Authentifizierung mit dem 802.1X CS unter Verwendung von EAPoUDP erweitert. Der 802.1X CA öffnet einen UDP-Socket auf Port 5995 und wartet auf Verbindungen von dem 802.1 X CS. Der 802.1 X CA kann immer noch als älterer 802.1X A fungieren, welcher AA für Netzwerk-Hosts in altem 802.1X über EAPoL ausführt. Als Beispiel für eine Netzwerksteuerung mit xRAC wird ein eingeschränkter MAC-lernender Switch implementiert. Er lernt MAC-Adressen von verbundenen Hosts, leitet jedoch Pakete lediglich weiter, wenn die IP-Adressen von Sender und Empfänger in einer Whitelist sind. Die Whitelist beinhaltet statische Einträge, zum Beispiel für öffentliche Server, und dynamische Einträge, welche durch den 802.1X CA nach dem Empfang von CAZD von dem 802.1X AS modifiziert werden können. Der eingeschränkte MAC-lernende Switch wird durch Erweiterung der L2 schaltenden SDN-Anwendung von dem Ryu SDN Controller Framework implementiert.
Des Weiteren wird die häufig verwendete Software FreeRADIUS als 802.1X AS verwendet, wobei ein AA-Datenmodell erweitert wird, um CAND und CAZD zu implementieren. In FreeRADIUS können zusätzliche Attribute für AA und einfache Merkmale unter Verwendung von spezifischen Attributen implementiert werden, welche in der unlang-Verarbeitungssprache definiert sind. Das definierte AA-Datenmodell kann einfach erweitert werden und kann durch Hinzufügen von mehreren Vendor-Specific Attributes (VSAs) modifiziert werden.
Zwei Webserver VMs in der Testumgebung betreiben einen Python-Webserver, welcher HTML-Dateien über HTTP liefert. Der geschützte Webserver mit der statischen IPv6-Adresse 2001 :db8::aa:0 liefert eine HTML-Seite mit dem Satz „protected content“. Der öffentliche Webserver mit der statischen IPv6-Adresse 2001 :db8::bb:0 liefert eine HTML-Seite mit dem Satz „public content“.
Zum Nachweis der Funktionalität wurden mit der beschriebenen Testumgebung Experimente durchgeführt.
Die Experimente betrachten insbesondere die Kommunikation zwischen dem verwalteten Host, einem bestimmten RAC, dem geschützten Webserver und dem öffentlichen Webserver. Dabei wird ein wget-Tool als RAC verkapselt, um Dateien unter Verwendung von HTTP zu empfangen. In den folgenden Experimenten wird der RAC verwendet, um eine HTML-Datei von sowohl dem geschützten wie auch dem öffentlichen Webserver anzufragen. Es werden UAND, CAND und CAZD auf dem RADIUS-Server hinzugefügt, um einem bestimmten Benutzer zu erlauben, den RAC auszuführen und auf den geschützten Webserver zuzugreifen.
Es werden die in 14 dargestellten Experimente durchgeführt. Vor dem Ausführen des RAC wird gezeigt, dass der verwaltete Host die Öffentlichkeit erreichen kann, jedoch nicht den geschützten Webserver. Deshalb wird eine ICMP-Echoanfrage von dem geschützten Host zu der IPv6-Adresse von sowohl dem öffentlichen Webserver wie auch dem geschützten Webserver gesendet. Der öffentliche Webserver ist ohne Autorisierung erreichbar (1a), jedoch schlägt ein Versuch, den geschützten Webserver zu erreichen, fehl (1b). Nun wird demonstriert, dass die Integrität von RACs während einer Authentifizierung verifiziert wird, d.h. dass ein RAC mit einer divergierenden Prüfsumme nicht gestartet werden kann. Es wird ein weiteres RAC-Bild erzeugt, welches eine gepatchte Version von wget verkapselt und versucht, dies zu starten, und zwar unter Verwendung der Benutzerzugangsdaten wie auf dem RADIUS-Server definiert. Die Autorisierung schlägt fehl, d.h. der RAC kann nicht auf dem verwalteten Host gestartet werden. Nun wird demonstriert, dass der korrekte RAC gestartet werden kann und dass er den geschützten Webserver nach erfolgreichem AA erreichen kann. Nach dem Eingeben eines Kommandos zum Starten des RAC wird dieser authentifiziert und autorisiert, wie zuvor beschrieben (2a). Der SDN-Controller empfängt CAZD und programmiert den SDN-Switch zum Erlauben von Forwarding von Paketen zwischen dem RAC und dem geschützten Webserver (2c). Nun ist der RAC dazu in der Lage, die empfangene HTML-Datei von dem geschützten Webserver zu empfangen. Ein Versuch, die gleiche HTML-Datei mit wget direkt von dem verwalteten Host abzurufen, schlägt fehl (2e), d.h. der geschützte Webserver kann durch den RAC, jedoch nicht durch den verwalteten Host erreicht werden.
Zusammengefasst ist festzustellen, dass xRAC vorgeschlagen wird, ein Konzept für die Ausführung von Zugriffskontrolle von Restricted Application Containers (RACs) auf verwalteten Clients. Es beinhaltet Authentifizierung und Autorisierung (AA) für RACs derart, dass nur aktuelle RAC-Bilder durch zugelassene Benutzer ausgeführt werden können. Ferner wird die Autorisierung erweitert auf geschützte Netzwerkressourcen, und zwar derart, dass autorisierte RACs auf diese zugreifen können. Datenverkehrsteuerung wird durch die Tatsache vereinfacht, dass jeglicher Verkehr eines RAC durch seine IPv6-Adresse identifiziert wird. Die Architektur von xRAC wird vorgestellt und es wird durch eine Prototypenimplementierung gezeigt, dass xRAC mithilfe von standardisierter Technologie, Protokollen und Infrastruktur aufgebaut werden kann. Ein Prototyp von xRAC verwendet Docker als Containervirtualisierungsplattform zum Verteilen und Ausführen von RACs, und eine Signalisierung basiert auf 802.1X-Komponenten. Modifikationen können vorgenommen werden an einem Supplicant, einem Authentifikator und einem Autorisierungsserver, so dass sowohl Benutzer- wie auch Container-AA-Daten ausgetauscht werden können. Ferner wird der Containerauthentifikator erweitert, um benötigte Netzwerksteuerungselemente über autorisierte RACs zu informieren. xRAC unterstützt softwaredefinierte Netzwerksteuerung und verbessert die Netzwerksicherheit ohne Modifizierung von Kernkomponenten von Anwendungen, Hosts und Infrastruktur.
Erwähnte Schritte des erfindungsgemäßen Verfahrens können bevorzugt in der angegebenen Reihenfolge ausgeführt werden. Das erfindungsgemäße Verfahren kann in einer seiner Ausführungen, beispielsweise mit einer bestimmten Zusammenstellung von Schritten, in der Weise ausgeführt werden, dass keine weiteren Schritte ausgeführt werden. Es können jedoch grundsätzlich auch weitere Schritte ausgeführt werden, auch solche welche nicht erwähnt sind.
Es sei darauf hingewiesen, dass in den Ansprüchen und in der Beschreibung Merkmale in Kombination beschrieben sein können, beispielsweise um das Verständnis zu erleichtern, obwohl diese auch separat voneinander verwendet werden können. Der Fachmann erkennt, dass solche Merkmale auch unabhängig voneinander mit anderen Merkmalen oder Merkmalskombinationen kombiniert werden können.
Rückbezüge in Unteransprüchen können bevorzugte Kombinationen der jeweiligen Merkmale kennzeichnen, schließen jedoch andere Merkmalskombinationen nicht aus.

Claims

Verfahren zum selektiven Ausführen eines Containers (RAC), der eine Anwendung beinhaltet, wobei das Verfahren folgende Schritte aufweist: - Empfangen von Benutzerauthentisierungsdaten (UAND) durch eine Containermanagementkomponente (CMD), - Weiterleiten der Benutzerauthentisierungsdaten (UAND) an einen Containerantragsteller (CS), - Senden, durch den Containerantragsteller (CS), einer Autorisierungsanforderung an einen Autorisierungsserver (AS), wobei die Autorisierungsanforderung zumindest die Benutzerauthentisierungsdaten (UAND) beinhaltet, - Empfangen, durch den Containerantragsteller (CS), einer Autorisierungsantwort (CAZD) von dem Autorisierungsserver (AS), wobei die Autorisierungsantwort (CAZD) zumindest eine Freigabeinformation beinhaltet, welche entweder einen positiven oder einen negativen Wert annehmen kann, - Weiterleiten der Autorisierungsantwort (CAZD) an die Containermanagementkomponente (CMD), - Entscheiden, durch die Containermanagementkomponente (CMD), ob der Container (RAC) auszuführen ist, wobei der Container (RAC) auszuführen ist wenn die Freigabeinformation einen positiven Wert hat, und wobei der Container (RAC) nicht auszuführen ist wenn die Freigabeinformation einen negativen Wert hat, - nur wenn der Container (RAC) auszuführen ist, Starten und Ausführen des Containers (RAC).
Verfahren nach Anspruch 1, - wobei der Autorisierungsserver (AS) die Freigabeinformation zumindest basierend auf den Benutzerauthentisierungsdaten (UAND) bestimmt.
Verfahren nach einem der vorhergehenden Ansprüche, - wobei der Containerantragsteller (CS) ein 8021X Supplicant ist, und/oder - wobei der Autorisierungsserver (AS) ein 802.1X Autorisierungsserver (AS) ist, und/oder - wobei die Containermanagementkomponente (CMD) ein Container Management Daemon ist.
Verfahren nach einem der vorhergehenden Ansprüche, welches ferner folgenden Schritt aufweist: - Erzeugen von Containerauthentisierungsdaten (CAND) als Prüfsumme des Containers (RAC), - wobei die Autorisierungsanforderung die Containerauthentisierungsdaten (CAND) beinhaltet.
Verfahren nach Anspruch 4, - wobei der Autorisierungsserver (AS) die Freigabeinformation zumindest basierend auf den Containerauthentisierungsdaten (CAND) bestimmt.
Verfahren nach einem der vorhergehenden Ansprüche, - wobei die Autorisierungsantwort (CAZD) eine Berechtigungsinformation beinhaltet, - wobei die Anwendung mit Rechten ausgeführt wird, welche basierend auf der Berechtigungsinformation festgelegt werden.
Verfahren nach einem der vorhergehenden Ansprüche, welches ferner folgenden Schritt aufweist: - Zuweisen einer Netzwerkadresse zu dem Container (RAC).
Verfahren nach einem der vorhergehenden Ansprüche, - wobei die Autorisierungsanforderung über einen Containerauthentifikator (CA) zu dem Autorisierungsserver (AS) gesendet wird, und/oder - wobei die Autorisierungsantwort (CAZD) über einen Containerauthentifikator (CA) von dem Autorisierungsserver (AS) empfangen wird.
Verfahren nach Anspruch 8, - wobei der Containerauthentifikator (CA) ein 802.1X Authenticator ist.
Verfahren nach einem der Ansprüche 8 oder 9, welches ferner folgende Schritte aufweist: - Erzeugen, durch den Containerauthentifikator (CA), einer Netzwerkfreigabeinformation basierend auf der Autorisierungsanforderung und/oder der Autorisierungsantwort (CAZD), und - Senden, durch den Containerauthentifikator (CA), der Netzwerkfreigabeinformation an eine Netzwerksteuerungskomponente (FW), - wobei die Netzwerksteuerungskomponente (FW) Datenverkehr zu und/oder von dem Container (RAC) basierend auf der Netzwerkfreigabeinformation freigibt oder blockiert.
Verfahren nach den Ansprüchen 7 und 10, - wobei der Containerauthentifikator (CA) die dem Container (RAC) zugewiesene Netzwerkadresse an die Netzwerksteuerungskomponente (FW) sendet, und - wobei die Netzwerksteuerungskomponente (FW) den Datenverkehr basierend auf der Netzwerkadresse freigibt oder blockiert.
Verfahren nach einem der vorhergehenden Ansprüche, - wobei der Container (RAC) dazu konfiguriert ist, nur eine Anwendung auszuführen.
Verfahren nach einem der vorhergehenden Ansprüche, welches ferner folgenden Schritt aufweist: - Herunterladen der Anwendung und/oder des Containers (RAC) von einem Bereitstellungsserver.
Verfahren nach Anspruch 13, - wobei der Container (RAC) dazu konfiguriert ist, ausschließlich von dem Bereitstellungsserver heruntergeladene Anwendungen auszuführen.
Verfahren nach einem der vorhergehenden Ansprüche, - wobei die Autorisierungsanforderung und/oder die Autorisierungsantwort (CAZD) EAP-Nachrichten oder EAPoUDP-Nachrichten sind.