Infrastruktur

Hva BulkGate kjører på, hvordan meldinger når frem til operatørenes nett, hvordan vi beskytter trafikken, og hva det betyr for en integrasjon som må holde under topplast.

Tre lokasjoner

Tjenesten kjører på flere servere i tre geografiske lokasjoner. Det er ikke én maskin med en reserve, men samtidig drift — hvis én av lokasjonene faller ut, overtar de øvrige trafikken automatisk og uten at du trenger å gjøre noe. For integrasjonen din endres ingenting: portal.bulkgate.com svarer fortsatt, og forespørslene går ut på samme måte.

Det failoveren ikke dekker, er veien til oss — et brudd hos internettleverandøren din, hos en operatør eller hvor som helst på veien mellom serveren din og vår. Til det finnes reserveserveren.

Infrastrukturen er bygget for å tåle utfall og er beskyttet mot DDoS av WEDOS Global Protection. Trafikken når ikke serverne våre direkte — den går gjennom deres anycast-nett med over 120 noder, der den nærmeste noden tar imot den. Et angrep blir spredt og filtrert hos dem før det i det hele tatt når oss; serverne våre håndterer bare de legitime forespørslene som slipper gjennom. Anycast korter også ned veien for forespørselen din, fordi noden som er nærmest deg, tar imot den.

WEDOS lagrer også logger, konfigurasjon og analyser innenfor EU, så heller ikke DDoS-beskyttelsen fører data ut av unionen — se Servere i EU.

Gjeldende status for tjenesten finner du på bulkgate.status.online.

Servere i EU

Alle serverne våre kjører i EU. Dataene dine forlater derfor ikke EU, og du trenger ikke å forholde deg til overføringer til tredjeland eller standard personvernbestemmelser.

Hvordan vi behandler personopplysninger, er beskrevet i Vilkårene for behandling av personopplysninger og i Personvernerklæringen.

Tilkoblinger til operatører

Vi leverer meldinger via direkte tilkoblinger til operatører i Europa, Asia, Afrika og i Nord-, Mellom- og Sør-Amerika.

Hva 0-hop betyr

En direkte tilkobling er en 0-hop-tilkobling — ingen andre står mellom oss og operatørens SMSC. Meldingen går fra gatewayen vår rett inn i mottakernettet. Det er den høyeste mulige leveringskvaliteten; det finnes ingen bedre rute til mottakernummeret, fordi det ikke finnes noen kortere.

Hvert mellomledd på ruten er et sted der noe kan gå galt:

Derfor bygger vi direkte tilkoblinger der vi kan. Ved store volumer og tidskritiske meldinger — OTP-koder, ordrebekreftelser — merkes forskjellen mest.

I dag har vi 0-hop til mer enn 50 land, og antallet vokser stadig.

Der vi ikke har 0-hop, er førstevalget en lokal leverandør i det aktuelle landet — ett mellomledd som kjenner det lokale markedet, ikke en kjede av aggregatorer. Først når det ikke finnes en eneste slik, leverer vi via SMS-huber; dem har vi som reserve for et minimum av destinasjoner, ikke som den vanlige ruten.

RCS via direkte tilkobling til Google

Direkte tilkoblinger stopper ikke ved SMS. RCS Business Messaging kjører på Googles plattform. Vi har en direkte tilkobling til den og i tillegg egne avtaler med operatørene — begge deler trengs: Google godkjenner agenten og innholdet, operatøren slipper trafikken inn i nettet sitt. Uten en av dem når en RCS-melding aldri frem til mottakeren.

Hva RCS gir deg i tillegg til SMS:

Meldingstyper og hvordan de faktureres, er beskrevet i Typer RCS Business-meldinger; oppsett av agenten i Chatinnstillinger for RCS Business Messaging.

Viber som offisiell partner

For Viber er vi en offisiell partner, ikke en forhandler — du finner oss i deres katalog over meldingspartnere. Meldingene går derfor ut via den godkjente ruten rett inn i Vibers nett, og vi registrerer avsenderen din direkte hos dem.

Hva det betyr i praksis:

Meldingstyper og økter er beskrevet i Typer Viber-meldinger.

SMPP for store volumer

Ved siden av HTTP API-et tilbyr vi større kunder en SMPP-tilkobling — protokollen som selve SMS-nettene kjører på. Den lønner seg der volumene er jevnt høye og du trenger å holde en økt åpen i stedet for å sende enkeltstående HTTP-forespørsler.

SMPP settes opp individuelt; ta kontakt med oss, så går vi gjennom volumene og parameterne dine.

Prioritering av meldinger

Ikke alle meldinger kan vente like lenge. En kode som brukeren sitter og venter på i et skjema, må gå ut med en gang; en kampanje til hundre tusen numre lider ikke av ett sekund ekstra. Derfor deler vi trafikken inn i separate køer og behandler dem i denne rekkefølgen:

