¿Qué es nuestro software para la CCPA?
El año pasado, mi socio y yo decidimos ofrecer una solución de software de cumplimiento para gestionar solicitudes de ejercicio de derechos mediante un formulario web y un Toll-Free Number, que permite a las empresas cumplir los requisitos de la Ley de Privacidad del Consumidor de California (CCPA). Desde entonces, hemos ido añadiendo funciones de nivel empresarial como el cifrado en reposo al 100 %, la autenticación multifactor para mayor seguridad y recordatorios de plazos de las solicitudes para todos nuestros usuarios. Mi socio es abogado de profesión, y yo soy ingeniero y ayudé a crear la solución de software para la línea de privacidad 866-I-OPT-OUT (866-467-8688).
Si siente curiosidad por el funcionamiento interno de nuestra solución SaaS, ¡siga leyendo!
Construimos CCPATollfree.com en tres partes. En primer lugar, un panel publica los datos de configuración y gestión de la cuenta de nuestros usuarios en una base de datos Postgres. En segundo lugar, usamos algunos de esos datos para habilitar una experiencia de voz programable de Twilio y una integración de formulario web que envía las solicitudes a nuestra base de datos. En tercer lugar, usamos procesos en segundo plano para enviar informes a nuestros usuarios y calcular el uso de llamadas de cada cuenta. Analicemos a fondo cada una de las tres partes.
Configuración y gestión de la cuenta
El panel le permite crear Service Codes, que puede imaginar como repositorios independientes donde los consumidores pueden registrar sus preferencias de privacidad. Son un medio para segmentar lógicamente las solicitudes de ejercicio de derechos. Por ejemplo, es habitual que los clientes empresariales tengan varias marcas y publiquen el mismo número de teléfono con distintos Service Codes en diferentes sitios web. Además de segmentar las solicitudes, puede personalizar el saludo asociado a cada Service Code para que la experiencia telefónica sea distinta en cada uno. Toda esta configuración se publica y almacena en tiempo real en una base de datos Postgres. Almacenamos los saludos en un bucket de Amazon S3 y los ponemos a disposición en tiempo real para cuando los consumidores llamen a su Toll-Free Number.
Cada pestaña que ve en el panel es un recurso de nuestro backend que tiene ciertas acciones asociadas. El backend es una aplicación Ruby on Rails. Para cada uno de nuestros clientes es fundamental que los datos almacenados en una base de datos compartida no se filtren entre cuentas de clientes distintos. Cada controlador de esos recursos solo puede devolver datos que pertenezcan a la cuenta del usuario que ha iniciado sesión. Esto es lo que llamamos segmentación horizontal de los datos, y evita que se muestren registros de la base de datos que pertenezcan a otra cuenta. Otro tipo de segmentación es la segmentación vertical: solo se ponen a disposición de la interfaz de usuario las columnas estrictamente necesarias para ella. Para garantizar este comportamiento, probamos cada endpoint para asegurarnos de que ningún dato incumpla la segmentación horizontal ni la vertical. Para los clientes empresariales que requieren el máximo nivel de garantía, ofrecemos instancias de nuestra aplicación en nube privada conectadas a una base de datos exclusiva en lugar de compartida.
Experiencia con Twilio y el formulario web
Twilio ofrece un producto llamado voz programable (programmable voice). La capacidad de llamadas entrantes es ilimitada en la arquitectura de Twilio, lo que significa que podemos aceptar un número ilimitado de llamadas entrantes simultáneas por segundo. Es una parte fundamental de nuestra arquitectura que nos permite usar un número compartido entre cientos de clientes distintos, por grandes que sean. Twilio da soporte de telefonía a usuarios como Uber en números compartidos, así que creemos que nos bastará durante bastante tiempo.
La voz programable de Twilio realiza una solicitud HTTP por cada interacción de un consumidor. La experiencia comienza cuando un consumidor llama a nuestro número de teléfono: 1-866-467-8688 o 1-866-I-OPT-OUT. La solicitud llega a nuestro backend, que responde con XML indicando cómo debe comportarse Twilio. Por ejemplo, al introducir el Service Code 1#, nuestro backend usa los datos de configuración disponibles en el panel para dirigir a Twilio al siguiente paso de la experiencia: escuchar el saludo del Service Code 1.
Al integrar nuestro servicio en su sitio web, tendrá acceso a nuestro formulario web, que envía las solicitudes a su panel junto con las que recibe por su Toll-Free Number. ¿Ha notado que el formulario web incluye un RECAPTCHA? Es una herramienta gratuita de Google que protege los formularios web. Genera un token en el backend de Google, que recibimos en nuestro formulario web y pasamos a nuestro backend. A continuación, comprobamos la validez de ese token con el servicio RECAPTCHA de Google. De hecho, protegemos todos los endpoints. Usamos una gema de Ruby llamada Devise para asegurarnos de que todos los usuarios estén autenticados antes de permitirles acceder a los datos. Usamos tecnología de firmas con comprobación de marcas de tiempo para evitar ataques de repetición en los webhooks. También incluimos los orígenes en una lista blanca para que ningún tercero pueda ofrecer un formulario web que envíe solicitudes a su panel. Por eso debe enviarnos un correo solicitando que configuremos su dominio para comunicarse con nuestra aplicación mediante HTTPS.
Procesos en segundo plano
La última pieza fundamental de nuestra arquitectura son los procesos en segundo plano. Los usamos para tareas como calcular de forma asíncrona el uso de telefonía de cada cuenta, que luego enviamos a Stripe a diario. También generamos los correos de informes que enviamos según las preferencias que haya seleccionado en el panel. Estos procesos se ejecutan en nuestra infraestructura construida sobre Heroku y también están segmentados por cuenta para garantizar que los datos nunca se filtren entre cuentas. Por correo solo enviamos datos agregados, por lo que los correos nunca contienen información sensible.
Otra parte importante de nuestro trabajo asíncrono es la capacidad de reproducir flujos de datos en caso de fallo de red o de cómputo. Para hacer seguimiento del uso de cada cuenta (p. ej., el número de llamadas), abrimos una transacción en la base de datos, actualizamos el uso a «procesado» y después enviamos a Stripe el recuento agregado de uso a diario. Si todo va bien, confirmamos la transacción. Si algo falla, revertimos el uso a «no procesado». Si se produce un error después de la llamada a Stripe y antes de que se complete la transacción, podemos gestionar los problemas que predice el teorema CAP volviendo a calcular el recuento diario de llamadas de cada cuenta.
Supervisamos los procesos en segundo plano con Papertrail y New Relic y recibimos alertas cada vez que algo falla. De hecho, el mismo nivel de alertas existe en cada parte de nuestro sistema. Recibimos alertas cuando algo falla con Twilio, el backend, el formulario web, nuestro servidor de correo o los pagos de Stripe, para poder resolver cualquier incidencia en cuanto se produzca. Esto forma parte de nuestro compromiso de ofrecer soporte de nivel empresarial a nuestros clientes.
CCPA Toll Free está ampliando sus funciones siguiendo el mismo modelo de seguridad y supervisión que nos propusimos desde el principio. En nuestra hoja de ruta tenemos numerosas alianzas, integraciones y mucho más por desarrollar. No dude en escribirnos a support@optacy.com con sus preguntas y solicitudes de funciones.