Infraestructura

Sobre qué funciona BulkGate, cómo llegan los mensajes a las redes de los operadores, cómo protegemos el tráfico y qué significa todo ello para una integración que tiene que aguantar los picos de carga.

Tres ubicaciones

El servicio funciona en varios servidores situados en tres ubicaciones geográficas. No se trata de una máquina con otra de reserva, sino de un funcionamiento simultáneo: si alguna de las ubicaciones cae, las restantes asumen el tráfico automáticamente y sin que usted tenga que hacer nada. Para su integración no cambia nada: portal.bulkgate.com sigue respondiendo y las solicitudes se envían igual que siempre.

Lo que la conmutación por error no cubre es el camino hasta nosotros: una caída de su proveedor de conectividad, de un operador de red o de cualquier punto del trayecto entre su servidor y el nuestro. Para eso existe el servidor de respaldo.

La infraestructura está diseñada para resistir caídas y está protegida contra ataques DDoS por WEDOS Global Protection. El tráfico no llega directamente a nuestros servidores: pasa por su red anycast de más de 120 nodos, donde lo recoge el nodo más cercano. Un ataque se reparte y se filtra en su lado antes de llegar a nosotros; nuestros servidores solo atienden las solicitudes legítimas que pasan el filtro. Además, anycast acorta el recorrido de su solicitud, porque la recoge el nodo más próximo a usted.

WEDOS también guarda los registros, la configuración y los análisis dentro de la UE, de modo que ni siquiera la protección contra DDoS saca datos fuera de la Unión; consulte Servidores en la UE.

El estado actual del servicio se puede consultar en bulkgate.status.online.

Servidores en la UE

Todos nuestros servidores funcionan en la Unión Europea. Por tanto, sus datos no salen de la UE y no tiene que ocuparse de transferencias a terceros países ni de cláusulas contractuales tipo.

Cómo tratamos los datos personales se describe en las Condiciones de tratamiento de datos personales y en la Política de privacidad.

Conexiones con operadores

Entregamos los mensajes a través de conexiones directas con operadores en Europa, Asia, África y en América del Norte, Central y del Sur.

Qué significa 0-hop

Una conexión directa es una conexión 0-hop: no hay nadie más entre nosotros y el SMSC del operador. El mensaje pasa de nuestra pasarela directamente a la red de destino. Es la máxima calidad de entrega posible; no existe una ruta mejor hasta el número de destino, porque no existe una más corta.

Cada intermediario en la ruta es un punto en el que algo puede salir mal:

Por eso creamos conexiones directas siempre que podemos. Con grandes volúmenes y con mensajes en los que el tiempo es crítico (códigos OTP, confirmaciones de pedidos) es donde más se nota la diferencia.

Hoy tenemos 0-hop en más de 50 países, y la cifra sigue creciendo.

Donde no tenemos 0-hop, la primera opción es un proveedor local dentro del país: un único intermediario que conoce el mercado local, no una cadena de agregadores. Solo cuando no existe ni siquiera uno de ellos entregamos a través de hubs de SMS; los mantenemos como alternativa para un número mínimo de destinos, no como la ruta habitual.

RCS mediante una conexión directa con Google

Las conexiones directas no se limitan a los SMS. RCS Business Messaging funciona sobre la plataforma de Google. Tenemos una conexión directa con ella y además acuerdos propios con los operadores; hacen falta ambas cosas: Google aprueba el agente y el contenido, y el operador deja entrar el tráfico en su red. Sin cualquiera de las dos, un mensaje RCS nunca llega al destinatario.

Qué aporta RCS frente a los SMS:

Los tipos de mensajes y cómo se facturan se explican en Tipos de mensajes RCS; la configuración del agente, en Configuración del chat RCS.

Viber como socio oficial

En Viber somos socio oficial, no revendedor; nos encontrará en su directorio de socios de mensajería. Por eso los mensajes salen por la ruta aprobada directamente a la red de Viber y registramos su remitente directamente con ellos.

Qué significa esto en la práctica:

Los tipos de mensajes y las sesiones se explican en Tipos de mensajes de Viber.

SMPP para grandes volúmenes

Además de la API HTTP, ofrecemos a los clientes más grandes una conexión SMPP, el protocolo sobre el que funcionan las propias redes de SMS. Resulta rentable cuando los volúmenes son altos de forma continuada y necesita mantener una sesión abierta en lugar de enviar solicitudes HTTP individuales.

SMPP se configura de forma individual; póngase en contacto con nosotros y repasaremos juntos sus volúmenes y parámetros.

Priorización de mensajes

No todos los mensajes pueden esperar lo mismo. Un código que el usuario está esperando con la vista fija en un formulario tiene que salir de inmediato; una campaña a cien mil números no sufrirá por un segundo de más. Por eso dividimos el tráfico en colas separadas y las atendemos en este orden:

