Tests privilegierter Zugriffe bei Banken: mehr als bloße Netzwerkerreichbarkeit

Die Entscheidung, bei der Ihnen dieser Leitfaden hilft

Behandeln Sie Konnektivität, Authentifizierung und Befugnis als drei getrennte Prüfpunkte. Verwenden Sie eine bekannte Ausgangsrolle und einen vereinbarten geschützten Vorgang und vergleichen Sie dann den vorgesehenen Ablauf mit einem klar definierten unzulässigen Fall. Berücksichtigen Sie Maschinenidentitäten und den Ablauf von Berechtigungen, sofern sie für den Bankdienst relevant sind.

Beginnen Sie mit einem operativen Privileg

Wählen Sie eine Berechtigung aus, die für einen Bankdienst relevant ist: Bereitstellung, Konfigurationsänderung, Zugriff auf geschützte Daten oder Verwaltung einer unterstützenden Identität. Legen Sie fest, welche Personen und Workload-Prinzipale sie erhalten sollen, über welchen Zugangsweg sie erlangt wird und wie der Genehmigungsprozess aussieht. Eine Liste von Administratorgruppen ist ein Ausgangspunkt, erklärt aber nicht, wie ein Betreiber den Dienst erreicht oder für welche Aktionen eine zusätzliche Genehmigung erforderlich sein sollte.

Beschreiben Sie die Frage in geschäftlichen Begriffen, ohne die Auswirkungen zu übertreiben. Der Test kann beispielsweise untersuchen, ob eine bereitgestellte Supportrolle auf eine geschützte Verwaltungsschnittstelle zugreifen kann. Das ist eine engere Frage als die, ob ein Angreifer die gesamte Bank kompromittieren kann.

Den Pfad durch die einzelnen Grenzen abbilden

Stellen Sie den für den Leistungsumfang relevanten Quellrechner oder Workload, Identitätsanbieter, Zugriffsgateway, Netzwerkgrenze und Zieldienst dar. Kennzeichnen Sie, wo die einzelnen Berechtigungen geprüft werden und welche verantwortliche Person sie erläutern kann. Berücksichtigen Sie Dienstidentitäten, die nach der ersten Anmeldung ausgegeben werden, da sie eine andere Gültigkeitsdauer oder andere Berechtigungen haben können. Halten Sie einen unterstützten Ausgangszustand ausdrücklich fest.

Ein Gateway, das eine starke Authentifizierung durchsetzt, kann dennoch zu einer übermäßig weit gefassten Zielliste führen. Ebenso kann ein erreichbarer Port zu einem Dienst führen, der den Principal korrekt zurückweist. Im Test sollte jede beobachtete Ebene einzeln ausgewiesen werden, statt Konnektivität als Beleg für vollständigen privilegierten Zugriff zu behandeln.

Bereiten Sie positive und negative Vergleiche vor

Wählen Sie eine genehmigte Aktion für eine festgelegte Canary-Ressource und einen ausdrücklich unzulässigen Vergleichsfall. Verwenden Sie dedizierte Konten und nach Möglichkeit ein sicheres Ziel. Bestätigen Sie Quellstandort und Identitätskontext, damit ein verweigertes Ergebnis aussagekräftig ist. Testen Sie nicht jeden möglichen Verwaltungsendpunkt, nur weil ein einzelner Pfad im Umfang enthalten ist; eine Erweiterung erfordert eine dokumentierte Genehmigungs- und Risikoentscheidung.

Die klinische Infrastruktur hat andere Auswirkungen, aber unser Leitfaden zur Netzwerksegmentierung in Krankenhäusern bietet ein klares Modell zur Unterscheidung zwischen Netzwerkpfad und Dienst. Die übertragbare Erkenntnis: Dokumentieren Sie, auf welcher Ebene das Ergebnis entstand, und berücksichtigen Sie dabei die betrieblichen Einschränkungen der Bank.

Ablauf von Berechtigungen und Zuordnung beobachten

Wenn eine vorübergehende Rechteausweitung unterstützt wird, vereinbaren Sie den Zeitraum und das erwartete Ablaufverhalten. Beobachten Sie sowohl die bestehende Testsitzung als auch neue Authentifizierungsversuche. Prüfen Sie, ob der Zugriff auf nachgelagerte Dienste derselben Richtlinie folgt. Stellen Sie einen Zusammenhang zwischen Genehmigung, Identität, Sitzung und Canary-Aktion sowie den zuständigen Verantwortlichen her. Ein nicht nachverfolgbares gemeinsam genutztes Konto kann die Rechenschaftspflicht beeinträchtigen, selbst wenn die Netzwerkbeschränkungen wie vorgesehen funktionieren.

Vermeiden Sie die Erfassung umfangreicher privilegierter Protokolle ohne Nachweisplan. Bewahren Sie nur die kleinste zweckmäßige Aufzeichnung für die vereinbarte Beobachtung auf und schwärzen Sie Geheimnisse sowie nicht relevante Kundeninformationen. Legen Sie alle Protokollierungs- oder Zeitbeschränkungen offen, die die Sicherheit der zeitlichen Abfolge beeinflussen.

Den Pfad der Maschinenidentität einbeziehen

Bereitstellungs-Worker und Integrationsdienste können dieselbe geschützte Umgebung über einen anderen Weg erreichen als menschliche Administratoren. Legen Sie fest, ob diese Dienstkonten zum Prüfungsumfang gehören und welche Vorgänge getestet werden dürfen. Untersuchen Sie den Zusammenhang zwischen dem Zweck der Workload und ihren effektiven Berechtigungen. Ein Dienst, der zur Veröffentlichung eines Releases verwendet wird, benötigt möglicherweise keine Berechtigungen für nicht zugehörige Daten oder Identitäten.

Der Leitfaden zu Tests von Cloud-Workload-Identitäten entwickelt diese Vergleiche anhand von Canary-Ressourcen und begrenzten Nachweisen weiter. Halten Sie jede konfigurationsbasierte Schlussfolgerung getrennt von einer Handlung, die während der Bankprüfung tatsächlich nachgewiesen wurde.

Schließen Sie die Kontrolllücke, ohne den Betrieb zu beeinträchtigen

Ordnen Sie Befunde der fehlerhaften Ebene zu: Zielauswahl, Netzwerkdurchsetzung, Rollenzuordnung, Dienstautorisierung, Ablauf oder Zurechenbarkeit. Empfehlungen sollten ein messbares Ergebnis und eine verantwortliche Person benennen. Wenn mehrere Kontrollen zum Angriffsweg beitragen, bewahren Sie diesen Zusammenhang, statt voneinander unabhängige Tickets zu erstellen, bei denen jedes Team davon ausgeht, ein anderes habe das Problem gelöst.

Testen Sie den untersagten Vergleich und die erforderliche Betriebsaufgabe in der geänderten Umgebung erneut. Dokumentieren Sie temporäre Ausnahmen, Richtlinienversionen und verbleibende Annahmen zur Unterstützung. Die abschließenden Nachweise sollten es der Bank ermöglichen, sowohl zu erklären, warum der unerwünschte Pfad blockiert wird, als auch, warum eine legitime Administration weiterhin möglich ist.