Spickzettel: 10 Best Practices für Bitbucket-Sicherheit

In diesem Spickzettel erfahren Sie, wie Sie Bitbucket sicherer nutzen und dazu beitragen können. Einiges ist speziell auf Bitbucket zugeschnitten, vieles ist jedoch auch für andere Git- und Nicht-Git-Repositories nützlich.

Spickzettel herunterladen

Starten wir also mit unserer Liste der 10 Best Practices für Bitbucket-Sicherheit – beginnend mit dem klassischen Fehler, Passwörter in Bitbucket-Repositories abzulegen!

1. Speichern Sie niemals Zugangsdaten als Code oder Konfiguration in Bitbucket

Es gibt viele großartige Tools wie git-secrets, die Ihre Commits mithilfe eines Git-Pre-Commit-Hooks statisch analysieren können, um sicherzustellen, dass Sie keine Passwörter oder vertraulichen Informationen in Ihr Bitbucket-Repository übertragen. Commits werden abgelehnt, wenn das Tool einem der konfigurierten regulären Ausdrucksmuster entspricht, die darauf hindeuten, dass vertrauliche Informationen unsachgemäß gespeichert wurden. Das kann Pushes ein wenig verlangsamen, lohnt sich aber allemal.

Teamweite Regeln, die verhindern, dass Zugangsdaten als Code gespeichert werden, sind eine hervorragende Möglichkeit, Fehlverhalten im bestehenden Entwickler-Workflow zu unterbinden. Verwenden Sie ein Tool wie Vault, um Ihre Secrets in der Produktion zu verwalten. Ziehen Sie außerdem eine Toolchain für Identitäts- und Benutzermanagement in Betracht, etwa Keycloak (das derzeit von mehreren Entwicklerinnen und Entwicklern bei Red Hat gepflegt wird) oder andere Lösungen.

Atlassian unterstützt das Einfügen von Zugangsdaten in Bitbucket-Pläne über Umgebungsvariablen. Ein sichererer Ansatz könnte jedoch darin bestehen, Adaptavists ScriptRunner als Middleware zu verwenden, um Systeme für die Verwaltung von Zugangsdaten und Authentifizierung wie Vault und Keycloak zu verbinden.

Es gibt viele Möglichkeiten, Zugangsdaten gar nicht erst in Ihr Repository gelangen zu lassen. Sie sollten so viele davon wie möglich umsetzen. Dennoch besteht immer die Gefahr, dass vertrauliche Informationen hineingeraten. Prüfen Sie Ihre Repositories daher regelmäßig mit Tools wie GitRob oder truffleHog, die Ihre Codebasis durchsuchen und mithilfe von Musterabgleichen nach vertraulichen Informationen suchen.

2. Entfernen Sie vertrauliche Daten aus Dateien und dem Bitbucket-Verlauf

Wenn Sie vertrauliche Daten in Ihrem Bitbucket-Repository finden, müssen Sie mehrere Schritte unternehmen. Zunächst müssen Sie die Tokens und Passwörter, die öffentlich zugänglich waren, ungültig machen. Sobald ein Secret im Internet öffentlich ist, sollten Sie davon ausgehen, dass Angreifer darauf Zugriff haben, und entsprechend reagieren.

Natürlich müssen Sie dieselben vertraulichen Daten auch aus Ihrem Repository entfernen. Vergessen Sie dabei aber nicht, dass Bitbucket eine vollständige Historie all Ihrer Commits führt. Dazu gehören Änderungsprotokolle, in denen Ihre vertraulichen Informationen aufgeführt sein können. Wenn Sie vertrauliche Daten aus einem Repository entfernen, müssen Sie auch den Bitbucket-Verlauf bereinigen. Weitere Informationen finden Sie unter Dateien aus dem Verlauf Ihres Repositorys entfernen. Der Link führt zwar zu GitHub, die Hinweise gelten jedoch allgemein für alle Git-Repositories und lassen sich daher auch in Bitbucket anwenden. Mit ScriptRunner können Sie solche Integrationen ebenfalls ganz einfach umsetzen.

3. Kontrollieren Sie den Zugriff streng

