Compliance

Wat is dataresidentie en waar worden mijn berichtgegevens opgeslagen?

Dataresidentie is de vraag in welke jurisdictie je data wordt opgeslagen en verwerkt.

De regio die je kiest, bepaalt waar Bird de data van je organisatie opslaat en verwerkt. Het bepaalt ook welke grensoverschrijdende privacyregels van toepassing zijn.

Waar bevinden mijn data zich?

In één regio, gekozen bij het aanmaken van de organisatie.

Elke Bird-organisatie krijgt bij aanmelding een regio toegewezen. us1 is de Verenigde Staten en eu1 is de Europese Unie, en de regiodocumentatie beschrijft wat die toewijzing omvat:

Every organization is assigned a region at signup. The region is detected from your location, can be changed before you confirm, and is immutable in v1. The workspace, API keys, messages, recipient data, and event logs remain in that region. They are never replicated across regions.

De kernzin is "never replicated". Een residentietoezegging die een kopie elders toestond voor redundantie of analytics zou er geen zijn. Hier is het datavlak werkelijk gescheiden per regio, en dat is ook waarom de keuze onwijzigbaar is: een organisatie verplaatsen tussen regio's is geen instelling, het is een migratie die de huidige API-versie niet biedt.

Hoe wordt het afgedwongen?

In de credential en in de routering, zodat een fout luid mislukt.

Er is geen enkel globaal endpoint voor het datavlak. Elke regio heeft een eigen host, en een API-sleutel vermeldt zijn regio in het prefix: een bk_eu1_-sleutel hoort bij eu1. De SDK's en de CLI lezen het prefix en kiezen automatisch de juiste host.

Wat er gebeurt wanneer een verzoek op de verkeerde plek terechtkomt, is het interessante deel:

A request that reaches the wrong region is rejected with 421 Misdirected Request instead of being forwarded. The error message names the correct host

Weigeren in plaats van doorsturen is de ontwerpbeslissing die residentie verifieerbaar maakt. Een platform dat een verkeerd gericht verzoek stilzwijgend proxyde, zou handig zijn, maar zou ook betekenen dat een verzoek met persoonsgegevens een grens had overschreden zonder dat iemand het merkte. Hier kan dat niet: het verzoek mislukt, en de foutmelding noemt de host die je moet gebruiken.

Elk antwoord bevat ook een X-Bird-Region-header met de regio die het heeft afgehandeld, zodat je kunt bevestigen waar een aanroep daadwerkelijk terechtkwam in plaats van op de configuratie te vertrouwen.

Wat is niet regiogebonden?

Authenticatie en accountbeheer, en de documentatie zegt dat expliciet in plaats van het impliciet te laten:

Only authentication and account administration (/v1/auth, /v1/admin) operate on globally replicated data, which is why they are served from the non-region host platform.bird.com.

Dit is de moeite waard om te weten in plaats van over te slaan. Inloggen en accountbeheer raken identiteitsgegevens die overal moeten werken, dus die twee onderdelen zijn bewust globaal, terwijl alles rond berichten en ontvangers dat niet is. Als je je eigen datastromen documenteert, is die scheiding de grens die je moet trekken.

Bepaalt residentie waar mijn berichten naartoe gaan?

Nee, en de twee door elkaar halen leidt in beide richtingen tot de verkeerde conclusie.

Residentie gaat over waar je data wordt opgeslagen en verwerkt. Bezorging gaat over waar je ontvangers zich bevinden, en dat wordt bepaald door dekking, lokale regels en sancties. Een eu1-organisatie kan berichten sturen naar ontvangers overal waar Bird bezorgt, en een us1-organisatie kan berichten sturen naar Europese ontvangers. Ondersteunde landen en beperkingen behandelt de bezorgkant.

Wat residentie wél bepaalt, is waar het record van dat bericht daarna leeft: het bericht zelf, de ontvangersgegevens, het eventlog. Dat record is meestal waar een gegevensbeschermingsvraag werkelijk over gaat.

Wat moet je vooraf beslissen?

De regio, want dat is het enige onderdeel dat je niet kunt herzien.

Omdat de toewijzing onwijzigbaar is na bevestiging, hoort regioselectie thuis in het proces waarmee je je productieorganisatie aanmaakt, samen met alles wat eenmalig wordt bepaald. Een testorganisatie in de verkeerde regio is een kleine ergernis; een productieorganisatie is een migratie.

Twee gerelateerde zaken om tegelijk te regelen, omdat ze in de meeste reviews samengaan: de verwerkersovereenkomst die de relatie regelt, en waar de aanbieder zijn sub-verwerkerlijst publiceert, want een sub-verwerker in een andere jurisdictie is een doorgifte-vraag die residentie alleen niet beantwoordt.

Kort gezegd

  1. Residentie is een eigenschap van de organisatie, niet van een verzoek.

    De regio wordt toegewezen bij aanmelding, kan worden gewijzigd vóór bevestiging en is daarna onwijzigbaar in de huidige API-versie.

  2. Er wordt niets gerepliceerd tussen regio's.

    Werkruimtes, sleutels, berichten, ontvangersgegevens en eventlogs blijven in één regio, en dat is wat een residentietoezegging betekenisvol maakt.

  3. De API-sleutel bevat zijn regio, en een verkeerde host wordt geweigerd.

    Een verzoek dat de verkeerde regio bereikt, krijgt 421 Misdirected Request terug met de juiste host, in plaats van stilzwijgend te worden doorgestuurd.

  4. Twee onderdelen zijn bewust globaal.

    Authenticatie en accountbeheer draaien op gerepliceerde data, en daarom antwoorden ze op een regio-onafhankelijke host.

Breng het in de praktijk.

Ga verder met de documentatie, gidsen en voorbeelden voor dit onderwerp. De bronnen zijn in het Engels.

Ontvang een implementatieoverzicht

Bouw op hetzelfde netwerk.

Een test-API-key is direct beschikbaar. Productietoegang wordt ontgrendeld zodra u een betaalmethode toevoegt en een afzender verifieert.

Jouw volgende idee.
Klaar om te verbinden.