Die Verkehrsregeln sind eigentlich ganz einfach: Man hält an einer roten Ampel an, hält sich an die Geschwindigkeitsbegrenzung und fährt natürlich nicht in eine Einbahnstraße von der Gegenseite ein oder parkt in einem Sperrgebiet. Trotz der vielen Personen, die täglich am Verkehr teilnehmen, funktionieren die genannten Regeln meist ganz gut. Im Grunde genommen, weil jeder sie kennt und sich mehr oder weniger daran hält.
Dass es während der Führerscheinprüfung nicht gerade klug wäre, sich über die Regeln hinwegzusetzen, liegt auf der Hand. Aber nach bestandener Prüfung? Als ich neulich durch die Stadt fuhr, fuhren plötzlich alle langsamer, ohne erkennbaren Grund. Klar, einen „Blitz“ später hat sich ein Unaufmerksamer ein ziemlich teures Foto eingehandelt – wegen Geschwindigkeitsüberschreitung innerhalb der Stadtgrenzen.
Wie es scheint, reicht es nicht aus, nur Regeln zu haben. Es muss auch jemand da sein, der sie durchsetzt. Und um die Regeln durchzusetzen, muss jemand auf Streife gehen. Was für den Straßenverkehr und seine Regeln so selbstverständlich zu sein scheint, ist für viele Webentwickler weniger offensichtlich. Sie neigen dazu, es zu versäumen, zu definieren (und zu überwachen), was auf der Anwendungsebene sowie auf der Infrastrukturebene ihrer Anwendung passiert. Es reicht nicht aus, eine Standardinstallation des Betriebssystems der Wahl auszuführen, die benötigten Dienste hinzuzufügen und das Beste zu hoffen. Wenn man bedenkt, wie viel Geld und Reputationsschäden entstehen, entweder direkt durch Betrug und Missbrauch oder indirekt durch die Zeit, die verloren geht, um ein gehacktes System oder eine gehackte Software wiederherzustellen, ist der Ansatz „Hoffen wir das Beste“ von fragwürdiger Qualität. Und wir denken hier noch nicht einmal an generelle Bugs.
Bevor Sie irgendwelche Zugriffsregeln implementieren und Mittel zu deren Durchsetzung definieren können, müssen Sie sich überlegen, welche Dienste Sie tatsächlich benötigen, wie sie kommunizieren sollen und mit welchen Berechtigungen sie arbeiten sollen.
Das Härten der Systeme (was unter anderem bedeutet, dass nicht benötigte Dienste, die mit einer Standardinstallation geliefert werden, entfernt werden oder Sicherheitsregeln durchgesetzt werden, wie zum Beispiel die Beschränkung des Shell-Zugriffs auf eine bestimmte Gruppe von IP-Adressen und Benutzern) ist das erste, was zu tun ist, sobald das Basissystem installiert ist. Dies ist eine Voraussetzung für eine sichere Umgebung.
In Anbetracht der Tatsache, dass es keine 100-prozentige Sicherheit gibt, ist es wichtig zu definieren, was die Risiken sind und was ein Versagen bei der Durchsetzung einer der oben genannten Regeln zur Folge haben könnte. Die Infrastruktur, die Sie nutzen werden oder bereits nutzen, ist wahrscheinlich ständigen Angriffen ausgesetzt. Entweder durch manuelle Versuche, sich in das System einzuhacken, oder durch automatisierte Skripte und Bots, die immer auf der Suche nach neuen Opfern sind. Der Housing-Standort zum Beispiel und die Art des Uplinks für Ihren Server können ebenso wichtig sein wie das Betriebssystem und andere Softwarekomponenten sowie die verwendeten Versionen oder die Hardwareplattform, auf der das Ganze basiert.
Sich Gedanken über den Uplink und den Standort des Servers zu machen, mag auf den ersten Blick nicht sicherheitsrelevant erscheinen. Es ist aber ein weiterer wichtiger Faktor im Gesamtbild: Egal, wie viel Zeit und Geld Sie in die Absicherung der über Remote-Verbindungen erreichbaren Dienste auf Software-Ebene investiert haben, all diese Bemühungen sind umsonst, wenn es kein Sicherheitsprotokoll für den physischen Zugriff auf die betreffende Maschine gibt. Warum sollte ein engagierter Angreifer versuchen, sich in Ihren gut geschützten Datenbankserver zu hacken, wenn es so viel einfacher ist, einfach den physischen Rechner zu stehlen – oder das letzte Backup-Band?
Es ergibt auch keinen Sinn, nur ein – möglicherweise prominentes – System zu sichern und andere Teile der Infrastruktur ungeschützt zu lassen, wie ich vor einiger Zeit bei einem Audit gesehen habe: Stellen Sie sich einen Webserver vor, der durch eine Firewall auf Anwendungsebene geschützt ist, die nur gültigen HTTP-Verkehr zulässt, und der auf einer versiegelten Box gehostet wird, was es praktisch unmöglich macht, ihn zu hacken. Aber die Datenbank lief auf einer ungeschützten Maschine eines Drittanbieters, auf die jeder zugreifen konnte. Obwohl das ursprünglich nur für Entwicklungszwecke geplant war, gab es nun keine Notwendigkeit mehr für einen Angreifer, sich durch die Firewall zu hacken, um alle Daten zu sammeln, die er brauchen könnte.
Aber wie kann man erkennen, ob jemand tatsächlich versucht, einzubrechen? Ziemlich genau so, wie es die Polizei im Straßenverkehr macht: mit Geschwindigkeitskontrollen und durch Streifendienst. Eine richtig konfigurierte Firewall zeigt und unterbindet jede nicht autorisierte Kommunikation innerhalb des Netzwerks und Sie müssen nur noch die Vitaldaten Ihrer Infrastruktur überwachen. Das umfasst neben dem Netzwerkverkehr auch Details auf Betriebssystemebene wie CPU-Last und Speichernutzung, geht weiter mit dem Sammeln statistischer Daten, um zu erwartende Verkehrsspitzen von Angriffen zu unterscheiden, und endet mit der Analyse von Logfiles auf ungewöhnliche und potenziell problematische Warnungen.