Adminpolicy

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.

• 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

Wenn Dinge größer umkonfiguriert werden gibt es je nach betroffenem Publikum eine (kurze) Mail an misc@, infra@ oder gw-admins@

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

• 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.

• Hardware: bevorzugt mit (serieller) Konsole und Proxmox als Virtualisierungsschicht
• Kontainer/Instanzen:
  1. Debian stable, wenn testing nötig ist den Distributionsnamen verwenden, nicht 'testing', unstable kann durch apt-preferences fast immer vermieden werden
  2. Ubuntu LTS
  3. DPKG-basiert
  4. RPM-basiert
  5. wenn die benötigte Applikation nur für andere Systeme automatisch aktualisiert wird auch andere

1. deb-basiert aus Debian Distributions Repository automatisch aktualisierbar
2. deb-basiert aus Herstellerrepository
3. snap (Ubuntu)
4. rpm-basiert aus Repository automatisch aktualisierbar
5. automatisch aktualisierbares in anderen Formaten
6. .deb manuell installiert
7. .rpm manuell installiert
8. andere Formate
9. 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'

Das ist an sich weder gut noch schlecht. Es muss allerdings klar sein wie Updates erfolgen und ob die vollständig sind. Gut ist, wenn der Hersteller das Docker-Image auf jeweils aktuellem Softwarestand auch der Basis darunter anbietet. Wenn jemand mal eben die immer aktuelle Softwareversion auf ein veraltetes Basisimage legt hilft das nichts.

Bestenfalls verträgt es die Software auch noch immer ein :latest-Image zu nutzen das über watchtower o.ä. aktualisiert wird.

• 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

• bevorzugt über Namen statt IP-Adressen

• 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

• will der Verein haben, Basis check-mk, weitere Instanzen von anderen sind willkommen
• allgemeines Systemmonitoring, z.B. Netzerreichbarkeit, Plattenplatz
• Applikationsspezifisches Monitoring

Der Verein muss dazu Dinge bereitstellen, direkt oder als Auftrag

• Hardware Backupsystem
• Hardware Monitoringsystem
• Hardware Dienste