Von Dienstkontoschlüsseln migrieren

Dienstkontoschlüssel werden häufig zur Authentifizierung bei Google Cloud-Diensten verwendet. Sie können jedoch auch zu einem Sicherheitsrisiko werden, wenn sie nicht ordnungsgemäß verwaltet werden, wodurch Ihre Sicherheitslücken wie Bedrohungen durch Datenlecks, Rechteausweitung, Offenlegung von Informationen und Nachweisbarkeit erhöht werden.

In vielen Fällen können Sie sich mit sicheren Alternativen zu Dienstkontoschlüsseln authentifizieren. Dieser Leitfaden hilft Ihnen bei der Migration von Dienstkontoschlüsseln als primärem Authentifizierungsmechanismus zur Verwendung sichererer Alternativen, mit gelegentlichen Ausnahmen, bei denen Dienstkontoschlüssel wirklich erforderlich sind.

Dieses Dokument richtet sich an Sicherheitsadministratoren, die ihre Sicherheit verbessern möchten, indem sie die Verwendung von Dienstkontoschlüsseln zugunsten sichererer Authentifizierungsmechanismen verringert. Diese Sicherheitsadministratoren sind möglicherweise für die Sicherheit vorhandener Produktionsarbeitslasten, Entwickler-Workflows und interner Prozesse verantwortlich, die Dienstkontoschlüssel verwenden.

Überblick

Das Entfernen von Dienstkontoschlüsseln aus vorhandenen Arbeitslasten erfordert eine sorgfältige Planung, um eine versehentliche Störung zu vermeiden. Der folgende Migrationsplan ermöglicht es Ihnen, zentralisierte Kontrollen zu erzwingen und Störungen für Entwickler zu minimieren.

Dieser Migrationsplan setzt sich aus drei Phasen zusammen:

Bewerten: In dieser Phase bewerten Sie Ihre vorhandene Umgebung, um zu ermitteln, wo Dienstkontoschlüssel vorhanden sind und ob die Schlüssel verwendet werden.
Planen: In dieser Phase entscheiden Sie, welche Kontrollen Sie letztendlich bereitstellen, und teilen den Migrationsplan den Beteiligten mit.
Bereitstellen: In dieser Phase beginnen Sie mit der Refaktorierung von Arbeitslasten, um sich mit sicheren Alternativen zu Dienstkontoschlüsseln zu authentifizieren. Sie erstellen auch zusätzliche Funktionen, um Ihre Umgebung kontinuierlich zu überwachen und zukünftiges Risiko zu minimieren.

Verwendung des Dienstkontoschlüssels bewerten

In dieser Phase bewerten Sie Ihre vorhandene Umgebung, um nachzuvollziehen, wo Dienstkontoschlüssel vorhanden sind und ob die Schlüssel verwendet werden.

In den folgenden Abschnitten werden die Daten beschrieben, die Sie erfassen können, um besser zu verstehen, wie Dienstkontoschlüssel in Ihrer Organisation verwendet werden.

Daten zur Schlüsselnutzung erfassen

Ermitteln Sie zuerst, wo Dienstkontoschlüssel vorhanden sind und wie sie verwendet werden.

Google Cloud bietet Tools zur Nutzung des Dienstkontos. Mit diesen Tools können Sie feststellen, welche Dienstkonten und Schlüssel kürzlich zur Authentifizierung verwendet wurden, welche Dienstkonten in den letzten 90 Tagen nicht verwendet wurden und welche Dienstkonten übermäßig privilegierte Rollen haben.

Sie können Informationen aus allen diesen Tools kombinieren, um ein besseres Bild davon zu erhalten, wie Dienstkonten und Schlüssel in Ihrem Unternehmen eingesetzt werden. Ein Beispiel für die Kombination von Informationen aus den verschiedenen Quellen in Ihrer gesamten Organisation finden Sie in der bereitstellbaren Referenzarchitektur auf GitHub. In dieser Referenzarchitektur werden Daten aus verschiedenen Tools aggregiert und zur Analyse regelmäßig in eine BigQuery-Tabelle exportiert.

