Sicherung eines Cloud-Bestands, den Sie nicht aufgebaut haben

Sie haben gerade die Schlüssel zu einem Cloud-Konto erhalten, das drei Jahre lang unbeaufsichtigt gewachsen ist. Niemand hat Dokumentation hinterlassen. IAM hat 40 Rollen mit Wildcard-Berechtigungen, es gibt S3-Buckets, an deren Erstellung sich niemand mehr erinnert, und die letzte Person, die die Netzwerk-Topologie verstand, hat das Unternehmen 2022 verlassen. Das ist häufiger, als die meisten Stellenausschreibungen zugeben würden, und der erste Monat bestimmt den Ton für alles Weitere.

Erstellen Sie ein Inventar, bevor Sie etwas anfassen

Widerstehen Sie dem Drang, sofort mit dem Absichern zu beginnen. Sie brauchen zuerst eine Karte. Führen Sie aws resourcegroupstaggingapi get-resources in jeder Region aus, nicht nur in us-east-1 — Teams lieben es, Test-Ressourcen in ap-southeast-2 zu starten und sie dann zu vergessen. Kombinieren Sie das mit AWS Config, falls bereits aktiviert, oder aktivieren Sie es jetzt. Auf Azure funktioniert az resource list --output table in eine Tabelle exportiert für einen ersten Überblick. Auf GCP gibt Ihnen Cloud Asset Inventory's gcloud asset search-all-resources denselben Überblick.

Gleichen Sie mit der Abrechnung ab. Alles, das Geld kostet, sollte in Ihrem Ressourcen-Inventar auftauchen; alles im Inventar mit null aktuellen Aktivitäten ist ein Kandidat für Archivierung. Diskrepanzen sind normalerweise dort, wo die schlimmen Dinge versteckt sind — verwaiste EC2-Instanzen mit öffentlichen IPs, vergessene unverschlüsselte RDS-Snapshots, Load Balancer, die auf nichts zeigen.

Auditing von IAM wie bei einer Straftat

Ziehen Sie jede IAM-Policy ab und suchen Sie nach "Action": "*" kombiniert mit "Resource": "*". Diese Kombination sollte außerhalb einer Handvoll Break-Glass-Admin-Rollen nicht existieren, und selbst diese sollten MFA-Erzwingung und CloudTrail-Alerting angebracht haben. Verwenden Sie IAM Access Analyzer, um Rollen zu finden, die Zugriff auf externe Konten gewähren — das erfasst sowohl absichtliche Cross-Account-Vertrauensbeziehungen als auch Fehler von jemandem, der ein Terraform-Modul gegen die falsche Konto-ID getestet hat.

Überprüfen Sie Zugriffstasten älter als 90 Tage mit aws iam generate-credential-report. Übernommene Bestände haben fast immer lang lebende Schlüssel an Dienstkonten angebracht, manchmal hartcodiert in einer Lambda-Umgebungsvariablen oder einem Jenkins-Job. Drehen Sie sie, aber inszenieren Sie es — das Löschen eines Schlüssels, von dem ein nächtlicher Batch-Job um 2 Uhr morgens abhängt, ist der Grund, warum Sie in Ihrer ersten Woche angerufen werden.

Finden Sie die öffentliche Exposition, bevor ein Angreifer es tut

Führen Sie eine Netzwerk-Erreichbarkeitsprüfung über Ihre VPCs durch. Security Groups mit 0.0.0.0/0 auf etwas anderem als 80/443 benötigen Begründung, nicht Annahme. Tools wie ScoutSuite oder Prowler werden in Minuten durch ein Konto gehen und einen nach Schweregrad geordneten Bericht ausgeben — fangen Sie dort an, anstatt Ihre eigene Checkliste von Grund auf zu erstellen.

S3-Buckets verdienen besondere Aufmerksamkeit, da sie die klassische Landmine des übernommenen Bestands sind. Überprüfen Sie sowohl Bucket-Richtlinien als auch Kontoebenen-Einstellungen für öffentlichen Zugriff blockieren; jemand könnte die Kontostandard vor Jahren für eine einmalige statische Website deaktiviert haben und nie wieder eingeschaltet haben. aws s3api list-buckets kombiniert mit einer Schleife, die get-bucket-acl und get-bucket-policy-status auf jedem überprüft, gibt Ihnen ein klares Bild in unter zehn Minuten für die meisten Konten.

Etablieren Sie Logging, bevor Sie Vertrauen etablieren

Falls CloudTrail, VPC Flow Logs oder GuardDuty nicht bereits überall laufen, schalten Sie sie jetzt ein, bevor Sie andere Änderungen vornehmen. Sie möchten ein Protokoll dessen, was von diesem Punkt an geschieht, und Sie möchten es, bevor Sie anfangen, Dinge zu löschen, denn das Löschen ist genau das, wenn Fehler passieren und der neuen Person die Schuld gegeben wird. Versenden Sie Logs wenn möglich an ein separates Konto oder Abonnement, damit ein kompromittierter Workload auch nicht seine eigenen Nachweise löschen kann.

Richten Sie GuardDuty oder Azure Defender for Cloud mit Alerting ein, das irgendwohin geleitet wird, wo ein Mensch tatsächlich schaut — nicht in einen Slack-Channel mit 400 ungelesenen Nachrichten. Der Wert von Erkennungs-Tooling ist nahe bei Null, wenn die Alerts ins Nichts landen.

Beheben Sie die lautesten Probleme zuerst, dokumentieren Sie alles

Sie werden einen übernommenen Bestand nicht in einem Sprint reparieren. Triage nach Explosionsradius: öffentliche Datenpreisgabe zuerst, dann Übergriffsidentitäten, dann Netzwerk-Segmentation, dann alles andere. Schreiben Sie auf, was Sie gefunden und was Sie geändert haben, auch in einem einfachen Google Doc, denn die nächste Person, die dies von Ihnen übernimmt, verdient besser als das, was Sie bekamen.

Erwarten Sie Gegenwind, wenn Sie eine Security Group straffen und ein Integration Test eines Entwicklers anfängt zu fehlschlagen. Das ist normal — es bedeutet, dass das Audit funktioniert. Sprechen Sie mit dem Team, das den Workload besitzt, bevor Sie etwas in der Produktion umschalten, und halten Sie einen Rollback-Plan für die ersten zwei Wochen bereit.

Weitere Informationen zu den Tools und der Begründung hinter Cloud-Audits finden Sie in Korra Studio's Segmenten zu IAM-Hardening und Cloud-Detection-Engineering — beide passen gut zum obigen Workflow.