Datenpannen vermeiden? Setzen Sie auf Secrets-Erkennung

Als Softwareentwickler ist es unerlässlich, die Sicherheit Ihrer Anwendungen zu gewährleisten. Dazu gehört auch, Secrets zu verwalten und ein Tool zur Secrets-Erkennung einzusetzen. Als Secrets werden in diesem Zusammenhang sensible Daten wie API-Schlüssel, Datenbank-Zugangsdaten, Verschlüsselungsschlüssel und andere vertrauliche Informationen bezeichnet. Unbefugter Zugriff darauf oder ihre Offenlegung kann katastrophale Folgen haben, darunter Datenpannen und erhebliche geschäftliche Verluste.

Fest codierte Secrets kommen in der Entwicklung häufig vor. Sie bieten eine schnelle und einfache Möglichkeit, sich bei externen Diensten, Datenbanken oder anderen Komponenten zu authentifizieren, für die eine Zugriffskontrolle erforderlich ist. So ist es beispielsweise keine Seltenheit, dass API-Schlüssel oder Datenbank-Zugangsdaten direkt in Anwendungen fest codiert werden, insbesondere in frühen Entwicklungsphasen.

# Example of hardcoded database credentials
host = 'localhost'
database = 'my_database'
user = 'my_user'
password = 'my_password'

Dieser Ansatz mag Zeit sparen, birgt jedoch zahlreiche Sicherheitsrisiken, die sich durch Secrets-Erkennung leicht vermeiden lassen.

Was wäre, wenn Sie eine Datenpanne verhindern könnten, indem Sie Secrets frühzeitig während der Entwicklung erkennen? Hier sehen Sie einen Screenshot der Snyk-IntelliJ-IDE-Erweiterung, die die Verwendung fest codierter Secrets und weiterer Datenbank-Zugangsdaten in einer JavaScript-Anwendung erkennt:

Entwickler, DevOps-Teams und Sicherheitsexperten bemühen sich ständig darum, Secrets während ihres gesamten Lebenszyklus angemessen zu schützen, zu kontrollieren und zu überwachen. Da Anwendungsarchitekturen jedoch immer komplexer und stärker verteilt sind, wird eine sichere und effiziente Verwaltung von Secrets zu einer erheblichen Herausforderung.

Was sind Secrets in der Softwareentwicklung?

In der Softwareentwicklung bezeichnet der Begriff „Secrets“ sensible Daten, deren Offenlegung unbefugten Zugriff auf Systeme und Daten sowie deren missbräuchliche Nutzung ermöglichen kann. Dazu zählen unter anderem:

• Passwörter: Geheime Phrasen oder Zeichenfolgen, mit denen sich Benutzer authentifizieren, ihre Identität nachweisen oder Zugriff auf eine Ressource erhalten.

• API-Schlüssel: API-Schlüssel sind eindeutige Kennungen, mit denen sich ein Benutzer, Entwickler oder aufrufendes Programm bei einer API authentifiziert.

• Tokens: Ein Token ist ein vom Server erstellter Datensatz. Er kann Informationen zur Identifizierung eines Benutzers, zur Gültigkeit des Tokens und zum Ausstellungszeitpunkt enthalten. Ein bekanntes Beispiel sind JSON Web Tokens (JWT).

Häufige Fehler im Umgang mit Secrets

Beim Umgang mit Secrets machen Entwickler häufig bestimmte Fehler. Hier sind einige davon:

1. Secrets fest codieren: Entwickler codieren Secrets häufig fest in den Quellcode einer Anwendung. Das ist höchst unsicher, da jeder mit Zugriff auf die Codebasis diese Secrets potenziell abrufen kann.

2. Secrets unsachgemäß speichern: Secrets unverschlüsselt in Text-, Konfigurations- oder Datenbankdateien zu speichern, ist ein weiterer häufiger Fehler.

3. Secrets nicht ausreichend oft rotieren: Secrets regelmäßig zu ändern oder zu rotieren, ist eine bewährte Sicherheitsmaßnahme. Viele Entwickler versäumen dies jedoch und lassen dieselben Secrets über lange Zeiträume unverändert.

# An example of hardcoding secrets in Python
password = "mySuperSecretPassword"
api_key = "myAPIKey1234"

Die Folgen eines mangelhaften Secrets-Managements

Die Folgen eines mangelhaften Secrets-Managements sind weitreichend und gravierend. Das unterstreicht, wie wichtig es ist, während des Softwareentwicklungszyklus Mechanismen zur Secrets-Erkennung einzusetzen.

