Adminpolicy
Präambel
Ziel der Policy ist eine langfristig stabile Infrastruktur auf Basis von Vertrauen und freier Software zu haben. Das heisst für mich, dass ich eventuelle Schmerzen in Kauf nehme wenn ich Dinge reparieren muss die Leute mit entsprechenden Rechten aus Versehen kaputt gemacht haben, mehr Konfigurationsaufwand mit einer freien Software statt einer proprietären habe, oder mit einem Softwarepaket zur Distribution passend arbeite statt ein fertiges Image zu nehmen.
Leitfragen zur Entscheidungsfindung
Was muss ich beachten um den Dienst die nächsten 3-5 Jahre auf dem sicherheitstechnisch aktuellen Stand zu halten?
Welches Wissen ist nötig um den Dienst neu aufzusetzen?
Was muss der Rest des Teams wissen damit ich selbst unnötig zur Problembehebung bin?
Was muss ich beachten, damit der Zugriff von Clients und Nutzern auch nach einer Migration auf einen anderen Virtualisierungshost reibungslos möglich ist
Bereiche
Kommunikation
Wenn Dinge größer umkonfiguriert werden gibt es je nach betroffenem Publikum eine (kurze) Mail an misc@, infra@ oder gw-admins@
Zugriff
Die Partei die für den Server haftet, bestimmt wer darauf Zugriff hat. Für Systeme die der Verein betreibt wird ein breites Adminteam angestrebt in dem technisch alle dieselben umfassenden Berechtigungen haben, diese aber verantwortungsvoll nutzen.
Zugriff erfolgt nach Möglichkeit über individuelle Zugangsdaten und entsprechende Berechtigungen, z.B. via sudo
ssh-Zugriff bevorzugt mit ssh-Keys statt Passwort
Applikationszugriff möglichst über verschlüsselte Methoden, http sollte vermieden werden
Installation
Bevorzugt werden Installationen auf virtuellen Instanzen auf von uns betriebener Hardware, d.h. wir können die virtuellen Instanzen vom Host aus notfalls warten.
Hardware wird bevorzugt mit Virtualisierungslayer betrieben der auch ohne speziellen Client wartbar ist, z.B. Webfrontend
virtuelle Instanzen sind bevorzugt auf Kontainerbasis, die sind deutlich Resourceneffizienter, wenn das nicht geht KVM.
Basissysteme
Software
deb-basiert aus Repository automatisch aktualisierbar
snap (Ubuntu)
rpm-basiert aus Repository automatisch aktualisierbar
automatisch aktualisierbares in anderen Formaten
.deb manuell installiert
.rpm manuell installiert
andere Formate
manuell installiert aus Sourcen, möglichst nur unter Verwendung eines Tools zur automatischen Paketierung a la „checkinstall“ in dafür vorgesehene lokale Pfade, explizit nicht '/usr/bin'
Betriebsstandort
bevorzugt im FFS, IP-Bereich 10.191.255.0/24 in Absprache mit gw-admins/backbone
offizielle/externe IPs werden für Dienste nicht direkt verwendet und sollten im FFS zum Betrieb nicht notwendig sein
extern sind nur wirklich notwendige Ports erreichbar, z.B. über selektives DNAT, eventuell über vorgeschaltete Proxies für https/http
Applikationszugriff
Backup
will der Verein haben für alle Dienste die der Verein für relevant hält, d.h. eine eigene Instanz hat, dieses Backup können auch andere im FFS-Umfeld für FFS-Dienste nutzen
Personen mit Adminzugriff auf einen Dienst dürfen zusätzlich eigene regelmäßige Backups machen
wer die Installation macht, sagt wie/was gesichert werden muss, damit bei einem Teil- oder Totalverlust der Betrieb möglichst rasch wieder aufgenommen werden kann, das kann ein klassisches Backup sein, aber auch ein allen Admins verfügbares Skript das einfach eine neue, identische Instanz aufsetzt und anschließend die Applikationsdaten wieder einspielt
Monitoring
will der Verein haben, Basis check-mk, weitere Instanzen von anderen sind willkommen
allgemeines Systemmonitoring, z.B. Netzerreichbarkeit, Plattenplatz
Applikationsspezifisches Monitoring
Anforderungen an den Verein
Der Verein muss dazu Dinge bereitstellen, direkt oder als Auftrag