CODE-DE und Behörden

Als deutsche (Landes-/Bundes-)Behörde kann es eine große Hürde sein, eine CLOUD-Umgebung wie CODE-DE zu nutzen.
Behörden haben einen IT-Service bzw. eine Datenverabreitungs-Abteilung (DV), der/die für den Betrieb, die Sicherheit und Wartung des Behördennetzes verantwortlich ist.
Auch wenn CODE-DE zweifach lizensiert ist vom BSI (C5, ISO 27001), muss der Sicherheitsbeauftragte (IT-SiBe) der jeweiligen Behörde das System unter behördenspezifischen Gesichtspunkten prüfen, inwiefern die Plattform eine Gefahr für das Behörden-Intranet sein kann.

CODE-DE am JKI

Ich arbeite am JKI, einer Bundesbehörde und Resortforschungeinrichtung des Bundesministeriums für Landwirtschaft und Ernährung (BMEL).
Wir nutzen CODE-DE produktiv etwa seit März 2021. Bei unserer täglichen fernerkundlichen Arbeit geht es vor allem darum, die Virtuellen Maschinen (VM) der Plattform zu nutzen, also dem CODE-DE-Angebot Fernerkundungsdaten zu prozessieren.
Wir hatten zunächst erhebliche Probleme, die Plattform in ihrem gesamten Funktionalität zu nutzen. Ich möchte hier unseren technischen Weg kurz darstellen, wie wir es geschafft haben CODE-DE am JKI zu nutzen.

Derzeit nutzen wir etwa 15 virtuelle Maschinen, um verschiedenste Projekte mit Fernerkundungsdaten zu realisieren.
Die Abbildung zeigt exemplarisch, wie unsere CODE-DE-Plattform aussieht.
CDE-Infrastruktur des JKIs

Neun Virtuelle Maschinen (Instances) haben Zugriff zu den zwei internen CODE-DE-Netzwerken.
Das cloud_00xxx-Netzwerk dient dem Remotezugang zu den VMs, das Netzwerk dlr-access-net dient dem alleinigen Zugriff auf die bei CODE-DE vorhandenen Geodaten.
Alle Maschinen besitzen eine interne IP die mit 10.X.X.X beginnt. Diese IPs können genutzt werden um untereinander per SSH zu kommunizieren.

DAS PROBLEM

Normalerweise vergibt man für jede VM eine externe IP (172.X.X.X) um eine Verbindung nach "draußen" ins Internet zu haben. Über diese externe IP kann man dann bspw. per SSH auch von überall her auf die VM über das Internet zugreifen.
Genau das ist für eine Behörde das Sicherheitsrisiko, denn wenn man vom Behördenintranet einen Tunnel per SSH öffnet zu CODE-DE, können theoretisch auch Hacker über CODE-DE in das Behördenintranet eindringen.

LÖSUNG: VPN-TUNNEL

Unsere Lösung ist auch in der Abbildung dargestellt (PINK).
Nur eine unserer VMs hat eine externe IP-Adresse (Instance: DV_openVPN).
Diese VM wurde dem IT-Service unserer Behörde komplett überlassen. Dort wurde eine Software (openVPN) eingerichtet, die einen VPN-Tunnel zwischen der CODE-Plattform und dem Behörden-Intranet herstellt. Die VMs von CODE-DE werden so quasi in das Intranet unserer Behörde eingebunden und benötigen somit keine eigene externe IP mehr.
Die Verbindung per SSH/SFTP/... wird somit über die internen IPs (10.X.X.X) hergestellt.
Ein großer Vorteil und Nebeneffekt dabei ist, dass die maximale Anzahl an externen IP-Adressen keine Rolle mehr spielt.
Mit dieser Lösung können somit theoretisch beliebig viele VMS betrieben werden, bis andere Grenzen (bspw. Anzahl CPUs) erreicht sind.

Arbeiten mit Entwicklungsumgebungen (JupyterLab / VS Code) oder Remote Desktop

Um nun produktiv mit den VMs zu arbeiten, muss entweder eine Remote-Desktop-Verbindung zur VM hergestellt werden, oder mit Entwicklungsumgebungen (Jupyter / VS CODE / R-Studio Server) gearbeitet werden. All diese Verbindungsarten benötigen neben der SSH-Zugänglichkeit zusätzliche Portfreigaben um die Verbindung aufbauen zukönnen. Diese Ports müssen in der Firewall der Behörde vom IT-Service freigegeben werden.

Nachteil der VPN-Lösung

Einen Nachteil hat diese Lösung. Außerhalb des Behördenintranets gibt es so keine Möglichkeit auf die VMs zuzugreifen. Man muss also entweder im Intranet der Behörde sein. Außerhalb der Behörde (HomeOffice, Dienstreise, ...) muss der PC dann eine VPN-Verbindung zum Behördenintranet (und somit eine IP der Behörde) haben, um mit den VMs arbeiten zu können.