DevOps Security Best Practices oder wie Uber 57 Millionen Benutzerkonten verlor

Best Practices für DevOps-Sicherheit

Sicherheit ist bei DevOps von größter Bedeutung. Laut Business Insider wurden im vergangenen Jahr in den USA über 1,2 Milliarden Benutzerkonten missbraucht. Infolgedessen versucht Facebook immer noch, seinen Ruf wiederherzustellen, und Google musste sein soziales Netzwerk Google Plus ganz abschalten. Diese Beispiele sollten für Unternehmen jeden Kalibers Ansporn genug sein, bewährte DevOps-Sicherheitsverfahren einzurichten und zu befolgen, um ein Fiasko zu vermeiden.

Warum kommt es zu DevOps-Sicherheitsfehlern? Wer sollte für sie verantwortlich sein? Was sind die Antworten auf diese DevOps-Sicherheitsherausforderungen? Und was noch wichtiger ist: Warum sollte Sie das interessieren? Wir beantworten diese und andere sicherheitsrelevante Fragen zu DevOps, damit Sie Ihren Kunden manipulationssichere Anwendungen bereitstellen können.

Offenlegung: In diesem Beitrag wird es nicht um DevSecOps gehen, denn DevSecOps ist ein unsinniges Schlagwort (sogar ohne eine eigene Seite auf Wikipedia), das lediglich für sicheres DevOps steht. Es ist nicht so, dass Sie zu Ihrem CEO kommen und ihn fragen können: “Chef, welche Art von Ops-Geschmack hätten Sie gerne? DevOps oder DevSecOps oder SecDevOps?” Die Antwort ist immer DevOps, und immer sicher.

Warum ist DevOps-Sicherheit ein Thema?

Lassen Sie uns kurz rekapitulieren, was DevOps ist - nur um sicherzustellen, dass wir auf derselben Seite stehen. Die Definition von DevOps des Softwaregiganten Amazon klingt ziemlich glaubwürdig:

DevOps ist die kollaborative Denkweise eines Projektteams sowie Tools zur Automatisierung von Entwicklung, Tests, Bereitstellung und Wartung digitaler Produkte.

Agil - Schnell

DevOps ist Teil von Agile - einem äußerst beliebten Softwareentwicklungsrahmen, der schnelle und häufige Entwicklungswiederholungen fördert und einen starken Schwerpunkt auf die Zusammenarbeit zwischen den Teammitgliedern legt. Einige Unternehmen liefern wöchentlich mehrere Updates für ihre digitalen Produkte, andere täglich. Unabhängig davon bleibt bei diesem hohen Tempo nicht viel Zeit für gründliche Tests. Und natürlich schleichen sich irgendwann Schwachstellen in solche Projekte ein.

Sicherheit - Langsam?

Es ist ein weit verbreiteter Irrglaube, dass mehr Sicherheitsprüfungen zu längeren Lieferzyklen und infolgedessen zu verpassten Terminen führen. Und obwohl niemand zusätzliche Verzögerungen bei seinen Projekten wünscht, kann der Schaden, den ein einziger Sicherheitsfehler anrichten kann, für ein Unternehmen, das die Sicherheit zugunsten der Agilität opfert, verheerend sein.

Im Jahr 2012 erfreute sich die soziale iOS-App Path großer Beliebtheit, bis jemand entdeckte, dass die App die Kontakte der Nutzer über ein unsicheres Protokoll und ohne Erlaubnis auf ihre Server hochlud. Infolgedessen gibt es die Path-App nicht mehr, obwohl sie zwei Millionen Nutzer hatte und der ganze Hype um ein lang erwartetes mobiles soziales Netzwerk nur für enge Freunde und Familie.

Open-Source & Container - beängstigend

Um die Entwicklung zu beschleunigen, nutzen DevOps-Teams möglicherweise Open-Source-Lösungen, die häufig keine Sicherheitstests durchlaufen. Selbst eine einzige Bibliothek oder eine Serverkomponente aus einer ungeprüften Quelle kann eine Kaskade von Fehlern verursachen und schließlich dazu führen, dass Ihr Dienst oder Produkt für Kunden nicht mehr verfügbar ist.

