Infrastruktur

Worauf BulkGate läuft, wie Nachrichten in die Netze der Betreiber gelangen, wie wir den Datenverkehr schützen und was das für eine Integration bedeutet, die auch zu Spitzenzeiten zuverlässig funktionieren muss.

Drei Standorte

Der Dienst läuft auf mehreren Servern an drei geografischen Standorten. Das ist nicht eine Maschine mit einer Reserve, sondern ein paralleler Betrieb — fällt ein Standort aus, übernehmen die übrigen den Datenverkehr automatisch und ohne Ihr Zutun. Für Ihre Integration ändert sich nichts: portal.bulkgate.com antwortet weiterhin und Anfragen werden auf dieselbe Weise versendet.

Was das Failover nicht abdeckt, ist der Weg zu uns — ein Ausfall bei Ihrem Internetanbieter, bei einem Carrier oder irgendwo auf der Strecke zwischen Ihrem und unserem Server. Dafür gibt es den Backup-Server.

Die Infrastruktur ist auf Ausfallsicherheit ausgelegt und durch WEDOS Global Protection gegen DDoS-Angriffe geschützt. Der Datenverkehr erreicht unsere Server nicht direkt — er läuft über deren Anycast-Netz mit mehr als 120 Knoten, wo ihn der nächstgelegene Knoten annimmt. Ein Angriff wird auf deren Seite verteilt und gefiltert, bevor er uns überhaupt erreicht; unsere Server bearbeiten nur die legitimen Anfragen, die durchkommen. Anycast verkürzt zudem den Weg Ihrer Anfrage, weil sie der Ihnen nächstgelegene Knoten annimmt.

WEDOS speichert auch Logs, Konfiguration und Analysen innerhalb der EU, sodass nicht einmal der DDoS-Schutz Daten aus der Union hinausträgt — siehe Server in der EU.

Den aktuellen Status des Dienstes finden Sie unter bulkgate.status.online.

Server in der EU

Alle unsere Server laufen in der Europäischen Union. Ihre Daten verlassen die EU daher nicht und Sie müssen sich weder mit Übermittlungen in Drittländer noch mit Standardvertragsklauseln befassen.

Wie wir mit personenbezogenen Daten umgehen, beschreiben die Bedingungen für die Verarbeitung personenbezogener Daten und die Datenschutzerklärung.

Anbindungen an Betreiber

Wir stellen Nachrichten über direkte Anbindungen an Betreiber in Europa, Asien, Afrika sowie in Nord-, Mittel- und Südamerika zu.

Was 0-Hop bedeutet

Eine direkte Anbindung ist eine 0-Hop-Verbindung — zwischen uns und dem SMSC des Betreibers steht niemand sonst. Die Nachricht geht von unserem Gateway direkt in das Zielnetz. Das ist die höchstmögliche Zustellqualität; einen besseren Weg zur Zielnummer gibt es nicht, weil es keinen kürzeren gibt.

Jeder Zwischenhändler auf der Strecke ist eine Stelle, an der etwas schiefgehen kann:

Deshalb bauen wir direkte Anbindungen überall dort auf, wo es möglich ist. Bei hohen Volumina und zeitkritischen Nachrichten — OTP-Codes, Bestellbestätigungen — zeigt sich der Unterschied am deutlichsten.

Heute haben wir 0-Hop in mehr als 50 Länder, und es werden laufend mehr.

Wo wir kein 0-Hop haben, ist die erste Wahl ein lokaler Anbieter im jeweiligen Land — ein einziger Zwischenhändler, der den lokalen Markt kennt, keine Kette von Aggregatoren. Erst wenn es nicht einmal einen solchen gibt, stellen wir über SMS-Hubs zu; diese halten wir als Rückfalllösung für ein Minimum an Zielen bereit, nicht als üblichen Weg.

RCS über eine direkte Anbindung an Google

