Das haben wir alle schon einmal erlebt: Sie möchten eine AWS-Cloud-Infrastruktur schützen. Was tun Sie also? Sie lesen in der AWS-Dokumentation die bewährten Verfahren für Sicherheit nach, folgen den Anweisungen und vergessen sie wieder. Was aber, wenn Sie weiterführende Informationen benötigen? Oder wenn die Empfehlungen nicht auf Ihren Fall zutreffen?

In diesem Artikel gehen wir ausführlicher auf die Empfehlungen ein und erläutern, weshalb es manchmal nicht genügt, die von Amazon empfohlenen Sicherheitsmaßnahmen pauschal zu befolgen.

Best Practices und was sie Ihnen nicht verraten

Wir alle kennen diese Situation bereits und wissen, dass es unzählige Ressourcen zu empfohlenen Sicherheitsmaßnahmen gibt. In der Regel behandeln sie jedoch die gleichen Themen und konzentrieren sich auf die ersten Schritte für den Schutz der Cloud-Infrastruktur.

Uns werden zum Beispiel basale Schritte empfohlen, wie die Einrichtung von IAM-Benutzern, Rollen und MFA. Wir werden über die Bedeutung starker Kennwörter informiert und auf die Notwendigkeit hingewiesen, sie zu verschlüsseln (etwa mit KMS). Diese Ratschläge funktionieren und bringen uns zunächst ein Stück weiter. Sie lassen sich jedoch meist kaum skalieren und bieten keine umfassende und robuste Sicherheit. Wenn Sie wirklich zuverlässigen Schutz benötigen, müssen Sie einen Schritt weiter gehen.

CROWDSTRIKE CLOUD SECURITY ON AWS

Mit der CrowdStrike Falcon®-Plattform und der Unterstützung eines Teams aus Cybersicherheitsexperten können Sie sich darauf verlassen, dass alle Ihre Systeme vollständig und zuverlässig an allen Fronten geschützt werden und dass kein Angriff unentdeckt bleibt.

Jetzt herunterladen

Vorsicht vor dem verwirrten Stellvertreter

Das Problem des verwirrten Stellvertreters ist ein Sicherheitsproblem, bei dem eine Entität ohne entsprechende Berechtigung eine privilegiertere Entität dazu zwingen kann, auf Ihre Ressourcen im AWS-Konto zuzugreifen. Dies geschieht zwar nur dann, wenn wir Dritten den Zugriff auf unsere Ressourcen gewähren müssen, hat sich jedoch in der Welt von Cloud-Computing und SaaS als gängige Praxis etabliert.

Wenn Sie diese Gefahr unterschätzen, kann es schnell passieren, dass Sie einem böswilligen Akteur uneingeschränkten Zugriff auf Ihre Infrastruktur gewähren. Um dies zu verhindern, verwenden Sie beim Definieren von Rollen die externe ID von AWS. Dabei handelt es sich um eine zusätzliche Information (ähnlich wie ein Kennwort), die eine Entität angeben muss, um eine bestimmte Rolle wahrzunehmen.

Dennoch sollte dies nicht auf die leichte Schulter genommen werden, denn es gibt zahlreiche Möglichkeiten, diese Information per Brute-Force-Angriff zu ermitteln. Wenn eine solche ID definiert wurde, sollte sie mit einem sicheren, schwer zu erratenden Kennwort geschützt und nur in verschlüsselter Form an Ihren Drittanbieter gesendet werden. Um die Sicherheit zusätzlich zu erhöhen, können Sie diese externen IDs regelmäßig ändern.

Einfache, knappe und skalierbare Richtlinien

Wie Sie wissen, verwendet AWS Richtlinien, um den Zugriff von Benutzern auf Ressourcen zu gewähren oder zu verweigern. Laut AWS sollten Sie auf diese Weise festlegen, wer Zugriff worauf erhält. Wenn Sie allerdings in der Lage sein möchten, stark zu skalieren, sollten Sie auf jeden Fall einen Plan für die langfristige Verwaltung Ihrer Richtlinien vorsehen. Dazu müssen die Richtlinien einfach und präzise sein.

Beispiel: Wenn Sie Zugriff auf einen bestimmten Service (z. B. AWS Lambda) gewähren möchten, sollten Sie eine Richtlinie erstellen, die genau das definiert – und sonst nichts. Auf diese Weise verhindern Sie unerwünschte Interaktionen zwischen Benutzern und Services. Es ist besser, für die Durchführung einer Aktion mehrere Richtlinien anzuwenden, als eine einzige Richtlinie zu verwenden, die mehrere Aktionen definiert, da sich solche Richtlinien nur schwer lesen, verwalten und skalieren lassen.

Welchen Vorteil bieten IAM-Gruppen gegenüber Benutzern oder Rollen?

