Die Aufnahme externer Fachkräfte in ein PHP-Team erfordert nicht, ihnen dieselben Zugangsdaten zu geben, die interne Mitarbeitende verwenden. Der angemessene Zugriff hängt von der Aufgabe ab: Code schreiben, einen Fehler reproduzieren, Metriken prüfen oder ein Deployment ausführen sind unterschiedliche Tätigkeiten und erfordern nicht zwangsläufig dieselben Systeme oder Berechtigungen.
Ein wirksames Zugriffsmanagement für externe Entwickler kombiniert einen begrenzten Umfang, individuelle Identitäten, überprüfbare Laufzeiten und benannte interne Verantwortliche. Ziel ist es nicht, die Arbeit zu behindern, sondern die Angriffsfläche zu verringern und eine praktische Frage klar beantworten zu können: Wer kann was, in welchem System und wie lange tun?
Entwicklung, Tests, Deployment und Untersuchung trennen
Ordnen Sie die Tätigkeiten, für die Zugriff beantragt wird, bevor Sie Konten einrichten. Für die Entwicklung einer PHP-Funktion können Repository, technische Dokumentation und eine lokale Umgebung mit Testdaten ausreichen. Zur Überprüfung von Änderungen kann eine Integrations- oder Staging-Umgebung erforderlich sein. Code bereitzustellen, die Produktionsumgebung einzusehen und einen Vorfall zu untersuchen sind unterschiedliche Fälle und sollten getrennt bewertet werden.
Produktionszugriff ist für die Entwicklung nicht standardmäßig erforderlich. Wenn ein reales Problem untersucht werden muss, prüfen Sie zunächst, ob Protokolle, Traces, Metriken oder eine Reproduktion in einer isolierten Umgebung zur Diagnose ausreichen. Ist direkter Zugriff nötig, legen Sie fest, auf welche Ressource zugegriffen wird, welche Aktionen erlaubt sind und wann die Berechtigung abläuft.
Unterscheiden Sie außerdem zwischen der Berechtigung, Code zu ändern, und der Berechtigung, eine Version zu veröffentlichen. Eine Person kann eine Änderung vorbereiten und zur Überprüfung einreichen, ohne über Deployment-Rechte zu verfügen. Ebenso bedeutet Lesezugriff auf Metriken nicht, dass die Person Warnmeldungen oder Konfigurationen ändern darf.
Systeme und Zugriffsbeziehungen erfassen
Das Inventar sollte Personen konkreten Systemen zuordnen und sich nicht auf eine allgemeine Werkzeugliste beschränken. Prüfen Sie bei einer bestehenden PHP-Anwendung mindestens Folgendes:
- Repositories: Code, geschützte Branches, Review-Konfiguration und gegebenenfalls technische Dokumentation.
- Umgebungen: Entwicklung, Integration, Tests, Staging und Produktion; halten Sie fest, welche Daten und Dienste mit jeder Umgebung verbunden sind.
- Datenbanken: Instanz, Schema und erlaubte Vorgänge. Vergeben Sie keine Schreibrechte, wenn die Aufgabe nur Lesezugriff erfordert.
- Beobachtbarkeit: Protokolle, Metriken, Traces, Warnmeldungen und Fehlerverfolgungswerkzeuge; unterscheiden Sie zwischen Lesezugriff und Administration.
- Integration und Deployment: Pipelines, Artefaktmanager und Veröffentlichungsmechanismen. Halten Sie fest, wer Definitionen oder Secrets ändern kann.
- Verbundene Dienste: Speicher, E-Mail, Zahlungen, Queues, externe APIs und Secret-Management – je nachdem, was die Anwendung verwendet.
Dokumentieren Sie für jeden Eintrag die Identität, den Zweck, die Berechtigungsstufe, die intern genehmigende Person sowie das Prüf- oder Ablaufdatum. Mit diesem Inventar lassen sich indirekte Zugriffe erkennen: Eine Berechtigung für eine Pipeline kann beispielsweise ein Deployment in eine Umgebung ermöglichen, auch wenn das Konto keinen direkten Serverzugriff hat.
Begrenzte, individuelle und zeitlich befristete Berechtigungen vergeben
Verwenden Sie nach Möglichkeit individuelle Konten. Bei gemeinsam genutzten Konten lassen sich Aktionen nicht zuverlässig zuordnen, der Zugriff ist schwieriger zu entziehen, und Zugangsdaten können außerhalb der Kontrolle der Organisation geraten. Unterstützt ein Werkzeug keine getrennten Identitäten, dokumentieren Sie die Ausnahme und beschränken Sie, wer das Konto nutzen darf und wie dessen Nutzung protokolliert wird.
Wenden Sie das Prinzip der geringsten Berechtigung an: Gewähren Sie nur die Fähigkeiten, die für die aktuelle Aufgabe erforderlich sind. In einem Repository kann beispielsweise Lesezugriff für eine Codeprüfung ausreichen; Schreibrechte sind für Änderungen gerechtfertigt. In einer Nicht-Produktionsdatenbank kann ein Testkonto fiktive Testdaten und eingeschränkte Berechtigungen haben, statt Produktionszugangsdaten zu verwenden.
Trennen Sie Zugangsdaten nach Umgebung und Funktion. Verwenden Sie in der Entwicklung kein Secret wieder, das für die Produktion gültig ist, und nehmen Sie keine Zugangsdaten in Quellcode, freigegebene Dateien oder Tickets auf. Verwenden Sie den zugelassenen Mechanismus zur Speicherung von Secrets und beschränken Sie, wer sie einsehen oder rotieren kann. Wenn eine Aufgabe kein Secret erfordert, richten Sie die Umgebung so ein, dass die Person es nicht sehen muss.
Verknüpfen Sie jede Berechtigungsvergabe mit einer Frist oder einer ausdrücklichen Überprüfung. Die Dauer sollte sich nach der Aufgabe richten und nicht aus Bequemlichkeit zu einem unbefristeten Zugriff werden. Ein automatisches Ablaufdatum verringert das Risiko, etwas zu vergessen, ersetzt aber nicht die Überprüfung, wenn sich die Zuständigkeit ändert oder ein Auftrag endet.
Antrag, Genehmigung und Überprüfung festlegen
Definieren Sie einen einfachen Ablauf, der vier Punkte festhält: Wer beantragt den Zugriff, wofür wird er benötigt, wer genehmigt ihn und wie wird geprüft, ob er weiterhin erforderlich ist. Die Genehmigung sollte von einer internen Person kommen, die die Auswirkungen auf das System beurteilen kann, etwa der oder dem Verantwortlichen für die Anwendung oder Plattform. Bei sensiblen Berechtigungen kann je nach internem Verfahren zusätzlich eine Prüfung durch Sicherheit oder Betrieb erforderlich sein.
Dokumentieren Sie die Vergabe und Änderungen an einer Stelle, die für die Verantwortlichen einsehbar ist. Der Eintrag sollte erkennen lassen, welche Berechtigung wann erteilt wurde, ohne Passwörter oder Tokens zu speichern. Planen Sie Überprüfungen zu wichtigen Zeitpunkten ein: bei einem Aufgabenwechsel, bei der Verlängerung einer Zusammenarbeit und vor der Verlängerung von Berechtigungen, die Daten oder Deployments betreffen.
Stimmen Sie Infrastruktur- und Anwendungsberechtigungen aufeinander ab, aber setzen Sie sie nicht gleich. Ein Serverkonto, eine Cloud-Identität und ein Datenbankbenutzer sind unterschiedliche Kontrollen. Wird eine davon entzogen, verschwinden die anderen nicht zwangsläufig; und der Zugriff auf ein Dashboard schränkt nicht immer ein, was über eine API oder Pipeline möglich ist.
Ausnahmen für Produktion und Vorfälle vorbereiten
Bei manchen Vorfällen kann ein Zugriff auf die Produktionsumgebung oder ein dringender Eingriff erforderlich sein. Legen Sie im Voraus fest, wie diese Ausnahme aktiviert wird, wer den Zugriff genehmigt, welche Aktionen erlaubt sind und wer die Arbeit überwacht oder überprüft. Wenn praktikabel, verwenden Sie eine zeitlich befristete Berechtigung mit automatischem Ablauf und bewahren Sie verfügbare Aktivitätsprotokolle auf.
Trennen Sie bei dringenden Änderungen, sofern der Betriebsablauf es zulässt, die Genehmigung von der Ausführung: Wer den Vorfall untersucht, kann die Diagnose liefern oder die Änderung vorbereiten, während eine autorisierte Person sie prüft und veröffentlicht. Wenn die Situation den Eingriff derselben Person erfordert, dokumentieren Sie den Grund und führen Sie anschließend eine Überprüfung durch. Machen Sie aus einer einmaligen Ausnahme kein dauerhaftes Privileg.
Onboarding, Änderungen und Offboarding testen
Prüfen Sie das Verfahren anhand konkreter Szenarien, bevor Sie sich darauf verlassen. Beim Onboarding sollten Sie sicherstellen, dass die Person nur die genehmigten Zugriffe erhält und ihre Aufgabe in der vorgesehenen Umgebung erledigen kann. Ändert sich die Zuständigkeit, prüfen Sie, ob die bisherigen Berechtigungen überprüft wurden und die neuen begründet sowie befristet sind.
Beim Offboarding deaktivieren Sie das Konto und entziehen die Berechtigungen in jedem System des Inventars, einschließlich Repositories, Cloud, Datenbanken, Observability, Pipelines und verbundenen Diensten. Falls Zugangsdaten möglicherweise weitergegeben wurden oder sich nicht benutzerbezogen widerrufen lassen, rotieren Sie sie und prüfen Sie die zugehörigen Verwendungen. Prüfen Sie gegebenenfalls auch aktive Sitzungen, persönliche Tokens und API-Schlüssel.
Vergewissern Sie sich schließlich, dass der Widerruf keinen Betriebsprozess ohne Verantwortliche zurücklässt: Geplante Aufgaben, Dienstkonten, Integrationen oder Pipelines können von einer externen Identität abhängen. Das Konto einer Person sollte nicht der einzige Eigentümer notwendiger Automatisierungen sein. Weisen Sie diese Ressourcen geeigneten Identitäten und internen Verantwortlichen zu und prüfen Sie, ob sie nach dem Entzug des persönlichen Zugriffs weiterhin funktionieren.
Wiederverwendbare Checkliste
- Sind die Aufgabe und die benötigten Systeme konkret beschrieben?
- Sind die Berechtigungen für Entwicklung, Tests, Observability und Deployment getrennt?
- Verwendet jeder Zugriff eine individuelle Identität und die geringstmögliche Berechtigungsstufe?
- Sind die Zugangsdaten nach Umgebung getrennt und aus dem Quellcode herausgehalten?
- Gibt es eine interne genehmigende Person, einen Eintrag und ein Prüf- oder Ablaufdatum?
- Sind Umfang, Genehmigung und Überprüfung für Ausnahmen beim Produktionszugriff festgelegt?
- Berücksichtigt das Offboarding alle Systeme und die Rotation gemeinsam genutzter Zugangsdaten?
- Haben Automatisierungen und Dienste nach dem Entzug weiterhin eine verantwortliche Stelle?
Dieser Ansatz beseitigt nicht alle Risiken und ersetzt keine Sicherheitskontrollen der Anwendung. Er macht externe Zugriffe überprüfbar und anpassbar: Sie werden für einen konkreten Bedarf gewährt, bei Änderungen dieses Bedarfs überprüft und nach dessen Ende koordiniert entzogen.
