AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略

もうすぐAWS Summit Japan 2024！改めて考える AWS Identity and Access Management（IAM）のアンチパターン/AWSが考える最低権限実現への
アプローチ概略～AWS IAM Identity Center の権限設計も考えてみる～ 2024年6月18日 NRIネットコム株式会社クラウド事業推進部丹勇人 NRIネットコム TECH & DESIGN STUDY #34

1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します #nncstudy
自己紹介＆本日の主題 01 AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン 02 AWSが考える最小権限実現への4ステップアプローチ概略 03 AWS IAM Identity Center の権限設計も考えてみる 04 Summary, References & Appendix 05

2 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します丹
勇人（たんはやと）自己紹介&本日の主題 ◼ NRIネットコム株式会社現在クラウド事業推進部所属 ◼ 2022 APN AWS Top Engineer（Service） ◼ AWS Community Builder（Security） since 2023 ◼ AWS認定「AWS認定Data Engineer - Associate」以外の12個 ◼ 直近のプロジェクト ⚫ AWS環境の構築・運用支援 ⚫ AWSマルチアカウント環境の組織管理・運用支援 ⚫ AWSアカウント管理（請求代行）、技術サポート ◼ その他プロフィール ⚫ 秋田県出身→福島県→東京都大田区→埼玉県 ⚫ 子供５人（育休ブログ、TECHブログ書いてます）

本日の主題自己紹介&本日の主題 ◼本日お話すること ⚫AWS IAMでのセキュリティのベストプラクティス/アンチパターン ⚫最小権限実現へのステップアプローチ ⚫AWS IAM Identity Centerの権限設計 ◼本日お話しないこと ⚫AWS IAM の基礎 ⚫AWS Elastic Compute Cloud（EC2）等のその他AWSサービス詳細 ⚫AWS re:Inforce 2024 の話 … 1billion API calls per second worldwide

用語① 自己紹介&本日の主題 ◼ ルートユーザー 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

AWS IAM の管理は簡単？ AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン A. いいえ。難しいです。 • 増えるユーザ数 • 権限を与えすぎて起きる操作ミス • 権限を絞りすぎると落ちる開発スピード • 認証情報の漏洩による情報流出…etc. これらの課題に対処しながら IAMユーザ/グループ/ポリシー管理やルートユーザ、アクセスキー等の認証情報の管理が必要になります。

AWS Identity and Access Management（IAM）を上手く管理できていますか？

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でのセキュリティのアンチパターン６パターン

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）を利用して、アカウント内のアクセス許可の管理を委任する

AWS IAMでのセキュリティのベストプラクティスを適用しないケース AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン IAMでのセキュリティのベストプラクティスを適用しない場合にどういった対応を取るか、というのを考えてみます。 No. AWS IAMでのセキュリティのベストプラクティスを適用しないケース 1 （IDプロバイダーとのフェデレーションを使用できない場合もある）※今回は割愛 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）を利用しない場合もある）※今回は割愛

AWS IAMでのセキュリティのアンチパターン AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン IAMでのセキュリティのベストプラクティスを適用しないケースの内、類似しているケースをまとめて、AWS IAMでのセキュリティのアンチパターンを６パターンに分類しました。 AWS IAMでのセキュリティのアンチパターン ① • 長期的な認証情報のみを利用する（AWSアカウント間のアクセスの委任にIAMロールを利用しない） • 長期的な認証情報を必要とするユースケースでアクセスキーを更新しない ② • IAMユーザに多要素認証 (MFA) を利用しない ③ • ルートユーザーの認証情報を保護するためのベストプラクティスに従わない（ルートユーザの常用、アクセスキー作成、MFA未設定、未承認利用等） ④ • 最小権限ではない（不要な）アクセス許可を適用する • AWS 管理ポリシーを利用しない（インラインポリシーを利用する、AWSマネージドポリシーのみを利用する） ⑤ • 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認しない（棚卸しない） ⑥ • IAM Access Analyzer を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない

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ステップアプローチ前編/後編を出展として、本ページ以降でブログの一部を掲載します

はじめに AWSが考える最小権限実現への4ステップアプローチ概略 IAMでのセキュリティのベストプラクティスとして掲げられているのが、最小権限の原則（No.6,7）です。「最小権限を適切に運用する」ことを計画します。 ⚫ システムの運用や開発の視点で「必要」となる操作の権限のみを人やアプリケーションに付与する ➢ 「必要だから」と過剰に権限を付与→操作ミスが発生 ⚫ 「リスクを考慮して受容」できる範囲内に絞って「必要最小」の権限を人やアプリケーションに付与する ➢ 「少しでも危なそうな機能を使わない」とのスタンスから使いたい機能を禁止→必要な操作ができない受容可能なリスクの算出は、システム開発・運用の現場には荷の重いテーマなだけに、検討がおざなりになって、上記のような権限設定をしてしまうことがあります。 User User

受容可能な最大権限とは 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/

最小権限実現への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/

