Verteidigung in der Tiefe ist wichtig

Denken Sie auch daran, Ihren Benutzern aufgabenspezifische Rollen zuzuweisen. Ein Benutzer, der zum Beispiel Änderungen an der Plattform vornehmen darf, braucht keine Rolle mit Schreibrechten anzunehmen, wenn er die Plattform nur untersucht.

Explosionsradius minimieren

Es ist naiv zu glauben, dass Ihre Umgebung niemals kompromittiert wird: Irgendwann wird es passieren. Wir wissen auch, dass, wenn wir kompromittiert werden, die nächste Frage lauten wird: "Was ist die Auswirkung dieses Verstoßes?" und wie schmerzhaft die Antwort sein wird: "Es betrifft alle unsere Produktionsanwendungen". In AWS ist es sehr üblich, eine Strategie mit mehreren Konten anzuwenden. Ein AWS-Konto bietet den höchsten Grad an Isolierung und ein Kunde kann so viele AWS-Konten wie nötig haben. In den ersten Tagen war die Verwaltung mehrerer AWS-Konten mit einem erheblichen Mehraufwand für betriebliche Aufgaben verbunden, aber mit den jüngsten Entwicklungen rund um AWS Organizations, AWS Control Tower, AWS Transit Gateway, AWS Resource Access Manager usw. sind die meisten dieser Herausforderungen gelöst. Zumindest so weit, dass sie nicht mehr als Ausrede für die Anwendung einer Strategie mit mehreren Konten dienen können.

Häufig angewandte Strategien sind:

• Auf Geschäftseinheiten ausgerichtete Strategie (Konto pro Geschäftseinheit, mehrere Anwendungen und Eigentümer pro Konto).

• Anwendungslebenszyklus-orientierte Strategie (Konto pro Phase in D, T, A und P, mehrere Anwendungen und Eigentümer pro Konto).

• Kostenstellenorientierte Strategie (Konto pro Kostenstelle, mehrere Anwendungen und möglicherweise pro Konto).

• Anwendungsorientierte Strategie (Konto pro Anwendung, ein Eigentümer).

• Eigentümerorientierte Strategie (ein Eigentümer pro Konto, mehrere Anwendungen pro Konto).

• Benutzerorientierte Strategie (ein Konto pro Benutzer, hauptsächlich für Sandboxing-Zwecke verwendet).

Aus unserer Erfahrung kann ich sagen, dass ich letztendlich eine anwendungsorientierte Strategie den anderen Strategien vorziehe. Sie bietet den kleinstmöglichen Explosionsradius, feinkörnige Einblicke und Flexibilität in Bezug auf Eigentum/Zugriff.

Verringern Sie die effektive Zeit, in der Sie angreifbar sind

Der Verlust oder die Weitergabe von Passwörtern ist ein sehr häufiger Fehler. Dies geschieht entweder aus Versehen oder durch unvorsichtige Arbeitsweise. Denken Sie an Passwörter, die über unverschlüsselte Kanäle weitergegeben werden, die in Quellcode-Repositories veröffentlicht werden, die auf einem Klebezettel unter der Tastatur oder auf dem Monitor hinterlassen werden, die leicht zu erraten sind, usw. Sobald sich die Zugangsdaten in der Hand eines Angreifers befinden, können sie ohne Einschränkungen missbraucht werden. Durch Hinzufügen von OTP (2FA) und/oder temporären Anmeldedaten, die von einem Identitätsanbieter bereitgestellt werden, wird die Zeit, in der die Anmeldedaten gültig sind, auf ein Minimum reduziert.

Um dieser Bedrohung zu begegnen, würde ich empfehlen, OTP auf dem Identitätsanbieter des Unternehmens zu implementieren (mit einer angemessenen Ablauffrist für STS-Zugangsdaten) oder eine MFA-Authentifizierung für den IAM-Benutzer zu erzwingen (z. B. keinen Schreib-/Lesezugriff auf die Plattform ohne gültiges MFA-Token).

Erweitern Sie Ihre IAM-Richtlinien um zusätzliche Attribute

IAM-Richtlinien auf AWS können sehr feinkörnig geschrieben werden. Neben der Angabe, welche Aktionen erlaubt sind, können die Richtlinien durch die Verwendung von Bedingungen erweitert werden. Diese Bedingungen müssen erfüllt sein, bevor eine Aktion erlaubt wird. Auf diese Weise können Sie anhand von kontextbezogenen Informationen, wie z. B. einer Quell-IP-Adresse oder Informationen über den Authentifizierungsprozess, steuern, wer auf was Zugriff hat. Mehrere Bedingungen können kombiniert werden, um eine solide Richtlinienanweisung zu erstellen.

Interessante Bedingungen sind:

