- PagerDuty /
- Blog /
- Bewährte Verfahren und Erkenntnisse /
- Shift-Left: Wie operative Prozesse die Sicherheit früher einbeziehen können
Blog
Shift-Left: Wie operative Prozesse die Sicherheit früher einbeziehen können
Als Experte für operative Abläufe in einem Cloud-Sicherheitsunternehmen habe ich eine besondere Perspektive darauf, wie Sicherheit und Betrieb zusammenarbeiten können – und im Idealfall sollten. Ein häufiges Problem in der heutigen Technologiebranche ist, dass Sicherheit fast immer erst zu spät in den Entwicklungsprozess einbezogen wird.
Es mag sich so anfühlen, als sei Sicherheit eine völlig separate Disziplin, und ihre Integration in enge DevOps-Feedbackschleifen mag abschreckend wirken. Aber ich kann Ihnen versichern, dass nicht nur dürfen Es ist zwar möglich, aber nicht so schwierig, wie es aussieht – und wenn man es richtig macht, verbessert sich Ihre allgemeine Sicherheitslage deutlich, während gleichzeitig eine Vielzahl von Problemen beseitigt wird.
Insbesondere das Konzept des „Shift-Left“ ermöglicht es Teams, Sicherheitsprozesse, die sie bisher erst spät im Bereitstellungsprozess (oder gar nicht) durchgeführt haben, früher zu integrieren. So wird Sicherheit von Anfang an gewährleistet und nicht erst im Nachhinein berücksichtigt. In diesem Beitrag erkläre ich, wie das funktioniert.
Was bedeutet „Zu spät“?
Werfen wir zunächst einen kurzen Blick darauf, wie Sicherheit heutzutage in DevOps-Prozesse integriert wird. Oftmals geschieht dies gar nicht. Das zeigt sich darin, dass Entwickler Code bereitstellen, sobald er fertig ist, ohne die Sicherheit dabei zu berücksichtigen. Natürlich tun diese Entwickler lediglich ihre Arbeit. Sie stehen unter dem Druck der Produktteams, Funktionen zu veröffentlichen, und tun einfach, was nötig ist, um den Code so schnell wie möglich bereitzustellen.
In anderen Fällen werden Sicherheitsteams in diesen Prozess eingebunden und fungieren als Kontrollinstanz, die eine Sicherheitsprüfung vor der Veröffentlichung des Codes verlangt. Es ist positiv, dass Sicherheitsexperten einbezogen und der Code auf Sicherheitslücken überprüft wird. Doch bis zur letzten Minute zu warten, kann kontinuierliche Entwicklungszyklen behindern, und im heutigen schnelllebigen Umfeld ist das oft keine Option. Hinzu kommt, dass es zu erheblichen Spannungen zwischen den Teams führen kann, da sie gegeneinander ausgespielt werden.
Wie man mit dem Linksschalten beginnt
In den letzten Jahren optimieren immer mehr Unternehmen ihre DevOps-Teams, um schneller zu arbeiten und Software kontinuierlich bereitzustellen. Jetzt ist es an der Zeit, auch die Sicherheit zu integrieren. Hier sind meine Tipps dazu.
Verwenden Sie die gleichen Werkzeuge
Es ist wichtig, dass Ihre Sicherheitsteams mit denselben CI/CD-Tools vertraut sind, die auch Ihre DevOps-Teams verwenden. Genau so hat die Zusammenarbeit von Entwicklung und Betrieb überhaupt erst begonnen – indem man den Betriebsmitarbeitern das Programmieren und den Entwicklern den Umgang mit Konfigurationsmanagement-Tools wie Chef beigebracht hat. Jetzt ist es an der Zeit, dies auch im Bereich Sicherheit umzusetzen.
Jenkins ist ein hervorragendes Beispiel. Wenn Ihre Entwickler Jenkins bereits zum Testen und Bereitstellen von Code verwenden, warum sollten Sie dann nicht auch Ihr Sicherheitsteam darin schulen? Wenn beide dasselbe Tool für Sicherheitstests nutzen, ist es viel einfacher, sie frühzeitig in den Prozess einzubinden.
Ein weiteres großartiges Werkzeug heißt: Gauntlt Obwohl ich gewisse Vorbehalte gegenüber dem Begriff „robustes DevOps“ habe, ist die Idee hinter Gauntlt gut. Von deren Website:
„Gauntlt bietet Schnittstellen zu einer Vielzahl von Sicherheitstools und stellt diese Sicherheits-, Entwicklungs- und Betriebsteams zur Verfügung, um gemeinsam robuste Software zu entwickeln. Es wurde entwickelt, um das Testen und die Kommunikation zwischen den Gruppen zu erleichtern und umsetzbare Tests zu erstellen, die in Ihre Bereitstellungs- und Testprozesse integriert werden können.“
Das Konzept, Sicherheit von Anfang an in Betriebs- und Entwicklungsprozesse zu integrieren, ist grundsätzlich sinnvoll. So wird die Auslieferung nicht durch Sicherheit verlangsamt, und der Feedback-Mechanismus kann bei auftretenden Problemen beschleunigt werden. Sicherheitsteams können mit Gauntlt Code schreiben und ihn vor der Veröffentlichung testen, was eine erfolgreiche, kontinuierliche Bereitstellung ermöglicht.
Versuchen Sie es mit der statischen Analyse.
Eine weitere Möglichkeit besteht darin, eine statische Analyse mithilfe eines Tools wie beispielsweise Veracode Anschließend können Ihre Sicherheitsteams den Code vor der Bereitstellung analysieren und potenzielle Probleme aufspüren. Die statische Analyse untersucht die Software, ohne den Code auszuführen. Sicherheitsteams können sie nutzen, um automatisiert nach potenziellen Schwachstellen zu suchen, ohne den Softwareentwicklungsprozess zu unterbrechen.
Anreize aufeinander abstimmen
Historisch gesehen besteht eine der Herausforderungen bei der Zusammenarbeit von DevOps und IT-Sicherheit darin, dass ihre Anreize im Widerspruch zueinander stehen. DevOps profitiert von einer schnellen Codebereitstellung. IT-Sicherheit profitiert hingegen nur von der Bereitstellung sicheren Codes.
DevOps- und Sicherheitsteams arbeiten besser zusammen, wenn sie dieselben oder kompatible Tools verwenden, wie oben erläutert. Um die Zusammenarbeit weiter zu optimieren, ist es außerdem wichtig, die Anreize zwischen den Teams aufeinander abzustimmen. Das bedeutet, DevOps-Teams für die Bereitstellung sicheren Codes und Sicherheitsteams für schnellere Fortschritte zu belohnen.
Eigentumsrechte sichern
Ein häufiger Fehler, den wir beobachten, ist, dass die Sicherheitsabteilung keinen Zugriff auf die Produktionsumgebung hat. Wenn die Sicherheitsabteilung keine direkte Verantwortung für den Code trägt, kann man davon ausgehen, dass sie nicht eng in die DevOps-Prozesse eingebunden sein wird.
Wenn man Sicherheitsexperten hingegen Verantwortung überträgt und ihnen beibringt, wie sie selbstständig Probleme im Code beheben können, werden sie Teil eines reibungslos funktionierenden Systems, anstatt isoliert zu arbeiten. Zum Beispiel: Bedrohungsliste Sie können Ihr Team über Sicherheitsprobleme informieren. Wenn Sie Sicherheitsteams darin schulen, diese Probleme zu beheben, und ihnen Zugriff auf den Konfigurationsverwaltungscode gewähren, können sie direkt Systemänderungen vornehmen.
Ähnlich, Küchenchef hat ein Tool namens Open Source veröffentlicht. InSpec InSpec ist ein Framework für Auditierung und Tests. Mit InSpec können Sicherheitsteams Code schreiben, um Server zu prüfen und die Einhaltung von Vorschriften sicherzustellen. Dadurch erhalten sie deutlich mehr Kontrolle über den Prozess. Wenn Sie Sicherheitsteams befähigen, ihre DevOps-Kompetenzen zu verbessern, werden Sie die positiven Auswirkungen schnell erkennen.
Eine andere Herangehensweise (insbesondere wenn kein dediziertes Sicherheitsteam vorhanden ist) besteht darin, Backend-Entwickler mit der Behebung von Sicherheitslücken im Code zu beauftragen. Wenn Entwickler direkt für die Sicherheit ihres Codes verantwortlich sind, konzentrieren sie sich viel eher darauf, ihn von vornherein sicher zu entwickeln. Bei Threat Stack haben wir zwei Mitarbeiter im Bereich Operations und zehn Backend-Entwickler im Bereitschaftsdienst. Wenn also ein Problem mit dem Produkt auftritt, werden in der Regel die Backend-Entwicklungsteams, die den Code geschrieben haben, zur Behebung hinzugezogen. Dieses hohe Maß an Sicherheit ist entscheidend. Code-Verantwortung Das schafft einen Anreiz für sie, es von vornherein richtig zu bauen.
Der Weg nach vorn führt seitwärts
Die Verlagerung der Sicherheit in frühere Phasen des Entwicklungsprozesses ist für die allgemeine Gesundheit Ihres Unternehmens von Vorteil. Anstatt dass Sicherheitsteams Probleme erkennen, Tickets erstellen und auf die Behebung durch Entwickler oder Betriebsexperten warten, werden sie befähigt, selbstständig zu handeln. Dies spart nicht nur Zeit und Personal, sondern gewährleistet auch die kontinuierliche und sichere Bereitstellung von Code. Es liegt an allen Beteiligten, proaktiver zu werden, die Arbeitsweise anderer Teams kennenzulernen und sich enger in deren Arbeitsabläufe zu integrieren.
Die obigen Tipps bieten Ihnen einen Ausgangspunkt, um „Sicherheit frühzeitig in den Entwicklungsprozess zu integrieren“ (Shift-Left-Security) in Ihrem Unternehmen umzusetzen. Denken Sie daran: Wie bei vielen Aspekten der Sicherheit erfordert dies auch hier einen gewissen Aufwand. Kulturwandel (Es geht nicht nur um die Einführung neuer Tools.) Aber mit der richtigen Denkweise, den richtigen Anreizen und entsprechenden Feedbackschleifen ist es möglich.