Las colas no se adelantan unas a otras: una campaña grande que ya está en curso no retrasará un código OTP que llegue en medio de ella.

Protección contra el phishing y el SMS pumping

Evaluamos el tráfico de forma continua para detectar dos cosas que perjudican tanto a los remitentes como a los destinatarios.

Phishing. Cada mensaje se compara con patrones de campañas fraudulentas conocidas, tanto el ID de remitente como el texto, y por separado para cada país de destino. La comprobación también tiene en cuenta las imitaciones: detecta un nombre o una redacción alterados deliberadamente en unos pocos caracteres para burlar una comparación literal. Así se protege su marca frente a la suplantación y su ID de remitente frente a un daño de reputación ante el operador.

SMS pumping. Tráfico generado artificialmente (AGT): un atacante envía códigos OTP a través de su formulario a números de rangos premium y se queda con una parte de su precio. Por eso vigilamos la forma del tráfico, no su contenido. En cuanto vemos un tráfico que no corresponde a lo que la cuenta envía normalmente (un aumento repentino o destinos inusuales), detenemos el envío y se lo notificamos por correo electrónico y SMS. El ataque se corta antes de que salga caro; el daño se limita a lo que ya se haya enviado.

Puede prevenir un ataque a su propio formulario configurando request_quota_identification y request_quota_number en la API de OTP: la cuota se vincula al solicitante, normalmente a su dirección IP. El portal añade además restricciones geográficas y límites diarios de envío; cómo configurarlos se explica en Hacked OTP SMS: Protect yourself with BulkGate API limits!.

Seguridad de las comunicaciones y de los datos

Toda la comunicación se realiza por HTTPS. La API no tiene ninguna variante sin cifrar: una solicitud http:// se redirige a HTTPS, pero la redirección no conserva el cuerpo del POST, por lo que el mensaje no se envía. Llame siempre directamente a https:// y no confíe nunca en la redirección.

Aceptamos TLS 1.2 y 1.3; el servidor rechaza las versiones antiguas TLS 1.0 y 1.1. Si su integración funciona en un entorno antiguo, asegúrese de que su cliente HTTP admite TLS 1.2; de lo contrario, la conexión falla antes incluso de que se envíe la solicitud. Lo mismo se aplica al servidor de respaldo.

La comunicación con los proveedores siempre está cifrada. El cifrado no termina en su solicitud. El segundo tramo de la ruta está protegido de la misma manera, tanto si el mensaje va 0-hop directamente al operador como si pasa por un proveedor local o por un hub.

El portal está protegido por cabeceras de seguridad. Envía al navegador las siguientes:

• Content Security Policy: los scripts solo se ejecutan con un nonce de un solo uso.
• X-Content-Type-Options: nosniff: el navegador no debe adivinar el tipo de contenido.
• X-Frame-Options: SAMEORIGIN: la página no se puede incrustar en un marco ajeno, protección contra el clickjacking.
• Referrer-Policy: strict-origin-when-cross-origin: a un dominio ajeno no se le facilita la ruta completa con sus parámetros.
• Feature-Policy: el micrófono, la cámara y la API de pagos están desactivados en el portal.

Las contraseñas NO se guardan en texto plano. Solo se conserva un hash Argon2id: la contraseña no se puede obtener de vuelta a partir de la base de datos, ni siquiera si alguien se hiciera con ella. Los códigos de un solo uso se tratan igual: un código OTP se guarda en la base de datos como hash Argon2id, no como un número legible, de modo que nadie de nuestro lado puede leerlo.

Los tokens de la API están cifrados en la base de datos. Un token se guarda cifrado (AES-256), no como una cadena legible.

Por qué les importa a los grandes clientes

La diferencia entre proveedores no está en si envían el mensaje, sino en por qué camino. Con nosotros, un mensaje va primero 0-hop directamente a la red del operador; donde no tenemos esa conexión, a través de un proveedor local en ese país; y solo en un número mínimo de casos a través de un hub de SMS. Cuanto más arriba en este orden viaja un mensaje, antes llega, más preciso es su informe de entrega y menos manos lo tocan; y con cientos de miles de mensajes al mes esa diferencia se nota tanto en las estadísticas de entrega como en la factura.

A eso se suma todo lo demás: funcionamiento en tres ubicaciones con conmutación por error automática, un servidor de respaldo para una caída en la ruta, servidores en la UE sin transferencia de datos a terceros países, comunicación cifrada en ambos tramos de la ruta y SMPP para los volúmenes con los que la API HTTP empieza a tener dificultades. Por encima del propio tráfico funciona la protección contra el phishing y el SMS pumping, que detiene un ataque a su formulario antes de que salga caro. Ofrecemos el servicio desde 2012, así que puede construir sobre él una integración que no tendrá que reescribir dentro de un año.