In der Referenzarchitektur wird eine Datenpipeline bereitgestellt, die Cloud Asset Inventory abfragt, um Dienstkontoschlüssel in Ihrer Organisation zu identifizieren. Anschließend kombiniert die Datenpipeline diese Daten mit Daten zur Schlüssel- und Berechtigungsnutzung für das zugehörige Konto. Die resultierende Tabelle sa_key_usage hilft Ihnen, Fragen wie die folgenden zu beantworten:

Wie viele nichtflüchtige Schlüssel wurden erstellt? Diese Zahl kann als allgemeiner Messwert nützlich sein, um den Fortschritt bei der Migration von Schlüsseln zu verfolgen.
Welche Projekte und Dienstkonten verwenden Schlüssel? Anhand dieser Informationen können Sie die Inhaber von Arbeitslasten ermitteln, die Dienstkontoschlüssel verwenden.
Welche Schlüssel sind inaktiv? Sie können diese Schlüssel wahrscheinlich ohne weitere Bewertung durch Arbeitslastinhaber löschen.
Welche Schlüssel sind Dienstkonten zugeordnet, die Empfehlungen zu nicht erforderlichen Berechtigungen haben? Wenn ein Dienstkontoschlüssel mit einem zu privilegierten Dienstkonto verknüpft ist, insbesondere eines mit einer Rolle als Inhaber, Bearbeiter oder Betrachter, ist der Schlüssel möglicherweise besonders riskant. Wenn Sie nach Dienstkonten mit Rollenempfehlungen suchen, können Sie ermitteln, welche Dienstkonten zu privilegiert sind. Nachdem Sie diese Dienstkonten identifiziert haben, können Sie diese Arbeitslasten für die Migration priorisieren. Sie können die Rollenempfehlungen auch anwenden, um übermäßige Berechtigungen proaktiv zu reduzieren.

Diese Datenpipeline wird täglich ausgeführt und schreibt in eine datumspartitionierte BigQuery-Tabelle. Sie können diese Tabelle verwenden, um bestimmte Dienstkonten oder Schlüssel zu untersuchen oder den Fortschritt der Problembehebung mit einem Dashboard-Tool wie Looker Studio zu verfolgen.

Schlüsselnutzungsdaten mit zusätzlichem Kontext anreichern

Nachdem Sie das Schlüsselnutzungs-Dataset erstellt haben, können Sie es optional mit zusätzlichen Datenquellen erweitern. Wir empfehlen das Hinzufügen von Datenquellen, die Sie bereits für das Tracking der Governance und die Herkunft von Ressourcen verwenden. Je nach vorhandener Governance können Sie zusätzliche Daten hinzufügen, z. B.:

Informationen zur Inhaberschaft aus einer Konfigurationsverwaltungsdatenbank (Configuration Management Database, CMDB) oder einem ähnlichen System
In Projektlabels konfigurierte Governance-Informationen, z. B. das für ein Projekt zuständige Team oder Kostenstelle.
Umgebungsinformationen zu Schlüsseln, die für Arbeitslasten in Umgebungen außerhalb von Google Cloud verwendet werden.

Plan zur Reduzierung der Nutzung von Dienstkontoschlüsseln erstellen

Bevor Sie Änderungen bereitstellen können, um die Nutzung von Dienstkontoschlüsseln zu reduzieren, müssen Sie festlegen, welche Arbeitslasten und Umgebungen betroffen sind und wie Sie diese Änderungen durchsetzen. Außerdem müssen Sie diesen Plan unternehmensweit kommunizieren und darauf achten, dass die Inhaber der Arbeitslast den Plan unterstützen.

In den folgenden Abschnitten werden die wichtigsten Themen vorgestellt, auf die sich Ihr Plan beziehen soll. Ihr spezifischer Plan hängt von der Größe Ihrer Organisation und den spezifischen Anforderungen Ihrer Arbeitslasten ab.

Verantwortung der aktuellen Arbeitslastinhaber festlegen

