Im Zeitalter von Cloud- und Serverless-Computing sowie Microservices und Domain-Driven Design gibt es neben den gerade genannten Schlagwörtern noch viele weitere, die man unbedingt kennen sollte. Ein äußerst wichtiger Aspekt der Softwareentwicklung heutzutage ist das sogenannte DevOps.
DevOps steht für die Integration von Softwareentwicklung (Dev) und Operations (Ops) in einen geschlossenen Prozess, bei dem der gesamte Entwicklungslebenszyklus so kurz und effizient wie möglich gehalten wird. DevOps repräsentiert eine Methodologie, bei der Softwareentwicklung ganzheitlich und agil entwickelt und betrieben werden kann. Aufgrund der weitreichenden Beliebtheit ist DevOps in den letzten Jahren zu einem führenden Paradigma für Technologieunternehmen und IT-Abteilungen geworden.
Ohne hier eine detaillierte Erläuterung von DevOps als Methodologie vorzunehmen, möchte ich auf eine konkrete Weiterentwicklung eingehen: DevSecOps. Da sich DevOps nur auf die Integration des Entwicklungs- und Operationsprozesses konzentriert, geht ein äußerst wichtiger Aspekt jeder Softwareentwicklung verloren: der Sicherheitsaspekt.
DevSecOps als Erweiterung von DevOps
DevSecOps erweitert die DevOps-Methodologie um den Sicherheitsaspekt und deckt somit die Anforderungen zeitgemäßer Softwareentwicklung besser ab. Durch die Integration von Sicherheitsrelevanten Anforderungen in den gesamten Lebenszyklus des Prozesses werden diese Anforderungen ebenfalls erfasst und berücksichtigt.
Das Cloud Native Glossary hat einen eigenen Eintrag über DevSecOps und definiert den Begriff wie folgt:
“The term DevSecOps refers to a cultural merger of the development, operational, and security responsibilities. It extends the DevOps approach to include security priorities with minimal to no disruption in the developer and operational workflow. Like DevOps, DevSecOps is a cultural shift, pushed by the technologies adopted, with unique adoption methods.”
DevOps sowie DevSecOps sind laut der CNCF nicht nur Methodologien, sondern auch ein kompletter Kulturwandel. Es wird hier über die Verantwortlichkeiten in Bezug auf Entwicklung, Betrieb und Sicherheit gesprochen. Sicherheit ist dabei ein weiterer Bestandteil und eine Priorität, die minimale bis keine Unterbrechungen in der Entwicklungs- und Betriebsphase garantiert.
Auch Snyk, ein bekannter Cloud-Native-Player mit einer Produktpalette, die auf Sicherheit spezialisiert ist, definiert DevSecOps auf eigene Weise. Hier ist deren Definition:
“The definition of DevSecOps Model, at a high-functioning level, is to integrate security objectives as early as possible in the lifecycle of software development. While security is “everyone’s responsibility,” DevOps teams are uniquely positioned at the intersection of development and operations, empowered to apply security in both breadth and depth.”
Snyk betont die Wichtigkeit, Sicherheit von Anfang an in den Softwareentwicklungslebenszyklus zu integrieren, damit dieser Aspekt von allen Beteiligten getragen werden kann. Sowohl diese Definition als auch die zuvor genannte verdeutlichen, dass es bei DevSecOps darum geht, Sicherheit als wesentlichen Bestandteil aller Überlegungen während des gesamten Prozesses zu betrachten. Die Verantwortung und Umsetzung von sicherheitsrelevanten Punkten obliegt somit dem gesamten Dev(Sec)Ops-Team und ist eine Kernkompetenz in allen relevanten Aktivitäten.
Hier ist ein Venn-Diagramm zu sehen, links der DevOps-Prozess ohne Sicherheit und rechts derselbe Prozess mit dem Sicherheitsaspekt. Dies dient als einfache Visualisierung dessen, wofür “Sec” in DevSecOps steht.
Figure: Quelle: Snyk
Vorteile von DevSecOps
Warum sollte man überhaupt DevSecOps betreiben wollen? Falls die Vorteile eines security-affinen DevOps-Prozesses nicht intuitiv klar sein sollten, möchte ich hier kurz die Punkte auflisten und erläutern, warum es sinnvoll ist, DevSecOps als vollwertigen Teil von DevOps zu betrachten.
Figure: Quelle: Snyk
- Schnellere Softwarebereitstellung: Die Geschwindigkeit der Softwarebereitstellung wird verbessert, wenn Sicherheit in den Entwicklungsprozess integriert wird. Fehler werden vor der Bereitstellung identifiziert und behoben, sodass sich Entwickler auf die Funktionalität konzentrieren können.
- Verbesserte Sicherheitsausrichtung: Sicherheit ist von Beginn an ein wichtiger Aspekt. Ein Modell der gemeinsamen Verantwortung stellt sicher, dass Sicherheit eng integriert ist - von der Konzeption über die Entwicklung bis hin zur Sicherung von produktiven Workloads.
- Kostenoptimierung: Durch die Identifizierung von Schwachstellen und Fehlern vor der Bereitstellung wird das Risiko und die Betriebskosten exponentiell reduziert.
- Mehrwert für DevOps: Die Verbesserung der allgemeinen Sicherheitslage als Teil einer gemeinsamen Verantwortungskultur wird durch die Integration von Sicherheitspraktiken in DevOps erreicht. Laut dem Snyk/Puppet 2020 DevSecOps Insights Report trifft dies auf etablierte DevSecOps-Organisationen zu.
- Verbesserung der Integration und Geschwindigkeit von Sicherheitsmassnahmen: Die Kosten und der Zeitaufwand für die sichere Softwarebereitstellung werden reduziert, da Sicherheitskontrollen nicht nachträglich implementiert werden müssen.
- Gesamtwirtschaftlicher Erfolg: Ein höheres Vertrauen in die Sicherheit der entwickelten Software und die Akzeptanz neuer Technologien ermöglichen ein verbessertes Umsatzwachstum und erweiterte Geschäftsangebote.
Der DevSecOps-Flow
Figure: Quelle: Snyk
Shift-left and shift-right
Es wurde bereits viel über die Vorteile der Durchführung von Sicherheitsbewertungen zu einem frühen Zeitpunkt im Lebenszyklus der Softwareentwicklung geschrieben ("Shift Left"), bevor Schwachstellen ihren Weg in die Produktion finden.
DevSecOps muss sich jedoch auch auf Produktionsumgebungen erstrecken ("Shift Right") aus vier Gründen:
- Die meisten Angriffe finden in der Produktion statt.
- Das Scannen des Quellcodes kann nicht die gleichen umfassenden Erkenntnisse liefern wie die Beobachtung der Anwendung während ihrer Ausführung in der Produktion.
- Einige Anwendungen, die in der Produktion ausgeführt werden, sind möglicherweise nicht durch die Entwicklungsumgebung gelaufen, sodass sie nie die Chance hatten, von Sicherheitstools in Ihrer Entwicklungsumgebung gescannt zu werden.
- Um neue Zero-Day-Schwachstellen zu erkennen, müssen vorhandene Anwendungen in Ihrer Produktionsumgebung überwacht werden.
Im Zeitalter nach Log4j
Thoughtworks, eine der bekanntesten Technology Consultancies und Erfinderin des Technology-Radar-Formats, von dem wir zuvor eine Abweichung von CNCF als Referenz herangezogen haben, gibt regelmäßig ihre Meinungen zu allgemeinen Trends und Marktentwicklungen preis. In einem Artikel mit dem Titel “Macro trends in the tech industry | March 2022” von Anfang 2022 hat Thoughtworks einen ganzen Absatz der Frage gewidmet, wie die Tech-Welt nach der Zero-Day-Schwachstelle Log4j mit Open-Source-Projekten umgehen wird.
Nachdem erläutert wurde, wie sich Open-Source, insbesondere GNU/Linux, in der IT-Welt etabliert hat und nun 90% der Cloud-Server ausmacht, sowie wie weit verbreitet Open-Source-Software in verschiedenen Bereichen der Softwareentwicklung ist, wurde durch Log4j klar, dass der Aspekt der Herkunft und Qualität sowie Entwicklung und Wartung eines Open-Source-Projekts genauso relevant für die firmeneigene Sicherheit ist wie potenziell hausgemachte Sicherheitslücken.
Der Artikel zitiert auch Steve Marquess, dessen Zitat ich hier gerne erwähnen möchte.
“It takes nerves of steel to work for many years on hundreds of thousands of lines of very complex code, with every line of code you touch visible to the world, knowing that code is used by banks, firewalls, weapons systems, web sites, smart phones, industry, government, everywhere. Knowing that you’ll be ignored and unappreciated until something goes wrong.”
CNCF hat ein eigenes Cloud Native End-User Tech Radar
In Anlehnung an das Thoughtworks Technology Radar hat die CNCF eine eigene Variation davon geschaffen, um Technologie-Trends einen visuellen Überblick zu bieten.
Figure: CNCF Technology Radar 2021
Die ersichtlichen Resultate basieren auf rund 150 Rezensionen einer CNCF-Umfrage aus dem Jahr 2021. Dabei wird zwischen den Kategorien “Adopt”, “Trial” und “Assess” unterschieden. “Adopt” sind Technologien, die sich bereits ausreichend etabliert haben und ohne Bedenken in den eigenen DevSecOps-Prozess integriert werden können. “Trial” sind Technologien, die man ausprobieren sollte. “Assess” sind Technologien, die man im Auge behalten sollte, aber noch nicht den Reifegrad erreicht haben, um sie bedenkenlos einzusetzen.
Viele bekannte Tools sind im “Adopt”-Bereich zu finden, darunter Namen wie Sonarqube, Istio, HashiCorp Vault, Terraform, ArgoCD und OPA. Diese Technologien sollten jedem versierten DevOps-Fachmann bekannt sein. Weniger bekannte Kandidaten sind im “Assess”-Bereich zu finden. Genau diese Technologien könnten in Zukunft die gewünschte Innovation im Bereich DevSecOps hervorbringen.
Hier ist ein kurzer Überblick über die aufgeführten “Assess"-Technologien und warum sie für DevSecOps interessant sein können:
Cilium
Cilium ist eine Kubernetes-Komponente, die das Netzwerk und die Konnektivität sicherer macht. Es basiert auf dem modernen GNU/Linux-Kernel-Feature eBPF, das eine Art Bytecode-Interpreter auf Kernel-Ebene darstellt. Mit eBPF kann man Workloads gezielt auf Kernel-Ebene isoliert ausführen und Kernel-Funktionen außerhalb des vorgesehenen Betriebs ausführen. Dadurch kann Cilium den Netzwerkverkehr direkt im Kernel verarbeiten und umgeht viele Umwege, was effizienter und sicherer ist.
HashiCorp Sentinel
Sentinel ist eine Software für Policy-as-Code und stammt von der bekannten und führenden Cloud-Native-Software-Schmiede HashiCorp. Damit kann man Richtlinien in den eigenen DevOps-Prozess integrieren und wie Anwendungscode versionieren, überprüfen und testen lassen.
Trivy
Trivy ist ein Vulnerability-Scanner und ermöglicht die Überprüfung einer breiten Palette von Artefakten auf Sicherheitslücken.
All diese Technologien sollten separat evaluiert werden und eignen sich perfekt für weitere technologische Verbesserungen. Schau regelmässig bei uns vorbei, um zu sehen, ob wir das Tool in der Zwischenzeit bereits aufbereitet haben. 🤓
Fallbeispiel: Aqua Trivy
Trivy ist ein interessantes Projekt, welches ein Vulnerability-Scanning von Artefakten vornimmt. In den eigenen Worten von Trivy definiert sich die Anwendung wie folgt:
Trivy (tri ausgesprochen wie trigger, vy ausgesprochen wie envy) ist ein einfacher und umfassender Schwachstellen/Fehlkonfigurations/Geheimnis-Scanner für Container und andere Artefakte. Trivy erkennt Schwachstellen von Betriebssystempaketen (Alpine, RHEL, CentOS, etc.) und sprachspezifischen Paketen (Bundler, Composer, npm, yarn, etc.). Darüber hinaus durchsucht Trivy Infrastruktur als Code (IaC)-Dateien wie Terraform und Kubernetes, um potenzielle Konfigurationsprobleme zu erkennen, die Ihre Bereitstellungen einem Angriffsrisiko aussetzen. Trivy durchsucht auch fest codierte Geheimnisse wie Passwörter, API-Schlüssel und Tokens. Trivy ist einfach zu bedienen. Installieren Sie einfach die ausführbare Datei und Sie sind bereit zum Scannen. Alles, was Sie zum Scannen tun müssen, ist ein Ziel anzugeben, wie z.B. einen Imagenamen des Containers.
Installation und Nutzung
Trivy kann man kann leicht über den Paketmanager der Wahl installieren. Hier auf macOS einfach mit brew:
|
|
Der Syntax von trivy ist wie folgt:
|
|
Für ein Container-Image könnte das so aussehen:
|
|
Auf der offiziellen Webseite gibt es noch ein animiertes GIF, welches dessen Nuztung auch recht gut darstellt. So könnte das in etwa aussehen:
Figure: Quelle: Trivy
Eine kleine Liste von Best-Practices
Ich habe mir die Best-Practices nicht selber ausgedacht, sondern berufe mich auf die kollektive Erfahrung. Auf Devops.com gibt es eine meiner Meinung nach recht sinnvolle Auflistung von Punkten, die ich gerne durchgehen möchte.
- Sichere den Entwicklungsprozess ab: Der erste Schritt von DevSecOps besteht darin, die CI/CD-Pipelines abzusichern. Das bedeutet, dass nur autorisierte Entwickler Zugriff auf die Git-Repositories haben und Änderungen am Code über Pull-Requests von dafür vorgesehenen Reviewern genehmigt werden müssen. Dadurch wird sichergestellt, dass die Codebasis selbst auf sicherheitsrelevante Aspekte überprüft wird und neuer Code den gleichen Prozess durchläuft.
- Schütze die Produktionsumgebung: Die Produktionsumgebung ist der Ort, an dem die Anwendung bereitgestellt und dem Endkunden zur Verfügung gestellt wird. Daher ist es von entscheidender Bedeutung, dass die Produktionsumgebung so sicher wie möglich gestaltet ist. Eine Möglichkeit, dies zu erreichen, besteht darin, sie in verschiedene sogenannte Tiers aufzuteilen. Wenn eines dieser Tiers kompromittiert wird, stehen weitere Tiers zur Verfügung, um die Anwendung bereitzustellen.
- Führe Least-Privilege-Prinzipien ein: Es ist sinnvoll, die Zugriffsrechte auf DevOps-Ressourcen so zu gestalten, dass den Benutzern nur die geringstmöglichen Privilegien gewährt werden. Dieses Prinzip wird als Least-Privilege bezeichnet. Der Grund dafür ist, dass die eigenen Entwickler und Stakeholder letztendlich das größte Sicherheitsrisiko darstellen. Der Grund dafür liegt nicht unbedingt darin, dass Mitarbeiter böswillig handeln, sondern darin, dass es nicht immer einfach ist, sicherheitsbewusst zu arbeiten und alle Sicherheitslücken zu kennen.
- Setze rollenbasierte Zugriffskontrolle (RBAC) ein: Rollenbasierte Zugriffskontrolle, auch als Role-based Access Control (RBAC) bezeichnet, ist eine Methode, um den Zugriff auf Ressourcen basierend auf Rollen anstatt auf einzelnen Benutzern zu autorisieren. Der Vorteil dabei ist, dass die Rollen definiert werden müssen, z.B. “Entwickler” oder “Tester”, und Benutzern diese Rollen zugewiesen werden können. Wenn eine DevOps-Ressource angefordert wird, wird überprüft, ob der Benutzer die Rolle hat, die für die Ressource erforderlich ist. RBAC hat den Vorteil, dass potenzieller Schaden proaktiv begrenzt werden kann, da nur Benutzer Ressourcen kompromittieren können, für die sie auch die entsprechende Rolle haben.
- Verschlüssele sensible Daten: Alle Daten, die potenziell dazu verwendet werden können, um Einzelpersonen zu schädigen oder zu impersonieren, sollten als sensibel eingestuft werden. Dazu können zum Beispiel Kreditkartennummern oder Sozialversicherungsnummern gehören. Sensible Daten müssen entsprechend verschlüsselt werden. Eine von mehreren Möglichkeiten hierfür ist die Verschlüsselung mit PGP (Pretty Good Privacy), einer Kombination aus öffentlichem und privatem Schlüssel zur Verschlüsselung von Daten. Es gibt viele weitere Möglichkeiten zur Verschlüsselung.
- Nutze Multi-Faktor-Authentifizierung: Die Multi-Faktor-Authentifizierung (MFA), auch als 2-Faktor-Authentifizierung bezeichnet, wenn nur 2 Kanäle für die Authentifizierung genutzt werden, ist eine Methode, um die Sicherheit bei der Anmeldung und Authentifizierung für DevOps-Ressourcen zu erhöhen. Dies hilft, wenn ein unberechtigter Benutzer versucht, sich mit einem legitimen Passwort auf einer Cloud-Plattform anzumelden, da das Passwort kompromittiert wurde.
- Verwende Tools für das Secrets-Management: In der Codebasis können auch sensible Daten enthalten sein, wie z.B. API-Schlüssel oder Benutzerdaten für Schnittstellen. Diese sollten nicht ungesichert in einem Git-Repository gespeichert werden, auch wenn der Zugriff auf die Repositories geregelt ist. Abhilfe schafft hier ein Secrets-Management-Tool wie HashiCorp Vault oder AWS Secrets Manager. Damit können diese Secrets entsprechend geschützt und nur dort verwendet werden, wo sie benötigt werden.
- Fördere das Sicherheitsbewusstsein: Ein wichtiger Bestandteil von DevSecOps ist natürlich die Mentalität und die Kultur der Mitarbeiter. Es ist wichtig, ein Bewusstsein für Sicherheit zu schaffen und kontinuierliche Schulungen in diesem Bereich zu fördern. Dazu gehören Schulungen mit Zertifikaten oder maßgeschneidertes Training für die interne Infrastruktur und die DevOps-Umgebung.
- Verwende eine Web Application Firewall (WAF): Eine Web Application Firewall (WAF) ist eine Firewall, die speziell für Webanwendungen entwickelt wurde und den Zugriff auf Webserver-Backendsysteme reguliert. Sie hilft dabei, bösartigen eingehenden Traffic abzufangen. Es gibt viele WAF-Lösungen, die oft in Kombination mit einem Reverse-Proxy wie NGINX oder HAProxy eingesetzt werden.
- Führe regelmäßige Sicherheitsaudits durch: Regelmäßige Audits sind ein zentraler Prozess in einer DevOps-Umgebung, insbesondere im Hinblick auf Sicherheitsaspekte. Sie helfen dabei, Schwachstellen zu identifizieren und zu beheben. Diese Audits können den gesamten DevOps-Prozess abdecken oder in kleinere, dedizierte Einheiten wie Penetrationstests oder einfache Code-Reviews unterteilt werden.
- Verwende Intrusion Detection and Prevention Systems (IDPS): Intrusion Detection and Prevention Systems (IDPS) sind dazu gedacht, bösartige Aktivitäten zu erkennen und zu blockieren. Sie können physische und virtuelle Ressourcen schützen. Es gibt viele IDPS-Lösungen wie Snort, Suricata oder Bro. Oft werden IDPS-Systeme als Teil von Security Information and Event Management Systems (SIEM) eingesetzt.
- Entwerfe einen Disaster-Recovery-Plan (DRP): Falls etwas schief geht und Systeme ungewollt kompromittiert werden, ist es sinnvoll, einen Backup-Plan in Form eines Disaster-Recovery-Plans (DRP) zu haben. Dieser Plan dient als Leitfaden dafür, was im Falle eines Ausfalls zu tun ist. Er enthält eine Liste von Schritten und Bedingungen, unter denen diese Schritte ausgeführt werden sollen. DRPs enthalten auch Kontaktdaten und detaillierte Anleitungen zur Wiederherstellung oder Neuaufsetzung von Systemen.
- Nutze Logging- und Monitoring-Tools: Logging und Monitoring sind grundlegende Bestandteile eines jeden DevOps-Prozesses, aber im Hinblick auf die Sicherheit ist die Nachvollziehbarkeit ein wichtiger Aspekt. Man möchte im Falle eines Angriffs genau nachverfolgen können, was passiert ist, um die Sicherheitslücke zu schließen. Es gibt viele bekannte Lösungen, die von großen Unternehmen eingesetzt werden, wie Splunk, Nagios oder der ELK Stack.
- Führe regelmäßige Penetrationstests durch: Penetrationstests sind Sicherheitstests, bei denen versucht wird, unbefugten Zugriff auf ein Zielsystem zu erlangen. Dabei werden potenzielle Angriffsmöglichkeiten kontrolliert simuliert, um bekannte und unbekannte Angriffsvektoren bestmöglich einzuschätzen. Penetrationstests sind Teil eines Sicherheitsaudits und sollten regelmäßig durchgeführt werden. Häufig werden dafür spezialisierte Penetrationstester engagiert. Bekannte Tools in diesem Bereich sind beispielsweise Metasploit.
- Verwende Access-Control-Lists (ACLs): Zugangskontrolllisten, auch als Access-Control-Lists (ACLs) bezeichnet, sind Listen von Regeln, die den Zugriff auf DevOps-Ressourcen ermöglichen oder einschränken. Dabei werden alle Regeln überprüft, z.B. ob die eingehende IP-Adresse auf einer Blacklist steht. Wenn keine Regel greift, wird der Zugriff gewährt.
So, das waren jetzt 15 Best Practices im Schnelldurchlauf. Es ist definitiv sinnvoll, jeden Punkt einzeln zu betrachten und sich mit den Prinzipien vertraut zu machen. Sicherheit ist kein statischer Zustand, sondern ändert sich im Laufe der Zeit und passt sich neuen Bedingungen an. Es ist daher wichtig, regelmäßig zu lesen und sich fortzubilden, um auf dem neuesten Stand zu bleiben. Die oben aufgeführten Punkte geben einen guten Einblick in den Sicherheitsaspekt einer DevSecOps-Lösung.
Abschlusswort
Bei uns bei b-nova ist DevOps eines unseren Steckenpferden. Und wir sind mittlerweile auch der Meinung, dass man richtiges DevOps nur in Kombination mit dem Security-Aspekt, also als DevSecOps, betreiben kann. Das ist auch mitunter der Grund warum wir vermehrt Security-Themen nachgehen und diese proaktiv in unseren Alltag und Wissenspool integrieren.
Schau dir doch am besten unsere TechUps über Security an, um am Ball von DevSecOps zu bleiben.
Links und weiterführende Quellen
DevSecOps | Cloud Native Glossary
DevSecOps, September 2021 | Cloud Native End User Tech Radar
DevSecOps Overview | Snyk Resources
What is DevSecOps? And what you need to do it well | dynatrace
DevSecOpsTools | The DevSecOp tools that secure DevOps workflows | Atlassian
15 DevSecOps Best Practices | DevOps.com
Container Security Scanning with Trivy and Azure DevOps | Liam Gulliver’s Blog