Die Plattform

Eine Plattform, die wir bis zur letzten Schicht kennen.

Wir haben sie nicht gemietet, sondern gebaut: jede Komponente ausgewählt, gehärtet, dokumentiert und automatisiert. Hier legen wir offen, wie sie funktioniert.

Schichtenmodell

Von außen nach innen.

Sechs Schichten, jede mit klarer Aufgabe und eigener Netzzone. Was nicht ausdrücklich erlaubt ist, ist gesperrt.

  1. 01
    Edge

    Eingang und Abwehr

    Reverse Proxy mit automatischen TLS-Zertifikaten, Ratenbegrenzung und verhaltensbasierter Abwehr. Öffentlich ist nur, was ausdrücklich freigegeben wurde.

    Reverse ProxyVerhaltensanalyseTLS automatisch
  2. 02
    Zugang

    Zero Trust

    Code-Plattform, Registry, Monitoring und SIEM sind nicht öffentlich. Der Zugriff führt über ein verschlüsseltes Overlay-Netz mit Single Sign-on und zweitem Faktor.

    Overlay-Netzzentrale IdentitätWebAuthn
  3. 03
    Plattform

    Bauen und Ausrollen

    Eigene Code-Plattform mit CI und Registry. Jede Änderung läuft zuerst auf eine getrennte Entwicklungsumgebung. Ausgerollt wird ein geprüftes Abbild.

    eigene Code-PlattformCI/CDRegistryImage-Digest
  4. 04
    Laufzeit

    Isolierte Anwendungen

    Jedes Projekt läuft mit eigener Kennung, schreibgeschütztem Dateisystem, ohne Sonderrechte und mit erzwungenen Quoten.

    ContainerQuotenEgress gesperrt
  5. 05
    Beobachtung

    Erkennen und reagieren

    Logs, Metriken und Sicherheitsereignisse laufen zentral zusammen. Ein IDS liest den Netzwerkverkehr mit, Alarme gehen direkt an die Betreiber.

    SIEMIDSMetrikenzentrale LogsAlarme mit Anweisung
  6. 06
    Fundament

    Hardware und Sicherung

    Dedizierte Server in einem deutschen Rechenzentrum, getrennte Netzzonen, nächtliche Sicherungen und geprobte Wiederherstellung. Alles als Code beschrieben.

    dedizierte HardwareVirtualisierungInfrastruktur als CodeRestore geprobt
Plattform / 01 von 06
https://ihre-firma.de A-EINTRAGTXT-BINDUNGAUTOMATISCHERNEUERT

Edge

Eingang und Abwehr

Jede Anfrage aus dem Internet trifft zuerst auf den Eingang. Er spricht TLS, kennt jeden freigegebenen Namen und weist alles andere ab.

So funktioniert es

  1. Automatische Zertifikate für jede freigegebene Domain.
  2. Ratenbegrenzung gegen Überlastung einzelner Dienste.
  3. Verhaltensbasierte Abwehr sperrt auffällige Adressen vorübergehend.
  4. Interne Oberflächen haben einen eigenen, nicht öffentlichen Eingang.

So prüfen wir es

Die Liste der öffentlichen Namen wird automatisch gegen die Router geprüft; ein unbekannter Name bekommt keine Antwort.

Grenze

Ein einzelner Eingang ist ein Engpass. Verfügbarkeitsanforderungen besprechen wir projektbezogen.

Reverse ProxyVerhaltensanalyseTLS automatisch
Plattform / 02 von 06
GERÄT WEBAUTHN SSO DIENST

Zugang

Zero Trust

Interne Werkzeuge sind aus dem Internet unsichtbar. Der Weg dorthin führt über ein zugelassenes Gerät und eine starke Anmeldung.