STEP1: 必要最小限の権限エリア（A）を把握する AWSが考える最小権限実現への4ステップアプローチ概略架空のベンチャー企業が作成した地図画像を生成するシステム「マップつくラボ」を例に、具体的なアプローチの説明を始めます。「マップつくラボ」は、ポスター、広告、フライヤーに掲載する地図デザインを、実際の地図と入力パラメータを元に自動的に作成するアプリケーションです。アクセス元（出典：最小権限実現への4ステップアプローチ前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/

STEP1: 必要最小限の権限エリア（A）を把握する AWSが考える最小権限実現への4ステップアプローチ概略アクセスレベルを定義して、「「マップつくラボ」システムで使用される必要最小の権限の一覧」（表1）を作成します。表1 （出展：最小権限実現への4ステップアプローチ前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/

STEP2: 受容できないビジネス影響を洗い出す AWSが考える最小権限実現への4ステップアプローチ概略ユースケースに基づき、主な脅威とその対象となる主要機能、データ保管場所を洗い出し、ビジネス影響を確認します。データの機密性が最も重要等のいくつかの前提から「想定される脅威とビジネス影響一覧」（表2）を作成します。表2 （出典：最小権限実現への4ステップアプローチ前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/

最小権限実現への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」として作成しています再掲

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/

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/

最小権限実現への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のパブリック許可をもったバケットポリシーが検出されたら、一旦バケットポリシーを全アクセス禁止の形式に上書きしてしまいます

最適化された権限セット AWSが考える最小権限実現への4ステップアプローチ概略受容できないビジネス影響をもたらしうる権限範囲（B） <統制> （出典：最小権限実現への4ステップアプローチ後編） https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp2/

受容可能な最大権限の実現 AWSが考える最小権限実現への4ステップアプローチ概略このように最小権限実現への4ステップアプローチを踏むことで、受容可能な最大権限を実現することができるというわけです。 STEP1：把握 STEP2：洗い出す STEP3：把握 STEP4：統制（出典：最小権限実現への4ステップアプローチ前編）https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/

用語② AWS IAM Identity Center の権限設計も考えてみる ◼ AWS Organizations ⚫ 複数のAWSアカウントを一元管理できる無料のAWSサービス ▪組織内のAWSアカウントの一元管理 ▪すべてのメンバーアカウントの一括請求など ◼ マネジメントアカウント ⚫ AWS Organizations の管理に使用する AWSアカウント ⚫ AWS Organizations で発生した料金の支払いを行う ⚫ AWS Organizations 内のアカウント作成や管理 ◼ メンバーアカウント AWS Organizations の組織に所属する管理アカウント以外のアカウント Management account Member accounts AWS Organizations

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

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

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 マネジメントアカウント用権限セットメンバーアカウント用権限セット

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 デフォルトのクォータを超えてしまう

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ロールはアーカイブルールで除外

Summary (1) IAMでのセキュリティのベストプラクティスから考えるアンチパターン Summary, References & Appendix ⚫AWS IAMでのセキュリティベストプラクティスを見てみる →AWS IAMでのセキュリティベストプラクティスを適用しないケースを考える →類似するケースをまとめると、６つのAWS IAMでのセキュリティのアンチパターンが考えられる AWS IAMでのセキュリティのアンチパターン ① • 長期的な認証情報のみを利用する（AWSアカウント間のアクセスの委任にIAMロールを利用しない） • 長期的な認証情報を必要とするユースケースでアクセスキーを更新しない ② • IAMユーザに多要素認証 (MFA) を利用しない ③ • ルートユーザーの認証情報を保護するためのベストプラクティスに従わない（ルートユーザの常用、アクセスキー作成、MFA未設定、未承認利用等） ④ • 最小権限ではない（不要な）アクセス許可を適用する • AWS 管理ポリシーを利用しない（インラインポリシーを利用する、AWSマネージドポリシーのみを利用する） ⑤ • 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認しない（棚卸しない） ⑥ • IAM Access Analyzer を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない

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/

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ロールはアーカイブルールで除外

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

References（Others） Summary, References & Appendix ◼AWSの薄い本 IAMのマニアックな話 https://booth.pm/ja/items/1563844

（参考）AWS IAMでのセキュリティのベストプラクティスを適用しないケース（No.1~3）（Appendix）AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン ◼ <No.1>人間のユーザーが一時的な認証情報を使用して AWS にアクセスする場合に ID プロバイダーとのフェデレーションを使用することを必須とする ➢ （IDプロバイダーとのフェデレーションを使用できない場合もある）※今回は割愛 ◼ <No.2>ワークロードが AWS にアクセスする場合に IAM ロールで一時的な資格情報を使用することを必須とする ➢ 長期的な認証情報のみを利用する（AWSアカウント間のアクセスの委任にIAMロールを利用しない） AWSアカウント間のアクセスの委任にIAMロールを利用しないで、アクセスキー（シークレットキー）を常用すると、アクセスキー情報が漏洩して悪意のある第三者に認証情報を利用される可能性があります。 ◼ <No.3>多要素認証 (MFA) を必須とする ➢ IAMユーザーに多要素認証 (MFA) を利用しない IAMユーザーにMFAを利用しない場合、AWSへのログインをパスワードのみで守る形となり、パスワードを第三者に知られることで不正にアクセスされる可能性があります。危険危険