An dieser Stelle möchten wir darauf hinweisen, dass Sie Richtlinien nicht direkt auf Benutzer oder Rollen, sondern auf IAM-Gruppen anwenden sollten. Auf diese Weise können Sie mehrere Richtlinien erstellen, die für verschiedene Teilbereiche Ihrer Kontobenutzer gelten, z. B. für Entwickler, Systemadministratoren, Testbenutzer, QA-Ingenieure usw.

Sie können diese Richtlinien den jeweiligen Benutzergruppen zuweisen, um sie nach Zuständigkeit oder Rolle zu differenzieren. Der Vorteil: Sie müssen nur einen einzigen Richtliniensatz schreiben und können alle darin enthaltenen Richtlinien auf einmal anwenden. Wenn Sie für einen bestimmten Mitarbeiter mehr Granularität benötigen, können Sie diesem einen Benutzer eine Ihrer einfachen Richtlinien zuordnen und ihm damit die gewünschten Berechtigungen gewähren.

Wenn Sie hingegen eine Benutzergruppe (z. B. die für Entwickler) ändern möchten, müssen Sie lediglich deren Gruppenrichtlinien bearbeiten, um alle Benutzerrichtlinien für diese Gruppe in einem Vorgang anzupassen.

Welche Vorteile bietet ein Transparenzservice wie AWS Systems Manager?

AWS Systems Manager ist ein Sicherheits- und Transparenzservice, der als Knotenpunkt Ihrer AWS-Assets und -Workflows fungiert. Er stellt eine zentrale Benutzeroberfläche für Sie bereit, über die Sie Ihre Infrastruktur nach Belieben durchsuchen, nach Schwachstellen suchen und diese patchen sowie die Konfigurationsdaten aller Anwendungen in Ihrer Umgebung verwalten können.

Mithilfe dieses Services können Sie Ressourcengruppen für unterschiedliche AWS-Services erstellen und dann aggregierte Daten nach Ressourcengruppe anzeigen. Das gibt Ihnen die Möglichkeit, auf Erkenntnisse zu reagieren und betriebliche Aktionen innerhalb dieser Ressourcengruppen zu automatisieren.

AWS Systems Manager verfügt über zusätzliche Funktionen in Form von kleineren Services wie Incident Manager und Change Manager. Incident Manager ermöglicht das Erstellen von Reaktionsplänen, die umgesetzt werden, wenn Probleme mit der Verfügbarkeit, Leistung oder Sicherheit innerhalb Ihrer Anwendungen oder Workflows auftreten. Sie können beispielsweise Benachrichtigungen generieren lassen, sobald eine Änderung in Ihrer Umgebung zu einer Sicherheitsschwachstelle führt, die umgehend behoben werden muss. Wenn die entsprechenden Bedingungen erfüllt werden, führt Incident Manager die definierten Pläne durch, benachrichtigt die First Responder-Verantwortlichen per SMS oder E-Mail, setzt die ursächlichen Änderungen zurück und liefert nützliche Post-Incident-Kennzahlen.

Change Manager hingegen vereinfacht Änderungen an der Infrastruktur und Konfiguration Ihres Kontos. Mithilfe von Änderungsvorlagen lassen sich unerwünschte Ergebnisse bei Anpassungen (z. B. an IAM-Richtlinien) vermeiden. Dies bietet sich an, wenn Sie sicherstellen möchten, dass keine disruptive Änderung den vordefinierten Workflow erreicht, wodurch sich wiederum Sicherheitszwischenfälle stoppen lassen, bevor sie eintreten.

All das lässt sich sehr gut mit einer richtlinienreichen Sicherheitslösung vereinbaren und entspricht der Vorgehensweise, die uns AWS ohnehin empfiehlt.

Zusammenfassung

Auch wenn möglicherweise nicht alle Punkte auf Ihre Infrastruktur zutreffen, sollten Sie zusätzlich zu den üblicherweise von AWS empfohlenen Schritten weitere Schutzvorkehrungen treffen. Das Modell der gemeinsamen Verantwortung ist zwar nützlich, gibt uns jedoch de facto kein Werkzeug an die Hand, um unsere Umgebung zu schützen. Wir erfahren lediglich, was wir schützen sollten.

Es ist allgemein bekannt, dass wir unsere Daten verschlüsseln und Sicherheitszugriffsschlüssel schützen sollten und dass die Planung unserer Sicherheitsstrategie selbstverständlich sein sollte, wenn wir eine umfangreiche Cloud-Infrastruktur verwenden und warten möchten.

Wir hoffen, dass diese Empfehlungen Ihre Sicherheit verbessern. Wenn Sie auf der Suche nach einer stärker verwalteten Lösung sind, sehen Sie sich CrowdStrike Falcon for AWS an. Dieser Service bietet lückenlosen Schutz vom Host bis zur Cloud und für alle Bereiche dazwischen sowie vollständige Transparenz zu all Ihren Ressourcen, Konten und Instanzen.