Optimieren Sie Ihren Sicherheitsfußabdruck in AWS - Teil 1

In den letzten Jahren sind die Kosten für den Betrieb von Sicherheitslösungen in die Höhe geschossen. Wir haben eine Explosion von Sicherheitslösungen erlebt, die alle um ihren eigenen Platz in der Cybersicherheit kämpfen. Ich bin mir ziemlich sicher, dass jede Lösung ihren Zweck erfüllt, aber aus der Sicht eines CISO wird die Landschaft jedes Jahr komplexer und teurer, oder freundlicher ausgedrückt: weniger kosteneffizient.

Die öffentliche Cloud ist der wichtigste Motor für Innovationen. Mit dem Aufkommen neuer Denkansätze, neuer Fähigkeiten und der Neuerfindung der Art und Weise, wie wir IT betreiben, haben sich die Dinge enorm verändert.

Ich möchte die Gelegenheit nutzen und zwei heiße Themen in einer Blogserie zusammenfassen: Sicherheit und Kostenoptimierung. Und ja (Spoiler), die beiden können sich gegenseitig verstärken. In diesem und den kommenden Blogs teile ich unsere Erfahrungen aus den letzten Jahren und Dutzenden von Migrationen/Implementierungen.

Drop Active Directory Integration

Eines der schmerzhaftesten Themen während einer Migration ist die Integration von Active Directory. Nicht nur aus finanzieller Sicht, sondern auch aus technischer Sicht. Jahrzehntelang haben wir Active Directory als unser primäres Benutzerverzeichnis implementiert und anschließend alle unsere Ressourcen diesem Verzeichnis beitreten lassen. Auf diese Weise hatten wir das Gefühl, eine Art feinkörnige Kontrolle darüber zu haben, wer auf welche Ressource Zugriff hat.

Das größte technische Problem mit AD ist die enge Integration mit der Infrastruktur. Ein weiteres Beispiel: Es ersetzt Ihren DNS-Resolver und verlässt sich auf IP-Kommunikation. Dies zwingt Sie dazu, eine Angriffsfläche zu schaffen, die sich mehr oder weniger über alle Ihre Netzwerke erstreckt, da Sie AD verschiedenen Arten von Netzwerken aussetzen müssen. Zum Beispiel, indem Sie Ihr privates AD Ressourcen aussetzen, die in einem öffentlichen Subnetz gehostet werden. Und wenn Sie mehrere Domänenmaster haben, müssen sie alle von jeder Ressource erreichbar sein. Dies führt zu einem sehr komplexen Routing-Setup, wenn Ihre Umgebung wächst und vor allem, wenn Sie im Hybrid-Modus arbeiten. Das ist etwas, das Sie vermeiden möchten, wenn Sie eine Plattform mit sehr starken Isolierungsfunktionen verwenden.

Eine weitere Herausforderung ist die Analogie zwischen Haustieren und Rindern. Ressourcen in der öffentlichen Cloud sind (wenn sie richtig eingesetzt werden) dynamisch und kurzlebig. Sie kommen und gehen, wenn sich die Nachfrage ändert. Ich weiß, dass Sie den Beitritt zu einer Domäne per Skript steuern können, aber wenn Sie sich das Design von AD ansehen, stellen Sie fest, dass es nicht für eine solch dynamische Umgebung ausgelegt ist. Nach einer Weile haben Sie Tausende von verwaisten Ressourcen. Es ist auch nicht hochgradig skalierbar. Vergessen Sie nicht, dass AD vorzugsweise möchte, dass alle Clients AD als Resolver für die DNS-Auflösung verwenden.

Wahrscheinlich könnte ich stundenlang darüber sprechen, warum es generell keine gute Idee ist, Ihre AD-Einrichtung zu Verwaltungszwecken auf eine fähige Plattform auszuweiten. Konzentrieren wir uns darauf, wie Sie dieses Problem auf effektivere Weise lösen können. Eine der wichtigsten Funktionen von AD ist die Bereitstellung von RDP/SSH-Zugang zu Instanzen für den Remote-Desktop/Shell-Zugriff. AD kümmert sich um den Authentifizierungs- und Autorisierungsprozess. So wird der Benutzer bei jedem Verbindungsversuch aufgefordert, sich anzumelden (oder über Kerberos weitergeleitet). Auf der Grundlage von Richtlinien wird einem Benutzer/einer Gruppe der Zugang zu einer Instanz gestattet. Dies ist kein skalierbares Modell, da jede Instanz oder Gruppe von Instanzen über ein Gruppenrichtlinienobjekt verfügen muss, das die Benutzeridentität für den Fernzugriff erlaubt. Auch der Prozess des Domänenbeitritts ist umständlich: Denken Sie an umständliche PowerShell-Skripte und eine sehr merkwürdige Linux-Konfiguration (unterschiedliche Konfiguration pro Distribution).