Obwohl ein zentrales Sicherheitsteam bewerten kann, welche Schlüssel vorhanden sind, erfordert eine erfolgreiche Migration den Aufwand der Arbeitslastinhaber. Bei Schlüsseln für die Migration müssen Arbeitslastinhaber festlegen, welche der verfügbaren Authentifizierungsmethoden für ihren Anwendungsfall geeignet ist, und dann diese Migration ausführen.

Überlegen Sie sich, wie Sie Verbesserungen an Ihrem vorhandenen Sicherheitsstatus gegen die Arbeit von Arbeitslastinhabern ausgleichen können. In den folgenden Abschnitten werden zwei beispielhafte Ansätze beschrieben: ein Ansatz, der Verbesserungen des Sicherheitsstatus stark priorisiert und ein zweiter Fokus auf der Minimierung von Aufwand der Arbeitslastinhaber. Der tatsächliche Ansatz kann variieren. Sie können beispielsweise einzeln auswählen, welche Arbeitslasten im Geltungsbereich liegen.

Beispiel: Alle aktuellen Arbeitslasten werden für die Migration ausgewertet.

Ein möglicher Ansatz ist die Durchsetzung von Dienstkonto-Schlüsselkontrollen für alle vorhandenen und zukünftigen Arbeitslasten. Dazu sind folgende Schritte erforderlich:

Zusammenarbeit mit Arbeitslastinhabern, um die Schlüsselnutzung für vorhandene Arbeitslasten zu bewerten.
Arbeitslastinhaber migrieren alle vorhandenen Arbeitslasten mit Schlüsselnutzung, es sei denn, ihnen wurde eine Ausnahme gewährt.
Verhindern, dass alle zukünftigen Arbeitslasten Dienstkontoschlüssel verwenden, es sei denn, ihnen wurde eine Ausnahme gewährt.

Dieser Ansatz priorisiert Verbesserungen der vorhandenen Sicherheitslage, erfordert aber kurzfristig mehr Aufwand von Entwicklern und Arbeitslastinhabern. Damit Sie einen solchen Plan erfolgreich ausführen können, müssen Sie von den Arbeitslastinhabern verpflichtet werden, an der Überprüfung und Refaktorierung der Arbeitslast teilzunehmen.

Beispiel: Es werden keine aktuellen Arbeitslasten für die Migration ausgewertet.

Ein weiterer Ansatz besteht darin, vorhandenen Arbeitslasten eine automatische Ausnahme zu erlauben, damit Dienstkontoschlüssel weiterhin verwendet werden können, und nur neue Kontrollen für zukünftige Arbeitslasten angewendet werden.

Dieser Ansatz verbessert den Sicherheitsstatus zukünftiger Arbeitslasten und minimiert die Verantwortung der aktuellen Arbeitslastinhaber. Dies verbessert jedoch nicht den Sicherheitsstatus vorhandener Arbeitslasten.

Schnelle Erfolge ermitteln

Bei der Bewertung können Sie Schlüssel ermitteln, die ohne weitere Abhilfemaßnahmen von Arbeitslastinhabern sicher gelöscht werden können. Wenn ein Schlüssel beispielsweise 90 Tage lang keine Aktivität hat oder mit nicht mehr aktiven Ressourcen zusammenhängt, können Sie ihn möglicherweise sicher entfernen, ohne zu einem anderen Authentifizierungsmechanismus migrieren zu müssen. eine

Erstellen Sie eine Liste der Schlüssel, die diese Kriterien erfüllen. Sie verwenden diese Liste während der Bereitstellungsphase, um unnötige Schlüssel zu löschen. Bevor Sie einen Schlüssel zur Liste hinzufügen, prüfen Sie, ob es Anwendungsfälle gibt, in denen der Dienstkontoschlüssel selten benötigt wird, z. B. für den Notfallzugriff in der Produktion, der auf Dienstkontoschlüsseln basiert.

Planen, wo Änderungen an Organisationsrichtlinien erzwungen werden

