Empfehlungen für Identitäts- und Zugriffssicherheit

In diesem Artikel werden alle Identitäts- und Zugriffssicherheitsempfehlungen aufgeführt, die in Microsoft Defender für Cloud möglicherweise angezeigt werden.

Die Empfehlungen, die in Ihrer Umgebung angezeigt werden, basieren auf den Ressourcen, die Sie schützen und auf Ihrer angepassten Konfiguration.

Informationen zu Aktionen, die Sie als Reaktion auf diese Empfehlungen ausführen können, finden Sie unter "Korrekturempfehlungen" in Defender für Cloud.

Tipp

Wenn eine Empfehlungsbeschreibung keine verwandte Richtlinie besagt, liegt dies in der Regel daran, dass diese Empfehlung von einer anderen Empfehlung abhängig ist.

Die Empfohlene Endpunktschutz-Integritätsfehler sollten beispielsweise behoben werden, indem empfohlen wird, dass überprüft wird, ob eine Endpunktschutzlösung installiert ist (Endpunktschutzlösung sollte installiert werden). Die zugrunde liegende Empfehlung verfügt über eine Richtlinie. Das Einschränken von Richtlinien auf grundlegende Empfehlungen vereinfacht die Richtlinienverwaltung.

Azure-Identitäts- und Zugriffsempfehlungen

Für Abonnements dürfen maximal 3 Besitzer festgelegt werden.

Beschreibung: Um das Risiko von Verstößen durch kompromittierte Besitzerkonten zu verringern, empfehlen wir, die Anzahl der Besitzerkonten auf maximal 3 zu beschränken (verwandte Richtlinie: Maximal 3 Besitzer sollten für Ihr Abonnement festgelegt werden).

Schweregrad: hoch

Konten mit Besitzerberechtigungen für Azure-Ressourcen sollten MFA-fähig sein

Beschreibung: Wenn Sie nur Kennwörter verwenden, um Ihre Benutzer zu authentifizieren, lassen Sie einen Angriffsvektor offen. Benutzer verwenden oft schwache Kennwörter für mehrere Dienste. Durch die Aktivierung der mehrstufigen Authentifizierung (MultiFactor Authentication , MFA) bieten Sie eine bessere Sicherheit für Ihre Konten, während Ihre Benutzer sich weiterhin bei fast jeder Anwendung mit einmaligem Anmelden (Single Sign-On, SSO) authentifizieren können. Die mehrstufige Authentifizierung ist ein Prozess, mit dem Benutzer während des Anmeldevorgangs zur Identifizierung aufgefordert werden. Beispielsweise kann ein Code an sein Mobiltelefon gesendet werden, oder er wird um einen Fingerabdruckscan gebeten. Wir empfehlen Ihnen, MFA für alle Konten zu aktivieren, die über Besitzerberechtigungen für Azure-Ressourcen verfügen, um Sicherheitsverletzung und Angriffe zu verhindern. Weitere Details und häufig gestellte Fragen finden Sie hier: Verwalten der Erzwingung der mehrstufigen Authentifizierung (MFA) für Ihre Abonnements (keine zugehörige Richtlinie).

Schweregrad: hoch

Konten mit Leseberechtigungen für Azure-Ressourcen sollten MFA-fähig sein

Beschreibung: Wenn Sie nur Kennwörter verwenden, um Ihre Benutzer zu authentifizieren, lassen Sie einen Angriffsvektor offen. Benutzer verwenden oft schwache Kennwörter für mehrere Dienste. Durch die Aktivierung der mehrstufigen Authentifizierung (MultiFactor Authentication , MFA) bieten Sie eine bessere Sicherheit für Ihre Konten, während Ihre Benutzer sich weiterhin bei fast jeder Anwendung mit einmaligem Anmelden (Single Sign-On, SSO) authentifizieren können. Die mehrstufige Authentifizierung ist ein Prozess, mit dem Benutzer während des Anmeldevorgangs zur Eingabe einer zusätzlichen Identifikation aufgefordert werden. Beispielsweise kann ein Code an sein Mobiltelefon gesendet werden, oder er wird um einen Fingerabdruckscan gebeten. Wir empfehlen Ihnen, MFA für alle Konten zu aktivieren, die über Leseberechtigungen für Azure-Ressourcen verfügen, um Sicherheitsverletzung und Angriffe zu verhindern. Weitere Details und häufig gestellte Fragen finden Sie hier. (Keine zugehörige Richtlinie)

Schweregrad: hoch

Konten mit Schreibberechtigungen für Azure-Ressourcen sollten MFA-fähig sein

Beschreibung: Wenn Sie nur Kennwörter verwenden, um Ihre Benutzer zu authentifizieren, lassen Sie einen Angriffsvektor offen. Benutzer verwenden oft schwache Kennwörter für mehrere Dienste. Durch die Aktivierung der mehrstufigen Authentifizierung (MultiFactor Authentication , MFA) bieten Sie eine bessere Sicherheit für Ihre Konten, während Ihre Benutzer sich weiterhin bei fast jeder Anwendung mit einmaligem Anmelden (Single Sign-On, SSO) authentifizieren können. Die mehrstufige Authentifizierung ist ein Prozess, mit dem Benutzer während des Anmeldevorgangs zur Eingabe einer zusätzlichen Identifikation aufgefordert werden. Beispielsweise kann ein Code an sein Mobiltelefon gesendet werden, oder er wird um einen Fingerabdruckscan gebeten. Wir empfehlen Ihnen, MFA für alle Konten zu aktivieren, die über Schreibberechtigungen für Azure-Ressourcen verfügen, um Sicherheitsverletzung und Angriffe zu verhindern. Weitere Details und häufig gestellte Fragen finden Sie hier: Verwalten der Erzwingung der mehrstufigen Authentifizierung (MFA) für Ihre Abonnements (keine zugehörige Richtlinie).

Schweregrad: hoch

Azure Cosmos DB-Konten sollten Azure Active Directory als einzige Authentifizierungsmethode verwenden

Beschreibung: Die beste Methode zur Authentifizierung bei Azure-Diensten ist die Verwendung der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC). RBAC ermöglicht es Ihnen, das Prinzip der minimalen Berechtigungen beizubehalten, und unterstützt die Fähigkeit, kompromittierte Berechtigungen als wirksame Reaktionsmethode zu widerrufen. Sie können Ihr Azure Cosmos DB-Konto so konfigurieren, dass RBAC als einzige Authentifizierungsmethode erzwungen wird. Wenn die Erzwingung konfiguriert ist, werden alle anderen Zugriffsmethoden verweigert (Primärschlüssel/Sekundärschlüssel und Zugriffstoken). (Keine zugehörige Richtlinie)

Schweregrad: Mittel

Gesperrte Konten mit Besitzerberechtigungen für Azure-Ressourcen sollten entfernt werden

Beschreibung: Konten, die für die Anmeldung bei Active Directory gesperrt wurden, sollten aus Ihren Azure-Ressourcen entfernt werden. Diese Konten können Ziele für Angreifer sein, die versuchen, unbemerkt auf Ihre Daten zuzugreifen. (Keine zugehörige Richtlinie)

Schweregrad: hoch

Gesperrte Konten mit Lese- und Schreibberechtigungen für Azure-Ressourcen sollten entfernt werden

Beschreibung: Konten, die für die Anmeldung bei Active Directory gesperrt wurden, sollten aus Ihren Azure-Ressourcen entfernt werden. Diese Konten können Ziele für Angreifer sein, die versuchen, unbemerkt auf Ihre Daten zuzugreifen. (Keine zugehörige Richtlinie)

Schweregrad: hoch

Veraltete Konten müssen aus Abonnements entfernt werden.

Beschreibung: Benutzerkonten, die für die Anmeldung gesperrt wurden, sollten aus Ihren Abonnements entfernt werden. Diese Konten können Ziele für Angreifer sein, die versuchen, unbemerkt auf Ihre Daten zuzugreifen. (Verwandte Richtlinie: Veraltete Konten sollten aus Ihrem Abonnement entfernt werden).

Schweregrad: hoch

Veraltete Konten mit Besitzerberechtigungen sollten aus Abonnements entfernt werden.

