Infraestrutura

Em que assenta a BulkGate, por onde as mensagens chegam às redes dos operadores, como protegemos o tráfego e o que isso significa para uma integração que tem de aguentar os picos.

Três localizações

O serviço funciona em vários servidores em três localizações geográficas. Não se trata de uma máquina com uma de reserva, mas de funcionamento em simultâneo — se qualquer uma das localizações falhar, as restantes assumem o tráfego automaticamente e sem qualquer intervenção da sua parte. Para a sua integração nada muda: portal.bulkgate.com continua a responder e os pedidos seguem pelo mesmo caminho.

O que o failover não cobre é o caminho até nós — uma falha no seu fornecedor de conectividade, numa operadora ou em qualquer ponto do percurso entre o seu servidor e o nosso. Para isso existe o servidor de reserva.

A infraestrutura foi concebida para resistir a falhas e está protegida contra DDoS pela WEDOS Global Protection. O tráfego não chega diretamente aos nossos servidores — passa pela sua rede anycast com mais de 120 nós, onde o nó mais próximo o recebe. Um ataque é dispersado e filtrado do lado deles antes de chegar até nós; os nossos servidores lidam apenas com os pedidos legítimos que passam. O anycast também encurta o caminho do seu pedido, porque é o nó mais próximo de si que o recebe.

A WEDOS guarda também os registos, a configuração e as análises dentro da UE, pelo que nem a proteção contra DDoS leva dados para fora da União — consulte Servidores na UE.

O estado atual do serviço está em bulkgate.status.online.

Servidores na UE

Todos os nossos servidores funcionam na União Europeia. Os seus dados não saem, portanto, da UE e não tem de lidar com transferências para países terceiros nem com cláusulas contratuais-tipo.

A forma como tratamos os dados pessoais está descrita nas Condições de tratamento de dados pessoais e na Política de privacidade.

Ligações a operadores

Entregamos as mensagens através de ligações diretas a operadores na Europa, na Ásia, em África e na América do Norte, Central e do Sul.

O que significa 0-hop

Uma ligação direta é uma ligação 0-hop — ninguém se interpõe entre nós e o SMSC do operador. A mensagem segue do nosso gateway diretamente para a rede de destino. É a mais alta qualidade de entrega possível; não existe melhor caminho até ao número de destino, porque não existe um mais curto.

Cada intermediário no percurso é um ponto onde algo pode correr mal:

É por isso que criamos ligações diretas sempre que possível. Em grandes volumes e com mensagens urgentes — códigos OTP, confirmações de encomendas — a diferença nota-se mais.

Hoje temos 0-hop para mais de 50 países, e o número continua a crescer.

Onde não temos 0-hop, a primeira opção é um fornecedor local nesse país — um único intermediário que conhece o mercado local, não uma cadeia de agregadores. Só quando nem esse existe é que entregamos através de hubs SMS; mantemo-los como recurso para um número mínimo de destinos, não como o caminho habitual.

RCS através de uma ligação direta à Google

As ligações diretas não ficam pelo SMS. O RCS Business Messaging funciona na plataforma da Google. Temos uma ligação direta a ela e ainda acordos próprios com os operadores — ambos são necessários: a Google aprova o agente e o conteúdo, o operador deixa o tráfego entrar na sua rede. Sem qualquer um deles, uma mensagem RCS nunca chega ao destinatário.

O que o RCS acrescenta em relação ao SMS:

Os tipos de mensagens e a forma como são faturados são abordados em Tipos de mensagens RCS; a configuração do agente em Definições do chat RBM.

Viber como parceiro oficial

No Viber somos parceiro oficial, não revendedor — encontra-nos no diretório de parceiros de mensagens. As mensagens seguem, portanto, pelo caminho aprovado diretamente para a rede do Viber e registamos o seu remetente diretamente junto deles.

O que isso significa na prática:

Os tipos de mensagens e as sessões são abordados em Tipos de mensagens Viber.

SMPP para grandes volumes

Além da API HTTP, oferecemos aos clientes de maior dimensão uma ligação SMPP — o protocolo em que as próprias redes SMS funcionam. Compensa quando os volumes são constantemente elevados e precisa de manter uma sessão aberta em vez de enviar pedidos HTTP individuais.

O SMPP é configurado individualmente; contacte-nos e analisaremos consigo os seus volumes e parâmetros.

Priorização das mensagens

Nem todas as mensagens podem esperar o mesmo. Um código para o qual o utilizador está a olhar num formulário tem de sair de imediato; uma campanha para cem mil números não sofre com um segundo a mais. Por isso, dividimos o tráfego em filas separadas e servimo-las por esta ordem:

As filas não se ultrapassam umas às outras: uma campanha grande já em curso não atrasa um código OTP que chegue a meio dela.

