Entwurf v1.0

Autoren: Energent.ai Sicherheits- & Engineering-Team

Zusammenfassung

Energent.ai bietet einen KI-gestützten virtuellen Desktop-Agenten, der komplexe Multi-Anwendungs-Workflows für Unternehmensbenutzer automatisiert. Da der Agent mit sensiblen Geschäftsdaten arbeitet und möglicherweise umfassende Berechtigungen auf Benutzer-Desktops und Cloud-Ressourcen erhält, sind Sicherheit und Datenschutz grundlegend für unser Produktdesign. Dieses Whitepaper dokumentiert das Bedrohungsmodell, die Verteidigungsarchitektur, die Sicherheitskontrollen und die Compliance-Position der Energent-Plattform. Es basiert auf dem strukturierten, datengestützten Ansatz, der im CambioML AnyParser-Whitepaper verwendet wird, und orientiert sich an den Best Practices des AWS Well-Architected Security Pillar sowie den Sicherheitskontrollrichtlinien von NIST SP 800-53 Rev 5.

Inhaltsverzeichnis

1. Einführung
2. Energent-Plattformarchitektur
3. Bedrohungsmodell
4. Sicherheitskontrollen
5. Compliance & Governance
6. Betriebliche Sicherheit
7. Kundenbereitstellungsoptionen
8. Fazit
9. Anhang A – Kontrollzuordnung
10. Referenzen

1 Einführung

1.1 Zweck

Dieses Dokument ermöglicht es Sicherheits-, IT- und Compliance-Teams zu bewerten, ob Energent.ai ihre organisatorischen Sicherheitsanforderungen erfüllt. Es beschreibt, wie wir Daten, Systeme und Benutzer während des Agentenlebenszyklus schützen, von der Entwicklung bis zu den Produktionsoperationen.

1.2 Umfang

• Energent Cloud (SaaS). Multi-Tenant-Service, der von Energent.ai auf AWS betrieben wird.
• Private Cloud / VPC-Isoliert. Dedizierter Single-Tenant-Stack, der in einem vom Kunden kontrollierten Konto auf AWS, Azure oder GCP bereitgestellt wird.
• On-Prem/VM. Luftdicht abgeschottetes Linux-VM-Image für hochregulierte Umgebungen.

1.3 Zielgruppe

CISOs, Sicherheitsarchitekten, DevOps-Ingenieure, Auditoren und Beschaffungsexperten, die Energent.ai bewerten.

2 Energent-Plattformarchitektur

2.1 Hochrangige Komponenten

Abbildung 1. Logische Ansicht der Energent-Komponenten und Vertrauensgrenzen.

2.2 Sicherheitsprinzipien nach Design

1. Geringste Privilegien & Mikrosegmentierung. IAM-Rollen und Sicherheitsgruppen beschränken jeden Dienst auf die minimal erforderlichen Berechtigungen.
2. Ende-zu-Ende-Verschlüsselung. TLS 1.2+ für Daten in Bewegung; AES-256-GCM für Daten im Ruhezustand unter Verwendung von KMS-verwalteten Schlüsseln.
3. Unveränderliche Infrastruktur. Alle Compute-Knoten werden aus signierten AMIs neu aufgebaut; keine Änderungen vor Ort.
4. Kontinuierliche Compliance-Automatisierung. Leitplanken in IaC und AWS Config-Regeln kodifiziert, um Abweichungen zu erkennen.

3 Bedrohungsmodell

3.1 Vermögenswerte

• Benutzeranmeldeinformationen und API-Tokens
• Workflow-Artefakte (Screenshots, extrahierte Daten, generierte Dokumente)
• Proprietäre Workflow-Logik

3.2 Gegner & Fähigkeiten

3.3 Vertrauensgrenzen

• Tenant-Isolierung zwischen Kunden-Stacks.
• Trennung zwischen Steuer- und Datenebene.
• In-VM-Sandbox vs. Host-Umgebung.

4 Sicherheitskontrollen

4.1 Identität, Authentifizierung & Autorisierung

• SSO über SAML 2.0 / OIDC mit MFA-Durchsetzung.
• Fein abgestufte ABAC IAM-Richtlinien für alle Mikrodienste.
• Just-in-Time (JIT) privilegierter Zugriff mit automatischer Ablauffrist.

4.2 Netzwerk- & Infrastruktursicherheit

• VPC-ebene Egress-Only-Gateways; keine öffentlichen Lastenausgleicher im Private-Cloud-Modus.
• Alle API-Verkehr wird an AWS ALB mit WAF WebACL (OWASP Top 10-Regelsatz) beendet.
• Opt-in private Konnektivität über AWS PrivateLink oder Kunden-VPN.

