Was ist unsere CCPA-Software?
Letztes Jahr haben mein Geschäftspartner und ich beschlossen, eine Compliance-Softwarelösung anzubieten, mit der Unternehmen Datenschutzanfragen über ein Webformular und eine Toll-Free Number verwalten und so die Anforderungen des California Consumer Privacy Act (CCPA) erfüllen können. Seitdem haben wir Enterprise-Funktionen ergänzt, etwa 100 % Verschlüsselung ruhender Daten, Multi-Faktor-Authentifizierung für zusätzliche Sicherheit und Fristerinnerungen für Datenschutzanfragen für alle unsere Nutzer. Mein Partner ist von Beruf Jurist, ich bin Ingenieur und habe die Softwarelösung für die Datenschutz-Hotline 866-I-OPT-OUT (866-467-8688) mitentwickelt.
Wenn Sie wissen möchten, wie unsere SaaS-Lösung im Inneren funktioniert, lesen Sie weiter!
Wir haben CCPATollfree.com in drei Teilen aufgebaut. Erstens veröffentlicht ein Dashboard die Kontokonfiguration und Verwaltungsdaten unserer Nutzer in einer Postgres-Datenbank. Zweitens nutzen wir bestimmte dieser Daten für ein Sprachdialogerlebnis mit Twilio Programmable Voice sowie für eine Webformular-Integration, die Datenschutzanfragen zurück in unsere Datenbank sendet. Drittens verwenden wir Background-Jobs, um Berichte an unsere Nutzer zu senden und die Anrufnutzung für jedes Konto zu berechnen. Schauen wir uns alle drei Teile im Detail an.
Kontokonfiguration und -verwaltung
Im Dashboard können Sie Service Codes erstellen. Stellen Sie sich diese als separate Ablagen vor, in denen Verbraucher ihre Datenschutzpräferenzen hinterlegen können. Sie dienen dazu, Datenschutzanfragen logisch zu segmentieren. Enterprise-Kunden besitzen beispielsweise häufig mehrere Marken und veröffentlichen dieselbe Telefonnummer mit unterschiedlichen Service Codes auf verschiedenen Websites. Neben der Segmentierung von Datenschutzanfragen können Sie die Begrüßung für jeden Service Code individuell anpassen, sodass sich das Telefonerlebnis je Service Code unterscheidet. Diese gesamte Konfiguration wird in Echtzeit in einer Postgres-Datenbank veröffentlicht und gespeichert. Begrüßungen speichern wir in einem Amazon-S3-Bucket und stellen sie in Echtzeit bereit, wenn Verbraucher Ihre Toll-Free Number anrufen.
Jeder Tab, den Sie im Dashboard sehen, ist eine Ressource in unserem Backend, der bestimmte Aktionen zugeordnet sind. Das Backend ist eine Ruby-on-Rails-Anwendung. Für jeden unserer Kunden ist entscheidend, dass die in einer gemeinsamen Datenbank gespeicherten Daten nicht zwischen verschiedenen Kundenkonten durchsickern. Jeder Controller für diese Ressourcen kann nur Daten zurückgeben, die zum Konto des aktuell angemeldeten Nutzers gehören. Das nennen wir horizontale Segmentierung der Daten: Sie verhindert, dass Datensätze eines anderen Kontos jemals angezeigt werden. Eine weitere Art ist die vertikale Segmentierung: Der Benutzeroberfläche werden nur die Spalten bereitgestellt, die sie zwingend benötigt. Um dieses Verhalten durchzusetzen, testen wir jeden Endpunkt darauf, dass keine Daten die horizontale oder vertikale Segmentierung verletzen. Für Enterprise-Kunden, die ein Höchstmaß an Sicherheit benötigen, bieten wir Private-Cloud-Instanzen unserer App an, die mit einer eigenen statt einer gemeinsamen Datenbank verbunden sind.
Twilio und das Webformular
Twilio bietet ein Produkt namens Programmable Voice. Eingehende Anrufe skalieren in der Architektur von Twilio unbegrenzt, d. h. wir können beliebig viele gleichzeitige eingehende Anrufe pro Sekunde annehmen. Dieser Teil unserer Architektur ist entscheidend, denn er ermöglicht uns, eine gemeinsame Nummer für Hunderte verschiedener Kunden zu nutzen, unabhängig von deren Größe. Twilio stellt die Telefonie für Nutzer wie Uber über gemeinsame Telefonnummern bereit, daher sind wir zuversichtlich, dass es uns noch eine ganze Weile genügen wird!
Twilio Programmable Voice sendet bei jeder Interaktion eines Verbrauchers einen HTTP-Request. Das Erlebnis beginnt, wenn ein Verbraucher unsere Telefonnummer anruft: 1-866-467-8688 bzw. 1-866-I-OPT-OUT. Der Request erreicht unser Backend, das mit XML antwortet und festlegt, wie sich Twilio verhalten soll. Gibt der Anrufer beispielsweise den Service Code 1# ein, nutzt unser Backend die Konfigurationsdaten aus dem Dashboard, um Twilio zum nächsten Schritt zu leiten: dem Abspielen der Begrüßung für Service Code 1.
Wenn Sie unseren Service auf Ihrer Website integrieren, erhalten Sie Zugriff auf unser Webformular, das Datenschutzanfragen an Ihr Dashboard sendet, neben den Anfragen, die Sie über Ihre Toll-Free Number erhalten. Ist Ihnen aufgefallen, dass das Webformular ein RECAPTCHA enthält? Dabei handelt es sich um ein kostenloses Tool von Google zur Absicherung von Webformularen. Es erzeugt im Backend von Google ein Token, das wir in unserem Webformular empfangen und an unser Backend weitergeben. Anschließend prüfen wir die Gültigkeit dieses Tokens über den RECAPTCHA-Service von Google. Tatsächlich schützen wir jeden Endpunkt. Mit dem Ruby-Gem Devise stellen wir sicher, dass alle Nutzer authentifiziert sind, bevor sie auf Daten zugreifen können. Für Webhooks verwenden wir Signaturen mit Zeitstempelprüfung, um Replay-Angriffe zu verhindern. Zudem setzen wir Origins auf eine Whitelist, damit Dritte kein Webformular bereitstellen können, das Anfragen an Ihr Dashboard sendet. Deshalb müssen Sie uns per E-Mail bitten, Ihre Domain für die Kommunikation mit unserer Anwendung über HTTPS einzurichten.
Background-Jobs
Der letzte zentrale Baustein unserer Architektur sind Background-Jobs. Wir nutzen sie beispielsweise, um die Telefonienutzung jedes Kontos asynchron zu berechnen, die wir anschließend täglich an Stripe übermitteln. Außerdem erstellen wir Berichts-E-Mails, die wir entsprechend Ihren im Dashboard gewählten Einstellungen versenden. Diese Jobs laufen auf unserer Infrastruktur bei Heroku und sind ebenfalls nach Konten segmentiert, damit niemals Daten zwischen Konten durchsickern. Per E-Mail versenden wir ausschließlich aggregierte Daten, sodass E-Mails nie sensible Informationen enthalten.
Ein weiterer wichtiger Teil unserer asynchronen Verarbeitung ist die Möglichkeit, Datenströme bei einem Netzwerk- oder Rechenausfall erneut abzuspielen. Um die Kontonutzung (z. B. die Anzahl der Anrufe) zu erfassen, öffnen wir eine Datenbanktransaktion, setzen die Nutzung auf „verarbeitet“ und senden anschließend täglich die aggregierte Nutzung an Stripe. War das erfolgreich, committen wir die Transaktion. Geht etwas schief, setzen wir die Nutzung per Rollback auf „unverarbeitet“ zurück. Tritt ein Fehler nach dem Aufruf von Stripe, aber vor Abschluss der Transaktion auf, können wir die vom CAP-Theorem vorhergesagten Probleme lösen, indem wir die tägliche Anzahl der Anrufe für jedes Konto neu berechnen.
Wir überwachen Background-Jobs mit Papertrail und New Relic und erhalten Alerts, sobald etwas schiefgeht. Tatsächlich gibt es dieselbe Alerting-Tiefe für jeden Teil unseres Systems. Wir erhalten Alerts, wenn es Probleme mit Twilio, dem Backend, dem Webformular, unserem E-Mail-Server oder Stripe-Zahlungen gibt, damit wir sie sofort beheben können. Das ist Teil unseres Versprechens, unseren Kunden Support auf Enterprise-Niveau zu bieten.
CCPA Toll Free erweitert seinen Funktionsumfang nach demselben Sicherheits- und Monitoring-Modell, das wir uns von Anfang an vorgenommen haben. Auf unserer Roadmap stehen zahlreiche Partnerschaften, Integrationen und vieles mehr. Schreiben Sie uns gern mit Fragen und Funktionswünschen an support@optacy.com.