TISAX-konformes Livestreaming. In Ihrer Compliance-Zone.
Unveröffentlichte Modelle, vertrauliche Kampagnen, Footage aus dem Windkanal: Automotive-Inhalte verlassen das Haus nur über eine Pipeline, die den Anforderungen der Auftraggeber standhält. dfine.io streamt live mit Sub-1-Sekunde-Latenz bis UHD, wahlweise auf TISAX-geprüfter Infrastruktur in Frankfurt oder On-Premises auf Ihrer eigenen Hardware.
TISAX-geprüfte Infrastruktur · FrankfurtOn-Premises möglichSub-1s · bis UHD
Streaming-Option auf TISAX-geprüfter Infrastruktur (ENX-Label)
Der Streaming-Server steht physisch bei Ihnen im Haus, in Ihrem Netz und TISAX-Scope, installiert und betreut von dfine.io.
Eigene Dienstleister gezielt freischalten: die gesamte Pipeline bleibt lückenlos nachvollziehbar.
Ihr Publish-Ingest geht an Ihren lokalen Server, die Viewer beziehen den Stream von dort. Das Streaming-Signal bleibt in Ihrer Infrastruktur, region-pinned.
Was TISAX verlangt, und warum es Streaming betrifft.
TISAX (Trusted Information Security Assessment Exchange) ist der Prüfstandard der Automobilindustrie für Informationssicherheit, betrieben von der ENX Association auf Basis des VDA-ISA-Katalogs. Formal ist TISAX keine Zertifizierung, sondern ein Assessment mit Labels, die über die ENX-Plattform geteilt werden. OEMs und Zulieferer verlangen sie von Dienstleistern, sobald vertrauliche Inhalte verarbeitet werden, und ein Livestream mit einem unveröffentlichten Fahrzeug ist genau das. Wer hier mit generischen Streaming-Diensten arbeitet, fällt bei der Lieferantenprüfung durch. dfine.io bietet deshalb beide Wege: TISAX-geprüfte Infrastruktur oder Ihre eigene.
Die Pipeline
Vom Set bis zur Abnahme, ohne Umweg.
01 · INGEST
OBS oder Hardware-Encoder
Signal direkt aus der Suite oder vom Set, RTMPS-verschlüsselt in die private Umgebung.
Ihre Streams laufen in einer privaten, TISAX-geprüften Umgebung auf Google, mit geteilten Ressourcen oder dediziert, oder on-premises auf Ihrer Hardware.
03 · ABNAHME
Geschützte Viewer
Zugangscode- oder passwortgeschützte Links im Browser, parallel farbecht auf dem Referenzmonitor via SDI/HDMI.
Transparenz vorab, bevor Ihr Informationssicherheits-Team fragt: so ist die Private-Shared-Cloud-Variante aufgebaut. Bei On-Premises stellen sich die meisten dieser Punkte nicht, dort läuft alles auf Ihrer Hardware.
Speichert der Streaming-Server Videodaten?
Nein. Streaming ist bei uns eine reine Echtzeit-Durchleitung vom Ingest zur Ausspielung. Aufzeichnung und Cloud-Storage-Upload sind serverseitig deaktiviert; auf der Instanz existieren keine Video-Dateien und keine Buckets. Was bleibt, sind Metadaten wie Zeiten und Dauer, und die liegen nicht auf der Streaming-Instanz, sondern containerisiert in unserer zentralen Datenbank auf Hetzner in Nürnberg, nicht öffentlich erreichbar und anwendungsseitig zugriffskontrolliert.
Was teilen sich Kunden auf der Instanz, und was nicht?
Geteilt wird die Rechenleistung einer dedizierten, TISAX-konformen Compute-Instanz auf Google Cloud (europe-west3, Frankfurt), strikt getrennt von unserer regulären Infrastruktur auf Hetzner in Nürnberg. Nicht geteilt wird Storage, denn Videodaten werden gar nicht persistiert. Wer auch die Rechenleistung exklusiv braucht, bekommt eine dediziert fokussierte Engine oder betreibt den Server on-premises.
Wie bleibt jeder Stream bei seinem Kunden?
Über eindeutige Zugangs-Tokens je Kunde, die der Server bei jedem Verbindungsaufbau erneut prüft (Round-Trip-Authentifizierung). Die Ausspielung ist ebenso pro Stream geschützt: Zuschauer kommen nur per Zugangscode oder vertraulichem Login hinein. Metadaten hängen an organisationsgebundenen Datensätzen mit anwendungsseitigen Zugriffskontrollen, und der Datenbank-Port ist nicht öffentlich erreichbar. Da kein Video-Storage existiert, gibt es strukturell keinen gemeinsamen Speicher, über den Inhalte von einem Kunden zum anderen gelangen könnten.
Und der Weg dazwischen, ist der Transport abgesichert?
Durchgängig verschlüsselt: RTMPS beim Ingest, WebRTC bei der Ausspielung. Wiederholte Fehlversuche gegen die Stream-Authentifizierung erkennt die Infrastruktur automatisch und blockiert die Quelle.
Die Instanz läuft auf Google Cloud, greift dann nicht der US CLOUD Act?
Ja, Google ist ein US-Anbieter, und das verschweigen wir nicht. Der Server selbst steht allerdings nachweislich in Deutschland: die Instanz läuft in der Google-Cloud-Region europe-west3 in Frankfurt, der Standort ist dokumentiert und belegbar. Entscheidend ist zudem, was dort liegt: keine Videodaten, denn die Instanz leitet das Signal nur in Echtzeit durch und speichert nichts. Die Metadaten liegen bei Hetzner, einem deutschen Anbieter, mit der dfine.io GmbH als Vertragspartner. Wer auch das Restrisiko der Durchleitung ausschließen will, betreibt den Server on-premises, dann verlässt das Signal Ihre Infrastruktur gar nicht erst.
Welche Subdienstleister sind beteiligt?
Alle Auftragsverarbeiter sind öffentlich dokumentiert, mit verlinkten Auftragsverarbeitungsverträgen (AVV nach Art. 28 DSGVO), in unserer Trust-&-Compliance-Übersicht. Keine versteckten Ketten: was dort steht, ist die vollständige Liste.
Wird der Betrieb aktiv überwacht?
Ja, aber auf Betriebsebene, nicht inhaltlich: Überwacht werden technische Metriken wie Bitrate, Laufzeit und Verbindungsstatus, darüber setzen wir Plan-Limits serverseitig durch. In den Stream selbst schaut dabei niemand hinein, das Signal wird durchgeleitet, nicht mitgesehen. Fehler- und Audit-Logs laufen EU-seitig zusammen. Und wenn etwas klemmt, erreichen Sie keine Ticket-Schleife, sondern uns direkt.
Wie werden Sicherheitsupdates eingespielt?
CVE-getrieben statt nach starrem Kalender: sobald für eingesetzte Komponenten neue Schwachstellen bekannt werden, spielen wir die Updates ein. Wartungsfenster liegen grundsätzlich nachts, damit laufende Produktionen nicht gestört werden. Zertifikate erneuern sich automatisiert.
Wie lange werden Metadaten aufbewahrt?
Session-Metadaten (Zeiten, Dauer) werden nach 12 Monaten automatisiert gelöscht, über einen monatlichen Bereinigungs-Job. Videoinhalte werden ohnehin nie gespeichert.
Lässt sich der Arbeitsspeicher der Instanz verschlüsseln?
Auf dediziert fokussierten Engines ja: Confidential Computing verschlüsselt den RAM der VM mit einem hardware-generierten Schlüssel (AMD SEV/SEV-SNP bzw. Intel TDX), auf den weder Cloud-Anbieter noch Hypervisor noch Nachbar-VMs Zugriff haben. Das schützt gegen kompromittierte Hypervisoren und Insider-Zugriffe. Der Overhead ist bei rechenlastigen Workloads gering, bei netzwerkintensiven Streaming-Workloads spürbar höher, deshalb ist es auf der geteilten Variante standardmäßig nicht aktiv.
Sprechen wir über Ihr Setup.
Wir antworten persönlich und sagen ehrlich, ob wir helfen können.
Streaming-Option auf TISAX-geprüfter Infrastruktur (ENX-Label)