Wybrany region decyduje o tym, gdzie Bird przechowuje i przetwarza dane Twojej organizacji. Wpływa też na to, jakie transgraniczne zasady ochrony prywatności mają zastosowanie.
Gdzie znajdują się moje dane?
W jednym regionie, wybranym przy tworzeniu organizacji.
Każdej organizacji Bird przypisywany jest region przy rejestracji. us1 to Stany Zjednoczone, a eu1 to Unia Europejska. Dokumentacja regionów opisuje, co obejmuje to przypisanie:
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.
Kluczowe sformułowanie to "never replicated". Zobowiązanie o rezydencji, które dopuszczałoby kopię danych w innym miejscu na potrzeby redundancji lub analityki, nie byłoby prawdziwym zobowiązaniem. Tutaj warstwa danych jest rzeczywiście odseparowana per region, co jest też powodem niezmienności wyboru: przeniesienie organizacji między regionami to nie zmiana ustawienia, lecz migracja, której bieżąca wersja API nie oferuje.
Jak jest to egzekwowane?
Poprzez poświadczenie i routing, tak by błąd był wyraźnie widoczny.
Nie ma jednego globalnego endpointu dla warstwy danych. Każdy region ma własny host, a klucz API zawiera w prefiksie informację o regionie: klucz bk_eu1_ należy do eu1. SDK-i i CLI odczytują prefiks i wybierają host bez dodatkowej konfiguracji.
To, co dzieje się, gdy żądanie trafia w niewłaściwe miejsce, jest tu najistotniejsze:
A request that reaches the wrong region is rejected with
421 Misdirected Requestinstead of being forwarded. The error message names the correct host
Odrzucanie zamiast przekierowywania to decyzja projektowa, która czyni rezydencję weryfikowalną. Platforma, która po cichu przekierowywałaby błędnie skierowane żądanie, byłaby wygodna, ale oznaczałaby też, że żądanie zawierające dane osobowe przekroczyło granicę, zanim ktokolwiek to zauważył. Tutaj jest to niemożliwe: żądanie kończy się błędem, a komunikat o błędzie wskazuje właściwy host.
Każda odpowiedź zawiera też nagłówek X-Bird-Region z nazwą regionu, który ją obsłużył, więc możesz potwierdzić, gdzie wywołanie faktycznie trafiło, zamiast polegać na konfiguracji.
Co nie jest ograniczone do regionu?
Uwierzytelnianie i administracja kontem, a dokumentacja mówi o tym wprost, zamiast pozostawiać to domyślne:
Only authentication and account administration (
/v1/auth,/v1/admin) operate on globally replicated data, which is why they are served from the non-region hostplatform.bird.com.
Warto to wiedzieć, a nie pomijać. Logowanie i zarządzanie kontem dotyczą danych tożsamości, które muszą być dostępne z dowolnego miejsca, dlatego te dwie warstwy są z założenia globalne, a wszystko związane z wiadomościami i odbiorcami już nie. Jeśli dokumentujesz własne przepływy danych, ta granica jest właściwą linią podziału.
Czy rezydencja decyduje o tym, dokąd trafiają moje wiadomości?
Nie, a łączenie tych dwóch pojęć prowadzi do błędnych wniosków w obu kierunkach.
Rezydencja dotyczy tego, gdzie przechowywane i przetwarzane są Twoje dane. Dostarczanie dotyczy tego, gdzie są Twoi odbiorcy, co regulują zasięg, lokalne przepisy i sankcje. Organizacja eu1 może wysyłać wiadomości do odbiorców wszędzie tam, gdzie dostarcza Bird, a organizacja us1 może wysyłać do odbiorców europejskich. Obsługiwane kraje i ograniczenia opisują stronę dostarczania.
To, o czym rezydencja decyduje, to miejsce przechowywania zapisu tej wiadomości: sama wiadomość, dane odbiorcy, log zdarzeń. Zwykle to właśnie ten zapis jest faktycznym przedmiotem pytań o ochronę danych.
Co powinienem ustalić z góry?
Region, bo to jedyna część, do której nie możesz wrócić.
Ponieważ przypisanie jest niezmienne po potwierdzeniu, wybór regionu powinien być częścią procesu tworzenia organizacji produkcyjnej, obok wszystkiego innego, co ustala się raz. Testowa organizacja utworzona w niewłaściwym regionie to drobna niedogodność; produkcyjna to migracja.
Dwie powiązane kwestie warto ustalić w tym samym czasie, bo w większości przeglądów idą w parze: umowa o przetwarzanie danych, która reguluje relację, oraz miejsce, w którym dostawca publikuje listę podwykonawców przetwarzania, ponieważ podwykonawca w innej jurysdykcji to kwestia transferu danych, na którą sama rezydencja nie odpowiada.
W skrócie
Rezydencja jest właściwością organizacji, nie żądania.
Region jest przypisywany przy rejestracji, można go zmienić przed potwierdzeniem, a potem jest niezmienny w bieżącej wersji API.
Nic nie jest replikowane między regionami.
Obszary robocze, klucze, wiadomości, dane odbiorców i logi zdarzeń pozostają w jednym regionie, i to właśnie nadaje zobowiązaniu o rezydencji rzeczywiste znaczenie.
Klucz API zawiera informację o swoim regionie, a żądanie do niewłaściwego hosta jest odrzucane.
Żądanie skierowane do niewłaściwego regionu otrzymuje
421 Misdirected Requestwskazujący właściwy host, zamiast być po cichu przekierowane.Dwie warstwy są celowo globalne.
Uwierzytelnianie i administracja kontem działają na replikowanych danych, dlatego odpowiadają na hoście niezależnym od regionu.