![\"Zwei](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/hand-adspasskey-de.png\")
\n2. Halten Sie fest, wer was autorisiert<\/h2>\n\n\n\n
Beginnen Sie mit dem Artefakt, das fast niemand hat: einer schriftlichen Matrix Ihrer eigenen Zug\u00e4nge. Eine YAML-Datei im Repository ist ein Anfang, besser ist eine kleine SQLite-Tabelle, denn Sie werden sie abfragen wollen. Wichtig sind genau die Spalten, die Sie in sechs Monaten nicht mehr aus dem Ged\u00e4chtnis rekonstruieren k\u00f6nnen.<\/p>\n\n\n\n
create table ads_authorization (\n integration text primary key,\n auth_type text not null check (auth_type in ('user_account','service_account')),\n google_account text,\n config_path text,\n token_store text,\n owner text not null,\n deputy text,\n customer_ids text,\n last_verified date\n);\n\ninsert into ads_authorization values\n ('nightly-cost-load','user_account','ads-bot@example.com','\/srv\/etl\/conf\/ads.yaml',\n 'vault:kv\/ads\/refresh','l.wojcik','m.kowalski','123-456-7890,222-333-4444','2026-08-08'),\n ('bi-connector','service_account',null,'\/srv\/bi\/sa.json',\n 'gcp-secret-manager','platform-team',null,'123-456-7890','2026-08-08');<\/code><\/pre>\n\n\n\n\n- auth_type:<\/strong> trennt den Bestand mit einer einzigen
where<\/code>-Klausel in betroffen und nicht betroffen.<\/li>\n- deputy:<\/strong> das Feld, um das es bei dieser Anforderung eigentlich geht. Wenn die Person in
owner<\/code> drei Wochen weg ist, wer meldet sich dann an?<\/li>\n- token_store:<\/strong> Ein pers\u00f6nliches Home-Verzeichnis ist hier ein Befund, kein Wert.<\/li>\n<\/ul>\n\n\n\n
3. Finden Sie die Autorisierungen, die Sie vergessen haben<\/h2>\n\n\n\n
Ein Inventar ist nur so gut wie seine Abdeckung, und wehtun werden genau die Eintr\u00e4ge, die Ihnen entfallen sind. Durchsuchen Sie die Config-B\u00e4ume und vergleichen Sie das Ergebnis anschlie\u00dfend mit dem, was Sie notiert haben.<\/p>\n\n\n\n
grep -rIls -e refresh_token --include='*.y*ml' --include='*.json' --include='*.env' \\\n \/etc \/srv \/opt \/home<\/code><\/pre>\n\n\n\n#!\/usr\/bin\/env python3\n\"\"\"Lokale OAuth-Configs klassifizieren und mit dem Zugangsinventar abgleichen.\"\"\"\nimport pathlib, re, sqlite3, sys\n\nroot = pathlib.Path(sys.argv[1])\npatterns = (\"*.yaml\", \"*.yml\", \"*.json\", \"*.env\", \"*.ini\")\nhas_refresh = re.compile(r\"refresh_token\\s*[:=]\\s*\\S\")\nis_service = re.compile(r\"service_account|private_key_id\")\n\ndb = sqlite3.connect(\"access.db\")\nknown = {row[0] for row in db.execute(\"select config_path from ads_authorization\")}\n\nfor pattern in patterns:\n for path in sorted(root.rglob(pattern)):\n text = path.read_text(errors=\"ignore\")\n if not (has_refresh.search(text) or is_service.search(text)):\n continue\n kind = \"service_account\" if is_service.search(text) else \"user_account\"\n flag = \"\" if str(path) in known else \" UNTRACKED\"\n print(f\"{kind:16}{path}{flag}\")<\/code><\/pre>\n\n\n\nLassen Sie das Skript auf jedem Host laufen, der mit der API spricht \u2013 auch auf dem Analysten-Laptop, den niemand erw\u00e4hnen m\u00f6chte. Jede UNTRACKED<\/code>-Zeile ist entweder eine Zeile, die Sie dem Inventar schulden, oder ein Credential, das Sie heute widerrufen sollten. Hinter jeder user_account<\/code>-Zeile steht eine Person, die Sie jetzt namentlich benennen m\u00fcssen.<\/p>\n\n\n\n4. Der Notfallpfad f\u00fcr geteilte Zug\u00e4nge und Agenturzug\u00e4nge<\/h2>\n\n\n\n
Jetzt der operative Teil. Legen Sie f\u00fcr jede user_account<\/code>-Zeile vorab fest, was passiert, wenn diese Person nicht erreichbar ist \u2013 denn eine Anmeldung, die einen Passkey verlangt, verlangt auch den Menschen, der ihn besitzt.<\/p>\n\n\n\n\n- Benennen Sie eine Vertretung, die im Rahmen Ihrer eigenen Richtlinien Zugriff auf dasselbe Google-Konto hat, und tragen Sie sie in die Matrix ein.<\/li>\n
- Holen Sie den Refresh Token aus pers\u00f6nlichen Dateien heraus in Ihren Secret Store, damit die erneute Authentifizierung der einzige Schritt bleibt, f\u00fcr den es noch eine Person braucht.<\/li>\n
- Notieren Sie pro Integration, welche Customer IDs keine Daten mehr liefern, wenn diese Autorisierung wegbricht. Das ist Ihr Blast Radius, und er bestimmt die Reihenfolge der Arbeit.<\/li>\n
- Halten Sie bei Agentur-Setups schriftlich fest, welche Seite die Autorisierung h\u00e4lt und wer an einem Freitagabend angerufen wird. Pr\u00fcfen Sie anschlie\u00dfend, ob dort ein Service Account praktikabel ist, denn solche Zeilen fallen vollst\u00e4ndig aus dem Geltungsbereich der Anforderung heraus.<\/li>\n<\/ol>\n\n\n\n
select integration, google_account, owner, customer_ids\nfrom ads_authorization\nwhere auth_type = 'user_account'\n and (deputy is null or last_verified < date('now','-90 day'))\norder by owner;<\/code><\/pre>\n\n\n\nPacken Sie diese Abfrage in einen viertelj\u00e4hrlichen Cronjob und schicken Sie sich die Ausgabe per Mail. Eine leere Ergebnismenge ist das gesamte Review.<\/p>\n\n\n\n
5. Fazit<\/h2>\n\n\n\n
Sie haben drei kleine Dinge gebaut: eine Tabelle, die festh\u00e4lt, welche Integration von welchem Konto autorisiert ist, einen Suchlauf, der die Konfigurationen findet, die niemand dokumentiert hat, und eine Abfrage, die jeden Single Point of Failure ohne Vertretung auflistet. Nichts davon ist auf Google beschr\u00e4nkt. Es beantwortet eine Frage, die Ihnen fr\u00fcher oder sp\u00e4ter jede API stellen wird, in deren Autorisierungskette ein Mensch steht.<\/p>\n\n\n\n