• aws:MultiFactorAuthPresent: Verwenden Sie dies, um eine MFA-Authentifizierung zu erzwingen, bevor Sie den Zugriff auf AWS-Services oder -Ressourcen erlauben.

• aws:SourceIp: Verwenden Sie diese Bedingung, um eine Quelladresse anzugeben, von der aus Aktionen zugelassen werden sollen. Zum Beispiel nur von den bekannten Standorten Ihres Unternehmens.

• aws:AngefragteRegion: Verwenden Sie diese Bedingung, um die Aktion auf eine bestimmte AWS-Region zu beschränken. Die meisten Angreifer werden z.B. die beliebteste AWS Region us-east-1 verwenden. Sie möchten vielleicht nur einem authentifizierten und autorisierten Benutzer den Zugriff auf eine bestimmte Region erlauben. Wir sind in Europa ansässig und verwenden daher hauptsächlich die Regionen eu-{west,central}-1.

Eine ausführliche Liste der Bedingungsschlüssel finden Sie hier. Einige Dienste haben spezielle Konditionsschlüssel, die hier aufgelistet sind hier.

Reduzieren Sie IAM-Privilegien und implementieren Sie Service Control Policies

Administrator-Benutzer haben regelmäßig zu viele Privilegien auf der Plattform. Es kommt sehr häufig vor, dass diese Benutzer die verwaltete IAM-Richtlinie AdministratorAccess haben, während die meisten Operationen nur lesend ausgeführt werden und der Schreibzugriff auf eine sehr kleine Teilmenge von Aufrufen beschränkt ist. Für die meisten Aufgaben reicht der Schreibzugriff über Infrastructure As Code aus. Sie können erzwingen, dass Aufrufe an CloudFormation eine dedizierte Rolle mit Schreibzugriff verwenden. Auf diese Weise erfordern Änderungen an der Plattform ein gewisses Maß an Nachdenken und spezifische Kenntnisse der Plattform. Ich weiß, das ist nicht narrensicher. Aber alles, was den Angreifer ausbremst, hilft.

Auch die Implementierung von Service Control Policies wird empfohlen. Ich ziehe es vor, Service Control Policies grobkörnig anzuwenden. Auf diese Weise können Sie organisationsweit den Zugriff auf Aktionen einschränken, die eigentlich nicht stattfinden sollten.

Schützen Sie die Werte der Landezone

Verhindern Sie, dass Angreifer (und Benutzer) Basisdienste wie Ihre VPC, GuardDuty, CloudTrail usw. deaktivieren. Ich gehe davon aus, dass Sie eine Pipeline für die Bereitstellung Ihrer Landing Zone Assets verwenden. In Ihren SCPs können Sie Richtlinien festlegen, die Ihren Pipeline-Rollen den Zugriff auf die Foundation Services erlauben und allen anderen Identitäten den Schreibzugriff verweigern.

Beschränkung des Zugriffs auf Abonnementanrufe

Einige API-Aufrufe sind kostspielig und wirken sich auf lange Sicht aus. Denken Sie an API-Aufrufe für den Kauf von (C)RIs, die Aktivierung von AWS Shield Advanced und andere lang laufende Abonnements. Dies ist etwas, das Sie auch in normalen Situationen verhindern und nur bestimmten Rollen gewähren möchten. Es funktioniert am besten, wenn die Einschränkungen auf der Ebene der Stammdaten der Organisation vorgenommen werden.

Verweigerung des Zugangs zu ungenutzten Diensten und Regionen

Angreifer werden versuchen, jeden Dienst zu nutzen, den sie können. Je weniger Dienste erlaubt sind, desto geringer ist ihre Erfolgsquote. Das Gleiche gilt für Regionen. Wenn Sie wissen, dass Ihre Arbeitslasten nur eine Teilmenge der verfügbaren AWS-Regionen nutzen werden, kann es eine gute Idee sein, alle anderen Regionen zu sperren (Vorsicht, einige globale Services/Ressourcen erfordern den Zugriff auf die Region us-east-1).

Tipp: Verwenden Sie die NotAction-Anweisung, um Dienste auf die Whitelist zu setzen.

Verhalten proaktiv überwachen

AWS bietet eine Reihe von Services, mit denen Sie das Verhalten auf der AWS-Plattform analysieren können. Als Ausgangspunkt empfehle ich, CloudTrail so zu konfigurieren, dass Aktivitäten in allen Konten und Regionen aufgezeichnet werden, vorzugsweise auf Organisationsebene, und Amazon GuardDuty zu aktivieren. Und warten Sie mit dem Sammeln von Erkenntnissen über Aktivitäten nicht, bis Sie kompromittiert worden sind.

Regelmäßige Überprüfung der IAM-Richtlinien

Verwenden Sie den IAM Access Analyzer, um Ressourcen zu entdecken, die (ungewollt) mit Ressourcen außerhalb Ihrer Vertrauenszone geteilt werden. So erhalten Sie einen Überblick über Ressourcen, auf die Sie aus der Ferne zugreifen können.