Direkte Anbindungen hören nicht bei SMS auf. RCS Business Messaging läuft auf der Plattform von Google. Wir haben eine direkte Anbindung daran und zusätzlich eigene Verträge mit Betreibern — beides ist nötig: Google genehmigt den Agenten und den Inhalt, der Betreiber lässt den Datenverkehr in sein Netz. Ohne eines von beiden erreicht eine RCS-Nachricht den Empfänger nie.

Was RCS gegenüber SMS bietet:

Nachrichtentypen und ihre Abrechnung beschreibt RCS-Nachrichtentypen; die Einrichtung des Agenten RBM-Chat-Einstellungen.

Viber als offizieller Partner

Für Viber sind wir ein offizieller Partner, kein Wiederverkäufer — Sie finden uns in deren Verzeichnis der Messaging-Partner. Nachrichten gehen daher über den genehmigten Weg direkt in das Netz von Viber und wir registrieren Ihren Absender direkt dort.

Was das in der Praxis bedeutet:

Nachrichtentypen und Sitzungen beschreibt Viber-Nachrichtentypen.

SMPP für hohe Volumina

Neben der HTTP-API bieten wir größeren Kunden eine SMPP-Verbindung an — das Protokoll, auf dem die SMS-Netze selbst laufen. Sie lohnt sich dort, wo die Volumina dauerhaft hoch sind und Sie eine Sitzung offen halten müssen, statt einzelne HTTP-Anfragen zu senden.

SMPP wird individuell eingerichtet; nehmen Sie Kontakt mit uns auf und wir besprechen Ihre Volumina und Parameter.

Priorisierung von Nachrichten

Nicht jede Nachricht kann gleich lange warten. Ein Code, auf den der Nutzer in einem Formular wartet, muss sofort raus; einer Kampagne an hunderttausend Nummern schadet eine Sekunde mehr nicht. Deshalb teilen wir den Datenverkehr in getrennte Warteschlangen auf und bedienen sie in dieser Reihenfolge:

Die Warteschlangen überholen sich nicht gegenseitig: Eine bereits laufende große Kampagne hält keinen OTP-Code auf, der mitten in ihr eintrifft.

Schutz vor Phishing und SMS-Pumping

Wir werten den Datenverkehr laufend aus, um zwei Dinge zu erkennen, die Absendern und Empfängern gleichermaßen schaden.

Phishing. Jede Nachricht wird mit Mustern bekannter betrügerischer Kampagnen abgeglichen — sowohl die Absenderkennung als auch der Text, und zwar für jedes Zielland separat. Die Prüfung berücksichtigt auch Lookalikes: Sie erkennt einen Namen oder eine Formulierung, die absichtlich um ein paar Zeichen verändert wurde, um an einem wörtlichen Vergleich vorbeizukommen. Das schützt Ihre Marke davor, nachgeahmt zu werden, und Ihre Absenderkennung vor einem Reputationsschaden beim Betreiber.

SMS-Pumping. Künstlich erzeugter Datenverkehr (AGT) — ein Angreifer schleust über Ihr Formular OTP-Codes an Nummern in Premium-Bereichen und kassiert einen Anteil an deren Preis. Deshalb beobachten wir die Form des Datenverkehrs, nicht seinen Inhalt. Sobald wir Datenverkehr sehen, der nicht dem entspricht, was das Konto normalerweise sendet — einen plötzlichen Anstieg oder ungewöhnliche Ziele —, stoppen wir den Versand und benachrichtigen Sie per E-Mail und SMS. Der Angriff wird abgeschnitten, bevor er teuer wird; der Schaden bleibt bei dem, was bereits versendet wurde.

Einem Angriff auf Ihr eigenes Formular können Sie vorbeugen, indem Sie in der OTP-API request_quota_identification und request_quota_number festlegen — das Kontingent ist an den Anfragenden gebunden, typischerweise an seine IP-Adresse. Das Portal ergänzt dies um geografische Beschränkungen und tägliche Sendelimits; wie Sie diese einrichten, beschreibt Hacked OTP SMS: Protect yourself with BulkGate API limits!.

