Architektur & Sicherheit
Sicherheit und Compliance
Identity, Secrets, Policy und Datenresidenz-Haltung für gh0stcloud.
gh0stcloud nutzt ein kontrolliertes Plattformmodell: Nutzer arbeiten über Portal-, API- und GitOps-Workflows; Plattform-Policy entscheidet, was erlaubt ist; Secret-Werte bleiben aus Git heraus.
Sicherheitsmodell
| Bereich | Ansatz |
|---|---|
| Identity | OIDC-basierte Authentifizierung und organizationsbewusster Zugriff. |
| Autorisierung | Tenant- und Capability-Checks im Plattformworkflow. |
| Secrets | Secret-Werte laufen über den konfigurierten Secret-Backend-/Workflow, nicht über Git. |
| Policy | Runtime- und Tenant-Aktionen werden durch Plattform-Policy und Tenant Limits begrenzt. |
| GitOps | Gewünschter Anwendungszustand ist versioniert und reconciled statt manuell angewendet. |
| Auditierbarkeit | Git History, Portalzustand, Billing State und Support-/Request-Workflows liefern Nachvollziehbarkeit, sofern verfügbar. |
Shared Responsibility
| Bereich | gh0stservice | Kunde |
|---|---|---|
| Plattformbetrieb | Verantwortet | - |
| Plattformpatching und Lifecycle | Verantwortet | - |
| Tenant Policy und Guardrails | Verantwortet | Prüft und beantragt Änderungen |
| Anwendungscode | - | Verantwortet, sofern Managed Scope nichts anderes sagt |
| Anwendungsdependencies | - | Verantwortet, sofern Managed Scope nichts anderes sagt |
| Secret-Werte | Stellt Workflow | Verantwortet Werte und sichere Behandlung, sofern Managed Scope nichts anderes sagt |
| Anwendungsbetrieb | Abhängig vom Modell | Abhängig vom Modell |
Compliance-Wording
Öffentliche Docs sollten Audit-Status, Penetration-Test-Cadence, exakte Datenlokation oder rechtliche Zusagen nicht überziehen. Diese Punkte gehören in aktuelle Evidence Packages, Kundenverträge und Datenschutzdokumente.
Für Kundenprüfungen sollten aktuelle Sicherheits- und Vertragsunterlagen angefragt werden, statt Marketingcopy als Nachweis zu nutzen.
Fragen oder bereit loszulegen?
Mit uns sprechen