Um Ihre IAM-Richtlinien zu verbessern, verwenden Sie den IAM Access Advisor, um Informationen darüber zu sammeln, welche Dienste von Ihren Benutzern genutzt werden. Dies ist ein wertvoller Input, um die IAM-Richtlinien zu optimieren/zu optimieren. Sie sollten in Erwägung ziehen, ungenutzte Dienste aus der Liste der erlaubten Aktionen zu entfernen.

Aktivität überwachen

Eine der am schwierigsten zu beantwortenden Fragen ist: "Werden Sie gerade angegriffen?". Um diese Frage zu beantworten, ist Beobachtbarkeit unerlässlich. Alle Aktivitäten zu protokollieren ist einfach, aber Ereignisse in zwei Kategorien zu unterteilen: erwartete und unerwartete, ist viel schwieriger. Wie definieren Sie erwartete Ereignisse? Das erfordert eine Menge Abstimmungsarbeit, eine große Anzahl von falsch-positiven Ergebnissen usw. Und was ist mit neuen Arten von Ereignissen zu tun? Zum Beispiel durch neue Funktionen und die Einführung neuer Dienste usw.

Amazon GuardDuty kann hier helfen. Dies ist ein vollständig von AWS verwalteter Service, dessen Konfiguration sehr einfach ist. Sie aktivieren einfach die Dienste und schon beginnt die Überwachung Ihrer Umgebung. Er verwendet CloudTrail, VPC Flow Logs und Route 53 Logs (DNS), um Anomalien zu erkennen. Die Erkennung erfolgt durch Machine Learning-Modelle. Es unterstützt eine große Anzahl von Ereignissen und die Liste wächst ständig weiter. Bestes Beispiel ist beispielsweise die Verwendung Ihrer AWS-Anmeldedaten. GuardDuty erstellt eine Basislinie Ihres Verhaltens. Wenn Sie beispielsweise Ihre Anmeldeinformationen von Ihrem (Heim-)Büro aus verwenden und plötzlich Ihre Anmeldeinformationen an einem anderen geografischen Standort verwendet werden, generiert GuardDuty einen Befund. Dieser Befund kann an Ihr bevorzugtes Überwachungssystem weitergeleitet werden. Durch die Nutzung von GuardDuty-Ereignissen erhalten Sie Einblicke in das Geschehen auf der Plattform. Bei einigen Ereignissen können Sie sich sogar für eine automatische Korrektur entscheiden, indem Sie eine Lambda-Funktion auslösen, wenn ein Ereignis eingetreten ist.

Budget-Warnungen konfigurieren

Die Cloud basiert hauptsächlich auf Verbrauchsmodellen, die Sie nach Bedarf bezahlen. Signifikante Änderungen in der Service-Nutzung führen also zu finanziellen Veränderungen. Am offensichtlichsten ist ein plötzlicher Kostenanstieg, z. B. wenn ein Angreifer Ihre Umgebung nutzt, um Krypto-Mining zu betreiben, oder wenn es zu einem Datenleck kommt (die Datenübertragung in der Cloud ist teuer). Aber auch ein unerwarteter Rückgang der Kosten kann vorkommen. Ein Angreifer könnte Ressourcen stoppen oder beenden, um seine Spuren zu verwischen oder wenn er Ihnen durch das Löschen von Daten schaden will. Überwachen Sie Veränderungen im Budget genau, um einen Einblick in das Verhalten zu erhalten. Ein fester Budgetalarm könnte helfen, ist aber wahrscheinlich nicht der klügste Weg. AWS und Cloud-Management-Plattformen bieten Prognosen und die Erkennung von Kostenanomalien. Nutzen Sie diese Funktionen, um Ihre Kosten genau im Auge zu behalten und die Anzahl der durch Budgetwarnungen erzeugten falsch-positiven Ergebnisse zu reduzieren.

Abschließende Gedanken

Mit diesem Blog wollte ich keine erschöpfende Liste von Sicherheitskontrollen vorlegen. Ich hatte vielmehr die Absicht, einige Einblicke zu geben, wie Sie die Auswirkungen einer Sicherheitsverletzung verringern können. Wir alle wissen, dass Software (und Hardware) ihre Schwachstellen haben, wenn es um die Sicherheit geht. Und wir wissen auch, dass wir von einem Angreifer angegriffen werden könnten. Es gibt viel, was wir tun können, um die Auswirkungen zu verringern, falls etwas passiert. Hoffentlich trägt dieser Blog dazu bei, Ihre Cloud-Umgebung zu einem sicheren Ort zu machen.

Hinweis: Das Problem ist zum Zeitpunkt der Veröffentlichung dieses Blogs gelöst #noworries.