Softwareentwicklung

Wo Angreifer oft sensible Daten finden - Zugangsdaten in der DevSecOps-Pipeline

Wo Angreifer oft sensible Daten finden - Zugangsdaten in der DevSecOps-Pipeline

Entwickler nutzen fest kodierte Zugangsdaten, um nahtlos auf die Dienste zuzugreifen, die für die Erstellung und Bereitstellung von Anwendungen erforderlich sind, oder sich zu authentifizieren. Diese Praxis rationalisiert zwar die Entwicklung, birgt aber auch Risiken, wie Palo Alto Networks immer wieder in der Praxis beobachtet.

Wenn Zugangsdaten – wie Kennwörter, API-Schlüssel und Zugriffstoken – im Quellcode öffentlich zugänglich sind, können Angreifer sie nutzen, um sich unbefugten Zugriff zu verschaffen und Angriffe mit Datenlecks, Code-Manipulationen, gestohlenen vertraulichen Informationen oder Dienstunterbrechungen zu starten. Es ist wichtig, die Preisgabe dieser „Geheimnisse“ zu vermeiden, was aber nicht immer einfach ist.

Sensible Daten können sich überall verbergen – in Infrastructure-as-Code (IaC) und Anwendungscodedateien, Repo-Konfigurationsdateien, Konfigurationsdateien der Lieferpipeline und mehr. Wenn diese Dateien, aus welchem Grund auch immer, öffentlich werden, können Informationen in die falschen Hände geraten. Selbst wenn sich ein Unternehmen sicher ist, dass seine hartkodierten Zugangsdaten in einem privaten Repo oder hinter einer Firewall sicher sind, können Fehler passieren. Dateien können immer noch öffentlich werden.

Unternehmen sollten nach Meinung von Palo Alto Networks proaktive Maßnahmen ergreifen und die Risiken der Offenlegung von Zugangsdaten vermeiden. Sinnvoll ist dabei die Beseitigung von fest kodierten Zugangsdaten und die Anwendung von Best Practices, wie z. B. die Verwendung von Geheimnistresoren.

Es gibt fünf Bereiche, an denen sich sensible Daten im Verborgenen befinden. Best Practices helfen dabei, eine umfassende Strategie für die sicherer Verwaltung dieser Daten zu implementieren und dem Risiko einer Offenlegung einen Schritt voraus zu sein. Diese fünf beobachtet Palo Alto Networks in der Praxis besonders häufig:

IaC und Anwendungscodedateien

Auch wenn es eine bewährte Praxis ist, Zugangsdaten niemals im Quellcode zu verschlüsseln, können sich während der Entwicklung dennoch Daten in die Umgebung einschleichen. Es kommt vor, dass Entwickler vorübergehend einen Berechtigungsnachweis hartcodieren – mit der Absicht, ihn später zu entfernen – und es dann vergessen. Die Information wird im Quellcode im Versionskontrollsystem (VCS) gespeichert und fällt dann aus dem Blickfeld.

Sensible Daten können auch über IaC-Templates und Container-Images eingeschleust werden. Deshalb muss jede umfassende Strategie zur Verwaltung von Informationen eine Lösung zum Scannen von Daten nutzen, die alle Dateitypen auf offengelegte Zugangsdaten überprüft und diese aufdeckt. In der Realität bieten jedoch nicht alle Scanner die Tiefe und Breite, die Unternehmen zum Schutz ihrer Informationen benötigen. Viele eindimensionale Scanning-Tools scannen nicht alle Dateitypen und decken nicht alle offenen Zugangsdaten auf, weil sie nur Scanning mit regulären Ausdrücken und Schlüsselwörtern einsetzen.

Beim Scannen mit regulären Ausdrücken erfolgt die Suche nach bestimmten Mustern, die sich auf einen Berechtigungstyp beziehen, z. B. AWS-Zugangsschlüssel. Beim Scannen mit Schlüsselwörtern erfolgt die Suche nach Phrasen, die wahrscheinlich sensible Daten enthalten, z. B. „Passwort“. Diese Scanning-Techniken sind zwar wertvoll, aber es besteht die Gefahr, dass sie Informationen übersehen oder verrauschte Alarme auslösen. Dies kann passieren, wenn sie nicht mit den fortschrittlicheren Scanning-Techniken kombiniert werden, wie z. B. dem entropiebasierten Scanning, das Scanner für multidimensionale Daten einsetzen.

Versionskontrollsysteme

Wenn ein Team Zugangsdaten in den Quellcode einträgt und diese Daten nicht von einem Geheimhaltungsscanner erfasst werden, können Daten ihren Weg in das Versionskontrollsystem (VCS) finden. Öffentliche Repositorys stellen das offensichtlichste Risiko dar, da Angreifer diesen Repos besondere Aufmerksamkeit widmen, um offene Zugangsdaten zu finden. Ebenso können Dateien, die in privaten Repos gespeichert sind, von Personen mit Zugang heruntergeladen oder in öffentliche Repos kopiert werden, wie bei der Toyota-Datenpanne im letzten Jahr. Eine schwache VCS-Zugangskontrolle kann Unternehmen ebenfalls angreifbar machen. Deshalb ist es wichtig, einige Best Practices zu befolgen, um proaktiv alle Zugangsdaten zu entfernen und zu sichern, die im VCS vorhanden sind.

