GDPR 中小企業向けのセルフホスティングと EU ソブリン BaaS

ヨーロッパのデータセンターのセルフホスト型バックエンドと EU ソブリン BaaS はどちらも、EU の所在地、ヨーロッパの事業会社、利用可能な DPA (プロバイダー側)、または最新の内部レジストリ (セルフホスト側) など、同じ GDPR ボックスにチェックを入れることができます。 GDPR には、この 2 つの間でアーキテクチャ上の優先順位はありません。本当に変わるのは、セキュリティ パッチ、テスト済みのバックアップ、オンコール、継続的な監視など、日々の運用負荷を誰が吸収するかということです。

完全な法的枠組みである GDPR およびクラウド法については、GDPR 準拠および EU 主権のバックエンド ガイドで詳しく説明されています。このガイドでは、必ずしも専用の SRE を持たないチームの各オプションの実際の運用コストについては詳しく説明しません。この記事の角度はこんな感じです。

Postgres バックエンドを自己ホストすると、サーバーだけでなく、運用上の全責任がチームに移されます。具体的には、Postgres セキュリティ パッチが公開されたらすぐに適用する、バックアップ復元をスケジュールするだけでなく定期的にテストする、という 4 つのタスクが繰り返し登場します。また、可用性を継続的に監視するか、より長い応答時間を受け入れ、文書化されたスケジュールに従ってシークレットとアクセス キーをローテーションする必要もあります。

セルフホスティングであっても、これらのタスクがなくなることはありません。また、お客様は、ホスト (Hetzner、OVH、Scaleway など) に対して、独自の技術下請け業者のままになります。 DPA が存在する必要があり、処理登録簿 (GDPR 第 30 条) にこのチェーンを文書化する必要があります。専任のインフラストラクチャ チームを持たない中小企業は、この最後の点を過小評価していることがよくあります。

EU の主権 BaaS は、日付が記載された検証可能な DPA (GDPR 第 28 条) に基づいて、パッチ適用、バックアップ インフラストラクチャ、および可用性の監視をプロバイダーに転送します。変更されるのは、法的責任ではなく、前の点で説明した運用上の負担です。

選択したサプライヤーに関係なく、データ管理者は引き続きお客様になります (GDPR 第 24 条)。処理の法的根拠、収集されるデータの最小化、72 時間以内の監督当局への違反通知 (GDPR 第 33 条): これらの決定はお客様の責任となります。 EU Sovereign BaaS は、DPO または顧客への準拠証明の作成に必要な時間を短縮します。それを持つ義務がなくなるわけではありません。

多くのチームは 2 つのオプションのみを比較し、3 番目のオプションは実際の決定を考慮します。それは、ハイパースケーラーか、米国の法律に基づいてヨーロッパ地域で構成された BaaS です。 eu-west-1リージョンまたは同等のサービスを使用した AWS Amplify は、レイテンシーを短縮し、データ常駐要件を満たします。しかし、これによって運営会社の国籍が変わるわけではありません。

米国法に基づいて設立された企業は、顧客が選択した地域に関係なく、引き続きクラウド法の対象となります。この点は、ガイド GDPR 準拠および EU ソブリン バックエンド と、専用記事 で CLOUD 法が BaaS の選択を変える理由で詳しく説明されています。このオプションが短期的には最も簡単に見える場合でも、中小企業の仲裁では重要です。

ここでは、現在中小企業が実際に利用できる 3 つのオプションを、チェックされた地域ボックスだけでなく、アーキテクチャの決定において最も重要な基準に基づいて比較しています。

セルフホスティングの実際のコストは、サーバーの請求書からは読み取ることができません。この情報は、エンジニアが製品に費やした時間や、インシデントが発生した場合の直接の法的リスクにさらされる可能性があります。

セルフホスト型 SME は、データ管理者であると同時に、独自の技術下請け業者になります。 Postgres パッチの適用漏れやテストされていないバックアップは、文書の徹底に反対する DPA の契約チェーンがなければ、データ管理者自身に直接原因があることになります (GDPR 第 83 条)。 EU の主権 BaaS プロバイダーでも、同様の障害が依然として現実的な危険にさらされています。しかし、それは再構築される内部履歴ではなく、DPO または監査人が数分で確認できる日付の付いた契約の一部です。

セルフホスティングは、すでに SRE/運用チームがあり、オンコールで機能している ETI または大規模なアカウントに引き続き関連します。これは、主権が外部の下請けの連鎖を容認しない分野、つまり公共部門、防衛、特定の医療施設にも当てはまります。物理サーバーの直接制御は、運用速度よりも優先されます。

すでに社内の Kubernetes または Postgres インフラストラクチャに投資しており、それを維持するスキルを備えている企業は、ゼロから始める中小企業よりもこの選択を容易に償却できます。

EU Sovereign BaaS は、顧客または DPO に対して迅速にコンプライアンスを証明する必要がある、専任のインフラストラクチャ チームを持たない中小企業にとって正しい選択です。したがって、彼女は Postgres のパッチ適用ではなく、エンジニアリングの時間を製品に費やすことを好みます。これは、スタックの全体的な制御よりもリリースの速度を優先するチームにとっても適切な選択です。

Aurabase は、この選択を一方向に固定しません。このプラットフォームは、EU の主権管理型 BaaS に存在し、生産インフラストラクチャはドイツ (ニュルンベルク、ファルケンシュタイン) と Hetzner 経由でフィンランド (ヘルシンキ) で検証され、フランスの法律に基づいて設立された会社である Aurabase SAS によって運営されています。これはセルフホスティングにも存在します。リポジトリは、 ./start.sh経由で起動されるローカル Kubernetes クラスター (k3d) と、Kubernetes の完全な Helm チャートをすべて MIT ライセンスの下で提供します。

同じ PostgreSQL 16 エンジン、同じ RLS ポリシー、および同じ SDK が両側に適用されます。あるモデルから別のモデルに移行する場合、スキーマを書き直す必要はありません。このセルフホストモードと他のモノバイナリ Rust ネイティブ バックエンド (sh0.dev、TrailBase) の比較については、記事 Sovereign self-hosting: Aurabase vs Rust-native BaaS で、このアーキテクチャの観点から詳しく説明しています。これは引き続き GDPR 決定に焦点を当てています。

GDPR ガイドのサプライヤー検証チェックリストに加えて、選択する前に自問すべき 4 つの運用上の質問。

For the complete vendor verification checklist, including legal issues, see our GDPR compliance checklist for a BaaS. For the associated technical security posture, see Aurabase Security page.