（参考） AWS IAMでのセキュリティのベストプラクティスを適用しないケース（No.4~6）（Appendix）AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン ◼ <No.4>長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する ➢ 長期的な認証情報を必要とするユースケースでアクセスキーを更新しない原則アクセスキーを利用しないことをお勧めしますが、アプリケーションからのアクセス等にアクセスキーを利用するケースがあります。この場合に、アクセスキーを更新しないと、アクセスキーが漏洩した際に第三者が認証情報を利用し続けてしまいます。 ◼ <No.5>ルートユーザーの認証情報を保護するためのベストプラクティスに沿う ➢ ルートユーザーの認証情報を保護するためのベストプラクティスに従わない（ルートユーザの常用、アクセスキー作成、MFA未設定、未承認利用等）ルートユーザーは管理者権限であるため、原則権限を絞ることができません。ルートユーザーを常用したり、ルートユーザーのアクセスキーを作成、MFA未設定、承認無しで利用することは、ルートユーザーの情報が漏洩する危険性につながります。 ◼ <No.6>最小権限アクセス許可を適用する ➢ 最小権限ではない（不要な）アクセス許可を適用する「必要だから」と過剰に権限を付与してしまい、操作ミスが起きる可能性があります。一方で、「少しでも危なそうな機能を使わない」とのスタンスから使いたい機能を禁止すると、必要な操作もできなくなってしまいます。危険

（参考） AWS IAMでのセキュリティのベストプラクティスを適用しないケース（No.7~9）（Appendix）AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン ◼ <No.7>AWS管理ポリシー（およびカスタマー管理ポリシー）の利用を開始し、最小特権のアクセス許可に移行する ➢ AWS管理ポリシーおよびカスタマー管理ポリシーを利用しない（インラインポリシーのみを利用、AWSマネージドポリシーのみを利用する） AWS管理ポリシーを利用することで最小権限に絞り込むことができます。 IAMユーザーに直接付与可能なインラインポリシーばかりを利用しているとユーザー増加に伴い管理しきれなくなり、不要なアクセス許可が残ってしまう可能性があります。また、AWSが用意するAWSマネージドポリシーは便利であるものの、各アカウントやユーザーの利用用途に沿った最小権限ではないため、AWSマネージドポリシーのみを利用することは不要なアクセス許可をユーザーに与えることになります。 ◼ <No.8>IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する ➢ 最小権限ではない（不要な）アクセス許可を適用したIAMポリシーを生成する（No.6と類似）※今回は割愛 ◼ <No.9>未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認して削除する ➢ 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認しない（棚卸しない） IAMの棚卸をしないと、退職者やプロジェクトから離れた職員からの認証情報漏洩、不要になったロールの不正利用、無駄なアクセス許可やポリシーによる操作ミス等の危険性が高まります。危険

（参考） AWS IAMでのセキュリティのベストプラクティスを適用しないケース（No.10~14）（Appendix）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）を利用しない場合もある） ※今回は割愛危険

Appendix Summary, References & Appendix Amazon Elastic Compute Cloud（EC2）にアタッチされているIAMロールの認証情報が攻撃者によって盗まれると、攻撃者は外部から EC2 インスタンスにアタッチされている IAM ロールの権限で API コールを実施することができてしまい、大きなセキュリティリスクとなります。認証情報の漏洩対策 - [3] IMDSv2によるSSRF攻撃の防御により、先に取得したセッショントークンが必要となり、攻撃が成立するための条件が厳しくなります。 ※IMDSv2の利用により、攻撃が成立するための条件が厳しくなりますが、多層での防御を推奨します（出典：Amazon EC2認証情報の漏洩対策）https://aws.amazon.com/jp/builders-flash/202305/compromise-prevention-ec2-auth/ ◼典型的な攻撃の例（IMDSv1の場合） ◼Amazon EC2認証情報の漏洩対策のまとめ

44 Copyright（C） NRI Netcom, Ltd. All rights reserved. NRIネットコム株式会社も“AWS Summit
Japan 2024”でブース出展します！ NRIネットコム株式会社は、“AWS Summit Japan 2024”に「Silver Sponsor」として出展します。当社ブースでは、お客様のクラウド活用をサポートした事例に加え、AWSを学ぶためのヒントも展示する予定です。 ◼ブース出展出展ブース：ブースID「H5-S094」出展期間：6月20日（木）～ 21日（金） ◼セッション登壇登壇日時：6月21日（金）12:30～12:45 会場：パートナーシアターA（セッションID：PT-21A）ぜひ、NRIネットコム株式会社の展示ブースへお越しください！！

AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略

AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略

More Decks by Hayato Tan

Other Decks in Technology

Featured

Transcript