このチェックリストには、サービスとしてのバックエンド (BaaS) と署名する前に確認すべき 10 の基準が詳しく記載されており、それぞれについて各サプライヤーに尋ねるべき正確な質問が含まれています。
最も忘れられがちな基準は、サーバーの場所とは別に、サプライヤーの国籍です。米国の親会社は、データがフランスやドイツのサーバーで実行されている場合でも、引き続きクラウド法の対象となります。 GDPR と EU 主権に関する 包括的なガイド では、この法的区別について詳しく説明しています。このチェックリストは、サプライヤー評価時にチェックすべき運用上のポイントに焦点を当てています。
必需品
- 「EU 地域」ボックスにチェックを入れると、リスクの一部のみがカバーされます。データをホストする企業の国籍は、クラウド法と同様に重要です。
- DPA (GDPR 第 28 条) は、企業の規模に関係なく、サプライヤーがお客様に代わってデータを処理するとすぐに必須となります。
- クライアント間の分離は実装の詳細ではありません。tenant_id を持つ共有テーブルは、プロジェクトごとの専用データベースと同じ保証を提供しません。
- 「ロードマップ」認証は取得された認証ではありません。マーケティング上の約束ではなく、署名された監査報告書が必要です。
- アクセス、消去、移植の権利はセルフサービスで行使できる必要があります。カスタム SQL スクリプトで応答するサプライヤーは、企業自身のコンプライアンスを遅らせることになります。
- セルフホスティングでは請負業者は不要になりますが、セキュリティと侵害通知に関する運用上の負担全体がチームに移されます。
データの場所とプロバイダーの国籍
データの保管場所と、データをホストしている企業の法的国籍という 2 つの個別の事実によって、法的リスクが決まります。 GDPR は最初の点を規定します。 2 番目については、米国の CLOUD 法が規定されています。
この文書は、米国連邦当局が、子会社を含む米国法に基づいて設立されたあらゆる企業に対してデータを要求する権限を与えています。これは、このデータが物理的にヨーロッパにあるサーバーでホストされている場合にも当てはまります。マーケティング サイトの「EU でホストされている」というバッジには、親会社の国籍については何も書かれていません。
Aurabase は、パリに拠点を置くフランス企業 Aurabase SAS です。その運用インフラストラクチャは、EU の主権により、ニュルンベルク、ファルケンシュタイン (ドイツ)、ヘルシンキ (フィンランド) にあるヘッツナー データ センターで稼働しています。法的本社とサーバーの場所という 2 つの異なる事実を、同じ注意において混同しないでください。
サプライヤーに尋ねるべき質問: サーバーがヨーロッパにある場合でも、親会社は EU 外に登録されていますか?
DPA: GDPR 第 28 条が要求するもの
GDPR では、データ管理者であるお客様と、サプライヤーである下請け業者との間で書面による契約を締結する必要があります。これは第 28 条です。この文書がなければ、サプライヤーの技術的な真剣度に関係なく、準拠していません。
有効な DPA は、処理の目的と期間、データとデータ主体のカテゴリ、および下請業者のリストを指定します。また、適用されるセキュリティ対策と、ユーザーの要求があった場合の支援義務についても詳しく説明します。最後に、契約終了時のデータの運命、つまり削除か復元かを決定します。
Aurabase は、欧州委員会によって採用された標準契約条項 (決定 2021/914) に基づいて構築された署名可能な DPA をスタジオから直接発行します。サービスとしてのバックエンドの DPA に特化した 記事 では、署名前に確認する内容を条項ごとに詳しく説明しています。
下請け業者のリストは公開され、通知されなければなりません
GDPR 第 28 条では、下請け業者に対し、ホスト、支払いゲートウェイ、トランザクション電子メール サービスなど、独自の下請け業者をリストすることも義務付けています。いかなる変更も、異議を申し立てる権利とともに、お客様に通知される必要があります。
このリストを書面で要求し、各重要な下請け業者、特にホストが EU 内に拠点を置いているかどうかを確認してください。そうでない場合、下請けチェーンは、元のサプライヤーを変更することで回避しようとしたクラウド法のリスクを再現します。
クライアント間の分離: 共有か専用か?
お客様のデータと同じサプライヤーの他の顧客のデータとの間の分離によって、バグが発生した場合の漏洩の範囲が決まります。保証が大きく異なる 3 つのアーキテクチャが存在します。
最も一般的なモデルである tenant_id列を持つ大規模な共有テーブルは、最も脆弱でもあります。 RLS ポリシーの作成が不十分である場合、またはフィルター句のないクエリにより、一度に複数のクライアントが公開される可能性があります。プロジェクトごとに独自の接続ロールを使用することで、この種のバグが排除されます。境界は、開発者が忘れる可能性のある WHERE 句ではなく、接続レベルで設定されます。
この点で、各 Aurabase プロジェクトは独自の Postgres データベースを受け取り、ゲートウェイ レベルで JWT から挿入された search_path によってスコープが定められた独自の接続ロールを持ちます。 2 つの組織間では、専用の Postgres クラスター、別個の Kubernetes 名前空間という物理的な分離が行われます。詳細については、セキュリティページをご覧ください。
技術的セキュリティ: 暗号化、監査、バグ報奨金
GDPR は、正確な基準を列挙することなく、「適切な技術的および組織的措置」（第 32 条）を課しています。実際には、検証すべき具体的な要素は 3 つあります。それは、転送中および保存中の暗号化、独立した監査プログラムの存在、および文書化された脆弱性報告チャネルです。
Aurabase は、Enterprise プランの BYOK オプション (AWS KMS または HashiCorp Vault 経由でキー管理) を使用して、交換を TLS 1.3 で暗号化し、保存データを AES-256 で暗号化します。 Huntr.dev/aurabase でホストされている公開バグ報奨金プログラムでは、見つかった欠陥の重大度に応じて 200 ユーロから 10,000 ユーロが支払われます。調整された開示ポリシーは 90 日間続きます。定義上、文書化された報告チャネルを持たないサプライヤーは、独立した監査を実施していません。
データ主体の権利: セルフサービスまたは手動スクリプト?
GDPR の第 15 条、第 17 条、および第 20 条は、エンド ユーザーにデータのアクセス、消去、およびポータビリティの権利を保証します。 BaaS に尋ねるべき質問: これらの権利はセルフサービスで行使できますか、それともリクエストごとにカスタマイズされた SQL スクリプトが必要ですか?
たとえ基盤となるインフラストラクチャが不透明であっても、30 日以内に対応する法的義務を負うのはデータ管理者であるあなたです。リクエストごとに手動スクリプトを必要とするプロバイダーでは、応答時間が遅くなります。 Aurabase では、エクスポートと削除は Studio → 設定 → プライバシーから、またはより複雑な場合には privacy@aurabase.cloud からアクセスできます。
違反通知: 法的期限と契約上の義務
GDPR では、データ管理者であるお客様に対し、違反を認識してから 72 時間以内に監督機関に違反を通知することを義務付けています (第 33 条)。この期間は、サプライヤーから通知されたときにのみ開始されます。
したがって、通知するというサプライヤーの契約上の約束は、法的期限そのものと同じくらい重要です。インシデントを通知するために遵守することを約束する契約上の最大期限と、この通知に含まれなければならない内容（違反の性質、カテゴリ、関連するデータのおおよその量）を尋ねます。この数字は、販売前に口頭で説明するだけでなく、DPA に白黒で記入する必要があります。
認定: 取得済みですか、それともロードマップですか?
マーケティング サイトで発表された認定は、取得された認定と同じではありません。多くの BaaS プロバイダーは、対応する第三者監査を開始せずに「コンプライアンス ロードマップ」 (SOC 2、ISO 27001) を伝えています。
この点に関しては、発表そのものよりも透明性の方が重要です。 Aurabase の セキュリティ ページでは、現在までサードパーティ認定が確約されていないことが明示されており、未獲得のバッジを表示するのではなく、専用のトラスト センターでそのロードマップが公開されています。サプライヤーからの認証が当然であると考える前に、問題の規格の名前だけでなく、署名済みの監査報告書を体系的に要求してください。
セルフホスティング: 完全なコンプライアンスには運用コストがかかります
独自の Postgres をセルフホスティングすると、下請け業者の問題はなくなりますが、GDPR 準拠が自動的に解決されるわけではありません。セキュリティ、暗号化されたバックアップ、パッチ適用、侵害への対応に対する責任は完全にお客様にあります。
Postgres セキュリティ専用の SRE を持たないチームの場合、署名された DPA を持つ EU Sovereign BaaS は、管轄権を犠牲にすることなく、この運用負担の一部を監査済みの第三者に移管します。セルフホスティングの と EU ソブリン BaaS の比較 は、小規模チームにおけるこの妥協を定量化します。
10の基準と尋ねるべき質問
要約版。サプライヤー評価会議や独自の監査グリッドの構築に役立ちます。
| 基準 | サプライヤーへの質問 |
|---|---|
| 所在地と国籍 | サーバーはどこにあり、プロバイダーの親会社はどこに登録されていますか? |
| DPA (GDPR 第 28 条) | 下請け契約は署名されていますか、それともプリセールスでのみ言及されていますか? |
| 協力会社一覧 | それは公開されており、変更された場合には通知され、最新のものですか? |
| データの分離 | tenant_id 列を持つ共有テーブル、またはクライアントごとの専用ベース? |
| 暗号化 | 転送中の TLS、保存中の AES、BYOK オプションは利用可能ですか? |
| 独立した監査 | アクティブなバグ報奨金または日付付きの外部侵入テスト、文書化された報告チャネルはありますか? |
| GDPR の権利 (アクセス、消去、ポータビリティ) | セルフサービスで実行できますか、それとも要求に応じて手動スクリプトを介してのみ実行できますか? |
| 違反通知 | DPAに白黒で書かれている最大契約期間はどれくらいですか? |
| 認証 | 署名された監査報告書とともに入手されますか、それともロードマップとしてのみ入手されますか? |
| コンプライアンスの責任者 | 監査済みの EU ソブリン BaaS ですか、それとも運用負担を内部で想定したセルフホスティングですか? |
FAQ: GDPR への準拠と BaaS の選択
次のステップ
これら 10 個の基準はいずれも、サービスとしてのバックエンドの GDPR 準拠を保証するために単独では十分ではありません。マーケティングバッジから推測するのではなく、それらの組み合わせによって点ごとに検証され、真剣なサプライヤー評価が構築されます。
開催地域とサプライヤーの国籍の間の法的な微妙な違いについては、GDPR および EU 主権ガイドをご覧ください。基準 4 および 5 に記載されている技術的なセキュリティ対策の詳細については、Aurabase Security ページが最新のリファレンスです。