Die 2FA eines gemeinsam genutzten AWS-Kontos verwalten

Niemand sollte sich mit einer geteilten Kennung bei AWS anmelden. Der tägliche Zugriff gehört zu Identitäten je Person über IAM Identity Center, und die Automatisierung gehört zu Rollen statt zu irgendetwas, das ein Mensch tippt.

Bleibt der Root-Benutzer, der wirklich eine einzige Kennung pro Konto ist. Nützlich zu wissen ist, dass Sie auch dessen zweiten Faktor nicht teilen müssen: AWS erlaubt es, mehrere MFA-Geräte am Root-Benutzer zu registrieren, zwei oder drei Administratoren können also jeweils ihr eigenes einrichten. Ein TOTP-Geheimnis zu kopieren ist ein Rückfall für die Fälle, in denen das nicht geht, nicht die Voreinstellung.

Drei verschiedene Kennungen

„Unser AWS-Konto“ meint meist eines dieser drei Dinge, und sie haben unterschiedliche Antworten.

Der Root-Benutzer. Einer pro Konto, über eine E-Mail-Adresse identifiziert, fähig zu allem, einschließlich das Konto zu schließen und die Abrechnung zu ändern. Nicht für die tägliche Arbeit gemacht.

Die Identitäten je Person. Benutzer des IAM Identity Center oder IAM-Benutzer in älteren Konfigurationen. Dort wird wirklich gearbeitet, und dort hat jede Person ihren eigenen zweiten Faktor.

Die Zugriffsschlüssel. Langlebige Anmeldedaten für den programmatischen Zugriff. Das ist keine Anmeldung, es ist nicht durch MFA geschützt, wie die Leute annehmen, und es ist das, was man am häufigsten in einem alten Repository findet.

Die meisten Fragen zur „geteilten AWS-2FA“ betreffen in Wahrheit das Erste und stellen sich, weil die anderen beiden nie eingerichtet wurden.

Tägliche Arbeit: Identitäten je Person

IAM Identity Center gibt jeder Person eine eigene Anmeldung, eine eigene MFA und zeitlich begrenzte Anmeldedaten auf den Konten und Rollen, auf die sie Anspruch hat. Der Zugang wird per Zuweisung gewährt, statt irgendetwas herauszugeben, und jemanden zu entfernen ist eine Handlung an einer Stelle, egal wie viele AWS-Konten Sie betreiben.

Sind Sie noch bei IAM-Benutzern, ist das Minimum ein Benutzer pro Person, jeder mit eigenem MFA-Gerät, und kein geteilter Benutzer für das Team. Ein geteilter IAM-Benutzer hat alle Probleme eines geteilten Root-Benutzers ohne einen seiner Gründe.

Für eine Agentur, die im Konto einer Kundin arbeitet, ist das Gegenstück zu „ladet mich ein“ eine kontoübergreifende Rolle: Die Kundin behält das Eigentum und kann sie an einer Stelle entziehen, und niemand verschickt Anmeldedaten per E-Mail.

Automatisierung: Rollen, keine Anmeldungen

Alles, was unbeaufsichtigt läuft, sollte eine Rolle annehmen, statt sich anzumelden. Auf AWS selbst heißt das Instanzprofile, Task-Rollen oder eine OIDC-Föderation von Ihrem CI-Anbieter. Das sind zeitlich begrenzte Anmeldedaten, ohne zu speicherndes Geheimnis und ohne etwas, das ein Mensch tippen muss.

Fragt ein Skript jemanden nach einem sechsstelligen Code, benutzt es die Identität eines Menschen, und es wird an dem Tag brechen, an dem dieser Mensch geht.

Langlebige Zugriffsschlüssel sind die andere Hälfte des Themas. Sie sind einzeln entziehbar und erneuerbar, was ein echter Vorteil gegenüber einem TOTP-Geheimnis ist, aber sie sind auch die Anmeldedaten, die in Commits auslaufen. Halten Sie wenige davon und rotieren Sie sie nach einem Zeitplan, den Sie wirklich einhalten.

Der Root-Benutzer: das eigentliche geteilte Konto

Root existiert, mehrere Personen müssen ihn erreichen können, und er darf nicht vom Telefon einer einzigen Person abhängen.

Registrieren Sie mehr als ein MFA-Gerät

Das ist die AWS-eigene Antwort, und sie beseitigt die Frage des Teilens vollständig. Richten Sie die App oder den Hardware-Schlüssel jeder Administratorin ein, die als Root handeln können muss. Jedes Gerät hält sein eigenes Geheimnis, und kein Geheimnis wird je kopiert. Ein Abgang ist die Abmeldung eines Geräts, nicht das Zurücksetzen der 2FA des Kontos und die Neueinrichtung für alle.

Wo ein Hardware-Schlüssel infrage kommt, ist hier der Ort, an dem er seinen Preis wert ist: Der zweite Faktor lässt sich weder fotografieren noch übertragen noch synchronisieren.

