データレジデンシーは、データがどこに保存または処理されるかを表します。スイスのサーバーは、バックアップ、サポートシステム、外部統合、アクセス権を持つすべての人の場所を確立するものではありません。それらのコンポーネントは別々に評価しましょう。
マシンの場所とデータの流れを分ける
ホスティングプランの国ラベルは、狭い問いに答えます。記載された構成がどこにあるかです。それでもアプリケーションは情報を別の場所に送ることがあります。エラー報告、メール配信、決済処理、オフサイトバックアップ、管理者アクセスは、インフラ図に存在しなくてもサービスの一部です。スイスの宛先は、プロジェクト全体についての結論ではなく、データマップの1つのエントリとして扱いましょう。
まず、扱う情報を名付けることから始めましょう。公開ドキュメントサイト、顧客ポータル、プライベートアーカイブでは、必要な管理が異なります。公開コンテンツ、個人情報、認証秘密、内部運用記録を区別しましょう。各カテゴリがなぜ存在し、開示、改変、喪失された場合に何が起こるかを記録しましょう。これにより、法域の一般的な魅力に頼るのではなく、後の場所の判断が具体的になります。
小さな処理台帳を作る
代表的なユーザー操作を1つ、ブラウザからストレージまで追いましょう。どのシステムがリクエストを受け取り、何を書き込み、どの他のサービスに通知するかに注目しましょう。アカウント作成、パスワード回復、アップロード、サポートについても同じ演習を繰り返しましょう。ログ、メールキュー、診断エクスポートに二次コピーを発見することがよくあります。アーキテクチャがまだ変更可能なほど単純なうちに、これらを記録しましょう。
各コンポーネントについて、目的、宛先、アクセス責任者、保持の判断を含む台帳を使いましょう。始めるのに複雑なコンプライアンスツールは必要ありません。有用な特性は、誰かがすべての行を説明でき、新しい統合の後に更新できることです。バックアップの場所や管理者アクセスのない図は、レジデンシー判断には不完全です。
| コンポーネント | 確立すべきこと | 有用な証拠 |
|---|---|---|
| プライマリデータベース | ホスティング場所と許可されたアクセス | サービス仕様とアクセスポリシー |
| リカバリコピー | 宛先、保持、削除 | バックアップ構成と復元手順 |
| サポートエクスポート | 内容と受信者 | マスキング済みサンプルとサポートポリシー |
| 外部統合 | 送信される情報と処理条件 | 統合構成とプロバイダーのドキュメント |
自分に残る責任を理解する
スイス連邦データ保護・情報コミッショナーは、処理の外部委託がデータ保護に関する管理者の責任を除去するものではないと説明しています。そのガイダンスは、処理者の選定、指示の発行、個人データの取り扱いの確認をカバーしています。これは、ラックの場所だけでなくサービス関係も検査する理由です。あなたの組織に対する正確な義務は、適用される枠組みと関与する情報によって異なります。
情報が国境を越えて開示される可能性がある場合は、関連する公式ガイダンスを使い、法的評価が必要な判断については助言を得ましょう。国名が自動的にアプリケーションを準拠させるわけではないと宣言するのは避けましょう。処理者と再処理者が誰か、処理がどこで行われるか、どのような取り決めが適用されるかを問いましょう。回答はプロジェクトの運用ドキュメントとともに保管し、後で判断を見直せるようにしましょう。
場所の判断が必要な情報を減らす
定義された目的に資するものだけを収集しましょう。ニュースレターに必ずしも完全な郵送先住所は必要なく、トラブルシューティングレポートに顧客データベース全体が必要になることはほとんどありません。不要なフィールドを削除すると、露出が減り、保持が簡素化されます。診断ツールから秘密情報を排除し、集計測定が個々の記録を再現せずに運用上の問いに答えられるか検討しましょう。
暗号化は特定のコピーの保護に役立ちますが、誰が鍵を管理し、どこで復号が行われるかを特定しましょう。読み取り可能なデータを処理しなければならないアプリケーションは、誰も決してアクセスできないかのように扱うことはできません。同様に、仮名識別子は時間の経過とともに記録をリンクさせる可能性があります。暗号化バッジを処理マップの代わりに使うのではなく、実装された管理を正確に記述しましょう。
実践的なシナリオ：小規模な顧客ポータル
スイスのVPS上にホストされたポータル、独立したリカバリコピー、サードパーティのメールサービスを想像してください。通常運用中、顧客データベースはVPS上に留まりますが、パスワードリセットメッセージとサポート通知はそのマシンから出ていきます。チームは、それらのメッセージに含める最小限のフィールド、バックアップに使用する宛先、レコードのエクスポートを許可される担当者を記録すべきです。
妥当なレビューでは、エラーレポート内の完全なレコードをランダムなインシデント参照に置き換え、診断の保持期間を短縮し、バックアップへのアクセスを制限するかもしれません。これらの変更は、選択した国に関係なく有用です。この例は計画の演習であり、SwissOctetがこれらの統合を含む、または特定の居住地の取り決めを検証済みであるという主張ではありません。
公開コミットメントを行う前にマップを検証する
ユーザーに場所を約束する前に、登録簿を実際の構成および確認済みのサービス条件と比較してください。バックアップと削除の手順が期待どおりに機能するかをテストしてください。エクスポート、監視エージェント、スケジュールされたジョブを確認してください。これらは、初期購入時に誰も覚えていないコピーを生み出す可能性があるからです。新しい宛先を承認し、アーキテクチャの変更時に登録簿を更新する担当者を割り当ててください。
SwissOctetはカタログでスイスの構成を提示しています。実際の運用者の処理体制、サポートアクセス、保持ルールは、実際の注文の前に別途確認する必要があります。その境界を念頭に置いてインフラストラクチャを選択してください。明確なスイスの場所はあなたのアーキテクチャを支えることができ、完全で維持されたデータマップは、それについて行う主張を支えます。
実践チェックリスト。
- プロジェクトが扱う情報を分類します。
- プライマリストレージ、バックアップ、ログ、統合をマッピングします。
- 処理者、アクセス権者、保持の決定を特定します。
- 該当する越境に関する質問について公式ガイダンスを確認します。
- 居住地を約束する前に実際の構成を検証します。
重要な詳細。
スイスのサーバーは、すべてのコピーがスイスに留まることを意味しますか？+
いいえ。バックアップの宛先、エクスポート、サポートシステム、統合にはそれぞれ独自のデータ経路があり、個別に確認する必要があります。
暗号化は処理のマッピングの必要性をなくしますか？+
いいえ。データと鍵がどこに存在し、誰がそれを復号でき、どのような処理が行われるかを知る必要は依然としてあります。
このガイドはSwissOctetのデプロイを認定しますか？+
いいえ。これは計画手法を提供します。実際の処理条件と実装された管理策は、特定のサービスについて確認する必要があります。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- FDPIC：クラウドにおけるデータ処理 www.edoeb.admin.ch
- FDPIC：データ処理の外部委託 www.edoeb.admin.ch
- FDPIC：個人データの越境移転 www.edoeb.admin.ch
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。