Køene forbigår ikke hverandre: en stor kampanje som allerede er i gang, holder ikke igjen en OTP-kode som kommer midt i den.

Beskyttelse mot phishing og SMS-pumping

Vi vurderer trafikken fortløpende for å fange opp to ting som skader både avsendere og mottakere.

Phishing. Hver melding kontrolleres mot mønstre fra kjente svindelkampanjer — både avsender-ID-en og teksten, og separat for hvert mottakerland. Kontrollen tar også høyde for etterligninger: den fanger opp et navn eller en formulering som med vilje er endret med noen få tegn for å slippe forbi en bokstavelig sammenligning. Det beskytter merkevaren din mot å bli utgitt for og avsender-ID-en din mot å få dårligere omdømme hos operatøren.

SMS-pumping. Kunstig generert trafikk (AGT) — en angriper presser OTP-koder gjennom skjemaet ditt til numre i premiumserier og får en andel av prisen deres. Derfor følger vi med på trafikkens form, ikke innholdet. Så snart vi ser trafikk som ikke stemmer med det kontoen vanligvis sender — en plutselig økning eller uvanlige destinasjoner — stopper vi utsendelsen og varsler deg på e-post og SMS. Angrepet stanses før det blir dyrt; skaden begrenser seg til det som allerede er sendt.

Du kan avverge et angrep på ditt eget skjema ved å angi request_quota_identification og request_quota_number i OTP-API-et — kvoten er knyttet til den som sender forespørselen, typisk IP-adressen. Portalen legger i tillegg til geografiske begrensninger og daglige utsendelsesgrenser; hvordan du setter dem opp, er beskrevet i Hacked OTP SMS: Protect yourself with BulkGate API limits!.

Sikkerhet for kommunikasjon og data

All kommunikasjon går over HTTPS. API-et har ingen ukryptert variant — en http://-forespørsel blir omdirigert til HTTPS, men omdirigeringen beholder ikke POST-innholdet, så meldingen blir ikke sendt. Kall alltid https:// direkte og stol aldri på omdirigeringen.

Vi godtar TLS 1.2 og 1.3; de eldre TLS 1.0 og 1.1 avvises av serveren. Hvis integrasjonen din kjører i et eldre miljø, må du sørge for at HTTP-klienten støtter TLS 1.2 — ellers mislykkes tilkoblingen før forespørselen i det hele tatt blir sendt. Det samme gjelder reserveserveren.

Kommunikasjonen med leverandørene er alltid kryptert. Krypteringen stopper ikke ved forespørselen din. Den andre etappen av ruten er beskyttet på samme måte — enten meldingen går 0-hop rett til operatøren, via en lokal leverandør eller via en hub.

Portalen er beskyttet med sikkerhetshoder. Den sender disse til nettleseren:

• Content Security Policy — skript kjøres bare med en engangs-nonce.
• X-Content-Type-Options: nosniff — nettleseren får ikke gjette innholdstypen.
• X-Frame-Options: SAMEORIGIN — siden kan ikke bygges inn i en fremmed ramme, beskyttelse mot clickjacking.
• Referrer-Policy: strict-origin-when-cross-origin — et fremmed domene får ikke hele stien med parameterne.
• Feature-Policy — mikrofon, kamera og betalings-API-et er slått av i portalen.

Passord lagres IKKE i klartekst. Det lagres bare en Argon2id-hash — passordet kan ikke utledes fra databasen, selv om noen skulle få tak i den. Engangskoder håndteres på samme måte: en OTP-kode lagres i databasen som en Argon2id-hash, ikke som et lesbart tall, så ingen hos oss kan lese den.

API-tokener er kryptert i databasen. Et token lagres kryptert (AES-256), ikke som en lesbar streng.

Hvorfor store kunder bryr seg

Forskjellen mellom leverandørene er ikke om de sender meldingen, men hvilken vei. Hos oss går en melding først 0-hop rett inn i operatørens nett; der vi ikke har en slik tilkobling, via en lokal leverandør i det aktuelle landet; og bare i et minimum av tilfeller via en SMS-hub. Jo høyere opp i denne rekkefølgen en melding går, desto raskere kommer den frem, desto mer nøyaktig er leveringsrapporten, og desto færre hender er innom den — og ved hundretusenvis av meldinger i måneden merkes den forskjellen både i leveringsstatistikken og på fakturaen.

Resten kommer i tillegg: drift i tre lokasjoner med automatisk failover, en reserveserver for brudd på ruten, servere i EU uten overføring av data til tredjeland, kryptert kommunikasjon på begge etapper av ruten og SMPP for volumer som HTTP API-et begynner å slite med. Oppå selve trafikken kjører beskyttelse mot phishing og SMS-pumping, som stopper et angrep på skjemaet ditt før det blir dyrt. Vi har drevet tjenesten siden 2012, så du kan bygge en integrasjon på den som du ikke må skrive om om et år.