So funktioniert es

  1. Overlay-Netz mit zugelassenen Geräten, Ende zu Ende verschlüsselt.
  2. Zentrale Anmeldung mit zweitem Faktor, als Regel WebAuthn.
  3. Rollen trennen Betrieb und Entwicklung.
  4. Server und Hypervisor erreichen wir über einen eigenen verschlüsselten Tunnel mit Geräteschlüssel. Er bleibt nutzbar, auch wenn Anmeldedienste ausfallen.

So prüfen wir es

Die Überwachung prüft alle fünf Minuten, dass Betriebsoberflächen ohne Sitzung nichts preisgeben.

Grenze

Personengebundene Konten verlangen Disziplin beim Ein- und Austritt. Dafür gibt es ein festes Verfahren.

Overlay-Netzzentrale IdentitätWebAuthn
Plattform / 03 von 06
PUSHBAUENDEVPROD sha256:7f48…c315 FREIGABE

Plattform

Bauen und Ausrollen

Vom Push bis zur Produktion nimmt jede Änderung denselben Weg. Was live geht, ist exakt das Abbild, das vorher geprüft wurde. Erkennbar ist es an seinem Digest.

So funktioniert es

  1. Eigene Code-Plattform mit Registry, nur über das Overlay-Netz erreichbar.
  2. Bauen ohne Netzzugriff, dann Tests im fertigen Abbild.
  3. Ausrollen zuerst in die Entwicklung, nach Freigabe in die Produktion.
  4. Die Produktion zieht den Stand selbst; einen offenen Zugang hinein gibt es nicht.

So prüfen wir es

Eine Zulassungsprüfung vergleicht jeden Vorschlag mit den Regeln, bevor er freigegeben werden kann.

Grenze

Freigaben für die Produktion bleiben bewusst beim Menschen.

eigene Code-PlattformCI/CDRegistryImage-Digest
Plattform / 04 von 06
PROJEKT A QUOTEPROJEKT B QUOTEPROJEKT C QUOTE EIGENES NETZ JE PROJEKT

Laufzeit

Isolierte Anwendungen

Anwendungen teilen sich Maschinen, aber nicht ihre Rechte. Jede läuft in ihrem eigenen Raum mit Grenzen, die der Kernel durchsetzt.

So funktioniert es

  1. Eigene Kennung und eigene Netze je Projekt.
  2. Schreibgeschützt, ohne Root, ohne Sonderrechte.
  3. Erzwungene Quoten für Speicher, CPU und Platte.
  4. Kein ausgehender Internetzugang in Produktion.

So prüfen wir es

Ein Gesundheitstor entscheidet nach jedem Ausrollen: läuft die neue Version, bleibt sie; sonst kommt die vorige zurück.

Grenze

Für besonders schutzbedürftige Anwendungen planen wir eigene Maschinen ein.

ContainerQuotenEgress gesperrt
Plattform / 05 von 06
HOSTNETZAUTH SIEM ALARM

Beobachtung

Erkennen und reagieren

Wir wollen von einem Problem wissen, bevor Sie es bemerken. Dafür sammeln wir Metriken, Logs und Sicherheitsereignisse an einem Ort.

So funktioniert es

  1. Metriken und Logs aller Maschinen, mit festgelegten Aufbewahrungsfristen.
  2. SIEM mit Dateiintegrität, Härtungsprüfungen und Korrelation.
  3. IDS zwischen den Netzzonen.
  4. Alarme mit Ursache und Handlungsanweisung, direkt an die Betreiber.

So prüfen wir es

Die Überwachung überwacht sich selbst: Fällt ein Sensor aus, ist das ein Alarm.

Grenze

Alarme laufen über unsere eigene Infrastruktur; für deren Ausfall gibt es einen getrennten Notweg.

SIEMIDSMetrikenzentrale LogsAlarme mit Anweisung
Plattform / 06 von 06
DATEN SICHERUNG NÄCHTLICHRESTORE-PROBE

Fundament

Hardware und Sicherung

Unter allem liegt dedizierte Hardware, die nur wir verwalten. Wie sie konfiguriert ist, steht vollständig im Code und lässt sich daraus wieder herstellen.

