IaC-Scannen: Eine fantastische, übersehene Lernmöglichkeit

Alles, was Sie über Infrastruktur als Code (IaC) lesen, konzentriert sich darauf, wie sie funktioniert oder warum Sie sicherstellen möchten, dass sie tatsächlich so erstellt wird, wie Sie es möchten.

Dies sind kritische Bereiche. Aber denken wir genug darüber nach, wie wir diesen Ansatz in unserer Organisation anwenden?

As Melinda Marken von ESG stellt in einem Unternehmensbericht fest, dass „83 % der Organisationen eine Zunahme von IaC-Vorlagen-Fehlkonfigurationen erlebten“, während sie die Technologie weiter einführten.

Wir wissen aus der Arbeit der Cloud Security Alliance („Top-Bedrohungen für Cloud Computing: Egregious Eleven“) und anderen sind Fehlkonfigurationen weiterhin ein Top-Risiko in der Cloud.

IaC wird unterstützt Veteran
Fehlkonfigurationen durch Systematisierung der Infrastrukturerstellung, Hinzufügen einer Strenge und eines Prozesses, der sicherstellt, dass Teams das bauen, was sie wollen, und nur das, was sie wollen. Wenn ~83 % der Teams das nicht sehen, liegt ein tieferes Problem vor.

In kleineren Teams, in denen die Dev- und Ops-Teile der DevOps-Philosophie zusammenkommen, ist das sinnvoll. IaC ermöglicht es diesen kleinen Teams, dieselbe Sprache – Code – zu verwenden, um alles zu beschreiben, was sie tun.

Aus diesem Grund sehen wir Abstraktionen auf noch höherer Ebene als Tools wie Terraform oder AWS CloudFormation in der AWS-CDK und Projekte wie cdk8s. Diese High-Level-Abstraktionen sind für Entwickler komfortabler.

Die Ops/SRE/Plattform-Perspektive eines Cloud-Dienstes unterscheidet sich stark von der Entwicklerperspektive desselben Dienstes. Ein Entwickler wird sich einen Warteschlangendienst ansehen und in seine Benutzeroberfläche eintauchen – ein einfacher Endpunkt zum Hinzufügen und einer zum Lesen? Verkauft. Das ist eine einfache Integration.

Diese operative Perspektive zielt darauf ab, die Kanten zu finden. Wann erreicht diese Warteschlange also ihr Limit? Ist die Leistung konstant oder ändert sie sich unter Last radikal?

Ja, es gibt sich überschneidende Bedenken. Und ja, das ist eine vereinfachte Ansicht. Aber die Idee hält. IaC löst viele Probleme, kann aber auch die Trennung zwischen Teams erzeugen und verstärken. Noch wichtiger ist, dass es die Lücke zwischen der Absicht dessen, was Sie zu bauen versuchen, und der Realität dessen, was Sie gebaut haben, hervorheben kann.

Infolgedessen eskalieren hier häufig die Sicherheitsbedenken.

Die meisten Tools – kommerziell oder Open Source – konzentrieren sich darauf, Dinge zu identifizieren, die mit den Infrastrukturvorlagen nicht in Ordnung sind. Dieser
ist ein gutes Konstrukt. Herstellung fehlen uns die Worte.
wäre schlecht. Diese Tools zielen darauf ab, diese Ergebnisse als Teil der Continuous Integration/Continuous Delivery (CI/CD)-Pipeline zu generieren.

Das ist ein toller Anfang. Aber es gibt dasselbe Sprachproblem wieder.

Wer spricht und wer hört zu?

Wenn ein IaC-Tool ein Problem hervorhebt, wer wird es angehen? Wenn es das Entwicklungsteam ist, hat es genügend Informationen, um zu wissen, warum dies als Problem gekennzeichnet wurde? Falls es sich um das Betriebsteam handelt, sind die Folgen des Problems im Bericht dargelegt?

Für Entwickler passiert es oft, dass sie einfach die Konfiguration anpassen, damit der IaC-Test bestanden wird.

Für den Betrieb geht es in der Regel darum, ob die Tests bestanden werden. Wenn ja, dann weiter zur nächsten Aufgabe. Das ist kein Schlag für beide Teams; vielmehr hebt es die Kluft zwischen Erwartungen und Realität hervor.

Was benötigt wird, ist Kontext. IaC-Sicherheitstools bieten Einblick in das, was (hoffentlich) gebaut wird. Das Ziel ist es, Probleme zu stoppen Bevor Sie gehen in die Produktion.

Die heutigen IaC-Sicherheitstools heben echte Probleme hervor, die angegangen werden müssen. Die Ausgabe dieser Tools zu nehmen und sie mit zusätzlichem Kontext anzureichern, der für das für den Code verantwortliche Team spezifisch ist, ist eine perfekte Gelegenheit für eine benutzerdefinierte Automatisierung.

Dies wird auch dazu beitragen, die sprachliche Kluft zu überbrücken. Die Ausgabe Ihrer Tools erfolgt im Wesentlichen in einer dritten Sprache – nur um die Dinge komplizierter zu machen – und muss auf eine Weise kommuniziert werden, die entweder einem Entwicklungs- oder einem Betriebspublikum Sinn macht. Oft beides.

Wenn ein Scan beispielsweise anzeigt, dass eine Sicherheitsgruppenregel keine Beschreibung hat, warum spielt das eine Rolle? Nur eine Benachrichtigung zu erhalten, die besagt: „Beschreibung für den Kontext hinzufügen“, hilft niemandem, besser zu bauen.

Diese Art von Flag ist eine großartige Gelegenheit, die Teams zu schulen, die in der Cloud arbeiten. Das Hinzufügen einer Erklärung, dass Sicherheitsgruppenregeln so spezifisch wie möglich sein sollten, verringert die Gelegenheit für böswillige Angriffe. Geben Sie Referenzen zu Beispielen für strenge Regeln an. Rufen Sie das aus, ohne die Absicht zu kennen, und andere Teams können die Gültigkeit der Sicherheitsbestätigung nicht testen.

Sicherheit liegt in der Verantwortung aller. Wenn Sie also die Sprachlücke zwischen Entwicklern und Betriebsabläufen anerkennen, werden Möglichkeiten wie diese hervorgehoben, um einfache Automatisierungen hinzuzufügen, die Ihren Teams Einblicke bieten. Dies wird dazu beitragen, das zu verbessern, was sie aufbauen, und als Ergebnis bessere Sicherheitsergebnisse erzielen.

Über den Autor

Ich bin Forensiker, Redner und Technologieanalyst und versuche, Ihnen dabei zu helfen, die digitale Welt und ihre Auswirkungen auf uns zu verstehen. Für alltägliche Benutzer hilft meine Arbeit, die Herausforderungen der digitalen Welt zu erklären. Wie stark wirkt sich die Nutzung sozialer Medien auf Ihre Privatsphäre aus? Was bedeutet es, wenn Technologien wie die Gesichtserkennung in unseren Gemeinden eingesetzt werden? Ich helfe, Fragen wie diese und mehr zu beantworten. Für Menschen, die Technologie entwickeln, helfe ich ihnen, ihre Arbeit mit einem Sicherheits- und Datenschutzobjektiv zu versehen, damit sie Benutzern ermöglichen können, klarere Entscheidungen über ihre Informationen und ihr Verhalten zu treffen. Es gibt einen Berg an Verwirrung, wenn es um Privatsphäre und Sicherheit geht. Das sollte es nicht geben. Ich mache Sicherheit und Datenschutz verständlicher.