Datenpannen: Die unmittelbarste und gefährlichste Folge eines mangelhaften Secrets-Managements ist eine mögliche Datenpanne. Erlangt ein Angreifer Zugriff auf offengelegte Secrets, kann er leicht in Ihre Systeme eindringen, auf sensible Daten zugreifen und sogar die Kontrolle über Ihre Infrastruktur übernehmen. So kann er beispielsweise mit API-Schlüsseln Ihre Anwendung imitieren, mit Datenbank-Zugangsdaten Daten stehlen oder manipulieren oder mit Zertifikaten Ihre Verschlüsselung aushebeln. Datenpannen können zu erheblichen finanziellen Verlusten, Reputationsschäden und rechtlichen Konsequenzen führen.

Nichteinhaltung gesetzlicher Vorgaben: In einer Zeit, in der Datenschutz- und Sicherheitsvorschriften immer strenger werden, kann ein mangelhaftes Secrets-Management zur Nichteinhaltung gesetzlicher Vorgaben führen. Verstöße gegen Regelungen wie DSGVO, CCPA und HIPAA können hohe Bußgelder und rechtliche Sanktionen nach sich ziehen.

Verlust der Wettbewerbsfähigkeit: Secrets ermöglichen häufig den Zugriff auf proprietäre Algorithmen, Geschäftslogik und strategische Daten. Ihre Offenlegung kann zum Verlust von Wettbewerbsvorteilen und zum Diebstahl geistigen Eigentums führen.

Hier sehen Sie, wie einfach ein Secret in einem Git-Repository offengelegt werden kann:

# Initial commit with a secret
echo "SECRET = 'my_super_secret_key'" > config.py
git add config.py
git commit -m "Initial commit"

# Realize the mistake and remove the secret
echo "SECRET = 'REMOVED'" > config.py
git commit -am "Remove secret"

Obwohl das Secret im zweiten Commit entfernt wurde, ist es weiterhin im Repository-Verlauf enthalten und kann von allen Personen mit Zugriff darauf abgerufen werden.

Um diese Folgen zu vermeiden und die Sicherheitslage Ihrer Anwendungen zu verbessern, müssen Sie Lösungen zur Secrets-Erkennung und -Verwaltung einsetzen. Tools wie Snyk helfen Ihnen dabei, offengelegte Secrets früh im Entwicklungsprozess in Ihrer Codebasis zu erkennen, wenn Entwickler die Snyk-IDE-Erweiterung installieren, oder während der CI/CD-Pipeline, wenn Sie die Secrets-Erkennungsfunktionen von Snyk integrieren.

So funktioniert Secrets-Erkennung

Bei der Secrets-Erkennung werden vertrauliche Informationen oder „Secrets“ wie API-Schlüssel, Passwörter und Tokens identifiziert, die möglicherweise in Ihrer Codebasis offengelegt werden. Die Offenlegung oder missbräuchliche Verwendung dieser Secrets kann zu unbefugtem Zugriff oder Datenpannen führen.

Secrets-Erkennung ist entscheidend, um Datenpannen zu verhindern: Sie identifiziert und kennzeichnet potenziell offengelegte Secrets, bevor diese ausgenutzt werden können. Wird ein Secret beispielsweise versehentlich in ein öffentliches Repository übertragen, kann es erkannt und entfernt werden, bevor böswillige Akteure es entdecken. Für eine wirksame Secrets-Erkennung sind automatisierte Scan-Tools entscheidend, die Ihre Codebasis durchsuchen und potenzielle Secrets ausfindig machen und kennzeichnen. Eine Möglichkeit hierfür ist der Einsatz regulärer Ausdrücke (Regex) und bekannter Muster, um potenzielle Secrets zu erkennen.

Ein API-Schlüssel lässt sich beispielsweise anhand eines Musters wie diesem erkennen:

import re

# This is a very simplified example
API_KEY_REGEX = r'[A-Za-z0-9]{32}'

def detect_secrets(text):
    return re.findall(API_KEY_REGEX, text)

Das ist ein vereinfachtes Beispiel, doch das Prinzip ist dasselbe: Anhand bekannter Muster lassen sich potenzielle Secrets in Ihrem Code erkennen. In der Praxis nutzen Secrets-Erkennungstools wie Snyk wesentlich ausgefeiltere Techniken, um Secrets aufzuspüren.

Secrets-Erkennung in die CI/CD-Pipeline integrieren

