Fintech-Cloud-Penetrationstests: Was kann eine Workload-Identität tun?

Die Entscheidung, bei der Ihnen dieser Leitfaden hilft

Wählen Sie einen Workload aus, der eine wesentliche Geschäftsfunktion unterstützt, und identifizieren Sie seine Laufzeit- und Bereitstellungsprinzipale. Verfolgen Sie die Ressourcen, auf die jeder zugreifen kann, sowie die im Test zulässigen Aktionen. Die Nachweise sollten zwischen einer theoretischen Berechtigung und einer beobachteten, autorisierten Nachweisaktion unterscheiden.

Beginnen Sie mit einer geschäftsrelevanten Arbeitslast

Wählen Sie einen Workload mit einem klaren Zweck: Zahlungsereignisse verarbeiten, Kundenberichte erstellen oder einen Dienst bereitstellen. Ermitteln Sie dessen Laufzeitprinzipal, Bereitstellungsprinzipal und die Ressourcen, auf die beide jeweils zugreifen sollen. Ein Hostinventar erfasst diese Beziehungen nicht, insbesondere wenn Workloads kurzlebig sind oder von einer Plattform verwaltet werden. Dokumentieren Sie Umgebung und Zuständigkeitsgrenze, bevor Sie Testverfahren auswählen.

Ziel ist die Prüfung einer klar definierten Vertrauensbeziehung, nicht die Erfassung sämtlicher in einem Cloud-Konto sichtbaren Zugangsdaten. Vereinbaren Sie, welche Identitäten, Ressourcen und Vorgänge zum Umfang gehören und welche Nachweise die betreffende Berechtigungsentscheidung belegen.

Konfigurierte Berechtigung von nachgewiesener Handlung unterscheiden

Eine Richtlinienprüfung kann darauf hindeuten, dass ein Principal weitreichende Rechte besitzt. Das ist ein nützlicher Nachweis, doch die Ausübung dieser Rechte kann Nebenwirkungen haben und die Testgenehmigung überschreiten. Wählen Sie gemeinsam mit der verantwortlichen Person eine begrenzte Validierungsmethode, etwa eine Aktion an einem dafür vorgesehenen Canary-Objekt. Geben Sie an, ob ein Befund auf einer Analyse der effektiven Richtlinien, einer beobachteten Aktion oder beidem beruht. Erwecken Sie nicht den Eindruck, dass jede theoretisch mögliche Aktion ausprobiert wurde.

Dokumentieren Sie den für das Ergebnis relevanten Identitätskontext und die Ressourcenrichtlinie. In mehrschichtigen Berechtigungssystemen der Cloud erklärt ein einzelner Richtlinienauszug möglicherweise nicht die endgültige Entscheidung; die Nachweise müssen die Bedingungen enthalten, die während des Tests tatsächlich galten.

Die Grenze zwischen Bereitstellung und Laufzeit prüfen

Build- und Deployment-Systeme können Material ausgeben oder aufbewahren, das eine privilegiertere Identität repräsentiert, als die laufende Anwendung benötigt. Ermitteln Sie, wo dieses Material gespeichert ist, wer darauf zugreifen kann und ob es außerhalb des vorgesehenen Workflows weiterhin nutzbar ist. Prüfen Sie aufgefundenes Material nicht ohne ausdrückliche Genehmigung anhand von Produktionsressourcen. Eine Canary-Beobachtung oder eine durch den Verantwortlichen unterstützte Beobachtung kann den relevanten Sachverhalt oft mit geringerem Betriebsrisiko belegen.

Unser Leitfaden zu Angriffspfaden über CI-Artefakte im Bankenumfeld erläutert den Unterschied zwischen Offenlegung, Verwendbarkeit und Berechtigungsumfang. Diese Unterscheidung ist auch für Release-Pipelines von Fintech-Unternehmen hilfreich und verhindert, dass die Auswirkungen einer Zeichenfolge, die wie ein Geheimnis aussieht, übertrieben dargestellt werden.

Vorgesehenen und unbeabsichtigten Zugriff vergleichen

Bereiten Sie für die ausgewählte Identität einen zulässigen Vorgang und einen verbotenen Vergleich vor. Ein Report-Worker benötigt beispielsweise möglicherweise einen eigenen synthetischen Ergebnisspeicher, aber keinen Zugriff auf das Canary-Objekt eines anderen Dienstes. Halten Sie die Bedingungen für Ressource und Identität ausreichend stabil, um das Ergebnis interpretieren zu können. Berücksichtigen Sie den Ablauf oder Widerruf der Identität nur, wenn dieses Verhalten zum vereinbarten Umfang gehört und sicher beobachtet werden kann.

Ein verweigerter Vergleich ist ein Nachweis für diesen konkreten Fall. Er beweist nicht, dass im gesamten Cloud-Bestand das Prinzip der geringsten Berechtigungen gilt. Dokumentieren Sie Ressourcen, Richtlinien und Umgebungsversion, damit spätere Prüfer den Umfang der Abdeckung nachvollziehen können.

Maschinellen Zugriff mit der betrieblichen Governance verknüpfen

Fragen Sie, wer Änderungen an Berechtigungen genehmigt, Zugangsdaten rotiert oder widerruft und eine unerwartete Nutzung der Workload-Identität untersucht. Der Penetrationstest kann einen technischen Angriffsweg aufdecken, dessen Behandlung mehrere Teams erfordert. Benennen Sie diese Zuständigkeiten, statt pauschal eine „IAM-Prüfung“ ohne Verantwortliche zu empfehlen. Die Prüfungsnachweise sollten ausreichen, um die kontrollierte Aktion mit dem Prinzipal, der Workload und der Canary-Ressource zu verknüpfen.

Wenn ein Cloud-Anbieter ein fortgeschrittenes Testprogramm eines Finanzunternehmens unterstützt, erläutert der DORA-TLPT-Leitfaden zur Koordination mit Drittanbietern, warum die Beteiligung des Anbieters und die Berechtigungsgrenzen frühzeitig berücksichtigt werden müssen. Ein routinemäßiger Cloud-Penetrationstest bleibt ein separater Auftrag mit eigenem Umfang.

Grenze und Workload-Funktion erneut testen

Wiederholen Sie nach der Behebung den unzulässigen Vergleich und bestätigen Sie, dass die Workload ihre legitime Aufgabe weiterhin ausführen kann. Dokumentieren Sie die bereitgestellte Richtlinie und Workload-Version. Ersetzt die Fehlerbehebung ein Zugangsmittel durch einen anderen Mechanismus, prüfen Sie die daraus resultierenden Berechtigungen, statt anzunehmen, dass der neue Mechanismus engere Rechte garantiert. Bereinigen Sie temporäre Testobjekte und Zugriffsmaterialien beim Abschluss.

Der Bericht sollte festhalten, was sich geändert hat, was beobachtet wurde und was außerhalb des Prüfungsumfangs bleibt. So entsteht ein wiederverwendbarer Nachweis für künftige Releases und Berechtigungsabweichungen lassen sich leichter besprechen, ohne aus einer zeitlich begrenzten Prüfung eine Behauptung kontinuierlicher Sicherheit abzuleiten.