Wir haben die AWS-Infrastruktur einer Gesundheitsplattform (SaaS) in den USA von Grund auf aufgebaut. Die Anwendung läuft auf Elastic Beanstalk mit Nginx. Ein Datenverkehrsfilter mit 23 Regeln und ein automatisches Skript, das Scanner sperrt, schützen sie. Fertige Abfragen in den Protokollen zeigen, was passiert.
Reales Projekt, ohne Namen
| Branche | Gesundheit und Kliniken · SaaS und Technologie |
|---|---|
| Herausforderung | Vertrauen und Glaubwürdigkeit |
| Entscheidungsumfeld | Beaufsichtigt |
| Komplexität | Hoch |
| Leistung | Cloud-Aufbau |
Wenn eine Anwendung sensible Daten verwaltet, etwa Gesundheitsdaten, schützt die Infrastruktur diese Daten jeden Tag. Die Fallstudie zeigt, in welcher Reihenfolge dieser Schutz aufgebaut wurde, warum jedes Teil gewählt wurde und wie auch jemand, der kein Ingenieur ist, nachlesen kann, was geschieht.
Eine Gesundheitsplattform, die als Software (SaaS) in den USA angeboten wird, brauchte eine Cloud-Infrastruktur, die bei null beginnt. Es gab keine Umgebung, keinen Filter und keine fertige Abfrage in den Protokollen. Ein Gesundheitsprodukt betrifft Menschen und ihre Gesundheit. Deshalb musste die Infrastruktur vom ersten Tag an stimmen.
Wir haben die Cloud-Seite übernommen: die Umgebung einrichten, in der die Anwendung läuft, sie schützen und dem Team der Plattform einen einfachen Weg geben, sie zu beobachten.
Der Start bei null hat einen Vorteil: Nichts Altes muss geändert werden. Er verlangt aber Sorgfalt, denn jede Entscheidung wird bewusst getroffen und festgehalten.
Jede Anwendung, die im Internet erreichbar ist, bekommt wenige Stunden nach dem Start automatische Tests ab. Programme rufen Tausende Adressen auf, um eine vergessene Konfigurationsdatei, ein Verwaltungsfenster oder ein altes Skript zu finden. OWASP beschreibt diesen automatisierten Missbrauch als ständiges Hintergrundrauschen rund um Webanwendungen (siehe Quellen).
Bei einem Gesundheitsprodukt wiegt jeder solche Test schwerer als bei einer einfachen Vorstellungsseite. Die Infrastruktur musste deshalb zwei Dinge tun. Erstens sollte sie schädlichen Datenverkehr stoppen, bevor er die Anwendung erreicht. Zweitens sollte sie klar zeigen, was passiert, damit ein Mensch erkennt, was die Regeln nicht vorhersehen.
Vier Rahmenbedingungen prägten die meisten Entscheidungen. Die Lösung musste auf AWS laufen. Sie musste von Grund auf so gebaut werden, dass sie jeder leicht versteht, der sie später betreut. Der Filter musste echte Nutzer durchlassen, auch an den komplexen Anmeldestellen, an denen Anfragen leicht wie ein Angriff aussehen.
Die vierte Bedingung betrifft das, was wir veröffentlichen. Die Seite beschreibt nur, was eingerichtet wurde. Sie behauptet keine Zertifizierungen und nennt keine Angaben des Kunden.
Eine solche Einrichtung wirkt, wenn drei Dinge zusammenarbeiten. Der Filter ist auf die konkrete Plattform abgestimmt, sodass Kunden durchkommen und Angriffe gestoppt werden. Das Team kann die Protokolle leicht lesen. Der Schutz arbeitet automatisch und wartet nicht darauf, dass jemand daran denkt, zu reagieren.
Es hilft auch, wenn jede Regel einen bekannten Zweck hat. Eine lange Liste, die aus einer Vorlage kopiert wurde, macht dem Team das Leben schwer: Wird ein echter Nutzer blockiert, ist nicht zu sehen, welche Regel schuld ist. Mit erklärten Regeln ist die Ursache schnell gefunden, und der Filter bleibt aktiv.
Schließlich hat die Sperre eine Dauer. Eine Adresse, die für immer gesperrt wird, kann später zu unschuldigen Nutzern gehören, weil viele Adressen geteilt oder neu vergeben werden. Eine Sperre mit Zeitlimit schützt die Plattform, ohne echte Menschen auszusperren.
Wir haben in Schichten gearbeitet, von außen nach innen, sodass jede Schicht auffängt, was die vorige durchlässt. Zuerst das Hosting der Anwendung, dann ein Filter davor, dann ein automatisches Skript, das die Protokolle liest. Zum Schluss fertige Abfragen für die Person, die die Plattform beobachtet.
Hosting der Anwendung auf AWS Elastic Beanstalk, mit Nginx vor dem Anwendungsserver.
Eine Firewall für Webanwendungen (AWS WAF), also ein Filter, der schädlichen Datenverkehr stoppt, mit 23 Regeln.
Ein kleines automatisches Skript (AWS Lambda in Python), das alle 3 Minuten die Protokolle liest, Scanner erkennt und sperrt.
Fertige Abfragen in Amazon CloudWatch Logs Insights, damit das Team die Protokolle lesen kann, ohne Abfragen von Anfang an zu schreiben.
Die 23 Regeln umfassen ein Limit für Anfragen pro IP, eine geografische Beschränkung und fertige Regelgruppen, die AWS pflegt: häufige Bedrohungen, bekannte schädliche Daten, IP-Reputation von Amazon, anonyme IPs, WordPress, PHP. Weitere Regeln blockieren die Suche nach Dateien wie .env, .git, node_modules oder phpMyAdmin. Sie blockieren außerdem PHP-Dateien oder -Parameter, die die Plattform nicht verwendet, sowie automatisierte Clients. Dazu kommen Listen mit erlaubten und gesperrten IPs und Ausnahmen für die komplexen Anmeldestellen.
Die Entscheidungen zählen mehr als die Liste der Werkzeuge. Vier stechen hervor: enge Ausnahmen für die Anmeldung, Sperren, die schrittweise wachsen, Regeln mit klarem Zweck und fertige Abfragen in den Protokollen, bevor sie gebraucht werden. Jede macht die Plattform sicherer, ohne es echten Nutzern schwerer zu machen.
Ausnahmen für die Anmeldung. Die komplexen Anmeldestellen senden Anfragen, die ein strenger Filter für verdächtig hält. Wir haben nur diese Stellen von bestimmten Regeln ausgenommen. Alle übrigen Regeln blieben für die gesamte Plattform aktiv.
Sperren, die schrittweise wachsen. Die Lambda-Funktion sperrt eine Adresse nicht beim ersten Anzeichen für immer. Die Dauer der Sperre steigt, je öfter sich das Verhalten wiederholt: Ein einzelner Fehler läuft schnell ab, ein hartnäckiger Scanner bleibt länger draußen.
Regeln mit klarem Zweck. Jede Regel sagt, was sie stoppt. Wird ein Nutzer blockiert, ist die Ursache in wenigen Minuten gefunden.
Vorbereitete Abfragen. Die Abfragen in Logs Insights decken Fehler 4xx und 5xx, Weiterleitungen, verdächtige IPs und Sperren ab. Bei einem Vorfall sind die ersten Fragen fast immer dieselben. Ist die Antwort schon bereit, gewinnt das Team Zeit in dem Moment, in dem es zählt.
Wir haben nur die AWS-Dienste verwendet, die die Plattform brauchte, ohne zusätzliche Werkzeuge. Die Technik folgt den Anforderungen.
Das Ergebnis ist ein Satz von Mechanismen, die zusammenarbeiten. Die Plattform läuft in einer stabilen, festgelegten Umgebung. Schädlicher Datenverkehr trifft auf einen Filter, bevor er die Anwendung erreicht. Scanner, die die ersten Regeln überwinden, erkennt das Skript innerhalb weniger Minuten. Das Team sieht über die fertigen Abfragen, was passiert.
Zahlen wie gestoppte Angriffe oder Antwortzeiten veröffentlichen wir nicht, weil wir keine freigegebenen Angaben zur Veröffentlichung haben. Eine solche Einrichtung stützt die Verlässlichkeit der Plattform über Jahre, weil sie Probleme früh sichtbar macht. Sicherheit ist eine laufende Aufgabe: Sie wird gepflegt und mit der Zeit verbessert.
Wenn Sie etwas Ähnliches planen, erklärt die Seite zur AWS-Cloud-Einrichtung, wie wir arbeiten. Der Artikel wie eine Anwendung vor automatisierten Scans geschützt wird erklärt die Idee in einfachen Worten.
Es wurden vier Dienste verwendet: AWS Elastic Beanstalk für das Hosting der Anwendung mit Nginx davor, AWS WAF für den Datenverkehrsfilter, AWS Lambda in Python für die automatische Sperre und Amazon CloudWatch Logs Insights zum Lesen der Protokolle. Hinzugefügt wurde nur, was die Plattform brauchte.
Es ist ein reales Projekt. Die Identität des Kunden bleibt privat, ebenso seine Angaben. Hier beschreiben wir in groben Zügen, was wir eingerichtet haben, damit Sie den Ansatz beurteilen können.
Der Filter und die automatische Sperre verringern das Rauschen, stoppen die einfachen Angriffe und machen sichtbar, was übrig bleibt. Keine Anwendung ist völlig unangreifbar. Deshalb waren die Protokolle mit den fertigen Abfragen von Anfang an Teil der Arbeit.
Ja. Dieselbe Methode passt zu jeder Webplattform, in jeder Branche. Wie wir arbeiten, sehen Sie bei SaaS-Plattformen und Unternehmensanwendungen. Oder starten Sie ein Projekt, indem Sie Ihren Bedarf beschreiben.
Die Qualitäts- und Sicherheits-Agents sind unser eigenes Werkzeug. Es prüft jeden Build auf einem festen Weg: QA, UX, Sicherheit, Pentest, SEO/AEO, technische Prüfung mit Lighthouse, Code-Review.
Die Website einer SaaS-Plattform macht das Produkt verständlich, wenn der Inhalt nach Zielgruppe und Tiefe getrennt ist und die Anwendungsfälle vor der Funktionsliste stehen.
Praion AI ist unsere eigene SaaS-Plattform, auf der jeder Kunde seine eigene Datenbank hat. Drei Anwendungen (Lead Concentrator, Content Studio, Product Manager) teilen sich Konten, Firmenprofile und ein Guthaben an KI-Credits.
Senden Sie eine Projektanfrage oder prüfen Sie Ihre aktuelle Website kostenlos. Jede Nachricht lesen wir selbst.