Damit Sie die Vorteile der Secrets-Erkennung voll ausschöpfen können, sollte sie in Ihre Continuous-Integration-/Continuous-Deployment-Pipeline (CI/CD) integriert werden. So können Sie potenzielle Secrets bereits in der frühestmöglichen Phase des Entwicklungsprozesses erkennen.

Sie können Ihre CI/CD-Pipeline beispielsweise so konfigurieren, dass bei jedem neuen Commit ein Scan zur Secrets-Erkennung ausgeführt wird. Werden Secrets erkannt, kann die Pipeline fehlschlagen und das Team so auf das Problem aufmerksam machen.

# This is a simplified example of a CI/CD pipeline configuration steps:
  - name: Run Secrets Detection
    run: snyk code test
  - name: Build
    run: make build
  - name: Deploy
    run: make deploy

In diesem Beispiel führt der Befehl snyk code test als ersten Schritt in der Pipeline einen Scan zur Secrets-Erkennung aus. Werden Secrets erkannt, schlägt die Pipeline fehl und die Build- und Deploy-Schritte werden nicht ausgeführt.

Secrets-Erkennung mit Snyk implementieren

Datenpannen können verheerende Folgen haben: Sie schädigen Ihren Ruf und das Vertrauen Ihrer Kunden und können zu finanziellen Strafen führen. Werden Secrets wie API-Schlüssel, Tokens und Passwörter offengelegt, können böswillige Akteure damit leicht in Ihr System eindringen. Eine wirksame Schutzmaßnahme besteht darin, Secrets-Erkennung in Ihre Entwicklungspipeline zu integrieren. In diesem Kapitel erfahren Sie, wie Sie mit SAST von Snyk verhindern, dass Secrets übertragen werden, und mögliche Datenpannen vermeiden.

Einführung in die Secrets-Erkennungsfunktionen von Snyk

Snyk bietet robuste Secrets-Erkennung als Teil seines umfassenden Angebots für Anwendungssicherheit. Das Tool scannt Ihre Code-Repositories auf potenzielle Secrets und benachrichtigt Sie sicher über die Ergebnisse. Diese Funktion ist in das Produkt Snyk Code integriert, das Ihnen während des Programmierens Feedback und Vorschläge in Echtzeit liefert.

Die Secrets-Erkennung von Snyk basiert auf ausgefeilten Mustern und Heuristiken. Damit lassen sich potenzielle Secrets in Ihrem Code aufspüren, die Angreifer ausnutzen könnten.

Snyk-IDE-Erweiterungen für die Secrets-Erkennung in Echtzeit einrichten

Um die Secrets-Erkennungsfunktionen von Snyk zu nutzen, müssen Sie die Snyk-IDE-Erweiterung einrichten. Sie integriert die Funktionen von Snyk direkt in Ihre Entwicklungsumgebung und liefert Ihnen während des Programmierens Feedback und Vorschläge in Echtzeit.

So richten Sie die IDE-Erweiterung ein:

1. Öffnen Sie in Ihrer IDE den Bereich „Erweiterungen“ (Visual Studio Code, IntelliJ usw.).

2. Suchen Sie nach „Snyk“.

3. Installieren Sie die Snyk-Erweiterung.

4. Starten Sie das Plugin oder Ihre IDE neu.

Nach der Installation beginnt die Snyk-Erweiterung automatisch damit, Ihren Code während der Entwicklung auf potenzielle Secrets zu scannen.

# Example of a Snyk scan output
Detected secrets:
- AWS Access Key ID: AKIAIOSFODNN7EXAMPLE
- AWS Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Best Practices: Mit Snyk verhindern, dass Secrets übertragen werden

Bei der Secrets-Erkennung mit Snyk sollten Sie einige Best Practices beachten.

• Übertragen Sie niemals Secrets in Ihre Code-Repositories. Auch bei privaten Repositories besteht immer das Risiko einer Offenlegung. Wenn Snyk ein Secret erkennt, entfernen Sie es aus Ihrem Code und widerrufen Sie es nach Möglichkeit.

• Speichern Sie Secrets in Umgebungsvariablen. Statt Secrets fest in Ihren Code zu codieren, sollten Sie Umgebungsvariablen verwenden. So lassen sich Secrets einfacher verwalten und das Risiko verringert sich, dass sie in Ihr Code-Repository übertragen werden.

• Scannen Sie Ihre Code-Repositories regelmäßig mit Snyk. Regelmäßige Scans helfen sicherzustellen, dass keine Secrets unentdeckt bleiben. Mit Snyk können Sie automatisierte Scans einrichten und den Prozess so vereinfachen.