Container sind neben Open-Source-Code und -Tools ein weiterer unverzichtbarer Bestandteil eines modernen DevOps-Setups. Entwickler, Systemadministratoren und QA-Ingenieure verwenden Container, um ein Projekt fast sofort auf einer neuen Maschine verfügbar zu machen oder um zu einer früheren Entwicklungsversion eines Produkts zurückzukehren. Container bieten jedoch kaum Einblick in ihren Inhalt und werden häufig nur unzureichend gescannt. Ein Bericht von Threat Stack ergab, dass 94 Prozent der Befragten Container als Sicherheitsbedrohung ansehen.

Strategien zur Sicherung von DevOps

Alle an Bord holen

Unternehmen betreiben DevOps auf unterschiedliche Weise. Bei einigen übernehmen die Softwareentwickler alle Vorgänge nach der Codierung, z. B. das Erstellen, Testen und Bereitstellen von Anwendungen. Andere Unternehmen haben getrennte Entwicklungs- und Betriebsteams. Für eine sichere DevOps-Umgebung ist es jedoch am besten, alle Mitarbeiter an Bord zu holen, unabhängig davon, zu welcher Gruppe sie gehören. Unternehmen, die erfolgreich Sicherheitsrichtlinien für DevOps eingeführt haben, haben ganz oben angefangen - bei der Geschäftsleitung - und dabei auch ihre Rechts- und IT-Abteilungen aktiv in die Gespräche einbezogen.

Ausarbeitung einer präzisen Sicherheitsrichtlinie

Der Sinn einer Sicherheitsrichtlinie besteht darin, Ihr Team in die Lage zu versetzen, im Ernstfall schnell zu reagieren. Als Faustregel gilt, einen WISP (schriftlicher Informationssicherheitsplan) und einen DIRP (Reaktionsplan auf Datenvorfälle) zu erstellen, die kurz und klar genug sind, um im Bedarfsfall sofortige Maßnahmen zu ergreifen. Ein guter Ausgangspunkt ist die Common Weakness Enumeration - eine von der Gemeinschaft erstellte Liste allgemeiner Softwaresicherheitsschwächen. Eine vernünftige Richtlinie sollte auch sichere Codierungsmuster betonen, die keinen Platz für Angriffe lassen.

Schulen Sie Ihr Personal

Natürlich sollte jeder Projektmitarbeiter die Sicherheitsrichtlinien und -anforderungen je nach seiner Rolle kennen. Software-Ingenieure sollten beispielsweise vermeiden, Anmeldeinformationen aus Bequemlichkeit im Quellcode aufzubewahren, Mitglieder des QA-Teams benötigen nicht unbedingt Zugang zur Entwicklungsumgebung, und Systemadministratoren müssen unter anderem Firewalls richtig konfigurieren. Stellen Sie also sicher, dass Ihr Einführungsprozess die Sicherheitsgrundlagen abdeckt.

Automatisieren Sie DevOps-Sicherheitsprozesse und Tools

Bei DevOps ging es schon immer um Automatisierung. Die schnelle Veröffentlichung von Softwareprodukten erfordert ordnungsgemäß eingerichtete Pipelines für die kontinuierliche Integration (CI) und die kontinuierliche Bereitstellung (CD) - wenn neue Produktversionen automatisch kompiliert, geprüft und überwacht werden. Es ist von entscheidender Bedeutung, die automatische Sicherheitsüberprüfung in diese DevOps-Prozesse einzubeziehen.

Eine geschickt eingesetzte DevOps-Toolchain hilft Ihnen, anfälligen Code zu erkennen, bevor er die Produktionsumgebung erreicht. Eine solche Toolchain überwacht Ihr Produkt auch während der Test-, Integrations-, Bereitstellungs- und Veröffentlichungszyklen und liefert Ihnen Erkenntnisse über potenzielle Sicherheitsbedrohungen.

Übernehmen Sie die Kontrolle über das Privileged Access Management

