Was ist DevOps?

Viele kennen das: die Lücke zwischen Vertrieb und Produktion scheint groß zu sein. Das zeigt sich wenn Produkte dem Markt nicht schnell genug folgen können oder die Anforderungen aus dem Markt nicht wirklich durch das Produkt befriedigt werden. Genauso verhält es sich in der IT-Produktion: Entwickler auf der einen Seite möchten schnell etwas im Markt ausprobieren können. Sie mögen keine Beschränkungen und sie benötigen ihre Freiheiten. Betriebsmanager auf der anderen Seite möchten einen stabilen Betrieb sicher stellen. Der stabile Betrieb hat seine Sicherheitsanforderungen und es gibt QualityGates die neue Releases vor Inbetriebnahme überprüfen.

Das DevOps-Konzept soll diese Lücke schließen und Produkte bzw. neue Releases schnell auf den Markt bringen können. Die hohe Geschwindigkeit der Developer scheint ein Problem für Sicherheits-Manager zu sein. Die hohe Geschwindigkeit für das Deployment in den Betrieb (Ops) ebenfalls. DevOps muss zum Enabler für mehr Sicherheit der Produkte werden. Dieser Artikel fasst zusammen welche Sicherheitsstandards heran gezogen werden können und beschreibt weiterhin wie IT-Sicherheit in Rapid- und Agile-Teams und -Prozesse integriert werden kann.

WELCHE SICHERHEITSSTANDARDS SIND SINNVOLL?

Nicht nur die großen IT-Betriebe wie Facebook, Google oder Amazon setzen auf DevOps, sondern auch die Branchen aus Finanzen, Energie oder Telekommunikation.
Es gibt IT-sicherheitsrelevante Standards aus der Finanzindustrie (wie PCI DSS oder Sicherer IT-Betrieb, SITB), der Versicherungsbranche (VAIT), der Pharmabranche (HIPAA, HITECH) und Anforderungen von Aufsichtsbehörden (BAFIN, MAS, SEC).

Weil DevOps von der Branche unabhängig ist, kann es sinnvoll sein ebenso unabhängige Sicherheitsstandards zu nutzen. Dazu zählen diese:

• Die ISO (International Organization for Standardization) hat den Sicherheitsstandard ISO27001 (letzte Version von 2013) heraus gebracht welche als allgemeine Richtlinie zum Aufbau einer Organisation und somit auch DevOps verwendet werden kann.
• Die Organisation „Open Web Application Security Project“ (OWASP) stellt diverse Informationen bereit um Werkzeuge zur Source-Code Analyse zu bewerten. Weiterhin hat die OWASP eine Guideline zur Code Analyse heraus gebracht welche zur Softwareentwicklung im Rahmen von DevOps hilfreich sein kann.
• Das National Institute of Standards and Technology (NIST) aus den U.S. stellt mit seiner Special Publication SP 800-64 Schritte zur Integration von Sicherheitsaspekten in SDLC (Software Development Life Cycle) vor.

TRADITIONELLE SICHERHEITSMASSNAHMEN

Traditionelle Maßnahmen wie zum Beispiel Penetration Testing brauchen viel Zeit zur Durchführung und liefern lange Reports. Pen Testing scheint daher keine sinnvolle Sicherheitsmaßnahme für DevOps zu sein. Andere typische Maßnahmen wie der Einsatz von Web Application Firewalls prüfen Transaktionen inhaltlich zwischen End-User und Webanwendung bzw. Webanwendung und Datenbank. Auch diese Komponenten scheinen sich in DevOps Umgebungen mit kontinuierlicher Entwicklung bzw. sich permanent ändernder Konfigurationen nicht zu eignen. Die klassische (statische) Code Analyse braucht ebenfalls viel Zeit und widerspricht daher direkt der Anforderung an DevOps, nämlich der hochoptimierten Entwicklung von Software die zügig in die Produktion gebracht werden muss.

WIE FUNKTIONIERT DIE INTEGRATION?

Sicherheitsmaßnahmen nach links schieben

Betrachtet man die Kette von links nach rechts in folgender Reihenfolge: Design, Entwicklung (DEV), Integrations-Test (SIT), Installation, Abnahmetest (UAT) und Produktion (PRD), dann findet man in typischen Umgebungen ganz rechts die höchsten Sicherheitsanforderungen. Hier sind Webserver gehärtet, Datenbanken lassen keine Entwickler zu, SYS und SYSADMIN sind gelockt, Funktionen und Netzwerke sind getrennt. Die Abnahmeumgebung arbeitet z.T. mit Produktionsdaten während die Testumgebung nur mit synthetischen Daten arbeitet. Entwickler können ganz links selbständig Benutzer anlegen bzw. Rechte vergeben und haben häufig Root-Zugriff. Diese Rechte hat der Entwickler (und seine Software) in Produktion natürlich nicht mehr.

DevOps verlangt nun das die Entwicklungsumgebung und Produktionsumgebungen näher  zusammen rücken bzw. Code automatisiert „durchgeschoben“ werden kann. Daher müssen Sicherheitsanforderungen möglichst früh getestet werden. Testscripte müssen für jede Sicherheitsanwendung bzw. -funktion erstellt, abgenommen und automatisiert durchgeführt werden. Außerdem sollten Datenbanken möglichst früh bereits produktionsnahe Sicherheitsstandards aufzeigen. Sie sollten bereits eine ordentliche Rechtetrennung sowie Datenverschlüsselung erzwingen, sodass Entwickler direkt auf die Betriebsumgebung hinarbeiten können.

Trenne Sicherheitsfunktionen und Sicherheitskonfiguration vom restlichen Code auf jeder Plattform