Zunächst sollten Verantwortliche sicherstellen, dass sie ihren IaC- und Anwendungscode so früh wie möglich im Entwicklungszyklus scannen. Durch frühzeitiges Scannen werden die Entwickler auf Daten aufmerksam gemacht, die sie möglicherweise übersehen oder vergessen haben zu entfernen. Sie können dann die notwendigen Schritte unternehmen, um das Geheimnis aus dem Quellcode in einen Geheimhaltungsmanager zu verschieben oder es bei der Übertragung einfach zu ignorieren. Auf diese Weise können sie die Wahrscheinlichkeit minimieren, dass hartkodierte Zugangsdaten in ihr VCS hochgeladen werden.

Teamleiter sollten auch Leitplanken in ihrem VCS einrichten, damit sie bei der Übergabe einer neuen Datei oder eines neuen Codes sofort alle fest kodierten Daten identifizieren können. Darüber hinaus ist es eine bewährte Praxis, Umgebungsvariablen oder einen Secrets-Manager zu verwenden, um sicherzustellen, dass alle Geheimnisse, die Teammitglieder verwenden müssen, gegen Angreifer geschützt sind.

Auslieferungs-Pipelines

Daten können sich an zwei Stellen in Bereitstellungspipelines verstecken – sowohl im Code, der bereitgestellt werden soll, als auch in den Bereitstellungspipelines selbst, d. h. in CI/CD-Konfigurationsdateien. Das Scannen des Codes zu einem möglichst frühen Zeitpunkt im Entwicklungszyklus ist immer eine bewährte Praxis, aber es ist auch wichtig, als Teil der CI/CD-Builds nach offengelegten Zugangsdaten zu suchen. Unternehmen verwenden oft IaC- und CI/CD-Pipelines, um Container-Images einzulesen, die als Anwendungskomponenten oder Testumgebungen ausgeführt werden.

Eine bewährte Praxis besteht darin, eine geheime Sicherheitslösung einzusetzen, die alle Images identifiziert, die aus IaC- und CI/CD-Dateien eingelesen werden, so dass sich diese auf offengelegte Zugangsdaten überprüfen lässt. Um einen vollständigen Schutz zu erhalten, müssen Unternehmen auch exponierte Zugangsdaten in den Pipelines selbst identifizieren und beseitigen. Durch den Einsatz eines mehrdimensionalen Secrets-Scanners, der das Scannen von CI/CD-Konfigurationsdateien unterstützt, können sie einen Einblick in ihre öffentlich zugänglichen Zugangsdaten erhalten und diese bei Bedarf entfernen oder sichern.

Runtime-Umgebungen

Wenn Unternehmen einen einfachen Secrets-Scanner verwenden, können Daten aus zwei Quellen in Laufzeitumgebungen eingeführt werden. Grundlegende Scanner bieten keine vollständige Abdeckung beim Scannen von Geheimnissen, was bedeutet, dass sie möglicherweise nicht alle Daten im Quellcode oder die in Container-Images eingebetteten Daten erkennen, bevor diese Daten bereitgestellt werden.

Angenommen, ein Scanner übersieht ein fest kodiertes API-Token im Quellcode und der Code wird bereitgestellt: Wenn das Team dies erst im Nachhinein bemerkt, muss es das Problem manuell beheben, indem es die Zugangsdaten aus der laufenden Anwendung und dem Quellcode entfernt und dann den Schlüssel sowohl widerruft als auch rotiert. Dies kann andere Anwendungen beschädigen.

Alternativ dazu ist es möglich, sensible Daten in die Container-Images einzubetten. Obwohl es eine schlechte Praxis ist, laufende Container zu verändern, könnten Daten manuell zu Images hinzugefügt worden sein. Daten können sich auch in die Runtime-Umgebungen einschleichen, wenn sie nicht frühzeitig erkannt werden, weil sie durch die Pipeline (z. B. in einer Vault) verwaltet und dann dem Image hinzugefügt wurden. Es ist eine bewährte Praxis, Daten rechtzeitig vor dem Zugriff zu injizieren. Ohne einen tiefen Blick in die Container-Dateisysteme könnten diese Daten vom Team übersehen werden, aber nicht von Angreifern.

Lange Liste von Alarmen

Secrets-Scanning-Lösungen haben einen schlechten Ruf, weil sie zu viele Warnmeldungen erzeugen. Zu viele Fehlalarme können zu Ermüdungserscheinungen führen, das Team ablenken und dazu führen, dass Alarme übersehen werden, die auf legitime Daten hinweisen.

Um die Anzahl der Warnungen, die das Team bearbeiten muss, zu reduzieren, müssen Unternehmen einen umfassenden Secrets-Scanner finden, der mehrdimensional und fein abgestimmt ist. Wenn der Scanner Schlüsselwörter, reguläre Ausdrücke und entropiebasiertes Scannen in einem multidimensionalen Ansatz kombiniert, wird er mehr Daten identifizieren. Daher ist es wichtig, Daten validieren zu können, um das Gesamtvolumen der Warnmeldungen zu reduzieren, die False-Positive-Rate zu senken und die vollständige Abdeckung zu bieten, die Unternehmen benötigen.

Die Kaskadennatur der Offenlegung von Geheimnissen bedeutet, dass übersehene Daten in IaC-Dateien und Anwendungscode in öffentliche Repos hochgeladen und von Delivery-Pipelines bereitgestellt werden können. Diese enthalten ihre eigenen offengelegten Daten enthalten und werden dann zu Laufzeit-Sicherheitsproblemen, die Teams beheben müssen. Um diesem Kaskadeneffekt zuvorzukommen, müssen Unternehmen die Sicherheit ihrer Daten in der Zeitleiste nach links verlagern („shift left“) und einen umfassenden, auf Prävention ausgerichteten Ansatz für die Verwaltung von Geheimnissen wählen.