Hier im Vereinigten Königreich öffnen wir Britinnen und Briten bei großer Hitze (sprich: mildem Wetter) gern alle Fenster im Haus, damit es nicht zur Sauna wird. Wenn wir das Haus verlassen, schließen wir die Haustür jedoch doppelt ab – und lassen oft viele Fenster einen Spalt offen, damit die Luft zirkulieren kann. Das ergibt natürlich keinen Sinn: Wer einbrechen möchte, versucht es schließlich nicht durch die Haustür! Stattdessen sucht man nach einem weniger offensichtlichen Weg, vielleicht durch eines der praktischerweise geöffneten Fenster. Bei der Absicherung unserer Anwendungen gehen wir oft ähnlich vor. Wir konzentrieren uns sehr stark auf komplexe Angriffsvektoren, scheitern aber bei einigen der einfachsten. Ein Angreifer braucht beispielsweise nur einen Entwickler, der sein Passwort auf einem Haftnotizzettel am Monitor hinterlässt. Wir müssen sicherstellen, dass grundlegende Einstellungen und Verfahren eingehalten werden – sowohl auf der Bitbucket-Plattform als auch allgemein. Schreiben Sie Ihren Mitwirkenden die folgenden grundlegenden Maßnahmen vor:

1. Verlangen Sie eine Zwei-Faktor-Authentifizierung für das Bitbucket-Konto aller Mitwirkenden.

2. Lassen Sie Bitbucket-Benutzer niemals Konten oder Passwörter gemeinsam nutzen.

3. Alle Laptops und Geräte mit Zugriff auf Ihren Quellcode müssen angemessen abgesichert sein.

4. Repository-Administratoren sollten den Teamzugriff auf Daten verwalten. Gewähren Sie Mitwirkenden nur Zugriff auf die Daten, die sie für ihre Arbeit benötigen.

5. Bitbucket-Konten können persönliche Konten sein und verschwinden nicht automatisch, wenn Benutzer das Unternehmen verlassen. Entziehen Sie Bitbucket-Benutzern, die nicht mehr für Sie tätig sind, unbedingt den Zugriff.

Mit dem Branch-Permissions-Modell von Bitbucket können Sie festlegen, wer Commits in welche Branches übertragen darf.

Sie können einen ScriptRunner-Job so planen, dass bestimmte Bitbucket-Benutzer zu einem festgelegten Datum und Zeitpunkt deaktiviert werden und keinen weiteren Zugriff auf Bitbucket Server haben. Im folgenden Beispiel deaktivieren wir die Benutzer „User“ und „Contractor“ am 17. August 2018 um 9 Uhr. Im Abschnitt „Notes“ wird der JIRA-Vorgangsschlüssel ACCESS-1234 angegeben, damit nachvollziehbar ist, wer die Änderung gemeldet hat.

4. Fügen Sie eine SECURITY.md-Datei hinzu

Für die meisten Projektinhaber und Maintainer ist es selbstverständlich, ihrem Repository eine README.md-Datei hinzuzufügen. Heutzutage wird sie sogar erwartet; fehlt sie, wird das oft kritisch gesehen. Ebenso wird es immer üblicher, eine SECURITY.md-Datei mit sicherheitsrelevanten Informationen zum Projekt bereitzustellen. Sie enthält nicht nur wichtige Sicherheitshinweise für die Benutzer Ihres Open-Source-Projekts, sondern regt auch die Maintainer dazu an, über den Umgang mit Sicherheitsmeldungen und Updates sowie über allgemeine Sicherheitspraktiken nachzudenken.

Hier finden Sie einen Überblick über einige Themen, die Sie in Ihrer SECURITY.md-Datei behandeln sollten:

Richtlinie zur Offenlegung von Sicherheitslücken