Für eine erfolgreiche Migration von der Verwendung von Dienstkontoschlüsseln müssen Sie verhindern, dass neue Schlüssel erstellt werden. Während der Bereitstellungsphase erzwingen Sie die Einschränkung der Organisationsrichtlinie iam.disableServiceAccountKeyCreation, um das Erstellen neuer Dienstkontoschlüssel zu verhindern.

Diese Einschränkung verhindert zwar nicht die Verwendung vorhandener Schlüssel, kann aber bestehende Arbeitslasten beeinträchtigen, die ihre Schlüssel regelmäßig rotieren. Entscheiden Sie vor Beginn der Bereitstellungsphase, wo Sie sie in Ihrer Ressourcenhierarchie erzwingen, um Störungen zu minimieren.

Möglicherweise möchten Sie die Einschränkung zuerst auf Projekt- oder Ordnerebene statt auf Organisationsebene erzwingen. Sie können beispielsweise die Einschränkung für den Ordner erzwingen, der für Ihre Entwicklungsumgebung verwendet wird, bevor Sie sie in Produktionsordnern bereitstellen. In einer großen Organisation mit vielen Teams können Sie zuerst die Einschränkung für einen Ordner für ein einzelnes Team erzwingen und dann die Einschränkung für zusätzliche Ordner erzwingen, wenn Sie diese migrieren.

Sie können Organisationsrichtlinien mit Tags verwenden, um Organisationsrichtlinien auf Projekt- oder Ordnerebene bedingt zu erzwingen.

Ausnahmeprozess entwerfen

Obwohl das Ziel dieser Migration darin besteht, die Verwendung von Dienstkontoschlüsseln zu reduzieren oder zu vermeiden, gibt es einige legitime Anwendungsfälle, die Dienstkontoschlüssel erfordern. Auch wenn für keine vorhandenen Arbeitslasten Dienstkontoschlüssel erforderlich sind, sind zukünftige Arbeitslasten möglich. Daher müssen Sie einen operativen Prozess definieren, um Ausnahmen für Anwendungsfälle zu bewerten und zu genehmigen, die Dienstkontoschlüssel erfordern.

Definieren Sie einen Prozess für Arbeitslastinhaber, um eine Ausnahme anzufordern, mit der ihre Arbeitslast Dienstkontoschlüssel verwenden kann. Stellen Sie sicher, dass die Entscheidungsträger, die für eine Ausnahme zuständig sind, das technische Wissen haben, um den Anwendungsfall zu validieren. Wenden Sie sich an die Arbeitslastinhaber, um zu erfahren, welche der Alternativen zu Dienstkontoschlüsseln möglicherweise besser geeignet ist. Außerdem empfehlen wir Arbeitslastinhabern die Best Practices für die Verwaltung von Dienstkontoschlüsseln.

Anstehende Änderungen für Arbeitslastinhaber kommunizieren

Nachdem Sie einen Plan entwickelt haben, müssen Sie diesen Plan im gesamten Unternehmen klar kommunizieren und sicherstellen, dass Stakeholder, insbesondere Führungskräfte, bereit sind, sich für die Migration zu verpflichten.

Während die spezifischen Migrationsdetails für Ihre Organisation variieren, sollten Sie die folgenden Themen in Ihren Kommunikationsplan aufnehmen:

Die negativen Auswirkungen von unsicheren Dienstkontoschlüsseln auf die Organisation und die Motivationen, die Ihre Migration von Dienstkontoschlüsseln fördern.
Mit den neuen Sicherheitskontrollen wird verhindert, dass Dienstkontoschlüssel erstellt werden, und wie sich dies auf vorhandene Prozesse auswirken kann.
Anleitung für Entwickler zur Identifizierung sichererer Alternativen zu Dienstkontoschlüsseln
Der Prozess für Teams, eine Ausnahme anzufordern, um Dienstkontoschlüssel zuzulassen, einschließlich der Häufigkeit, mit der diese Ausnahme neu ausgewertet wird.
Zeitplan zur Durchsetzung der vorgeschlagenen Änderungen.

