AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略（JAWS-UG朝会#59資料改修20分版）

AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略
～AWS IAM Identity Center の権限設計についても考えてみる～

JAWS-UG朝会#59でお話した資料です。
https://jawsug-asa.connpass.com/event/291919/

Transcript

1. 2024年7月19日 AWS Identity and Access Management （IAM）のアンチパターン/AWSが考える最低権限 実現へのアプローチ概略 ～AWS IAM Identity Center の権限設計も考えてみる～ NRIネットコム株式会社 クラウド事業推進部 丹 勇人 JAWS-UG朝会 #59
2. 1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介＆本日の主題 01 AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン 02 AWSが考える最小権限実現への4ステップアプローチ概略 03 AWS IAM Identity Center の権限設計も考えてみる 04 Summary, References & Appendix 05
3. 2 Copyright（C） NRI Netcom, Ltd. All rights reserved. 丹 勇人（たん はやと） 自己紹介&本日の主題 ◼ NRIネットコム株式会社 現在 クラウド事業推進部 所属 ◼ 2024 Japan AWS Ambassadors （Associate Ambassador） ◼ 2024 Japan AWS Top Engineers (Security) ◼ AWS Community Builders（Security） since 2023 ◼ 2022 APN AWS Top Engineers (Service) ◼ AWS認定 ⚫ 2024 Japan ALL AWS Certifications Engineers ◼ 直近のプロジェクト ⚫ AWS環境の構築・運用支援 ⚫ AWSマルチアカウント環境の組織管理・運用支援 ⚫ AWSアカウント管理（請求代行）、技術サポート ◼ その他プロフィール ⚫ 秋田県出身→福島県→東京都大田区→埼玉県 ⚫ 子供５人（育休ブログ、TECHブログ書いてます）
4. 3 Copyright（C） NRI Netcom, Ltd. All rights reserved. NRI NETCOM TECH & DESIGN STUDY 自己紹介&本日の主題 過去’23/6/18に30分間で話しました。が、、 内容を詰め込みすぎまして。。。今回の20分枠に至ります。 一部を参考として要点を絞ってお話します。 NRIネットコム勉強会「NRI NETCOM TECH & DESIGN STUDY」毎月開催してます！ connpass NRIネットコム TECH & DESIGN STUDY
5. 4 Copyright（C） NRI Netcom, Ltd. All rights reserved. 本日の主題 自己紹介&本日の主題 ◼本日お話すること ⚫AWS IAMでのセキュリティのベストプラクティス/アンチパターン ⚫最小権限実現へのステップアプローチ ⚫AWS IAM Identity Centerの権限設計 ◼本日お話しないこと ⚫AWS IAM の基礎 ⚫AWS Elastic Compute Cloud（EC2）等のその他AWSサービス詳細 ⚫AWS re:Inforce 2024 の話 … 1billion API calls per second worldwide
6. 5 Copyright（C） NRI Netcom, Ltd. All rights reserved. 用語① 自己紹介&本日の主題 ◼ ルートユーザー AWSアカウントのすべてのAWSサービスとリソースに対して完全なアクセス権限を持つユーザー ◼ AWS管理ポリシー/カスタマー管理ポリシー/インラインポリシー ⚫ AWS管理ポリシー：AWS が作成および管理するスタンドアロンポリシー ⚫ カスタマー管理ポリシー：プリンシパルエンティティ (ユーザー、グループ、ロール) にアタッチできる利用者独自で管理するポリシー ⚫ インラインポリシー：1 つの IAM アイデンティティ (ユーザー、グループ、ロール) に埋め込まれたポリシー ◼ Permissions Boundary IAMユーザーやIAMロールに対して、アクセス権限の許可範囲を設定することができる機能 （出典：Permissions boundaries for IAM entities）https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html User
7. 6 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介＆本日の主題 01 AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン 02 AWSが考える最小権限実現への4ステップアプローチ概略 03 AWS IAM Identity Center の権限設計も考えてみる 04 Summary, References & Appendix 05
8. 7 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAM の管理は簡単？ AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン A. いいえ。難しいです。 • 増えるユーザ数 • 権限を与えすぎて起きる操作ミス • 権限を絞りすぎると落ちる開発スピード • 認証情報の漏洩による情報流出…etc. これらの課題に対処しながら IAMユーザ/グループ/ポリシー管理や ルートユーザ、アクセスキー等の認証情報の管理 が必要になります。
9. 8 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン AWSの公式ドキュメントに、IAMでのセキュリティのベストプラクティスがまとめられています。 ベストプラクティスを適用しないケースを考え、最終的にアンチパターンを整理します。 AWS IAM でのセキュリティのベストプラクティス（No.1~14） https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html AWS IAMでのセキュリティのベストプラクティスを適用しないケース ８ケース AWS IAMでのセキュリティのアンチパターン ６パターン
10. 9 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAMでのセキュリティのベストプラクティス AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン AWSの公式ドキュメントに、IAMでのセキュリティのベストプラクティスがまとめられています。 （出典：IAM でのセキュリティのベストプラクティス）https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html No. AWS IAMでのセキュリティのベストプラクティス 1 人間のユーザーが一時的な認証情報を使用して AWS にアクセスする場合に ID プロバイダーとのフェデレーションを使用することを必須とする 2 ワークロードが AWS にアクセスする場合に IAM ロールで一時的な資格情報を使用することを必須とする 3 多要素認証 (MFA) を必須とする 4 長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する 5 ルートユーザーの認証情報を保護するためのベストプラクティスに沿う 6 最小権限アクセス許可を適用する 7 AWS管理ポリシー（およびカスタマー管理ポリシー）の利用を開始し、最小権限のアクセス許可に移行する 8 IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する 9 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認して削除する 10 IAM ポリシーで条件を指定して、アクセスをさらに制限する 11 IAM Access Analyzer を使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認する 12 IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス許可を確保する 13 複数のアカウントにまたがるアクセス許可のガードレールを確立する 14 アクセス許可の境界（Permissions Boundary）を利用して、アカウント内のアクセス許可の管理を委任する
11. 10 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAMでのセキュリティのベストプラクティスを適用しないケースを考える AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン IAMでのセキュリティのベストプラクティスを適用しない場合にどういった対応を取るか、という のを考えてみます。 No. AWS IAMでのセキュリティのベストプラクティス 1 ID プロバイダーとのフェデレーションを使用することを必須とする 2 IAM ロールで一時的な資格情報を使用することを必須とする 3 多要素認証 (MFA) を必須とする 4 アクセスキーを必要な時に更新する 5 ルートユーザーを保護するためのベストプラクティスに沿う 6 最小権限アクセス許可を適用する 7 最小権限のアクセス許可に移行する 8 IAM Access Analyzer で、最小特権ポリシーを生成する 9 未使用の認証情報を定期的に確認して削除する 10 IAM ポリシーで条件を指定して、アクセスをさらに制限する 11 パブリックアクセスおよびクロスアカウントアクセスを確認する 12 IAM ポリシーを検証し、機能的なアクセス許可を確保する 13 アクセス許可のガードレールを確立する 14 アクセス許可の境界（Permissions Boundary）を利用 No. AWS IAMでのセキュリティのベストプラクティスを適用しないケース 1 （IDプロバイダーとのフェデレーションを使用できない場合もある） 2 長期的な認証情報のみを利用する 3 IAMユーザに多要素認証 (MFA) を利用しない 4 アクセスキーを更新しない 5 ルートユーザーを保護するためのベストプラクティスに従わない 6 最小権限ではない（不要な）アクセス許可を適用する 7 AWS管理ポリシーおよびカスタマー管理ポリシーを利用しない 8 不要なアクセス許可を適用したIAMポリシーを生成する 9 未使用の認証情報を定期的に確認しない（棚卸しない） 10 No.8に同じ 11 パブリックアクセスおよびクロスアカウントアクセスを確認しない 12 （IAM ポリシー検証を実施しない場合もある） 13 （アクセス許可のガードレールを確立しない場合もある） 14 （アクセス許可の境界（Permissions Boundary）を利用しな い場合もある）
12. 11 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAMでのセキュリティのベストプラクティスを適用しないケース AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン IAMでのセキュリティのベストプラクティスを適用しないケースをまとめます。 No. AWS IAMでのセキュリティのベストプラクティスを適用しないケース 1 （IDプロバイダーとのフェデレーションを使用できない場合もある）※後ほど、AWS IAM Identity Center について紹介 2 長期的な認証情報のみを利用する（AWSアカウント間のアクセスの委任にIAMロールを利用しない） 3 IAMユーザに多要素認証 (MFA) を利用しない 4 長期的な認証情報を必要とするユースケースでアクセスキーを更新しない 5 ルートユーザーの認証情報を保護するためのベストプラクティスに従わない（ルートユーザの常用、アクセスキー作成、MFA未設定、未承認利用等） 6 最小権限ではない（不要な）アクセス許可を適用する 7 AWS管理ポリシーおよびカスタマー管理ポリシーを利用しない（インラインポリシーのみを利用、AWS管理ポリシーのみを利用する） 8 最小権限ではない（不要な）アクセス許可を適用したIAMポリシーを生成する（No.6と類似）※今回は割愛 9 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認しない（棚卸しない） 10 No.8に同じ ※今回は割愛 11 IAM Access Analyzer を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない 12 （IAM Access Analyzer を使用した IAM ポリシー検証を実施しない場合もある）※今回は割愛 13 （複数のアカウントにまたがるアクセス許可のガードレールを確立しない（管理対象外の）場合もある）※今回は割愛 14 （アクセス許可の境界（Permissions Boundary）を利用しない場合もある）※今回は割愛
13. 12 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAMでのセキュリティのアンチパターンを考える AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン IAMでのセキュリティのベストプラクティスを適用しないケースの内、類似しているケースを まとめて、使用しない場合もあるものは対象外とします。 No. AWS IAMでのセキュリティのベストプラクティスを適用しないケース 1 （IDプロバイダーとのフェデレーションを使用できない場合もある）※後ほど、AWS IAM Identity Center について紹介 2 長期的な認証情報のみを利用する（AWSアカウント間のアクセスの委任にIAMロールを利用しない） 3 IAMユーザに多要素認証 (MFA) を利用しない 4 長期的な認証情報を必要とするユースケースでアクセスキーを更新しない 5 ルートユーザーの認証情報を保護するためのベストプラクティスに従わない（ルートユーザの常用、アクセスキー作成、MFA未設定、未承認利用等） 6 最小権限ではない（不要な）アクセス許可を適用する 7 AWS管理ポリシーおよびカスタマー管理ポリシーを利用しない（インラインポリシーのみを利用、AWS管理ポリシーのみを利用する） 8 最小権限ではない（不要な）アクセス許可を適用したIAMポリシーを生成する（No.6と類似）※今回は割愛 9 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認しない（棚卸しない） 10 No.8に同じ ※今回は割愛 11 IAM Access Analyzer を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない 12 （IAM Access Analyzer を使用した IAM ポリシー検証を実施しない場合もある）※今回は割愛 13 （複数のアカウントにまたがるアクセス許可のガードレールを確立しない（管理対象外の）場合もある）※今回は割愛 14 （アクセス許可の境界（Permissions Boundary）を利用しない場合もある）※今回は割愛
14. 13 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAMでのセキュリティのアンチパターン AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン AWS IAMでのセキュリティのアンチパターンを６パターンに分類しました。 まずは、AWS IAMでのセキュリティのアンチパターンを行わないようにしましょう！ AWS IAMでのセキュリティのアンチパターン ① • 長期的な認証情報のみを利用する（AWSアカウント間のアクセスの委任にIAMロールを利用しない） • 長期的な認証情報を必要とするユースケースでアクセスキーを更新しない ② • IAMユーザに多要素認証 (MFA) を利用しない ③ • ルートユーザーの認証情報を保護するためのベストプラクティスに従わない （ルートユーザの常用、アクセスキー作成、MFA未設定、未承認利用等） ④ • 最小権限ではない（不要な）アクセス許可を適用する • AWS 管理ポリシーを利用しない（インラインポリシーを利用する、AWSマネージドポリシーのみを利用する） ⑤ • 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認しない（棚卸しない） ⑥ • IAM Access Analyzer を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない
15. 14 Copyright（C） NRI Netcom, Ltd. All rights reserved. （参考）AWS IAMでのセキュリティのベストプラクティスを適用しないケース（No.1~3） AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン ◼ <No.1>人間のユーザーが一時的な認証情報を使用して AWS にアクセスする場合に ID プロバイダーとのフェデ レーションを使用することを必須とする ➢ （IDプロバイダーとのフェデレーションを使用できない場合もある）※後ほど、AWS IAM Identity Center について紹介 ◼ <No.2>ワークロードが AWS にアクセスする場合に IAM ロールで一時的な資格情報を使用することを必須とする ➢ 長期的な認証情報のみを利用する（AWSアカウント間のアクセスの委任にIAMロールを利用しない） AWSアカウント間のアクセスの委任にIAMロールを利用しないで、アクセスキー（シークレットキー）を常用すると、アクセスキー情報 が漏洩して悪意のある第三者に認証情報を利用される可能性があります。 ◼ <No.3>多要素認証 (MFA) を必須とする ➢ IAMユーザーに多要素認証 (MFA) を利用しない IAMユーザーにMFAを利用しない場合、AWSへのログインをパスワードのみで認証する形となり、パスワードを第三者に知られること で不正にアクセスされる可能性があります。 危険 危険 参考
16. 15 Copyright（C） NRI Netcom, Ltd. All rights reserved. （参考） AWS IAMでのセキュリティのベストプラクティスを適用しないケース（No.4~6） AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン ◼ <No.4>長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する ➢ 長期的な認証情報を必要とするユースケースでアクセスキーを更新しない 原則アクセスキーを利用しないことをお勧めしますが、アプリケーションからのアクセス等にアクセスキーを利用するケースがあります。こ の場合に、アクセスキーを更新しないと、アクセスキーが漏洩した際に第三者が認証情報を利用し続けてしまいます。 ◼ <No.5>ルートユーザーの認証情報を保護するためのベストプラクティスに沿う ➢ ルートユーザーの認証情報を保護するためのベストプラクティスに従わない（ルートユーザの常用、アクセスキー作成、MFA未 設定、未承認利用等） ルートユーザーは管理者権限であるため、原則権限を絞ることができません。ルートユーザーを常用したり、ルートユーザーのアクセス キーを作成、MFA未設定、承認無しで利用することは、ルートユーザーの情報が漏洩する危険性につながります。 ◼ <No.6>最小権限アクセス許可を適用する ➢ 最小権限ではない（不要な）アクセス許可を適用する 「必要だから」と過剰に権限を付与してしまい、操作ミスが起きる可能性があります。 一方で、「少しでも危なそうな機能を使わない」とのスタンスから使いたい機能を禁止すると、必要な操作もできなくなってしまいま す。 危険 参考
17. 16 Copyright（C） NRI Netcom, Ltd. All rights reserved. （参考） AWS IAMでのセキュリティのベストプラクティスを適用しないケース（No.7~9） AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン ◼ <No.7>AWS管理ポリシー（およびカスタマー管理ポリシー）の利用を開始し、最小特権のアクセス許可に移行 する ➢ AWS管理ポリシーおよびカスタマー管理ポリシーを利用しない（インラインポリシーのみを利用、AWS管理ポリシーのみを利用 する） カスタマー管理ポリシーを利用することで最小権限に絞り込むことができます。 IAMユーザーに直接付与可能なインラインポリシーばかりを利用しているとユーザー増加に伴い管理しきれなくなり、不要なアクセス 許可が残ってしまう可能性があります。 また、AWSが用意するAWS管理ポリシーは便利であるものの、各アカウントやユーザーの利用用途に沿った最小権限ではないため、 AWS管理ポリシーのみを利用することは不要なアクセス許可をユーザーに与えることになります。 ◼ <No.8>IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する ➢ 最小権限ではない（不要な）アクセス許可を適用したIAMポリシーを生成する（No.6と類似）※今回は割愛 ◼ <No.9>未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認して削除する ➢ 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認しない（棚卸しない） IAMの棚卸をしないと、退職者やプロジェクトから離れた職員からの認証情報漏洩、不要になったロールの不正利用、無駄なア クセス許可やポリシーによる操作ミス等の危険性が高まります。 危険 参考
18. 17 Copyright（C） NRI Netcom, Ltd. All rights reserved. （参考） AWS IAMでのセキュリティのベストプラクティスを適用しないケース（No.10~14） AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン ◼ <No.10>IAM ポリシーで条件を指定して、アクセスをさらに制限する ➢ No.8に同じ ※今回は割愛 ◼ <No.11>IAM Access Analyzer を使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確 認する ➢ IAM Access Analyzer を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない パブリックアクセスやクロスアカウントアクセスは、AWSアカウント外に影響するため非常に注意が必要な観点です。 リソースの意図しないパブリックアクセスやクロスアカウントアクセスがあった場合、不正にアクセスされて情報が漏洩する可能性が あります。 ◼ <No.12>IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス許可を確保する ➢ （IAM Access Analyzer を使用した IAM ポリシー検証を実施しない場合もある）※今回は割愛 ◼ <No.13>複数のアカウントにまたがるアクセス許可のガードレールを確立する ➢ （複数のアカウントにまたがるアクセス許可のガードレールを確立しない（管理対象外の）場合もある） ※今回は割愛 ◼ <No.14>アクセス許可の境界（Permissions Boundary）を利用して、アカウント内のアクセス許可の管理を 委任する ➢ （アクセス許可の境界（Permissions Boundary）を利用しない場合もある） ※今回は割愛 危険 参考
19. 18 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介＆本日の主題 01 AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン 02 AWSが考える最小権限実現への4ステップアプローチ概略 03 AWS IAM Identity Center の権限設計も考えてみる 04 Summary, References & Appendix 05
20. 19 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWSの考える 最小権限実現への4ステップアプローチ はご存じでしょうか？ （出典：最小権限実現への4ステップアプローチ 前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/ （出典：最小権限実現への4ステップアプローチ 後編） https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp2/ ※4ステップアプローチ 前編/後編を出展として、本ページ以降でブログの一部を掲載します
21. 20 Copyright（C） NRI Netcom, Ltd. All rights reserved. はじめに AWSが考える最小権限実現への4ステップアプローチ概略 IAMでのセキュリティのベストプラクティスとして掲げられているのが、最小権限の原則（No.6,7）です。 「最小権限を適切に運用する」ことを計画します。 ⚫ システムの運用や開発の視点で「必要」となる操作の権限のみを人やアプリケーションに付与する ➢ 「必要だから」と過剰に権限を付与→操作ミスが発生 ⚫ 「リスクを考慮して受容」できる範囲内に絞って「必要最小」の権限を人やアプリケーションに付与する ➢ 「少しでも危なそうな機能を使わない」とのスタンスから使いたい機能を禁止→必要な操作ができない 受容可能なリスクの算出は、システム開発・運用の現場には荷の重いテーマなだけに、検討がおざなりになって、上記 のような権限設定をしてしまうことがあります。 User User
22. 21 Copyright（C） NRI Netcom, Ltd. All rights reserved. 受容可能な最大権限とは AWSが考える最小権限実現への4ステップアプローチ概略 Amazon Simple Storage Service（Amazon S3）で、機密度の高い情報を取り扱うシステム例とした場合、 パブリック公開機能を有効化する権限はその組織にとっては受容しがたい権限となります。 ⚫ 受容可能な権限 = Amazon S3の全権限 – パブリック公開権限 Amazon S3の全権限 パブリック公開権限 ※本番環境における権限の最適化を目的としています。開発環境では開発者の利便性を最大限考慮して、AWS機能を緩やかな制限で利用するケースもあります （出典：最小権限実現への4ステップアプローチ 前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/
23. 22 Copyright（C） NRI Netcom, Ltd. All rights reserved. 最小権限実現への4ステップアプローチ（STEP1~3） AWSが考える最小権限実現への4ステップアプローチ概略 各ステップの概要を目次として見ていきます。 ◼ STEP1: 必要最小限の権限エリア（A）を把握する ➢ 表1：「マップつくラボ」システムで使用される必要最小の権限 架空のベンチャー企業が作成した地図画像を生成するシステム「マップつくラボ」を例に、システムで使用される必要最小の権限を 洗い出しています ◼ STEP2: 受容できないビジネス影響を洗い出す ➢ 表2：想定される脅威とビジネス影響一覧の例 「マップつくラボ」のユースケースに基づき、主な脅威とその対象となる主要機能、データ保管場所を洗い出し、ビジネス影響を「致 命的/局所的影響/受容可」の３段階で評価しています ◼ STEP3:受容できないビジネス影響をもたらしうる権限範囲（B）を把握する ➢ （表2 + アクセスレベル）表3-1：受容できない権限一覧 ➢ （表1 + 表3-1）表3-2：システム運用にリクエストされる必要最小の権限と悪用された場合のビジネス影響の一覧 「マップつくラボ」における受容できないリスクをもたらす権限をAWSアクセスレベルで「表3-1」として抽出しています。 「マップつくラボ」において、必要最小の権限が悪用された場合のビジネス影響一覧を「表3-2」として作成しています （出典：最小権限実現への4ステップアプローチ 前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/
24. 23 Copyright（C） NRI Netcom, Ltd. All rights reserved. （参考）STEP1: 必要最小限の権限エリア（A）を把握する AWSが考える最小権限実現への4ステップアプローチ概略 架空のベンチャー企業が作成した地図画像を生成するシステム「マップつくラボ」を例に、具体的なアプローチの説明 を始めます。 「マップつくラボ」は、ポスター、広告、フライヤーに掲載する地図デザインを、実際の地図と入力パラメータを元に自動的 に作成するアプリケーションです。 アクセス元 （出典：最小権限実現への4ステップアプローチ 前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/ アクセス先 処理 参考
25. 24 Copyright（C） NRI Netcom, Ltd. All rights reserved. （参考） STEP1: 必要最小限の権限エリア（A）を把握する AWSが考える最小権限実現への4ステップアプローチ概略 アクセスレベルを定義して、「「マップつくラボ」システムで使用される必要最小の権限の一覧」（表1）を作成します。 表1 （出展：最小権限実現への4ステップアプローチ 前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/ 参考
26. 25 Copyright（C） NRI Netcom, Ltd. All rights reserved. （参考） STEP2: 受容できないビジネス影響を洗い出す AWSが考える最小権限実現への4ステップアプローチ概略 ユースケースに基づき、主な脅威とその対象となる主要機能、データ保管場所を洗い出し、ビジネス影響を確認しま す。データの機密性が最も重要等のいくつかの前提から「想定される脅威とビジネス影響一覧」（表2）を作成します。 表2 （出典：最小権限実現への4ステップアプローチ 前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/ 参考
27. 26 Copyright（C） NRI Netcom, Ltd. All rights reserved. （参考）最小権限実現への4ステップアプローチ（STEP1~3） AWSが考える最小権限実現への4ステップアプローチ概略 各ステップの概要を目次として見ていきます。 ◼ STEP1: 必要最小限の権限エリア（A）を把握する ➢ 表1：「マップつくラボ」システムで使用される必要最小の権限 架空のベンチャー企業が作成した地図画像を生成するシステム「マップつくラボ」を例に、システムで使用される必要最小の権限を 洗い出しています ◼ STEP2: 受容できないビジネス影響を洗い出す ➢ 表2：想定される脅威とビジネス影響一覧の例 「マップつくラボ」のユースケースに基づき、主な脅威とその対象となる主要機能、データ保管場所を洗い出し、ビジネス影響を「致 命的/局所的影響/受容可」の３段階で評価しています ◼ STEP3:受容できないビジネス影響をもたらしうる権限範囲（B）を把握する ➢ （表2 + アクセスレベル）表3-1：受容できない権限一覧 ➢ （表1 + 表3-1）表3-2：システム運用にリクエストされる必要最小の権限と悪用された場合のビジネス影響の一覧 「マップつくラボ」における受容できないリスクをもたらす権限をAWSアクセスレベルで「表3-1」として抽出しています。 「マップつくラボ」において、必要最小の権限が悪用された場合のビジネス影響一覧を「表3-2」として作成しています 参考・再掲
28. 27 Copyright（C） NRI Netcom, Ltd. All rights reserved. （参考） STEP3:受容できないビジネス影響をもたらしうる権限範囲（B）を把握する(3-1) AWSが考える最小権限実現への4ステップアプローチ概略 STEP2で作成した作成した受容できないリスクの一覧（表2）をAWSのアクセスレベルに変換して、 「受容できない権限の一覧」（表3-1）を作成します。 表3-1 （出典：最小権限実現への4ステップアプローチ 前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/ 表2 参考
29. 28 Copyright（C） NRI Netcom, Ltd. All rights reserved. （参考） STEP3:受容できないビジネス影響をもたらしうる権限範囲（B）を把握する(3-2) AWSが考える最小権限実現への4ステップアプローチ概略 「マップつくラボ」において、「必要最小の権限が悪用された場合のビジネス影響一覧」を作成します。 左側のアクセス元、アクション、アクセス先は表1から、右側のビジネス影響は表3-1からそれぞれ求めます。 表3-2 （出典：最小権限実現への4ステップアプローチ 前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/ 表3-1 表1 参考
30. 29 Copyright（C） NRI Netcom, Ltd. All rights reserved. 最小権限実現への4ステップアプローチ（STEP4 手法1~5） AWSが考える最小権限実現への4ステップアプローチ概略 STEP3で求めた受容できないビジネス影響をもたらしうる権限範囲（B）を制御する手法を４つ紹介しています。 STEP4: 受容できないビジネス影響をもたらしうる権限範囲（B）の統制メカニズムを選定する ⚫ 手法1 - 権限を条件で細かく制御する サンプルケース：開発者に割り当てるポリシーに条件を付与して制御できるようにします 例えば、VPC内にしかLambda環境をデプロイできないように、開発者のIAMユーザにVPC設定の条件キーを使用したポリシーをア タッチするといった制御です ⚫ 手法2 – データに対する人の直接アクセスを抑制する サンプルケース：人によるS3オブジェクト操作を抑制するメカニズム 例えば、S3オブジェクトの作成、更新、削除の作業はすべて所定の Lambda Function を経由するものとするといった制御です ⚫ 手法3 - 事前定義型の機能を使用する（AWS Control Tower による予防的ガードレール） AWS Control Towerによるガードレールの自動生成/暗号化/アカウント単位のAmazon S3パブリックアクセスブロック機能 /Amazon VPC内にリソースを集約したアクセス制御 ⚫ 手法4 - 権限の行使を監視する（発見的ガードレール） サンプルケースAmazon GuardDuty による多層的な監視メカニズム 例えば、Amazon GuardDutyを使用したS3 APIに対する不正アクセス監視です ⚫ 手法5 - 非準拠のリソースを自動修正する（訂正的統制） 例えば、AWS Config RulesによるAmazon S3のパブリック許可をもったバケットポリシーが検出されたら、一旦バケットポリシーを 全アクセス禁止の形式に上書きしてしまいます
31. 30 Copyright（C） NRI Netcom, Ltd. All rights reserved. 最適化された権限セット AWSが考える最小権限実現への4ステップアプローチ概略 受容できないビジ ネス影響をもたら しうる権限範囲 （B） <統制> （出典：最小権限実現への4ステップアプローチ 後編） https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp2/
32. 31 Copyright（C） NRI Netcom, Ltd. All rights reserved. 受容可能な最大権限の実現 AWSが考える最小権限実現への4ステップアプローチ概略 このように最小権限実現への4ステップアプローチを踏むことで、受容可能な最大権限を実現することができるという わけです。 STEP1：把握 STEP2：洗い出す STEP3：把握 STEP4：統制 （出典：最小権限実現への4ステップアプローチ 前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/
33. 32 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介＆本日の主題 01 AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン 02 AWSが考える最小権限実現への4ステップアプローチ概略 03 AWS IAM Identity Center の権限設計も考えてみる 04 Summary, References & Appendix 05
34. 33 Copyright（C） NRI Netcom, Ltd. All rights reserved. 用語② AWS IAM Identity Center の権限設計も考えてみる ◼ AWS Organizations ⚫ 複数のAWSアカウントを一元管理できる無料のAWSサービス ▪組織内のAWSアカウントの一元管理 ▪すべてのメンバーアカウントの一括請求 など ◼ マネジメントアカウント ⚫ AWS Organizations の管理に使用する AWSアカウント ⚫ AWS Organizations で発生した料金の支払いを行う ⚫ AWS Organizations 内のアカウント作成や管理 ◼ メンバーアカウント AWS Organizations の組織に所属する管理アカウント以外のアカウント Management account Member accounts AWS Organizations
35. 34 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAM Identity Center AWS IAM Identity Center の権限設計も考えてみる AWS IAM Identity Center は、組織内のAWSアカウントへのアクセスを一元管理できるサービスです。各AWSアカ ウントへのシングルサインオン（SSO）アクセスが可能になります。 AWS Organizations で作成された組織に対して有効化することができ、マルチアカウント管理において AWS IAM Identity Center はID管理を行うための重要な役割のサービスです。 マネジメントアカウントで利用することができ、機能の大半をメンバーアカウントへ委任して管理することもできます。 （出典：SSO プロバイダー - AWS IAM アイデンティティセンター）https://aws.amazon.com/jp/iam/identity-center/ AWS Organizations Management account Organizational unit Organizational unit Organizational unit Accounts Accounts AWS IAM Identity Center Accounts
36. 35 Copyright（C） NRI Netcom, Ltd. All rights reserved. IAM or AWS IAM Identity Center AWS IAM Identity Center の権限設計も考えてみる AWS IAM は各アカウントで作成して利用する一方で、AWS IAM Identity Center は組織内のAWSアカウントへ のアクセスを一元管理できるサービスです。 AWSでのセキュリティのベストプラクティスNo.1にもある通り、AWS IAM Identity Center 活用してフェデレーションの利 用を必須とすることを推奨します。 AWS Organizations Management account Organizational unit Organizational unit Organizational unit Accounts Accounts AWS IAM Identity Center Accounts Users Users Users Users Users Users Users Users Users
37. 36 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAM Identity Center の外部IDプロバイダー接続 AWS IAM Identity Center の権限設計も考えてみる AWS IAM Identity Center のID CenterディレクトリやActive DirectoryでID管理を行うことができますが、 Okta, Azure AD, OneLogin等の外部IDプロバイダーに接続してID管理することもできます。 外部ID プロバイダー （IdPs） 各AWSアカウント AWS利用者 認証情報の要求 認証情報の提供 IdPへログイン AWSアカウントへSSO AWS IAM Identity Center
38. 37 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAM Identity Center quotas観点の設計 AWS IAM Identity Center の権限設計も考えてみる AWS IAM Identity Center のクォータとして、AWSアカウント毎のプロビジョン権限セットの上限があります。デフォ ルト「250」で引き上げは可能なのですが、権限セットが多すぎても管理しきれないため、できる限りデフォルト上限内で 権限セットの作成することをお勧めします。 このクォータから考える設計としては、各アカウントへの権限セットをパターン化して、各アカウント個別の権限セットを なるべく作らないようにするのが良いかと思います。 例） AWSアカウント毎に個別の権限セットを10個作成した場合 20アカウント × 10権限セット = 200権限セット ↓ これが30アカウントに増えた場合 30アカウント × 10権限セット = 300権限セット （出典：AWS IAM Identity Center quotas – 2024/5/18時点） https://docs.aws.amazon.com/singlesignon/latest/userguide/limits.html デフォルトのクォータを超えてしまう
39. 38 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAM Identity Center 権限委任観点の設計 AWS IAM Identity Center の権限設計も考えてみる AWS IAM Identity Center の管理権限をマネジメントアカウントから、以下の機能以外の管理をメンバーアカウン トに委任することができます。 ⚫ AWS IAM Identity Center を有効にする ⚫ AWS IAM Identity Center の設定を削除する ⚫ マネジメントアカウントにプロビジョニングされた権限セットの管理 ⚫ 他のメンバーアカウントを委任管理者として登録または登録解除する ⚫ マネジメントアカウントでのユーザアクセスの有効化または無効化 この場合、マネジメントアカウントにプロビジョニングされた権限セットの 管理を、委任された AWS IAM Identity Center 用のAWSアカウント から管理することができません。 そのため、マネジメントアカウント用/メンバーアカウント用の権限セットを 分けて作成および管理する必要があります。 （出典：AWS IAM Identity Center における許可セットの管理とアカウント割り当ての委任） https://aws.amazon.com/jp/blogs/news/delegating-permission-set-management-and-account-assignment-in-aws-iam-identity-center/ （出典：委任された管理）https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/delegated-admin.html マネジメントアカウント用権限セット メンバーアカウント用権限セット
40. 39 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAM でのセキュリティのアンチパターン観点の設計 AWS IAM Identity Center の権限設計も考えてみる AWS IAM でのセキュリティのアンチパターンは、AWS IAM Identity Center においても同じことが言えます。アンチパ ターンが発生しない設計を意識できるようにしましょう。 AWS IAMでのセキュリティのアンチパターン ① • 長期的な認証情報のみを利用する（AWSアカウント間のアクセスの委任にIAMロールを利用しない） • 長期的な認証情報を必要とするユースケースでアクセスキーを更新しない →AWS IAM Identity Center の機能により、一時的な認証情報を利用しましょう！ ② • IAMユーザに多要素認証 (MFA) を利用しない →AWS IAM Identity Center の機能でユーザに多要素認証（MFA）を利用しましょう！ ③ • ルートユーザーの認証情報を保護するためのベストプラクティスに従わない （ルートユーザの常用、アクセスキー作成、MFA未設定、未承認利用等） →AWS IAM Identity Center とは関連無いため除外 ④ • 最小特権ではない（不要な）アクセス許可を適用する • AWS 管理ポリシーを利用しない（インラインポリシーを利用する、AWSマネージドポリシーのみを利用する） →最小特権のアクセス許可を適用して、グループとAWS管理ポリシーを利用しましょう！ ⑤ • 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認しない（棚卸しない） →AWS IAM Identity Center のユーザー、グループ、権限セット、ポリシーを定期的に確認（棚卸）しましょう！ ⑥ • IAM Access Analyzer を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない →IAM Access Analyzer を使用する場合は、AWS IAM Identity Centerで作成されるIAMロールはアーカイブルールで除外
41. 40 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介＆本日の主題 01 AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン 02 AWSが考える最小権限実現への4ステップアプローチ概略 03 AWS IAM Identity Center の権限設計も考えてみる 04 Summary, References & Appendix 05
42. 41 Copyright（C） NRI Netcom, Ltd. All rights reserved. Summary (1) IAMでのセキュリティのベストプラクティスから考えるアンチパターン Summary, References & Appendix ⚫AWS IAMでのセキュリティベストプラクティスを見てみる →AWS IAMでのセキュリティベストプラクティスを適用しないケースを考える →類似するケースをまとめると、６つのAWS IAMでのセキュリティのアンチパターンが考えられる AWS IAMでのセキュリティのアンチパターン ① • 長期的な認証情報のみを利用する（AWSアカウント間のアクセスの委任にIAMロールを利用しない） • 長期的な認証情報を必要とするユースケースでアクセスキーを更新しない ② • IAMユーザに多要素認証 (MFA) を利用しない ③ • ルートユーザーの認証情報を保護するためのベストプラクティスに従わない （ルートユーザの常用、アクセスキー作成、MFA未設定、未承認利用等） ④ • 最小権限ではない（不要な）アクセス許可を適用する • AWS 管理ポリシーを利用しない（インラインポリシーを利用する、AWSマネージドポリシーのみを利用する） ⑤ • 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認しない（棚卸しない） ⑥ • IAM Access Analyzer を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない
43. 42 Copyright（C） NRI Netcom, Ltd. All rights reserved. Summary (2) AWSが考える最小権限実現への4ステップアプローチ概略 Summary, References & Appendix ⚫STEP1: 必要最小限の権限エリア（A）を把握する ⚫STEP2: 受容できないビジネス影響を洗い出す ⚫STEP3:受容できないビジネス影響をもたらしうる権限範囲（B）を把握する ⚫STEP4: 受容できないビジネス影響をもたらしうる権限範囲（B）の統制メカニズムを選定する STEP1：把握 STEP2：洗い出す STEP3：把握 STEP4：統制 （出典：最小権限実現への4ステップアプローチ 前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/
44. 43 Copyright（C） NRI Netcom, Ltd. All rights reserved. Summary (3) AWS IAM Identity Center の権限設計も考えてみる Summary, References & Appendix ⚫AWS IAM Identity Center 権限委任観点から考えてみる ⚫AWS IAM Identity Center quotas観点から考えてみる ⚫AWS IAMでのセキュリティのアンチパターンは、AWS IAM Identity Centerにも当てはまる AWS IAMでのセキュリティのアンチパターン ① • 長期的な認証情報のみを利用する（AWSアカウント間のアクセスの委任にIAMロールを利用しない） • 長期的な認証情報を必要とするユースケースでアクセスキーを更新しない →AWS IAM Identity Center の機能により、一時的な認証情報を利用しましょう！ ② • IAMユーザに多要素認証 (MFA) を利用しない →AWS IAM Identity Center の機能でユーザに多要素認証（MFA）を利用しましょう！ ③ • ルートユーザーの認証情報を保護するためのベストプラクティスに従わない （ルートユーザの常用、アクセスキー作成、MFA未設定、未承認利用等） →AWS IAM Identity Center とは関連無いため除外 ④ • 最小特権ではない（不要な）アクセス許可を適用する • AWS 管理ポリシーを利用しない（インラインポリシーを利用する、AWSマネージドポリシーのみを利用する） →最小特権のアクセス許可を適用して、グループとAWS管理ポリシーを利用しましょう！ ⑤ • 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認しない（棚卸しない） →AWS IAM Identity Center のユーザー、グループ、権限セット、ポリシーを定期的に確認（棚卸）しましょう！ ⑥ • IAM Access Analyzer を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない →IAM Access Analyzer を使用する場合は、AWS IAM Identity Centerで作成されるIAMロールはアーカイブルールで除外
45. 44 Copyright（C） NRI Netcom, Ltd. All rights reserved. References Summary, References & Appendix ◼ IAMのベストプラクティス ⚫ IAM でのセキュリティのベストプラクティス https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html ⚫ AWS アカウントのルートユーザーのベストプラクティス https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/root-user-best-practices.html ◼ 最小権限実現への4ステップアプローチ ⚫ 最小権限実現への4ステップアプローチ 前編 https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/ ⚫ 最小権限実現への4ステップアプローチ 後編 https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp2/ ◼ AWS IAM Identity Center ⚫ SSO プロバイダー - AWS IAM アイデンティティセンター https://aws.amazon.com/jp/iam/identity-center/ ⚫ AWS IAM Identity Center における許可セットの管理とアカウント割り当ての委任 https://aws.amazon.com/jp/blogs/news/delegating-permission-set-management-and-account- assignment-in-aws-iam-identity-center/ ⚫ 委任された管理 https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/delegated-admin.html ⚫ AWS IAM Identity Center quotas https://docs.aws.amazon.com/singlesignon/latest/userguide/limits.html
46. 45 Copyright（C） NRI Netcom, Ltd. All rights reserved. References（Others） Summary, References & Appendix ◼AWSの薄い本 IAMのマニアックな話 https://booth.pm/ja/items/1563844
47. 46 Copyright（C） NRI Netcom, Ltd. All rights reserved. Appendix Summary, References & Appendix 全IAM資料の参考文献となる資料を AWS Summit で拝見しました。 https://x.com/htan02303749/status/1804285075707851123
48. 47 Copyright（C） NRI Netcom, Ltd. All rights reserved. JAWS PANKRATION 2024 Summary, References & Appendix 今回のAWS IAMのアンチパターンの話で、JAWS PANKRATION 2024 に登壇することになりました。(深夜12時枠) JAWS PANKRATION 2024は主催JAWS-UGで行われる3度目の24時間オンラインイベントです。全国のJAWS-UG支部 だけでなく、世界中のAWS HERO、AWS Community Builder、AWS User Group Leader、その他AWSタイトルホルダー に、AWS内の方を招待して、各国のAWSに関するカルチャーやAWSに関するテクニカルトークなど様々なセッションが開 催されます。 https://jawspankration2024.jaws-ug.jp/ja/