• Informieren Sie Ihr Team darüber, wie wichtig Secrets-Management ist. Alle in Ihrem Team sollten die Risiken kennen, die mit dem Übertragen von Secrets verbunden sind, und wissen, wie wichtig die Secrets-Erkennungsfunktionen von Snyk sind.

Wenn Sie diese Best Practices befolgen und Snyk nutzen, können Sie das Risiko offengelegter Secrets und möglicher Datenpannen erheblich verringern. Denken Sie daran: Sicherheit ist keine einmalige Aufgabe, sondern ein kontinuierlicher Prozess. Starten Sie jetzt Ihren Weg zu mehr Sicherheit und registrieren Sie sich hier für Snyk.

Weitere Informationen zu Secrets-Management, Tools und Best Practices finden Sie bei Snyk Learn.

Fortgeschrittene Strategien für das Secrets-Management

In den Bereichen Anwendungssicherheit und Softwareentwicklung ist die Verwaltung von Secrets wie API-Schlüsseln, Passwörtern und Zertifikaten eine wichtige Aufgabe. Ein wirksames Secrets-Management unterstützt die Einhaltung gesetzlicher Vorgaben und verhindert Datenpannen. Hier stellen wir einige fortgeschrittene Strategien vor, mit denen Sie Ihr Secrets-Management verbessern können.

Umgebungsvariablen für das Secrets-Management nutzen

Eine sichere Methode zur Verwaltung von Secrets ist die Verwendung von Umgebungsvariablen. Sie lassen sich in vielen Programmiersprachen einsetzen und ermöglichen es Ihnen, Secrets getrennt von Ihrer Codebasis zu speichern. Das ist entscheidend, um eine versehentliche Offenlegung von Secrets zu verhindern, insbesondere in Open-Source-Projekten.

Hier ein Beispiel in Python:

import os
SECRET_KEY = os.environ.get('SECRET_KEY')

In diesem Beispiel ist SECRET_KEY eine Umgebungsvariable, in der der geheime Schlüssel gespeichert wird. Die Funktion os.environ.get() ruft den Wert der Umgebungsvariablen ab. Wird die Umgebungsvariable nicht gefunden, gibt sie None zurück.

Secrets-Management-Tools und -Dienste nutzen

Der Einsatz von Secrets-Management-Tools und -Diensten kann die Sicherheit Ihrer Secrets erheblich verbessern. Tools wie HashiCorp Vault und Cloud-Dienste wie AWS Secrets Manager oder Azure Key Vault helfen dabei, Secrets sicher zu speichern und den Zugriff darauf streng zu kontrollieren.

Hier sehen Sie ein Beispiel dafür, wie Sie mit dem AWS SDK für Python ein Secret aus AWS Secrets Manager abrufen:

import boto3
secretsmanager = boto3.client('secretsmanager')
response = secretsmanager.get_secret_value(SecretId='my_secret')

In diesem Beispiel ist my_secret der Name des in AWS Secrets Manager gespeicherten Secrets. Die Funktion get_secret_value() ruft das Secret ab.

Secrets-Rotation automatisieren

Die automatisierte Rotation von Secrets ist ein wichtiger Bestandteil des Secrets-Managements. Werden Secrets regelmäßig geändert, können potenzielle Angreifer alte Secrets nicht mehr für unbefugten Zugriff nutzen.

Das lässt sich mit Secrets-Management-Diensten wie AWS Secrets Manager umsetzen, der die automatische Rotation von Secrets für Amazon RDS, Amazon DocumentDB und Amazon Redshift unterstützt.

Hier sehen Sie ein Beispiel für die Konfiguration der automatischen Rotation von Secrets in AWS Secrets Manager:

import boto3
secretsmanager = boto3.client('secretsmanager')
response = secretsmanager.rotate_secret(
  SecretId='my_secret',
  RotationLambdaARN='my_lambda_function',
  RotationRules={
    'AutomaticallyAfterDays': 30
  }
)

In diesem Beispiel ist my_secret der Name des zu rotierenden Secrets, my_lambda_function die AWS-Lambda-Funktion, die die Rotation durchführt, und AutomaticallyAfterDays gibt das Rotationsintervall in Tagen an.

Um die Sicherheit Ihrer Anwendung zu erhöhen, empfiehlt sich ein Sicherheitsprodukt wie Snyk. Snyk bietet eine Secrets-Erkennung, mit der Secrets in Ihrer Codebasis identifiziert und vor Offenlegung geschützt werden können. Hier können Sie sich für Snyk registrieren.