Einführung in den AWS Systems Manager Session Manager

Um die Fernverwaltung zu vereinfachen, hat AWS zwei Funktionen eingeführt: SSM Session Manager (EC2-Instanzen) und ECS Exec (Container). Sie funktionieren für Linux, Windows und MacOS. Beide Funktionen verfügen über eine starke Integration in die Plattform und sind einfach zu implementieren und zu warten. Es funktioniert über den AWS Systems Manager Session Manager Agent, der über aktuelle , von AWS bereitgestellte AMIs bereitgestellt wird . In AWS ist es am besten, jeder Recheninstanz ein Instanzprofil zuzuordnen. Diesem Profil kann der Zugriff auf AWS-Ressourcen gewährt werden. Damit der SSM Agent sich beim SSM Service anmelden kann, fügen Sie dem Instanzprofil einfach die von AWS verwaltete Richtlinie zu. Standardmäßig werden die öffentlichen API-Endpunkte von SSM für die Verbindung verwendet, aber Sie können natürlich auch VPC-Endpunkte einrichten, um zu vermeiden, dass der Datenverkehr über das Internet geleitet wird. Starten Sie nun Ihre Instanz und die Vorbereitungen auf der Plattform sind abgeschlossen. Ganz einfach, nicht wahr?

Jetzt ist es an der Zeit, Ihren IAM-Benutzern/Rollen den Zugriff auf die Instanzen zu erlauben. Je nach Bedarf können Sie selbst entscheiden, wer die ssm:StartSession Aktion aufrufen darf. Dies kann mit Ihrer AWS-Kontostruktur, der Föderation und IAM-Bedingungen wie Tags, Zeit, Quell-IP usw. kombiniert werden, um es so feinkörnig wie nötig zu machen.

Hinweis: Dies funktioniert auch für hybride Umgebungen. Sie können den SSM Agent auf Ihren lokalen Ressourcen installieren und Ihre Instanzenflotte über AWS Session Manager verwalten. Er ist auch mit ausgehenden/weitergeleiteten Proxys kompatibel. Er passt also technisch gesehen in fast jede Umgebung.

Aus Sicht der Rechnungsprüfung werden alle Aktionen in AWS CloudTrail, Sitzungsdaten in S3 oder Amazon CloudWatch Logs aufgezeichnet. Wenn Sie eine Ereignisreaktion in Echtzeit wünschen, können Sie Amazon EventBridge in Verbindung mit Amazon Simple Notification Service verwenden, um Ereignisse an Ihr Slack, SIEM, ITSM oder Lambda (für die automatische Korrektur) usw. weiterzuleiten.

Auf Wiedersehen RDP und SSH

Als letzten Schritt sollten Sie nicht vergessen, die Ingress-Regeln in Ihrer Sicherheitsgruppe zu entfernen, da der direkte Zugriff über RDP und SSH nicht mehr erforderlich ist. Wenn Sie aus irgendeinem Grund SSH für die Port-Weiterleitung verwenden: Keine Sorge. Dies wird von SSM unterstützt. Lesen Sie hier mehr darüber. AWS Systems Manager Session Manager ermöglicht den Zugriff über die Webkonsole und über die AWS-Befehlszeilenschnittstelle, so dass Sie wählen können, welche Sie verwenden möchten.

Hinweis: ECS Exec unterstützt derzeit nur den Zugriff über awscli.

Ausgefallen. Was ist mit den Kosten?

Die laufenden Kosten für die oben genannte Lösung liegen wahrscheinlich weit unter dem Preis Ihres Mittagessens (selbst wenn Sie von zu Hause aus arbeiten). SSM Session Manager ist kostenlos, für CloudWatch Logs und S3-Speicher fallen Kosten an und für den VPC-Endpunkt wird eine stündliche Gebühr erhoben.

Abschließende Gedanken

Die Einführung von AWS Systems Manager wird eine Reihe neuer Funktionen freisetzen, während der Sicherheitsaufwand wie Betriebsmanagement, laufende Kosten, Anzahl der Tools usw. auf ein Minimum reduziert wird. Das Schöne an dieser Lösung ist auch, dass Sie keine Ports freilegen oder netzwerk- und umgebungsübergreifende Verbindungen herstellen müssen, was normalerweise den Grad der Isolierung beeinträchtigen und den Explosionsradius vergrößern würde. Ich empfehle Ihnen dringend, sich hier über die anderen Möglichkeiten von SSM zu informieren, da Sie damit eine Menge leistungsstarker Funktionen erhalten. Aufgrund der Leichtgewichtigkeit dieses Agenten ist es auch möglich, ihn auf Architekturen mit weniger Ressourcen, wie z.B. IoT-Geräten, einzusetzen.

Lesen Sie weiter

Teil 2 ist jetzt verfügbar!