Webanwendungen waren eine bahnbrechende Neuerung, da sie die Möglichkeit boten, Anwendungen einmal zu bauen und dann überall zur Verfügung zu stellen. Dies hatte jedoch den Nachteil, dass Ihre Anwendung nun auch einmal gebaut und dann von überall aus gehackt werden konnte. Solange sie online war, hatte auch ein Hacker auf der anderen Seite des Planeten Zugriff darauf und konnte sie hacken.
Das lag daran, dass Webanwendungen, genau wie Oger, Schichten hatten. In dieser Serie werden wir einige dieser Schichten aufdecken und darüber sprechen, wie man sie schützen kann. Webanwendungen haben viele Angriffsflächen, von den Anwendungen selbst bis hin zur Infrastruktur, auf der sie laufen. Deshalb braucht Websicherheit ebenfalls einen mehrschichtigen Ansatz.
Webanwendungssicherheit umfasst die Erkennung und Abwehr von Cyberangriffen auf Webanwendungen. Dazu gehört die Sicherung der Anwendungen sowie der Infrastruktur, auf der sie ausgeführt werden.
Webanwendungen existieren auf mehreren Schichten, was bedeutet, dass sie zahlreiche Angriffsvektoren haben. Ihr Ansatz für deren Sicherheit sollte dies berücksichtigen. Es gibt keine festgelegte Definition der Schichten, aber wir können sie grob wie folgt unterteilen
Beide haben jeweils eigene Schichten, d. h.
Das sind eine Menge Schichten, und wenn man genauer hinschaut, haben einige davon noch eigene Schichten, was zu einer riesigen Angriffsfläche führt. Wie verteidigen wir eine so große Fläche? Indem wir Verteidigungsschichten hinzufügen, die den Angriffsbereich auf ein überschaubares Maß reduzieren.
Die Herausforderung besteht darin, die richtige Balance zwischen zu viel und zu wenig zu finden, denn mit jeder zusätzlichen Verteidigungsschicht erhöht sich auch die Gesamtkomplexität des Systems. Das Ziel ist es, Sicherheit bereits bei der Konzeption zu berücksichtigen und sicherzustellen, dass Ihre Anwendung von Grund auf sicher ist.
In diesem Beitrag konzentrieren wir uns hauptsächlich auf die Infrastruktur und werden im nächsten Beitrag über die eigentliche Webanwendung sprechen. Um die Sache verständlicher zu machen und weil mir außer dieser ersten keine weiteren Oger-Analogien einfallen, werden wir ein anderes anschauliches Beispiel verwenden, nämlich die Architektur des 10. Jahrhunderts. Eine Webanwendung ist wie eine Burg, und was Sie schützen, ist das Gold im Inneren der Burg. Es gibt viele Wege, Ihren Schatz vor Plünderern zu verteidigen, aber nicht alle sind gleichwertig.
Sprechen wir über unsere Burg. Wenn Sie Ihren Schatz schützen wollen, bauen Sie Ihre Burg nicht in einem Sumpf, es sei denn, Sie möchten, dass sie zweimal versinkt und abbrennt, bevor sie ihren Zweck erfüllt, ganz wie bei Monty Python. Stattdessen bauen Sie sie auf verteidigungsfähigem, festem Terrain. Auf diese Weise arbeitet das Terrain für und nicht gegen Sie.
In der Webanwendungssicherheit bedeutet dies, dass wir, bevor wir eine einzige Zeile Code schreiben, überlegen, wo wir die Anwendung einsetzen werden und wie sicher diese Umgebung ist.
Lassen Sie uns zunächst Ihr gewähltes Betriebssystem und Ihre Servertechnologien betrachten. So wie eine alte, baufällige Burg zu einer Belagerung einlädt, lädt ein nicht gewarteter Tech-Stack zu Cyberangriffen ein. Stellen Sie immer sicher, dass Ihr Betriebssystem und Ihre Kerntechnologien auf dem neuesten Stand sind, und entscheiden Sie sich nach Möglichkeit für Long-Term-Support-Versionen (LTS), um kontinuierliche Sicherheitsupdates zu gewährleisten.
Dank PaaS-Anbietern (Platform as a Service), die den Großteil davon für Sie übernehmen, ist das Leben einfacher geworden. Es ist jedoch immer noch sinnvoll, dies zu überprüfen. Wenn Sie Dienste nutzen, bei denen Sie eine Version festlegen können, wählen Sie eine LTS-Version aus. Die Dienstanbieter aktualisieren diese in der Regel für Sie.
Und wenn wir schon beim Thema Kerntechnologien sind: Denken Sie daran, dass es besser ist, keine zu haben, als eine, die nicht gewartet wird.
Wo würden Sie Ihre Goldberge lieber aufbewahren? In einem losen Haufen im Hof neben dem Tor oder in einem verschlossenen Raum tief im Inneren der Burg? Die Datenbanksicherheit verdient besondere Aufmerksamkeit. Sensible Daten wie Kreditkarteninformationen sollten beispielsweise durch Verschlüsselung oder Speicherung in einer separaten Datenbank geschützt werden.
Eine weitere Möglichkeit, Ihre Daten zu schützen, besteht darin, ihre Integrität sicherzustellen. Datenintegrität bedeutet, die Genauigkeit und Konsistenz von Daten zu gewährleisten, indem unbefugte Änderungen verhindert werden und sichergestellt wird, dass die Daten während ihres gesamten Lebenszyklus unverändert bleiben. In unserem Burgbeispiel können Sie sich dies wie eine Gästeliste vorstellen. Wenn Lord Farquaad ausgeladen wurde, möchten Sie doch nicht, dass seine Begleitperson trotzdem in die Burg kommt, oder? In diesem Fall sollte die Ausladung von Lord Farquaad automatisch auch die Ausladung seiner Begleitperson zur Folge haben. In Datenbanken verwenden Sie dazu Constraints, d. h. wenn ein Datensatz gelöscht wird, werden auch alle anderen Datensätze, die davon abhängen, gelöscht.
Genauso wie nicht nur Plünderer hinter Ihrem Gold her sind, sondern auch gierige Verwalter, sollten Sie auch auf Insider-Bedrohungen für Ihre Daten achten. Sie müssen Maßnahmen ergreifen, um unbefugten Zugriff oder Missbrauch von Daten durch Mitarbeiter sowie andere Insider zu verhindern.
Eine Möglichkeit ist die Anwendung des Prinzips der minimalen Berechtigungen. Dabei gewähren Sie Benutzern nur die Berechtigungen, die für die Ausführung ihrer vorgesehenen Funktionen unbedingt erforderlich sind. Eine weitere Möglichkeit besteht darin, diese Berechtigungen regelmäßig zu überprüfen, um festzustellen, ob sie noch benötigt werden. Wenn nicht, entfernen Sie diese. Eine weitere Möglichkeit ist die Hinzufügung von Zugriffsrechten auf Zeilen- und Spaltenebene für Ihre Daten, aber beachten Sie, dass dies zusätzliche Komplexität mit sich bringt.
Es gibt noch weitere Maßnahmen, die Sie ergreifen können, wie z. B. den Einsatz von Data Loss Prevention (DLP)-Lösungen, aber das würde für diesen Beitrag zu sehr in den Bereich der IT-Richtlinien gehen. In diesem Zusammenhang empfiehlt es sich jedoch, eine IT-Sicherheitsrichtlinie zu haben.
In „Der Herr der Ringe: Die zwei Türme“ wurde die große Festung Helms Klamm durchbrochen, als die Orks eine winzige, ungesicherte Rinne ausnutzten. Genauso kann auch Ihre CI/CD-Pipeline Sicherheitslücken verursachen. CI/CD wird verwendet, um die Bereitstellung Ihrer Anwendung zu automatisieren. Daher ist es hier besonders wichtig, sicherzustellen, dass es böswilligen Akteuren nicht leicht gemacht wird, schädlichen Code direkt in Ihr Produktionssystem einzuschleusen.
Zu wissen, was Sie entwickeln, ist ebenso wichtig für die Sicherheit wie zu wissen, wer einen Build auslöst. Angemessene Zugriffskontrollen sind ebenso unerlässlich wie die Überprüfung der Integrität aller Artefakte. Außerdem sollten Sie vor dem Auslösen der Produktionsbereitstellung eine manuelle Genehmigung und Überprüfung verlangen.
Die Konfiguration ist ebenfalls wichtig, denn wenn Sie Ihre Pipeline falsch konfigurieren, werden Geheimnisse schneller preisgegeben, als die Pipeline ausgeführt werden kann. Beispielsweise können Sicherheitsschlüssel, die in Variablen oder im Code gespeichert sind, bei der Ausführung der Pipeline protokolliert werden. Das ist schlecht, wenn Sie an einem Open-Source-Projekt arbeiten, bei dem die Protokolle öffentlich zugänglich sind, aber selbst in privaten Repositorys haben die Mitarbeiter Ihrer Pipeline-Anbieter Zugriff auf diese Protokolle, und Sie möchten wahrscheinlich auch nicht, dass sie Ihre Schlüssel erhalten.
Wie können wir das erreichen? Nun, zunächst einmal speichern Sie Geheimnisse nicht in Code oder lokalen Variablen, sondern als Umgebungsvariablen. Wenn Ihre Plattform dies zulässt, sollten Sie auch einen Secret-Manager verwenden. Auf diese Weise werden Geheimnisse vor der Speicherung verschlüsselt, bei Bedarf in Ihrer Pipeline automatisch entschlüsselt und in der Regel aus den Protokollen entfernt.
Das Prinzip der minimalen Berechtigungen gilt auch für Geheimnisse in Ihrer Pipeline. Die Prozesse sollten gerade so viele Berechtigungen haben, wie für die Ausführung der erforderlichen Aufgaben erforderlich sind, und nicht mehr.
Nehmen Sie Ihre Pipeline ernst.
Firewalls und Intrusion Detection/Prevention-Systeme (IDS/IPS) fungieren als vorderste Verteidigungslinie Ihrer digitalen Burg. Firewalls halten unerwünschte Besucher fern, während IDS/IPS aktiv nach Bedrohungen suchen und diese neutralisieren, bevor sie eindringen können.
In unserer Burg-Analogie wäre die Firewall also die eigentliche Mauer und IDS/IPS die Wachen, die aktiv überprüfen, dass keine unerwünschten Personen eindringen und Probleme verursachen.
Nicht alle Hackerangriffe zielen jedoch darauf ab, etwas zu entwenden. Eine andere Art von Angriff ist der "Distributed Denial of Service (DDoS)". Dabei überfluten Hacker Ihre Anwendung mit Anfragen, um Ihr System zu überlasten, sodass es keine legitimen Anfragen mehr bearbeiten kann.
Stellen Sie sich das wie eine riesige, wütende Menschenmenge vor, die sich vor den Toren drängt und Beleidigungen brüllt. Sie versuchen nicht, hineinzukommen, aber sie blockieren den Eingang, sodass auch die Händler, die Lebensmittel bringen, nicht hineinkommen können.
Load Balancing kann diese Belastung verringern, indem es eingehende Anfragen auf mehrere Server verteilt. Das ist so, als würden Ihre Wachen den Händlern sagen, sie sollen ein anderes Tor benutzen, wenn das eine überfüllt ist.
Wenn ich über Load Balancing spreche, sollte ich auch Content Delivery Networks (CDNs) erwähnen. CDNs verteilen Inhalte auf mehrere Server, wodurch die Belastung für jeden einzelnen Server reduziert wird und es für Angreifer schwieriger wird, das Ziel zu überlasten.
Das klingt ähnlich, aber im Allgemeinen verteilt Load Balancing den Datenverkehr auf eine Gruppe von Servern, oft innerhalb eines bestimmten Rechenzentrums, während CDNs Inhalte an verschiedenen geografischen Standorten, z. B. in verschiedenen Städten oder Ländern, verteilen.
Es ist zwar gut, die Last zu verteilen, aber Sie können auch begrenzen, wie oft bestimmte IP-Adressen auf die Anwendung zugreifen.
Keine der oben genannten Lösungen kann einen DDoS-Angriff allein abwehren, aber in Kombination sollten Sie ihn überstehen können.
In extremen Fällen können Sie Ihre Firewall auch so konfigurieren, dass sie Blackholing-Anfragen startet. Blackholing ist eine Gegenmaßnahme zur Abschwächung eines Angriffs, bei der der Netzwerkverkehr auf der Grundlage strenger Anforderungen abgelehnt wird. Dies hat den Nachteil, dass bei falschen Anforderungen auch legitime Anfragen betroffen sind, weshalb ich denke, dass diese Maßnahme nur als letztes Mittel eingesetzt werden sollte.
Es ist eine Tatsache, dass man nie genug Zeit oder Budget hat, um alles zu tun, was man tun möchte. Aber Systeme müssen dennoch gesichert werden, daher müssen Sie das Beste aus der Ihnen zur Verfügung stehenden Zeit und Ihrem Budget machen. Lassen Sie uns über einige allgemeine Dinge sprechen, die zwar keine Schichten im eigentlichen Sinne sind, aber dazu beitragen, Ihre Anwendung sicherer zu machen.
Sie können zusätzliche Sicherheitsschichten hinzufügen, aber meiner Erfahrung nach ist das nicht immer der beste Ansatz. Zusätzliche Sicherheitsschichten erhöhen auch die Komplexität Ihres Systems und können zusätzliche Schwachstellen mit sich bringen. Je komplexer Ihr System ist, desto größer ist die Wahrscheinlichkeit, dass Sie etwas übersehen, und je mehr Schichten Sie hinzufügen, desto mehr verlieren Sie den Überblick.
Das Hinzufügen zusätzlicher Schichten hat auch seinen Preis, entweder in Form von Komplexität oder Kosten. Eine externe Firewall von einem namhaften Anbieter kann ein Vermögen kosten, während die Einführung einer kostenlosen Firewall Sie Zeit kostet.
Ein gut überwachtes System kann Bedrohungen erkennen, bevor sie eskalieren. Detaillierte Protokollierung sorgt dafür, dass Sie im schlimmsten Fall genau nachvollziehen können, wie es dazu gekommen ist, und verhindert, dass sich so etwas in Zukunft wiederholt. Denn wenn Sie eines Tages aufwachen und die Hälfte Ihres Schatzes verschwunden ist, möchten Sie wissen, wer ihn gestohlen hat und wie. Wenn Sie das nicht schnell herausfinden, könnte der Dieb morgen Nacht zurückkommen und den Rest mitnehmen.
Ihre Protokolle sollten idealerweise niemals auf demselben Server verbleiben, auf dem Ihre Webanwendung gehostet wird. Denn wenn jemand Zugriff auf den Server erhält, ist es ein Leichtes, seine Spuren zu verwischen.
Wie bei allen guten Dingen gibt es auch hier ein Zuviel und ein Zuwenig. Wenn Sie zu wenig protokollieren, riskieren Sie, wichtige Informationen zu verpassen, weil sie nicht protokolliert wurden. Wenn Sie zu viel protokollieren, wird es aufgrund der Informationsflut fast unmöglich, die Ursache zu finden. Sie müssen die perfekte Balance zwischen zu wenig und zu viel Daten finden.
Wir haben bereits über die Verschlüsselung von Passwörtern und Kommunikation gesprochen, aber Verschlüsselung ist ein so wichtiges Thema, dass ich es für notwendig hielt, ihm eine eigene Kategorie zu widmen. Verschlüsselung ist eines dieser Wörter, die jeder schon einmal gehört hat, aber nicht jeder versteht sie vollständig. Verschlüsselung ist der Prozess der Umwandlung von Informationen in einer Weise, dass im Idealfall nur autorisierte Personen sie entschlüsseln können.
Erinnern Sie sich daran, als König Heinrich VIII. mehrere Liebesbriefe an Anne Boleyn schrieb, die irgendwie im Vatikan landeten und vom Papst gelesen wurden? Das ist ein Beispiel für unverschlüsselte Kommunikation. Hätten Harry und Ann jedoch einen Code entwickelt, den nur sie beide kannten, und diese Briefe in diesem Code verschickt, hätte niemand wissen können, was in den Briefen stand, und ihre Geheimnisse wären sicher geblieben – das ist Verschlüsselung.
Ich möchte einige Punkte ansprechen:
Verschlüsselung sollte niemals eine Nebensache sein, sondern Teil der ursprünglichen Planung.
Halten Sie sich an bewährte Verschlüsselungsstandards, anstatt eigene zu entwickeln. Die Geschichte ist voll von gescheiterten Versuchen von Leuten, die dachten, sie könnten es besser machen.
Eine Burg besteht nicht nur aus ihren Mauern, sondern auch aus der Strategie, die dahintersteckt. Das Gleiche gilt für die Sicherheit. Man braucht nicht unbedingt die neueste und beste Technologie, nur weil sie gerade angesagt ist. Stabile, gut gewartete Lösungen sind oft die beste Wahl. Wenn man die Angriffsflächen und ihre Grenzen kennt, kann man seine Sicherheit sicher strukturieren.
Das Verständnis der Rolle jeder Schicht ist der Schlüssel zum Aufbau sicherer Webanwendungen. In unserem nächsten Beitrag erfahren Sie mehr über die Sicherheitsschichten in Webanwendungen. Folgen Sie uns auf LinkedIn, um benachrichtigt zu werden, wenn dieser Beitrag erscheint.