Wenn Sie ein neuer Kunde sind, Trusted Cloud wird in den folgenden Fällen automatisch eine Organisationsressource für Ihre Domain bereitgestellt:
- Ein Nutzer aus Ihrer Domain meldet sich zum ersten Mal an.
- Ein Nutzer erstellt ein Rechnungskonto, dem keine zugehörige Organisationsressource zugeordnet ist.
Die Standardkonfiguration dieser Organisationsressource, die durch uneingeschränkten Zugriff gekennzeichnet ist, kann die Infrastruktur anfällig für Sicherheitsverletzungen machen. So ist beispielsweise das Erstellen von Standardschlüsseln für Dienstkonten eine kritische Sicherheitslücke, die Systeme potenziellen Sicherheitsverletzungen aussetzt.
Mit den standardmäßig sicheren Organisationsrichtlinien werden unsichere Konfigurationen durch eine Reihe von Organisationsrichtlinien behoben, die beim Erstellen einer Organisationsressource erzwungen werden. Beispiele für diese Maßnahmen sind das Deaktivieren des Erstellens von Dienstkontoschlüsseln und das Deaktivieren des Hochladens von Dienstkontoschlüsseln.
Wenn ein vorhandener Nutzer eine Organisation erstellt, kann die Sicherheitslage für die neue Organisationsressource von der der vorhandenen Organisationsressourcen abweichen. Standardmäßig sichere Organisationsrichtlinien werden für alle Organisationen erzwungen, die am oder nach dem 3. Mai 2024 erstellt wurden. Bei einigen Organisationen, die zwischen Februar 2024 und April 2024 erstellt wurden, sind diese Standardrichtliniendurchsetzungen möglicherweise ebenfalls festgelegt. Informationen zum Aufrufen von Organisationsrichtlinien, die auf Ihre Organisation angewendet werden, finden Sie unter Organisationsrichtlinien aufrufen.
Als Administrator sind die folgenden Szenarien relevant, in denen diese Organisationsrichtlinien automatisch durchgesetzt werden:
- Google Workspace- oder Cloud Identity-Konto: Wenn Sie ein Google Workspace- oder Cloud Identity-Konto haben, wird eine Organisationsressource erstellt, die mit Ihrer Domain verknüpft ist. Die standardmäßig sicheren Unternehmensrichtlinien werden automatisch für die Organisationsressource erzwungen.
- Erstellung von Rechnungskonten: Wenn das von Ihnen erstellte Rechnungskonto nicht mit einer Organisationsressource verknüpft ist, wird automatisch eine Organisationsressource erstellt. Die standardmäßig sicheren Organisationsrichtlinien werden für die Organisationsressource erzwungen. Dieses Szenario funktioniert sowohl in der Trusted Cloud Console als auch in der gcloud CLI.
Erforderliche Berechtigungen
Die IAM-Rolle (Identity and Access Management) roles/orgpolicy.policyAdmin
ermöglicht einem Administrator die Verwaltung von Organisationsrichtlinien. Sie müssen Administrator für Organisationsrichtlinien sein, um Organisationsrichtlinien ändern oder überschreiben zu können.
Führen Sie zum Zuweisen der Rolle den folgenden Befehl aus:
gcloud organizations add-iam-policy-binding ORGANIZATION --member=PRINCIPAL --role=ROLE
Ersetzen Sie Folgendes:
ORGANIZATION
: Eindeutige Kennung Ihrer Organisation.PRINCIPAL
: Das Mitglied, für das die Bindung eingefügt werden soll. Muss das Formatuser|group|serviceAccount:email
oderdomain:domain
haben. Beispiel:user:222larabrown@gmail.com
ROLE
: Die Rolle, die dem Hauptkonto zugewiesen werden soll. Verwenden Sie den vollständigen Pfad einer vordefinierten Rolle. In diesem Fall sollte esroles/orgpolicy.policyAdmin
sein.
Auf Organisationsressourcen erzwungene Organisationsrichtlinien
In der folgenden Tabelle sind die Einschränkungen für Organisationsrichtlinien aufgeführt, die automatisch erzwungen werden, wenn Sie eine Organisationsressource erstellen.
Name der Organisationsrichtlinie | Einschränkung der Organisationsrichtlinie | Beschreibung | Auswirkungen der Erzwingung |
---|---|---|---|
Erstellen von Dienstkontoschlüsseln deaktivieren | constraints/iam.disableServiceAccountKeyCreation |
Verhindern, dass Nutzer dauerhafte Schlüssel für Dienstkonten erstellen. Informationen zum Verwalten von Dienstkontoschlüsseln finden Sie unter Alternativen zum Erstellen von Dienstkontoschlüsseln anbieten. | Das Risiko, dass Anmeldedaten für Dienstkonten offengelegt werden, wird verringert. |
Hochladen von Dienstkontoschlüsseln deaktivieren | constraints/iam.disableServiceAccountKeyUpload |
Das Hochladen externer öffentlicher Schlüssel in Dienstkonten verhindern Informationen zum Zugriff auf Ressourcen ohne Dienstkontoschlüssel finden Sie in diesen Best Practices. | Das Risiko, dass Anmeldedaten für Dienstkonten offengelegt werden, wird verringert. |
Standarddienstberechtigungen für Standarddienstkonten deaktivieren | constraints/iam.automaticIamGrantsForDefaultServiceAccounts |
Verhindert, dass Standarddienstkonten beim Erstellen die IAM-Rolle Editor mit übermäßigen Berechtigungen erhalten. |
Mit der Rolle Editor kann das Dienstkonto Ressourcen für die meisten Trusted Cloud -Dienste erstellen und löschen. Dies stellt eine Sicherheitslücke dar, wenn das Dienstkonto kompromittiert wird. |
Identitäten nach Domain einschränken | constraints/iam.allowedPolicyMemberDomains |
Die Freigabe von Ressourcen auf Identitäten beschränken, die zu einer bestimmten Organisationsressource gehören. | Wenn die Organisationsressource für den Zugriff durch Akteure mit anderen Domains als der des Kunden geöffnet bleibt, entsteht eine Sicherheitslücke. |
Kontakte nach Domain einschränken | constraints/essentialcontacts.allowedContactDomains |
Durch diese Einschränkung von „Wichtige Kontakte“ erhalten nur verwaltete Nutzeridentitäten in den ausgewählten Domains Plattformbenachrichtigungen. | Ein böswilliger Akteur mit einer anderen Domain kann als wichtiger Kontakt hinzugefügt werden, was zu einer Beeinträchtigung der Sicherheit führen kann. |
Einheitlicher Zugriff auf Bucket-Ebene | constraints/storage.uniformBucketLevelAccess |
Verhindert, dass Cloud Storage-Buckets ACLs pro Objekt (ein separates System von Zulassungs- und Ablehnungsrichtlinien) für den Zugriff verwenden. | Sorgt für Konsistenz bei der Zugriffsverwaltung und beim Auditing. |
Zonales DNS standardmäßig verwenden | constraints/compute.setNewProjectDefaultToZonalDNSOnly |
Einschränkungen festlegen, sodass Anwendungsentwickler keine globalen DNS-Einstellungen für Compute Engine-Instanzen auswählen können. | Globale DNS-Einstellungen haben eine geringere Dienstzuverlässigkeit als zonale DNS-Einstellungen. |
Protokollweiterleitung basierend auf dem Typ der IP-Adresse einschränken | constraints/compute.restrictProtocolForwardingCreationForTypes |
Die Konfiguration der Protokollweiterleitung auf interne IP-Adressen beschränken. | Schützt Zielinstanzen vor externem Traffic. |
Durchsetzung von Organisationsrichtlinien verwalten
Sie können die Durchsetzung von Organisationsrichtlinien auf folgende Weise verwalten:
Organisationsrichtlinien auflisten
Mit dem folgenden Befehl können Sie prüfen, ob die standardmäßig sicheren Organisationsrichtlinien in Ihrer Organisation erzwungen werden:
gcloud resource-manager org-policies list --organization=ORGANIZATION_ID
Ersetzen Sie ORGANIZATION_ID
durch die eindeutige Kennung Ihrer Organisation.
Organisationsrichtlinien deaktivieren
Führen Sie den folgenden Befehl aus, um eine Organisationsrichtlinie zu deaktivieren oder zu löschen:
gcloud org-policies delete CONSTRAINT_NAME --organization=ORGANIZATION_ID
Ersetzen Sie Folgendes:
CONSTRAINT_NAME
ist der Name der Einschränkung für Organisationsrichtlinien, die Sie löschen möchten. Ein Beispiel dafür istiam.allowedPolicyMemberDomains
.ORGANIZATION_ID
ist die eindeutige Kennzeichnung Ihrer Organisation.
Werte für eine Organisationsrichtlinie hinzufügen oder aktualisieren
Wenn Sie Werte für eine Organisationsrichtlinie hinzufügen oder aktualisieren möchten, müssen Sie die Werte in einer YAML-Datei speichern. Beispiel für den Inhalt dieser Datei:
{
"name": "organizations/ORG_ID/policies/CONSTRAINT_NAME",
"spec": {
"rules": [
{
"values": {
"allowedValues": ["VALUE_A"]
}
}
]
}
}
Führen Sie den folgenden Befehl aus, um die in der YAML-Datei aufgeführten Werte hinzuzufügen oder zu aktualisieren:
gcloud org-policies set-policy POLICY_FILE
Ersetzen Sie POLICY_FILE
durch den Pfad zur YAML-Datei, die die Werte der Organisationsrichtlinie enthält.