Der Bericht 2017 Snyk State of Open Source Security zeigt: Nur 21 % der Maintainer, die keine öffentliche Richtlinie zur Offenlegung von Sicherheitslücken haben, wurden privat über eine Schwachstelle informiert. Bei den Maintainer, die eine solche Richtlinie haben, sind es dagegen 73 %. Das zeigt, wie wichtig es ist, ein Verfahren festzulegen, über das Personen, die ein Problem melden, Sicherheitslücken verantwortungsvoll offenlegen können. Dazu sollte auch gehören, wer auf welchem Weg zu kontaktieren ist. Das ist äußerst wichtig, denn so erhalten Sie wertvolles Feedback von den Nutzern Ihres Projekts. Wenn es keinen einfachen, klar definierten Weg gibt, verzichten wir leicht ganz darauf, etwas zu melden. Andere veröffentlichen die Schwachstelle möglicherweise als offenes Issue und machen die Welt so unbeabsichtigt darauf aufmerksam, bevor eine Korrektur verfügbar ist. Geben Sie den Nutzern Ihres Projekts alle nötigen Hinweise, damit sie den Maintainer bei Problemen die richtigen Informationen bereitstellen können.

Richtlinie für Sicherheitsupdates

Jeden Tag werden Software-Schwachstellen entdeckt. Wird eine Schwachstelle in Ihrer Anwendung oder Bibliothek gefunden, sind Sie verpflichtet, die Benutzer Ihres Projekts zu informieren. Sie könnten Ihren Open-Source-Code in der Produktion auf kritischen Systemen einsetzen. Sie benötigen ein klar definiertes Verfahren, um ihnen die relevanten Informationen mitzuteilen – darunter den Schweregrad der Schwachstelle, das damit verbundene Risiko und die Möglichkeit, auf eine korrigierte Version Ihres Codes umzusteigen. Legen Sie dieses Verfahren im Voraus fest, damit die Informationen Ihre Projektbenutzer erreichen und sie so früh wie möglich über neu entdeckte und behobene Sicherheitslücken informiert werden. Dafür kann eine Sicherheits-Mailingliste genügen. Eine SECURITY.md-Datei ist ein geeigneter Ort für solche Informationen im Repository. Wenn Sie eine Website haben, empfiehlt sich eine eigene Seite – ein Beispiel ist die Sicherheitsseite von Express.js.

Sicherheitsrelevante Konfiguration

Die Sicherheitsaspekte Ihres Projekts gehen über den Code hinaus. Benutzer Ihres Open-Source-Projekts müssen wahrscheinlich Konfigurationen hinzufügen und Einstellungen vornehmen, damit es in ihrer Umgebung wie vorgesehen funktioniert. Empfehlen Sie Einstellungen, mit denen die Benutzer beim Deployment die Sicherheitslage ihres Projekts verbessern können. Dazu gehören etwa HTTPS zu aktivieren, eine Autorisierungsebene hinzuzufügen und natürlich Standardpasswörter zu ersetzen – ein Ratschlag, den sich viele MongoDB-Benutzer gewünscht hätten. Bedenken Sie, dass viele Benutzer nur über geringe Sicherheitskenntnisse verfügen. Jeder Hinweis, den Sie weitergeben, kann ihnen sehr helfen.

Bekannte Sicherheitslücken und geplante Verbesserungen

Es gilt abzuwägen, ob Sie Ihren Benutzern die nötigen Informationen zur Absicherung ihrer Umgebung geben oder Angreifern dadurch mögliche Angriffswege aufzeigen. Überlegen Sie stets, wie beide Seiten die Informationen nutzen könnten. Nur selten sind Projekte bereits so weit entwickelt, dass alle gewünschten Sicherheitsverbesserungen umgesetzt wurden. Informieren Sie Ihre Projektbenutzer unbedingt über die Sicherheitsmaßnahmen, die noch fehlen. Sie sollten die vollständigen Informationen kennen, um fundierte Entscheidungen zur Nutzung Ihres Projekts treffen zu können. Vielleicht tragen sie sogar eine Implementierung der Sicherheitsmaßnahmen bei, die auf der Liste stehen!

5. Integrieren Sie Sicherheitstipps mit Code Insights in Ihren Workflow

Code Insights macht Informationen sichtbar, die für einen Pull Request relevant sind. So können Verfasser und Reviewer fundiertere Entscheidungen treffen. Snyk bietet eine Integration, die alle geöffneten Pull Requests scannt, um sicherzustellen, dass keine neuen Open-Source-Schwachstellen eingeführt werden. Enthalten Pull Requests solche Schwachstellen, kann die Integration verhindern, dass sie zusammengeführt werden.

