AI901-Concept#23-2
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある総合病院が、患者カルテの要約を生成する AI システムを Azure OpenAI Service と Azure AI Foundry で構築します。カルテには PHI (Protected Health Information) が含まれるため、HIPAA 相当のプライバシー要件を満たし、データの不要な外部流出を最小化する設計が必要です。
解決策
開発と運用を迅速化するため、Foundry プロジェクトの RBAC ロールを全関係者に対して Owner として一括付与し、誰でもすべてのリソースを変更・参照できる状態にします。
この解決策は目的を満たしますか?
解説
【判定: いいえ】の理由
全員 Owner は最小特権原則 (least privilege) の根本的違反です。医療データの取り扱いでは、データ サイエンティストは Reader / Data Scientist ロール、運用担当は Contributor、管理者のみ Owner といった段階的な権限分離が必須です。全員 Owner では監査時に「誰が PHI へアクセスしたか」の追跡が困難で、内部不正リスクや誤操作リスクも極大化します。HIPAA / GDPR / 個人情報保護法のいずれの観点でも不適切な構成で、規制当局の監査でも指摘対象となります。
【「はい」が違う理由】
開発速度を理由に最小特権を放棄するのは Privacy and security 原則と完全に矛盾する設計で、規制環境では監査不適合となります。一度の漏洩でも重大な事業リスクを招くため、「目的を満たす」とは判定できません。
全員 Owner は最小特権原則 (least privilege) の根本的違反です。医療データの取り扱いでは、データ サイエンティストは Reader / Data Scientist ロール、運用担当は Contributor、管理者のみ Owner といった段階的な権限分離が必須です。全員 Owner では監査時に「誰が PHI へアクセスしたか」の追跡が困難で、内部不正リスクや誤操作リスクも極大化します。HIPAA / GDPR / 個人情報保護法のいずれの観点でも不適切な構成で、規制当局の監査でも指摘対象となります。
【「はい」が違う理由】
開発速度を理由に最小特権を放棄するのは Privacy and security 原則と完全に矛盾する設計で、規制環境では監査不適合となります。一度の漏洩でも重大な事業リスクを招くため、「目的を満たす」とは判定できません。
コメント