Die hier vorgestellten Strategien sind nur einige der vielen Möglichkeiten, das Secrets-Management zu verbessern. In Kombination mit weiteren proaktiven Sicherheitsmaßnahmen können sie den Schutz Ihrer Anwendung vor Bedrohungen deutlich stärken und dafür sorgen, dass Ihre Softwareentwicklung und Compliance-Bemühungen sicher und wirksam sind.

Historische Datenpannen durch offengelegte Secrets

Datenpannen sind in den Bereichen Anwendungssicherheit und Softwareentwicklung seit Langem ein Problem. Eine häufige Ursache sind offengelegte Secrets oder Zugangsdaten, die unbefugten Zugriff und Datenlecks ermöglichen. In diesem Abschnitt sehen wir uns einige frühere Datenpannen an, die durch offengelegte Secrets verursacht wurden, und sprechen über die daraus gezogenen Lehren und die Bedeutung der Secrets-Erkennung.

Datenpanne bei Uber: Die Folgen offengelegter Zugangsdaten

2016 kam es bei Uber zu einer erheblichen Datenpanne, bei der Daten von 57 Millionen Kundinnen, Kunden und Fahrern offengelegt wurden. Die Ursache? Offen zugängliche AWS-Zugangsdaten in einem privaten GitHub-Repository, das von den Entwicklern des Unternehmens genutzt wurde. Die Angreifer erlangten Zugriff auf diese Zugangsdaten und konnten anschließend auf das AWS-Konto von Uber zugreifen und große Mengen sensibler Daten herunterladen.

Dieser Vorfall unterstreicht, wie wichtig es ist, Zugangsdaten sicher aufzubewahren, und welche Risiken entstehen, wenn solche Secrets in Code-Repositories gespeichert werden – selbst in privaten.

Cloudflare: Die Folgen eines gestohlenen Okta-Authentifizierungstokens

2019 wurde Cloudflare Opfer einer schwerwiegenden Datenpanne. Ursache war ein Okta-Authentifizierungstoken, das einem Cloudflare-Mitarbeiter gestohlen und auf GitHub offengelegt worden war. Der Angreifer nutzte dieses Token, um auf interne Cloudflare-Systeme zuzugreifen und sensible Kundendaten offenzulegen.

Dieser Vorfall veranschaulicht die Risiken, die entstehen können, wenn geheime Schlüssel wie Authentifizierungstokens in Code-Repositories gespeichert werden – selbst wenn diese als sicher gelten.

Codecov: Wie hartcodierte Secrets zu einer massiven Datenpanne führten

2021 erlitt Codecov, eine von Entwicklern für Code-Coverage-Berichte genutzte Plattform, eine erhebliche Datenpanne. Angreifer nutzten dabei einen Fehler im Prozess zur Erstellung von Docker-Images aus, durch den hartcodierte Secrets offengelegt wurden. Mit diesen Secrets veränderten sie das Bash-Uploader-Skript von Codecov und konnten so sensible Daten aus den Umgebungen der Nutzer exfiltrieren.

Die Lehre aus diesem Vorfall? Hartcodierte Secrets stellen ein erhebliches Risiko dar. Um solche Risiken zu minimieren, empfiehlt es sich, Tools wie Snyk für die Erkennung und Verwaltung von Secrets zu verwenden.

Sumo Logic: Erkenntnisse aus dem Vorfall

2023 meldete Sumo Logic, ein cloudbasiertes Unternehmen für Log-Management, eine Sicherheitsverletzung im Zusammenhang mit der Kompromittierung seines AWS-Kontos. Der Vorfall wurde am 3. November 2023 entdeckt. Trotz des unbefugten Zugriffs über kompromittierte Zugangsdaten bestätigte das Unternehmen, dass seine Netzwerke und Systeme nicht betroffen waren und Kundendaten sicher verschlüsselt blieben. Als Reaktion sicherte Sumo Logic die betroffene Infrastruktur und aktualisierte möglicherweise offengelegte Zugangsdaten.

GitHub: Der Fall eines offengelegten privaten SSH-Schlüssels 

In einem besonders ironischen Vorfall kam es bei GitHub, der weithin für das Hosting von Code genutzten Plattform, zu einer Datenpanne aufgrund eines offengelegten privaten SSH-Schlüssels. Der Schlüssel wurde versehentlich in ein öffentliches Repository eingecheckt und von einem unbefugten Nutzer für den Zugriff auf interne GitHub-Systeme verwendet.

Dieser Vorfall unterstreicht ebenso wie viele der oben genannten, wie wichtig ein gutes Secrets-Management und die Erkennung von Secrets sind, um Datenpannen zu verhindern.