So funktioniert es

  1. Dedizierte Server in Deutschland, keine geteilten Hypervisoren mit Fremden.
  2. Virtualisierung mit getrennten Maschinen je Aufgabe.
  3. Nächtliche Sicherungen und regelmäßige Wiederherstellungsproben.
  4. Jede Konfiguration versioniert und automatisch geprüft.

So prüfen wir es

Über 200 automatisierte Prüfungen vergleichen Konfiguration und laufendes System.

Grenze

Ein Standort ist ein Standort. Was mehr Redundanz braucht, planen wir ausdrücklich ein.

dedizierte HardwareVirtualisierungInfrastruktur als CodeRestore geprobt

Der Weg einer Anfrage

Was passiert, wenn jemand Ihre Seite aufruft.

Drei Wege durch unsere Plattform: vom Browser über den Eingang bis in den Container. Und einer, der dort endet, wo er enden soll.

GET/leistungen/200 OKSchematisch · Beispielwerte
  1. 01 / ClientBrowserAnfrage über HTTPS
  2. 02 / EdgeEingangTLS, Router, Abwehr
  3. 03 / PoolProjekt-ProxyWeiterleitung je Projekt
  4. 04 / LaufzeitContainerIhre Anwendung
  5. 05 / DatenDatenbanknicht beteiligt
  6. 06 / AusgangInternetnicht beteiligt

Schnell ausgeliefert.

Die Seite kommt direkt aus dem Container, vorkomprimiert und mit Sicherheitsköpfen. Eine Datenbank wird nicht gebraucht.

  1. 0 msBrowserTLS 1.3 zum Eingang aufgebaut
  2. 2 msEdgeRouter für die Domain gefunden, Ratenbegrenzung eingehalten
  3. 3 msEdgeVerhaltensbasierte Abwehr: keine Sperre
  4. 4 msPoolWeiterleitung in das Netz des Projekts
  5. 6 msContainerDatei aus dem Speicher, Brotli, ETag
  6. 9 msBrowser200 OK, Seite steht

Der Weg einer Änderung

Weitergereicht wird ein Abbild, kein Quelltext.

Die Produktion zieht sich den freigegebenen Stand selbst. Es gibt keinen offenen Zugang, über den jemand von außen hineinschieben könnte.

  1. Push

    Code landet auf der eigenen Code-Plattform, nur über das Zero-Trust-Netz erreichbar.

    Keine öffentliche Code-Ablage

  2. Pipeline

    Bauen ohne Netzzugriff, Tests, Abbild mit eindeutigem Digest in die eigene Registry.

    Reproduzierbar

  3. Entwicklung

    Ein Agent auf der Entwicklungsmaschine übernimmt den Digest und startet ihn isoliert.

    Getrennte Maschine

  4. Produktion

    Nach Freigabe zieht der Agent in Produktion denselben Digest. Gesundheitstor oder Rückfall.

    Kein lauschender Dienst

Für Entwicklerteams

Eine Datei. Der ganze Betrieb.

Port, Gesundheitsprüfung, Ressourcen, Datenbank, Hintergrunddienste, Geheimnisse und Domains: Ihr Team beschreibt, was die Anwendung braucht. Die Plattform kümmert sich um den Rest, inklusive Quoten, die der Kernel erzwingt.

# rb-projekt.yml: die einzige Datei, in der Ihr Team den Betrieb beschreibt
schema_version: 1
web:
  port: 8080
  gesundheitspfad: /healthz      # scheitert er, läuft der vorige Stand weiter
  speicher_mib: 512
  cpu: 0.50
schreibpfade: [uploads]          # gesichert in Produktion, jede Nacht
geheimnisse: [API_SCHLUESSEL]   # Werte verschlüsselt im Repository
domains: [ihre-firma.de]       # Zertifikat kommt automatisch
platte_gib: 5
rueckfall: automatisch

Prinzipien

Wie wir bauen.