Heutige Entwicklungsumgebungen oder Frameworks erlauben eine Trennung von systemabhängigen Properties und umgebungsabhängige Properties. Das ist allerdings nicht hinreichend! Schwieriger wird es eine weitere Trennung für sicherheitsrelevante Funktionen und Sicherheitskonfigurationen einzuführen. Einerseits muss die Integrität von einzelnen Benutzern und Ihren Funktionen sichergestellt werden. Andererseits ist ebenso die Vertraulichkeit der Informationen die einzelne Benutzer verarbeiten sicher zu stellen.

Je nach Software-Anwendung müssen sicherheitsrelevanten Bereiche zunächst identifiziert werden. Bei zum Beispiel einem Webmail-Service muss das Session-Management im Authentifikations-Schema dafür sorgen dass tatäschlich nur die zugelassenen Funktionen (wie z.B. Benutzer anlegen oder authentifizieren) aufgerufen werden können. Zur Wahrung der Vertraulichkeit muss hier beispielsweise sichergestellt werden dass ein Dispatcher im Application-Server für eine strikte Isolation von laufenden Anwendungen sorgt.

Wenn diese Trennung bereits auf der Testumgebung eingeführt wird, dann lassen sich unterschiedliche Secrets für verschiedene Plattformen leichter einrichten und insbesondere durch verschiedene Administratoren verwalten (separation of duties, need-to-know principle, least privilege).

SICHERHEIT IM SDLC

In DevOps Umgebungen wird der Software-Development-Life-Cycle extrem beschleunigt. Er kann durch die folgenden Sicherheits-Maßnahmen verbessert werden:

1. Sicherheit Planen
   1. 1. Identifiziere APIs und Frameworks die nicht abgesichert wurden.
   1. 1. Identifiziere sicherheitsrelevante Code-Teile (z.B.: Passwortchange, User-Authentication).
   1. Kalkuliere regulatorische Anforderungen früh mit ein.
2. Fordere Entwickler heraus
   1. Lade Entwickler zu Security-Konferenzen mit ein.
   2. Installiere Online-Plattformen wie Jive, Confluence.
   3. Führe regelmäßige Entwickler-Treffen ein bei denen erkannte Code-Verwundbarkeiten diskutiert und Gegenmaßnahmen vorgestellt werden.
3. Rüste Entwickler mit Sicherheits-Paketen aus
   1. Verwende sichere Frameworks (Spring Security).
   2. Führe Secure Code Analyse Tools zur Qualitätsanalyse ein. So liefern schon kleinsten Änderungen schnelle Antworten über Software-Sicherheit.
4. Automatisiere soviel wie möglich
   1. Integriere den Build.
   2. Stoppe den Build sobald Security Tests (SCA) fehl schlagen.
   3. Stelle wichtige Security-Services auch in SIT zur Verfügung (z.B. Security Logging, SSO, Crypto-Services wie HSM, PKI/CA).
   4. Protokolliere Zugriffe aufs Repository und erstelle Profil über Standardaktivitäten (->WAF).
   5. Exportiere regelmäßig User/Rollen von allen Systemen und lasse sie automatisch prüfen.
5. Nutze dennoch „alte“ Werkzeuge/Maßnahmen vernünftig
   1. Führe weiterhin Penetration Tests durch, baue Security-Tests in die Develop-Phase ein sowie zwischen der Deploy und Publish-To-Release-Repository Phase.
   2. Nutze WAF auf wichtigen Strecken wie z.B. zur Repository Datenbank.
   3. Erstelle Code Reviews für sicherheitsrelevante Code-Teile.
   4. Trenne Administrative Aufgaben bei Code-Deployment, Software-Testing, Security-Test-Scripte-Erstellung und -Prüfung, Rollen- und Benutzermanagement.
   5. Härte auch SIT-Umgebungen.
   6. Stärke Roll-Back Möglichkeiten im Change-Management durch Restore auf vorherige Checkpoints vom Repository nach PROD. Bei Fehlern in neuen Releases kann der Betrieb überfordert sein wenn schnell ein alter Softwarestand wieder hergestellt werden sollte. Dann hilft nur ein Roll-Back auf einen abgenommenen Stand.
   7. Datenbank-Restore auf alte Schemas muss möglich sein. Die zentrale Versionierung muss daher Datenbank-Checkpoints mit aufnehmen.
6. Setze langfristig auf Roll-Forwards
   1. Fehler dürfen die Produktion nicht lahmlegen. Mittelfristig sind Roll-Backs daher notwendig.
   2. Produktions-Fehler müssen zukünftig durch direkte Korrekturen der Entwickler im Sourecode behoben werden
7. Compliance Standards nachführen
   1. Überarbeite Sicherheits-Policies sodass auch DevOps Themen adressiert werden.
   2. Erstelle eine Policy für das Patching im SDLC auf DevOps. Es müssen jederzeit Versionierung und Zusammenhänge zwischen Microservices, Apps, Schnittstellen, Systemen, Datenbanken sowie der aktuellen Netzwerkkonfiguration (Firewall- und Router-Konfiguration) bekannt sein. Jeder Patch muss reversibel sein durch RCS/CVS rollback. Jede Change-Beschreibung muss das getestete Verfahren zum Rollback/Backout enthalten.
   3. Halte die Anforderungen an Security-Tests im SLDC in Handlungsanweisungen/Guidelines für Entwickler fest.

ZUSAMMENFASSUNG

DevOps soll die Agilität von IT-Betrieben und damit Time-to-Market massiv erhöhen. Neue Sicherheitsrisiken könnten die Stabilität der Anwendungen und damit den Erfolg eines Unternehmens negativ beeinflussen. Deshalb muss ein Umdenken bei Administratoren und Entwicklern erfolgen und Sicherheit direkt in die Produktionskette (SDLC) eingebaut werden.