Richtlinien für Mitglieder (Gruppen-/Projektzugriff)¶

Diese Richtlinien gelten für alle Mitgliedschaften in dieser Gruppe bzw. in diesem Projekt. Sie richten sich an Personen, die Teammitglieder verwalten (können). Ziel ist ein sicherer, nachvollziehbarer und wartbarer Betrieb mit klaren Verantwortlichkeiten.

1. Grundprinzipien¶

1.1 Least Privilege¶

Vergib immer nur die minimal notwendigen Rechte – zeitlich und sachlich begrenzt.

1.2 Nachvollziehbarkeit vor Bequemlichkeit¶

Jede Rechtevergabe muss begründbar und auditierbar sein: - Wer? - Warum? - Wie lange? - Welche Rechte?

1.3 Trennung von Rollen¶

Menschen erhalten personenbezogene Accounts.
Automatisierung nutzt Service Accounts / Deploy Tokens / CI/CD-Variablen – niemals private Benutzerkonten.

2. Rollenmodell und Berechtigungsstufen (GitLab)¶

Verwende die niedrigste Rolle, die den Zweck erfüllt.

Guest: Sichtbarkeit/Einblicke, keine Änderungen
Reporter: Lesen + Issues/MRs/Build-Infos (je nach Projekt)
Developer: Entwickeln (Merges abhängig von Regeln)
Maintainer: Projekt-/Gruppenverwaltung, Schutzregeln, CI/CD, Mitglieder
Owner (nur Gruppe): vollständige Gruppenverwaltung

2.1 Standard-Zuordnung (Empfehlung)¶

Standard-Mitwirkende: Developer
Review-/QA-Rollen: Reporter oder Developer (je nach Workflow)
Projektverantwortung: Maintainer (sparsam)
Externe / temporäre Mitarbeit: kleinste Rolle + Ablaufdatum

3. Mitgliedschaft anlegen: Checkliste¶

Beim Hinzufügen eines Mitglieds prüfe und dokumentiere:

Zweck der Mitgliedschaft (Projektauftrag / Aufgabe)
Scope: Gruppe oder einzelnes Projekt?
Rolle: minimal erforderlich
Dauer: Ablaufdatum setzen, wenn temporär
2FA/SSO: erforderlich und aktiv (sofern im System erzwungen)
Zugriffsweg: persönlicher Account (kein Shared Account)

3.1 Ablaufdatum (Expiry) ist Standard¶

Temporäre Zugriffe müssen ein Ablaufdatum haben: - Externe Unterstützung - Praktikant:innen / Werkstudierende - Review-/Audit-Zugriffe - Incident-Unterstützung

4. Mitgliedschaft beantragen: Mindestangaben¶

Anträge auf Mitgliedschaft müssen folgende Informationen enthalten:

Name / Benutzername
Organisation / Team
Konkreter Zweck (Issue, Epic, Projektphase)
Benötigte Aktionen (lesen, MRs erstellen, Mergen, Releases, CI ändern)
Benötigter Zeitraum (Start, Ende)
Begründung, warum niedrigere Rolle nicht reicht

Unvollständige Anträge werden zurückgestellt.

5. Gruppen- vs. Projektmitgliedschaft¶

5.1 Gruppe (bevorzugt für langfristige Mitarbeit)¶

Nutze Gruppenmitgliedschaft, wenn: - dauerhaft an mehreren Projekten gearbeitet wird - gemeinsame Standards/Policies gelten - Zugriff konsistent bleiben soll

5.2 Projekt (für punktuelle Aufgaben)¶

Nutze Projektmitgliedschaft, wenn: - nur ein Projekt betroffen ist - temporärer Zugriff benötigt wird - externe Beiträge erfolgen

6. Externe Mitwirkende¶

Externe erhalten grundsätzlich: - niedrigste sinnvolle Rolle - Ablaufdatum - Zugriff nur auf benötigte Projekte - keine Admin-/Owner-Rechte - keine Einsicht in Secrets/Variablen/Runner-Konfiguration

Optional (empfohlen): - Arbeit ausschließlich via Merge Request - eingeschränkte Branch-Rechte - separate Review-Regeln

7. Service Accounts, Bots und Automatisierung¶

7.1 Grundsatz¶

Automatisierung darf nicht über private Benutzerkonten laufen.

Nutze stattdessen (je nach Bedarf): - Project/Group Access Tokens - Deploy Tokens - CI_JOB_TOKEN (wo möglich) - Service Accounts (klar benannt)

7.2 Benennung¶

Service Accounts müssen eindeutig sein, z. B.: - svc-esw-ci - bot-release - svc-monitoring

7.3 Rechte¶

minimal erforderlich
keine Owner-Rechte
Tokens nur mit notwendigen Scopes
Rotation/Erneuerung dokumentieren