Wird eine neue Schwachstelle gefunden, benachrichtigt Snyk Sie darüber und erstellt einen Fix-Pull-Request mit Upgrade-Vorschlägen oder Snyk-Patches zur Behebung der Schwachstelle.

In der Bitbucket-Pull-Request-Oberfläche werden die Änderungen gescannt und die Ergebnisse als detaillierte Inline-Anmerkungen neben den Änderungen angezeigt, durch die neue Probleme entstehen. So lassen sich die Ergebnisse des Snyk-Scans leichter nachvollziehen und fundierte Entscheidungen treffen.

Weitere Informationen zur Installation und Nutzung finden Sie in diesem Snyk-Blogbeitrag zu Bitbucket Code Insights – inklusive Video, das den gesamten Ablauf zeigt!

6. Prüfen Sie Ihre Bitbucket-Anwendungen sorgfältig

Alle guten Plattformen lassen sich erweitern, und Bitbucket bildet mit seinem App-Marktplatz keine Ausnahme. Anwendungen werden von Organisationen und Drittentwicklern erstellt. Behalten Sie das im Hinterkopf, wenn Sie sie zu Ihrem Repository hinzufügen. Beachten Sie bei der Auswahl und Installation von Bitbucket-Anwendungen Folgendes:

• Gewähren Sie Anwendungen nicht mehr Zugriffsrechte als nötig.

• Hinterfragen Sie, warum eine Anwendung die angeforderten Zugriffsrechte benötigt, und überlegen Sie, welchen Schaden sie mit diesen Rechten anrichten könnte.

• Vergewissern Sie sich, dass der Autor oder die Organisation hinter der Anwendung vertrauenswürdig und glaubwürdig ist, bevor Sie Zugriff auf Ihre Repositories gewähren. Gehen Sie dabei genauso vor wie bei der Aufnahme eines neuen Committers in Ihr Projekt.

Ihre Sicherheit ist nur so stark wie Ihr schwächstes Glied. Hat eine Anwendung, der Sie Zugriff gewähren, eine schlechte Sicherheitslage, kann ein Angriff auf ihren Code Angreifern Zugang zu Ihrem Code verschaffen – einem Ihrer sensibelsten Werte.

Überwachen und überprüfen Sie Ihre Anwendungen und deren Mitwirkende regelmäßig, um sicherzustellen, dass Sie sie noch benötigen und ihnen weiterhin vertrauen – und dass die benötigten Zugriffsrechte nach wie vor angemessen sind. Behalten Sie Ihr Anwendungsmanagement im Blick und entfernen Sie Anwendungen, die Sie nicht mehr benötigen oder deren Zugriffsrechte Ihnen zu weit gehen.

7. Integrieren Sie Sicherheitstests in Pull Requests

Bitbucket verfügt über ein leistungsstarkes, ereignisgesteuertes Git-Hook-Framework, mit dem Sie bei bestimmten Ereignissen HTTP-POST-Anfragen an einen Dienst Ihrer Wahl senden können. Sie können auf eine Vielzahl von Ereignissen reagieren. Für das Testen inkrementeller Codeänderungen ist das Ereignis pull_request besonders nützlich. Viele Tools zur statischen Codeanalyse unterstützen Git Hooks: Wird ein PR erstellt, löst ein HTTP-POST-Aufruf einen Test Ihrer neuesten Änderungen aus. So können Sie sicherstellen, dass Code- und Konfigurationsänderungen Ihren Sicherheitsanforderungen entsprechen.

Snyk analysiert beispielsweise Ihr Repository statisch, um anfällige Abhängigkeiten zu finden, die Sie möglicherweise verwenden, und hilft Ihnen, diese zu beheben. Sie können Ihre Repositories über die Snyk-Benutzeroberfläche auf Probleme prüfen. Außerdem können Sie verhindern, dass Entwickler neue anfällige Bibliotheken hinzufügen, indem Sie Pull Requests testen und den Test fehlschlagen lassen, wenn eine neue Sicherheitslücke eingeführt wurde.

