Blog
Lassen Sie sich nicht von der Sicherheit aufhalten

In meinem letzten Blog habe ich darüber geschrieben, wie AWS die Sicherheit in seinen Teams verankert. Jorge Liauw Calo forderte mich auf, etwas mehr über meine Sicherheitsvision zu erzählen. Warum also nicht einen weiteren Blogbeitrag schreiben ;-).
Einige Hintergrundinformationen: Ich arbeite seit 2009 mit AWS zusammen. Die meisten meiner Meinungen sind also durch den Input von AWS geprägt. Das ist nichts Schlechtes, denn im Allgemeinen leistet AWS großartige Arbeit bei der Entwicklung sicherer Dienste. Auf der AWS re:Invent 2022 habe ich auch das folgende Zitat gehört:
Vertrauen Sie, aber überprüfen Sie!
Ich denke, das fasst auch meine persönliche Auffassung von Sicherheit zusammen. Ich habe den Input von AWS mit meiner eigenen Erfahrung als Entwickler vermischt und mit meiner Beratungserfahrung abgerundet.
Blockiert werden
Traditionelle Sicherheitsabteilungen versuchen, den Entwicklungsteams alle Arten von Regeln und Frameworks entgegenzusetzen. Das Problem bei diesem Ansatz ist, dass es mehr Entwickler als Sicherheitsingenieure gibt. Das bedeutet, dass die Sicherheitsingenieure nicht die Zeit haben, die Entwickler anzuleiten. Das Endergebnis ist, dass Ihre Arbeit nicht in die Produktion gehen kann, weil die Sicherheit sie blockieren würde. Und um fair zu sein, sie haben gute Gründe dafür!
Es liegt im Interesse des Entwicklers, die Sicherheit in Ihren Anforderungen zu verankern. Auf der Grundlage dieser Anforderungen stellen Sie sicher, dass Sie den Sicherheitsaspekt in Ihren Entwurf einbeziehen. Danach können Sie Ihre Lösung immer noch mit Blick auf die Sicherheit entwickeln. Auf diese Weise verringern Sie nicht nur das Risiko, von einem Sicherheitsteam blockiert zu werden. Sie verhindern auch, dass Sie die Sicherheitsprobleme im Nachhinein beheben müssen. Der Aufwand für die Behebung bestimmter Sicherheitsprobleme ist höher, wenn Sie Ihre Lösung bereits erstellt haben, als während der Anforderungs- und Entwurfsphase derselben Lösung.
Sie sollten sich nicht auf die Kontrollmechanismen verlassen, die das Sicherheitsteam ablehnt. Sie müssen für sich selbst denken. Ihr Team weiß, was Ihre Lösung tut, und deshalb sind Sie der perfekte Kandidat, um sie zu sichern. Im Allgemeinen werden diese Kontrollen des Sicherheitsteams funktionieren, aber in bestimmten Fällen reichen sie nicht aus.

Sie können ein Schloss verwenden, aber Sie müssen es richtig einsetzen, um Wirkung zu erzielen!
Abhängigkeiten
Bei der Entwicklung Ihrer Lösungen werden Sie mit Abhängigkeiten konfrontiert. Diese Abhängigkeiten können Sicherheitslücken enthalten. Oft wird eine Sicherheitslücke zu einem heißen Thema und die Dringlichkeit steigt. Sie wird zu etwas, das JETZT behoben werden muss!
Wenn Sie über Tools zur Erkennung und Benachrichtigung verfügen, werden Sie in Zukunft weniger Probleme haben. So können Sie Prioritäten setzen, die Abhilfemaßnahmen planen und testen. Anstatt überstürzt eine Lösung zu finden und zu hoffen, dass nichts kaputt geht. Wenn so etwas passiert, geht es nicht nur um die Zeit, die Sie für die eigentliche Problemlösung aufwenden. Sie müssen auch Ihre Teams auf der Stelle mobilisieren. Dadurch werden sie aus ihrer aktuellen Aufgabe herausgerissen und verschwenden immer mehr Zeit.
Indem Sie den Entwicklern ermöglichen, ihre Abhängigkeiten proaktiv zu aktualisieren. Sie gewinnen die Kontrolle über diesen Prozess und werden weniger durch dringend erforderliche Korrekturen abgelenkt. Dies ist gut für die Moral des Teams und die Entwicklungsgeschwindigkeit.
Wenn Sie den Entwicklern zeigen, welchen Mehrwert sie davon haben. Es ist wahrscheinlicher, dass sie anfangen, diese Sicherheitsprinzipien zu übernehmen. Gleichzeitig verbessern Sie Ihre Sicherheitslage und erhöhen Ihre Entwicklungsgeschwindigkeit!
Fazit
Wenn Sie sich bereits in der Anforderungs- und Entwurfsphase auf die Sicherheit konzentrieren, sparen Sie in Zukunft Zeit! Diese Zeit können Sie nutzen, um neue Funktionen zu entwickeln, die Ihre Entwicklungsgeschwindigkeit erhöhen und gleichzeitig Ihre Sicherheitslage verbessern.
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.
Contact