Die rapide Zunahme hochwertiger Frameworks für die Anwendungsentwicklung stellt einen entscheidenden Vorteil für die Softwareindustrie weltweit dar. Die Erstellung von Anwendungen und die Schaffung von Mehrwert für Kunden sind einfacher denn je und können von überall auf der Welt aus durchgeführt werden. Bedauerlicherweise gilt dies gleichermaßen für Hacker, die die Anwendungen angreifen möchten. Die zunehmende Vernetzung von Software und die Speicherung wertvoller Daten weltweit machen diese Ziele für Hacker immer attraktiver. Die weniger gute Nachricht ist, dass es praktisch unmöglich ist, absolut sichere Anwendungen zu schreiben. Es ist leider unvermeidlich, dass sich Fehler einschleichen werden. Somit besteht die Möglichkeit, dass Angreifer diese Fehler finden und ausnutzen. Die gute Nachricht ist jedoch, dass Sie Ihre Anwendungen so gestalten können, dass der potenzielle Schaden durch diese Fehler möglichst gering ist. Die noch bessere Nachricht ist, dass sich sichere Anwendungen ganz einfach entwickeln lassen. Es gibt ein paar Grundregeln, die in der Anwendungsentwicklungsphase beachtet werden sollten. Dadurch kann verhindert werden, dass Angreifer alle Ihre wertvollen Daten erbeuten oder den gesamten Dienst lahmlegen.
Im Folgenden erläutern wir die grundlegenden Sicherheitsrichtlinien, die bei jeder Art von Software-Anwendung zu berücksichtigen sind. Die Einhaltung dieser Richtlinien ist von entscheidender Bedeutung, um die Sicherheit der Kunden zu gewährleisten.
1. Die geringste Privilegien
Ein wesentlicher Aspekt bei der Entwicklung sicherer Designs ist das Prinzip der geringsten Privilegien. Das Prinzip der geringsten Privilegien besagt, dass den Mitarbeitern nur der Zugang zu Informationen und Systemen gewährt wird, der für die Erfüllung ihrer Aufgaben erforderlich ist. Durch die Beschränkung von Konten auf die für ihre jeweilige Funktion erforderlichen Berechtigungen wird sichergestellt, dass ein potenzieller Angreifer, der ein Konto kompromittiert, nur auf ein Minimum an Informationen zugreift. Dadurch wird das Risiko eines Angriffs und etwaiger daraus resultierender Schäden begrenzt.
2. Aufgabentrennung
Der Gedanke der Aufgabentrennung basiert auf der Annahme, dass keine einzelne Rolle zu viele Befugnisse haben sollte. Dies unterscheidet sich vom Konzept der geringstmöglichen Privilegien (Least Privilege). Während der Fokus beim Prinzip der geringsten Privilegien darauf liegt, sicherzustellen, dass Personen nur die erforderlichen Berechtigungen für ihre Aufgaben haben, zielt dieser Ansatz darauf ab, sicherzustellen, dass die Aufgaben selbst nicht zu umfangreich sind. Wenn eine Person mit einer zu umfangreichen Aufgabe betraut wird, besteht die Gefahr, dass sie viele Berechtigungen benötigt, um diese Aufgabe zu erfüllen. Dies kann zu einer erhöhten Anfälligkeit für schlechte Entscheidungen führen.
3. Defense in Depth (Sicherheit in der Tiefe)
Während sich die Prinzipien der geringsten Privilegien und der Aufgabentrennung damit befassen, wie Menschen Zugang zum System erhalten, geht es bei Defense in Depth darum, den Zugang zum System zu verhindern. Die grundlegende Annahme bei Defense in Depth ist, dass jedes Sicherheitssystem, Schwachstellen aufweisen wird. Es mag sehr schwierig sein, Computersicherheitssysteme zu umgehen, aber es ist immer möglich. Ein Beispiel für die Umsetzung von Defense-in-Depth-Prinzipien ist die Verwendung von Sicherheitssoftware bei Servern für Softwaresysteme, die jedoch in einem einzigen Gebäude untergebracht sind. Ein Einbrecher hätte physischen Zugang zu jedem der Server. Eine ausgeklügelte Firewall oder Software zur Erkennung von Eindringlingen ist wertlos, wenn die physischen Sicherheitsvorkehrungen und Überwachungskameras in Rechenzentren nicht vorhanden sind. Die beste Firewall der Welt nützt nichts, wenn die physische Sicherheit vernachlässigt wird. Übertragen auf die Implementierung einer Anwendung sollten die Sicherheitsmechanismen auf mehreren Ebenen implementiert werden, um sicherzustellen, dass ein einzelner Sicherheitsfehler nicht zu einem vollständigen Kompromittieren der Anwendung führt.
4. Sicherheit beim Scheitern
Das Prinzip der Sicherheit beim Scheitern besagt, dass ein System auf Fehler oder Ausfälle so reagieren sollte, dass die Gesamtsicherheit der Anwendung gewahrt bleibt. Wenn etwas schiefgeht, muss das System in einen sicheren Zustand übergehen, anstatt Schwachstellen oder sensible Informationen preiszugeben.Das Prinzip umfasst die Implementierung robuster Fehlerbehandlungs- und Validierungsmechanismen in Ihrer gesamten Codebasis. Dadurch wird sichergestellt, dass jeder Fehler, sei es aufgrund einer ungültigen Benutzereingabe, eines Systemfehlers oder eines fehlgeschlagenen Authentifizierungsversuchs, zu einer allgemeinen Fehlermeldung führt und keine sensiblen Informationen oder Hinweise auf die interne Funktionsweise des Systems preisgibt
Ein wesentlicher Aspekt bei der Entwicklung sicherer Designs ist das Prinzip der geringsten Privilegien. Das Prinzip der geringsten Privilegien besagt, dass den Mitarbeitern nur der Zugang zu Informationen und Systemen gewährt wird, der für die Erfüllung ihrer Aufgaben erforderlich ist. Durch die Beschränkung von Konten auf die für ihre jeweilige Funktion erforderlichen Berechtigungen wird sichergestellt, dass ein potenzieller Angreifer, der ein Konto kompromittiert, nur auf ein Minimum an Informationen zugreift. Dadurch wird das Risiko eines Angriffs und etwaiger daraus resultierender Schäden begrenzt.
2. Aufgabentrennung
Der Gedanke der Aufgabentrennung basiert auf der Annahme, dass keine einzelne Rolle zu viele Befugnisse haben sollte. Dies unterscheidet sich vom Konzept der geringstmöglichen Privilegien (Least Privilege). Während der Fokus beim Prinzip der geringsten Privilegien darauf liegt, sicherzustellen, dass Personen nur die erforderlichen Berechtigungen für ihre Aufgaben haben, zielt dieser Ansatz darauf ab, sicherzustellen, dass die Aufgaben selbst nicht zu umfangreich sind. Wenn eine Person mit einer zu umfangreichen Aufgabe betraut wird, besteht die Gefahr, dass sie viele Berechtigungen benötigt, um diese Aufgabe zu erfüllen. Dies kann zu einer erhöhten Anfälligkeit für schlechte Entscheidungen führen.
3. Defense in Depth (Sicherheit in der Tiefe)
Während sich die Prinzipien der geringsten Privilegien und der Aufgabentrennung damit befassen, wie Menschen Zugang zum System erhalten, geht es bei Defense in Depth darum, den Zugang zum System zu verhindern. Die grundlegende Annahme bei Defense in Depth ist, dass jedes Sicherheitssystem, Schwachstellen aufweisen wird. Es mag sehr schwierig sein, Computersicherheitssysteme zu umgehen, aber es ist immer möglich. Ein Beispiel für die Umsetzung von Defense-in-Depth-Prinzipien ist die Verwendung von Sicherheitssoftware bei Servern für Softwaresysteme, die jedoch in einem einzigen Gebäude untergebracht sind. Ein Einbrecher hätte physischen Zugang zu jedem der Server. Eine ausgeklügelte Firewall oder Software zur Erkennung von Eindringlingen ist wertlos, wenn die physischen Sicherheitsvorkehrungen und Überwachungskameras in Rechenzentren nicht vorhanden sind. Die beste Firewall der Welt nützt nichts, wenn die physische Sicherheit vernachlässigt wird. Übertragen auf die Implementierung einer Anwendung sollten die Sicherheitsmechanismen auf mehreren Ebenen implementiert werden, um sicherzustellen, dass ein einzelner Sicherheitsfehler nicht zu einem vollständigen Kompromittieren der Anwendung führt.
4. Sicherheit beim Scheitern
Das Prinzip der Sicherheit beim Scheitern besagt, dass ein System auf Fehler oder Ausfälle so reagieren sollte, dass die Gesamtsicherheit der Anwendung gewahrt bleibt. Wenn etwas schiefgeht, muss das System in einen sicheren Zustand übergehen, anstatt Schwachstellen oder sensible Informationen preiszugeben.Das Prinzip umfasst die Implementierung robuster Fehlerbehandlungs- und Validierungsmechanismen in Ihrer gesamten Codebasis. Dadurch wird sichergestellt, dass jeder Fehler, sei es aufgrund einer ungültigen Benutzereingabe, eines Systemfehlers oder eines fehlgeschlagenen Authentifizierungsversuchs, zu einer allgemeinen Fehlermeldung führt und keine sensiblen Informationen oder Hinweise auf die interne Funktionsweise des Systems preisgibt. Nehmen wir als Beispiel einen Authentifizierungsprozess. Wenn ein Benutzer sich nicht anmelden kann, sollte das System keine Informationen preisgeben, die Rückschlüsse auf den Grund des Scheiterns zulassen. Stattdessen sollte es lediglich angeben, dass die Authentifizierung fehlgeschlagen ist.
5. Minimierung der Angriffsfläche
Die Angriffsfläche (Attack Surface Area, ASA) bezeichnet alle Punkte, an denen ein nicht autorisierter Benutzer mit einem System oder einer Anwendung interagieren kann. Das Ziel der Minimierung der ASA besteht in der Begrenzung dieser Einstiegspunkte, um die Die Angriffsfläche (Attack Surface Area, ASA) bezeichnet alle Punkte, an denen ein nicht autorisierter Benutzer mit einem System oder einer Anwendung interagieren kann. Das Ziel der Minimierung der ASA besteht in der Begrenzung dieser Einstiegspunkte, um die Möglichkeiten für Angreifer, Schwachstellen auszunutzen, zu verringern. Entwickler sollten die nicht unbedingt erforderlichen Code-Bestandteile, Dienste und Prozesse gewissenhaft prüfen und reduzieren. Bei der Serverkonfiguration sollten beispielsweise nur bestimmte notwendige Ports offen gelassen werden, während alle anderen sicher geschlossen oder blockiert werden sollten. Auch API-Endpunkte sollten mit Bedacht erstellt werden, und es sollten keine zu allgemeinen oder wild-card Endpunkte verwendet werden, die möglicherweise mehr Funktionen als beabsichtigt offenlegen. Ebenso wichtig ist es, ungenutzte oder veraltete Funktionen und Komponenten zu deaktivieren und zu entfernen.
6. Das offene Designs
Das Sicherheitsprinzip des offenen Designs besagt, dass die Implementierungsdetails des Entwurfs unabhängig vom Entwurf selbst sein sollten. Dadurch kann der Entwurf offen bleiben, während die Implementierung geheim gehalten werden kann. Dieses Prinzip steht im Das Sicherheitsprinzip des offenen Designs besagt, dass die Implementierungsdetails des Entwurfs unabhängig vom Entwurf selbst sein sollten. Dadurch kann der Entwurf offen bleiben, während die Implementierung geheim gehalten werden kann. Dieses Prinzip steht im Gegensatz zu “Security by Obscurity”, bei der die Sicherheit der Software von der Verschleierung des Entwurfs selbst abhängt. Bei der Entwicklung von Software nach dem Konzept des offenen Entwurfs wird eine Überprüfung des Entwurfs selbst ohne Beeinträchtigung der Sicherheitsvorkehrungen in der Software durchgeführt. Das Prinzip des offenen Designs basiert auf dem Kerckhoffschen Prinzip, wonach die Sicherheit eines kryptografischen Systems ausschließlich von der Geheimhaltung seiner Schlüssel abhängt. Alle anderen Aspekte, einschließlich des Algorithmus selbst, sollten als öffentliches Wissen betrachtet werden.
7. Complete Mediation (Vollständige Vermittlung)
Complete Mediation setzt voraus, dass jede Zugriffsanfrage auf eine Systemressource gründlich authentifiziert und autorisiert wird. Dies sollte jedes Mal und ohne Ausnahme geschehen
Complete Mediation setzt voraus, dass jede Zugriffsanfrage auf eine Systemressource gründlich authentifiziert und autorisiert wird. Dies sollte jedes Mal und ohne Ausnahme geschehen. Nehmen wir als Beispiel eine API in einer Microservice-Architektur. Selbst wenn ein Benutzer auf der Gateway-Ebene authentifiziert wurde, sollte jeder Microservice die Berechtigungen des Benutzers unabhängig validieren, bevor er eine Anforderung erfüllt. Dies könnte dadurch erreicht werden, dass für jeden API-Aufruf ein gültiges Authentifizierungs-Token verlangt wird, wobei der Microservice das Token dekodiert und die Berechtigungen des Benutzers anhand der angeforderten Aktion überprüft.
8. Der kleinste gemeinsame Mechanismus
Das Sicherheitsprinzip der am wenigsten gemeinsamen Mechanismen besagt, dass die gemeinsame Nutzung von Mechanismen, die mehreren Benutzern oder Prozessen zugewiesen sind, nicht zulässig ist, wenn die Benutzer oder Prozesse unterschiedliche Privilegienstufen haben. Dies ist eine wichtige Maßnahme zum Schutz gegen Privilegieneskalation.
9. Standardmäßige Sicherheit
Unter der Bezeichnung “Standardmäßig sicher” verstehen wir die sichersten Standardkonfigurationseinstellungen, die möglich sind. Diese Einstellungen sind jedoch nicht unbedingt die benutzerfreundlichsten. Das System ist so zu konfigurieren, dass nur die geringste Funktionalität zur Verfügung steht und die Verwendung aller anderen Funktionen, Ports, Protokolle und/oder Dienste ausdrücklich untersagt und/oder eingeschränkt wird. Die Standardeinstellungen sind entsprechend den besten Praktiken so restriktiv wie möglich zu konfigurieren, wobei die Nutzbarkeit und Verwaltbarkeit des Systems zu gewährleisten sind.
10. Keep it simple
Bei mehreren verfügbaren Implementierungen ist die einfachste und am leichtesten verständliche Lösung zu wählen. Die Wahrscheinlichkeit von Schwachstellen steigt mit der Komplexität der Software-Architektur und des Codes. Zudem nimmt die Wahrscheinlichkeit zu, wenn es schwierig ist, dem Code zu folgen oder ihn zu überprüfen. Um die Angriffsfläche der Software zu verringern, ist es empfehlenswert
Das Sicherheitsprinzip der am wenigsten gemeinsamen Mechanismen besagt, dass die gemeinsame Nutzung von Mechanismen, die mehreren Benutzern oder Prozessen zugewiesen sind, nicht zulässig ist, wenn die Benutzer oder Prozesse unterschiedliche Privilegienstufen haben. Dies ist eine wichtige Maßnahme zum Schutz gegen Privilegieneskalation.