生成AI時代に理解しておきたい認証認可

Transcript

1. 生成AI時代に理解しておきたい認証認可 NRIネットコム TECH AND DESIGN STUDY#83 2025年11月25日 NRIネットコム株式会社 デジタルソリューション事業本部 クラウド事業推進部 大林 優斗
2. 1 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 登壇者：大林 優斗 ◼ 受賞歴 ⚫ 2025 Japan AWS Top Engineer (Services) ⚫ 2024 Japan AWS Jr. Champion ◼ AWS認定資格 ◼ 書籍執筆 自己紹介 ◼ ブログ執筆 ◼ NRI Netcom BLOG：https://tech.nri- net.com/archive/author/y-obayashi ◼ 登壇活動 ⚫ NRIネットコム主催の外部向け勉強会(TECH & DESIGN STUDY) ⚫ JAWS-UG朝会 ⚫ JAWS Days 2025 ⚫ 他社で開催される勉強会 ⚫ 登壇資料：https://speakerdeck.com/yuobayashi
3. 2 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します なぜAIを使う上で認証認可が重要になるのか
4. 3 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します 生成AIの普及とクラウド環境でのデータ利用が増加 なぜAIを使う上で認証認可が重要になるのか ◼ AIを使うほど「データ」が中心資産になる 生成AI・大規模言語モデルは、大量のデータを扱う前提で動作する AI利用が広がるにつれて、以下が新たな資産として扱われるようになった ⚫ 学習データ（Training Data） ⚫ プロンプト（Prompt） ⚫ AIモデルそのもの（LLM、Embeddingモデル等） ⚫ 推論結果（回答・要約・生成したコードや文章） ⚫ ベクトルデータベースの埋め込み（Embedding） これらは従来のシステムと比べて情報の密度が高く、漏洩した場合の被害が大きいことが特徴である
5. 4 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します 生成AIの普及とクラウド環境でのデータ利用が増加 なぜAIを使う上で認証認可が重要になるのか ◼ クラウド利用の増加でデータは分散・動的に移動する クラウド環境では以下のように様々な粒度で様々な場所にデータが存在する ⚫ S3、RDS、DynamoDB、OpenSearch ⚫ Redshift、Glue、Lambda ⚫ Bedrock などの生成AIサービス ⚫ 別リージョン・別アカウント AIがアクセスするデータの所在が複雑化し、アクセス制御の重要性が急激に高まっている
6. 5 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します 認証・認可が“AI資産／データ資産”を守る理由 なぜAIを使う上で認証認可が重要になるのか ◼ AIを扱うユーザーは「人間だけではない」 生成AI時代のアクセス主体は、人間だけではない ⚫ Lambda・ECSタスク ⚫ 他システムからのAPI呼び出し ⚫ AIエージェント自身 AIは自動的に外部へ問い合わせを行い、別のリソースへアクセスすることがあるため、「主体（Principal）が誰なのか」 「その主体が何を許可されているのか」を厳密に管理する必要がある
7. 6 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します 認証・認可が“AI資産／データ資産”を守る理由 なぜAIを使う上で認証認可が重要になるのか ◼ AIは「誤った行動を取る可能性がある」 AIは便利ですが、以下のような誤った操作を実行する可能性もある ⚫ 間違ったリソースへのアクセス ⚫ 意図しないデータの読み取り ⚫ 自己判断による不正確なAPI実行 ⚫ データの誤削除・誤更新 これらを防ぐには、AIがアクセスしてよい範囲を厳密に定義する「認可」が必須になる
8. 7 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します アクセス制御について
9. 8 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します RBAC（ロールベースアクセス制御） アクセス制御について ◼ 定義 RBAC（Role-Based Access Control） は、「ユーザー → ロール → 権限」という階層構造でアクセスを管理するモデ ルである ⚫ ユーザー：人・アプリケーション・サービス ⚫ ロール：役割（Admin / Dev / Auditor など） ⚫ 権限：実際に許可される操作（読み取り、更新、削除など） ロールに権限を割り当て、ユーザーがそのロールを持つことで権限が付与される IAMユーザー AWS Lambda Amazon Elastic Compute Cloud (Amazon EC2)
10. 9 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します RBAC（ロールベースアクセス制御） アクセス制御について ◼ メリット ⚫ シンプルで理解しやすい • 「役割」を与えるだけなので運用が容易 • 組織が「職務ベース」で動く場合にフィット ⚫ 役割が明確 • 「開発者はこの権限」「監査担当はこの権限」など、職務と権限が直感的に対応 ⚫ ガバナンスが取りやすい • ロールをアサインして運用できるため、変更管理・棚卸しが行いやすい ◼ デメリット（注意点） ⚫ ロール爆発（Role Explosion）が起きやすい 「開発者でも A チームと B チームは別権限」、「同じ職務でも機密度レベルが違う」などが増えると、ロールが無限に増え、管理が破 綻する ⚫ 細かい条件に弱い RBAC は「役割」単位でしか表現できないため、「特定の部署のメンバーだけ」、「特定の時間帯だけ」、「特定ラベルのついたリソース だけ」などの条件付き制御が苦手
11. 10 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します RBACを実装するAWSサービス アクセス制御の実装 RBAC は「誰にどのロールをつけるか」で制御するモデルなので、AWS では主に IAM と IAM Identity Center を使って 実装する ⚫ AWS Identity and Access Management（IAM） ⚫ IAMユーザー／グループ／ロール ユーザーに直接ポリシーを付けることもできるが、通常は「ロール（Role）」に権限をまとめて付与し、アプリケーションや人がロールを引 き受ける（AssumeRole）形にする ⚫ IAMポリシー Action,、Resource,、Effect を記述したJSONで権限を定義「AdminRole」「ReadOnlyRole」「DevOpsRole」など、役割ごとに ポリシーをまとめる ⚫ AWS IAM Identity Center ⚫ Azure AD / Entra IDなどのIdPのグループと連携し、「このグループの人は、このアカウントの、このロールを使える」というマッピング を作る。ここでも 「グループ（役割）」ベースの割り当て なので RBAC モデルである
12. 11 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します ABAC（属性ベースアクセス制御） アクセス制御について ◼ 定義 ABAC（Attribute-Based Access Control） は、ユーザー・リソース・アクション・環境の「属性（Attribute）」にもとづ きアクセスを決定するモデルである ⚫ 例：ユーザー属性 ⚫ 部署：Sales ⚫ 職位：Manager ⚫ 契約タイプ：社員 / 業務委託 ⚫ 所属テナント：Tenant A ⚫ 例：リソース属性 ⚫ 機密レベル：Confidential ⚫ プロジェクト：Project X ⚫ Tag：Environment=Prod IAMユーザー [タグ] department : Sales AWS Lambda [タグ] department : Sales IAMユーザー [タグ] department : Engineer AWS Lambda [タグ] department : Engineer
13. 12 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します ABAC（属性ベースアクセス制御） アクセス制御について ◼ メリット ⚫ 柔軟で細粒度 「ユーザーの部署 = リソースの部署」というように、属性の一致条件でアクセス可否を決められる RBAC では表現できない高度な条件が可能 ⚫ スケーラブル ロールの数が爆発しない 新しいプロジェクトや部署が追加されても、タグを付けるだけで権限を制御可能 ⚫ 動的ポリシーに対応 時間帯やIPなど「動的条件」に応じた制御が可能 ◼ デメリット（注意点） ⚫ データガバナンスがより求められる タグ設計・属性命名規則・必須項目など、データガバナンスが求められる ⚫ 運用負荷が高い タグ付けミスによるアクセス拒否・権限漏れが起きやすい ⚫ ポリシーが複雑化する 条件式（if/and/or/not）が増えると、ポリシーの可読性・レビュー性が低下
14. 13 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します ABACを実装するAWSサービス アクセス制御の実装 ABAC は「属性（タグなど）の組み合わせ」で制御するモデルなので、AWS ではタグ＋IAM信頼ポリシー＋いくつかの サービスの組み合わせで実装する 同じKey名は1つしか設定できないため、RBAC + ABACでアクセス制御を実装する IAMユーザー A [タグ] department : App AWS Lambda [タグ] department : App IAMロール A IAMユーザー B [タグ] department : Infra IAMロール B Amazon Elastic Compute Cloud (Amazon EC2) [タグ] department : Infra
15. 14 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します PBAC（ポリシーベースアクセス制御） アクセス制御について ◼ 定義 PBAC（Policy-Based Access Control） は、ロール（RBAC）や属性（ABAC）を含めた複数要素を中央のポリ シーで一元管理するモデルである AWS Verified Permissions では PBAC を積極的に採用しており、「ポリシーを中心に、RBAC と ABAC の双方を統 合し、コンテキストに応じた細かい制御が可能」 アプリケーション アプリケーション利用者 データベース Amazon Verified Permissions アクセス制御におけるポリシーの 評価結果を受け取る
16. 15 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します PBAC（ポリシーベースアクセス制御） アクセス制御について ◼ メリット ⚫ 動的ポリシー管理 変更頻度の高い制御をポリシーだけで調整できる アプリケーションコードの修正が不要 ⚫ 細かな条件が書ける Cedar（Amazon製ポリシー言語）などを使い、「条件式ベース」で高精度なアクセス判断が可能 AWS Verified Permissions の例： permit( principal == User::“test-user", action == Action::"read", resource in Resource::confidential ) when { principal.department == resource.department };
17. 16 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します PBAC（ポリシーベースアクセス制御） アクセス制御について ◼ デメリット（注意点） PBAC は ABAC の要素を含むため、タグ・属性・メタデータが正しく管理されていないと破綻する • 誤った属性が付くと誤許可・誤拒否が発生 • 属性の欠損や未統一タグが問題を引き起こす ➢ つまり、PBACは 属性データの統制がうまく機能している組織でなければ導入が難しい ➢ 誰がポリシーを書くのか、誰がポリシーの監査をするのかを明確にしておく必要がある ➢ PBACを実装した結果脆弱になることは避けたい
18. 17 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します PBAC を実装する AWS サービス アクセス制御の実装 PBAC は「ポリシーを中心に、RBACとABACを統合する」モデルなので、AWSではAmazon Verified Permissionsが代 表的な実装手段である Amazon Cognitoで認証、 Amazon Verified Permissionsで認可を実装することができる Amazon Cognito アプリケーション利用者 Amazon Verified Permissions Amazon API Gateway AWS Lambda Amazon Bedrock Allow or Deny Bedrock呼び出し 認証
19. 18 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します まとめ
20. 19 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 生成AIの普及で「データ」と「AIモデル」が新しい重要資産になった ◼ AI がアクセス主体になるため、従来以上に認証・認可が重要 ◼ RBAC：シンプルで運用しやすいが、柔軟性に限界 ◼ ABAC：柔軟・スケーラブルだが、属性管理のガバナンスが必須 ◼ PBAC：ポリシー中心で RBAC と ABAC を統合でき、AI 時代に使用していきたい ◼ AWS Verified Permissions により、PBAC を現実的に実装可能 ◼ PBACを実装する上で、誰が監査するのかを明確にして運用する まとめ