Sicherheit von Kommunikation und Daten

Die gesamte Kommunikation läuft über HTTPS. Die API hat keine unverschlüsselte Variante — eine http://-Anfrage wird auf HTTPS umgeleitet, die Umleitung behält den POST-Body jedoch nicht bei, sodass die Nachricht nicht gesendet wird. Rufen Sie immer direkt https:// auf und verlassen Sie sich nie auf die Umleitung.

Wir akzeptieren TLS 1.2 und 1.3; das ältere TLS 1.0 und 1.1 lehnt der Server ab. Läuft Ihre Integration in einer älteren Umgebung, stellen Sie sicher, dass deren HTTP-Client TLS 1.2 beherrscht — sonst scheitert die Verbindung, bevor die Anfrage überhaupt gesendet wird. Dasselbe gilt für den Backup-Server.

Die Kommunikation mit Anbietern ist immer verschlüsselt. Die Verschlüsselung endet nicht bei Ihrer Anfrage. Der zweite Abschnitt der Strecke ist auf dieselbe Weise geschützt — ob die Nachricht 0-Hop direkt zum Betreiber geht, über einen lokalen Anbieter oder über einen Hub.

Das Portal ist durch Sicherheits-Header geschützt. Es sendet dem Browser diese:

• Content Security Policy — Skripte laufen nur mit einer einmaligen nonce.
• X-Content-Type-Options: nosniff — der Browser darf den Inhaltstyp nicht erraten.
• X-Frame-Options: SAMEORIGIN — die Seite kann nicht in einen fremden Frame eingebettet werden, Schutz vor Clickjacking.
• Referrer-Policy: strict-origin-when-cross-origin — eine fremde Domain erhält nicht den vollständigen Pfad mit seinen Parametern.
• Feature-Policy — Mikrofon, Kamera und die Payment-API sind im Portal abgeschaltet.

Passwörter werden NICHT im Klartext gespeichert. Gespeichert wird nur ein Argon2id-Hash — das Passwort lässt sich aus der Datenbank nicht zurückgewinnen, selbst wenn jemand sie in die Hände bekäme. Mit Einmalcodes verfahren wir genauso: Ein OTP-Code liegt in der Datenbank als Argon2id-Hash, nicht als lesbare Zahl, sodass ihn auf unserer Seite niemand lesen kann.

API-Token sind in der Datenbank verschlüsselt. Ein Token wird verschlüsselt (AES-256) gespeichert, nicht als lesbare Zeichenkette.

Warum das für große Kunden zählt

Der Unterschied zwischen Anbietern liegt nicht darin, ob sie die Nachricht senden, sondern auf welchem Weg. Bei uns geht eine Nachricht zuerst 0-Hop direkt in das Netz des Betreibers; wo wir eine solche Anbindung nicht haben, über einen lokalen Anbieter im jeweiligen Land; und nur in einem Minimum an Fällen über einen SMS-Hub. Je weiter oben in dieser Reihenfolge eine Nachricht läuft, desto früher kommt sie an, desto genauer ist ihr Zustellbericht und desto weniger Hände berühren sie — und bei Hunderttausenden Nachrichten im Monat zeigt sich dieser Unterschied in der Zustellstatistik ebenso wie auf der Rechnung.

Der Rest kommt noch hinzu: Betrieb an drei Standorten mit automatischem Failover, ein Backup-Server für einen Ausfall auf der Strecke, Server in der EU ohne Datenübermittlung in Drittländer, verschlüsselte Kommunikation auf beiden Abschnitten der Strecke und SMPP für Volumina, bei denen die HTTP-API an ihre Grenzen stößt. Über dem eigentlichen Datenverkehr läuft der Schutz vor Phishing und SMS-Pumping, der einen Angriff auf Ihr Formular stoppt, bevor er teuer wird. Wir betreiben den Dienst seit 2012, sodass Sie darauf eine Integration aufbauen können, die Sie nicht in einem Jahr neu schreiben müssen.