Verteidigung in der Tiefe, Schicht für Schicht.
Ein Überblick über die Struktur der Messaging-Plattform von BroadNet – von der API-Schnittstelle bis zu den Carrier-Verbindungen –, sodass Sicherheit auf jeder Ebene implementiert und nicht erst nachträglich hinzugefügt wird. Diese Übersicht ist bewusst nicht vertraulich: Sie zeigt die Struktur des Stacks, nicht seine interne Topologie.
Die Schichten, einfach ausgedrückt.
Kunden-Apps und -Kanäle
Ihre Anwendungen und Kampagnen sind über dokumentierte, versionierte Schnittstellen miteinander verbunden. Informationen über nachgelagerte Mandanten werden niemals einem anderen Mandanten offengelegt.
API- und SDK-Gateway
Der öffentliche Rand. Kontobezogene Bearer-Zugriffstoken authentifizieren jede API-Anfrage; mandantenbezogene Ratenbegrenzung, IP-Zulassungslisten und eine automatisierte Web Application Firewall (WAF) befinden sich vor der Plattform.
Messaging-Plattform
Mandantenfähige Verarbeitung mit mandantenspezifischer Isolation, dauerhafter Warteschlangenverwaltung und Zustellungssteuerung. Zustandsänderungen werden in Audit-Logs protokolliert.
Routing-Intelligenz
Die kostengünstigste und qualitätsbasierte Routenwahl wählt für jedes Ziel einen legalen, konformen Pfad aus, wobei Graurouten erkannt und eine neue Route festgelegt wird, wenn die Qualität einer Route unter das Serviceziel fällt.
Sicherheit & Firewall
Schutzmechanismen auf Telekommunikationsniveau – SMS-Firewall, SS7-Firewall, Absender-ID-Schutz, Analyse von Flash-Anrufen und OTP-Missbrauch – werden standardmäßig auf die eigenen Routen von BroadNet angewendet.
Carrier-Verbindungen
1,000+ direkte Betreiberverbindungen sichern Direktanbindungen in 86 Ländern, mit gekennzeichneten Partnerrouten in den übrigen der 200+ erreichten Länder, sodass der Datenverkehr auf legitimen, vertraglich vereinbarten Routen endet.
Fünf Verteidigungsebenen in der Tiefe.
Die oben nummerierten Ebenen beschreiben den Weg einer Nachricht. Diese fünf Ebenen beschreiben die Steuerungsmechanismen, die an jedem Punkt dieses Weges wirken – jede ist so konzipiert, dass ein Fehler in einer Ebene durch die nächste aufgefangen wird.
Edge & Netzwerk
Der öffentliche Edge-Server beendet TLS 1.3, fängt Missbrauch durch Volumetrics ab und prüft, ob eine Anfrage wohlgeformt ist, bevor sie die Anwendungslogik erreicht. Kein nachgelagertes Netzwerk vertraut dem Netzwerk, über das es empfangen wurde.
- Ratenbegrenzung pro Mandant und pro Endpunkt mit Burst-Steuerung
- IP-Zulassungslisten und Mutual-TLS-Optionen für SMPP- und API-Bindungen
- Automatisierte Web Application Firewall (WAF) filtert gängige Einschleusungs- und Missbrauchsmuster
- DDoS-Absorption und Anomalieabweisung auf Verbindungsebene am Rand
Anwendung & Identität
Jede Anfrage wird individuell authentifiziert und autorisiert. Kontobezogene Bearer-Zugriffstoken dienen der Identitätsfeststellung; rollenbasierte Zugriffsrechte bestimmen die Berechtigungen dieser Identität; Mandantenfähigkeit wird im Code und nicht durch Konventionen erzwungen.
- Kontobezogene Bearer-Zugriffstoken für die API; kurzlebige Token für interaktive Sitzungen
- Rollenbasierte Zugriffskontrolle mit standardmäßigen Berechtigungen nach dem Prinzip der minimalen Rechtevergabe
- Mandantenspezifische Isolation, sodass kein Mandant auf die Daten eines anderen Mandanten zugreifen kann
- TLS-verschlüsselte Webhooks für eingehende DLR und MO
Daten & Speicherung
Nachrichteninhalte, Zustellungsmetadaten und Prüfprotokolle werden im Ruhezustand verschlüsselt gespeichert, wobei die Aufbewahrungsfristen den vertraglichen und regulatorischen Vorgaben entsprechen. Statusänderungen werden in einem schreibgeschützten Prüfprotokoll protokolliert.
- AES-256-Verschlüsselung ruhender Daten in primären Speichern und Backups
- Nur-Anhängen-Protokollierung von Zustandsänderungsaktionen
- Datenaufbewahrungsfristen, die an vertragliche und regionale Vorschriften angepasst sind
- Verschlüsselte Backups, getestet gegen definierte Wiederherstellungsziele
Schlüsselmanagement
Schlüssel werden innerhalb einer dedizierten Schlüsselverwaltungsinfrastruktur generiert, gespeichert, rotiert und außer Betrieb genommen. Der Anwendungscode enthält Referenzen, nicht das eigentliche Schlüsselmaterial, und die Rotation erfordert keine Dienstunterbrechung.
- Zentralisierte Schlüsselverwaltung mit Trennung von Anwendungsgeheimnissen
- Geplanter Schlüsselwechsel und sofortiger Entzug bei Verdacht auf Kompromittierung
- Funktionstrennung für Schlüsselverwahrung und administrativen Zugang
- Die Hüllverschlüsselung sorgt dafür, dass die Datenschlüssel selbst durch Master-Schlüssel geschützt sind
Überwachung und Reaktion
Die Beobachtbarkeit erstreckt sich über den gesamten Stack und nicht nur auf einen einzelnen Engpass, sodass Anomalien nahe an ihrem Entstehungsort erkannt werden. Ein rund um die Uhr besetztes NOC verknüpft die Erkennung mit einem dokumentierten Incident-Response-Prozess.
- 24/7-NOC mit Warnmeldungen für Edge-, Plattform-, Routing- und Verbindungsnetze
- Analysen zu Graurouten, Absender-ID-Missbrauch und OTP-Missbrauch im Live-Verkehr
- Dokumentierte Reaktion auf Vorfälle mit Schweregradklassen und benannter Eskalation
- Ursachenanalyse (RCA) und Grund für den Ausfall (RFO) nach schwerwiegenden Vorfällen
Steuerungselemente, den Standards zugeordnet.
Eine beispielhafte Zuordnung der einzelnen Ebenen zu den Kontrollfamilien in ISO/IEC 27001, SOC 2 und ISO 22301. Sie dient der Veranschaulichung und ist nicht die vollständige Anwendbarkeitserklärung – die geprüften Kontrollsätze werden unter Geheimhaltungsvereinbarung weitergegeben.
| Layer | Repräsentative Kontrollen | Zugeordneter Standard |
|---|---|---|
| Edge & Netzwerk | TLS 1.3, WAF, mandantenbezogene Ratenbegrenzung, IP-Whitelisting, DDoS-Absorption | ISO 27001 A.8 · SOC 2 CC6.6 |
| Anwendung & Identität | API-Authentifizierung per Bearer-Token, RBAC nach dem Least-Privilege-Prinzip, Mandantenisolation | ISO 27001 A.8 / A.9 · SOC 2 CC6.1–CC6.3 |
| Daten & Speicherung | AES-256-Verschlüsselung ruhender Daten, Nur-Anhängen-Audit-Logs, Aufbewahrungsfenster, verschlüsselte Backups | ISO 27001 A.8 · SOC 2 CC6.1 / C1.1 |
| Schlüsselmanagement | Zentralisiertes KMS, geplante Rotation, Widerruf, Trennung der Aufgaben | ISO 27001 A.8.24 · SOC 2 CC6.1 |
| Überwachung & Reaktion | 24/7-NOC, schichtübergreifende Telemetrie, dokumentierte IR, RCA/RFO | ISO 27001 A.5.24–A.5.28 · SOC 2 CC7.2–CC7.4 |
| Continuity | Datensicherungen, getestete Wiederherstellungsziele, Geschäftskontinuitätsmanagement | ISO 22301 · SOC 2 A1.2 |
Die zugeordneten Standards beziehen sich auf ISO/IEC 27001:2022 Anhang A, die SOC 2 Trust Services Criteria und ISO 22301. Siehe Einhaltung für die Zertifizierungsliste und Das Trust Center Nachweise anzufordern.
Verschlüsselung und Schlüsselverwaltung.
Die Stärke einer Verschlüsselung hängt maßgeblich von der Art und Weise ab, wie ihre Schlüssel verwaltet werden. Daten sind während der Übertragung und im Ruhezustand geschützt, und die zugehörigen Schlüssel befinden sich in einer dedizierten Infrastruktur – getrennt vom Anwendungscode und den Daten selbst.
Bei der Übertragung
TLS 1.3 auf jeder externen Schnittstelle – API, SMPP und Webhooks – mit modernen Cipher Suites und Certificate-Pinning-Optionen für Enterprise-Binds.
Im Ruhezustand
AES-256-Verschlüsselung für primäre Speicher und Backups. Nachrichteninhalte und Zustellungsmetadaten unterliegen Aufbewahrungsfristen, die sich nach Vertrag und regionalen Vorschriften richten.
Schlüssel-Lebenszyklus
Zentralisiertes Schlüsselmanagement mit geplanter Rotation, sofortiger Widerrufsmöglichkeit, Funktionstrennung und Umschlagverschlüsselung, sodass die Datenschlüssel selbst durch Hauptschlüssel geschützt sind.
Bedrohungsmodell und gestaffelte Verteidigung.
Verteidigung in der Tiefe bedeutet, dass keine einzelne Steuerungseinrichtung allein die Last tragen kann. Für jedes realistische Angriffsziel müssen mehr als ein Flugzeug ausfallen, bevor es zum Einschlag kommt.
Diebstahl von Zugangsdaten oder durchgesickerter API-Schlüssel
Minimale Berechtigungen begrenzen den Wirkungsradius; kurzlebige Token und der sofortige Widerruf verkleinern das Zeitfenster; die Isolation pro Mandant verhindert eine seitliche Ausbreitung zu einem anderen Mandanten.
Grey-Route-Injection und Absender-ID-Spoofing
Die SMS-Firewall und der Sender-ID-Schutz klassifizieren und verwerfen unzulässigen Datenverkehr, bevor er beendet wird; direkte Betreiberverbindungen sorgen dafür, dass legitimer Datenverkehr auf vertraglich vereinbarten Routen landet.
OTP-Missbrauch / künstliche Aufblähung des Datenverkehrs
Verhaltensanalysen und die Erkennung von Flash-Call-/OTP-Missbrauch drosseln aufgeblähte Muster in Leitungsgeschwindigkeit, bevor sie nachgelagert monetarisiert werden können.
Angriffe auf der Signalisierungsschicht (SS7)
Die SS7-Firewall prüft und filtert die Signalübertragung, um auf der Netzwerkschicht vor Standortverfolgung, Abfangen und Betrugsversuchen zu schützen.
Datenexposition während der Übertragung oder im Ruhezustand
TLS 1.3 schützt Daten während der Übertragung und AES-256 schützt ruhende Daten; die Schlüssel befinden sich in einer dedizierten Schlüsselverwaltungsinfrastruktur, die von den zu schützenden Daten getrennt ist.
Missbrauch durch Insider oder Administratoren
Rollenbasierte Zugriffskontrolle, Aufgabentrennung bei der Schlüsselverwaltung und Protokollierung von Auditvorgängen, die nur angehängt werden, machen privilegierte Aktionen nachvollziehbar und überprüfbar.
Überwachung auf allen Ebenen
Die Beobachtbarkeit und die kontinuierliche Überwachung erstrecken sich über den gesamten Stack und beschränken sich nicht auf einen einzelnen Engpass. Dadurch werden Anomalien in der Nähe ihres Auftretens erkannt. Spezifische Tools und Alarmierungsschwellenwerte werden den Evaluatoren unter Geheimhaltungsvereinbarung (NDA) mitgeteilt.
Durchgängige Verschlüsselung
TLS 1.3 schützt Daten während der Übertragung und AES-256 schützt ruhende Daten über alle Schichten hinweg. Detaillierte Informationen zum Schlüsselmanagement und zur Datenkontrolle sind unter Geheimhaltungsvereinbarung erhältlich – siehe die Zertifizierungen für den geprüften Umfang.
Zertifizierte Kontrolldetails, Rechenzentrumsstandorte, genaue Wiederherstellungsziele und interne Topologie sind durch den geprüften Umfang von BroadNet abgedeckt und unterliegen einer Geheimhaltungsvereinbarung. Siehe ISO/IEC 27001 Und ISO 22301
Hier schließt sich der Kreis.
Diese Übersicht stellt die Architektur dar. Die Nachweise, Zertifikate und betrieblichen Verpflichtungen, die diese untermauern, finden Sie im Trust Center und auf den Seiten „Compliance und Sicherheit“.
Häufig gestellte Fragen.
Ist dies die vollständige Sicherheitsarchitektur?
Nein. Diese Seite ist bewusst nicht vertraulich: Sie zeigt die Struktur des Stacks und die Kontrollen auf jeder Ebene, nicht jedoch die interne Topologie, die Standorte der Rechenzentren oder die genauen Wiederherstellungsziele. Zertifizierte Kontrolldetails werden den Prüfern unter Geheimhaltungsvereinbarung (NDA) zur Verfügung gestellt und fallen unter den Prüfumfang von BroadNet.
Nach welchen Standards ist die Plattform zertifiziert?
BroadNet ist nach ISO/IEC 27001 (Informationssicherheit), ISO 9001 (Qualitätsmanagement) und ISO 22301 (Business Continuity Management) zertifiziert. Die Kontrollzuordnungstabelle auf dieser Seite verweist auf repräsentative Kontrollen in den Kontrollfamilien von ISO 27001, SOC 2 und ISO 22301, sodass Prüfer die Übereinstimmung der einzelnen Ebenen erkennen können.
Wie wird die Verschlüsselung während der Übertragung und im Ruhezustand gehandhabt?
TLS 1.3 schützt Daten während der Übertragung, AES-256 hingegen ruhende Daten – sowohl in primären Speichern als auch in Backups. Schlüssel werden innerhalb einer dedizierten Schlüsselverwaltungsinfrastruktur generiert, gespeichert, rotiert und außer Betrieb genommen. Dabei kommt eine Envelope-Verschlüsselung zum Einsatz, sodass die Datenschlüssel selbst durch Hauptschlüssel geschützt sind.
Setzen Sie Ihre eigenen SMS- und SS7-Firewalls für den BroadNet-Datenverkehr ein?
Ja. Die Sicherheitsvorkehrungen auf Telekommunikationsniveau – SMS-Firewall, SS7-Firewall, Absender-ID-Schutz und OTP-Missbrauchsanalyse – werden standardmäßig auf die eigenen Routen von BroadNet angewendet und nicht nur als Zusatzoption für Drittanbieter angeboten.
Wie kann ich die Details der geprüften Kontrollen anfordern?
Benannte Kontrolldetails, Rechenzentrumsstandorte, genaue Wiederherstellungsziele und die interne Topologie werden qualifizierten Prüfern unter Geheimhaltungsvereinbarung (NDA) zur Verfügung gestellt. Beginnen Sie im Trust Center oder auf der Compliance-Seite oder kontaktieren Sie das Sicherheitsteam, um das Dokumentationspaket anzufordern.