AWS IAM のアンチパターンとAWSが考える”最小権限実現へのアプローチ”概略解説～AWS IAM Identity Center の活用を検討してみましょう～

2024年8月2日 AWS IAM のアンチパターンとAWSが考える ”最小権限実現へのアプローチ”概略解説～AWS IAM Identity Center の活用を検討してみましょう～
NRIネットコム株式会社クラウド事業推進部丹勇人

1 Copyright（C） NRI Netcom, Ltd. All rights reserved. NRIネットコムの紹介 01
AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン 02 AWSが考える最小権限実現への4ステップアプローチ概略 03 AWS IAM Identity Center の活用と効果 04 NRIネットコムのAWS請求代行＆アカウント管理サービス 05

2 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介 ◼
2015年 4月 NRIネットコム株式会社入社 ◼ 現在クラウド事業推進部主任 ◼ AWS環境のサーバ、ネットワーク等の運用を実施 ◼ AWS環境の構築・運用支援 ◼ AWSマルチアカウント環境の組織管理・運用支援 ◼ AWSアカウント管理（請求代行）、技術サポート ◼ 2024 Japan AWS Ambassadors（Associate Ambassador） ◼ 2024 Japan AWS Top Engineers (Security) ◼ AWS Community Builders（Security）since 2023 ◼ 2022 APN AWS Top Engineers（Services） ◼ AWS認定 ⚫ 2024 Japan All AWS Certifications Engineers 丹勇人（たんはやと） ◼ Webシステム ⚫ 不動産会社Webシステムリニューアル対応 ⚫ 大手流通会社のWebシステム運用、テスト推進支援 ◼ モバイル ⚫ 自社ソリューション「モバイル会議」の基盤開発、運用 ◼ クラウド ⚫ AWSアカウントセキュリティ設定 ⚫ AWSアカウントの組織管理、技術サポート ⚫ 大手サービス業向けデータレイク基盤の立案・構築 ⚫ ファイルサーバ・静的Webサイト構築 ⚫ AWSを利用したデータ分析基盤構築講座 ⚫ AWS導入・活用トレーニング講座（サーバーレス） ⚫ AWS構築運用作業支援

5 Copyright（C） NRI Netcom, Ltd. All rights reserved. NRIネットコムのAWSへの取り組み NRIネットコムの紹介
APNアドバンスドコンサルティングパートナー書籍執筆&ブログ執筆対外発表の推進複数のAWS Awards受賞者と多数のAWS認定者資格

6 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2. AWS
IAMでのセキュリティのベストプラクティスから考えるアンチパターン

7 Copyright（C） NRI Netcom, Ltd. All rights reserved. 用語① AWS
IAMでのセキュリティのベストプラクティスから考えるアンチパターン ◼ ルートユーザー 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

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

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

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の棚卸をしないと、退職者やプロジェクトから離れた職員からの認証情報漏洩、不要になったロールの不正利用、無駄なアクセス許可やポリシーによる操作ミス等の危険性が高まります。危険参考

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）を利用しない場合もある） ※今回は割愛危険参考

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

22 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 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 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 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 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 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/ 再掲

28 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 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 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 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 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 Copyright（C） NRI Netcom, Ltd. All rights reserved. 4. AWS
IAM Identity Center の活用と効果

34 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

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 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

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

Identity Center quotas観点の設計 AWS IAM Identity Center の活用と効果 AWS IAM Identity Center のクォータとして、権限セットの上限があります。デフォルト「2,000」で引き上げは可能なのですが、権限セットが多すぎても管理しきれないため、できる限りデフォルト上限内で権限セットの作成することをお勧めします。このクォータから考える設計としては、各アカウントへの権限セットをパターン化して、各アカウント個別の権限セットをなるべく作らないようにするのが良いかと思います。例） AWSアカウント毎に個別の権限セットを10個作成した場合 100アカウント × 15権限セット = 1,500権限セット ↓ これが150アカウントに増えた場合 150アカウント × 15権限セット = 2,250権限セット（出典：AWS IAM Identity Center quotas – 2024/7/28時点） https://docs.aws.amazon.com/singlesignon/latest/userguide/limits.html デフォルトのクォータを超えてしまう参考

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 の活用と効果 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ロールはアーカイブルールで除外

42 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 を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない

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/

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

46 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS請求代行＆AWSアカウント管理サービス NRIネットコムのAWS請求代行＆AWSアカウント管理サービスは、
AWS IAM Identity Center が利用可能です。さらに割引価格でAWSをご利用いただけるお得なサービスです。 NRIネットコムのAWS請求代行＆AWSアカウント管理サービスは、単純な請求代行だけでなく、AWS利用のコストダウンコンサルティングや、セキュリティ向上に役立つテンプレートをご提供するなど、かゆい所に手が届くサービスです。豊富なナレッジを持つメンバーがお客様の状況を丁寧に伺い、適切な管理方法をご提案しています。もちろん、すでにAWSのアカウントをお持ちのお客様もご利用いただけます。