8. SSH Keys, Tokens und Secrets¶

8.1 SSH Keys¶

Nur persönliche SSH Keys in persönlichen Accounts
Keys müssen sicher erzeugt und gespeichert werden
Verlorene/kompromittierte Keys sofort entfernen

8.2 Tokens¶

Tokens sind wie Passwörter zu behandeln
Keine Tokens in Issues, MRs oder Logs posten
Rotation bei Rollenwechsel, Offboarding und Verdacht

8.3 CI/CD-Variablen¶

Secrets gehören ausschließlich in geschützte CI/CD Variablen
Variablen mit protected nur für protected branches/tags
Zugriff auf Variablenverwaltung nur für wenige Maintainer

9. Branch-Schutz und Merge-Regeln (Empfehlung)¶

9.1 Protected Branches¶

Standard: main/master und Release-Branches sind geschützt: - Direkt-Push verboten (oder streng limitiert) - Merge nur via MR - Optional: Signed commits / approvals

9.2 Merge Requests¶

Empfohlen: - mindestens 1 Review/Approval - CI muss erfolgreich sein - Squash/Conventional Commits (falls Projektstandard)

9.3 CODEOWNERS (wenn vorhanden)¶

Wenn CODEOWNERS verwendet wird: - betroffene Bereiche benötigen Approval der Owner - Änderungen an kritischen Dateien (CI, Security, Deploy) sind besonders zu prüfen

10. Runner, CI und Ressourcen¶

10.1 Runner-Nutzung¶

Runner sind gemeinsame Infrastruktur
Ressourcenintensive Jobs nur wenn notwendig
Vermeide Endlosschleifen und „sleep“-Jobs

10.2 CI-Änderungen¶

Änderungen an: - .gitlab-ci.yml - Runner-Tags - Deploy-Skripten - Secrets/Variablen gelten als kritisch und benötigen Review.

10.3 Artifact- und Log-Hygiene¶

Logs dürfen keine Secrets enthalten
Artifacts nur so lange wie nötig aufbewahren
Sensible Ausgaben maskieren und prüfen

11. Onboarding (Neue Mitglieder)¶

Neue Mitglieder sollen (mindestens) folgende Schritte durchlaufen:

Projekt-/Gruppenüberblick lesen (README, CONTRIBUTING, Governance)
Entwicklungs-/Workflow-Regeln verstehen (MR-Prozess, Branching, CI)
Security-Basics bestätigen:
2FA aktiv
keine Token/Secrets teilen
Zugriff testen (Clone, MR, Pipeline)
Zuständigkeiten/Ansprechpartner kennen

12. Offboarding (Austritt / Rollenwechsel)¶

Bei Austritt oder Rollenwechsel:

Mitgliedschaft entfernen oder Rolle reduzieren
Ablaufdaten prüfen (abgelaufene entfernen)
Tokens/Keys widerrufen (insb. Service-/Access Tokens)
Zugriffsrechte auf Runner/Deploy/Secrets prüfen
Offboarding im Issue/Log dokumentieren (wer, wann, was)

Offboarding ist Pflicht – kein „später irgendwann“.

13. Regelmäßige Zugriffsprüfungen¶

Mindestens quartalsweise (oder nach Bedarf) ist zu prüfen:

verwaiste Accounts
abgelaufene temporäre Zugriffe
unnötige Maintainer-Rechte
alte Tokens/Keys
externe Mitglieder ohne aktiven Bedarf

Empfehlung: - eine feste Person/Gruppe ist verantwortlich - Ergebnisse kurz dokumentieren (Issue/Checkliste)

14. Ausnahmeverfahren¶

Ausnahmen (z. B. kurzfristiger Maintainer-Zugriff) sind möglich, aber nur wenn:

Zweck klar beschrieben ist
Zeitraum begrenzt ist (Expiry)
Nachbearbeitung geplant ist (Rückbau)
Entscheidung dokumentiert ist

15. Meldung von Sicherheitsvorfällen¶

Wenn Du den Verdacht hast, dass Zugangsdaten kompromittiert sind:

sofort Tokens/Keys deaktivieren bzw. ändern
zuständige Maintainer/Administratoren informieren
keine Details in öffentlichen Issues posten
Vorfall dokumentieren (intern)

16. Kontakt und Zuständigkeiten¶

Bei Fragen zu Mitgliedschaften: - wende Dich an die Maintainer/Owner dieser Gruppe bzw. des Projekts - beschreibe Dein Anliegen mit Zweck, Scope und gewünschter Dauer

17. Changelog dieser Richtlinien¶

Änderungen an diesen Richtlinien: - erfolgen sparsam und nachvollziehbar - werden bei Bedarf in einem MR/Issue begründet - gelten gruppenweit, sofern nicht projektspezifisch abweichend geregelt