Proteção contra phishing e SMS pumping

Avaliamos o tráfego continuamente para detetar duas coisas que prejudicam tanto os remetentes como os destinatários.

Phishing. Cada mensagem é verificada em relação a padrões de campanhas fraudulentas conhecidas — tanto o ID do remetente como o texto, e separadamente para cada país de destino. A verificação tem também em conta imitações: deteta um nome ou uma formulação deliberadamente alterados em alguns caracteres para escapar a uma comparação literal. Isto protege a sua marca contra a usurpação de identidade e o seu ID de remetente contra danos de reputação junto do operador.

SMS pumping. Tráfego gerado artificialmente (AGT) — um atacante faz passar códigos OTP pelo seu formulário para números de gamas premium e recebe uma parte do seu preço. Por isso, observamos o padrão do tráfego, não o seu conteúdo. Assim que detetamos tráfego que não corresponde ao que a conta normalmente envia — um aumento repentino ou destinos invulgares — paramos o envio e notificamo-lo por e-mail e SMS. O ataque é travado antes de ficar caro; o prejuízo fica limitado ao que já tiver sido enviado.

Pode prevenir um ataque ao seu próprio formulário definindo request_quota_identification e request_quota_number na API OTP — a quota está associada a quem faz o pedido, normalmente ao seu endereço IP. O portal acrescenta ainda restrições geográficas e limites diários de envio; a forma de os configurar é abordada em Hacked OTP SMS: Protect yourself with BulkGate API limits!.

Segurança da comunicação e dos dados

Toda a comunicação passa por HTTPS. A API não tem variante não encriptada — um pedido http:// é redirecionado para HTTPS, mas o redirecionamento não preserva o corpo do POST, pelo que a mensagem não é enviada. Chame sempre diretamente https:// e nunca confie no redirecionamento.

Aceitamos TLS 1.2 e 1.3; as versões mais antigas TLS 1.0 e 1.1 são recusadas pelo servidor. Se a sua integração funcionar num ambiente mais antigo, certifique-se de que o respetivo cliente HTTP suporta TLS 1.2 — caso contrário, a ligação falha antes mesmo de o pedido ser enviado. O mesmo se aplica ao servidor de reserva.

A comunicação com os fornecedores é sempre encriptada. A encriptação não termina no seu pedido. O segundo troço do percurso está protegido da mesma forma — quer a mensagem siga 0-hop diretamente para o operador, através de um fornecedor local ou através de um hub.

O portal está protegido por cabeçalhos de segurança. Envia ao navegador os seguintes:

• Content Security Policy — os scripts só são executados com um nonce de utilização única.
• X-Content-Type-Options: nosniff — o navegador não pode adivinhar o tipo de conteúdo.
• X-Frame-Options: SAMEORIGIN — a página não pode ser incorporada numa moldura alheia, proteção contra clickjacking.
• Referrer-Policy: strict-origin-when-cross-origin — um domínio alheio não recebe o caminho completo com os respetivos parâmetros.
• Feature-Policy — o microfone, a câmara e a API de pagamentos estão desativados no portal.

As palavras-passe NÃO são guardadas em texto simples. É guardado apenas um hash Argon2id — a palavra-passe não pode ser reconstituída a partir da base de dados, mesmo que alguém lhe tenha acesso. Os códigos de utilização única são tratados da mesma forma: um código OTP é mantido na base de dados como hash Argon2id, não como número legível, pelo que ninguém do nosso lado o consegue ler.

Os tokens de API são encriptados na base de dados. Um token é guardado encriptado (AES-256), não como cadeia de caracteres legível.

Porque é que isto importa aos grandes clientes

A diferença entre fornecedores não está em enviarem ou não a mensagem, mas por que caminho. Connosco, uma mensagem segue primeiro 0-hop diretamente para a rede do operador; onde não temos essa ligação, através de um fornecedor local nesse país; e só num número mínimo de casos através de um hub SMS. Quanto mais acima nesta ordem a mensagem viajar, mais depressa chega, mais preciso é o seu relatório de entrega e menos mãos lhe tocam — e com centenas de milhares de mensagens por mês essa diferença nota-se tanto nas estatísticas de entrega como na fatura.

O resto vem por acréscimo: funcionamento em três localizações com failover automático, um servidor de reserva para uma falha no percurso, servidores na UE sem transferência de dados para países terceiros, comunicação encriptada em ambos os troços do percurso e SMPP para volumes com que a API HTTP começa a ter dificuldades. Sobre o próprio tráfego funciona a proteção contra phishing e SMS pumping, que trava um ataque ao seu formulário antes de ficar caro. Operamos o serviço desde 2012, pelo que pode construir sobre ele uma integração que não terá de reescrever daqui a um ano.