Die Frage ist worüber muss man sich alles Gedanken machen, angefangen von Paketfilterung über AV bis zu Gruppenrichtlinien.
Vergiss BSI und den ganzen Murks für den Anfang. Solange das Thema nicht vom Datenschutzbeauftragten angegangen wird, der gegenüber dem Management ein paar Möglichkeiten zur Durchsetzung seiner Vorgaben hat, stopfst du dich beim BSI nur mit unnötigen Informationen voll. Ich spreche da durchaus aus Erfahrung. Hab ja nun in meinem Leben schon einige Netzwerke aufgeräumt und neu strukturiert. Du kennst die Aufbewahrungsfristen der einzelnen Daten ziemlich sicher nicht. Du kannst auch nicht in allen Fällen den Schutzbedarf einschätzen und vermutlich weisst du als Sysadmin noch nicht mal, ob bestimmte Mitarbeiter NDA von Kunden unterschreiben mussten, die irgendwelche technischen Schutzmaßnahmen vorgeben. Das sollte man aber wissen, wenn man nach BSI-Richtlinien vorgeht.
Betrachte die Sache daher aus praktischer Sicht. Du hast bestimmte Arten von Rechnern: PCs der Mitarbeiter, Laptops der Aussendienstler oder Homeofficeler, Server (diese unterteilt in Testsysteme, Buildsysteme, Live-Systeme, Office-Server etc.), ggf. private Smartphones, Router, Switches etc. Willst du die in der Praxis auch dann unter Kontrolle behalten, wenn das Netzwerk wächst, solltest du die jeweiligen Rechner-Arten in eigene Netzwerk-Segmente packen. Zwischen diese Segmente fügst du "Security-Layer" ein. Diese bestehen zumeist aus Routern, die mit Firewall, IDS/IPS, Monitoring der Datenflüsse etc. ausgestattet sind. Durch diese Aufteilung erreichst du eine Art modulares Design deines Netzwerks, bei dem du nun für jedes "Modul" den technischen Schutzbedarf definieren kannst. Bei einem "Modul", in dem keine Windows-Rechner sind, brauchst du vermutlich eher keine Virenscanner auf den Rechnern. Dafür aber vielleicht Bot-Erkennungssysteme wie rkhunter. Bei einem Client-Rechner macht es wenig Sinn die Änderungen von Dateien zu überwachen. Auf einem Live-Server aber evtl. schon. Du kannst also für jedes "Modul" klar definieren welche Schutzmaßnahmen die Rechner innerhalb des Moduls haben müssen.
Diese Vorgehensweise verhindert, dass du später ein Netzwerk hast, wo jeder Rechner andere Schutzmaßnahmen hat und keiner mehr durchsieht was nun wo installiert ist. Ausserdem schaffst du mit den Knotenpunkten zentrale Möglichkeiten um Zugriffsbeschränkungen zu den Rechern im Segment zu verwalten. "Rechner XY darf nur auf die Server A, B und C zugreifen" ist dann keine Konfiguration mehr an den Servern sondern an den Knotenpunkten zwischen den beteiligten "Modulen". Das spart Arbeit. Denn Admins sind bekanntermaßen faule Wesen, die alles so weit automatisieren und zentralisieren, dass sie möglichst wenig Arbeit damit haben. Das kommt ganz nebenbei auch oft der Sicherheit zugute.
Grundsätzlich gilt:
- Jeder Rechner sollte nur auf die Ressourcen zugreifen können, die für die Arbeit des Rechners notwendig sind. Beispiele: Server von Projekt X sollten keine valide Route zu Servern von Projekt Y haben, sofern diese nicht notwendig ist. Mitarbeiter ABC an Rechner BLABLUB darf nur auf die Dateien in Ordner XYZ auf Server FOOBAR zugreifen. Testsysteme dürfen keinen Zugriff auf Livesysteme haben.
- Jeder Server sollte regelmässige Checks auf Dateiänderungen (bei Systemdateien) und ungewollte Prozesse durchlaufen.
- Jeder Server sollte mit ACLs für die Zugriffsbeschränkungen ausgestattet sein.
- Jeder Client sollte mit aktuellem AV und regelmässigem Backup ausgestattet sein. (Jaja, sollte jeder Server auch, aber in Zeiten der automatischen Build-Systeme und der agilen Entwicklung (mit Auto-Deployments, Continious Delivery etc.) lassen sich manche Server durch Reinstallation und Einspielen der Software aus dem Build-System schneller wieder an den Start bringen als durch ein Backup-Restore.)
- Zwischen jedem Netzwerksegment/Modul sollte sich ein Paketfilter befinden, mit dem du die Zugriffe zwischen den Segmenten beliebig steuern kannst.
- Nur der Admin und die Manager haben physischen Zugang zu Servern (auch nicht in jedem Unternehmen selbstverständlich, da werkeln gern mal Devs an den Kisten rum).
Und wenn du das umgesetzt hast, nimmst du dir den BSI-Grundschutzkatalog und wirst feststellen, dass dein Netzwerk die meisten Anforderungen darin bereits erfüllt.
Der Rest ist dann nur in Zusammenarbeit mit dem Datenschutzbeauftragten zu bewältigen. Der kann dir z.B. sagen wann und unter welchen Umständen Daten irgendwo gelöscht werden müssen. Der kann dir auch sagen wann Daten auf keinen Fall gelöscht werden dürfen (musst du dann z.B. via ACLs verhindern). Und der kann dir auch sagen welchen Schutzbedarf und Integritätsbedarf die Daten der einzelnen Abteilungen und Mitarbeiter haben. Man muss z.B. die Emails von Devs nicht unbedingt revisionssicher archivieren. Die von der Finanzabteilung aber auf jeden Fall.
Die Stern-Topologie kannst du dabei durchaus beibehalten. Du solltest aber mittels ein paar zusätzlicher Router und Switches (kosten ja nicht die Welt, gute preiswerte Router für diese Zwecke gibt's z.B. bei Mikrotik) den Stern nicht mehr aus einzelnen Rechnern sondern aus einzelnen Segmenten bestehen lassen. So lange jeder Rechner auf jeden anderen Rechner im Netzwerk ungehindert zugreifen kann, wirst du BSI-Grundschutz eh niemals erfolgreich umsetzen bzw. in einen unnötig hohen Verwaltungsaufwand rennen.
Mal in den BSI-Kram reinschauen kann aber nicht schaden. Er vermittelt ein gutes Gefühl dafür, worauf du alles achten musst. Mach aber bloss nicht den Fehler das alles umsetzen zu wollen. Das ist neben einer normalen Admin-Tätigkeit nur zu schaffen, wenn das Management dir auch die Rechte eines Datenschutzbeauftragten einräumt oder dich zu selbigem ernennt und wenn du bereit bist einiges an Überstunden zu leisten. Ich hatte das bei Blog.de damals (dort war ich Sysadmin und DSB in einer Person) und kann nur davor warnen den Arbeitsaufwand dafür zu unterschätzen. Als Admin solltest du BSI-Grundschutz nur als ganz groben Leitfaden einsetzen.
Übrigens halte ich eine gute Netzwerk-Doku für den Einstieg für absolut richtig. Mit einer guten Doku lässt sich die Einteilung der Segmente wesentlich einfacher und strukturierter angehen. Wenn ich neu in einem Unternehmen bin, nehme ich mir normalerweise auch erstmal die vorhandene Doku oder schreibe eine, wenn keine da ist, um einen Überblick über die vorhandenen Systeme und die Datenflüsse zu bekommen. Auch ein grober Schutzbedarf der Rechner lässt sich damit besser ermitteln. Auf einem Rechner bei der Buchhaltung kann eine Angriffserkennung durchaus Sinn machen. Bei einer Workstation eines Entwicklers zumeist eher nicht.
![[HaBo]](/styles/default/logoklein.png){kind=small}
