Wie wir Itamite
von innen absichern.
Es reicht nicht aus, dass Frameworks bestätigen, dass Sie konform sind. Hier erläutern wir, was wir in den Bereichen Architektur, Kryptografie, Betrieb, Hardening, Supply Chain und Incident Response tun, damit Itamite wirklich sicher ist. Kein Marketing, sondern konkrete, überprüfbare Details.
Sicherheitsphilosophie
Itamite verwaltet sensible Inventare und ermöglicht die Fernsteuerung über Endpunkte kritischer Organisationen: Krankenhäuser, öffentliche Verwaltungen, Banken, Fintechs, Steuerkanzleien. Ein Sicherheitsvorfall bei Itamite ist nicht unser Vorfall; er ist ein Vorfall für alle Kunden gleichzeitig. Deshalb arbeiten wir nach dem Prinzip "secure by design, secure by default, secure by operation": Das Design verhindert ganze Fehlerkategorien, die Voreinstellungen sind sicher und der Betrieb wird kontinuierlich auditiert.
Das unveränderliche Hash-Chain-Audit, das Itamite seinen Kunden bietet, wenden wir auch auf unseren eigenen internen Betrieb an: Jeder Produktionszugriff eines Itrion-Technikers wird mit überprüfbarem SHA-256 protokolliert. Jede Änderung der Konfiguration eines Tenants erhält einen kryptografischen Zeitstempel. Null Ausnahmen für Administratoren. Würde Itrion morgen gehackt, wären die Logs nachweislich unveränderlich.
Wir veröffentlichen diese Seite bewusst ausführlich, weil wir glauben, dass Transparenz Teil der Sicherheit ist. Wenn wir nur "we take security seriously" ohne Details sagen, können Sie nichts überprüfen. Daher erklären wir Architektur, kryptografische Entscheidungen, Betrieb, Cluster-Hardening, Supply Chain, Pentesting-Programm und Incident-Response-Prozess mit konkreten Daten.
Wie die Sicherheit von Itamite aufgebaut ist
Strikte Multi-Tenant-Isolation
Jeder Tenant verfügt über eine separate logische Datenbank mit tenant_id in allen Tabellen und RLS (Row Level Security) in PostgreSQL. Kubernetes-Cluster mit NetworkPolicies, die den Verkehr pro Namespace segmentieren. Für Enterprise: Single-Tenant-Option mit dediziertem Kubernetes-Cluster und BYOK.
Verschlüsselung at-rest und in-transit
TLS 1.3 verpflichtend für alle Kommunikationen (Agent-Server, Client-Server, Server-DB). AES-256-GCM-Verschlüsselung at-rest für PostgreSQL und MinIO/S3. Für hochsensible Daten (Audit-Logs): Verschlüsselung auf Anwendungsebene mit Schlüssel pro Tenant. Optionales BYOK für Enterprise.
E2E-Remote-Sitzungen
Ephemerer Diffie-Hellman für jede Remote-Control-Sitzung. Nicht einmal Itrion kann den Bildschirm-, Audio- oder Tastaturinhalt während einer Sitzung lesen. Nur Metadaten (wer hat zugegriffen, wann, Dauer) bleiben in den Logs. Optionale Aufzeichnung mit signiertem SHA-256, gespeichert im Kunden-MinIO/S3.
Unveränderliches Hash-Chain-Audit
Jedes Ereignis (Zugriff, Konfigurationsänderung, Remote-Sitzung, Inventar, ausgeführter Befehl) wird im Log mit SHA-256 erfasst, der den Hash des vorherigen Logs enthält. Jede rückwirkende Änderung bricht die Kette und ist erkennbar. Unveränderlich selbst durch Itrion-DBAs.
Hardening des Kubernetes-Clusters
CIS Kubernetes Benchmark v1.8 vollständig angewendet. Pod Security Standards "restricted". NetworkPolicies pro Namespace. Service Mesh (Istio) mit automatischem mTLS. Secrets verschlüsselt mit sealed-secrets + external-secrets aus HashiCorp Vault. Ingress mit WAF (ModSecurity + OWASP CRS).
Supply-Chain-Sicherheit
SBOM für jedes Release veröffentlicht (Format SPDX + CycloneDX). Docker-Images signiert mit cosign + sigstore. SLSA-Level-3-Provenance-Attestations. Renovate Bot zur Erkennung verwundbarer Abhängigkeiten. CI/CD lehnt Merges ab, wenn kritische CVEs ungepatcht sind.
Betrieb und Reaktion
Jährliches Pentesting-Programm mit BDO Madrid: drei Wochen Testing, detaillierter Bericht, verpflichtende Behebung vor Veröffentlichung. Öffentliches Bug Bounty ab Q3 2026. Internes SOC mit 24x7-Erkennung (Wazuh + Grafana + Alarme an rotierendes Bereitschaftsteam). RTO <4h, RPO <15 min für Enterprise. Verschlüsselte Off-Site-Backups mit MinIO-Replikation in drei verschiedene EU-Rechenzentren. Incident-Response-Prozess: automatische Erkennung + Schweregradanalyse + Eskalation an den CISO von Itrion + Kommunikation an betroffene Kunden in <2h für bestätigte Vorfälle + öffentliches Post-Mortem 7 Tage später mit Root Cause und Präventivmaßnahmen. Transparente Politik: Wir kommunizieren Vorfälle auch dann, wenn wir gesetzlich nicht dazu verpflichtet wären.
- Jährliches Pentesting: BDO Madrid (unabhängige Firma)
- Internes SOC 24x7: permanente rotierende Bereitschaft
- RTO <4h, RPO <15 min: für Enterprise-Kunden
- Verschlüsselte Backups: repliziert in 3 EU-Rechenzentren
- Transparente Politik: Kommunikation von Vorfällen in <2h
Fragen zur Plattformsicherheit
Kann ich den letzten Pentesting-Bericht anfordern?
Was passiert, wenn Itrion gehackt wird?
Ist BYOK verfügbar?
Sind Sie ISO 27001 konform?
Weitere Details unter NDA
Wenn Sie den vollständigen Pentesting-Bericht, die detaillierte technische Architektur oder eine Sicherheits-Due-Diligence benötigen: kontaktieren Sie uns.