47 Copyright（C） NRI Netcom, Ltd. All rights reserved. カスタマイズも可能です AWS
Organizations マネジメントアカウントお客様OU Amazon S3 • CloudTrail Logs • Config Logs Log Archive Audit AWS Config Aggregator Amazon SNS Security OU AWS Control Tower AWS IAM Identity Center お客様 Management OU SSO AWS IAM Identity Center マネジメントアカウントは以下一部の権限のみ • アカウント作成 • Control Towerガードレール設定 • SCP設定請求情報の管理や、マネジメントアカウントのアクセス管理はNRIネットコムにて実施 Amazon GuardDuty AWS Config AWS Security Hub IAM Access Analyzer Amazon SNS サービスイメージ AWS IAM Identity Center（AWS SSOの後継）やAWS Control Tower も利用可能です AWS CloudTrail NRIネットコム

48 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS Organizations対応の請求代行プラン
NRIネットコムでは、AWS Organizations対応の請求代行プランを用意しています。共用プラン専有プラン AWS Organizations お客様管理他のお客様利用組織ユニットで完全に分離組織ユニット組織ルート NRIネットコム管理アカウント AWS Cloud アカウント AWS Cloud 組織ユニットアカウント AWS Cloud アカウント AWS Cloud AWS Organizations お客様管理お客様で組織を専有組織ユニット組織ルートアカウント AWS Cloud アカウント AWS Cloud 組織ユニットアカウント AWS Cloud アカウント AWS Cloud サービスイメージ NRIネットコム管理

49 Copyright（C） NRI Netcom, Ltd. All rights reserved. マルチアカウントの管理＆セキュリティ・ガバナンス強化 NRIネットコムの請求代行プランを利用することにより、
セキュリティ・ガバナンスの初期設定が可能となります。サービスイメージ Management account Account 本番環境検証環境 SCP SCP AWS CloudFormation StackSets 提供＆管理 AWS Organizations 環境ごとにグループを分け、それぞれにベースとなるポリシーを適用するサービスコントロールポリシー（SCP）を適用することで、アカウント全体に対しての権限の統制が可能 AWS Organizations、AWS CloudFormation StackSetsを利用して、AWSアカウントに対して一括でセキュリティ・ガバナンス設定標準設計のテンプレートをネットコムから配布 AWS Organizations AWS Organizations NRIネットコム Account Account

50 Copyright（C） NRI Netcom, Ltd. All rights reserved. コスト削減コンサルティングさらに定期的にコスト削減コンサルティングの利用が可能です。
サービスイメージ年間の使用状況を確認して、最適なサーバーの種類やプラン等をご提案いたしますコスト削減施策※ が有効なケース ※リザーブドインスタンスまたは Savings Plans ・毎月常時稼働している本番環境等・停止時間が長くない場合コスト削減施策※ が有効なケース ※スポットインスタンス・処理が中断しても再開可能なサービス・機械学習のモデル作成など一時的な並列計算が必要な場合常時稼働分の利用料を割引きできる利用時間月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 720時間年単位の契約でインスタンスを購入する利用環境によっては、最大 72% 割引 Ex. 1 Ex. 2 AWS 側のリソース供給量とそれに対する需要によって価格が決まる場合によっては、最大 90% 割引オンデマンド固定価格スポットインスタンス変動価格 ※需給の状況によっては、インスタンスが中断される

51 Copyright（C） NRI Netcom, Ltd. All rights reserved. 複数アカウントの請求を一元管理・最適化ルールに基づいて請求書を発行し、事務コストの削減に寄与します。
⚫ アカウント単位での請求の集計 ⚫ リザーブドインスタンスの購入など全体での最適化 ⚫ 必要に応じてAWSアカウント内で、プロジェクト単位での明細化、部門間の請求調整サービスイメージタグC タグC タグA タグB タグC インスタンス／その他課金ログ保存課金ログ NRIネットコム請求書請求データ明細作成貴社貴社ご担当者様ネットコム担当者アカウントアカウントアカウント集計システム ※請求書を複数枚発行が必要な場合は、別途手数料を頂きます。

AWS IAM のアンチパターンとAWSが考える”最小権限実現へのアプローチ”概略解説～AWS...

AWS IAM のアンチパターンとAWSが考える”最小権限実現へのアプローチ”概略解説～AWS IAM Identity Center の活用を検討してみましょう～

More Decks by NRI Netcom

Other Decks in Technology

Featured

Transcript