Tokyo_reInforce_2025_recap_iam_access_analyzer

Transcript

1. IAM Access Analyzerの新機能 Internal Accessって何？ 使ってみました！ クラスメソッド株式会社 芦沢広昭
2. 芦沢広昭（あしざわ ひろあき） 所属 クラスメソッド株式会社 クラウド事業本部 コンサルティング部 ロール ソリューションアーキテクト 担当業務 AWSインフラ設計構築、コンサルティング AWS re:Inforce 参加歴 オンライン(2023)、現地(2024, 2025) その他 2025 Japan All AWS Certifications Engineers 自己紹介 2
3. IAM Access Analyzer Internal Accessとは？ シングルアカウントで試してみた 検証してわかったこと アジェンダ 3
4. IAM Access Analyzer Internal Accessとは？ 4
5. S3・RDS・DynamoDBなどの リソースへアクセスできるすべてのIAMプリンシパル (IAMユー ザー、ロール) を、同じAWSアカウントや同じOrganizations組織の 範囲内から検出する機能 IAM Access Analyzerは、 「未使用のアクセス / 内部アクセス / 外部アクセス」の3つに！ 機能概要 5
6. 各アナライザーの違い 6
7. 分析対象リソース1つあたり $9.00 USD / 月 ※IAM Access Analyzer Pricingページ(英語版)を参照 結構お高いのでは...？ と思った方へ 最後に検証で発生したコストを発表します！お楽しみに 料金 7
8. シングルアカウントで試してみた 8
9. 検証内容（シングルアカウント） 9
10. 1. 事前準備（リソース作成、通知設定） 2. Internal Access作成 3. 結果の確認と分析 検証の流れ 10
11. 1. 以下リソースを作成しました リソースタイプ リソース名 設定内容 S3バケット internal-access-test-bucket-{AWSアカウントID} デフォルト設定 IAMロール internal-role ReadOnlyAccess権限 事前準備(リソース作成) 11
12. ※S3に設定したバケットポリシーはこちら { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowInternalRoleAccess", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "s3:GetObject", "s3:ListBucket", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "${bucket_arn}", "${bucket_arn}/*" ], "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::${account_id}:role/internal-*" } } } ] 事前準備(リソース作成) 12
13. 1. SNSトピックを作成、サブスクリプション設定でメールアドレスを登録した SNSトピックのサブスクライブも忘れずに実施 2. EventBridgeルールを作成、ターゲットはSNSトピックとした イベントパターンは以下を設定 { "source": ["aws.access-analyzer"], "detail-type": ["Internal Access Finding"] } 事前準備(通知設定) 13
14. 設定項目 検出結果のタイプ: Resource analysis - Internal access 名前: internal-access-analyzer 信頼ゾーン: 現在のアカウント（固定） 分析対象のリソース: internal-access-test-bucket-{AWSアカウントID} 内部アクセス分析の作成 14
15. 35件 の検出結果を検知 → 信頼ゾーン があるのに何故こんなに...？ 作成後、しばらく待つと... 15
16. 原因の一つは、IAMの評価論理の仕様にあり 同一アカウントの場合、どちらか一方の明示的な許可があればOK アイデンティティベースポリシー(IAMポリシー等) リソースベースポリシー(S3バケットポリシー等) 参考: https://dev.classmethod.jp/articles/devio-2021-iam-evaluation-logic/ 何故こんなに検知したのか？① 16
17. 内部アクセスには、信頼ゾーンの概念はないと想定する 外部アクセス：信頼ゾーンの範囲内の検出は問題なしとする → 内部アクセスは信頼ゾーンの概念がそもそも存在しないのでは...？ 想定する実際の仕様 信頼ゾーンとの記載はマネコンの不備と想定できる、実際は「選択されたアカウント」の想定 ※選択されたアカウント = 未使用アクセスと同じ仕様 何故こんなに検知したのか？② 17
18. S3バケットポリシーを制限して再度チャレンジしたが、権限を絞りすぎてエラーに。 再度ポリシー権限を見直して、再々チャレンジしたところ... 再スキャンが一向に実行されない ドキュメントによると「アナライザーが更新された時は24時間以内に自動再スキャンされ る」 リソース側が更新された場合の動作は...？ 手動スキャンはできない(再スキャンのボタンがない) 再チャレンジ 18
19. 別環境にて、Organizations組織の内部アナライザーを作成した環境で検知 どのリソースポリシーで許可されているか、SCP/RCPの影響のあるなし(Applied)、許可され ているアクセス権限(Access Level)がすぐわかる アクセスされるリソースとアクセス元のIAMプリンシパルの情報がまとまっており、クロスア カウントアクセスロールでも状況が一目でわかる 参考： Organizations組織での検出結果の例 19
20. 有効化した初日にコストが発生、分割して従量課金されない仕様 (未使用のアクセスと同じ) ここまでに発生したコスト 20
21. 検証してわかったこと 21
22. 1. 全リソースに対し一律で有効化する機能ではない 最小権限の実現や新規アクセスの通知が不要なリソースには適用しなくて良い 一撃で発生する利用費が高価になりがち(未使用のアクセスと同様) 2. 運用最適化までの難易度は高い リソースベースポリシー、アイデンティティベースポリシーともにかなり制限していないと、 多めに検知してしまう サービスリンクロールがあると大量に検知するので、アーカイブルールとセットで運用 3. シングルアカウントよりマルチアカウント環境での活用にメリットがある 詳しく紹介できなかったが、SCP/RCPやPermission Boundayrと併用することでより効率性の 高い 複雑なクロスアカウントアクセスの検知が可能無点がメリット SCP/RCPの影響があるリソースのみを検知してアーカイブすることも可能 検証してわかったこと 22
23. 料金が高額（$9/リソース/月、従量課金ではない） 全リージョン、全アカウントで有効化するのはコスト観点で危険 手動スキャン不可、再スキャンタイミングが不明瞭 トライアンドエラーしづらい 信頼ゾーンは誤植だと思われる おそらく内部アクセスは未使用のアクセスと同じ仕様 注意点 23
24. 質問・ご意見は Ask the Speaker でお待ちしております ご清聴ありがとうございました！ 24