Disable

gcloud resource-manager org-policies disable-enforce [–folder | –organization | –project ]

</details>

Ein Python-Skript für diese Methode ist [hier](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py) zu finden.

### `orgpolicy.policy.set`, `iam.serviceAccounts.actAs`

Normalerweise ist es nicht möglich, einen Service Account aus einem anderen Projekt an eine Ressource anzuhängen, da eine Richtlinienbeschränkung namens **`iam.disableCrossProjectServiceAccountUsage`** dies verhindert.

Sie können überprüfen, ob diese Einschränkung durchgesetzt ist, indem Sie den folgenden Befehl ausführen:

<details>
<summary>Einschränkung für projektübergreifende Service Account-Nutzung überprüfen</summary>
```bash
gcloud resource-manager org-policies describe \
constraints/iam.disableCrossProjectServiceAccountUsage \
--project=<project-id> \
--effective

booleanPolicy:
enforced: true
constraint: constraints/iam.disableCrossProjectServiceAccountUsage

Dies verhindert, dass ein attacker die Berechtigung iam.serviceAccounts.actAs missbraucht, um ein service account aus einem anderen Projekt zu impersonieren, ohne die zusätzlich erforderlichen Infrastruktur-Berechtigungen (z. B. zum Starten einer neuen VM), was zu privilege escalation führen könnte.

Dennoch kann ein attacker mit der Berechtigung orgpolicy.policy.set diese Einschränkung umgehen, indem er die Constraint iam.disableServiceAccountProjectWideAccess deaktiviert. Dadurch kann der attacker ein service account aus einem anderen Projekt an eine Ressource in seinem eigenen Projekt anhängen und so effektiv seine Privilegien erhöhen.