In diesem Dokument wird beschrieben, wie Sie Ihre vertraulichen Informationen mit dem integrierten Secret-Scanning in Secure Source Manager schützen können.
Das Scannen nach Secrets in Secure Source Manager verbessert die Sicherheit Ihrer Codebasis. Es analysiert Commits, die in Ihre Repositories übertragen oder über Pull-Anfragen zusammengeführt wurden, und sucht aktiv nach vertraulichen Informationen, die Sie verschlüsseln oder entfernen sollten. Wenn solche Daten erkannt werden, lehnt das Secret-Scanning den Push automatisch ab oder blockiert die Zusammenführung der Pull-Anfrage, um zu verhindern, dass vertrauliche Details versehentlich zusammengeführt werden.
Beim Secret-Scanning in Secure Source Manager werden die folgenden Informationskategorien als vertraulich behandelt:
- Verschlüsselungsschlüssel: Dazu gehören Elemente wie private SSH-Schlüssel.
- AWS-Anmeldedaten: Zugriffsschlüssel und geheime Schlüssel für Amazon Web Services.
- Google Cloud -Anmeldedaten: Dienstkontoschlüssel und andere Google Cloud -Secrets.
- OAuth-Clientschlüssel: Secrets, die für die Anwendungsauthentifizierung mit OAuth verwendet werden.
- Geheime Schlüssel: Sensible Schlüssel, die für die Authentifizierung oder Autorisierung verwendet werden.
Scannen auf Secrets aktivieren
Achten Sie darauf, dass die folgenden Rollen und Einstellungen für Ihr Repository aktiviert sind.
Erforderliche Rollen
Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Secure Source Manager Repository Admin (roles/securesourcemanager.repoAdmin) für das Secure Source Manager-Repository zuzuweisen, um die Berechtigung zu erhalten, die Sie zum Aktivieren des Scannens von Secrets benötigen.
Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.
Diese vordefinierte Rolle enthält die Berechtigung securesourcemanager.repositories.update, die zum Aktivieren des Secret-Scannings erforderlich ist.
Sie können diese Berechtigung auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.
Informationen zum Zuweisen von Secure Source Manager-Rollen finden Sie unter Zugriffssteuerung mit IAM und Nutzern Instanzzugriff gewähren.
Dienstkontoberechtigungen
Wenn Sie das Secret-Scanning so konfigurieren, dass eine benutzerdefinierte Inspektionsvorlage für Sensitive Data Protection verwendet wird, muss das von Secure Source Manager verwendete Dienstkonto die Berechtigung zum Lesen der Vorlage haben (z. B. die Rolle „DLP Reader“, roles/dlp.reader).
- Wenn für das Repository ein Repository-spezifisches Dienstkonto konfiguriert ist, verwendet Secure Source Manager ausschließlich dieses Dienstkonto. Sie müssen dem Dienstkonto pro Repository die Leseberechtigung für die Vorlage gewähren.
- Wenn kein Dienstkonto pro Repository konfiguriert ist, verwendet Secure Source Manager das Dienstkonto der Instanz.
Repository-Einstellungen aktualisieren
Sie können das Scannen nach Secrets für Ihre Repositories über die Secure Source Manager-Oberfläche aktivieren:
- Rufen Sie das Repository auf, in dem Sie das Scannen nach Secrets aktivieren möchten.
- Klicken Sie auf Settings (Einstellungen).
- Suchen Sie den Schalter Secret-Scans.
- Klicken Sie auf den Ein/Aus-Button, um die Position Ein festzulegen.
- Optional: Geben Sie im Feld Inspektionsvorlage den Ressourcennamen Ihrer Sensitive Data Protection Inspektionsvorlage ein.
- Klicken Sie auf Update Settings (Einstellungen aktualisieren).
Mit Secret-Scans arbeiten
Sobald das Secret-Scanning aktiviert ist, werden Commits in Ihrem Repository aktiv überwacht. Wenn vertrauliche Informationen in einem Commit identifiziert werden, der mit Git übertragen oder über eine Pull-Anfrage in der Weboberfläche zusammengeführt wurde, wird der Commit abgelehnt oder die Zusammenführung blockiert.
Wenn Sie Daten über die Befehlszeile übertragen, erhalten Sie eine Fehlermeldung, die auf das Vorhandensein sensibler Daten hinweist. An dieser Stelle haben Sie zwei Möglichkeiten:
Änderung rückgängig machen
Wenn Sie die vertraulichen Informationen entfernen möchten, können Sie den problematischen Commit mit dem folgenden Befehl rückgängig machen:
git reset --soft COMMIT_ID
Ersetzen Sie COMMIT_ID durch die tatsächliche Commit-ID.
Da Git den Verlauf aller Commits beibehält, können vertrauliche Daten weiterhin aus früheren Commits wiederhergestellt werden. Verwenden Sie den Befehl git reset --soft, um dies zu vermeiden. Korrigieren Sie dann die Dateien und führen Sie sie noch einmal aus, um die Daten aus dem aktuellen Verlauf des Zweigs zu entfernen.
Commit mit Force-Push übertragen (Secret-Scanning umgehen)
In bestimmten Situationen, in denen die erkannten Informationen als akzeptabel eingestuft werden, können Nutzer mit den entsprechenden Berechtigungen die Secret-Scanning-Prüfung umgehen und den Commit erzwingen.
git push -o dlpskip=true origin \
BRANCH_NAME
Ersetzen Sie BRANCH_NAME durch den Namen des Zweigs, den Sie zusammenführen.