Laut einer Studie von Beyond Trust ist etwa die Hälfte aller Sicherheitsverletzungen auf ein schlechtes Privileged Access Management (PAM) zurückzuführen. Dabei geht es nicht um einen Eindringling von außen, sondern um Teammitglieder mit guten Absichten, die mehr Zugriffsrechte haben, als sie sollten, oder die diese Rechte falsch verwalten. Die drei Schritte, die Unternehmen unternehmen können, um PAM unter Kontrolle zu bringen, sind folgende:

• Bestandsaufnahme der privilegierten Konten und Vermögenswerte

Eine DevOps-Umgebung kann manchmal sehr verwirrend sein. Dennoch müssen Sie sich die Mühe machen und alle privilegierten Benutzerkonten und alle Orte, auf die sie Zugriff haben, ausfindig machen.

• Verbieten Sie gemeinsam genutzte Konten und fest codierte Passwörter

DevOps-Ingenieure kodieren manchmal Anmeldeinformationen in einem Tool, das sie aus Bequemlichkeit verwenden, oder nutzen gemeinsam genutzte Konten, was die Prüfung erschwert.

• Umsetzung des Prinzips der geringsten Privilegien

Ein Konto mit dem Tool, das Metriken über Bugs in einer Testumgebung sammelt, braucht beispielsweise wahrscheinlich keinen Zugriff auf die Produktions- und Entwicklungsumgebung.

Einrichten eines Schwachstellenprogramms

Schwachstellenmanagement kann Ihnen dabei helfen, Ihre Produkte und Kunden zu schützen, indem Sie Ihre digitalen Ressourcen mit den Augen eines Hackers betrachten und anschließend Penetrationstests (oder einfach Pen-Tests) durchführen. Es gibt zwei Hauptvarianten von Pen-Tests, die von Unternehmen eingesetzt werden:

Externe Penetrationstests

Wenn ein Unternehmen nach Schwachstellen an seinem äußeren Verteidigungsperimeter sucht: Fehlkonfigurationen, Standardbenutzernamen und -kennwörter, ungepatchte Software, offene Ports usw.

Interne Penetrationstests

Wenn ein Unternehmen prüfen will, wie viel Schaden ein Hacker oder ein abtrünniger Mitarbeiter anrichten kann, wenn er bereits Zugriff auf das System hat. Können sie auf die unternehmenskritischen Teile Ihres Produkts, einschließlich der Kundendaten, zugreifen?

Aufteilung der DevOps-Umgebung in sichere Schichten

Die Logik der Anwendung und die Datenbank müssen nicht auf demselben Server liegen. Aus der Sicherheitsperspektive ist es sogar besser, getrennte Server zu betreiben und diese Elemente und andere DevOps-Assets in logischen Einheiten zu gruppieren, die sich standardmäßig nicht gegenseitig vertrauen. Fügen Sie einen Jump-Server mit Multi-Faktor-Authentifizierung und adaptiver Zugriffsberechtigung hinzu, um die Einheiten zu verbinden, und wenden Sie dann Sitzungen an - und schon sind Sie fertig. Wenn nun ein Hacker in ein Segment einbricht, bleibt zumindest der Rest der Einheiten sicher.

Ist Ihr DevOps sicher wie das von Uber oder Tesla?

Wenn Sie einen digitalen Service oder ein digitales Produkt verkaufen, sollte die DevOps-Sicherheit Ihre oberste Priorität sein. In dieser Hinsicht ist kein Unternehmen eine Ausnahme. Unternehmen wie Tesla und Uber scheinen groß und reif genug zu sein, um Opfer von Sicherheitsverletzungen zu werden. Doch bei Tesla nutzten Hacker die Server des Unternehmens, um eine Kryptowährung zu schürfen, und bei Uber wurden persönliche Daten von etwa 57 Millionen Kunden und Fahrern preisgegeben. Der Grund dafür ist in beiden Fällen falsch konfiguriertes DevOps.

Die gute Nachricht ist, dass man heute leicht viele Beratungs- und Entwicklungsfirmen finden kann, die Unternehmen dabei helfen können, ihre DevOps-Prozesse zu sichern, selbst wenn ein Unternehmen gerade erst mit der Einführung von DevOps beginnt. Kontaktieren Sie uns noch heute!