Wie das Deployment von VirtoSoftware-Apps im eigenen Microsoft 365-Tenant die Datenweitergabe an Dritte ausschließt, SOC 2- und ISO 27001-Reviews verkürzt und Ihrem Sicherheitsteam das einzige gibt, was es wirklich braucht – Kontrolle.
Die versteckten Kosten des „Vertrauens" in SaaS-Anbieter
Jede CISO kennt das Muster. Ein neues Microsoft 365-Add-on landet auf dem Beschaffungsschreibtisch, die Fachabteilungen wollen es sofort, und das Security-Team soll die Freigabe erteilen. Was folgt, ist ein monatelanger Prozess: Sicherheitsfragebögen für Anbieter, SOC 2 Type II-Berichte, ISO 27001-Zertifikate, Penetrationstestzusammenfassungen, DPIAs, Sub-Processor-Listen und Vertragsverhandlungen zu Datenspeicherort, Meldepflichten bei Sicherheitsvorfällen und Audit-Rechten.
Das alles kostet – direkt in Form von Prüfgebühren und externen Gutachterrechnungen, und indirekt durch die Engineering-Stunden, die Ihr Team damit verbringt, Berichte über fremde Umgebungen zu sichten.
Und was haben Sie am Ende wirklich überprüft? Dass ein Dritter, zu einem bestimmten Zeitpunkt, in einem bestimmten Prüfungsumfang, über Kontrollen verfügte, die ein Auditor als angemessen bewertet hat. Sie haben nicht verifiziert, dass Ihre Daten – sobald sie in der Infrastruktur dieses Anbieters liegen – wirklich sicher sind vor Bedienungsfehlern, Insider-Risiken, versehentlichem Löschen, falsch konfigurierten Backups oder einem Sicherheitsvorfall, den der Anbieter erst nach 72 Stunden – oder noch später – melden muss.
Das eigentliche Problem ist struktureller Natur. Das SaaS-Modell verlangt, dass Sie Vertrauen nach außen ausdehnen: an den Anbieter, seinen Hosting-Dienstleister, seine Support-Ingenieure, die für die Fehlerdiagnose temporären Zugriff auf Ihren Tenant benötigen, an die Prüfer, die ihn zertifizieren, und mitunter an eine Kette von Sub-Prozessoren, die Sie nie direkt evaluiert haben. Jede dieser Übergabestellen ist ein weiterer Punkt, an dem Daten weitergegebenen, kopiert, protokolliert oder offengelegt werden können. Compliance-Frameworks wie SOC 2 und ISO 27001 sollen dieses Risiko sichtbar und handhabbar machen – sie sind nicht dazu gedacht, es zu beseitigen.
Es gibt einen anderen Weg, diese gesamte Problemklasse zu lösen. Anstatt Vertrauen nach außen auszudehnen, können Sie die Vertrauensgrenze nach innen ziehen – und die Anwendung in einer Infrastruktur betreiben, die Sie bereits besitzen und bereits prüfen.
Das Zero-Trust-Deployment-Modell, verständlich erklärt
„Zero Trust" in der Sicherheitsarchitektur bedeutet: Gehen Sie nie davon aus, dass ein Akteur, ein Netzwerk oder ein Dienst von Natur aus vertrauenswürdig ist – überprüfen Sie jeden Zugriff, jedes Mal. Die meisten Teams wenden diesen Ansatz auf Identitäts- und Netzwerkverkehr an. Weitaus weniger tun dies bei Anbieter-Deployments – und genau dort liegt üblicherweise das größte verbleibende Risiko.
Ein Zero-Trust-Deployment-Modell überträgt dasselbe Prinzip auf den Ort, an dem die Anwendung selbst ausgeführt wird. Der Anbieter liefert Ihnen die Software; Sie betreiben sie in Ihrem eigenen Cloud-Abonnement, auf Ihrem eigenen Identity-Provider, hinter Ihren eigenen Netzwerkkontrollen, mit Ihrem eigenen Logging, Ihren eigenen Schlüsseln und Ihren eigenen Backup-Richtlinien. Der Anbieter hält Ihre Daten zu keinem Zeitpunkt. Er kann nicht verlieren, was er nie hatte.
Dieses Modell wird manchmal als Bring Your Own Cloud (BYOC), Single-Tenant Self-Hosted oder Customer-Managed Deployment bezeichnet. Die Bezeichnung ist weniger wichtig als die eigentliche Eigenschaft: Ihre Daten verbleiben in Ihrem Tenant, geregelt durch dieselben Richtlinien, die für Ihr gesamtes Microsoft 365-Estate gelten.
VirtoSoftware wurde genau für dieses Deployment-Modell entwickelt.
So sieht es mit VirtoSoftware in der Praxis aus
VirtoSoftware-Anwendungen können direkt in das Azure-Abonnement deployed werden, das Ihren Microsoft 365-Tenant bereits betreibt. Es gibt keine separate Anbieterumgebung, in der Ihre Daten gespeichert werden. Es gibt keine gemeinsam genutzte mandantenübergreifende Steuerungsebene, die Ihre Geschäftsdaten hält. Die Apps laufen als vollwertige Bestandteile Ihrer eigenen Infrastruktur und sind mit den Microsoft 365-Diensten integriert, bei denen Ihre Benutzer sich bereits anmelden.
In der Praxis verändert dies fünf Dinge auf einmal.
Datensouveränität wird zum Standard, nicht zur Vertragsklausel. Dateien, Listen, Konfigurationen, Audit-Logs und alle Geschäftsdaten, mit denen die Anwendung interagiert, verbleiben in Ihrem Azure-Abonnement. Sie unterliegen den Verschlüsselungs-, Aufbewahrungs- und Zugriffsrichtlinien, die Sie bereits für den Rest Ihres M365-Estates vereinbart haben. Es gibt keine Anbieterkopie, kein Anbieter-Backup, keine Anbieter-Analytics-Pipeline, über die Sie sich Gedanken machen müssen.
Ihr bestehendes Security-Stack übernimmt die Hauptlast. Die Anwendung läuft hinter Ihren Conditional Access-Richtlinien, Ihrer Microsoft Defender for Cloud-Konfiguration, Ihren Microsoft Sentinel-Ingestion-Regeln, Ihrem vorhandenen SIEM, Ihrem bestehenden Key Vault und Ihren bestehenden Workflows für privilegierten Zugriff. Sie müssen keine neue Logging-Pipeline einrichten oder einen Anbieter überzeugen, Ereignisse an Ihr SOC weiterzuleiten. Die Ereignisse befinden sich bereits in Ihrer Umgebung, weil die Anwendung in Ihrer Umgebung läuft.
Der Compliance-Scope schrumpft. Wenn die Anwendung in einer Infrastruktur betrieben wird, die bereits im Scope Ihres SOC 2- oder ISO 27001-Programms liegt, decken die von Ihnen bereits implementierten und getesteten Kontrollen sie ab. Sie fügen keinen neuen Drittanbieter-Sub-Prozessor hinzu, dessen eigener Attestierungsbericht jährlich geprüft, zugeordnet und neu bewertet werden muss. Die Anbieter-Risikoakte wird kürzer, nicht länger.
Source-Code-Transparenz statt „Vertrauen Sie uns." VirtoSoftware bietet vollständigen Quellcode-Zugang zu den deployten Lösungen, sodass Ihre IT- und Security-Teams genau prüfen können, was die Anwendung tut, wie sie Daten verarbeitet und welche Abhängigkeiten sie mitbringt. Es gibt kein undurchsichtiges Binary, das unbekannte Dinge in Ihrem Tenant ausführt. Ihr Team kann den Code lesen, ihn durch Ihr eigenes SAST- und SCA-Tooling laufen lassen und das Verhalten anhand Ihres eigenen Bedrohungsmodells verifizieren.
Operative Unabhängigkeit. Da die App in Ihrem Abonnement läuft, hängt sie nicht von der Verfügbarkeit einer externen SaaS-Steuerungsebene ab. Wartungsfenster, Upgrade-Zeitplanung, regionales Failover und Incident Response finden nach Ihrem Zeitplan statt und werden durch Ihre eigenen Runbooks geregelt.
Warum das nicht nur nach, sondern besonders während Audits relevant ist
Das Audit-Risiko, das die meisten Teams unterschätzen, ist nicht das Audit selbst – es ist die kumulative Angriffsfläche, die Compliance-Programme im Laufe der Zeit aufbauen.
Jeder externe SaaS in Ihrem Stack vergrößert diese Fläche auf drei Arten. Erstens erweitert er den Kreis der Personen, die in irgendeiner Form Zugriff auf Ihre Daten haben: Anbieter-Ingenieure, Anbieter-Support, Anbieter-Auditoren, Anbieter-Sub-Prozessoren und die Mitarbeiter jedes Dritten, den der Anbieter beauftragt hat. Zweitens vergrößert er die Menge der Umgebungen, in denen Ihre Daten physisch gespeichert sind – und von wo aus sie versehentlich exportiert, in ein Backup geSnapshottet, an ein Support-Ticket angehängt oder in einem Debug-Log zurückgelassen werden können. Drittens entsteht bei jeder Erneuerung eines SOC 2- oder ISO 27001-Zyklus ein zusätzlicher Aufwand für die Beweiserhebung.
Self-Hosted-Deployment im Customer-Tenant beseitigt den Großteil davon. Es gibt keinen Anbieter-Support-Ingenieur, der temporären Lesezugriff auf Ihre Produktionsdaten benötigt, um ein Problem zu debuggen – denn die Daten liegen in Ihrer Umgebung, nicht in seiner. Es gibt keine separate Anbieterumgebung, die einen eigenen Attestierungszyklus benötigt, denn die Anwendung ist Teil Ihrer Umgebung, abgedeckt durch Ihre Kontrollen. Die Frage des Auditors ändert sich von „Zeigen Sie mir den SOC 2 des Anbieters und Ihre Sub-Processor-Governance" zu „Zeigen Sie mir die Kontrollen für diese Azure-Ressourcengruppe" – und die können Sie mit denselben Nachweisen beantworten, die Sie ohnehin für alles andere bereits erstellen.
Das ist auch der Grund, warum das Modell einer strengen Prüfung in regulierten Branchen standhält. Gesundheitsorganisationen, die PHI innerhalb einer definierten Grenze halten müssen, Finanzdienstleister mit Datenspeicherort-Verpflichtungen, Verteidigungs- und öffentliche Sektor-Kunden mit Souveränitätsanforderungen sowie jede Organisation, die unter DSGVO, HIPAA, FedRAMP-konformen oder branchenspezifischen Regularien agiert – alle profitieren von derselben Eigenschaft: Daten verlassen den Tenant nicht, und die Vertrauensgrenze ist eine, die Sie bereits verwalten.
Was das Deployment in der Praxis umfasst
Der Deployment-Prozess ist bewusst auf die Arbeitsweise von Enterprise-IT-Teams ausgerichtet.
Die erste Phase umfasst Review und Planung. Ihr Team erhält den Quellcode der gewählten VirtoSoftware-Lösung und prüft ihn anhand interner Sicherheitsstandards. Sie dimensionieren die benötigten Azure-Ressourcen, planen die Integration mit Ihren bestehenden M365-Diensten und stimmen das Deployment mit Ihren Change-Management- und Sicherheitsprotokollen ab.
Die zweite Phase ist die Implementierung. Die Lösung wird in Ihrem Azure-Abonnement installiert, mit den relevanten Microsoft 365-Diensten integriert und entsprechend Ihrer Sicherheits-Baseline konfiguriert. Ab dem Moment des Go-Lives wird sie durch dieselben Tools protokolliert, überwacht und verwaltet, die den Rest Ihrer Umgebung kontrollieren.
VirtoSoftware unterstützt den Prozess von Anfang bis Ende: mit individuell auf Ihre Change-Fenster abgestimmten Update-Zeitplänen, fachkundiger Engineering-Unterstützung, optionaler individueller Entwicklung, Wissenstransfer und Schulungen für Ihr Team sowie flexiblen SLAs. Enterprise-Lizenzen können auf Deployment-Umfang, Vertragslaufzeiten, Integrationsanforderungen, Service-Plan-Präferenzen und White-Labeling-Bedarf zugeschnitten werden. Sie können zunächst in einer Nicht-Produktionsumgebung deployen, um das Modell zu validieren, bevor Sie in die Produktion übergehen – genauso wie Sie jede andere wesentliche Infrastrukturänderung behandeln würden.
Das Fazit
Compliance-Frameworks existieren, weil Vertrauen in der Breite schwierig ist. SOC 2 und ISO 27001 bieten Ihnen eine strukturierte Möglichkeit, die Vertrauenswürdigkeit von Organisationen zu beurteilen, deren Infrastruktur Sie nicht direkt kontrollieren können. Sie sind nützlich, und für genuinen externen Diensten sind sie unverzichtbar.
Aber sie sind auch eine Steuer – reale, laufende Kosten in Form von Prüfgebühren, Gutachterzeit, Vendor-Management-Aufwand und dem Restrisiko, das kein Zertifikat vollständig eliminieren kann. Wann immer es einen glaubwürdigen Weg gibt, Vertrauen gar nicht erst nach außen auszudehnen, sollte das die bevorzugte Option einer sicherheitsbewussten Organisation sein.
Für Microsoft 365-Add-ons existiert diese Option. Durch das Deployment von VirtoSoftware-Anwendungen in Ihrem eigenen Azure-Abonnement halten Sie Ihre Daten in Ihrem Tenant, halten Ihre Sicherheitslage unter Kontrolle durch Tools, die Sie bereits betreiben, verhindern eine stille Ausweitung des Audit-Scopes und behalten vollständige Einsicht in den Code, auf den Ihre Nutzer angewiesen sind.
So sieht Zero-Trust-Deployment in der Praxis aus – kein Schlagwort, sondern ein Deployment-Modell, das Ihrem IT-Team etwas Seltenes im modernen SaaS-Umfeld gibt: die Möglichkeit, einer neuen Geschäftsfunktion zuzustimmen, ohne die Vertrauensgrenze zu vergrößern, die alles andere schützt.
Bereit, VirtoSoftware in Ihrer eigenen Umgebung zu evaluieren? Sie können in jeder Nicht-Produktionsumgebung von Microsoft 365 deployen und testen, bevor Sie in die Produktion wechseln. Ihre Infrastruktur gehört Ihnen; wir liefern die Anwendung, den Quellcode, die Updates und den Support, um sie zuverlässig zu betreiben.