Webserver bei der dkd

Dieser Blogbeitrag demonstriert den Aufwand und die Kreativität, mit der die Infrastruktur gepflegt wird.

Vor allem aber zeigt er, dass IT-Sicherheit als Thema ernst genommen und stetig verbessert wird.
"Die Leute sollen verstehen, was hinter so einem Webserver steckt, was da alles in einander greift und wie wir die "Dinger" sicher machen." Ich stutze für einen Moment. Das Ziel eines Bühnenmagiers ist es, das Publikum von den Stellen abzulenken, an denen die "Zauberei" passiert. Niemand soll sehen, wie die Münze zwischen die Finger geklemmt wird, oder wie eine Spielkarte trotz heftigstem Mischen immer ganz oben auf dem Stapel liegen bleibt.
Und ich dachte bisher, genau das gleiche passiert beim Hostingangebot der dkd: Das Infrastrukturteam arbeitet im Verborgenen, während die Projektteams und der Support geschickt davon ablenken, dass es überhaupt ein Infrastrukturteam gibt - Webseiten funktionieren einfach, wie durch Zauberhand, und sind unter einer bestimmten Webadresse erreichbar.
Aber Support-Guru Thomas Janke hat einen Blogartikel zur Serversicherheit bei der dkd beauftragt, dann darf er den auch gerne haben. Dennoch möchte ich die geneigte Leserschaft vor die Wahl stellen: Wer lieber weiter an die Magie eines "einfach da" Webservers glauben möchte sollte an dieser Stelle aufhören zu lesen.
Noch da?
Super!

Bereit zum Abheben

Es gibt im dkd-internen Wiki eine Checkliste zur Vorbereitung eines Servers. Und ohne schon im ersten Absatz völlig die Magie der Webserverprovisionierung zu ruinieren: Das Ding liest sich, als gäbe es einen 4-stündigen Director's Cut von "Top Gun", in dem, während eines 30-minütigen Mega-Edits von "Danger Zone", Tom Cruise die Kontrollleuchten der Fahrgestellklappen und Ruderpedaltoleranzen prüft - lang, detailliert und man möchte nicht dabei zuschauen, aber irgendwer muss es machen.
Ab wann wir der Server benötigt? Welche Betriebssystemversion ist drauf? Vor dem Livegang noch Updates einspielen! Ist der Server im DNS bekannt? Auch IPv6? Ist das Backup konfiguriert? Wo laufen die Logs hin?... Das bedeutet nicht, dass vollends auf Heuristiken verzichtet wird - Erfahrung ist wichtig und wertvoll, aber es gibt auch immer die Liste mit ToDos, die diktiert, wie so ein dkd Server richtig und sicher aufgesetzt wird.
Damit ist die Wiederholbarkeit aber noch nicht bis zum Ende gedacht, weil immer noch großes Potential für menschlichen Fehler, zum Beispiel in Form von Tippfehlern, vorliegt. Deshalb werden Prozesse von Server Setup und Maintenance weitgehend automatisiert. Die verwendeten Automationsskripte können vor dem Loslassen in die freie Wildbahn zuerst auf Testumgebungen geprüft werden, sie sind selbst mit Codeanalysetools testbar und sorgen dafür, dass Integrations, Test- und Produktivumgebungen tatsächlich vergleichbar sind und keine kritischen Softwareinstallationen vergessen wurden.
Noch besser: Durch spezielle Inspektionstools wird der Soll-Zustand mit der vorliegenden Konfiguration verglichen und auf etwaige Unterschiede hingewiesen.
Ich kann es nicht beweisen, aber ich bin mir sicher dass auf jedem Server, beim Durchlaufen dieser Prozesse, Kenny Loggins läuft!
HIIIGHWAAAYYYY TOOOOO THEEEEE...

Dedizierte Server

An dieser Stelle möchte ich kurz erwähnen, was der große Unterschied zwischen einem richtigen Server und einfachem Webhosting ist.
Zum einen kann ich auf einem Server beliebige Software installieren, was in vielen anderen Hostingszenarien nicht möglich ist. Wenn ich einen bestimmten Kalenderserver benötige, um die Terminverwaltung meines Modelabels mit der Pariser Fashion Show zu koordinieren: Klar, kein Problem! Mein Pokémon Sammelkartengeschäft braucht eine spezielle Clientsoftware, um auf die Datenbanken großer Handelsbörsen zuzugreifen? Dauert 'ne Stunde, dann kann's losgehen!
Ich bin also völlig frei in der Gestaltung von Diensten, die ich benutze oder anbiete.
Das ist auch andersrum wertvoll. Auf einem dedizierten Server läuft nur, was ich auch tatsächlich brauche, es werden also keine Systemressourcen für Programmumgebungen verschwendet, die ich überhaupt nicht benutze. Als TYPO3- oder Wordpress-Nutzer brauche ich keine Java Umgebung, die es sich in meinem Arbeitsspeicher und meinen CPU-Zyklen gemütlich macht.
Ein weiterer Punkt, der erst nach etwas Kopfrechnen Sinn ergeben mag; alle dkd Server sind in Tier 3 Rechenzentren oder besser untergebracht. Das bedeutet eine garantierte Verfügbarkeit von 99,98% im Jahr.
Ich selber bezahle jeden Monat etwas Geld für ein kleines Hostingpaket, das mir 99% Verfügbarkeit verspricht. Das klingt jetzt bei rein emotionaler Betrachtung fast genauso gut. Aber wenn ich genauer darüber nachdenke: Mein kleiner Webspace kann im Jahr für dreieinhalb Tage ausfallen. Verglichen mit einer Garantie, dass meine Infrastruktur nicht mehr als 1,6 Stunden im Jahr vom Netz ist, steht mein privates Hostingpaket ziemlich schwachbrüstig da.

