Funktion als (sichererer) Dienst
Es gibt mehrere moderne Ansätze zur Application und -entwicklung, die im Wesentlichen nach dem Motto „Mach es kleiner und damit effizienter“ aussehen.
Sowohl Microservices als auch Function as a Service (FaaS) basieren auf dem Konzept eines hochfokussierten Codes. Auch wenn die meisten Unternehmen applications nicht in Hunderte von Microservices oder Tausende von Funktionen zerlegen, tendieren sie dennoch zu diesem Design. Der Grund hierfür liegt häufig darin, dass dadurch die agile Entwicklung erleichtert wird, weil ein relativ kleines Team einen Dienst viel schneller entwerfen, entwickeln und verfeinern kann als eine große, monolithische Application. Schließlich ist es viel einfacher, etwas mit 1.000 Codezeilen zu schreiben und zu testen, als eine größere Application mit 100.000 Codezeilen.
Aber es gibt noch einen weiteren interessanten Vorteil von Microservices und FaaS, der nicht so sehr angepriesen wird, wie er sollte: Sicherheit.
Es gibt im Internet zahlreiche Diskussionen – und ich habe eine ganze Reihe davon gelesen – in denen versucht wird, die „branchenübliche“ Defekt- und Schwachstellendichte festzulegen. Sie werden eine große Bandbreite an Schätzungen finden, von denen einige auf tatsächlichen Scans von Open- Quellcode und andere auf selbst gemeldeten Zahlen beruhen. Die NASA beispielsweise hat stolz die extrem niedrige Defektdichte dieser Bauteile als einen der Gründe für den Erfolg des Space-Shuttle-Programms angepriesen. Es gibt auch Berichte, die auf objektiv gesammelten Daten von Sicherheitsfirmen wie WhiteHat basieren. Die Zahlen konzentrieren sich jedoch auf die Schwachstellen pro Application und nicht unbedingt pro Codezeilen.
Es besteht kein wirklicher Konsens über die Defekt- und Schwachstellendichte, außer dass man sich einig ist, dass tatsächlich eine solche vorliegt.
Es liegt jedoch auf der Hand, dass die Wahrscheinlichkeit einer Einführung von Fehlern und Schwachstellen umso geringer ist, je weniger Codezeilen Sie schreiben. Und was ebenso wichtig ist: Je weniger Codezeilen Sie durchsuchen müssen, um eine Schwachstelle oder einen Defekt zu finden, desto schneller werden Sie ihn finden und vermutlich auch beheben.
Einer der Gründe dafür ist der Umfang. Wenn mein Microservice oder meine Funktion auf die Kodifizierung eines Aspekts der Geschäftslogik ausgerichtet ist, sind für die Implementierung weniger Logik und weniger Bibliotheken erforderlich. Dieser kleinere Umfang bedeutet eine geringere Wahrscheinlichkeit für die Einführung von Logikfehlern oder Sicherheitslücken in Bibliotheken (von Drittanbietern oder anderen), die zur Implementierung dieser zusätzlichen Logik erforderlich sind. Jedes Mal, wenn Sie eine weitere Komponente einbinden oder einen anderen Dienst aufrufen müssen, besteht die Gefahr von Fehlern und Schwachstellen.
Auch weniger Schnittstellen zur Funktion oder zum Microservice tragen zu sichererem Code bei. Jede Schnittstelle (ein Einstiegspunkt wie ein API-Aufruf) birgt die Möglichkeit einer Sicherheitslücke, da Sie Benutzereingaben verarbeiten. Und Benutzereingaben sollten, wie wir alle wissen, immer als verdächtig und potenziell böswillig behandelt werden .
Und wenn Microservices das Potenzial für Schwachstellen und Mängel verringern, sollte eine noch stärkere Reduzierung des Umfangs auf eine Funktion diese Möglichkeit noch weiter verringern.
Dies bedeutet jedoch nicht, dass Microservices und FaaS grundsätzlich sicherer sind als ihre dreistufigen und monolithischen Gegenstücke. Schlampiger Code bleibt schlampiger Code, egal, wie viele Zeilen er umfasst. Es stimmt jedoch, dass sich beide Architekturen für Entwicklungs- und Bereitstellungspraktiken eignen, die zu sichererem Code führen können.
Wenn Sie bei der Bewertung oder Implementierung von Microservices und/oder FaaS die Sicherheitsvorteile im Hinterkopf behalten, können Sie tatsächlich ein Aufblähen des Codes verhindern und sich vor der Einführung von Schwachstellen schützen.