Sicherheitsgrenzen zwischen Cloud-Konten

Was ist Sicherheitsgrenzen zwischen Cloud-Konten?

Ein Cloud-Konto ist die stärkste Grenze für die Auswirkungen einer Kompromittierung, die ein Cloud-Anbieter bietet – solange Vertrauensbeziehungen darüber eng begrenzt sind. Eine Rolle hat zwei Richtlinien: Die eine bestimmt ihre Befugnisse, die andere, wer sie übernehmen darf. Eine eng begrenzte Berechtigungsrichtlinie schützt nicht, wenn ein ganzes anderes Konto die Rolle übernehmen kann. Sie prüfen eine kontoübergreifende Vertrauensrichtlinie, die ohne Bedingung das ganze Dev-Konto benennt, wechseln in die Produktion und schließen die Lücke in zwei Schritten: benannter Principal mit Bedingung und übergeordnete Service Control Policy (SCP).

Was Sie lernen in Sicherheitsgrenzen zwischen Cloud-Konten

• Eine Rolle besitzt eine Richtlinie für ihre Befugnisse und eine dafür, wer sie übernehmen darf. Selbst eng begrenzte Befugnisse sind problematisch, wenn jeder die Rolle übernehmen kann.
• Eine Vertrauensrichtlinie, die ein ganzes Konto benennt, lässt das schwächste Konto die Sicherheit des stärksten bestimmen.
• Ein Konto begrenzt eine Kompromittierung grundsätzlich, sofern keine Vertrauensbeziehung geschaffen wurde, die den Wechsel in ein anderes Konto ermöglicht.
• Eine Service Control Policy begrenzt Berechtigungen oberhalb des Kontos. Ein Administrator des Mitgliedskontos kann ein ausdrückliches Verbot nicht selbst aufheben.

Sicherheitsgrenzen zwischen Cloud-Konten — Trainingsschritte

1. Der einfachste Einstieg

   Bob hat keinen Zugriff auf die Produktion. Er verfügt über Zugangsdaten eines CI-Runners im Sandbox-Konto von Dremwick; sie standen in einem öffentlichen Build-Log. In der Sandbox gibt es nichts Stehlenswertes. Genau deshalb überwacht sie niemand aufmerksam. Bob prüft zunächst, welche weiteren Konten zur Organisation gehören.

2. Ein ganzes Konto auf der Gästeliste

   Bob sucht nach Rollen im Produktionskonto, die Identitäten aus dem Dev-Konto übernehmen dürfen. Er findet eine Rolle für Audit-Tools und liest deren Vertrauensrichtlinie.

3. Die Rolle übernehmen

   Bob übernimmt die Rolle. Dafür braucht er keine Schwachstelle auszunutzen: Die Vertrauensrichtlinie akzeptiert sein Dev-Konto, und AWS stellt ihm temporäre Zugangsdaten für die Produktion aus.

4. Ein Blick ins Produktionskonto

   Mit der übernommenen Rolle handelt Bob nun als Principal im Produktionskonto. Er prüft, was er sehen kann.

5. Alle Verträge von Dremwick

   Der Vertragsexport enthält geschäftskritische Informationen: wer Strom kauft, zu welchem Preis und für welche Laufzeit. Bob gibt ihn direkt im Terminal aus.

6. Was ist schiefgelaufen?

7. Unsere Preise im Angebot der Konkurrenz

   Dremwick verliert eine Ausschreibung an einen Konkurrenten, dessen Angebot den eigenen Preis um einen Abstand unterbietet, der nur mit Kenntnis der internen Preise erklärbar ist. Der Geschäftsbereich meldet den Verdacht. Die Spur führt zu einer Sitzung im Produktionskonto, die aus dem Dev-Konto stammt.

8. Die Organisation öffnen

   Alice öffnet die Organisationsansicht mit Kontostruktur, Vertrauensrichtlinie der kontoübergreifenden Rolle und übergeordneten Schutzregeln der Organisationseinheiten.

9. Das ganze Dev-Konto auf der Gästeliste

   Die Lücke liegt in der Vertrauensrichtlinie: Sie benennt das gesamte Dev-Konto statt nur des Tools, das die Rolle nutzen soll.

10. Die zugelassene Rolle genau benennen

    Alice ändert die Vertrauensrichtlinie: Nur noch die ausdrücklich benannte Rolle des Audit-Tools darf die Produktionsrolle übernehmen. Zusätzlich verlangt sie eine ExternalId, die nur dieses Tool kennt.