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

Transcript

1. 2024年8月2日 AWS IAM のアンチパターンとAWSが考える ”最小権限実現へのアプローチ”概略解説 ～AWS IAM Identity Center の活用を検討してみましょう～ NRIネットコム株式会社 クラウド事業推進部 丹 勇人
2. 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
3. 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構築運用作業支援
4. 3 Copyright（C） NRI Netcom, Ltd. All rights reserved. 1. NRIネットコムの紹介
5. 4 Copyright（C） NRI Netcom, Ltd. All rights reserved. システム開発、クラウド構築から、デジタルマーケティング、Webサイト構築まで幅広い事業領域 NRIネットコムの紹介
6. 5 Copyright（C） NRI Netcom, Ltd. All rights reserved. NRIネットコムのAWSへの取り組み NRIネットコムの紹介 APNアドバンスド コンサルティングパートナー 書籍執筆&ブログ執筆 対外発表の推進 複数のAWS Awards受賞者と 多数のAWS認定者資格
7. 6 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2. AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン
8. 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
9. 8 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAM の管理は簡単？ AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン A. いいえ、難しいです。 …etc. これらの課題に対処しながら、 IAMユーザ/グループ/ポリシー管理や ルートユーザ、アクセスキー等の認証情報の管理が必要になります。 増えるユーザ数 権限を与えすぎて起きる操作ミス 権限を絞りすぎると落ちるスピード 認証情報の漏洩による情報流出 User User Users Users Users Users Users Users ・・・
10. 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でのセキュリティのアンチパターン ６パターン
11. 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）を利用して、アカウント内のアクセス許可の管理を委任する
12. 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）を利用しな い場合もある）
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でのセキュリティのベストプラクティスから考えるアンチパターン 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）を利用しない場合もある）※今回は割愛
15. 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 を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない
16. 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へのログインをパスワードのみで認証する形となり、パスワードを第三者に知られること で不正にアクセスされる可能性があります。 危険 危険 参考
17. 16 Copyright（C） NRI Netcom, Ltd. All rights reserved. （参考） AWS IAMでのセキュリティのベストプラクティスを適用しないケース（No.4~6） AWS IAMでのセキュリティのベストプラクティスから考えるアンチパターン ◼ <No.4>長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する ➢ 長期的な認証情報を必要とするユースケースでアクセスキーを更新しない 原則アクセスキーを利用しないことをお勧めしますが、アプリケーションからのアクセス等にアクセスキーを利用するケースがあります。こ の場合に、アクセスキーを更新しないと、アクセスキーが漏洩した際に第三者が認証情報を利用し続けてしまいます。 ◼ <No.5>ルートユーザーの認証情報を保護するためのベストプラクティスに沿う ➢ ルートユーザーの認証情報を保護するためのベストプラクティスに従わない（ルートユーザの常用、アクセスキー作成、MFA未 設定、未承認利用等） ルートユーザーは管理者権限であるため、原則権限を絞ることができません。ルートユーザーを常用したり、ルートユーザーのアクセス キーを作成、MFA未設定、承認無しで利用することは、ルートユーザーの情報が漏洩する危険性につながります。 ◼ <No.6>最小権限アクセス許可を適用する ➢ 最小権限ではない（不要な）アクセス許可を適用する 「必要だから」と過剰に権限を付与してしまい、操作ミスが起きる可能性があります。 一方で、「少しでも危なそうな機能を使わない」とのスタンスから使いたい機能を禁止すると、必要な操作もできなくなってしまいま す。 危険 参考
18. 17 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の棚卸をしないと、退職者やプロジェクトから離れた職員からの認証情報漏洩、不要になったロールの不正利用、無駄なア クセス許可やポリシーによる操作ミス等の危険性が高まります。 危険 参考
19. 18 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）を利用しない場合もある） ※今回は割愛 危険 参考
20. 19 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3. AWSが考える最小権限実現への4ステップアプローチ概略
21. 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ステップアプローチ 前編/後編を出展として、本ページ以降でブログの一部を掲載します
22. 21 Copyright（C） NRI Netcom, Ltd. All rights reserved. はじめに AWSが考える最小権限実現への4ステップアプローチ概略 IAMでのセキュリティのベストプラクティスとして掲げられているのが、最小権限の原則（No.6,7）です。 「最小権限を適切に運用する」ことを計画します。 ⚫ システムの運用や開発の視点で「必要」となる操作の権限のみを人やアプリケーションに付与する ➢ 「必要だから」と過剰に権限を付与→操作ミスが発生 ⚫ 「リスクを考慮して受容」できる範囲内に絞って「必要最小」の権限を人やアプリケーションに付与する ➢ 「少しでも危なそうな機能を使わない」とのスタンスから使いたい機能を禁止→必要な操作ができない 受容可能なリスクの算出は、システム開発・運用の現場には荷の重いテーマなだけに、検討がおざなりになって、上記 のような権限設定をしてしまうことがあります。 User User
23. 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/
24. 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/
25. 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/ アクセス先 処理 参考
26. 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/ 参考
27. 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/ 参考
28. 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/ 再掲
29. 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 参考
30. 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 参考
31. 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のパブリック許可をもったバケットポリシーが検出されたら、一旦バケットポリシーを 全アクセス禁止の形式に上書きしてしまいます
32. 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/
33. 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/ いかがでしたでしょうか？
34. 33 Copyright（C） NRI Netcom, Ltd. All rights reserved. 4. AWS IAM Identity Center の活用と効果
35. 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
36. 35 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
37. 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
38. 37 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
39. 38 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS IAM 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 デフォルトのクォータを超えてしまう 参考
40. 39 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 マネジメントアカウント用権限セット メンバーアカウント用権限セット 参考
41. 40 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ロールはアーカイブルールで除外
42. 41 Copyright（C） NRI Netcom, Ltd. All rights reserved. ここで一度 まとめてみます
43. 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 を使用しない、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認しない
44. 43 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/
45. 44 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ロールはアーカイブルールで除外
46. 45 Copyright（C） NRI Netcom, Ltd. All rights reserved. 5. NRIネットコムのAWS請求代行＆アカウント管理サービス
47. 46 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS請求代行＆AWSアカウント管理サービス NRIネットコムのAWS請求代行＆AWSアカウント管理サービスは、 AWS IAM Identity Center が利用可能です。 さらに割引価格でAWSをご利用いただける お得なサービスです。 NRIネットコムのAWS請求代行＆AWSアカウント管理サービスは、単純な請求代行だけでなく、AWS利 用のコストダウンコンサルティングや、セキュリティ向上に役立つテンプレートをご提供するなど、かゆい所に 手が届くサービスです。 豊富なナレッジを持つメンバーがお客様の状況を丁寧に伺い、適切な管理方法をご提案しています。も ちろん、すでにAWSのアカウントをお持ちのお客様もご利用いただけます。
48. 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ネットコム
49. 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ネットコム管理
50. 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
51. 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% 割引 オンデマンド 固定価格 スポットインスタンス 変動価格 ※需給の状況によっては、 インスタンスが中断される
52. 51 Copyright（C） NRI Netcom, Ltd. All rights reserved. 複数アカウントの請求を一元管理・最適化 ルールに基づいて請求書を発行し、事務コストの削減に寄与します。 ⚫ アカウント単位での請求の集計 ⚫ リザーブドインスタンスの購入など全体での最適化 ⚫ 必要に応じてAWSアカウント内で、プロジェクト単位での明細化、部門間の請求調整 サービスイメージ タグC タグC タグA タグB タグC インスタンス ／その他 課金ログ 保存 課金ログ NRIネットコム 請求書 請求データ 明細作成 貴社 貴社 ご担当者様 ネットコム 担当者 アカウント アカウント アカウント 集計システム ※請求書を複数枚発行が必要な場合は、別途手数料を頂きます。
53. 52 Copyright（C） NRI Netcom, Ltd. All rights reserved. NRIネットコムのAWSアカウント管理サービス利用における特典 さまざまな特典がついて、さらに利用料5%オフ 実績のある テンプレート利用 と提供 Organizations Control Tower 利用可能 利用料 5%オフ セキュリティ 設定カスタマイズ 技術サポート 事務コスト低減