Arbeiten Sie mit den Arbeitslastinhabern zusammen, um Ihren Plan zu optimieren und sicherzustellen, dass er in der gesamten Organisation funktioniert.

Steuerelemente bereitstellen und Arbeitslasten refaktorieren

Nachdem Sie einen Plan erstellt und den Arbeitslastinhabern mitgeteilt haben, können Sie mit der Migration von Dienstkontoschlüsseln beginnen.

In dieser Phase beginnen Sie mit der Refaktorierung der Arbeitslasten, damit diese sich mit sichereren Alternativen zu Dienstkontoschlüsseln authentifizieren können. Sie erstellen auch zusätzliche Funktionen, um Ihre Umgebung kontinuierlich zu überwachen und zukünftiges Risiko zu minimieren.

In den folgenden Abschnitten werden die Schritte beschrieben, mit denen Sie Arbeitslasten refaktorieren und Schlüssel mit minimaler Störung löschen können. Sie können diese Schritte in beliebiger Reihenfolge ausführen, je nach Priorität und Aufwand für Ihre Organisation.

Steuerelemente erzwingen, um die Erstellung neuer Dienstkontoschlüssel zu beenden

Wenn Sie die Erstellung neuer Dienstkontoschlüssel beenden möchten, erzwingen Sie die Einschränkung der Organisationsrichtlinie iam.disableServiceAccountKeyCreation.

Bevor Sie diese Einschränkung erzwingen, müssen Sie jedoch Tags zu allen Projekten oder Ordnern hinzufügen, die von der Richtlinie ausgenommen werden sollen. Sie können Ausnahmen für vorhandene Arbeitslasten zulassen, die nicht von Dienstkontoschlüsseln migriert werden können, oder für neue Arbeitslasten, die einen berechtigten Grund haben, sich nur mit Dienstkontoschlüsseln zu authentifizieren.

Nachdem Sie Tags zu ausgenommenen Projekten und Ordnern hinzugefügt haben, können Sie eine Organisationsrichtlinie mit Tags festlegen, um die Einschränkung iam.disableServiceAccountKeyCreation für nicht ausgenommene Projekte und Ordner zu erzwingen.

So verhindern Sie das Erstellen von Dienstkontoschlüsseln in allen nicht ausgenommenen Projekten und Ordnern:

Prüfen Sie, ob Sie die erforderlichen IAM-Rollen zum Verwalten von Tags und Organisationsrichtlinien auf Organisationsebene haben.
Erstellen Sie auf Organisationsebene einen Tag-Schlüssel und einen Tag-Wert, mit denen Sie festlegen, ob ein Projekt oder ein Ordner von der Organisationsrichtlinie ausgenommen werden soll. Wir empfehlen, ein Tag mit dem Schlüssel disableServiceAccountKeyCreation und den Werten enforced und not_enforced zu erstellen.

Informationen zum Erstellen von Tag-Schlüsseln und -Werten finden Sie unter Neues Tag erstellen und definieren.
Hängen Sie das Tag disableServiceAccountKeyCreation an die Organisation an und legen Sie es auf den Wert enforced fest. Alle Projekte oder Ordner in der Organisation übernehmen diesen Tag-Wert, sofern er nicht mit einem anderen Tag-Wert überschrieben wird.

