Security Requirements for UID2 Sharing
すべての UID2 参加者は、UID2 エコシステムの安全を確保する中核的な責任を負っています。以下は、すべての UID2 参加者のための標準的なセキュリティ慣行です。認証された sharing participants 間で raw UID2 を共有する場合、これらは必須であり、すべて一貫して満たす必要があります。
セキュリティ要件は以下の通りです:
Authentication
認証には、さまざまな方法を使用して組織の身元を確認し、その組織が当事者であることを確認することが含まれます。オンラインではメールアドレスによる認証が一般的であり、対面では政府発行の身分証明書を使用することが多いです。
ユーザ名とパスワード、API Key、または認証チェックの目的に便利なそ の他のクレデンシャルを発行することで、これらのクレデンシャルの発行者は、その後の認証チェックのために組織を識別することができます。
多要素認証(MFA)として知られる多層的なアプローチは、複数の形式の検証を要求することでセキュリティを大幅に強化し、不正アクセスをより困難にします。MFAには、2要素認証(2FA)が含まれる場合があり、ユーザーは、モバイルデバイスに送信されるコードや、送金時に認証アプリによって生成されるコードなど、2つ目の形式の識別情報を提供する必要があります。
オンライン認証プロセスを強化するために、セキュリティ質問、メール認証リンク、SMS認証コードも一般的に使用されています。
Authorization
オンライン認証は、ユーザが認証された後に、どのリソースにアクセスし、どのようなアクションを実行できるかを決定します。このプロセスには以下が含まれます:
- ユーザーの役割またはアカウントの詳細に基づいて、権限と制限を設定します。
- ユーザーが自分の権限に関連する情報や機能にのみアクセスできるようにします。さらに、共有参加者は、raw UID2 または UID2 Token の送受信を許可されるために、UID2 と契約を締結し、UID2 参加ポリシーに署名している必要があります。ただし、UID2 Sharing Getting Started ドキュメントの Exceptions で指定されている2つのケースは例外です。
認証された受信者が許可された UID2 共有参加者であることを確認するには、UID2 の連絡先に尋ねるという方法があります。
Accounting
Accounting とは、取引の記録があり、必要に応じてその活動を見直したり監査したりできることを意味します。データの転送が２つの sharing participants で行われる際に、包括的かつ追跡可能な取引ログを確保するためには、各取引の詳細や文脈を捉える特定の項目を記録することが重要です。
次の表は、トランザクションログに含めることを検討すべき主要フィールドです。
| Data | Explanation |
|---|---|
| Timestamp | データ転送が行われた正確な日時。 |
| Data recipient ID | データを受け取る参加者の識別子。 |
| Transaction ID | 各トランザクションの一意な識別子。このIDは、ログ内の特定のトランザクションを追跡・参照するために使用できます。 |
| Data volume | 転送されたデータ量。通常、行数(異なるUID2の数)またはファイルサイズ(メガバイトまたはギガバイトなど)で測定されます。 |
| Transfer method | HTTPS、SFTP、S3 署名付き URL など、データ転送 に使用される方法またはプロトコル。 |
| Status of transfer | 転送の結果(成功、失敗、部分的など)。 |
| Error codes/logs | 転送に失敗したり、問題が発生した場合、エラーコードや簡単なログを記録しておくと、問題の診断と解決に役立ちます。 |
| Authorization details | 関連する許可または承認を含め、転送を承認した者に関する情報。 |
| Checksum or hash value | チェックサムまたはハッシュ値で、転送後のデータの完全性を検証します。これは、転送中にデータが改ざんされていないことを確認するのに役立ちます。 |
ネットワークログ、アプリケーションログ、クラウド監査ログなどの追加ログも、送信元と送信先のIPアドレスやクラウドプラットフォームのアカウント ID などの追加情報を提供することで役立つ。
Secure Transport
セキュアトランスポートは、送信者から受信者、エンドからエンドへのデータの移行中に、傍受者が raw UID2 にアクセスしたり、変更したりできないように保護するのに役立ちます。セキュアトランスポートの例:
- HTTPS or TLS
- Message-based encryption
Example Workflow
以下は、オンラインAAA(Authentication, Authorization, and Accounting)フローのワークフロー例です。
-
Pre-Authentication:
- 共有参加者は、意図した受信者(共有受信者)の身元を確認し、ユーザー名やパスワード、API Key などの認証情報のセットを受信者に発行します。
-
Authentication:
- 目的の受信者は、ユーザー名やパスワードなどの認証情報を提供することから始めます。
- このプロセスをさらに安全にするために、二要素認証が必要になるかもしれません。ユーザーは SMS、メール、または認証アプリを通じてコードを受け取り、次に進むにはコードを入力しなければなりません。
-
Pre-Authorization:
-
認証が完了すると、システムはユーザーの役割と権限をチェックし、要求されたリソースやサービスにアクセスするための初期許可があるかどうかを判断します。
このステップでは、データベースまたはディレクトリサービスをチェックして、認証された ID に基づくユーザーのアクセス権を確認します。これは、"この人物は、私から UID2 データを受け取る権限があるか？"という質問に答えるものです。
-
-
UID2 Participant Authorization:
-
指定された検証者は、UID2 参加ポリシーを含む有効で署名された契約が、受信者(またはその組織)と UID2 の間に存在することを検証します。
このステップは、UID2 の担当者に尋ねるのも一つの方法です。
-
-
Post-Verification Authorization:
- 検証者が契約の存在と有効性を確認すると、共有参加者は共有されるデータへのアクセスを許可する権限を持ちます。
- 送信者のシステムは、受信者のアクセスステータスを更新してこの許可を反映させ、受信者が要求されたリソースにアクセスできるようにします。
-
Accounting:
-
セッションの間、システムは将来の監査と監視のために、すべてのトランザクションとアクセスの詳細を記録します。これには、最初の認証、許可の詳細、および人による介入のインスタンスのログが含まれます。
システムはまた、アクセス時間、持続時間、リソースの使用量などの使用指標を記録し、契約条件の遵守を確認し、該当する場合は課金目的に使用します。
-
-
Feedback and Notification:
-
承認プロセスが完了すると、受信者はアクセス状況に関する通知を受け取ります。アクセスが許可された場合は、その旨が通知され、次に進むことができます。アクセスが拒否された場合は、説明や次のアクションの手順を受け取ります。たとえば、共有の受信者は、ダウンロードの準備ができたというメール通知を受け取るかもしれません。
-
検証者は、自分の介入が正常に記録され、対処されたことを確認する通知を受け取ることもあります。
-
raw UID2 または UID2 Token を共有する前に、共有相手の参加者が UID2 参加方針に署名していることを確認する必要があります。共有する相手が署名しているかどうかわからない場合は、UID2 担当者に尋ねるのも一つの方法です。