Richten Sie die Root-E-Mail auf ein Postfach, das zwei Personen lesen können

Die Wiederherstellung von Root läuft über diese Adresse. Das private Postfach eines Gründers macht das Konto an dem Tag unwiederbringlich, an dem er nicht mehr da ist: Nehmen Sie eine Verteilerliste oder ein geteiltes Postfach, und vergewissern Sie sich, dass die Lesenden Menschen sind, denen Sie die Wiederherstellung des Kontos anvertrauen würden, denn funktional gewährt diese Adresse genau das.

Löschen Sie die Root-Zugriffsschlüssel

Es sollte keine geben. Existieren welche, sind es geteilte Anmeldedaten ohne jede MFA davor, was schlimmer ist als alles andere in diesem Artikel.

Überwachen Sie die Root-Anmeldungen

CloudTrail zeichnet sie auf, und ein Alarm auf Root-Nutzung ist übliche Praxis. Auf einem gesunden Konto sind Root-Anmeldungen selten und erklärbar, was sie billig zu überwachen und wertvoll zu sehen macht.

Wenn ein geteiltes TOTP-Geheimnis doch die Antwort bleibt

Mehrere MFA-Geräte decken die meisten Fälle ab. Einige widerstehen:

• Das Konto einer Kundin, das Sie nicht verwalten, wo man Ihnen Anmeldedaten gibt, ohne dass Sie etwas umbauen können.
• Alte oder fremde Konsolen rund um AWS (ein Abrechnungsportal, ein Reseller-Panel, ein Monitoring-Dienstleister), die genau eine TOTP-Einrichtung akzeptieren.
• Eine Notfallkennung, bei der Ihr Verfahren verlangt, dass mehrere Personen sie schnell nutzen können, wo einzelne Geräte nicht praktikabel sind.

Für diese gelten die Anforderungen jedes geteilten Kontos: eine einzige Verwahrung des Geheimnisses, ein je Person gewährter Zugriff auf die Codes, ein Protokoll darüber, wer einen Code gelesen hat, und Wiederherstellungscodes, die außerhalb des Kontos liegen, das sie wiederherstellen. Die Überlegung steht in wie man 2FA-Codes im Team sicher teilt, und der Vergleich der Mechanismen in den besten Wegen, die 2FA eines geteilten Kontos zu verwalten. Dieselbe Überlegung auf einen Zahlungsdienstleister angewandt steht in die 2FA eines geteilten Stripe-Kontos verwalten.

Ein Notfallverfahren, das aufgeschrieben gehört

Für Root und für alles, was nur im Notfall dient:

1. Wer es benutzen darf, namentlich, und was es auslöst.
2. Wo die Kennung und ihr zweiter Faktor leben, und wie viele Personen jedes davon erreichen.
3. Wo die Wiederherstellungscodes sind, außerhalb des Kontos, das sie wiederherstellen.
4. Was bei der Nutzung eine Warnung auslöst, also der CloudTrail-Alarm oben.
5. Was danach geschieht: wer benachrichtigt wird, was überprüft wird, was gegebenenfalls erneuert wird.
6. Wann es zuletzt getestet wurde. Ein nie geprobtes Verfahren wird an dem Abend entdeckt, an dem jemand es braucht.

Wenn jemand ein AWS-Konto verlässt

1. Entziehen Sie die Identity-Center-Zuweisungen oder löschen Sie den IAM-Benutzer.
2. Deaktivieren und löschen Sie die Zugriffsschlüssel, auch die, die seine Werkzeuge benutzten.
3. Melden Sie sein Root-MFA-Gerät ab, falls er eines hatte.
4. Hat er je ein geteiltes TOTP-Geheimnis gehalten, setzen Sie diese 2FA zurück und ändern Sie das zugehörige Passwort. Das Geheimnis verlässt sein Telefon nicht von allein.
5. Prüfen Sie, ob er die Root-E-Mail-Adresse noch lesen kann.
6. Lesen Sie CloudTrail rund um seinen Abgang, auf der Suche nach Unerwartetem.

Schritt 5 ist der, den man vergisst. Zugang zum Root-Postfach ist Zugang zum Root-Konto, was auch immer Sie sonst entzogen haben.

Wo Share Auth steht

Eng, und mit Absicht. Für die Konten aus dem Abschnitt oben, also die Konsole einer Kundin, ein fremdes Panel, das nur eine Einrichtung akzeptiert, oder eine Notfallkennung: Das Geheimnis wird einmal eingegeben und im Ruhezustand verschlüsselt, die Personen, die die Codes brauchen, sehen den Code und seinen Countdown statt des Geheimnisses, die Berechtigungen gelten je Mitglied, und jeder Abruf wird protokolliert.

Für einen AWS-Root-Benutzer, den Sie selbst verwalten, ist ein zweites registriertes MFA-Gerät besser als alles, was ein Tresor leisten kann, unseren eingeschlossen. Tun Sie das zuerst.