Backup vs. Backup

Auch Datensicherung ist nicht gleich Datensicherung. Ein anständiges Backup findet nicht nur regelmäßig statt, sondern ist bestenfalls nicht von den gleichen Problemen betroffen, wie der gesicherte Server. Wenn ich meine Daten in einem anderen Ordner auf der gleichen Festplatte sichere, dann ist bei Ausfall der Festplatte auch mein Backup futsch. Zweite Platte auf dem gleichen Server: Pech, wenn der Server ausfällt. Backup auf einem anderen Server im gleichen Netzwerk? Switch oder Router kaputt und ich komme nicht mehr an meine Daten.
Deshalb werden ordentliche Backups verschlüsselt über das Internet an einen sekundären Standort geschickt. Nur wenn gleichzeitig zu meinem Server die kritische Infrastruktur einer zweiten Rechenzentrums ausfällt, habe ich tatsächlichen Datenverlust zu befürchten.
Nur der Vollständigkeit halber (falls der Kontext noch nicht genug gewesen sein sollte): Natürlich werden Daten bei der dkd "off-site", also an einem zweiten Standort, gesichert!

Serverhärtung

In der IT Infrastruktur gibt es das Konzept des Härtens. Damit ist eine Absicherung durch Verkleinerung der möglichen Angriffsfläche gemeint. Programm- und Systemkonfigurationen, Netzwerkeinstellungen, Entfernen unnötiger Komponenten - das alles trägt dazu bei, dass ein möglicher Hackerangriff auf das System schwieriger und bestenfalls unmöglich wird.
Jetzt wäre es natürlich ganz fantastisch, wenn es dafür Dienste gäbe, die immer auf dem aktuellen Stand gehalten werden und die Systeme überwachen um Handlungsbedarf zu melden.
Auftritt Bühne links: DevSec! Nach diesen Richtilinien arbeiten wir. Und zusammen mit unseren bereits oben erwähnten Inspektionswerkzeugen, gibt es Warnung wenn etwas an der Sicherheitskonfiguration optimiert werden kann.Muss ich Nessus sowie OWASP Schwachstellenscanner erwähnen, die standardgemäß bei uns in der dkd im Einsatz sind? Wir gehen nunmal auf Nummer sicher.

Überwachung

Wenn ein Server im Rechenzentrum ausfällt aber niemand versucht, auf ihn zuzugreifen; macht es dann ein Geräusch?
Ja, macht es. Oder viel mehr, unser Monitoring Tool schreit auf.
Server Logs werden zentral und durchsuchbar gespeichert, sodass bei Problemen schnell zu klären ist, was tatsächlich das Problem ist, und das vernetzte Ressourcen-Monitoring stellt den Kontext eines Ausfalls klar und macht kritische Überlastungen schon vor dem Eintreten von Problemen sichtbar.
Bleibt noch zu erwähnen, dass die o.g. Monitoring Tools durch unser Orchestrator provisioniert sind. D.h. für jeden Dienst, der vom Orchestrator provisioniert ist, werden automatisch ein oder mehrere Checks im Monitoringsystem angelegt, um sicherzustellen, dass der gewünschte Dienst auch funktioniert und von Außen erreichbar oder eben nicht erreichbar ist.

Entwicklung

Ja, wie jetzt? Serversicherheit passiert doch auf der Infrastrukturebene, was hat das jetzt mit Entwicklung zu tun?
Unsichere Programmierpraktiken können unerwünschte Zugriffe auf z.B. Datenbankinhalte erlauben oder Cross-Site-Scripting Attacken ermöglichen. Deshalb gehört in ein IT-Sicherheitskonzept eben auch die Programmierpraxis.
Standardvorgehen in der dkd ist es, dass Code nur nach erfolgreichem Review auf den Integrationsserver gelangt und die Prüfung auf Sicherheitsthemen ist in den Teams sowohl Bestandteil der Programmiervorgaben wie auch der Prüfungsrichtlinien im Review.

Fazit

Wie fasse ich also zusammen, wie die IT-Sicherheit in der dkd funktioniert? Wenn ich mir ansehe, wie andere Unternehmen ihre Serverinfrastruktur behandeln, dann steht die Digitalagentur, bei der ich meine Brötchen verdiene, echt gut da! IT Sicherheit wird als fortlaufender Prozess begriffen, niemand ruht sich auf den Errungenschaften der Vergangenheit aus. Kontinuierlich werden neue Tools getestet, andere Methoden eruiert, neue Techniken diskutiert.
Das heißt, wenn ich das hier lese, besteht die Gefahr, dass das alles schon wieder veraltet ist?
Ja, und genau so sollte es sein! Diese Momentaufnahme zeigt, wie viel Planung, Prüfung und Probiererei in so einem Server-Setup und der fortlaufenden Administration steckt. Es demonstriert den Aufwand und die Kreativität, mit der die Infrastruktur gepflegt wird. Vor allem aber zeigt es, dass IT-Sicherheit als Thema ernst genommen und stetig verbessert wird.