Neben der praktischen Integration in Bitbucket haben Pull Requests gegenüber einem „Build-Abbruch“ den Vorteil, dass sie einen Merge nicht blockieren müssen (standardmäßig dienen sie lediglich der Information). Außerdem können sie Ihre Änderungen testen und nicht nur das Ergebnis – etwa indem der Test nur fehlschlägt, wenn Sie eine anfällige Bibliothek hinzugefügt haben, nicht aber, wenn diese bereits vorhanden war.

Zusätzlich zu Snyk sollten Sie auch SonarCloud oder CodeClimate für automatisierte Sicherheitsprüfungen des Codes in Betracht ziehen. Erwägen Sie außerdem, ein ScriptRunner-Skript hinzuzufügen, damit keine Geheimnisse in Ihr Repository gelangen.

8. Sicherheitstests in Ihre Bitbucket-Pipes integrieren

Mit Bitbucket Pipes können Sie einen CI/CD-Workflow anhand einer Auswahl sofort einsatzbereiter Aufgaben anpassen und automatisieren. Snyk bietet eine sofort einsatzbereite Pipe, die im Rahmen des CI/CD-Workflows Ihre Anwendungsabhängigkeiten und Docker-Images auf bekannte Sicherheitslücken in Open-Source-Komponenten scannt.

Um die Snyk-Pipe in Ihren Workflow aufzunehmen, kopieren Sie sie einfach und fügen Sie sie in die Pipeline ein.

Nach der Integration in den Bitbucket-Pipeline-Workflow scannt die Snyk-Pipe Ihre Abhängigkeiten im Rahmen des CI/CD-Workflows auf Sicherheitslücken in Open-Source-Komponenten. Werden Sicherheitslücken gefunden, steuert die Snyk-Pipe den Prozess entsprechend Ihrer Voreinstellungen. So können Sie beispielsweise verhindern, dass Sicherheitslücken mit hohem Schweregrad den Build durchlaufen. Weitere Informationen finden Sie auf den Dokumentationsseiten.

Eine weitere Pipe, die Sie zur Verbesserung Ihrer Sicherheitsresilienz in Ihre Pipeline integrieren sollten, ist SonarCloud.

9. Das passende Bitbucket-Angebot für Ihre Sicherheitsanforderungen wählen

Je nach Projekt oder den Vorschriften Ihrer Organisation dürfen Sie möglicherweise nur Software verwenden, die lokal ausgeführt werden kann. Oder es gelten Einschränkungen dazu, wo Ihr Quellcode gespeichert wird oder welche anderen Organisationen darauf zugreifen können. Solche Einschränkungen sind bei Finanzinstituten, Behörden und anderen stark regulierten Branchen üblich. Das bedeutet jedoch nicht, dass Sie auf Bitbucket verzichten müssen!

Sehen Sie sich das vollständig on-premises verfügbare Bitbucket-Server-Angebot an. Damit können Sie Bitbucket-Repositories vollständig innerhalb Ihrer Organisation hosten. So können Sie die Verbindung zum Internet trennen und trotzdem intern auf Ihre Projekte in den Bitbucket-Server-Repositories zugreifen.

10. SSH-Schlüssel und persönliche Zugriffstokens regelmäßig wechseln

Der Zugriff auf Bitbucket erfolgt üblicherweise über SSH-Schlüssel oder persönliche Zugriffstokens (anstelle eines Passworts, da Sie die Zwei-Faktor-Authentifizierung aktiviert haben!). Doch was passiert, wenn diese Tokens gestohlen werden, ohne dass Sie es bemerken? Erneuern Sie Ihre Schlüssel und Tokens regelmäßig, um mögliche Schäden durch offengelegte Schlüssel zu begrenzen.

Weitere Informationen zur Bitbucket-Sicherheit finden Sie in den Bitbucket-Sicherheitswarnungen. Und falls Sie es noch nicht getan haben: Laden Sie jetzt diesen Spickzettel herunter und hängen Sie ihn gut sichtbar auf, damit Sie auch künftig sichere Entscheidungen treffen!