Die Sicherung von Apps beginnt mit der Sicherung der SDLC-Pipeline

Moderne Entwicklungspraktiken automatisieren den Entwicklungslebenszyklus zunehmend. Von der IDE bis zu den Code-Repositories, vom automatisierten Erstellen und Scannen bis zur Freigabe für die Produktion sind die Tools so miteinander verbunden, dass sie eine kontinuierliche Bereitstellungspipeline bilden.

Repositories dienen sowohl als Speicherort für Code als auch zum Initiieren der Ereignisse, aus denen der Bereitstellungsprozess besteht. Beim Übertragen des Codes wird möglicherweise ein Sicherheitsscan ausgeführt. Wenn eine Konfiguration geändert wird, kann sie automatisch zur sofortigen Bereitstellung an die entsprechende Infrastruktur übertragen werden.

Diese Tools beschleunigen den Entwicklungs-, Liefer- und Bereitstellungsprozess – und befinden sich zunehmend „in der Cloud“. Auf die vor Ort vorhandenen Lösungen kann häufig über das Internet zugegriffen werden, um eine wachsende Community von Remote-Entwicklern zu unterstützen. Die meisten Organisationen sind zwar sicherheitsbewusst genug, um einen Berechtigungszugriff auf Repositories zu verlangen, sie schützen diesen Zugriff jedoch nicht unbedingt vor modernen Bedrohungen.

Eine dieser modernen Bedrohungen ist Credential Stuffing . Generell wird dies als Risiko für Unternehmensressourcen angesehen. Tatsächlich besteht jedoch bei jedem über das Internet zugänglichen Anmeldesystem die Gefahr einer Kompromittierung. Entwickler wenden ebenso wie andere IT-Experten keine sicheren Kennwortpraktiken an. Die Wiederverwendung von Passwörtern ist im Internet weit verbreitet und die Offenlegung von Milliarden von Anmeldeinformationen ermöglicht es Angreifern, bei ihren Bemühungen, Zugriff auf eine Vielzahl von Systemen zu erhalten, eine Vielzahl von Ressourcen auszunutzen. Lesen Sie diesen Artikel, der diesen Aphorismus entlarvt: „Eine von Lastline durchgeführte Umfrage unter 306 Infosec-Experten auf der Londoner Infosecurity-Konferenz 2018 ergab, dass 45 Prozent eine der größten Kardinalsünden in Sachen Sicherheit begehen: die Wiederverwendung von Passwörtern für mehrere Konten.“ Wenn fast die Hälfte der Sicherheitsexperten Passwörter wiederverwendet, stellen Sie sich vor, wie das Profil der übrigen IT-Community – einschließlich der Entwickler – aussieht.

Existenziell ist der berüchtigte Datendiebstahl in den USA … Der Angriff auf das Office of Personnel Management (OPM) begann im Jahr 2014 und wurde von Angreifern durchgeführt, denen es gelungen war, die Anmeldeinformationen eines privilegierten Benutzers zu kompromittieren. Nachdem die Angreifer diese Anmeldeinformationen erfolgreich gestohlen hatten, konnten sie nicht nur auf die vertraulichen Informationen auf den OPM-Servern zugreifen, sondern auch seitlich in Server und Infrastruktur der USA eindringen. Innenministerium, wo sie ebenfalls Chaos verursachten.

Durch den Zugriff auf die Systeme und Dienste, aus denen sich der SDLC zusammensetzt, können Angreifer sozusagen den Brunnen vergiften. Das Einschleusen böswilliger Handlungen oder der Diebstahl von Ideen ist leicht möglich, wenn man Zugriff auf den Quellcode hat. 

Um dieser Bedrohung entgegenzuwirken, sollten Unternehmen erwägen, das Konzept einer Zero-Trust -Architektur auf die Tools in ihrer Softwareentwicklungspipeline auszuweiten. Von der IDE über Cloud-Verwaltungskonsolen bis hin zu Code-Repositorys können durch die Verwendung von privilegiertem Benutzerzugriff strenge Sicherheitspraktiken auf Basis von MFA/CAC erzwungen werden.

Privilegierter Benutzerzugriff und die SDLC-Pipeline

Privileged User Access (PUA) ist im Grunde eine Föderation ohne SAML oder die Anforderung, dass Anwendungen eine Art exotische Authentifizierungsmethode unterstützen. Es ist in der Lage, die Zero-Trust-Prinzipien auf Legacy-Apps auszuweiten und gleichzeitig moderne, webbasierte Anwendungen zu unterstützen.

Diese Lösung basiert auf der Fähigkeit des F5 Access Policy Manager (APM), als Anmeldeinformations-Proxy zu fungieren, sowie auf seiner Fähigkeit, flüchtige Anmeldeinformationen automatisch zu verallgemeinern. Kurz gesagt: Benutzer werden gegenüber einem Anmeldeinformationsspeicher des Unternehmens (Domänencontroller, LDAP) authentifiziert und anschließend generiert APM temporäre Anmeldeinformationen, die zum Anmelden beim geschützten System verwendet werden können. Im Fall der Entwicklungspipeline könnte dies das Code-Repository wie Bitbucket , GitHub oder GitLab sein. Mit diesem Ansatz können Sie den Zugriff auf das Repository besser kontrollieren, ohne dass für den Entwickler ein enormer Prozessaufwand entsteht. 

1. Der Benutzer gibt Anmeldeinformationen für BIG-IP ein
2. BIG-IP validiert Benutzeranmeldeinformationen anhand eines IaaS- oder lokalen Verzeichnisdienstes
3. BIG-IP stellt dem authentifizierten Benutzer flüchtige Anmeldeinformationen zur Verfügung
4. Temporäre Benutzeranmeldeinformationen über IDE oder Browser zum Repository
5. Das Repository übergibt Benutzernamen und temporäre Anmeldeinformationen zur Validierung an BIG-IP.
6. BIG-IP gibt Validierung zurück
7. Der Benutzer hat sich erfolgreich beim Repository angemeldet.

Sensible Daten sollten Code enthalten. Das bedeutet, dass der Zugriff auf Code ebenso geschützt werden sollte wie auf Daten. Code ist das Herzstück eines digitalen Unternehmens und die Lieferkette wird zunehmend als Angriffsvektor betrachtet. Durch die Implementierung eines Modells für privilegierten Benutzerzugriff können Sie sicherer sein, dass sowohl die Anmeldeinformationen als auch der dahinter stehende Benutzer legitim sind.

Weitere Informationen zu F5 APM finden Sie hier .