4.3 Datenschutz

• Server-seitige Verschlüsselung (SSE-KMS) für S3; Client-seitige Verschlüsselungs-SDK verfügbar.
• Feldbasierte Verschlüsselung für PII/PHI unter Verwendung von AES-256 + Umschlüssel.
• Automatische Schlüsselrotation und pro-Mieter CMKs.

4.4 Anwendungssicherheit

• Sichere Codierungsstandards (OWASP ASVS L2).
• Automatisierte SCA, SAST und DAST-Pipelines, die in CI/CD integriert sind.
• Abhängigkeitssperren mit verifizierten PyPI/npm-Signaturen.

4.5 Geheimnis- & Schlüsselverwaltung

• Geheimnisse werden in AWS Secrets Manager mit automatischer Rotation gespeichert.
• Agenten ziehen zeitlich begrenzte Sitzungstokens über STS AssumeRole, niemals langfristige Schlüssel.

4.6 Sicherer Entwicklungslebenszyklus

• Bedrohungsmodellierung für jedes Epic (STRIDE-Methodik).
• Code-Reviews erfordern die Genehmigung durch zwei Personen und das Bestehen von Sicherheits-Gates.
• Reproduzierbare Builds mit Sigstore-Provenienz.

5 Compliance & Governance

5.1 Modell der gemeinsamen Verantwortung

Energent übernimmt den Ansatz der gemeinsamen Verantwortung von AWS, bei dem AWS die zugrunde liegende Cloud „der Cloud“ sichert und Energent alles „in der Cloud“ sichert.

5.2 Audit-Zertifizierungen (In Bearbeitung 2025)

5.3 Kontrollzuordnung

Anhang A bietet eine detaillierte Zuordnung der Energent-Kontrollen zu den NIST SP 800-53 Rev 5-Familien (AC, AU, SC, SI usw.).

6 Betriebliche Sicherheit

6.1 Überwachung, Erkennung & Reaktion

• Zentrale Protokollaggregation in Amazon OpenSearch mit unveränderlichen S3-Backups.
• GuardDuty, Inspector und Security Hub ermöglichen kontinuierliche Bedrohungserkennung.
• 24×7 erreichbares Security Incident Response Team (SIRT) mit dokumentierten Handbuchen.

6.2 Schwachstellenmanagement & Pen-Testing

• Wöchentliche Container-Image-Scans; kritische CVEs werden innerhalb von 24 Stunden gepatcht.
• Jährliche Penetrationstests von Dritten und vom Kunden in Auftrag gegebene Tests sind erlaubt.

6.3 Geschäftskontinuität & Notfallwiederherstellung

• Alle persistenten Daten werden in multi-AZ, versionierten S3 mit Cross-Region-Replikation gespeichert.
• RPO ≤ 15 Minuten, RTO ≤ 1 Stunde für kritische Dienste.

7 Kundenbereitstellungsoptionen

7.1 Energent Cloud (SaaS)

• Standardoption; schnellste Einarbeitung; erbt die Sicherheitsinfrastruktur von AWS.

7.2 Private Cloud / VPC-Isoliert

• Energent-Stack wird von Terraform in das Kunden-AWS-Konto bereitgestellt, mit Kontrolle über den Datenstandort.

7.3 On-Prem / VM-Only

• Offline-fähiges VM-Image; Hardware-Root-of-Trust-Bestätigung über TPM/SGX unterstützt.

8 Fazit

Energent.ai kombiniert Verteidigung-in-der-Tiefe-Engineering, rigorose Betriebsprozesse und transparente Compliance, um Kundendaten auf jeder Ebene zu schützen. Durch die Einhaltung führender Branchenrahmenwerke wie AWS Well-Architected und NIST SP 800-53 bieten wir eine Plattform, die sichere, skalierbare Automatisierung ermöglicht, ohne das Vertrauen der Benutzer zu gefährden.

Anhang A – Kontrollzuordnung (Auszug)

Vollständige Matrix auf Anfrage erhältlich.

Referenzen

1. AWS Well-Architected Framework – Sicherheits-Pfeiler, 6. Nov 2024
2. NIST SP 800-53 Rev 5, „Sicherheits- und Datenschutzkontrollen für Informationssysteme und Organisationen“, Sept 202
3. CambioML & Epsilla, „Erreichung von 2× Genauigkeit bei der Wissensretrieval aus Diagrammen und Tabellen“, 2. Aug 2024