Informationen zum Anhängen von Tags an Ressourcen finden Sie unter Tags an Ressourcen anhängen.
Hängen Sie für jedes Projekt oder jeden Ordner, den Sie von der Organisationsrichtlinie ausschließen möchten, das Tag disableServiceAccountKeyCreation an und legen Sie als Wert not_enforced fest. Wenn Sie einen Tag-Wert für ein Projekt oder einen Ordner auf diese Weise festlegen, wird der von der Organisation übernommene Tag-Wert überschrieben.
Erstellen Sie eine Organisationsrichtlinie, die das Erstellen von Dienstkontoschlüsseln für alle Ressourcen außer den ausgenommenen Ressourcen verhindert. Diese Richtlinie sollte die folgenden Regeln enthalten:
- Konfigurieren Sie die Einschränkung iam.disableServiceAccountKeyCreation so, dass sie für Ressourcen mit dem Tag disableServiceAccountKeyCreation: not_enforced nicht erzwungen wird. Die Bedingung in dieser Regel sollte so aussehen:
```
resource.matchTag(\"ORGANIZATION_ID/disableServiceAccountKeyCreation\", \"not_enforced\")
```
- Konfigurieren Sie die Einschränkung iam.disableServiceAccountKeyCreation so, dass sie für alle anderen Ressourcen erzwungen wird.
Informationen zum Erstellen von Organisationsrichtlinien mit Tag-Bedingungen finden Sie unter Organisationsrichtlinie mit Tags festlegen.

Vorhandene Arbeitslasten beheben

Arbeiten Sie mit jeder Arbeitslast zusammen, die Dienstkontoschlüssel verwendet, um eine alternative Authentifizierungsmethode auszuwählen und zu implementieren.

Wenn Sie auf Google Cloud-Dienste über die Google Cloud CLI, Cloud-Clientbibliotheken und Tools zugreifen, die Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) wie Terraform oder REST unterstützen, verwenden Sie das folgende Diagramm, um eine Authentifizierungsmethode auszuwählen:

Entscheidungsbaum zur Auswahl der Authentifizierungsmethode anhand des Anwendungsfalls

Dieses Diagramm führt Sie durch die folgenden Fragen:

Führen Sie Code in einer Entwicklungsumgebung für einzelne Nutzer aus, z. B. Ihrer eigenen Workstation, Cloud Shell oder einer virtuellen Desktop-Oberfläche?
1. Falls ja, fahren Sie mit Frage 4 fort.
2. Falls nein, fahren Sie mit Frage 2 fort.
Führen Sie Code in Google Cloud aus?
1. Falls ja, fahren Sie mit Frage 3 fort.
2. Falls nein, fahren Sie mit Frage 5 fort.
Führen Sie Container in Google Kubernetes Engine oder GKE Enterprise aus?
1. Wenn ja, verwenden Sie die Identitätsföderation von Arbeitslasten für GKE, um Dienstkonten an Kubernetes-Pods anzuhängen.
2. Falls nicht, fügen Sie der Ressource ein Dienstkonto hinzu.
Erfordert Ihr Anwendungsfall ein Dienstkonto?

Sie können beispielsweise die Authentifizierung und Autorisierung für Ihre Anwendung in allen Umgebungen konsistent konfigurieren.
1. Falls nein, authentifizieren Sie sich mit Nutzeranmeldedaten.
2. Falls ja, übernehmen Sie die Identität eines Dienstkontos mit Nutzeranmeldedaten.
Wird Ihre Arbeitslast bei einem externen Identitätsanbieter authentifiziert, der die Identitätsföderation von Arbeitslasten unterstützt?
1. Falls ja, konfigurieren Sie die Identitätsföderation von Arbeitslasten, damit Anwendungen, die lokal oder auf anderen Cloud-Anbietern ausgeführt werden, ein Dienstkonto verwenden können.
2. Falls nicht, erstellen Sie einen Dienstkontoschlüssel.

In einigen Fällen können Sie nur die Authentifizierungsmethode außer Dienstkontoschlüsseln verwenden. Beispiele, in denen ein Dienstkontoschlüssel die einzige mögliche Option ist, sind:

Sie verwenden kommerzielle Standardprodukte (COTS) oder Software-as-a-Service-Anwendungen (SaaS), in denen Sie aufgefordert werden, einen Google Cloud-Dienstkontoschlüssel direkt in die Benutzeroberfläche einzugeben.
Ihre Arbeitslast wird außerhalb von Google Cloud ausgeführt und ist nicht bei einem Identitätsanbieter authentifiziert, der die Identitätsföderation von Arbeitslasten unterstützen kann.

