Abschottung der Apps
- Jede App läuft in einem eigenen Container mit festem Speicher- und CPU-Limit
- Keine root-Rechte, keine Linux-Sonderrechte, keine neuen Rechte zur Laufzeit
- Container können einander im Netzwerk nicht erreichen
- Der Zugriff auf interne Verwaltungsschnittstellen des Servers ist gesperrt
- Obergrenze für Prozesse, damit eine App den Server nicht lahmlegt
Zugang und Konten
- Passwörter werden mit scrypt und Zufallssalz gespeichert
- Zwei-Faktor-Anmeldung mit Authenticator-App und Wiederherstellungscodes
- Zugriffsschlüssel liegen nur als Hash vor und tragen eine eigene Rolle
- Ein neues Passwort beendet alle offenen Sitzungen
- Prüfprotokoll über 180 Tage
Betrieb
- HTTPS für Console und alle Apps, Zertifikate automatisch
- Firewall, automatische Sicherheitsupdates, Überwachung mit Neustart
- Nächtliche Sicherung um 3:30 Uhr: Konten und Einstellungen, Abzüge aller Datenbanken, Dateien im Speicher und die dauerhaften Verzeichnisse der Apps
- 30 Tage Verlauf auf einem gespiegelten Plattenpaar im Server, zusätzlich verschlüsselt außer Haus auf einem getrennten Speichersystem – der Speicheranbieter sieht nur verschlüsselte Blöcke
- Die Wiederherstellung aus der Sicherung ist erprobt, nicht nur eingerichtet
- Server in einem Rechenzentrum in Deutschland
Platz auf der Platte
Jede App, jede Datenbank und jeder Speicher hat ein Kontingent. Das schützt dich vor deinen eigenen Ausreißern – und alle anderen davor, dass ein einzelner Kunde die Platte füllt und damit den ganzen Server lahmlegt.
| Dauerhafter Ordner /daten | 2 GB bei S, 5 GB bei M, 10 GB bei L. Ist er voll, hängen wir ihn schreibgeschützt ein: Die App läuft weiter und kann lesen, aber nichts mehr speichern. Sobald wieder Platz ist, geben wir ihn von selbst frei. |
| Datenbanken | 5 GB bei S, 10 GB bei M, 40 GB bei L. Ist der Platz aufgebraucht, bekommst du eine E-Mail und zwei Stunden Zeit. Danach halten wir die Datenbank an – einer Datenbank, der beim Schreiben der Platz ausgeht, können Daten verloren gehen. Eine größere Größe wählst du selbst in der Console, die Daten bleiben dabei erhalten. |
| Speicher (S3) | 10 GB je Speicher, in der Console bis 100 GB selbst erhöhbar, darüber hinaus über den Support. Ist er voll, lehnt die Schnittstelle Uploads mit 507 ab; Lesen und Löschen gehen weiter, damit du aufräumen kannst. |
Bei 80 % kommt eine E-Mail, lange bevor etwas gebremst wird. Die Grenzen prüft die Plattform alle paar Minuten, nicht der Kernel des Servers: Zwischen zwei Messungen kann ein Kontingent kurz überschritten werden.
Wenn etwas ausfällt
Was passiert, hängt davon ab, was ausfällt:
| Eine Instanz deiner App stürzt ab | Sie wird automatisch neu gestartet. Läuft die App mit mehreren Instanzen, übernehmen die anderen sofort, Besucher merken nichts. |
| Ein Deployment schlägt fehl | Die bisherige Version läuft weiter. Umgeschaltet wird erst, wenn die neue Version antwortet. |
| Branchway selbst wird aktualisiert | Deine Apps laufen weiter, sind aber für einige Sekunden nicht erreichbar, während die Plattform neu startet. |
| Der Server wird neu gestartet (Wartung) | Apps und Datenbanken fahren danach von selbst wieder hoch. Geplante Unterbrechungen kündigen wir 48 Stunden vorher auf der Statusseite an. |
| Der Server fällt ganz aus | Dann stellen wir auf einem Ersatzserver aus der Sicherung außer Haus wieder her. Das dauert Stunden, nicht Minuten, und was seit der letzten nächtlichen Sicherung dazugekommen ist, kann verloren sein – im schlimmsten Fall knapp 24 Stunden. |
Was noch aussteht
Ehrlichkeit gehört zur Sicherheit:
- Kein zweiter Standort – fällt das Rechenzentrum aus, sind die Apps offline
- Sicherung einmal pro Nacht, keine Wiederherstellung auf einen beliebigen Zeitpunkt
- Keine Zertifizierung nach ISO 27001 oder C5
- Keine Verschlüsselung der Festplatte im Ruhezustand
- Plattengrenzen setzt die Plattform durch, nicht das Dateisystem – zwischen zwei Messungen kann ein Kontingent für einige Minuten überschritten werden
Wer eine dieser Anforderungen erfüllen muss, ist bei einem größeren Anbieter derzeit besser aufgehoben – das sagen wir lieber vorher als nachher.
Häufige Fragen
Wer hat Zugriff auf meine Daten?
Technisch der Betreiber, soweit es für den Betrieb nötig ist. Zugriffe erfolgen nicht routinemäßig und nur zur Fehlerbehebung.
Gibt es eine Verfügbarkeitsgarantie?
Derzeit keine zugesicherte Verfügbarkeit in Prozent. Bei einem Einzelstandort wäre jede Zusage unseriös.
Wie viele Daten können bei einem Ausfall verloren gehen?
Bei einem Absturz oder Neustart keine. Nur wenn der ganze Server verloren ginge, wird aus der nächtlichen Sicherung wiederhergestellt – dann fehlt, was seit der letzten Sicherung dazugekommen ist, höchstens knapp 24 Stunden.