Beschreibung: Benutzerkonten, die für die Anmeldung gesperrt wurden, sollten aus Ihren Abonnements entfernt werden. Diese Konten können Ziele für Angreifer sein, die versuchen, unbemerkt auf Ihre Daten zuzugreifen. (Verwandte Richtlinie: Veraltete Konten mit Besitzerberechtigungen sollten aus Ihrem Abonnement entfernt werden.

Schweregrad: hoch

Diagnoseprotokolle in Key Vault sollten aktiviert sein

Beschreibung: Aktivieren Sie Protokolle, und bewahren Sie sie für bis zu einem Jahr auf. Auf diese Weise können Sie vergangene Aktivitäten nachvollziehen, wenn Sie Sicherheitsincidents untersuchen oder Ihr Netzwerk gefährdet ist. (Verwandte Richtlinie: Diagnoseprotokolle im Key Vault sollten aktiviert sein).

Schweregrad: Niedrig

Externe Konten mit Besitzerberechtigungen sollten aus Abonnements entfernt werden.

Beschreibung: Konten mit Besitzerberechtigungen, die über unterschiedliche Domänennamen (externe Konten) verfügen, sollten aus Ihrem Abonnement entfernt werden. Auf diese Weise wird der nicht überwachte Zugriff verhindert. Diese Konten können Ziele für Angreifer sein, die versuchen, unbemerkt auf Ihre Daten zuzugreifen. (Verwandte Richtlinie: Externe Konten mit Besitzerberechtigungen sollten aus Ihrem Abonnement entfernt werden.

Schweregrad: hoch

Externe Konten mit Leseberechtigungen müssen aus den Abonnements entfernt werden.

Beschreibung: Konten mit Leseberechtigungen, die unterschiedliche Domänennamen (externe Konten) aufweisen, sollten aus Ihrem Abonnement entfernt werden. Auf diese Weise wird der nicht überwachte Zugriff verhindert. Diese Konten können Ziele für Angreifer sein, die versuchen, unbemerkt auf Ihre Daten zuzugreifen. (Verwandte Richtlinie: Externe Konten mit Leseberechtigungen sollten aus Ihrem Abonnement entfernt werden.

Schweregrad: hoch

Externe Konten mit Schreibberechtigungen müssen aus Abonnements entfernt werden.

Beschreibung: Konten mit Schreibberechtigungen, die über unterschiedliche Domänennamen (externe Konten) verfügen, sollten aus Ihrem Abonnement entfernt werden. Auf diese Weise wird der nicht überwachte Zugriff verhindert. Diese Konten können Ziele für Angreifer sein, die versuchen, unbemerkt auf Ihre Daten zuzugreifen. (Verwandte Richtlinie: Externe Konten mit Schreibberechtigungen sollten aus Ihrem Abonnement entfernt werden.

Schweregrad: hoch

Für Key Vault muss eine Firewall aktiviert werden.

Beschreibung: Die Firewall des Schlüsseltresors verhindert, dass nicht autorisierter Datenverkehr Ihren Schlüsseltresor erreicht und bietet eine zusätzliche Schutzebene für Ihre geheimen Schlüssel. Aktivieren Sie die Firewall, um sicherzustellen, dass nur Datenverkehr aus zulässigen Netzwerken auf Ihren Schlüsseltresor zugreifen kann. (Verwandte Richtlinie: Die Firewall sollte im Key Vault aktiviert sein.

Schweregrad: Mittel

Konten mit Besitzerberechtigungen für Azure-Ressourcen sollten entfernt werden.

Beschreibung: Konten mit Besitzerberechtigungen, die außerhalb des Azure Active Directory-Mandanten (unterschiedliche Domänennamen) bereitgestellt wurden, sollten aus Ihren Azure-Ressourcen entfernt werden. Gastkonten werden nicht mit den gleichen Standards wie Unternehmensmandantenidentitäten verwaltet. Diese Konten können Ziele für Angreifer sein, die versuchen, unbemerkt auf Ihre Daten zuzugreifen. (Keine zugehörige Richtlinie)

Schweregrad: hoch

Gastkonten mit Leseberechtigungen für Azure-Ressourcen sollten entfernt werden

Beschreibung: Konten mit Leseberechtigungen, die außerhalb des Azure Active Directory-Mandanten (verschiedene Domänennamen) bereitgestellt wurden, sollten aus Ihren Azure-Ressourcen entfernt werden. Gastkonten werden nicht mit den gleichen Standards wie Unternehmensmandantenidentitäten verwaltet. Diese Konten können Ziele für Angreifer sein, die versuchen, unbemerkt auf Ihre Daten zuzugreifen. (Keine zugehörige Richtlinie)

Schweregrad: hoch

Gastkonten mit Schreibberechtigungen für Azure-Ressourcen sollten entfernt werden

Beschreibung: Konten mit Schreibberechtigungen, die außerhalb des Azure Active Directory-Mandanten (unterschiedliche Domänennamen) bereitgestellt wurden, sollten aus Ihren Azure-Ressourcen entfernt werden. Gastkonten werden nicht mit den gleichen Standards wie Unternehmensmandantenidentitäten verwaltet. Diese Konten können Ziele für Angreifer sein, die versuchen, unbemerkt auf Ihre Daten zuzugreifen. (Keine zugehörige Richtlinie)

Schweregrad: hoch

Key Vault-Schlüssel sollten ein Ablaufdatum aufweisen.

Beschreibung: Kryptografieschlüssel sollten ein definiertes Ablaufdatum aufweisen und nicht dauerhaft sein. Schlüssel, die immer gültig sind, bieten einem potenziellen Angreifer mehr Zeit, um den Schlüssel zu kompromittieren. Es empfiehlt sich, Ablaufdaten für kryptografische Schlüssel festzulegen. (Verwandte Richtlinie: Schlüsseltresorschlüssel sollten ein Ablaufdatum haben).

Schweregrad: hoch

Key Vault-Geheimnisse sollten ein Ablaufdatum aufweisen.

Beschreibung: Geheime Schlüssel sollten ein definiertes Ablaufdatum haben und nicht dauerhaft sein. Geheimnisse, die immer gültig sind, bieten einem potenziellen Angreifer mehr Zeit, sie zu kompromittieren. Es empfiehlt sich, Ablaufdaten für geheime Schlüssel festzulegen. (Verwandte Richtlinie: Schlüsseltresorschlüssel sollten ein Ablaufdatum haben).

Schweregrad: hoch

Für Schlüsseltresore sollte der Löschschutz aktiviert sein.

Beschreibung: Böswillige Löschung eines Schlüsseltresors kann zu dauerhaftem Datenverlust führen. Ein böswilliger Insider in Ihrer Organisation kann möglicherweise Schlüsseltresore löschen oder bereinigen. Der Löschschutz schützt Sie vor Insiderangriffen, indem ein verbindlicher Aufbewahrungszeitraum für vorläufig gelöschte Schlüsseltresore durchgesetzt wird. Niemand innerhalb Ihrer Organisation oder von Microsoft kann Ihre Schlüsseltresore während des Aufbewahrungszeitraums für vorläufiges Löschen löschen. (Verwandte Richtlinie: Schlüsseltresor sollten den Löschschutz aktiviert haben).

Schweregrad: Mittel

Für Schlüsseltresore sollte vorläufiges Löschen aktiviert sein.

Beschreibung: Durch das Löschen eines Schlüsseltresors ohne vorläufiges Löschen werden alle geheimen Schlüssel, Schlüssel und Zertifikate, die im Schlüsseltresor gespeichert sind, endgültig gelöscht. Das versehentliche Löschen eines Schlüsseltresors kann zu dauerhaftem Datenverlust führen. Vorläufiges Löschen ermöglicht es Ihnen, einen versehentlich gelöschten Schlüsseltresor innerhalb des konfigurierbaren Aufbewahrungszeitraums wiederherzustellen. (Verwandte Richtlinie: Schlüsseltresor sollten "Vorläufig löschen" aktiviert sein.

Schweregrad: hoch

Für Konten mit Besitzerberechtigungen für Abonnements muss MFA aktiviert sein.

Beschreibung: Die mehrstufige Authentifizierung (Multifactor Authentication, MFA) sollte für alle Abonnementkonten mit Besitzerberechtigungen aktiviert werden, um eine Verletzung von Konten oder Ressourcen zu verhindern. (Verwandte Richtlinie: MFA sollte für Konten mit Besitzerberechtigungen für Ihr Abonnement aktiviert sein).

Schweregrad: hoch

Für Konten mit Leseberechtigungen für Abonnements muss MFA aktiviert sein.

Beschreibung: Die mehrstufige Authentifizierung (Multifactor Authentication, MFA) sollte für alle Abonnementkonten mit Leseberechtigungen aktiviert werden, um eine Verletzung von Konten oder Ressourcen zu verhindern. (Verwandte Richtlinie: MFA sollte für Konten mit Leseberechtigungen für Ihr Abonnement aktiviert sein).

Schweregrad: hoch

Für Konten mit Schreibberechtigungen für Abonnements muss MFA aktiviert sein.

Beschreibung: Die mehrstufige Authentifizierung (Multifactor Authentication, MFA) sollte für alle Abonnementkonten mit Schreibberechtigungen aktiviert werden, um einen Verstoß gegen Konten oder Ressourcen zu verhindern. (Verwandte Richtlinie: MFA sollte Konten mit Schreibberechtigungen für Ihr Abonnement aktiviert sein).

Schweregrad: hoch

Microsoft Defender für Key Vault muss aktiviert sein.

Beschreibung: Microsoft Defender für Cloud umfasst Microsoft Defender für Key Vault und stellt eine zusätzliche Sicherheitsintelligenzebene bereit. Microsoft Defender für Key Vault erkennt ungewöhnliche und potenziell schädliche Versuche, auf Key Vault-Konten zuzugreifen oder diese missbräuchlich zu nutzen.

Auf der Seite "Defender-Pläne " werden Schutzmaßnahmen gegen diesen Plan in Rechnung gestellt. Wenn Sie in diesem Abonnement über keine Schlüsseltresore verfügen, fallen keine Gebühren an. Wenn Sie später Schlüsseltresore in diesem Abonnement erstellen, werden diese automatisch geschützt, und ab diesem Zeitpunkt werden Gebühren abgerechnet. Weitere Informationen finden Sie in den Preisen pro Region. Weitere Informationen finden Sie unter Einführung in Microsoft Defender für Key Vault. (Verwandte Richtlinie: Azure Defender für Key Vault sollte aktiviert sein).

Schweregrad: hoch

Berechtigungen von inaktiven Identitäten in Ihrem Azure-Abonnement sollten widerrufen werden.

Beschreibung: Microsoft Defender für Cloud hat eine Identität entdeckt, die in den letzten 45 Tagen keine Aktion für eine Ressource innerhalb Ihres Azure-Abonnements ausgeführt hat. Es wird empfohlen, Berechtigungen für inaktive Identitäten zu widerrufen, um die Angriffsfläche Ihrer Cloudumgebung zu verringern.

Schweregrad: Mittel

Für Key Vault muss ein privater Endpunkt konfiguriert werden.

Beschreibung: Der private Link bietet eine Möglichkeit, Key Vault mit Ihren Azure-Ressourcen zu verbinden, ohne Datenverkehr über das öffentliche Internet zu senden. Der private Link bietet umfassenden Schutz vor Datenexfiltration. (Verwandte Richtlinie: Privater Endpunkt sollte für Key Vault konfiguriert werden.

Schweregrad: Mittel

Der öffentliche Zugriff auf Speicherkonten muss untersagt sein

Beschreibung: Anonymer öffentlicher Lesezugriff auf Container und Blobs in Azure Storage ist eine bequeme Möglichkeit zum Freigeben von Daten, kann jedoch Sicherheitsrisiken darstellen. Um Datenverletzungen durch unerwünschten anonymen Zugriff zu verhindern, empfiehlt Microsoft, den öffentlichen Zugriff auf ein Speicherkonto zu verhindern, sofern dies für Ihr Szenario nicht erforderlich ist. (Verwandte Richtlinie: Der öffentliche Zugriff des Speicherkontos sollte unzulässig sein.

Schweregrad: Mittel

Den Abonnements muss mehr als ein Besitzer zugewiesen sein.

Beschreibung: Legen Sie mehr als einen Abonnementbesitzer fest, um über Redundanz des Administratorzugriffs verfügen zu können. (Verwandte Richtlinie: Ihrem Abonnement sollte mehr als ein Besitzer zugewiesen sein).

Schweregrad: hoch

Gültigkeitszeitraum für in Azure Key Vault gespeicherte Zertifikate sollte zwölf Monate nicht überschreiten

Beschreibung: Stellen Sie sicher, dass Ihre Zertifikate keinen Gültigkeitszeitraum haben, der 12 Monate überschreitet. (Verwandte Richtlinie: Zertifikate sollten den angegebenen Gültigkeitszeitraum haben.

Schweregrad: Mittel

Azure-überprovisionierte Identitäten sollten nur über die erforderlichen Berechtigungen verfügen (Vorschau)

Beschreibung: Überprovisionierte Identitäten oder über berechtigungsberechtigte Identitäten verwenden nicht viele ihrer erteilten Berechtigungen. Berechtigungen für die rechte Größe dieser Identitäten, um das Risiko eines Missbrauchs von Berechtigungen zu verringern, entweder versehentlich oder böswillig. Diese Aktion verringert den potenziellen Strahlradius während eines Sicherheitsvorfalls.

Schweregrad: Mittel

Privilegierte Rollen sollten keinen dauerhaften Zugriff auf Abonnement- und Ressourcengruppenebene haben.

Beschreibung: Microsoft Defender für Cloud hat eine Identität entdeckt, die in den letzten 45 Tagen keine Aktion für eine Ressource innerhalb Ihres Azure-Abonnements ausgeführt hat. Es wird empfohlen, Berechtigungen für inaktive Identitäten zu widerrufen, um die Angriffsfläche Ihrer Cloudumgebung zu verringern.

Schweregrad: hoch

Dienstprinzipale sollten nicht mit administrativen Rollen auf Abonnement- und Ressourcengruppenebene zugewiesen werden.

Beschreibung: Defender für Cloud identifizierte Dienstprinzipale, die privilegierte Rollen auf Ressourcengruppen- oder Abonnementebene zugewiesen sind. Privilegierte Administratorrollen sind Rollen, die vertrauliche Vorgänge für die Ressource ausführen können, z. B. Besitzer, Mitwirkender oder Benutzerzugriffsadministrator. Dienstprinzipale spielen eine wichtige Rolle bei der effizienten und sicheren Verwaltung von Azure-Ressourcen, wodurch die Notwendigkeit eines menschlichen Eingreifens beseitigt wird. Es ist wichtig, dem Prinzip der geringsten Berechtigung zu folgen, nur das Mindestmaß an Zugriff zu gewähren, das für einen bestimmten Dienstprinzipal erforderlich ist, um ihre Aufgaben auszuführen. Administratoren und privilegierten Zugriff sind primäres Ziel von Hackern. Bewährte Methoden für die Verwendung der Zuweisungen privilegierter Administratorrollen finden Sie unter Bewährte Methoden für Azure RBAC. Bewährte Methoden für Azure RBAC. Eine Liste der verfügbaren Rollen in Azure RBAC finden Sie in den integrierten Azure-Rollen.

Schweregrad: hoch

AWS-Identitäts- und Zugriffsempfehlungen

Amazon Elasticsearch Service-Domänen sollten sich in einer VPC befinden.

Beschreibung: DLP darf keine Domänen mit einem öffentlichen Endpunkt enthalten. Dies wertet die KONFIGURATION des SUBNET-Routings VON CLIENTS nicht aus, um die öffentliche Reichweite zu ermitteln.

Schweregrad: hoch

Anderen AWS-Konten in Bucketrichtlinien gewährte Amazon S3-Berechtigungen sollten eingeschränkt werden.

Beschreibung: Die Implementierung des geringsten Berechtigungszugriffs ist grundlegend, um das Sicherheitsrisiko und die Auswirkungen von Fehlern oder böswilligen Absichten zu verringern. Wenn eine S3-Bucketrichtlinie den Zugriff über externe Konten zulässt, kann dies zur Datenexfiltration durch eine Insiderbedrohung oder einen Angreifer führen. Der Parameter „blacklistedactionpatterns“ ermöglicht eine erfolgreiche Auswertung der Regel für S3-Buckets. Der Parameter gewährt Zugriff auf externe Konten für Aktionsmuster, die nicht in der Liste "blacklistedactionpatterns" enthalten sind.

Schweregrad: hoch

Verwendung des Root-Kontos vermeiden

Beschreibung: Das "Root"-Konto hat uneingeschränkten Zugriff auf alle Ressourcen im AWS-Konto. Es wird dringend empfohlen, die Verwendung dieses Kontos zu vermeiden. Das „Stamm“-Konto ist das AWS-Konto mit den meisten Berechtigungen. Die Minimierung der Verwendung dieses Kontos und die Übernahme des Prinzips der geringsten Rechte für die Zugriffsverwaltung verringern das Risiko versehentlicher Änderungen und der unbeabsichtigten Offenlegung von hoch privilegierten Anmeldeinformationen.

Schweregrad: hoch

AWS KMS-Schlüssel sollten nicht versehentlich gelöscht werden.

Beschreibung: Dieses Steuerelement überprüft, ob KMS-Schlüssel für den Löschvorgang geplant sind. Die Kontrolle schlägt fehl, wenn ein KMS-Schlüssel für die Löschung geplant ist. KMS-Schlüssel können nicht wiederhergestellt werden, nachdem sie gelöscht wurden. Daten, die mit einem KMS-Schlüssel verschlüsselt sind, können ebenfalls dauerhaft nicht wiederhergestellt werden, wenn der KMS-Schlüssel gelöscht wird. Wenn aussagekräftige Daten unter einem für die Löschung geplanten KMS-Schlüssel verschlüsselt wurden, sollten Sie die Daten entschlüsseln oder die Daten unter einem neuen KMS-Schlüssel erneut verschlüsseln, es sei denn, Sie führen absichtlich eine kryptografische Löschung durch. Wenn ein KMS-Schlüssel für die Löschung geplant ist, wird eine obligatorische Wartezeit erzwungen, um Zeit zu geben, die Löschung rückgängig zu machen, wenn sie fälschlicherweise geplant wurde. Der Standardwartezeitraum beträgt 30 Tage, kann jedoch auf bis zu sieben Tage reduziert werden, wenn der KMS-Schlüssel für den Löschvorgang geplant ist. Während des Wartezeitzeitraums kann der geplante Löschvorgang abgebrochen werden, und der KMS-Schlüssel wird nicht gelöscht. Weitere Informationen zum Löschen von KMS-Schlüsseln finden Sie im AWS-Schlüsselverwaltungsdienst-Entwicklerhandbuch zum Löschen von KMS-Schlüsseln.

Schweregrad: hoch

Überprovisionierte AWS-Identitäten sollten nur über die erforderlichen Berechtigungen verfügen (Vorschau)

Beschreibung: Eine überlastete aktive Identität ist eine Identität, die Zugriff auf Berechtigungen hat, die sie nicht verwendet haben. Überlastete aktive Identitäten, insbesondere für nicht menschliche Konten, die definierte Aktionen und Verantwortlichkeiten haben, können den Strahlradius im Falle eines Benutzers, eines Schlüssels oder einer Ressourcenkompromittierung erhöhen. Entfernen Sie nicht benötigte Berechtigungen, und richten Sie Überprüfungsprozesse ein, um die am wenigsten privilegierten Berechtigungen zu erreichen.

Schweregrad: Mittel

Die AWS WAF Classic Global Web-ACL-Protokollierung muss aktiviert sein.

Beschreibung: Dieses Steuerelement überprüft, ob die Protokollierung für eine globale AWS WAF-Web-ACL aktiviert ist. Dieses Steuerelement schlägt fehl, wenn die Protokollierung für die Web-ACL nicht aktiviert ist. Die Protokollierung ist ein wichtiger Bestandteil, um die Zuverlässigkeit, Verfügbarkeit und Leistung von AWS WAF global aufrecht zu halten. Es ist eine Geschäfts- und Complianceanforderung in vielen Organisationen und ermöglicht es Ihnen, das Anwendungsverhalten zu beheben. Es werden auch ausführliche Informationen zum Datenverkehr bereitgestellt, der von der Web-ACL analysiert wird, die an AWS WAF angefügt ist.

Schweregrad: Mittel

Für CloudFront-Verteilungen sollte ein Standardstammobjekt konfiguriert werden.

Beschreibung: Dieses Steuerelement überprüft, ob eine Amazon CloudFront-Verteilung so konfiguriert ist, dass ein bestimmtes Objekt zurückgegeben wird, das das Standardstammobjekt ist. Das Steuerelement schlägt fehl, wenn die CloudFront-Verteilung kein Standardstammobjekt konfiguriert hat. Ein Benutzer kann möglicherweise die Stamm-URL der Verteilung anstelle eines Objekts in der Verteilung anfordern. In diesem Fall können Sie durch die Angabe eines Standardstammobjekts verhindern, dass der Inhalt Ihrer Webverteilung verfügbar gemacht wird.

Schweregrad: hoch

CloudFront-Verteilungen sollten die ursprüngliche Zugriffsidentität aktiviert haben.

Beschreibung: Dieses Steuerelement überprüft, ob eine Amazon CloudFront-Verteilung mit dem Typ "Amazon S3 Origin" die Origin Access Identity (OAI) konfiguriert hat. Das Steuerelement schlägt fehl, wenn OAI nicht konfiguriert ist. CloudFront OAI verhindert den direkten Benutzerzugriff auf S3-Bucketinhalte. Wenn Benutzer direkt auf einen S3-Bucket zugreifen, umgehen sie effektiv die CloudFront-Distribution und alle Berechtigungen, die auf den zugrunde liegenden S3-Bucketinhalt angewendet werden.

Schweregrad: Mittel

CloudTrail-Protokolldateivalidierung sollte aktiviert sein.

Beschreibung: Um die zusätzliche Integritätsprüfung von CloudTrail-Protokollen sicherzustellen, empfehlen wir, die Dateiüberprüfung für alle CloudTrails zu aktivieren.

Schweregrad: Niedrig

CloudTrail sollte aktiviert sein.

Beschreibung: AWS CloudTrail ist ein Webdienst, der AWS-API-Aufrufe für Ihr Konto aufzeichnet und Ihnen Protokolldateien bereitstellt. Nicht alle Dienste aktivieren die Protokollierung standardmäßig für alle APIs und Ereignisse. Sie sollten neben CloudTrail zusätzliche Audit-Trails implementieren und die Dokumentation zu den einzelnen Diensten unter „Von CloudTrail unterstützte Dienste und Integrationen“ überprüfen.

Schweregrad: hoch

CloudTrail-Trails sollten in Amazon CloudWatch Logs integriert sein.

Beschreibung: Zusätzlich zum Erfassen von CloudTrail-Protokollen innerhalb eines angegebenen S3-Buckets für eine langfristige Analyse kann die Echtzeitanalyse durchgeführt werden, indem CloudTrail so konfiguriert wird, dass Protokolle an CloudWatch Logs gesendet werden. Für einen Trail, der in allen Regionen eines Kontos aktiviert ist, sendet CloudTrail Protokolldateien aus all diesen Regionen an eine CloudWatch-Protokollgruppe. Wir empfehlen, dass CloudTrail-Protokolle an CloudWatch-Protokolle gesendet werden, um sicherzustellen, dass AWS-Kontoaktivitäten erfasst, überwacht und entsprechend alarmiert werden. Das Senden von CloudTrail-Protokollen an CloudWatch-Protokolle erleichtert die Echtzeit- und Verlaufsprotokollierung von Aktivitäten basierend auf Nutzer, API, Ressourcen und IP-Adresse und bietet die Möglichkeit, Alarme und Benachrichtigungen für anomale oder sensible Kontoaktivitäten einzurichten.

Schweregrad: Niedrig

Die Datenbankprotokollierung sollte aktiviert sein.

Beschreibung: Dieses Steuerelement überprüft, ob die folgenden Protokolle von Amazon RDS aktiviert und an CloudWatch Logs gesendet werden:

• Oracle: (Warnung, Überwachung, Ablaufverfolgung, Listener)
• PostgreSQL: (Postgresql, Upgrade)
• MySQL: (Audit, Error, General, SlowQuery)
• MariaDB: (Audit, Error, General, SlowQuery)
• SQL Server: (Fehler, Agent)
• Aurora: (Audit, Error, General, SlowQuery)
• Aurora-MySQL: (Audit, Error, General, SlowQuery)
• Aurora-PostgreSQL: (Postgresql, Upgrade). Für RDS-Datenbanken müssen relevante Protokolle aktiviert sein. Die Datenbankprotokollierung stellt detaillierte Datensätze zu Anforderungen an RDS bereit. Datenbankprotokolle unterstützen Sie bei der Sicherheits- und Zugriffsüberwachung und helfen Ihnen bei der Diagnose von Verfügbarkeitsproblemen.

Schweregrad: Mittel

Deaktivieren des direkten Internetzugriffs für Amazon Sage Maker-Notizbuchinstanzen

Beschreibung: Der direkte Internetzugriff sollte für eine Sage Maker-Notizbuchinstanz deaktiviert werden. Hierzu wird überprüft, ob das Feld „DirectInternetAccess“ für die Notebook-Instanz deaktiviert ist. Sie sollten Ihre Instanz mit einer VPC konfigurieren und die Standardeinstellung so ändern, dass der Zugriff auf das Internet über eine VPC deaktiviert wird. Zum Trainieren oder Hosten von Modellen über ein Notebook benötigen Sie Internetzugriff. Um den Internetzugriff zu ermöglichen, stellen Sie sicher, dass Ihre VPC über ein NAT-Gateway verfügt und Ihre Sicherheitsgruppe ausgehende Verbindungen zulässt. Stellen Sie sicher, dass der Zugriff auf Ihre Sage Maker-Konfiguration nur auf autorisierte Benutzer beschränkt ist, und beschränken Sie die IAM-Berechtigungen der Benutzer, um Sage Maker-Einstellungen und -Ressourcen zu ändern.

Schweregrad: hoch

Beim ersten Benutzersetup sollten keine Zugriffsschlüssel für alle IAM-Benutzer eingerichtet werden, die über ein Konsolenkennwort verfügen.

Beschreibung: In der AWS-Konsole wird standardmäßig das Kontrollkästchen zum Erstellen von Zugriffstasten für die Aktivierung aktiviert. Dadurch werden viele Zugriffsschlüssel unnötig generiert. Neben nicht erforderlichen Anmeldeinformationen führt dies auch zu unnötigem Verwaltungsaufwand bei der Überwachung und Rotation dieser Schlüssel. Wenn sie festlegen müssen, dass der Benutzer zusätzliche Schritte ausführt, nachdem sein Profil erstellt wurde, gibt es einen stärkeren Hinweis darauf, dass Zugriffstasten [a] für ihre Arbeit erforderlich sind, und [b] nachdem der Zugriffsschlüssel auf einem Konto eingerichtet wurde, dass die Schlüssel irgendwo in der Organisation verwendet werden können.

Schweregrad: Mittel

Für die Incidentverwaltung mit dem AWS-Support muss eine Supportrolle erstellt worden sein.

Beschreibung: AWS bietet ein Supportcenter, das für die Benachrichtigung und Reaktion auf Vorfälle sowie technischen Support und Kundendienst verwendet werden kann. Erstellen Sie eine IAM-Rolle, um autorisierten Benutzern das Verwalten von Incidents mit AWS Support zu ermöglichen. Wenn Sie die geringsten Berechtigungen für die Zugriffssteuerung implementieren, erfordert eine IAM-Rolle eine geeignete IAM-Richtlinie, um Support Center-Zugriff zu ermöglichen, um Vorfälle mit AWS-Support zu verwalten.

Schweregrad: Niedrig

Zugriffsschlüssel müssen spätestens nach 90 Tagen rotiert werden.

Beschreibung: Zugriffstasten bestehen aus einer Zugriffstasten-ID und einem geheimen Zugriffsschlüssel, die zum Signieren von programmgesteuerten Anforderungen verwendet werden, die Sie in AWS vornehmen. AWS-Benutzer benötigen ihre eigenen Zugriffsschlüssel, um programmgesteuerte Aufrufe an AWS über die AWS-Befehlszeilenschnittstelle (AWS CLI), Tools für Windows PowerShell, die AWS SDKs oder direkte HTTP-Aufrufe über die APIs für einzelne AWS-Dienste durchzuführen. Es wird empfohlen, dass alle Zugriffstasten regelmäßig gedreht werden. Durch drehende Zugriffstasten wird das Zeitfenster für einen Zugriffsschlüssel reduziert, der einem kompromittierten oder beendeten Konto zugeordnet ist, das verwendet werden soll. Zugriffstasten sollten gedreht werden, um sicherzustellen, dass auf Daten nicht mit einem alten Schlüssel zugegriffen werden kann, der möglicherweise verloren gegangen, geknackt oder gestohlen wurde.

Schweregrad: Mittel

AWS Config muss in allen Regionen aktiviert sein.

Beschreibung: AWS Config ist ein Webdienst, der die Konfiguration der unterstützten AWS-Ressourcen innerhalb Ihres Kontos durchführt und Ihnen Protokolldateien bereitstellt. Die aufgezeichneten Informationen umfassen das Konfigurationselement (AWS-Ressource), Beziehungen zwischen Konfigurationselementen (AWS-Ressourcen) und Konfigurationsänderungen zwischen den Ressourcen. Es wird empfohlen, AWS Config in allen Regionen zu aktivieren.

Anhand des Verlaufs der von AWS Config erfassten AWS-Konfigurationselemente können Sicherheitsanalysen, die Änderungsnachverfolgung für Ressourcen und die Konformitätsüberwachung durchgeführt werden.

Schweregrad: Mittel

CloudTrail muss in allen Regionen aktiviert sein.

Beschreibung: AWS CloudTrail ist ein Webdienst, der AWS-API-Aufrufe für Ihr Konto aufzeichnet und Ihnen Protokolldateien bereitstellt. Die aufgezeichneten Informationen umfassen die Identität des API-Aufrufers, den Zeitpunkt des API-Aufrufs, die Quell-IP-Adresse des API-Aufrufers, die Anforderungsparameter und die vom AWS-Dienst zurückgegebenen Antwortelemente. CloudTrail stellt einen Verlauf der AWS-API-Aufrufe für ein Konto bereit, einschließlich API-Aufrufen, die über AWS Management Console, AWS SDKs, Befehlszeilentools und übergeordnete AWS-Dienste (z. B. AWS CloudFormation) durchgeführt werden. Der von CloudTrail erstellte Verlauf der AWS-API-Aufrufe ermöglicht Sicherheitsanalysen, die Änderungsnachverfolgung für Ressourcen und die Konformitätsüberwachung. Außerdem wurde Folgendes durchgeführt:

• Durch die Überprüfung, ob ein Pfad mit mehreren Regionen vorhanden ist, wird sichergestellt, dass unerwartete Aktivitäten in andernfalls nicht verwendeten Regionen erkannt werden.
• Die Überprüfung, ob ein Trail mit mehreren Regionen vorhanden ist, stellt sicher, dass "Global Service Logging" standardmäßig für einen Trail aktiviert ist, um aufzeichnungen von Ereignissen zu erfassen, die auf globalen AWS-Diensten generiert werden.
• Bei einem Trail mit mehreren Regionen stellt die Überprüfung, ob Verwaltungsereignisse für alle Arten von Lese-/Schreibvorgängen konfiguriert sind, sicher, dass die Aufzeichnung von Verwaltungsvorgängen, die für alle Ressourcen in einem AWS-Konto ausgeführt werden, durchgeführt werden.

Schweregrad: hoch

Seit mindestens 90 Tagen nicht genutzte Anmeldeinformationen müssen deaktiviert werden.

Beschreibung: AWS IAM-Benutzer können auf AWS-Ressourcen mit verschiedenen Arten von Anmeldeinformationen zugreifen, z. B. Kennwörter oder Zugriffstasten. Es wird empfohlen, dass alle Anmeldeinformationen, die in 90 oder mehr Tagen nicht verwendet wurden, entfernt oder deaktiviert werden. Wenn Sie unnötige Anmeldeinformationen deaktivieren oder entfernen, verringern Sie das Zeitfenster für Anmeldeinformationen, die einem kompromittierten oder verlassenen Konto zugeordnet sind, das verwendet werden soll.

Schweregrad: Mittel

Gemäß IAM-Kennwortrichtlinie laufen Kennwörter spätestens nach 90 Tagen ab.

Beschreibung: Die KENNWORTrichtlinien von IAM können festlegen, dass Kennwörter nach einer bestimmten Anzahl von Tagen gedreht oder abgelaufen sind. Es wird empfohlen, dass die Kennwortrichtlinie Kennwörter nach 90 Tagen oder weniger abläuft. Durch Verkürzen der Kennwortlebensdauer erhöht sich die Resilienz des Kontos gegenüber Brute-Force-Anmeldeversuchen. Das Anfordern regelmäßiger Kennwortänderungen ist außerdem in folgenden Szenarios hilfreich:

• Kennwörter können manchmal ohne Ihr Wissen gestohlen oder kompromittiert werden. beispielsweise durch Systemkompromittierung, ein Softwaresicherheitsrisiko oder eine interne Bedrohung.
• Bestimmte Webfilter für Unternehmen und Behörden oder Proxyserver können den Datenverkehr auch dann abfangen und aufzeichnen, wenn er verschlüsselt ist.
• Viele Personen verwenden dasselbe Kennwort für viele Systeme wie Arbeit, E-Mail und persönlich.
• Kompromittierte Endbenutzerarbeitsstationen verfügen möglicherweise über einen Tastaturanschlägeprotokollierer.

Schweregrad: Niedrig

Gemäß IAM-Kennwortrichtlinie dürfen Kennwörter nicht wiederverwendet werden.

Beschreibung: IAM-Kennwortrichtlinien können die Wiederverwendung eines bestimmten Kennworts durch denselben Benutzer verhindern. Es wird empfohlen, dass die Kennwortrichtlinie die Wiederverwendung von Kennwörtern verhindert. Dadurch erhöht sich die Resilienz des Kontos gegenüber Brute-Force-Anmeldeversuchen.

Schweregrad: Niedrig

Gemäß IAM-Kennwortrichtlinie müssen Kennwörter mindestens einen Kleinbuchstaben enthalten.

Beschreibung: Kennwortrichtlinien werden teilweise verwendet, um Anforderungen an die Kennwortkomplexität zu erzwingen. IAM-Kennwortrichtlinien können verwendet werden, um sicherzustellen, dass das Kennwort aus verschiedenen Zeichensätzen besteht. Es wird empfohlen, dass für die Kennwortrichtlinie mindestens ein Kleinbuchstabe erforderlich ist. Durch Festlegen einer Richtlinie für die Kennwortkomplexität erhöht sich die Resilienz des Kontos bei Brute-Force-Anmeldeversuchen.

Schweregrad: Mittel

Gemäß IAM-Kennwortrichtlinie müssen Kennwörter mindestens eine Ziffer enthalten.

Beschreibung: Kennwortrichtlinien werden teilweise verwendet, um Anforderungen an die Kennwortkomplexität zu erzwingen. IAM-Kennwortrichtlinien können verwendet werden, um sicherzustellen, dass das Kennwort aus verschiedenen Zeichensätzen besteht. Es wird empfohlen, dass für die Kennwortrichtlinie mindestens eine Zahl erforderlich ist. Durch Festlegen einer Richtlinie für die Kennwortkomplexität erhöht sich die Resilienz des Kontos bei Brute-Force-Anmeldeversuchen.

Schweregrad: Mittel

Gemäß IAM-Kennwortrichtlinie müssen Kennwörter mindestens ein Symbol enthalten.

Beschreibung: Kennwortrichtlinien werden teilweise verwendet, um Anforderungen an die Kennwortkomplexität zu erzwingen. IAM-Kennwortrichtlinien können verwendet werden, um sicherzustellen, dass das Kennwort aus verschiedenen Zeichensätzen besteht. Es wird empfohlen, dass für die Kennwortrichtlinie mindestens ein Symbol erforderlich ist. Durch Festlegen einer Richtlinie für die Kennwortkomplexität erhöht sich die Resilienz des Kontos bei Brute-Force-Anmeldeversuchen.

Schweregrad: Mittel

Gemäß IAM-Kennwortrichtlinie müssen Kennwörter mindestens einen Großbuchstaben enthalten.

Beschreibung: Kennwortrichtlinien werden teilweise verwendet, um Anforderungen an die Kennwortkomplexität zu erzwingen. IAM-Kennwortrichtlinien können verwendet werden, um sicherzustellen, dass das Kennwort aus verschiedenen Zeichensätzen besteht. Es wird empfohlen, dass für die Kennwortrichtlinie mindestens ein Großbuchstaben erforderlich ist. Durch Festlegen einer Richtlinie für die Kennwortkomplexität erhöht sich die Resilienz des Kontos bei Brute-Force-Anmeldeversuchen.

Schweregrad: Mittel

Stellen Sie sicher, dass die IAM-Kennwortrichtlinie eine Mindestlänge von 14 Zeichen verlangt.

Beschreibung: Kennwortrichtlinien werden teilweise verwendet, um Anforderungen an die Kennwortkomplexität zu erzwingen. IAM-Kennwortrichtlinien können verwendet werden, um sicherzustellen, dass das Kennwort mindestens eine bestimmte Länge aufweist. Es wird empfohlen, dass für die Kennwortrichtlinie eine Mindestkennwortlänge "14" erforderlich ist. Durch Festlegen einer Richtlinie für die Kennwortkomplexität erhöht sich die Resilienz des Kontos bei Brute-Force-Anmeldeversuchen.

Schweregrad: Mittel

Sicherstellen, dass die mehrstufige Authentifizierung (MultiFactor Authentication, MFA) für alle IAM-Benutzer aktiviert ist, die über ein Konsolenkennwort verfügen

Beschreibung: Die mehrstufige Authentifizierung (Multifactor Authentication, MFA) fügt eine zusätzliche Schutzebene über einem Benutzernamen und Kennwort hinzu. Wenn MFA aktiviert ist, werden benutzer, wenn sich ein Benutzer bei einer AWS-Website anmeldet, aufgefordert, den Benutzernamen und das Kennwort sowie einen Authentifizierungscode von ihrem AWS MFA-Gerät einzugeben. Es wird empfohlen, die MFA für alle Konten mit einem Konsolenkennwort zu aktivieren. Durch die Aktivierung von MFA wird die Sicherheit des Konsolenzugriffs erhöht, weil der Prinzipal, der sich authentifizieren möchte, über ein Gerät verfügen muss, das einen zeitabhängigen Schlüssel abgibt, und ihm Anmeldeinformationen bekannt sein müssen.

Schweregrad: Mittel

GuardDuty sollte aktiviert sein.

Beschreibung: Um zusätzlichen Schutz vor Angriffen bereitzustellen, sollte GuardDuty auf Ihrem AWS-Konto und Ihrer Region aktiviert sein.

GuardDuty ist möglicherweise keine vollständige Lösung für jede Umgebung.

Schweregrad: Mittel

Für das Root-Konto muss Hardware-MFA aktiviert sein.

Beschreibung: Das Stammkonto ist der privilegierteste Benutzer in einem Konto. Zusätzlich zu einem Benutzernamen und einem Kennwort wird durch MFA eine weitere Schutzebene hinzugefügt. Wenn MFA aktiviert ist und ein Benutzer sich bei einer AWS-Website anmeldet, wird er zur Eingabe seines Benutzernamens und Kennworts sowie zur Angabe eines Authentifizierungscodes von seinem AWS MFA-Gerät aufgefordert. Für Ebene 2 wird empfohlen, das Stammkonto mit einer Hardware-MFA zu schützen. Hardware-MFA weist eine kleinere Angriffsfläche auf als virtuelle MFA. Beispielsweise bietet Hardware-MFA nicht die Angriffsfläche, die durch ein mobiles Smartphone eingeführt wird, auf dem sich virtuelle MFA befindet. Wenn Sie Hardware für MFA für viele verwenden, können viele Konten zu einem logistischen Geräteverwaltungsproblem führen. In diesem Fall empfiehlt es sich, diese Empfehlung der Stufe 2 selektiv auf die Konten anzuwenden, die die höchste Sicherheit erfordern. Die Empfehlung der Stufe 1 kann anschließend auf die verbleibenden Konten angewendet werden.

Schweregrad: Niedrig

Die IAM-Authentifizierung sollte für RDS-Cluster konfiguriert werden.

Beschreibung: Dieses Steuerelement überprüft, ob ein RDS DB-Cluster die IAM-Datenbankauthentifizierung aktiviert hat. Die IAM-Datenbankauthentifizierung ermöglicht die Authentifizierung ohne Kennwort für Datenbankinstanzen. Die Authentifizierung verwendet ein Authentifizierungstoken. Der Netzwerkdatenverkehr zur und von der Datenbank wird mit SSL verschlüsselt. Weitere Informationen finden Sie im Abschnitt IAM-Datenbankauthentifizierung im Amazon Aurora-Benutzerhandbuch.

Schweregrad: Mittel

Die IAM-Authentifizierung sollte für RDS-Instanzen konfiguriert werden

Beschreibung: Dieses Steuerelement überprüft, ob eine RDS DB-Instanz die IAM-Datenbankauthentifizierung aktiviert hat. Die IAM-Datenbankauthentifizierung ermöglicht die Authentifizierung bei Datenbankinstanzen mit einem Authentifizierungstoken anstelle eines Kennworts. Der Netzwerkdatenverkehr zur und von der Datenbank wird mit SSL verschlüsselt. Weitere Informationen finden Sie im Abschnitt IAM-Datenbankauthentifizierung im Amazon Aurora-Benutzerhandbuch.

Schweregrad: Mittel

Kundenseitig verwaltete IAM-Richtlinien sollten keine Entschlüsselungsaktionen für alle KMS-Schlüssel zulassen.

Beschreibung: Überprüft, ob die Standardversion der vom KUNDEN verwalteten IAM-Richtlinien prinzipale die Verwendung der AWS KMS-Entschlüsselungsaktionen für alle Ressourcen ermöglichen. Dieses Steuerelement verwendet Zelkova, ein automatisiertes Reasoning-Modul, um Sie über Richtlinien zu validieren und zu warnen, die möglicherweise einen breiten Zugriff auf Ihre Geheimnisse in AWS-Konten gewähren. Dieses Steuerelement schlägt fehl, wenn die Aktionen "kms: Entschlüsseln" oder "kms: ReEncryptFrom" für alle KMS-Schlüssel zulässig sind. Die Kontrolle wertet sowohl angefügte als auch nicht angefügte kundenseitig verwaltete Richtlinien aus. Sie überprüft keine Inlinerichtlinien oder von AWS verwalteten Richtlinien. Mit AWS KMS steuern Sie, wer Ihre KMS-Schlüssel verwenden und Zugriff auf Ihre verschlüsselten Daten erhalten kann. IAM-Richtlinien definieren, welche Aktionen eine Identität (Benutzer, Gruppe oder Rolle) für welche Ressourcen ausführen kann. Nach bewährten Sicherheitsmethoden empfiehlt AWS, die geringstmöglichen Rechte zu erteilen. Mit anderen Worten: Sie sollten Identitäten die Berechtigungen „kms:Decrypt“ oder „kms:ReEncryptFrom“ nur für die Schlüssel gewähren, die zum Ausführen einer Aufgabe erforderlich sind. Andernfalls verwendet der Benutzer möglicherweise Schlüssel, die nicht für Ihre Daten geeignet sind. Statt Berechtigungen für alle Schlüssel zu erteilen, ermitteln Sie den Mindestsatz von Schlüsseln, die Benutzer für den Zugriff auf verschlüsselte Daten benötigen. Entwerfen Sie dann Richtlinien, um Benutzern nur die Verwendung dieser Schlüssel zu erlauben. Lassen Sie beispielsweise die Berechtigung "kms: Entschlüsseln" für alle KMS-Schlüssel nicht zu. Lassen Sie stattdessen "kms: Decrypt" nur für Schlüssel in einer bestimmten Region für Ihr Konto zu. Durch das Prinzip der geringstmöglichen Rechte können Sie das Risiko einer ungewollten Offenlegung Ihrer Daten verringern.

Schweregrad: Mittel

Von Ihnen erstellte kundenseitig verwaltete IAM-Richtlinien dürfen keine Platzhalteraktionen für Dienste zulassen.

Beschreibung: Dieses Steuerelement überprüft, ob die von Ihnen erstellten IDENTITY-basierten RICHTLINIEN über Allow-Anweisungen verfügen, die den Platzhalter *verwenden, um Berechtigungen für alle Aktionen für jeden Dienst zu erteilen. Das Steuerelement schlägt fehl, wenn eine Richtlinienausweisung 'Effect': 'Allow' mit 'Action': 'Service:*' enthält. Die folgende Anweisung in einer Richtlinie führt beispielsweise zu einem fehlgeschlagenen Ergebnis

'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:*',
  'Resource': '*'
}

Das Steuerelement schlägt auch fehl, wenn Sie 'Effect': 'Allow' mit 'NotAction': 'service:' verwenden. In diesem Fall bietet das NotAction-Element Zugriff auf alle Aktionen in einem AWS-Dienst, mit Ausnahme der in NotAction angegebenen Aktionen. Dieses Steuerelement gilt nur für vom Kunden verwaltete IAM-Richtlinien. Es gilt nicht für IAM-Richtlinien, die von AWS verwaltet werden. Wenn Sie AWS-Diensten Berechtigungen zuweisen, ist es wichtig, die zulässigen IAM-Aktionen in Ihren IAM-Richtlinien zu beschränken. Sie sollten DIE IAM-Aktionen nur auf die erforderlichen Aktionen beschränken. Auf diese Weise können Sie die geringsten Berechtigungen bereitstellen. Übermäßig zulässige Richtlinien können zu einer Berechtigungseskalation führen, wenn die Richtlinien einem IAM-Prinzipal angefügt sind, der möglicherweise nicht die Berechtigung erfordert. In einigen Fällen möchten Sie möglicherweise IAM-Aktionen zulassen, die ein ähnliches Präfix aufweisen, z. B. "DescribeFlowLogs" und "DescribeAvailabilityZones". In diesen autorisierten Fällen können Sie dem allgemeinen Präfix einen suffixierten Wildcard hinzufügen. Beispiel: ec2:Describe.

Diese Kontrolle ist bestanden, wenn Sie eine IAM-Aktion mit einem vorangestellten Platzhalter verwenden. Die folgende Anweisung in einer Richtlinie führt beispielsweise zu einem bestandenen Ergebnis.

 'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:Describe*',
  'Resource': '*'
}

Wenn Sie zusammengehörige IAM-Aktionen auf diese Weise gruppieren, können Sie auch vermeiden, die Größenbeschränkungen für IAM-Richtlinien zu überschreiten.

Schweregrad: Niedrig

IAM-Kennwortrichtlinien sollten nur auf Gruppen oder Rollen angewendet werden.

Beschreibung: Standardmäßig haben IAM-Benutzer, Gruppen und Rollen keinen Zugriff auf AWS-Ressourcen. IAM-Richtlinien sind das Mittel, mit dem Benutzern, Gruppen oder Rollen Berechtigungen zugewiesen werden. Es wird empfohlen, DASS DIE IAM-Richtlinien direkt auf Gruppen und Rollen angewendet werden, jedoch nicht auf Benutzer. Das Zuweisen von Berechtigungen auf Gruppen- oder Rollenebene ermöglicht eine weniger komplexe Zugriffsverwaltung bei Zunahme der Benutzeranzahl. Eine Verringerung der Komplexität der Zugriffsverwaltung kann auch dazu führen, dass ein Prinzipal versehentlich übermäßige Berechtigungen empfängt oder beibehalten kann.

Schweregrad: Niedrig

Es dürfen keine IAM-Richtlinien mit Gewährung vollständiger „:“-Administratorrechte erstellt werden.

Beschreibung: IAM-Richtlinien sind die Mittel, mit denen Benutzern, Gruppen oder Rollen Berechtigungen gewährt werden. Es wird empfohlen und als Standardsicherheitsratgeber für die Gewährung der geringsten Berechtigungen empfohlen, d. h. nur die Berechtigungen zu erteilen, die zum Ausführen einer Aufgabe erforderlich sind. Stellen Sie fest, welche Aktionen von den Benutzern ausgeführt werden müssen, und erstellen Sie dann Richtlinien, die Benutzern nur die Ausführung dieser Aufgaben ermöglichen, statt vollständige Administratorrechte zu gewähren. Es ist sicherer, mit einem Mindestsatz an Berechtigungen zu beginnen und bei Bedarf zusätzliche Berechtigungen zu erteilen, als mit zu freizügigen Berechtigungen zu beginnen und diese später zu verschärfen. Wenn Sie vollständige Administratorrechte und nicht nur den Mindestsatz der Berechtigungen zuweisen, die der Benutzer benötigt, werden die Ressourcen für potenziell unerwünschte Aktionen verfügbar gemacht. Sie sollten IAM-Richtlinien entfernen, die eine Anweisung mit "Effect": "Allow" mit "Action": "" über "Resource": "" enthalten.

Schweregrad: hoch

IAM-Prinzipale sollten nicht über IAM-Inlinerichtlinien verfügen, die Entschlüsselungsaktionen für alle KMS-Schlüssel zulassen.

Beschreibung: Überprüft, ob die Inlinerichtlinien, die in Ihre IAM-Identitäten (Rolle, Benutzer oder Gruppe) eingebettet sind, die AWS KMS-Entschlüsselungsaktionen für alle KMS-Schlüssel zulassen. Dieses Steuerelement verwendet Zelkova, ein automatisiertes Reasoning-Modul, um Sie über Richtlinien zu validieren und zu warnen, die möglicherweise einen breiten Zugriff auf Ihre Geheimnisse in AWS-Konten gewähren. Dieses Steuerelement schlägt fehl, wenn kms:Decrypt oder kms:ReEncryptFrom Aktionen für alle KMS-Schlüssel in einer Inlinerichtlinie zulässig sind. Mit AWS KMS steuern Sie, wer Ihre KMS-Schlüssel verwenden und Zugriff auf Ihre verschlüsselten Daten erhalten kann. IAM-Richtlinien definieren, welche Aktionen eine Identität (Benutzer, Gruppe oder Rolle) für welche Ressourcen ausführen kann. Nach bewährten Sicherheitsmethoden empfiehlt AWS, die geringstmöglichen Rechte zu erteilen. Mit anderen Worten: Sie sollten Identitäten nur die notwendigen Berechtigungen ausschließlich für diejenigen Schlüssel gewähren, die zum Ausführen einer Aufgabe erforderlich sind. Andernfalls verwendet der Benutzer möglicherweise Schlüssel, die nicht für Ihre Daten geeignet sind. Statt Berechtigungen für alle Schlüssel zu erteilen, ermitteln Sie den Mindestsatz von Schlüsseln, die Benutzer für den Zugriff auf verschlüsselte Daten benötigen. Entwerfen Sie dann Richtlinien, um Benutzern nur die Verwendung dieser Schlüssel zu erlauben. Lassen Sie beispielsweise die Berechtigung für alle KMS-Schlüssel nicht zu kms:Decrypt . Erlauben Sie „kms:Decrypt“ stattdessen nur für Schlüssel in einer bestimmten Region Ihres Kontos. Durch das Prinzip der geringstmöglichen Rechte können Sie das Risiko einer ungewollten Offenlegung Ihrer Daten verringern.

Schweregrad: Mittel

Lambdafunktionen sollten den öffentlichen Zugriff einschränken.

Beschreibung: Ressourcenbasierte Lambda-Funktion sollte den öffentlichen Zugriff einschränken. Diese Empfehlung überprüft nicht den Zugriff durch interne Prinzipale. Stellen Sie sicher, dass der Zugriff auf die Funktion auf autorisierte Prinzipale beschränkt ist, indem Sie die Richtlinien mit den geringstmöglichen Rechten verwenden.

Schweregrad: hoch

Für alle IAM-Benutzer sollte MFA aktiviert sein.

Beschreibung: Alle IAM-Benutzer sollten die mehrstufige Authentifizierung (MFA) aktiviert haben.

Schweregrad: Mittel

Für das Root-Konto sollte MFA aktiviert sein.

Beschreibung: Das Stammkonto ist der privilegierteste Benutzer in einem Konto. Zusätzlich zu einem Benutzernamen und einem Kennwort wird durch MFA eine weitere Schutzebene hinzugefügt. Wenn MFA aktiviert ist und ein Benutzer sich bei einer AWS-Website anmeldet, wird er zur Eingabe seines Benutzernamens und Kennworts sowie zur Angabe eines Authentifizierungscodes von seinem AWS MFA-Gerät aufgefordert. Wenn Sie virtuelle MFA für Stammkonten verwenden, wird empfohlen, dass das verwendete Gerät kein persönliches Gerät ist. Verwenden Sie stattdessen ein dediziertes mobiles Gerät (Tablet oder Telefon), das von Ihnen verwaltet und unabhängig von persönlichen Geräten geladen und gesichert wird. So verringern Sie das Risiko, den Zugriff auf die MFA durch Geräteverlust, Inzahlungnahme des Geräts oder Kündigung des Gerätebesitzers beim Unternehmen zu verlieren.

Schweregrad: Niedrig

Kennwortrichtlinien für IAM-Benutzer sollten sichere Konfigurationen aufweisen.

Beschreibung: Überprüft, ob die Kontokennwortrichtlinie für IAM-Benutzer die folgenden Mindestkonfigurationen verwendet.

• RequireUppercaseCharacters– Erfordert mindestens ein Großbuchstaben im Kennwort. (Standardwert = TRUE)
• RequireLowercaseCharacters– Mindestens ein Kleinbuchstaben im Kennwort erforderlich. (Standardwert = TRUE)
• RequireNumbers- Require at least one number in password. (Standardwert = TRUE)
• MinimumPasswordLength– Mindestlänge des Kennworts. (Standardwert = mindestens 7)
• PasswordReusePrevention– Anzahl der Kennwörter, bevor die Wiederverwendung zugelassen wird. (Standardwert = 4)
• MaxPasswordAge– Anzahl von Tagen vor Ablauf des Kennworts. (Standardwert = 90)

Schweregrad: Mittel

Berechtigungen von inaktiven Identitäten in Ihrem AWS-Konto sollten widerrufen werden.

Beschreibung: Microsoft Defender für Cloud hat eine Identität entdeckt, die in den letzten 45 Tagen keine Aktion für eine Ressource innerhalb Ihres AWS-Kontos ausgeführt hat. Es wird empfohlen, Berechtigungen für inaktive Identitäten zu widerrufen, um die Angriffsfläche Ihrer Cloudumgebung zu verringern.

Schweregrad: Mittel

Es sollte kein Zugriffsschlüssel für das Root-Konto vorhanden sein.

Beschreibung: Das Stammkonto ist der privilegierteste Benutzer in einem AWS-Konto. AWS-Zugriffsschlüssel bieten programmgesteuerten Zugriff auf ein bestimmtes AWS-Konto. Es wird empfohlen, alle Dem Stammkonto zugeordneten Zugriffstasten zu entfernen. Durch das Entfernen von Zugriffsschlüsseln, die dem Stammkonto zugeordnet sind, werden die Vektoren eingeschränkt, durch die das Konto kompromittiert werden kann. Zudem wird durch das Entfernen der Stammzugriffsschlüssel die Erstellung und Verwendung rollenbasierter Konten nach dem Prinzip der geringstmöglichen Rechte unterstützt.

Schweregrad: hoch

Die S3-Einstellung zum Blockieren des öffentlichen Zugriffs sollte aktiviert sein.

Beschreibung: Das Aktivieren der Einstellung "Öffentlicher Zugriff blockieren" für Ihren S3-Bucket kann dazu beitragen, vertrauliche Datenlecks zu verhindern und Ihren Bucket vor böswilligen Aktionen zu schützen.

Schweregrad: Mittel

Die S3-Einstellung zum Blockieren des öffentlichen Zugriffs muss auf Bucketebene aktiviert sein.

Beschreibung: Dieses Steuerelement überprüft, ob S3-Buckets öffentliche Zugriffsblöcke auf Bucketebene angewendet haben. Dieses Steuerelement schlägt fehl, wenn eine der folgenden Einstellungen auf "false" festgelegt ist:

• ignorePublicAcls
• blockPublicPolicy
• blockPublicAcls
• RestrictPublicBuckets Blockieren des öffentlichen Zugriffs auf S3-Bucketebene stellt Steuerelemente bereit, um sicherzustellen, dass Objekte nie über öffentlichen Zugriff verfügen. Der öffentliche Zugriff auf Buckets und Objekte wird über Zugriffssteuerungslisten (Access Control Lists, ACLs), Bucketrichtlinien oder beides gewährt. Sofern Ihre S3-Buckets nicht öffentlich zugänglich sein sollen, sollten Sie das Amazon S3-Feature „Öffentlichen Zugriff blockieren“ auf Bucketebene konfigurieren.

Schweregrad: hoch

Öffentlicher Lesezugriff auf S3-Buckets sollte entfernt werden.

Beschreibung: Durch das Entfernen des öffentlichen Lesezugriffs auf Ihren S3-Bucket können Sie Ihre Daten schützen und eine Datenschutzverletzung verhindern.

Schweregrad: hoch

Öffentlicher Schreibzugriff auf S3-Buckets sollte entfernt werden.

Beschreibung: Durch das Zulassen des öffentlichen Schreibzugriffs auf Ihren S3-Bucket können Sie anfällig für böswillige Aktionen wie das Speichern von Daten auf Kosten, das Verschlüsseln Ihrer Dateien für Lösegeld oder die Verwendung Ihres Buckets zum Betrieb von Schadsoftware sein.

Schweregrad: hoch

Für Secrets Manager-Geheimnisse sollte die automatische Rotation aktiviert sein.

Beschreibung: Dieses Steuerelement überprüft, ob ein geheimer Schlüssel, der im AWS Secrets Manager gespeichert ist, mit automatischer Drehung konfiguriert ist. Der Secrets Manager hilft Ihnen, den Sicherheitsstatus Ihrer Organisation zu verbessern. Zu den Geheimnissen gehören Datenbankanmeldeinformationen, Kennwörter und API-Schlüssel von Drittanbietern. Sie können den Secrets Manager verwenden, um Geheimnisse zentral zu speichern, Geheimnisse automatisch zu verschlüsseln, den Zugriff auf Geheimnisse zu steuern und Geheimnisse sicher und automatisch zu rotieren. Der Secrets Manager kann Geheimnisse rotieren. Sie können die Rotation verwenden, um Geheimnisse mit langer Gültigkeitsdauer durch kurzlebigere Geheimnisse zu ersetzen. Das Rotieren Ihrer Geheimnisse schränkt ein, wie lange ein nicht autorisierter Benutzer ein kompromittiertes Geheimnis verwenden kann. Aus diesem Grund sollten Sie Ihre Geheimnisse häufig rotieren. Weitere Informationen zur Rotation finden Sie unter Rotieren Ihrer AWS Secrets Manager-Geheimnisse im AWS Secrets Manager-Benutzerhandbuch.

Schweregrad: Mittel

Angehaltene EC2-Instanzen sollten nach einem angegebenen Zeitraum entfernt werden.

Beschreibung: Dieses Steuerelement überprüft, ob EC2-Instanzen länger als die zulässige Anzahl von Tagen angehalten wurden. Eine EC2-Instanz schlägt diese Überprüfung fehl, wenn sie länger als der maximal zulässige Zeitraum beendet wird, der standardmäßig 30 Tage beträgt. Ein fehlerhaftes Ergebnis weist darauf hin, dass eine EC2-Instanz für einen signifikanten Zeitraum nicht ausgeführt wurde. Dadurch entsteht ein Sicherheitsrisiko, da die EC2-Instanz nicht aktiv verwaltet wird (analysiert, gepatcht, aktualisiert). Wenn sie später gestartet wird, kann das Fehlen einer ordnungsgemäßen Wartung zu unerwarteten Problemen in Ihrer AWS-Umgebung führen. Um eine EC2-Instanz über einen inaktiven Zeitraum sicher zu warten, starten Sie sie regelmäßig zu Wartungszwecken, und beenden Sie sie nach der Wartung. Idealerweise erfolgt dies im Rahmen eines automatisierten Prozesses.

Schweregrad: Mittel

Nicht verwendete Identitäten in Ihrer AWS-Umgebung sollten entfernt werden (Vorschau)

Beschreibung: Inaktive Identitäten sind menschliche und nicht menschliche Entitäten, die in den letzten 90 Tagen keine Aktion für eine Ressource ausgeführt haben. Inaktive IAM-Identitäten mit berechtigungen mit hohem Risiko in Ihrem AWS-Konto können anfällig für Angriffe sein, wenn dies so bleibt und Organisationen offen für Missbrauch oder Ausbeutung von Anmeldeinformationen bleiben. Proaktives Erkennen und Reagieren auf nicht verwendete Identitäten hilft Ihnen, nicht autorisierte Entitäten am Zugriff auf Ihre AWS-Ressourcen zu hindern.

Schweregrad: Mittel

GCP-Identitäts- und Zugriffsempfehlungen

Kryptografische Schlüssel sollten nicht mehr als drei Benutzer haben.

Beschreibung: Diese Empfehlung bewertet DIE IAM-Richtlinien für Schlüsselringe, Projekte und Organisationen und ruft Prinzipale mit Rollen ab, mit denen sie Daten mithilfe von Cloud-KMS-Schlüsseln verschlüsseln, entschlüsseln oder signieren können: Rollen/Besitzer, Rollen/cloudkms.cryptoKeyEncrypterDecrypter, roles/cloudkms.cryptoKeyEncrypter, roles/cloudkms.cryptoKeyDecrypter, roles/cloudkms.signer und roles/cloudkms.signerVerifier.

Schweregrad: Mittel

Für ein Projekt dürfen keine API-Schlüssel erstellt werden.

Beschreibung: Schlüssel sind unsicher, da sie öffentlich angezeigt werden können, z. B. in einem Browser oder auf einem Gerät, auf dem sich der Schlüssel befindet. Es wird empfohlen, stattdessen den Standardauthentifizierungsfluss zu verwenden.

Nachstehend sind die Sicherheitsrisiken bei der Verwendung von API-Keys aufgeführt:

• API-Schlüssel sind einfache verschlüsselte Zeichenfolgen
• API-Schlüssel identifizieren den Benutzer oder die Anwendung, die die API-Anforderung stellt
• AUF API-Schlüssel kann in der Regel auf Clients zugegriffen werden, wodurch ein API-Schlüssel leicht erkannt und gestohlen werden kann.

Um das Sicherheitsrisiko bei der Verwendung von API-Schlüsseln zu vermeiden, empfiehlt es sich stattdessen, den Standardauthentifizierungsfluss zu verwenden.

Schweregrad: hoch

Stellen Sie sicher, dass API-Schlüssel nur auf APIs beschränkt sind, auf die die Anwendung Zugriff benötigt.

Beschreibung: API-Schlüssel sind unsicher, da sie öffentlich angezeigt werden können, z. B. in einem Browser oder auf einem Gerät, auf dem sich der Schlüssel befindet. Es wird empfohlen, api-Schlüssel so einzuschränken, dass nur APIs verwendet werden ( aufrufen), die von einer Anwendung benötigt werden.

Nachstehend sind die Sicherheitsrisiken bei der Verwendung von API-Keys aufgeführt:

• API-Schlüssel sind einfache verschlüsselte Zeichenfolgen
• API-Schlüssel identifizieren den Benutzer oder die Anwendung, die die API-Anforderung stellt
• AUF API-Schlüssel kann in der Regel auf Clients zugegriffen werden, wodurch ein API-Schlüssel leicht erkannt und gestohlen werden kann.

Angesichts dieser potenziellen Risiken empfiehlt Google die Verwendung des Standardauthentifizierungsflows anstelle von API-Schlüsseln. Es gibt jedoch einige wenige Fälle, in denen API-Schlüssel besser geeignet sind. Wenn beispielsweise eine mobile Anwendung vorhanden ist, die die Google Cloud Translation-API verwenden muss, andernfalls aber keinen Back-End-Server benötigt, sind API-Schlüssel die einfachste Möglichkeit, sich bei dieser API zu authentifizieren.

Um Angriffsflächen durch Erteilung der geringsten Rechte zu reduzieren, können API-Schlüssel so beschränkt werden, dass nur die von einer Anwendung benötigten APIs verwendet (aufgerufen) werden können.

Schweregrad: hoch

API-Schlüssel dürfen nur durch angegebene Hosts und Apps verwendet werden.

Beschreibung: Uneingeschränkte Schlüssel sind unsicher, da sie öffentlich angezeigt werden können, z. B. in einem Browser oder auf einem Gerät, auf dem sich der Schlüssel befindet. Es wird empfohlen, die API-Schlüsselverwendung auf vertrauenswürdige Hosts, HTTP-Verweise und Apps einzuschränken.

Nachstehend sind die Sicherheitsrisiken bei der Verwendung von API-Keys aufgeführt:

• API-Schlüssel sind einfache verschlüsselte Zeichenfolgen
• API-Schlüssel identifizieren den Benutzer oder die Anwendung, die die API-Anforderung stellt
• AUF API-Schlüssel kann in der Regel auf Clients zugegriffen werden, wodurch ein API-Schlüssel leicht erkannt und gestohlen werden kann.

Angesichts dieser potenziellen Risiken empfiehlt Google die Verwendung des Standardauthentifizierungsflows anstelle von API-Schlüsseln. Es gibt jedoch einige wenige Fälle, in denen API-Schlüssel besser geeignet sind. Wenn beispielsweise eine mobile Anwendung vorhanden ist, die die Google Cloud Translation-API verwenden muss, andernfalls aber keinen Back-End-Server benötigt, sind API-Schlüssel die einfachste Möglichkeit, sich bei dieser API zu authentifizieren.

Um Angriffsvektoren zu reduzieren, können API-Schlüssel nur auf vertrauenswürdige Hosts, HTTP-Verweisende und Anwendungen beschränkt werden.

Schweregrad: hoch

API-Schlüssel müssen alle 90 Tage rotiert werden.

Beschreibung: Es wird empfohlen, API-Schlüssel alle 90 Tage zu drehen.

Nachstehend sind die Sicherheitsrisiken bei der Verwendung von API-Keys aufgeführt:

• API-Schlüssel sind einfache verschlüsselte Zeichenfolgen
• API-Schlüssel identifizieren den Benutzer oder die Anwendung, die die API-Anforderung stellt
• AUF API-Schlüssel kann in der Regel auf Clients zugegriffen werden, wodurch ein API-Schlüssel leicht erkannt und gestohlen werden kann.

Angesichts dieser potenziellen Risiken empfiehlt Google die Verwendung des Standardauthentifizierungsflows anstelle von API-Schlüsseln. Es gibt jedoch einige wenige Fälle, in denen API-Schlüssel besser geeignet sind. Wenn beispielsweise eine mobile Anwendung vorhanden ist, die die Google Cloud Translation-API verwenden muss, andernfalls aber keinen Back-End-Server benötigt, sind API-Schlüssel die einfachste Möglichkeit, sich bei dieser API zu authentifizieren.

Sobald ein Schlüssel gestohlen wurde, hat er keinen Ablauf, d. h. er kann unbegrenzt verwendet werden, es sei denn, der Projektbesitzer widerruft oder generiert den Schlüssel erneut. Durch Rotieren von API-Schlüsseln wird das Zeitfenster für die mögliche Verwendung eines Zugriffsschlüssels verkürzt, der einem kompromittierten oder beendeten Konto zugeordnet ist.

API-Schlüssel sollten gedreht werden, um sicherzustellen, dass auf Daten nicht mit einem alten Schlüssel zugegriffen werden kann, der verloren gegangen, geknackt oder gestohlen wurde.

Schweregrad: hoch

KMS-Verschlüsselungsschlüssel müssen innerhalb von 90 Tagen rotiert werden.

Beschreibung: Google Cloud Schlüsselverwaltungsdienst speichert kryptografische Schlüssel in einer hierarchischen Struktur, die für nützliche und elegante Zugriffssteuerungsverwaltung entwickelt wurde. Das Format für den Rotationszeitplan hängt von der verwendeten Clientbibliothek ab. Für das Befehlszeilentool gcloud muss sich die nächste Drehungszeit im Format "ISO" oder "RFC3339" befinden, und der Drehungszeitraum muss sich in Form "INTEGER[UNIT]," befinden, wobei Einheiten eine von Sekunden (s), Minuten (m), Stunden (h) oder Tage (d) sein können. Legen Sie einen Periode und eine Startzeit für die Schlüsselrotation fest. Ein Schlüssel kann mit einem angegebenen "Drehungszeitraum" erstellt werden, was die Zeit zwischen dem Automatischen Generieren neuer Schlüsselversionen ist. Ein Schlüssel kann auch mit einem bestimmten nächsten Rotationszeitpunkt erstellt werden. Bei einem Schlüssel handelt es sich um ein benanntes Objekt, das einen "kryptografischen Schlüssel" darstellt, der für einen bestimmten Zweck verwendet wird. Das Schlüsselmaterial, die tatsächlichen Bits, die für die "Verschlüsselung" verwendet werden, können sich im Laufe der Zeit ändern, wenn neue Schlüsselversionen erstellt werden. Ein Schlüssel wird verwendet, um einige "Korpus von Daten" zu schützen. Eine Sammlung von Dateien könnte mit demselben Schlüssel verschlüsselt werden, und Personen mit "Entschlüsseln"-Berechtigungen für diesen Schlüssel könnten diese Dateien entschlüsseln. Daher muss sichergestellt werden, dass die "Rotationsperiode" auf einen bestimmten Zeitpunkt festgelegt ist.

Schweregrad: Mittel

Für Zuweisungsänderungen des Projektbesitzes müssen ein Protokollmetrikfilter und -alarm vorhanden sein.

Beschreibung: Um unnötige Projektbesitzzuweisungen an Benutzer/Dienstkonten und weitere Missbrauch von Projekten und Ressourcen zu verhindern, sollten alle Zuordnungen "Rollen/Besitzer" überwacht werden. Mitglieder (Benutzer/Dienstkonten) mit einer Rollenzuweisung zur primitiven Rolle "roles/Owner" sind Projektbesitzer. Der Projektbesitzer verfügt über alle Berechtigungen für das Projekt, zu dem die Rolle gehört. Diese werden nachfolgend zusammengefasst:

• Alle Viewerberechtigungen für alle GCP-Dienste innerhalb des Projekts
• Berechtigungen für Aktionen, die den Status aller GCP-Dienste innerhalb des Projekts ändern
• Verwalten von Rollen und Berechtigungen für ein Projekt und alle Ressourcen innerhalb des Projekts
• Das Einrichten der Abrechnung für ein Projekt, das der Besitzerrolle einem Mitglied (User/Service-Account) zu gewähren, ermöglicht es diesem Mitglied, die Identitäts- und Zugriffsverwaltungsrichtlinie (IAM) zu ändern. Weisen Sie daher die Rolle "Besitzer" nur zu, wenn das Mitglied einen legitimen Zweck zur Verwaltung der IAM-Richtlinie hat. Dies liegt daran, dass die IAM-Richtlinie des Projekts vertrauliche Zugriffssteuerungsdaten enthält. Wenn Sie nur eine minimale Anzahl von Benutzern haben, die die IAM-Richtlinie verwalten dürfen, wird die Überwachung vereinfacht, die möglicherweise erforderlich ist. Der Projektbesitzer verfügt über die höchste Berechtigungsstufe für ein Projekt. Um einen Missbrauch von Projektressourcen zu vermeiden, sollten die oben genannten Zuordnungs-/Änderungsaktionen für den Projektbesitz überwacht und die betroffenen Empfänger benachrichtigt werden.
• Senden von Projektbesitzseinladungen
• Akzeptanz/Ablehnung der Projektbesitzeinladung durch den Benutzer
• Hinzufügen role\Owner zu einem Benutzer-/Dienstkonto
• Entfernen eines Benutzer-/Dienstkontos aus role\Owner

Schweregrad: Niedrig

OS Login muss für ein Projekt aktiviert sein

Beschreibung: Durch aktivieren der Betriebssystemanmeldung werden SSH-Zertifikate an IAM-Benutzer gebunden und eine effektive SSH-Zertifikatverwaltung ermöglicht. Durch Aktivieren von OS Login wird sichergestellt, dass SSH-Schlüssel, die zum Herstellen einer Verbindung mit Instanzen verwendet werden, IAM-Benutzern zugeordnet werden. Wird der Zugriff für IAM-Benutzer widerrufen, werden alle SSH-Schlüssel widerrufen, die dem jeweiligen Benutzer zugeordnet sind. Es erleichtert die zentrale und automatisierte SSH-Schlüsselpaarverwaltung, die bei der Behandlung von Fällen wie der Reaktion auf kompromittierte SSH-Schlüsselpaare und/oder die Sperrung externer/Drittanbieter-/Anbieterbenutzer hilfreich ist. Um herauszufinden, welche Instanz bewirkt, dass das Projekt fehlerhaft ist, lesen Sie die Empfehlung "Sicherstellen, dass oslogin für alle Instanzen aktiviert ist".

Schweregrad: Mittel

OS Login muss für alle Instanzen aktiviert sein.

Beschreibung: Durch aktivieren der Betriebssystemanmeldung werden SSH-Zertifikate an IAM-Benutzer gebunden und eine effektive SSH-Zertifikatverwaltung ermöglicht. Durch Aktivieren von OS Login wird sichergestellt, dass SSH-Schlüssel, die zum Herstellen einer Verbindung mit Instanzen verwendet werden, IAM-Benutzern zugeordnet werden. Wird der Zugriff für IAM-Benutzer widerrufen, werden alle SSH-Schlüssel widerrufen, die dem jeweiligen Benutzer zugeordnet sind. Es erleichtert die zentrale und automatisierte SSH-Schlüsselpaarverwaltung, die bei der Behandlung von Fällen wie der Reaktion auf kompromittierte SSH-Schlüsselpaare und/oder die Sperrung externer/Drittanbieter-/Anbieterbenutzer hilfreich ist.

Schweregrad: Mittel

Ordnungsgemäße Konfiguration der Cloudüberwachungsprotokollierung für alle Dienste und alle Benutzer eines Projekts sicherstellen

Beschreibung: Es wird empfohlen, die Cloudüberwachungsprotokollierung so konfiguriert, dass alle Administratoraktivitäten nachverfolgt und Lese-, Schreibzugriff auf Benutzerdaten geschrieben werden.

Die Cloudüberwachungsprotokollierung verwaltet zwei Audit-Logs für jedes Projekt, jeden Ordner und jede Organisation: Administratoraktivität und Datenzugriff.

• Administratoraktivitätsprotokolle enthalten Protokolleinträge für API-Aufrufe oder andere administrative Aktionen, die die Konfiguration oder Metadaten von Ressourcen ändern.
• Administratoraktivitätsüberwachungsprotokolle sind für alle Dienste aktiviert und können nicht konfiguriert werden.
• Audit-Logs zum Datenzugriff zeichnen API-Aufrufe auf, die vom Benutzer bereitgestellte Daten erstellen, ändern oder lesen. Diese sind standardmäßig deaktiviert und sollten aktiviert werden.

Es gibt drei Arten von Informationen in Audit-Logs zum Datenzugriff:

• ADMIN_READ: Zeichnet Vorgänge auf, bei denen Metadaten oder Konfigurationsinformationen gelesen werden. Die Administratoraktivitätsüberwachungsprotokolle zeichnen Schreibvorgänge von Metadaten und Konfigurationsinformationen auf, die nicht deaktiviert werden können.
• DATA_READ: Zeichnet Vorgänge auf, die vom Benutzer bereitgestellte Daten lesen.
• DATA_WRITE: Zeichnet Vorgänge auf, die vom Benutzer bereitgestellte Daten schreiben.

Es wird empfohlen, eine effektive Standardüberwachungskonfiguration so konfiguriert zu haben, dass:

• Der Protokolltyp ist auf DATA_READ (zum Protokollieren der Benutzeraktivitätsnachverfolgung) und DATA_WRITES (zum Protokollieren von Änderungen/Manipulationen an Benutzerdaten) festgelegt.
• Die Überwachungskonfiguration ist für alle Dienste aktiviert, die von der Datenzugriffsüberwachungsprotokollfunktion unterstützt werden.
• Protokolle sollten für alle Benutzer erfasst werden, d. h., es gibt keine ausgenommenen Benutzer in einem der Überwachungskonfigurationsabschnitte. Dadurch wird sichergestellt, dass ein Überschreiben der Auditkonfiguration nicht der Anforderung widerspricht.

Schweregrad: Mittel

Stellen Sie sicher, dass Cloud KMS-Kryptoschlüssel nicht anonym oder öffentlich zugänglich sind

Beschreibung: Es wird empfohlen, dass die IAM-Richtlinie für Cloud-KMS-Kryptoschlüssel anonymen und/oder öffentlichen Zugriff einschränken sollte. Durch das Erteilen von Berechtigungen für "allUsers" oder "allAuthenticatedUsers" kann jeder auf das Dataset zugreifen. Ein solcher Zugriff ist möglicherweise nicht wünschenswert, wenn vertrauliche Daten am Speicherort gespeichert werden. Stellen Sie in diesem Fall sicher, dass anonymer und/oder öffentlicher Zugriff auf einen Cloud-KMS-Kryptoschlüssel nicht zulässig ist.

Schweregrad: hoch

Es müssen Unternehmensanmeldeinformationen verwendet werden.

Beschreibung: Verwenden Sie Unternehmensanmeldeinformationen anstelle von persönliches Konto, z. B. Gmail-Konten. Es wird empfohlen, vollständig verwaltete Google-Firmenkonten für erhöhte Sichtbarkeit, Überwachung und Kontrolle des Zugriffs auf Cloud Platform-Ressourcen zu verwenden. Gmail-Konten, die außerhalb der Organisation des Benutzers basieren, z. B. persönliches Konto, sollten nicht für geschäftliche Zwecke verwendet werden.

Schweregrad: hoch

Auf Projektebene dürfen IAM-Benutzern nicht die Rollen für Dienstkontobenutzer und Dienstkonto-Tokenersteller gewährt werden.

Beschreibung: Es wird empfohlen, einem Benutzer die Rollen "Service Account User (iam.serviceAccountUser)" und "Service Account Token Creator (iam.serviceAccountTokenCreator)" einem Benutzer für ein bestimmtes Dienstkonto zuzuweisen, anstatt die Rolle einem Benutzer auf Projektebene zuzuweisen. Ein Dienstkonto ist ein spezielles Google-Konto, das zu einer Anwendung oder einem virtuellen Computer (VM) und nicht zu einem einzelnen Endbenutzer gehört. Eine Anwendung/VM-Instanz verwendet das Dienstkonto, um die Google-API des Diensts aufzurufen, sodass Benutzer nicht direkt beteiligt sind. Ein Dienstkonto ist nicht nur eine Identität, sondern auch eine Ressource, für die IAM-Richtlinien gelten. Diese Richtlinien bestimmen, wer das Dienstkonto verwenden kann. Benutzer mit IAM-Rollen zum Aktualisieren der App Engine- und Compute Engine-Instanzen (z. B. App Engine-Bereitsteller oder Compute-Instanzadministrator) können Code als Dienstkonten ausführen, die zum Ausführen dieser Instanzen verwendet werden. Sie erhalten indirekt Zugriff auf alle Ressourcen, auf die die Dienstkonten Zugriff haben. Ebenso kann der SSH-Zugriff auf eine Compute Engine-Instanz auch die Möglichkeit bieten, Code als diese Instanz/das Dienstkonto auszuführen. Je nach Geschäftsanforderungen können mehrere vom Benutzer verwaltete Dienstkonten für ein Projekt konfiguriert werden. Das Gewähren der Rollen "iam.serviceAccountUser" oder "iam.serviceAserviceAccountTokenCreatorccountUser" für einen Benutzer für ein Projekt gewährt dem Benutzer Zugriff auf alle Dienstkonten im Projekt, einschließlich Dienstkonten, die in Zukunft erstellt werden können. Dies kann zu einer Erhöhung von Berechtigungen führen, indem Dienstkonten und entsprechende "Compute Engine-Instanzen" verwendet werden. Um bewährte Methoden für "geringste Berechtigungen" zu implementieren, sollten IAM-Benutzer nicht den Rollen "Service Account User" oder "Service Account Token Creator" auf Projektebene zugewiesen werden. Stattdessen sollten diese Rollen einem Benutzer für ein bestimmtes Dienstkonto zugewiesen werden, sodass der betreffenden Benutzer Zugriff auf das Dienstkonto erhält. Die Rolle "Dienstkontobenutzer" ermöglicht es einem Benutzer, ein Dienstkonto an einen Dienst für einen Auftrag mit langer Ausführungszeit zu binden, während die Rolle "Ersteller von Dienstkonto-Token" es einem Benutzer ermöglicht, direkt die Identität eines Dienstkontos anzunehmen (oder zu bestätigen).

Schweregrad: Mittel

Beim Zuweisen von KMS-bezogenen Rollen für Benutzer muss die Aufgabentrennung erzwungen werden.

Beschreibung: Es wird empfohlen, das Prinzip der "Trennung von Pflichten" beim Zuweisen von KMS-bezogenen Rollen für Benutzer durchzusetzen. Die integrierte/vordefinierte IAM-Rolle "Cloud KMS-Administrator" ermöglicht es dem Benutzer/der Identität, Dienstkonten zu erstellen, zu löschen und zu verwalten. Die integrierte/vordefinierte IAM-Rolle Cloud KMS CryptoKey Encrypter/Decrypter ermöglicht es dem Benutzer/der Identität (mit angemessenen Berechtigungen für betroffene Ressourcen), ruhende Daten mithilfe eines Verschlüsselungsschlüssels zu verschlüsseln und zu entschlüsseln. Mit der integrierten/vordefinierten IAM-Rolle Cloud KMS CryptoKey Encrypter können Benutzer/Identitäten (mit angemessenen Berechtigungen für betroffene Ressourcen) ruhende Daten mithilfe eines Verschlüsselungsschlüssels verschlüsseln. Die integrierte/vordefinierte IAM-Rolle Cloud KMS Crypto Key Decrypter ermöglicht es dem Benutzer/der Identität (mit angemessenen Berechtigungen für betroffene Ressourcen), ruhende Daten mithilfe eines Verschlüsselungsschlüssels zu entschlüsseln. Die Trennung von Aufgaben ist das Konzept, sicherzustellen, dass ein Einzelner nicht über alle erforderlichen Berechtigungen verfügt, um eine böswillige Aktion ausführen zu können. In Cloud KMS könnte dies eine Aktion sein, z. B. die Verwendung eines Schlüssels für den Zugriff auf und das Entschlüsseln von Daten, auf die ein Benutzer normalerweise keinen Zugriff haben sollte. Die Aufgabentrennung ist eine Steuerungsmaßnahme, die in der Regel in größeren Organisationen verwendet wird und dazu beitragen soll, Sicherheits- oder Datenschutzvorfälle und Fehler zu vermeiden. Es wird als bewährte Methode angesehen. Es sollte kein Benutzer über cloud-KMS-Administrator und eine der Cloud KMS CryptoKey Encrypter/DecrypterCloud KMS CryptoKey EncrypterRollen verfügen, Cloud KMS CryptoKey Decrypter die gleichzeitig zugewiesen sind.

Schweregrad: hoch

Beim Zuweisen von Benutzerrollen im Zusammenhang mit Dienstkonten muss die Aufgabentrennung erzwungen werden.

Beschreibung: Es wird empfohlen, das Prinzip der "Trennung von Pflichten" beim Zuweisen von Dienstkontenrollen für Benutzer durchzusetzen. Die integrierte/vordefinierte IAM-Rolle "Dienstkontoadministrator " ermöglicht es dem Benutzer/der Identität, Dienstkonten zu erstellen, zu löschen und zu verwalten. Die integrierte/vordefinierte IAM-Rolle "Dienstkontoadministrator" ermöglicht es dem Benutzer/der Identität (mit entsprechenden Berechtigungen für Compute und App Engine), Apps/Compute-Instanzen Dienstkonten zuzuweisen. Die Trennung von Aufgaben ist das Konzept, sicherzustellen, dass ein Einzelner nicht über alle erforderlichen Berechtigungen verfügt, um eine böswillige Aktion ausführen zu können. In Cloud IAM – Dienstkonten kann dies eine Aktion sein, z. B. die Verwendung eines Dienstkontos für den Zugriff auf Ressourcen, auf die der Benutzer normalerweise keinen Zugriff haben sollte. Die Aufgabentrennung ist eine Steuerungsmaßnahme, die in der Regel in größeren Organisationen verwendet wird und dazu beitragen soll, Sicherheits- oder Datenschutzvorfälle und Fehler zu vermeiden. Es wird als bewährte Methode angesehen. Einem Benutzer sollten niemals gleichzeitig die Rollen "Dienstkontoadministrator" und "Dienstkontonutzer" zugewiesen werden.

Schweregrad: Mittel

Dienstkonten dürfen keine Administratorberechtigungen umfassen.

Beschreibung: Ein Dienstkonto ist ein spezielles Google-Konto, das zu einer Anwendung oder einem virtuellen Computer gehört, anstelle eines einzelnen Endbenutzers. Die Anwendung verwendet das Dienstkonto, um die Google-API des Diensts aufzurufen, sodass Benutzer nicht direkt beteiligt sind. Es wird empfohlen, für Dienstkonten keinen Administratorzugriff verwenden. Dienstkonten sorgen für die Sicherheit der Ressourcen (Anwendung oder VM) auf Dienstebene, die durch die zugewiesenen Rollen bestimmt werden kann. Durch die Registrierung eines Dienstkontos mit Administratorrechten wird der uneingeschränkte Zugriff auf eine zugewiesene Anwendung oder VM ermöglicht. Ein ServiceAccount Access-Inhaber kann wichtige Aktionen wie Löschen, Aktualisieren von Änderungseinstellungen usw. ohne Benutzereingriff ausführen. Aus diesem Grund wird empfohlen, dass Dienstkonten nicht über Administratorrechte verfügen.

Schweregrad: Mittel

Für alle Protokolleinträge müssen Senken konfiguriert sein.

Beschreibung: Es wird empfohlen, eine Spüle zu erstellen, die Kopien aller Protokolleinträge exportiert. Dies kann hilfreich sein, um Protokolle aus mehreren Projekten zu aggregieren und in ein SIEM (Security Information and Event Management) zu exportieren. Protokolleinträge werden in der Stackdriver-Protokollierung gespeichert. Um Protokolle zu aggregieren, exportieren Sie diese in ein SIEM. Um sie länger zu halten, empfiehlt es sich, eine Protokollspüle einzurichten. Beim Exportieren wird ein Filter erstellt, der die zu exportierenden Protokolleinträge auswählt, und ein Ziels in Cloud Storage, BigQuery oder Cloud Pub/Sub ausgewählt. Filter und Ziel befinden sich in einem Objekt, das als Senke bezeichnet wird. Um sicherzustellen, dass alle Protokolleinträge in Senken exportiert werden, stellen Sie sicher, dass kein Filter für eine Spüle konfiguriert ist. Senken können in Projekten, Organisationen, Ordnern und Abrechnungskonten erstellt werden.

Schweregrad: Niedrig

Für Änderungen an der Überwachungskonfiguration müssen Protokollmetrikfilter und -warnungen vorhanden sein.

Beschreibung: Google Cloud Platform (GCP)-Dienste schreiben Überwachungsprotokolleinträge in Administratoraktivitäts- und Datenzugriffsprotokolle. Einträge helfen dabei, die Fragen zu beantworten: "Wer hat was gemacht, wo und wann?" in GCP-Projekten. Die aufgezeichneten Informationen in Clouds umfassen die Identität des API-Aufrufers, den Zeitpunkt des API-Aufrufs, die Quell-IP-Adresse des API-Aufrufers, die Anforderungsparameter und die vom GCP-Dienst zurückgegebenen Antwortelemente. Die Cloud Audit-Logs stellen den Verlauf der GCP-API-Aufrufe für ein Konto zur Verfügung, einschließlich API-Aufrufe über die Konsole, SDKs, Befehlszeilentools und andere GCP-Dienste. Administratoraktivitäten und Datenzugriffsprotokolle, die von der Cloudüberwachungsprotokollierung erstellt werden, ermöglichen Sicherheitsanalyse, Ressourcenänderungsnachverfolgung und Complianceüberwachung. Durch Konfigurieren von Metrikfilter und Warnungen für Änderungen der Überwachungskonfiguration wird sichergestellt, dass der empfohlene Zustand der Überwachungskonfiguration beibehalten wird, sodass alle Aktivitäten im Projekt jederzeit überwacht werden können.

Schweregrad: Niedrig

Für Änderungen an benutzerdefinierten Rollen müssen Protokollmetrikfilter und -warnungen vorhanden sein.

Beschreibung: Es wird empfohlen, dass ein Metrikfilter und -alarm für Änderungen an der Identitäts- und Zugriffsverwaltung (IAM)-Rollenerstellung, -löschung und -aktualisierung eingerichtet werden. Google Cloud IAM bietet vordefinierte Rollen, die differenzierten Zugriff auf bestimmte Google Cloud Platform-Ressourcen ermöglichen und unerwünschten Zugriff auf andere Ressourcen verhindern. Um jedoch organisationsspezifische Anforderungen zu erfüllen, bietet Cloud IAM auch die Möglichkeit, benutzerdefinierte Rollen zu erstellen. Projektbesitzer und Administratoren mit der Rolle "Administrator für Organisationsrollen" oder "IAM-Rollenadministrator" können benutzerdefinierte Rollen erstellen. Die Überwachung von Aktivitäten zum Erstellen, Löschen und Aktualisieren von Rollen hilft dabei, frühzeitig alle überprivilegierten Rollen zu identifizieren.

Schweregrad: Niedrig

Stellen Sie sicher, dass Benutzer verwaltete/externe Schlüssel für Dienstkonten alle 90 Tage oder weniger rotiert werden.

Beschreibung: Dienstkontoschlüssel bestehen aus einer Schlüssel-ID (Private_key_Id) und privatem Schlüssel, die verwendet werden, um programmgesteuerte Anfragen zu signieren, die Benutzer an Google Cloud Services zugänglich für dieses bestimmte Dienstkonto machen. Es wird empfohlen, dass alle Dienstkontoschlüssel regelmäßig gedreht werden. Das Rotieren von Dienstkontoschlüsseln reduziert das Zeitfenster für die Verwendung eines Zugriffsschlüssels, der einem kompromittierten oder beendeten Konto zugeordnet ist. Dienstkontoschlüssel sollten gedreht werden, um sicherzustellen, dass auf Daten nicht mit einem alten Schlüssel zugegriffen werden kann, der verloren gegangen, geknackt oder gestohlen wurde. Jedem Dienstkonto ist ein Schlüsselpaar zugeordnet, das von Google Cloud Platform (GCP) verwaltet wird. Sie wird für die Dienst-zu-Dienst-Authentifizierung innerhalb von GCP verwendet. Google rotiert die Schlüssel täglich. GCP bietet die Möglichkeit, vom Benutzer verwaltete Schlüsselpaare (sogenannte externe Schlüsselpaare) für die Verwendung außerhalb von GCP zu erstellen (z. B. Verwendung als Standardanmeldeinformationen für die Anwendung). Wenn ein neues Schlüsselpaar erstellt wird, muss der Benutzer den privaten Schlüssel herunterladen (der nicht von Google aufbewahrt wird).

Bei externen Schlüsseln sind Benutzer dafür verantwortlich, den privaten Schlüssel sicher und andere Verwaltungsvorgänge wie z. B. Die Schlüsselrotation zu gewährleisten. Externe Schlüssel können über die IAM-API, das Befehlszeilentool "gcloud" oder die Seite "Dienstkonten" in der Google Cloud Platform-Konsole verwaltet werden.

GCP erleichtert bis zu 10 externe Dienstkontoschlüssel pro Dienstkonto, um die Schlüsseldrehung zu erleichtern.

Schweregrad: Mittel

GCP-überprovisionierte Identitäten sollten nur über die erforderlichen Berechtigungen verfügen (Vorschau)

Beschreibung: Eine überlastete aktive Identität ist eine Identität, die Zugriff auf Berechtigungen hat, die sie nicht verwendet haben. Überlastete aktive Identitäten, insbesondere für nichtmenschliche Konten mit sehr definierten Aktionen und Verantwortlichkeiten, können den Explosionsradius im Falle eines Benutzers, schlüssels oder ressourcenkompromittieren Das Prinzip der geringsten Berechtigungen besagt, dass eine Ressource nur Zugriff auf die genauen Ressourcen haben sollte, die sie benötigt, um funktionieren zu können. Dieses Prinzip wurde entwickelt, um das Risiko kompromittierter Identitäten zu beheben, die einem Angreifer Zugriff auf eine vielzahl von Ressourcen gewähren.

Das GKE-Webdashboard sollte deaktiviert sein.

Beschreibung: Diese Empfehlung wertet das KubernetesDashboard-Feld der AddonsConfig-Eigenschaft für das Schlüsselwertpaar "disabled": false aus.

Schweregrad: hoch

Die Legacy-Autorisierung sollte in GKE-Clustern deaktiviert werden.

Beschreibung: Diese Empfehlung wertet die LegacyAbac-Eigenschaft eines Clusters für das Schlüsselwertpaar "enabled": true aus.

Schweregrad: hoch

Berechtigungen von inaktiven Identitäten in Ihrem GCP-Projekt sollten widerrufen werden.

Beschreibung: Microsoft Defender für Cloud hat eine Identität entdeckt, die in den letzten 45 Tagen keine Aktion für eine Ressource innerhalb Ihres GCP-Projekts ausgeführt hat. Es wird empfohlen, Berechtigungen für inaktive Identitäten zu widerrufen, um die Angriffsfläche Ihrer Cloudumgebung zu verringern.

Schweregrad: Mittel

Eine Redis-IAM-Rolle sollte nicht auf Organisations- oder Ordnerebene zugewiesen sein.

Beschreibung: Diese Empfehlung wertet die IAM-Zulassungsrichtlinie in Ressourcenmetadaten für prinzipale zugewiesene Rollen/redis.admin, rollen/redis.editor, roles/redis.viewer auf Organisationsebene oder Ordnerebene aus.

Schweregrad: hoch

Dienstkonten sollten über eingeschränkten Projektzugriff in einem Cluster verfügen.

Beschreibung: Diese Empfehlung wertet die Konfigurationseigenschaft eines Knotenpools aus, um zu überprüfen, ob kein Dienstkonto angegeben wird oder ob das Standarddienstkonto verwendet wird.

Schweregrad: hoch

Benutzer sollten über Zugriff mit geringsten Rechten mit granularen IAM-Rollen verfügen.

Beschreibung: Diese Empfehlung wertet die IAM-Richtlinie in Ressourcenmetadaten für alle prinzipale zugewiesenen Rollen/Besitzer, Rollen/Autor oder Rollen/Leser aus.

Schweregrad: hoch

Zugehöriger Inhalt

• Informationen zu Sicherheitsempfehlungen
• Überprüfen von Sicherheitsempfehlungen