Wenn Sie Dienstkontoschlüssel weiterhin verwenden müssen, folgen Sie den Best Practices für die Verwaltung von Dienstkontoschlüsseln.

Möglicherweise entscheiden Sie auch, bestimmte Arbeitslasten nicht zu beheben, da Sie feststellen, dass das Risiko der Verwendung von Dienstkontoschlüsseln nicht die Kosten für den Wechsel zu einer anderen Authentifizierungsmethode rechtfertigen.

Unnötige Schlüssel löschen

Wenn Sie sicher sind, dass ein Dienstkontoschlüssel nicht benötigt wird, sollten Sie den Schlüssel löschen. Zu den unnötigen Schlüsseln gehören:

Schlüssel ohne aktuelle Nutzung oder Schlüssel, die sich auf nicht verwendete Ressourcen beziehen, die Sie im Abschnitt Schnelle Erfolge ermitteln auf dieser Seite identifiziert haben.
Schlüssel für Arbeitslasten, die zu anderen Authentifizierungsmethoden migriert wurden.

Nachdem Sie alle Dienstkontoschlüssel in einem Projekt gelöscht haben, müssen Sie für dieses Projekt die Einschränkung iam.disableServiceAccountKeyCreation erzwingen. Wenn das Projekt zuvor von dieser Einschränkung ausgenommen wurde, entfernen Sie das Tag, das für die Ausnahme zulässig ist.

Um Schlüssel sicher zu löschen, empfehlen wir Ihnen, den Schlüssel zu deaktivieren, bevor Sie ihn löschen. Das Löschen kann nicht rückgängig gemacht werden. Wenn Sie es jedoch deaktivieren, können Sie den Schlüssel schnell wieder aktivieren, wenn Sie unerwartete Probleme feststellen. Warten Sie nach dem Deaktivieren des Schlüssels, bis Sie sicher sind, dass das Entfernen des Schlüssels keine Probleme verursacht, und löschen Sie den Schlüssel dann. Wenn Sie nach dem Deaktivieren des Schlüssels unerwartete Probleme feststellen, den Schlüssel wieder aktivieren, die Probleme beheben und den Vorgang wiederholen, bis Sie den Schlüssel sicher löschen können.

Integrierte Steuerelemente verwenden, um auf gehackte Schlüssel zu reagieren

Google Cloud bietet verschiedene Tools und Dienste, mit denen Sie gehackte Dienstkontoschlüssel erkennen und darauf reagieren können. Ziehen Sie die folgenden Mechanismen in Betracht, um auf gehackte Dienstkontoschlüssel zu reagieren:

Aktivieren Sie die Anomalieerkennung für Security Command Center, um öffentliche Repositories nach Schlüsseln zu scannen. Bei diesem Scan wird ein account_has_leaked_credentials erstellt, das feststellt, ob gehackte Schlüssel erkannt wurden.
Lesen Sie das Securitymining Protection Program von Security Command Center und achten Sie darauf, dass Sie die technischen Voraussetzungen für die Teilnahme erfüllen. Der Mining von Kryptowährungs-Mining ist ein häufiger Exploit, wenn Anmeldedaten gehackt werden.
Konfigurieren Sie Wichtige Kontakte so, dass Ihr Sicherheitsteam Sicherheitsbenachrichtigungen von Google Cloud erhält, einschließlich Missbrauch, der durch manipulierte Schlüssel verursacht wird. Achten Sie darauf, dass die E-Mail-Adresse überwacht wird und nicht von einzelnen Nutzern als Single Point Of Failure abhängig ist.

Weitere Informationen zum Vorfallmanagement finden Sie unter Gemeinsamen Prozess für Vorfallmanagement erstellen.

Kontinuierliche Verbesserungen bei der Dienstkontoverwaltung

Implementieren Sie nach Möglichkeit Best Practices für die Verwaltung von Dienstkontoschlüsseln. Durch die Verbesserung Ihrer Prozesse zur Schlüsselverwaltung können Sie das Risiko von verbleibenden Dienstkontoschlüsseln in Ihrer Organisation verringern.