Operated Service
OffRecord by Somos-Co
Anwendungen mit definierter Security Baseline und dokumentiertem Betriebsmodell betreiben lassen.
- Rolle
- Eigener Managed Service
- Status
- Aktives kommerzielles Angebot
- Einordnung
- Operated Service
Architektur
Ablauf
- Delivery
- Anwendung online
- Anfrage
- Betrieb
Entwicklungsumgebung · Delivery 1/3Ausgangspunkt einer Änderung: Entwicklung und lokale Prüfung, bevor sie in den definierten Delivery-Prozess übergeht.
CI/CD · Delivery 2/3Änderungen laufen über die definierte Pipeline — bauen, testen und versionieren — bevor sie in die Zielumgebung gelangen.
Deployment · Delivery 3/3Der kontrollierte Schritt in die Umgebung: definierte Deployment-Prozesse statt manueller Eingriffe.
Internet · Anfrage 1/3Der öffentliche Einstieg. Alles dahinter läuft über einen kontrollierten Traffic-Pfad.
Edge / Origin Shield · Anfrage 2/3Edge- und Origin-Shield-Layer vor dem Cluster — der Anfragepfad beginnt nicht direkt an der Anwendung.
Ingress · TLS · Anfrage 3/3Ingress mit TLS-Terminierung und Routing bildet den kontrollierten Pfad zur Anwendung.
K3s-Cluster · SystemgrenzeDie Kubernetes- bzw. K3s-Umgebung, abgegrenzt über RBAC und Network Policies.
Namespace · SystemgrenzeDer abgegrenzte Bereich im Cluster, in dem die Anwendung läuft. Network Policies, RBAC und Network Segmentation wirken auf dieser Grenze.
Anwendung · Ziel beider WegeDie betriebene Anwendung, containerisiert im eigenen Namespace. Beide Wege — Anfrage und Delivery — enden hier.
Monitoring · BetriebskanalMonitoring und Alerting machen den Systemzustand sichtbar; Incident-Workflows sind dokumentiert.
Backup / Restore · BetriebskanalBackup und Restore als dokumentierter Teil des Betriebsmodells.
Der Ablauf beginnt in der Entwicklungsumgebung. Eine Änderung läuft von dort über CI/CD und einen kontrollierten Deployment-Schritt in die Anwendung, die danach online ist. Anschließend verläuft der Anfragepfad vom Internet über einen Edge- und Origin-Shield-Layer zum Ingress mit TLS-Terminierung und von dort zur Anwendung. Im Betrieb machen Monitoring und Alerting den Systemzustand sichtbar; Backup und Restore sind Teil des Betriebsmodells. Der Cluster ist über RBAC und Network Policies abgegrenzt.
Kontext
OffRecord by Somos-Co ist ein Managed-Platform-Service für Anwendungen, die zuverlässig laufen müssen, aber kein eigenes Betriebsteam rechtfertigen. Der Service umfasst die Kubernetes- bzw. K3s-Umgebung, den Betrieb der Anwendungen darauf und die zugehörigen Betriebsprozesse.
Geschäftliches Problem
Viele Organisationen können eine Anwendung entwickeln oder entwickeln lassen, haben aber keinen belastbaren Betrieb dafür: Updates werden manuell eingespielt, niemand sieht den Systemzustand, Backups existieren, wurden aber nie zurückgespielt, und im Störungsfall ist unklar, wer entscheidet. Das Problem ist selten die Technologie, sondern die fehlende Betriebsverantwortung.
Mandat und Rolle
Verantwortung von Somos-Co
OffRecord ist ein eigenes Angebot von Somos-Co. Somos-Co übernimmt die technische Betriebsverantwortung im vereinbarten Umfang.
Verantwortung von Partner/Kunde
Die fachliche Verantwortung für die betriebene Anwendung bleibt beim Kunden.
Außerhalb der Rolle
Vollständige Penetrationstests, Red Teaming und formale regulatorische Security Audits sind nicht Teil des Service; der vereinbarte Umfang ergibt sich jeweils aus dem Vertrag.
Vorgehen
- 1
Bereitstellung einer Managed-Kubernetes- bzw. K3s-Umgebung
- 2
Definition und Umsetzung einer Security Baseline
- 3
Aufbau eines kontrollierten Traffic-Pfads einschließlich Origin Shield
- 4
Einrichtung von Monitoring und Alerting
- 5
Einrichtung und Prüfung von Backups
- 6
Dokumentation der Betriebsprozesse
Technischer Umfang
Plattform
- Managed Kubernetes/K3s
- Routing, Ingress, TLS und Origin Shield
Betrieb
- Security Baseline, Hardening, Network Policies, RBAC und Secrets Management
- Monitoring, Alerting und Logging
- Backup und Restore
- Kontrollierte Deployment- und Betriebsprozesse
Betriebsmodell
Der Betrieb folgt dokumentierten Prozessen: Änderungen laufen über definierte Deployment-Pfade, der Systemzustand ist über Monitoring sichtbar, Backups werden regelmäßig erstellt und Wiederherstellungen werden geprüft. Die Zuständigkeiten zwischen Somos-Co und Kunde sind schriftlich abgegrenzt.
Aktueller Status
OffRecord ist ein aktives kommerzielles Angebot mit ersten wirtschaftlich vergüteten Kunden beziehungsweise Plattformpartnerschaften.
Ergebnis und Belege
- Betriebene Umgebungen verfügen über eine definierte Security Baseline statt über gewachsene Einzelkonfigurationen.
- Der Systemzustand ist über Monitoring sichtbar.
- Backups sind eingerichtet und die Wiederherstellung ist geprüft.
- Betriebsverantwortung und Eskalationswege sind dokumentiert.
Grenzen dieser Aussagen
- Eine Security Baseline reduziert Risiko; absolute Sicherheit wird nicht behauptet und kann nicht zugesagt werden.
- Es werden keine Verfügbarkeits- oder SLA-Werte auf dieser Seite veröffentlicht; der jeweils vereinbarte Umfang ergibt sich aus dem Vertrag.
- Der Service umfasst keine vollständigen Penetrationstests, kein Red Teaming und keine formalen regulatorischen Security Audits.
- Die fachliche Verantwortung für die betriebene Anwendung bleibt beim Kunden.
Nächster Schritt
Ausbau der Betriebsautomatisierung und der Observability entlang des tatsächlichen Bedarfs der betriebenen Anwendungen.
Problem Check
Welche geschäftliche Entscheidung braucht eine belastbare Grundlage?
Beschreiben Sie Herausforderung, betroffenen Prozess und Zeithorizont. In einem ersten Problem Check klären wir, welche Fragen ein Dynamic Model beantworten sollte.
Für Anwendungen, Plattformen, IoT- und Digital-Twin-Vorhaben sowie Managed Operations.