Ressourcen in AWS sicher administrieren

Ein Cloudprojekt ist nicht mit der Erstellung der benötigten Ressourcen beendet – wäre ja auch zu einfach. Genauso, wie man es von on Premise kennt, haben IT Umgebungen einen Lifecycle. So müssen auch in der Cloud die einzelnen virtuellen Maschinen, Programme und Daten weiterhin verwaltet werden. 

Bei einem Approach, in dem man seine Umgebung komplett Cloud Native aufbaut, die Infrastruktur als Code definiert und die Provisionierung voll automatisiert, muss dieser Punkt nicht mehr ganz so stark betrachtet werden. Du hast dich zum Beispiel aus diversen Gründen für eine „Lift and Shift“ Migration entschieden? Dann läuft immer noch eine große Anzahl an virtuellen Maschinen, auf denen das Betriebssystem und die darauf laufenden Programme regelmäßig mit Updates versorgt werden wollen. 

Wie greift man aber sicher auf die neue Umgebung in der Cloud zu, um die administrativen Tätigkeiten vorzunehmen? 

Am besten sollte der Zugriff natürlich so gestaltet sein, dass er nicht von bösen Teenies mit schwarzen Hoodies ausgenutzt wird. Bei einer on Premise Umgebung gestaltet sich das Thema eigentlich recht einfach. Man hat seine Server im geschützten Datacenter, in sicheren Netzen hinter Routern mit ACLs, Firewall und diversen anderen sicherheitstechnischen Hürden. Kritische Infrastruktur steht in der Regel in einem gesonderten Bereich. Nur ein beschränkter Personenkreis hat aus definierten Netzen administrativen Zugang. Aber wie kann man das in der Cloud umsetzen? 

Einfache Portfreigabe 

Die naheliegendste Lösung wäre einfach die administrativen Ports nach außen freizugeben. Jede virtuelle Maschine bekommt eine externe IP Adresse und man kann sich einfach per SSH, RDP oder sonstigen Protokollen verbinden. 

Abgesehen davon, dass die Anzahl an externen IP Adressen bei AWS auf 5 pro Region und Account beschränkt ist, ist dieser Ansatz auch aus IT Security Sicht keine gute Idee. Alle möglichen bekannten oder noch unbekannten Sicherheitslücken können von jedem der einen Internetanschluss besitzt ausgenutzt werden. Natürlich kann man über Security Groups den Zugriff auf eine bestimmte Menge von externen IP Adressen beschränken. Das ist aber besonders in Zeiten von regelmäßigem Home Office eher unpraktisch. Außerdem muss man sich im Klaren sein, dass alle unverschlüsselte Kommunikation, z.B. die Eingabe von Passwörtern, über das Public Internet erfolgt. Somit sollte diese Variante, wenn überhaupt, für eine einzelne Testinstanz genutzt werden. 

Bestehendes VPN nutzen 

Steht schon eine VPN Verbindung – oder sogar eine direkte Verbindung (AWS Direct Connect) – zwischen Cloud und on Premise zur Verfügung, sollte diese Verbindung natürlich auch für die Verwaltung der Cloud Ressourcen genutzt werden. Über Zugriffsregeln auf lokalen Firewalls und Security Groups in AWS kann der Zugriff sehr genau reguliert werden. 

Wenn man jedoch regelmäßig aus dem Home Office arbeitet und dauernd den Umweg über das firmeneigene Client VPN gehen muss, oder vielleicht sogar keine Ressourcen mehr on Premise hat, ist diese Lösung eher unpraktisch. 

Bastion Host – die Festung in der Cloud 

Eine bekannte Lösung, die bereits mehrfach on Premise genutzt wird, ist ein sogenannter Bastion (engl. Festung) Host. Oft auch unter dem Namen Jump Host bekannt, handelt es sich hierbei um einen besonders abgesicherten Server um z.B. Infrastruktur in der DMZ oder Netzkomponenten im getrennten out of band Management zu verwalten. Die Idee dahinter ist, einen dedizierten Server mit sehr strikten Zugriffsregeln für einen sehr begrenzten Personenkreis zur Verfügung zu stellen. Über diesen können dann alle administrativen Tätigkeiten vorgenommen werden. Ein Vorteil der Lösung ist auch, dass auf dem Host alle benötigten Programme bereits installiert sind. Was besonders bei Verwaltungstools mit alten Java Versionen oder seltsamen Sicherheitseinstellungen im Browser hilfreich ist. 

