Inventarisieren Sie die Integrationsidentität, bevor Sie sie rotieren
Ein Dienstkonto oder eine API-Anmeldeinformation stellt einen nicht interaktiven Zugriffspfad dar und nicht nur eine Zeichenfolge, die in einem Secret Manager gespeichert ist. Bevor Sie ein Rotationsverfahren schreiben, identifizieren Sie den Integrationseigentümer, den zulässigen Mandanten, die zulässigen Vorgänge, jeden Verbraucher und den davon abhängigen Geschäftsablauf. Ein neuer Berechtigungsnachweis mit dem falschen Umfang kann die Gefährdung erhöhen, selbst wenn die Rotation selbst ohne Ausfall abgeschlossen wird. Anforderungen sollten daher Zugriffsgrenzen und Lebenszyklus gemeinsam berücksichtigen.
In diesem Artikel werden Anforderungen für die Integration von Authentifizierungsplattformen vorgeschlagen. Es wird nicht behauptet, dass EmailAuth Dienstkonten, bereichsbezogene API-Schlüssel, überlappende Anmeldeinformationen oder eine bestimmte Secret-Management-Integration unterstützt. Es wurde kein Berechtigungsnachweis erstellt, angezeigt, übermittelt, widerrufen oder geprüft. Leitfaden zur mehrinstanzenfähigen Identität von Azure unterstützt die Trennung von Identität und Ressourcenautorisierung und -berechtigungen; Die eigentliche Plattform muss ihr eigenes unterstütztes nicht interaktives Zugriffsmodell dokumentieren.
Definieren Sie die kleinste vorgesehene Autorität
Erstellen Sie eine Integrationsinventarzeile mit der Dienstidentität, dem Geschäftszweck, der Mandantenbindung, dem Ressourcenumfang, den zulässigen Vorgängen, dem Eigentümer, den Bereitstellungsstandorten und der Referenz zu den Anmeldeinformationen. Speichern Sie nur einen Verweis auf einen genehmigten geheimen Speicherort, nicht den Anmeldeinformationswert. Unterscheiden Sie schreibgeschützte Berichte von Exporten, Konfigurationsschreibvorgängen, Benutzerverwaltung und Abrechnungsvorgängen. Eine umfassende Verwaltungsqualifikation sollte nicht nur deshalb als notwendig erachtet werden, weil sie bei einer anfänglichen Integration praktisch war.
Fordern Sie die Plattform auf, zu erklären, wie die authentifizierte Identität an einen Mandanten gebunden ist und wie jeder Vorgang diese Grenze überprüft. Ein Mandantenparameter in einer URL oder einem Anforderungstext stellt für sich genommen keine Autorisierung dar. Ein für einen Kunden verwendeter Berechtigungsnachweis darf nicht durch Änderung einer Kennung in den Geltungsbereich eines anderen Kunden gelangen. Dabei handelt es sich um vorgeschlagene Akzeptanzkriterien; Es wurde kein Live-Service geprüft und aus der Anforderung lässt sich keine aktuelle Produktfähigkeit ableiten.
Trennen Sie den Austausch von Anmeldeinformationen von der Neugestaltung des Zugriffs
Eine routinemäßige Rotation sollte normalerweise die genehmigte Autorität wahren und gleichzeitig das geheime Material ersetzen. Wenn sich durch die Migration auch Rollen, Mandantenumfang oder Ressourcenzugriff ändern, überprüfen Sie diese Änderungen explizit. Andernfalls kann ein als Wartung bezeichneter Vorgang eine Zugangserweiterung verdecken. Erfassen Sie den alten und den beabsichtigten neuen Umfang mithilfe nicht geheimer Kennungen und vergleichen Sie diese vor einer autorisierten Umstellung.
Wählen Sie den unterstützten Anmeldeinformationstyp basierend auf der aktuellen Plattformdokumentation und den Organisationsrichtlinien aus. Ein Dienstkonto, ein API-Schlüssel, ein Zertifikat oder eine Workload-Identität können unterschiedliche Ausstellungs-, Ablauf- und Widerrufseigenschaften haben. Gehen Sie nicht davon aus, dass jede Integration kurzlebige Anmeldeinformationen bietet oder dass ein Secret Manager die Anmeldeinformationen beim Zieldienst automatisch ändert. Das Zielsystem und jeder Verbraucher müssen entsprechend ihrer tatsächlichen Fähigkeiten aufeinander abgestimmt werden.
Überlappende Rotation auf Systeme übertragen, die sie unterstützen
Microsofts Tutorial zur Rotation doppelter Anmeldeinformationen demonstriert ein bestimmtes Azure Storage- und Key Vault-Muster mit zwei Anmeldeinformationen. Es erklärt einen Mechanismus zum Wechseln der Anmeldeinformationen beim Aktualisieren gespeicherter geheimer Materialien. Dies ist ein Beweis für das dokumentierte Azure-Szenario und kein Beweis dafür, dass eine beliebige Authentifizierungsplattform zwei gleichzeitig gültige API-Schlüssel oder dieselbe Rotationssequenz unterstützt.
Wenn eine Überschneidung unterstützt wird, sollte der vorgeschlagene Plan die Referenz der Ersatzberechtigungsnachweise, die zu migrierenden Verbraucher, den Nachweis, dass jeder Verbraucher den Ersatz verwendet, und den Punkt angeben, an dem die alten Berechtigungsnachweise widerrufen werden. Durch Überlappungen kann es zu Unterbrechungen kommen, es bleibt aber auch vorübergehend mehr als ein nutzbarer Berechtigungsnachweis übrig. Beschränken Sie die Gültigkeitsdauer durch einen genehmigten Plan, anstatt den alten Berechtigungsnachweis auf unbestimmte Zeit aktiv zu lassen. Wenn Überschneidungen nicht unterstützt werden, dokumentieren Sie die erwartete Unterbrechung und den autorisierten Wiederherstellungspfad, anstatt eine nahtlose Umstellung zu versprechen.
Überprüfen Sie die Migration, bevor Sie den alten Pfad widerrufen
Definieren Sie Beweise, die den erfolgreichen Einsatz des Ersatzes belegen, ohne ihn offenzulegen. Abhängig vom tatsächlichen Anbieter können dies nicht geheime Anmeldeinformations-IDs in genehmigten Protokollen, Beobachtungen zum Integrationszustand oder unterstützte Prüfereignisse sein. Eine erfolgreiche Anfrage eines Workers beweist nicht, dass alle geplanten Jobs, Hintergrund-Worker oder Disaster-Recovery-Umgebungen migriert wurden. Die Bestandsaufnahme muss jeden Verbraucher berücksichtigen oder die Deckungslücke explizit dokumentieren.
Der Widerruf ist ein separater Schritt mit eigenem Ergebnisnachweis. Das Entfernen eines Geheimnisses aus der Konfiguration einer Anwendung beweist nicht, dass der Zieldienst es ungültig gemacht hat. Umgekehrt kann ein Widerruf am Ziel vor der Migration aller Verbraucher dazu führen, dass notwendige Arbeitsabläufe unterbrochen werden. Der autorisierte Responder sollte die Disposition des alten Pfads anhand unterstützter Beweise in einer genehmigten Umgebung überprüfen. Dieser Entwurf führt keine Anfrage mit alten oder neuen Anmeldeinformationen aus.
Planen Sie Fehler und Wiederherstellung, ohne die Gefährdung blind wiederherzustellen
Definieren Sie Stoppbedingungen vor der Änderung: Unerwarteter Mandantenumfang, fehlende Prüfnachweise, unvollständiger Verbraucherbestand oder Fehler nach der Migration erfordern möglicherweise eine Unterbrechung der Umstellung. Bei der Wiederherstellung sollte zwischen einem routinemäßigen Bereitstellungsfehler und einer vermuteten Kompromittierung der Anmeldedaten unterschieden werden. Die Wiederverwendung eines bekanntermaßen kompromittierten Geheimnisses als praktisches Rollback kann die eingedämmte Gefährdung wieder einführen. Erfordern Sie eine Sicherheitsentscheidung, anstatt alle vorherigen Anmeldeinformationen als sicheres Wiederherstellungsmaterial zu behandeln.
Halten Sie den Plan frei von geheimen Werten. Protokolle und Screenshots sollten keine Autorisierungsheader, Token oder vollständigen Verbindungszeichenfolgen enthalten. Wenn sensibles Material versehentlich offengelegt wird, leiten Sie es durch den Vorfallprozess der Organisation. Kopieren Sie es nicht in einen umfassenderen Fehlerbehebungskanal. Rotationsnachweise sollten zeigen, wer die Aktion autorisiert hat, welche nicht geheime Identität geändert wurde, welche Verbraucher überprüft wurden und was der Zieldienst über den Widerruf meldet.
Ein Arbeitsblatt zur Akzeptanz des Berechtigungslebenszyklus
Erstellen Sie ein Arbeitsblatt mit Integrationsidentität, Mandant, zulässigen Aktionen, geheimer Referenz, Verbraucherliste, aktueller Anmeldeinformations-ID, wo sicher, Ersetzungsstrategie, Genehmigungseigentümer, Migrationsprüfungen und Widerrufsprüfungen. Berücksichtigen Sie das unterstützte Überlappungsmodell und das maximale geplante Überlappungsfenster als interne Entscheidung und nicht als erfundene Anbietergarantie. Notieren Sie die tatsächliche Anbieterversion oder das Dokumentationsdatum, die zum Entwerfen der Sequenz verwendet wurden.
Fügen Sie eine Zugriffsmatrix hinzu, die zulässige und verweigerte Lese-, Export-, Schreib- und Lebenszyklusvorgänge für mindestens zwei synthetische Mandantengeräte abdeckt. Die Drehung darf diese Grenzen nicht versehentlich verändern. Fügen Sie nach der Rotation eine Überprüfung ein, um sicherzustellen, dass der beabsichtigte Zugriff weiterhin funktioniert und der verweigerte Zugriff weiterhin verweigert wird. Hierbei handelt es sich um vorgeschlagene Verteidigungstests, nicht um durchgeführte Ergebnisse oder um die Erlaubnis, einen Produktionsmieter zu untersuchen. Bewahren Sie alle als offen gekennzeichneten Originalbetriebsnachweise auf, bis sie bei einem autorisierten Lauf einbehalten werden.
Fiktive Diagnose: ein übersehener Planarbeiter
Eine fiktive Berichtsintegration verfügt über einen interaktiven Worker und einen nächtlichen Aggregationsjob. Das Team aktualisiert den interaktiven Worker auf einen Ersatz-Berechtigungsnachweis und sieht erfolgreiche Anfragen. Es ist dabei, die alten Anmeldeinformationen zu widerrufen, als die Bestandsprüfung ergibt, dass der geplante Job eine separate geheime Referenz liest. Der erfolgreiche interaktive Check deckte den nächtlichen Konsumenten nicht ab.
Die vorgeschlagene Reaktion besteht darin, den Migrationsplan zu aktualisieren, alle erforderlichen Genehmigungen einzuholen und beide Verbraucher zu überprüfen, bevor der Widerruf abgeschlossen wird. Wenn der Verdacht besteht, dass die alten Anmeldedaten kompromittiert wurden, könnte der Eigentümer des Vorfalls stattdessen eine sofortige Eindämmung mit einer kontrollierten Dienstunterbrechung wählen. In diesem fiktiven Beispiel waren keine echten Anmeldedaten, Arbeiter oder Ausfälle beteiligt. Sein Zweck besteht darin, eine vollständige Verbraucherschutzversicherung von einer erfolgreichen Anfrage zu unterscheiden.
Fordern Sie vor der Veröffentlichung den Plattformnachweis an
Eine nützliche Integrationsanforderung benennt unterstützte Anmeldeinformationstypen, Bereiche, Mandantenbindung, Ausstellungsautorität, Überlappungsverhalten, Ablauf, Widerruf und Prüfnachweise. Es sollte Einschränkungen klar darlegen, anstatt ein allgemeines Cloud-Tutorial in einen EmailAuth -Funktionsanspruch zu übersetzen. Bei den Demonstrationseinstellungen des Quell-Tutorials handelt es sich nicht um universelle Rotationsintervalle oder Organisationsrichtlinien.
Der Katalog erfordert eine Zugriffsmatrix und negative Tests für mandantenübergreifende Lesevorgänge, Exporte, Schreibvorgänge und Änderungen im Benutzerlebenszyklus. Diese Tests werden weiterhin nicht durchgeführt. Auch die Prüfung durch menschliche Spezialisten, die Anwendbarkeit der Quelle, die Produktionswege, die Zugänglichkeit und die Freigabe durch den Eigentümer bleiben offen. Dieser Entwurf liefert ein vorgeschlagenes Betriebsmodell und eine fiktive Übung, keine Anmeldeinformationen, Zugangsgewährungen oder Nachweise einer abgeschlossenen Rotation.