この記事では、Azure Confidential Ledger についてよく寄せられる質問について回答します。
全般
Azure Confidential Ledger サービスが自分の組織で役立つかどうか、どうすれば判断できますか?
Azure confidential ledger が最も役に立つのは、記録や保存処理を実行しているシステムに対して攻撃者が意欲的に侵入を試みる価値のある記録が存在する組織です。こうした攻撃には、以前の記録を捏造、改変、削除しようとする悪意のある従業員、すなわち "内部犯" によるものも含まれます。
Azure Confidential Ledger のセキュリティを大幅に強化する理由
その名前が示すように、台帳は Azure Confidential Computing プラットフォームおよび Confidential Consortium Framework を利用して改ざんが防止され、高い整合性のソリューションを提供します。 1 つの台帳は 3 つ以上のまったく同じインスタンスにまたがって存在し、それらの各インスタンスは、ハードウェアにより実装され、信頼性を完全に保証された、専用のエンクレーブで実行されます。 台帳の整合性はコンセンサス ベースのブロックチェーンによって保たれます。
Azure Confidential Ledger に書き込んだときは、書き込みのレシートを保存する必要がありますか?
その必要は必ずしもありません。 現在提供されているソリューションの中には、将来行うログの有効性確認のために、書き込みのレシートの保管をユーザーに求めるものがあります。 安全な保存設備でレシートを管理する必要がある場合、その分だけ負担が増えます。 台帳では、マークル木を利用した手法によりこの問題を解消します。この手法では、署名済みの信頼の基点 (root-of-trust) へのツリー内の完全な経路が、書き込みのレシートに記載されます。 ユーザーは台帳のデータを一切保存、管理せずに、トランザクションの有効性を確認できます。
台帳の信頼性の確認方法
クライアントの通信先である台帳サーバー ノードに信頼性があることを確認できます。 詳しくは、Confidential Ledger Nodes の認証に関する記事をご覧ください。
クライアントと ACL の間の通信は、Azure がクライアントと ACL の間の TLS を制御するため、Azure 管理者によって侵害される可能性がありますか?
クライアントとエンクレーブ内で実行されている特定のノードの間には TLS 接続が確立されます。 エンクレーブ内で接続が終了すると、Intel SGX 専用ハードウェアによって提供されるセキュリティにより、Azure 管理者も他のユーザーもエンクレーブ データにアクセスできません。
ACL では、受信/トランザクション ID 以外の属性に対するクエリが提供されますか?
ACL では、受信/トランザクション ID を使用したクエリに加えて履歴クエリ機能が提供されるため、コレクション ID (サブ台帳 ID とも呼ばれます) パラメーターを使用して、特定のキーの Genesis (または範囲内) からデータを読み取ることができます。 Microsoft では、製品ロードマップのために情報を収集しており、どのような属性がクエリに役立つかを理解しようとしています。
ディスク上のデータは個別に暗号化されますか? その場合、キーはどこに格納されますか?
台帳にデータを格納するときは、パブリック オプションまたはプライベート オプションを選択できます。 パブリック オプションは暗号化されません。プレーンテキストであり、開封が明示されて監査可能な台帳の使用を必要とする特定のユース ケースに適しています。 プライベート オプションは逆に暗号化されます。 データは、3 つのレベルの暗号化 (台帳シークレット、台帳シークレット ラッピング キー、回復キー共有) を使用して暗号化されます。詳細についてはこちらをご覧ください。
[ユーザー管理]
台帳でユーザーを管理する方法
Microsoft は、作成した台帳のユーザーの管理をサポートできますか?
不正解です。 台帳が作成されると、Microsoft はユーザー管理にアクセスできなくなります。
管理者なしで台帳を作成しました。 引き続きユーザーを追加できますか?
管理者なしで台帳を作成すると、AAD/証明書は管理者権限を取得します。 その ID を使用して、台帳を管理できます。