A picture containing diagram

Description automatically generated

Wie bereits bei der einfachen Portfreigabe muss auch hier auf einen sicheren Zugriff geachtet werden: 

  • er sollte auf einzelne IP Adressen beschränkt sein (Security Group) 
  • verschlüsselte Protokolle sind sehr zu empfehlen 
  • jegliche Verbindungen auch deren Versuche sollten geloggt werden 
  • der Host sollte gehardened sein 

Je nachdem wie wichtig die Verfügbarkeit des Bastion Hosts ist, sollte man in Betracht ziehen, mehrere Instanzen über eine sog. Autoscaling Group zur Verfügung zu stellen. 

Auch bei dieser Lösung sind schnell wechselnde IP Adressen im Home oder Biergarten Office eher hinderlich. Außerdem muss man natürlich erwähnen, dass diese Lösung Geld kostet, da der Bastion Host in der Regel rund um die Uhr läuft. 

DaaS mit Amazon WorkSpaces 

AWS bietet seit einiger Zeit eine Remote Desktop Lösung an; wenn man so will Desktop as a Service. Hier werden Windows oder Linux Maschinen mit anpassbarem Image von AWS bereitgestellt. Diese werden im eigenen VPC bereitgestellt und sind über einen Desktop Client von extern erreichbar. Die Authentisierung kann über das eigene Active Directory ermöglicht werden.  

Von Seiten der Usability ist es eine gute Lösung und AWS WorkSpaces hat definitiv seine Anwendungsbereiche. Dank einem festem monatlichen Grundpreis und zuzüglicher Kosten pro Stunde für diesen Anwendungsfall aber eher zu teuer. 

Mögliche Lösung – der AWS Systems Manager

Wenn es ausschließlich um die Administration von EC2 Instanzen geht, gibt es hier ein nützliches Tool von AWS. Mit AWS Systems Manager können Tätigkeiten an AWS Ressourcen automatisiert werden, zum Beispiel Patch Management oder Inventarisierung. 

Ein nützliches Feature für die hier beschriebene Problemstellung ist der Session Manager. Mit Hilfe eines kleinen CLI Tools auf dem eigenen Rechner, kann auf verschiedene Ports einer EC2 Instanz zugegriffen werden. Es müssen keine eingehenden Ports geöffnet werden oder ein Bastion Host bereitgestellt werden. Auf welche Ports zugriffen werden soll, wird beim CLI Aufruf angegeben. 

aws ssm start-session --target <instanceID> --document-name AWS-StartPortForwardingSession --parameters portNumber=3389,localPortNumber=<randomPort>  

Die Authentifizierung für den Zugriff wird über AWS IAM Policies gelöst. Sobald man erfolgreich authentifiziert ist, wird ein SSM Tunnel erstellt. Ähnlich einem SSH Tunnel, der sicherlich von Bastion Hosts mehr als bekannt ist. Danach kann man wie gewohnt per RDP, SSH oder sonstigem Protokollen auf die EC2 Instanz zugreifen. 

Je nachdem welche Feature des AWS Systems Manager genutzt werde, fallen unterschiedliche Preise an. Die Nutzung des hier beschriebenes Session Managers ist zum aktuellen Stand kostenfrei. 

Mein Fazit 

Mittel und Wege gibt es unzählige. Die hier beschriebenen, sind Teil der Möglichkeiten, die man mit AWS hat. Jedes Projekt bringt eigene Anforderungen und Gegebenheiten mit sich. Wenn sich aber ausschließlich um Zugriffe auf EC2 Instanzen handelt, ist diese Variante definitiv das Mittel der Wahl. 

Matthias Meyer SEQUAFY GmbH

Matthias hat den berüchtigten IT-Spieltrieb und testet gerne aus, anstatt lange darüber zu reden. Als Co Founder der SEQUAFY GmbH ist er außerdem Spezialist für Amazon Web Services, Netzwerkadministration, Architektur und Design.