セキュリティモデル ################## AutoPrivacy DataCleanRoomのセキュリティモデルの概要を説明します。 詳細なセキュリティ検証の仕組みについては、:doc:`../security/index` を参照してください。 概要 *********************** AutoPrivacy DataCleanRoomは、「検証可能性」を重視して設計されています。 ユーザーのデータの機密性は、TEE（Trusted Execution Environment）という特殊なハードウェア技術によって保護されます。 システムのセキュリティは検証可能であり、ユーザーは必要に応じて全てを検証できます。 信頼モデル *********************** 何を信頼するか ============== AutoPrivacy DataCleanRoomを使用する際、ユーザーが信頼する必要があるのは以下のみです： 1. **TEEチップベンダー** （Intel、AMDなど） - TEEハードウェアの実装 - Remote Attestation（遠隔認証）の仕組み 2. **MAA（Microsoft Azure Attestation）の運営元** （Microsoft） - Quoteの検証サービス - 検証結果の正確性 3. **ユーザー自身のローカル環境** - ユーザーのコンピューター - APC CLIツール 検証可能な範囲 ============== 以下の要素は検証可能であり、ユーザーが悪意の有無を確認できます： - **TEE環境**: Remote Attestationによる検証 - **実行関数**: Work-ID検証による確認 - **サーバーの実行状態**: Quote生成と検証 以下の要素は、たとえ悪意を持っていたとしてもユーザーのデータの機密性に影響しません： - Controller（計算実行サーバーのTEE外コンポーネント） - 計算実行サーバーの管理者 - ネットワーク経路 - クラウドプロバイダー セキュリティの仕組み *********************** 1. データの暗号化 ================== **クライアント環境での暗号化** - データはユーザーのローカル環境で暗号化されます - 暗号化に使用する共有秘密鍵は、クライアントとTEE内で生成されます **TEE内での復号** - 暗号化されたデータはTEE内でのみ復号されます - TEEの外からは、誰もデータにアクセスできません - サーバー管理者・クラウドサービスプロバイダーであっても、データを見ることはできません 2. Remote Attestation（遠隔認証） ================================= **サーバーの検証** 計算を実行する前に、サーバーの実行環境についてAPC CLIを用いて以下を検証します： - サーバーのTEE環境が正常に動作していること - 実行される関数が改ざんされていないこと **検証の仕組み** .. mermaid:: sequenceDiagram participant Client as クライアント
(APC CLI) participant TEE as TEE環境 Client->>TEE: サーバーの実行環境を検証 TEE-->>Client: 検証情報（証明書） Client->>Client: 証明書を検査 alt 検証成功 Client->>TEE: 信頼できると判断 Client->>TEE: 暗号化鍵を安全に交換 else 検証失敗 Client->>Client: 処理を中止 end 3. 安全な鍵交換 ================ サーバーの検証が完了すると、暗号化に使用する鍵を安全に交換します： - TEE内で生成された公開鍵を取得 - ユーザーのローカル環境で生成した鍵と組み合わせて共有秘密鍵を作成 - この共有秘密鍵は、クライアントとTEE内のプログラムのみが知っています 4. アクセス制御 ================ 管理者（Acompany）が、各TEEサーバーにリクエストを送信出来るユーザーを管理します。 ユーザーは許可されたTEEサーバーにのみ各種リクエストを送信することが出来ます。 データの保護範囲 *********************** 保護されるデータ ================ 以下のデータは安全に保護されます： - **入力データ**: ユーザーがアップロードするデータ - **中間データ**: 計算中の一時的なデータ - **出力データ**: 計算結果 - **暗号化鍵**: データの暗号化/復号に使用される鍵 これらは常に暗号化されているか、TEE内でのみ平文として扱われます。 保護されないデータ ================== 以下のデータは暗号化されません： - **実行関数**: アップロードした関数ファイルの内容全体（サーバー管理者が閲覧可能） - **ファイルメタデータ**: ファイル名やファイルサイズなどのメタデータ - **実行時刻**: ログ情報などの実行履歴 実行関数の内容やファイル名には、機密情報を含めないでください。 よくある質問 *********************** Q: サーバー管理者はユーザーのデータを見ることができますか？ ============================================================ A: いいえ、できません。データはTEE内でのみ復号されるため、サーバー管理者を含む誰もユーザーのデータを見ることはできません。 Q: クラウドプロバイダー（Azure等）は信頼する必要がありますか？ ============================================================= A: いいえ、必要ありません。TEE技術により、クラウドプロバイダーであってもTEE内のデータにアクセスすることはできません。 Q: ネットワーク経路で盗聴されても大丈夫ですか？ =============================================== A: はい、大丈夫です。データは送信前に暗号化されているため、ネットワーク経路で盗聴されても内容を読むことはできません。 Q: Acompanyは信頼する必要がありますか？ ====================================== A: いいえ、信頼する必要はありません。システムは「検証可能性」を重視して設計されています。TEE環境やサーバーの実行状態はRemote Attestationにより検証可能であり、ユーザーは必要に応じて全てを検証できます。 Q: TEEチップベンダーは信頼する必要がありますか？ =============================================== A: はい、TEEハードウェア（Intel SGXなど）の実装は信頼する必要があります。これは現在の技術における根本的な信頼の基盤です。 Q: アップロードした実行関数ファイルはTEEで暗号化管理されていますか？ =============================================== A: いいえ、TEE外で通常のアクセス制御ポリシーに従って保護されています。 まとめ *********************** AutoPrivacy DataCleanRoomのセキュリティモデルは、以下の原則に基づいています： 1. **最小限の信頼**: TEEハードウェアを基盤とした信頼モデル 2. **暗号化第一**: データは常に暗号化された状態で保存・転送 3. **検証可能性**: サーバーの実行環境やセキュリティ状態を検証可能 4. **透明性**: ユーザーが望めば全てを検証できる設計 この設計により、ユーザーはデータの完全な制御を保ちながら、安全にデータ分析を実行できます。 さらに詳しい技術情報については、:doc:`../security/index` を参照してください。