01 Alles als CodeServer, Netze, Firewall, Dienste und Prüfungen sind versioniert beschrieben.

Was nicht im Repository steht, gibt es auf der Plattform nicht. Jede Änderung ist nachvollziehbar, hat einen Autor und lässt sich zurücknehmen. Fällt eine Maschine aus, entsteht sie aus derselben Beschreibung neu.

Woran Sie es merken
  • Jede Änderung hat eine Begründung im Verlauf.
  • Wiederherstellung ist ein wiederholbarer Ablauf, kein Gedächtnisspiel.
  • Neue Umgebungen sehen exakt wie die bestehenden aus.
02 Geschlossen als StandardFirewalls schlagen im Fehlerfall zu, nicht auf. Produktion hat keinen freien Internetzugang.

Wir erlauben Wege einzeln und ausdrücklich. Fehlt eine Regel oder scheitert ihr Laden, bleibt alles gesperrt: sicherer Zustand statt offener Tür.

Woran Sie es merken
  • Öffentlich ist nur, was auf einer Liste steht.
  • Ausgehende Verbindungen aus der Produktion werden verworfen.
  • Updates laufen in kurzen, festen Fenstern.
03 Geringste RechtePersonengebundene Konten, Gruppen je Aufgabe, zweiter Faktor. Anwendungen ohne Sonderrechte.

Jede Person und jede Anwendung bekommt genau die Rechte, die ihre Aufgabe braucht. Wer mehr braucht, bekommt es begründet, und es wird wieder entzogen.

Woran Sie es merken
  • Keine geteilten Administratorkonten.
  • Container laufen ohne Root und schreibgeschützt.
  • Rollen trennen Betrieb und Entwicklung.
04 Beobachten statt hoffenMetriken, Logs und Sicherheitsereignisse laufen zentral zusammen. Alarme haben eine Handlungsanweisung.

Ein System, das niemand beobachtet, ist ein Glücksspiel. Wir messen, sammeln und werten aus, und jeder Alarm sagt, was zu tun ist.

Woran Sie es merken
  • Ausfälle fallen uns auf, bevor Sie sich melden.
  • Auch die Überwachung wird überwacht.
  • Alarme gehen direkt an die Betreiber.
05 Aktualität mit SystemJede Komponente ist auf eine Version festgelegt und wird alle sechs Stunden mit Herstellermeldungen abgeglichen.

Updates sind kein Bauchgefühl. Ein Wächter kennt jede Version, vergleicht sie mit dem Hersteller und meldet Sicherheitslücken sofort.

Woran Sie es merken
  • Keine wandernden Versionen.
  • Sicherheitsmeldungen lösen sofort eine Benachrichtigung aus.
  • Rückstände werden nach sieben Tagen gemeldet.
06 Ehrlich dokumentiertJede Phase hat ein Protokoll, das zwischen geplant, geprüft und getestet unterscheidet.

Wir schreiben auf, was wir tun und wie belastbar es ist. „Auf dem Zielsystem getestet“ heißt bei uns genau das, nicht „sollte funktionieren“.

Woran Sie es merken
  • Grenzen stehen in der Dokumentation, nicht im Kleingedruckten.
  • Messwerte haben Datum und Methode.
  • Offene Punkte sind sichtbar.

Betrieb in Zahlen

Was wir messen.

7

getrennte Netzzonen: Verwaltung, Edge, Kerndienste, Produktion, Entwicklung, CI und Überwachung

Segmentierung

6h

Takt des Abgleichs aller Komponenten mit Herstellermeldungen

Release-Wächter

200+

automatisierte Prüfungen gegen Konfiguration und laufendes System

Nach jeder Änderung

5min

höchstens, bis die Produktion einen freigegebenen Stand übernimmt

Ziehender Agent

Sicherheit und Souveränität im Detail

Kontakt

Ihre Anwendung auf unsere Plattform?

Wir prüfen gemeinsam, was Ihre Anwendung braucht, und planen den Umzug mit Probelauf und Rückweg.