Automatisierung und persönliche Administration trennen
Eine Reporting-API-Pipeline muss ein genehmigtes Artefakt auswählen und eine kontrollierte Release-Aktion aufrufen. Das erfordert nicht automatisch das Erstellen von Benutzern, das Ändern der Abrechnung oder das Lesen jedes Anwendungssecrets. Beginnen Sie mit einem Berechtigungsinventar und einer geschützten Testumgebung; halten Sie Credentials aus Dokumenten, Repositories und Beispiellogs heraus.
Der menschliche Wiederherstellungszugriff sollte separat bleiben, damit das Widerrufen eines Deployment-Credentials nicht den einzigen Untersuchungspfad entfernt. Identifizieren Sie einen autorisierten Maintainer und eine unabhängige Host-Verifizierung. Ein zweiter uneingeschränkter Schlüssel ist ein weiteres Credential, keine engere Rolle.
Die erlaubte Operation präzise beschreiben
| Fähigkeit | Benötigt? | Grenze |
|---|---|---|
| Genehmigtes Artefakt lesen | Ja | Spezifisches Repository/Version |
| Release-Aktion aufrufen | Ja | Feste App und Umgebung |
| Jedes Laufzeitsecret lesen | Vermeiden | Kontrollierte Laufzeitidentität |
| Benutzer oder SSH-Richtlinie ändern | Nein | Separate Administration |
| Workflow-Konfiguration ändern | Nein für Laufzeitidentität | Geschützte Repository-Überprüfung |
| Backups löschen | Nein | Separate Wiederherstellungsberechtigungen |
Validieren Sie die Eingaben der Release-Aktion. Ein eingeschränkter Befehl, der beliebigen Text in eine privilegierte Shell einfügt, erlaubt weiterhin unbeabsichtigte Arbeit. Überprüfen Sie Wrapper-Verhalten, beschreibbare Pfade und Artefaktvertrauen gemeinsam. Breite sudo-Rechte oder Zugriff auf den Docker-Socket können die beabsichtigte Grenze umgehen.
Workflow-Änderungen als Credential-Zugriff behandeln
Wer vertrauenswürdige Workflow-Schritte ändern kann, könnte seine Anmeldeinformationen verwenden oder offenlegen. Überprüfen Sie Repository-Berechtigungen, geschützte Deployment-Umgebungen und welche Ereignisse privilegierte Jobs ausführen. Halten Sie Produktions-Anmeldeinformationen von nicht vertrauenswürdigem Pull-Request-Code fern. Geben Sie einem Workflow-Token nur die Berechtigungen, die sein Job benötigt.
GitHub empfiehlt die Fixierung auf vollständige Commit-SHA für die Auswahl unveränderlicher Actions. Überprüfen Sie die ausgewählte Action und spätere Updates; ein Versions-Tag kann sich verschieben. Vermeiden Sie das direkte Einfügen nicht vertrauenswürdiger Ereignisdaten in Inline-Shell-Code. Das Maskieren bekannter Geheimwerte ist keine Garantie gegen Offenlegung durch Transformationen, Logs oder Artefakte.
Technische Referenz: Sichere Nutzung von GitHub Actions.
Kurze Lebensdauer verwenden, wenn das Ziel dies unterstützt
OpenID Connect kann es einem unterstützten Ziel ermöglichen, die Workflow-Identität gegen eine kurzlebige Anmeldeinformation einzutauschen. Konfigurieren Sie Vertrauensprüfungen für das vorgesehene Repository, den Branch oder die Umgebung und die Audience. Dies ist weder ein universeller SSH-Ersatz noch eine Funktion, die vom aktuellen PrivacyNodes-Frontend bereitgestellt wird.
Wenn Ihr Deployment SSH verwendet, überprüfen Sie die autorisierten Schlüsseloptionen des installierten Pakets. Ein forced command allein verbietet kein Forwarding; Einschränkungen müssen die vorgesehenen Zugriffspfade abdecken und dennoch eine sichere Release-Operation aufrufen. Testen Sie in einer separaten Umgebung. Bewahren Sie funktionierenden Administrations- und Wiederherstellungszugriff beim Ändern der Authentifizierung und überprüfen Sie eine neue unabhängige Verbindung, bevor Sie die alte Methode entfernen.
Technische Referenz: GitHub Actions OpenID Connect · OpenSSH authorized_keys-Format.
Erlaubte und verbotene Arbeit testen
Überprüfen Sie, dass die Identität das vorgesehene Artefakt auswählen, das Release aufrufen und ein nützliches Ergebnis erhalten kann. Testen Sie dann ihre Grenzen: Geheimnisse einer anderen Anwendung, unzusammenhängende Dateiänderungen und willkürliche Administration sollten nicht verfügbar sein. Fügen Sie Artefaktpfade und Argumente hinzu, die der Wrapper ablehnen muss.
Erfassen Sie Identität, Geltungsbereich, Ablaufdatum falls zutreffend, genehmigenden Maintainer und Aufbewahrungsort der Audit-Nachweise. Behalten Sie Speicherverweise statt Anmeldeinformationswerte. Wenn ein Test nur nach Gewährung umfassender Administration funktioniert, überdenken Sie die Release-Aufgabe, anstatt sie stillschweigend zur dauerhaften Rolle zu machen.
Widerruf und einen Release mit defekter Pipeline proben
Bereiten Sie einen Ersatz mit dem überprüften Geltungsbereich vor, verifizieren Sie ein Test-Deployment, wechseln Sie die Pipeline und widerrufen Sie die alte Identität. Bestätigen Sie, dass die ersetzte Anmeldeinformation fehlschlägt und kein Duplikat in einem anderen Workflow verbleibt. Das alleinige Hinzufügen eines neuen Schlüssels entfernt früheren Zugriff nicht.
Dokumentieren Sie, wie ein autorisierter Maintainer das Deployment anhält und wiederherstellt, wenn CI nicht verfügbar ist. Verlinken Sie dieses Verfahren mit dem Release-Eintrag und Wiederherstellungsinventar. Eine eng gefasste Anmeldeinformation begrenzt die beabsichtigte Autorität; sie macht ein bösartiges Artefakt nicht harmlos.
Offizielle Referenzen
Die Dokumentation wurde für diesen Artikel überprüft. Beispiele sind Planungsübungen, keine auf einem PrivacyNodes-Server getesteten Befehle. Prüfen Sie die Dokumentation für Ihre installierte Version.