Während der AWS re:Invent habe ich den SEC322: Transform builder velocity with security chalk talk besucht. Ich hätte Sie auf die Aufzeichnung auf YouTube verwiesen. Aber leider werden Chalk Talks nicht aufgezeichnet! Also müssen Sie sich stattdessen mit meiner Interpretation der Sitzung begnügen.
Der Titel der Sitzung lautete Transform builder velocity with security. Die meisten von Ihnen werden das Gefühl kennen, von der Sicherheit aufgehalten zu werden, wenn Sie mit Ihrer Anwendung in Betrieb gehen wollen. Wir neigen dazu, dem Sicherheitsteam an diesem Punkt die Schuld zu geben und zu sagen, dass es der Grund für die Verzögerung ist. Das Problem dabei ist, dass es sich stark auf Ihre Entwicklungsgeschwindigkeit auswirkt. Sie sind bereit für die Bereitstellung, können es aber nicht. Und es besteht das Risiko, dass Sie noch einmal von vorne anfangen müssen, weil Sie einen grundlegenden Fehler in Ihrem Entwurf gemacht haben.
Die Lösung scheint ganz einfach zu sein. Binden Sie die Sicherheit früher in den Prozess ein. Und ja, am Anfang wird dies funktionieren. Aber wenn Ihr Unternehmen zu wachsen beginnt, werden Sie Probleme mit der Skalierung Ihres Sicherheitsteams haben.
Wenn Sie also von Größe sprechen, könnten Sie AWS selbst als Beispiel nehmen. Sie haben viele Teams und scheinen gute Arbeit zu leisten. Und AWS hat immer gesagt, dass es in jedem Team einen Sicherheitsbeauftragten gibt. Aber ich habe nie gehört, wie sie das tatsächlich tun. Das hat sich in dieser Sitzung für mich geändert.
Wächter
In dieser Sitzung erklärten Collin Pace und Anya Khlobystina, dass jedes Team einen Wächter haben sollte. Der Guardian stellt dem Team alle relevanten Sicherheitsfragen. Er spielt also die Rolle des Sicherheitsbeauftragten im Team. Und woher kommt dieser Wächter? Nun, aus dem Team! Theoretisch kann jeder ein Wächter werden.
AWS verlässt sich auf den Ehrgeiz des Einzelnen, diese Rolle zu erfüllen. Der Grund dafür ist einfach. Wenn Sie jemanden haben, der die Aufgabe aus Ehrgeiz erledigen will, ist er engagierter als eine ernannte Person. Ehrgeizige Personen bringen den Funken mit, der sie antreibt, der sie motiviert, die beste Version ihrer selbst zu sein.
Diese Vormünder werden von anderen, älteren Vormündern unterstützt. Und es werden Schulungen angeboten, um die Vormünder auf ihrem Weg zu unterstützen.
Die Idee, diese Wächter in den eigentlichen Teams zu haben, besteht darin, potenzielle Sicherheitsprobleme so früh wie möglich zu erkennen. In der Entwurfsphase, aber auch in allen nachfolgenden Schritten. Sie kennen den Workload, den sie erstellen, und wissen daher am besten, warum und wie der Workload erstellt wird.
Widersprüchliche Interessen
Wie in jedem Unternehmen kann es also zu einem Konflikt zwischen dem Sicherheitsteam und einem Produktverantwortlichen kommen, der das Produkt ausliefern möchte.
Bei der Arbeit mit Vormündern geht diese Aufgabe auf den Vormund über. Aber ein Wächter kann immer das Sicherheitsteam bitten, zu bestätigen, dass die Bedenken berechtigt sind. Der einzige Unterschied besteht darin, dass Sie sich noch in der Entwurfsphase oder in der Implementierungsphase befinden. Sie sind noch nicht bereit für die Produktion, das ist ein großer Unterschied!
Das Team wird nicht gestoppt, es wird nur ein bestimmter Bereich diskutiert. So kann der Rest des Teams weiterhin dafür sorgen, dass Sie für eine Veröffentlichung bereit sind.
Fazit
Mit dem Einsatz von Wächtern verankern Sie die Rolle der Sicherheit in Ihren Teams. So können Sie schneller auf potenzielle Sicherheitsrisiken reagieren. Und verhindern, dass sie überhaupt erst entstehen.
Die Zeit, die Sie sparen, nutzen Sie, um Ihr Arbeitspensum zu steigern. Und das erhöht die Geschwindigkeit, mit der Sie bauen!
Foto von cottonbro studio
Verfasst von

Joris Conijn
Joris is the AWS Practise CTO of the Xebia Cloud service line and has been working with the AWS cloud since 2009 and focussing on building event-driven architectures. While working with the cloud from (almost) the start, he has seen most of the services being launched. Joris strongly believes in automation and infrastructure as code and is open to learning new things and experimenting with them because that is the way to learn and grow.
Unsere Ideen
Weitere Blogs
Contact




