令和の今、あらためて IAM を考える。アクセスキーを「無くせない現実」との向き合い方

2026年11月7日（土）にあきた芸術劇場ミルハスで開催された JAWS FESTA 2026 in AKITA でお話しした際の資料です。
アクセスキーをすぐに無くせないなら棚卸しをしよう、という観点でどのような手順を踏めば良いかを整理しました。
最後の方で昨今多くなっている LLMJacking の手法として最近見聞きした事例も含めお話ししています。
#jawsug #jawsfesta #jawsfesta2026

Transcript

1. 令和の今、あらためて IAM を考える。 アクセスキーを「無くせない現実」との向き合い方 JAWS FESTA 2026 in AKITA (November 7, 2026) Speaker : @kazzpapa3(ICHINO Kazuaki) #jawsug #jawsfesta2026
2. Biography { "Bio": { "Name": "ICHINO Kazuaki a.k.a. kazzpapa3", "Organization": "A certain AWS partner company", "Role": "Technical Support Engineer", "Favorite AWS Services": [ "AWS CLI", "AWS CloudTrail", "Kiro CLI" ], "Less Favorite People (as a Support Engineer)": [ "クレデンシャル情報を雑に扱う人 " ], "Personal Interest": "初音ミク", "Socials": { "Twitter/X": "@kazzpapa3", "LinkedIn": "https://www.linkedin.com/in/kazzpapa3/" } } }
3. アクセスキーをはじめとする クレデンシャルの問題が後を絶 ちません
4. JAWS DAYS 2026 での登壇では • • • Abuse report だけじゃない。AWS から緊急連絡が 来る状況とは？昨今の攻撃や被害の事例の紹介と備 えておきたい考え方について と題してお話ししました ここでは AWS から届く緊急連絡についてどのようなも のがあるか、何らかの傾向があるか アクセスキーが漏れた際の攻撃手法や備えておくべ き考え方 についてお話ししました
5. Security-JAWS での登壇では • • アクセスキー流出時の対応で再認識した攻撃側と防 御側の非対称性について と題してお話ししました ここではアクセスキーが漏れた時の攻撃の一例を参 考に、以下のような 非対称性 があったことをお伝えし ました ◦ ◦ 攻撃者側は 約 17 分で仕込みが完了していた（リソース が出揃うまでは約 3 時間） 対して防御側では、状況の把握から削除対象の洗い出 しまで含め、約 11 時間を要した
6. 紹介した実例から：鍵が漏れてから起きたこと • • 漏れたアクセスキーには AdministratorAccess がついていた 攻撃者はわずか 約 17 分 で、最終的に 4,000 超のリソースを生み出す仕込みを 完了 時刻 出来事 21:38 攻撃者がリソース作成開始 21:55 約 17 分で仕込み完了（ユーザー締め出し／リージョン追加／ IaC でリソース乱立） 22:07 AWS から緊急通知が届く 01:19 顧客と連絡がつき、削除着手 09:30 削除完了（通知から約 11 時間 後。実作業は全容把握＋削除で約7〜8 時間）
7. 攻撃者 vs 防御者：圧倒的な非対称性 観点 攻撃者 防御者 リソース操作 自動化・IaC 化済 ID を知らないと削除できない 所要時間 仕込み完了まで 約 17 分 全容把握 3.5 時間 + 削除 4 時間 （これ以外にも顧客に連絡がつくまでの待機時間 や、顧客での確認時間があった） リージョン 全リージョンに並列展開 1 リージョンずつ確認 依存関係 気にせず作るだけ 削除順序を守る必要あり 判断 迷いがない 正規 or 不正の選別に時間 • • 作るのは一瞬、全容把握して削除するのは重労働 しかも、完全に削除するまで課金は止まらない
8. いずれの登壇でも • • • その時々の攻撃手法や新たな手法があればお伝えしていました ただ、本質としてアクセスキーに代表される永続的なキーの使用は現在の AWS の ベストプラクティスではなくなっており脱却が望ましいこと 以下のような代替案が用意されていることをお伝えしています ◦ ◦ ◦ IAM ロールやインスタンスプロファイルの利用 IAM Roles Anywhere によるオンプレミス環境でのアクセスキーからの脱却 aws login コマンドによる AWS CLI や AWS SDK など開発シーンでのアクセスキーから の脱却
9. それでも、実際のユーザーの声
10. AWS Summit Japan 2026 • • クレデンシャル流出 ― 攻撃 3 時間 vs 復旧 10 時間。 この非対称性にどう備えるか としてチョークトーク登壇 しました その際 ◦ ◦ "運用を変えにくい" など、自組織だけに閉じておらず、 複数のベンダーに委託している背景から運用を刷新で きない もどかしさ 「わかっているけどできていない 」状態となる「運用」の 難しさを痛感
11. では、現実的な落としどころは？
12. やはり、棚卸しと適切な運用
13. まず「棚卸しで何を見たいのか」を分解する • • 「IAM の棚卸し」と一言でいっても、見たい対象はいくつかの層に分かれる 評価軸を考える前に、対象を分解しておくと論点が整理しやすくなる # 棚卸しの対象 具体的に見たいこと 1 ルートユーザー MFA の有無、アクセスキーの有無、最終利用日、連絡先情報の妥当性 2 IAM プリンシパル（ユーザー・ロール・グループ） 存在意義、退職者・不要になったものの残骸、未使用の検出 3 権限（付与されたポリシー） 過剰付与、実際には使われていない権限 4 外部アクセス・到達可能性 クロスアカウント共有、外部公開されたリソース
14. そもそもルートユーザーは使わ ない
15. ルートユーザーに議論の余地はない • メンバーアカウントのルートユーザーについては、Centralize root access for member accounts（ルートアクセスの一元化） を利用して認証情報そのものを排 除 ◦ • • • パスワードを設定しない && パスワード回復もさせない 管理アカウントのルートユーザーは適切に MFA を設定し、常用しない 残す残さない、の議論の余地なく、使わない/使えない ようにしておく そもそも ルートユーザーの認証情報を必要とする作業 もかなり減っている
16. IAM プリンシパルに対する調査
17. 費用承認が得られるのであれば • • IAM Access Analyzer を組織横断で常時稼働 管理アカウントから、Access Analyzer の 委任管理者（Delegated administrator） をセキュリティ用アカウントに委任 ◦ • 委任管理者は組織内のアナライザーを作成・管理でき、組織スコープの検出結果を集約 ビューで確認可能 外部アクセス分析（無料） と 未使用アクセス分析（有料） の両方を組織スコープで有 効化 ◦ 検出結果を AWS Security Hub CSPM や EventBridge 経由で通知に連携し、継続的 に監視
18. IAM Access Analyzer の課金体系 機能 何を見るか 課金 外部アクセス分析（External access） 信頼ゾーン外へ共有されているリソースの検出 無料 無料なので使わない手はない ポリシー検証（Policy validation） ポリシーが IAM ベストプラクティスに沿うかの検証 無料 ポリシー生成（Policy generation） ログの実績から最小権限ポリシーを生成 無料（※ ログ元の CloudTrail 費用は別） 未使用アクセス分析（Unused access） 使われていない IAM ユーザー・ロール・権限の検出 有料（分析対象の IAM ロール・ユーザー数 × 月） 内部アクセス分析（Internal access） 信頼ゾーン内のプリンシパルからリソースへの到達可 能性 有料（モニタ対象リソース数 × 月） カスタムポリシーチェック（Custom policy checks） デプロイ前のポリシー検証（CheckXxx 系 API） 有料（API リクエスト数） • • 有料機能は 棚卸しにかかる人件費と、自動化・継続監視を天秤に 未使用リソースを削減すれば、徐々にコストは下がっていくはず
19. 無料の範囲でどうにかならない か
20. いくつかのサービスを組み合わせる • • • IAM 認証情報レポート（Credential Report） を取得する IAM Access Advisor で最終アクセス情報を見る GetAccountAuthorizationDetails を活用する ◦ ◦ ただしこれらは全て単一のアカウントに対しての実行となる AWS Organizations 組織全体を調査したい場合、全てのアカウントにAssumeRole し て上記を実行、取得するような処理をぶん回す必要がある点に留意が必要
21. IAM 認証情報レポート（Credential Report） • • • アカウント内のすべてのユーザー（ルートユーザーも含む）と、パスワード、アクセス キー、MFA デバイスの設定状況などの各種認証情報を取得可能 IAM ロールについては検出できない マネジメントコンソールでも AWS CLI や AWS SDK で実行可能 # 認証情報レポートの生成をリクエストし、取得する aws iam generate-credential-report aws iam get-credential-report \ --query 'Content' --output text | base64 -d > credential-report.csv
22. IAM Access Advisor • • IAM ユーザー、IAM グループ、IAM ロールに対して、与えられている権限でアクセ スできるサービスに最後にアクセスしたのはいつか？の観点でレポートを作成可能 ただし、実行時に IAM リソースごとに実行・確認する必要がある ◦ ◦ そのため、マネジメントコンソールではリソースごとにアクセスを繰り返す必要がある API で実行する場合、対象のリソースのARN を把握している必要があり、網羅したい場 合、①対象リソースの ARN 取得 → ②調査実行 を繰り返す必要がある
23. IAM Access Advisor の実行例 # 事前に aws iam list-roles などで対象リソースの ARN を知っている必要がある # 以下は TARGET_ARN 変数に ARN が格納されていると想定 aws iam generate-service-last-accessed-details \ --arn "${TARGET_ARN}" # 以下のような job-id が返却される { "JobId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222" } # job-id を指定し、get-service-last-accessed-details を実行する aws iam get-service-last-accessed-details \ --job-id "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222" • 複数リソースを対象にしたい場合、上記を繰り返すイメージ
24. get-service-last-accessed-details での返却例 { "JobStatus": "COMPLETED", "JobCreationDate": "2019-10-01T03:50:35.929Z", "ServicesLastAccessed": [ { "ServiceName": "AWS Lambda", "LastAuthenticated": "2019-09-30T23:02:00Z", "ServiceNamespace": "lambda", "LastAuthenticatedEntity": "arn:aws:iam::123456789012:user/admin", "TotalAuthenticatedEntities": 6 } ], "IsTruncated": false }
25. GetAccountAuthorizationDetails の活用 • • • アカウント内のすべての IAM ユーザー、グループ、ロール、およびポリシーに関す る情報（相互の関係性を含む）を取得可能 aws iam get-account-authorization-details の要領で実行が可能 --filter オプションとして User、Role、Group、LocalManagedPolicy、 AWSManagedPolicy を列記できる ◦ aws iam get-account-authorization-details --filter User Group のように実行する ことで、IAM ユーザーと IAM グループのみにフォーカスして出力可能
26. 出力例（視認性のために YAML 化しています） UserDetailList: - Path: / UserName: admin UserId: AIDATTSMMODQEUQYAFFFG Arn: arn:aws:iam::123456789012:user/admin CreateDate: "2026-08-01T05:43:16+00:00" GroupList: - admin-group AttachedManagedPolicies: [] Tags: [] GroupDetailList: - Path: / GroupName: admin-group GroupId: AGPATTSMMODQGBTQ3GDKM Arn: arn:aws:iam::123456789012:group/admin-group CreateDate: "2022-06-07T01:06:08+00:00" GroupPolicyList: [] AttachedManagedPolicies: - PolicyName: AdministratorAccess PolicyArn: arn:aws:iam::aws:policy/AdministratorAccess RoleDetailList: [] Policies: []
27. 前述の出力例から • • • • admin ユーザーが存在していることを確認可能 admin ユーザーは admin-group グループに所属していることが確認できる admin-group グループには AWS 管理ポリシー AdministratorAccess が付与さ れていることが確認できる admin ユーザーに直接アタッチされているポリシーはないが、IAM グループ admin-group を通じて AWS 管理ポリシー AdministratorAccess がアタッチされ ていることがわかる
28. 無料でできそう。 でも「面倒」
29. 単一アカウントの手順を、組織全体で繰り返す
30. 判断ポイント • • • 取得するのはいくつかの AWS API を組み合わせて取得が可能 生成 AI も活用して、一連の作業をスクリプト化すると属人作業を減らすことはでき そう ただし、ポリシーが過剰かどうかを含め、人間での判断ポイントは多い ◦ ◦ 長いこと使っていない、は判断しやすいが、不当に過剰に権限がつきすぎているかは意 図 の正しい理解と判断が必要 IAM Access Analyzer のポリシー生成をうまく活用すると良い
31. ざっくりと論点の整理はできた • 有償か無償かを問わず、アクセスキー や不要リソースの撤廃に向けて棚卸しの道 筋はついた a. b. c. d. アクセスキー自体の存在を知る 最後に利用された日時を知る 最後にアクセスしたサービスを知る 最小権限になっているかを判断する （もちろんアクセスキーの場合、削除して運用を変える、という判断ができるとなお良し）
32. これで OK とはならない時代
33. そして、残り時間も少なくなって いるはず
34. Amazon Bedrock の API キーが悪用され始めた • • • 見かけた事例は AdministratorAccess が付与されているアクセスキーが不正利 用され、Amazon Bedrock の長期 API キーを新設されて悪用された ただし発行済の長期 API キーの流出でも起こりうるので、作れなければ良い、とい う話でもない そして、長期 API キーの作成は iam:CreateAccessKey ではない ◦ 実体は IAM ユーザーだが iam:CreateServiceSpecificCredential で作られる
35. Amazon Bedrock の長期 API キーの生成方法 • • GUI の場合、「長期 API キー」タブの「長期 API キーを生成」ボタンから有効期限を 指定して生成する CLI で行おうとした場合、以下の手順に分解される # 1. IAM ユーザーを新規作成する aws iam create-user --user-name bedrock-api-user # 2. 権限ポリシーをアタッチする aws iam attach-user-policy \ --user-name bedrock-api-user \ --policy-arn arn:aws:iam::aws:policy/AmazonBedrockLimitedAccess # 3. bedrock.amazonaws.com 向けのサービス固有認証情報（＝API キー）を生成する aws iam create-service-specific-credential \ --user-name bedrock-api-user \ --service-name bedrock.amazonaws.com \ --credential-age-days 30
36. では、その長期 API キーをどう棚卸しするか • • 長期 API キーは実体こそ IAM ユーザーだが、サービス固有認証情報 であり通常 のアクセスキーとは別管理 そのため、これまでの棚卸し手段では見落とす ◦ ◦ • 認証情報レポートのアクセスキー列（access_key_1/2）には出ない list-access-keys / get-access-key-last-used も 対象外 専用 API list-service-specific-credentials で列挙する ◦ --all-users フラグでアカウント内の全ユーザー分を一括列挙できる（ユーザーごとに回さ なくてよい）
37. 長期 API キーの棚卸しの実行例 # アカウント内の「全ユーザー」の Bedrock 長期 API キーを一括列挙 aws iam list-service-specific-credentials \ --service-name bedrock.amazonaws.com \ --all-users • • 上記で対象のアカウント内の bedrock.amazonaws.com に対する全てのサービ ス固有認証情報が取得できる ただしアカウント内に限定されるので、ここまで話してきた通り AWS Organizations 組織内を網羅するには、メンバーアカウントごとに AssumeRole す る必要がある
38. list-service-specific-credentials の応答例 { "ServiceSpecificCredentials": [ { "UserName": "BedrockAPIKey-9fri", "Status": "Active", "ServiceCredentialAlias": "BedrockAPIKey-9fri-at-123456789012", "CreateDate": "2026-11-03T10:13:00+00:00", "ExpirationDate": "2026-11-04T10:13:00+00:00", "ServiceSpecificCredentialId": "ACCA4JEXAMPLECRSU5GJBQ", "ServiceName": "bedrock.amazonaws.com" } ], "IsTruncated": false }
39. 確認観点 • Status（Active / Inactive / Expired）、CreateDate、ExpirationDate を確認 ◦ ◦ ExpirationDate が無い ＝ 無期限キー の炙り出しにも使える 期限切れのキーは Expired として残る（棚卸し時に併せて確認）
40. 確認観点 • 通常のアクセスキーにある get-access-key-last-used に相当する出力が 存在 しない ◦ • 「最後に使われたのはいつか」はCloudTrail で裏取りする ▪ userIdentity に IAM ユーザー名が記録される ▪ callWithBearerToken: true で API キー経由の呼び出しと判別可能 「アクセスキーを棚卸しして安心」ではなく、別系統の認証情報も棚卸し手順に明 示的に組み込む 必要がある
41. まとめ • Amazon Bedrock の長期 API キーは 2025年7月 に新たにできた概念 ◦ ◦ • • 同じ「長期 API キー」系は Amazon CloudWatch Logs も存在（いずれも有効期限の概 念がある） 従来型のサービス固有認証情報としては、AWS CodeCommit（HTTPS Git 認証情 報） や Amazon Keyspaces (Cassandra) も 今回 "不正な利用料高騰" に繋がりうる観点で Amazon Bedrock の長期 API キーに着目しています 情報流出や監査妨害の観点では他サービスも含める必要があり、サービスの利用 実態に応じて棚卸しや運用見直し観点は広がる
42. まとめ • • • 長期的なクレデンシャル情報は一度持ってしまうと確認が煩雑 アクセスキーに加えてサービス固有認証情報も踏まえて、棚卸し方法の確立と実 施は必要 従来存在していた "サービス固有認証情報" の概念を利用して Amazon Bedrock の長期 API キーとして展開されるなど、永続的なクレデンシャル を保持できる可 能性について常にサービスアップデートの確認は必要
43. Security is job zero. Thank you. #jawsug #jawsfesta2026