[レポート] re:Inforce 2022 – Security best practices with AWS IAM (IAM201) #reInforce

みなさんこんにちは、杉金です。
AWS re:Inforce 2022 セッション動画の視聴レポートです。IAMのセキュリティベストプラクティスに関するセッション動画なのですが、実はIAMのセキュリティベストプラクティスは2022/7/14にアップデートしています。古い情報のままでいる方は要チェックです。IAMのセキュリティベストプラクティスが載っているユーザーガイドは以下のページです。

実際のセッション動画では分かりやすい図であったり、詳細な説明やデモを披露してくださっていますので、レポートを読んで興味を持たれた方はぜひ動画をご覧ください。
個人的な見どころは、スピーカーの方がそれぞれの好きな条件キー（Condition key）を話しているところです。

セッション情報

セッション動画

セッション概要

AWS IAM is an essential service that helps you securely control access to your AWS resources. In this session, learn about IAM best practices like working with temporary credentials, applying least-privilege permissions, moving away from users, analyzing access to your resources, validating policies, and more. Leave this session with ideas for how to secure your AWS resources in line with AWS best practices.

スピーカー

• Brigid Johnsonさん
  • Senior Development Manager, AWS Identity
• Matt Luttrellさん
  • Senior Solution Architect, AWS Identity

レポート

アジェンダ

• AWS identity overview
• Diving into each of the 14 best practices
  • Identity and credentials management
  • Permissions management
  • Tools to guide you

Identity overview: Who can access what

• Who can access what
  • Who : 開発者とアプリケーション
  • Can acess : パーミッション
  • What : リソース
• 開発者とアプリケーション
  • 人やアプリケーション、ワークロード、自動化されたジョブなど
• リソース
  • S3バケット、Lambda関数、Step Functions、バッチジョブなど
• パーミッション
  • 「誰が（Whoi）」「何を（What）」を繋ぐもの
  • これがIAMによるアクセスコントロール

Identity and credentials management

• アイデンティティと認証情報管理のベストプラクティス
• 説明の流れ
  • ベストプラクティスの紹介
  • なぜベストプラクティスであるかの理由
  • AWSで実装する方法
• 最初のベストプラクティス

  Require human users to use federation with an identity provider to access AWS using temporary credentials

  • 人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには、ID プロバイダーとのフェデレーションの使用が必要
  • アイデンティティの種類
    • 人とワークロード
    • 人（ユーザー）
      • 人とは開発者、ビジネスアナリスト、データサイエンティストなど
        • これらはAWSにアクセスする人たち
      • CLIやコンソールを使って、クライアントアプリケーションを使用する
      • 通常は組織内の人間
        • 組織内のユーザーを workforce identitiesと呼ぶ
      • 組織外の人もアクセスできる
    • ワークロード
      • ワークロードとは、CICDパイプライン、アプリケーション、インフラストラクチャなど
      • 人間がいるわけではないのになぜIDプロバイダを使うのか
        • 理由のひとつとして、ユーザーストアを一元化するため
  • 人のアクセスになぜIDプロバイダを使用するのか
    • ユーザーストアの一元化
      • 組織には入社する人、転職する人、退職する人がいる。誰かが部署を異動したり、組織を去ったりしたときに複数の異なるシステムで更新作業を行うことは避けたい
    • パスワード疲労を軽減
      • ユーザー（人）にとって、多くの異なるシステムでパスワードを管理するのは嫌なもの
      • ユーザーは、あまり複雑でないパスワードや覚えやすいパスワードを選ぶ傾向があり、システム間でパスワードを重複させる傾向がある
    • 保護しなければならないシステムの数を減らす
      • IDプロバイダーが1つであれば、そのIDプロバイダーのセキュリティ確保に力を注ぐことができる　　
    • 監査のしやすさ
      • リクエストがどこから来ているのか、単一のIDソースに結びつけることができれば、監査の観点からも非常に楽になる
  • IAM Identity Center
    • AWSでは人のアクセスはIAM Identity Centerで行われる
    • 先日AWS SSOがIAM Identity Centerと呼ばれるようになった
    • IAM Identity Centerを使い始めるには、IDソースを選択する
      • Identity Centerディレクトリは、ユーザー名とパスワードをIdentity Centerで直接保存する場所
      • 既存のActive DIrectoryドメインまたは、外部 ID プロバイダを選択することができる
      • 外部 ID プロバイダを選択した場合、Identity Center と ID を同期する必要がある
      • これを手動で行うか、SCIM（スキム） を使用する
      • アイデンティティをIdentity Centerに同期させると、AWS組織内のAWSアカウントに対する権限を1箇所で管理できる
    • Identity Centerで接続されたアプリケーションを管理することもできる
    • （Identity Centerデモ披露：コンソール操作でユーザーをグループに追加、権限を割り当ててログインする)
• 次のベストプラクティス

  Require workloads to use temporary credentials with IAM roles to access AWS

  • ワークロードが一時的な認証情報（クレデンシャル）とIAMロールを使用してAWSにアクセスすること
  • なぜ一時的な認証情報がよいか
    • 有効期限があり、自動的に期限切れになること
      • 自動的に失効するためローテーションする必要がない
      • 一時的な認証情報が失効したときに明示的に取り消す必要がない
    • 認証情報の配布と保管を不要にする
    • 一時的な認証情報を使用すれば、アプリケーションは必要なときにそれを要求するだけでよい
  • IAMロールや一時的な認証情報を、IAMユーザーや長期的な認証情報よりも優先すべき
  • また、多くのAWSサービスはIAMロールとネイティブに統合されているため、ネイティブな統合を使用してほしい
  • IAMロールを使用する際のヒントとして、1つの責任には1つのロールを使用すること
    • 異なるサービスやアプリケーションには異なるロールを使用すること
    • これは最小限の特権について話すときに重要
  • AWS上で動作していないワークロードはどうすればよいか （データセンターで稼働しているワークロードや、他のインフラで稼働しているワークロード）
    • 長期的な認証情報を作成、配布、維持する代わりに最近発表されたIAM Roles Anywhereを使用できる
      • IAM Roles Anywhereは、認証局からのX.509証明書を使用してAWSと認証し、AWSへの安全なアクセスを提供する
      • AWSの外部でワークロードを実行している場合は、IAM Roles Anywhereをチェックしてみてほしい
• 次のベストプラクティス

  Require multi-factor authentication（MFA）

  • MFAとは、ユーザー名とパスワードと、あなたが持っているもの（通常はある種のトークン）を組み合わせたもの
  • AWSリソースにアクセスするすべての人にMFAを適用してほしい
    • ユーザー、特にIAMルートユーザー、そしてAWSにログインするためにIDプロバイダを使用している他の人間も含まれる
• 次のベストプラクティス

  Rotate access keys regularly for use cases that require long-term credentials

  • 長期的な認証情報を必要とするユースケースのために、アクセスキーを定期的にローテーションすること
  • アクセスキーは、IAMユーザーとIAMルートユーザーの両方に関連する長期的な認証情報の一種で、AWSへのプログラムアクセスに使用されるもの
  • そもそもIAMルートユーザーのアクセスキーを作成することはお勧めしない
  • IAMユーザーのアクセスキーはローテーションする必要がある
  • なぜアクセスキーをローテーションさせるのか
    • アクセスキーの有効期限を制限する
    • 社員が退職したときなどを想定して実際にアクセスキーを取り消す練習をすること
  • アクセスキーのローテーションはどのように行うのか
    1. 新しいアクセスキーを作成して、アクセスキーを2つ用意する
    2. アクセスキーを使用しているすべてのアプリケーションを、新しいアクセスキーを使用するように更新する
    3. すべてのアプリケーションが更新されたことを確認する
       • これはユースケースに依存する傾向がある
         • AWSコンソールにはLast Usedプロパティがあり、古いアクセスキーが最後にいつ使われたかを判断することができる
           • CLIやSDKでも同じように調べることができる
    4. アプリケーションの更新を確認したら、その古いアクセスキーを非アクティブとしてマークする
       • アクセスキーを非アクティブにすると、そのアクセスキーは使用できなくなる。まだその古いアクセスキーを使用しているユースケースがあることが分かったら、いつでもアクティブにできる
    5. 一定期間待って、もう使われていないことが確認できたら、その古いアクセスキーを削除する
       • アクセスキーのローテーションに自信がついたら、古いアクセスキーを削除するのに数日ではなく数時間待つようにするとよい
  • これはベストプラクティスのひとつですが、実際には使う必要がないことを願っている
    • つまり一時的な認証情報を使用し、IAMロールを使用してほしい
      • アクセスキーのローテーションを行う必要はない
      • IAMロールとその認証情報がローテーションされるという事実を利用してほしい
• 次のベストプラクティス

  Safeguard your root user credentials and don't use them for everyday tasks

  • ルートユーザーの認証情報を保護し、日常的なタスクに使用しないこと
  • なぜルート認証情報の使用を制限する必要があるのか
    • 1つ目の理由：それらは長期的な認証情報であり、長期的な認証情報よりも一時的な認証情報を優先させるべき
    • 2つ目の理由：ルートユーザーの認証情報は、あなたのAWSアカウントに無制限でアクセスできること
  • AWSのいくつかのアクションでは、ルート認証情報の使用を必要とするアクションもあるが、アカウントに関連付けられた電子メールアドレスの更新や、アカウントのサポートプランの変更などのようなもの
    • これらは頻繁に実行するアクションではないので、日常的にルート認証情報を使用するべきではない
  • どうやってルート認証情報を保護するのか
    • ルート認証情報自体を保護する
      • AWSコンソールにログインするためのコンソールユーザー名とパスワード、AWSへのプログラムアクセスに使用されるアクセスキー、そしてMFAトークンの保護
      • 最も簡単に保護できる認証情報は、存在しない認証情報
        • IAMルートユーザーのアクセスキーを作成しないようにすれば、保護について心配する必要はない
      • Consoleのログインについては、複雑なパスワードを作成し、パスワード保管庫のようなものに保管することがオススメ
      • MFAトークンは、物理トークンの場合は、物理金庫に保管してその金庫へのアクセスを制御すること
        • 仮想トークンの場合は、時間ベースのワンタイムパスワードを生成するために使用する秘密鍵をパスワード保管庫のようなものに保管すること
        • MFAトークンとパスワードへのアクセスには、two-person roleを使用することを検討してほしい
      • もうひとつの方法として、ログインパスワードをそのまま捨ててしまうこと
        • 非常に複雑なパスワードを設定し、どこにも書き留めないようにする。そのパスワードはルート認証情報のリカバリフローに頼ることになる
    • ルート認証情報のリカバリーフローの保護
      • ルート認証情報のリカバリーは、パスワードそのものか MFA トークンのどちらかをリセットすることができる
        • パスワードのリセットは、アカウントに関連付けられた電子メールによって行われる
        • MFAトークンのリセットは、電子メールと電話の組み合わせで行われる
      • アカウントに関連付けられた電子メールアドレスと、MFAトークンに関連付けられた電話番号へのアクセスを制御する
    • ルート認証情報の使用防止と監視
      • SCPで子アカウントのルート認証情報の操作をブロック
        • ルート認証情報は無制限にアクセスできる
        • AWS Organizationsの構成で、組織内の子アカウントのroot権限を拒否することができるサービスコントロールポリシー（SCP）と呼ばれるものを作成できる
          • AWSアカウントが組織内にいる場合は、SCPを使用して子アカウントのルートユーザーをブロックすることができる　
      • 監視としては、AWS GuardDutyのようなサービスを使って、ルート認証情報の不正利用を調べることがオススメ

Permissions management

• パーミッションのベストプラクティスについて
  • パーミッションとは何か
    • 誰が何にアクセスできるかを指定する
    • プリンシパル、アクション（数千種類）、リソース（数百種類）を指定し、誰が何にアクセスできるかを指定するための条件も設定する
    • AWSのすべてのアクセス制御について、AWSはポリシーをチェックし、入ってくるリクエストを見て、イエスかノーか、許可か拒否かの答えを出す
  • IAMポリシーのサンプルを画面で披露
    • Principal、Action、Resource、Condition
      • 私たちはこれを「PARCモデル」と呼んでいる
    • 基本的には、どのような条件下で、どのリソースに対して、どのようなアクションが可能かを、プリンシパルに許可することができる
    • 最初のベストプラクティスを考えるとき、最小限の特権を適用することを考える
• 次のベストプラクティス

  Apply least-privilege permissions

  • 最小特権とは、ユーザーやシステムに、必要なタスクを完了するための最も狭い範囲の権限を与えること
  • 必要なタスクはユースケースによって変化する
    • 開発中かもしれないし、新しいものを作ろうと模索中かもしれない
    • 本番環境では、クレジットカードのデータを処理するようなハードなワークロードがある場合は、非常に厳しい権限設定になる
  • このように、構築者に構築させ、ビジネスを革新させる一方で、危険な行為を防止し、説明責任を果たすためのセキュリティ姿勢を確立するために、成功に向けて取り組むべきバランスがある
  • 最小特権について考えるとき、それはチェックボックスではなく、旅である
  • 最小特権の旅
    1. Exploring AWS
       • AWSマネージドポリシーまたはカスタムテンプレートでより広い範囲をカバーする
    2. Right-sizing
       • IAM Access Analyzerにより、ポリシー生成とカスタマイズを実現
    3. Specifying conditions
       • IAM Access Analyzerを使用したポリシー検証により、カスタムポリシーを作成し、検証を行う
  • 今日はそのうちの2つのデモを披露する
• 次のベストプラクティス

  Establish permissions guardrails across multiple accounts

  • アカウント内できめ細かなパーミッションを行う前に、複数のアカウントにまたがるパーミッションのガードレールを確立する必要がある
  • ワークロードに複数のアカウントを使用し、それらをAWS Organizationsで使用し、そしてパーミッションのガードレールを確立する
    • これにより、エンジニアリングチームが成功するための準備が整う
    • 正しいことをするように、バンパーを与えるようなもの
    • ネットワーク制御を変更できる人、強力なパーミッションを変更できる人、バケットのパーミッションを変更するためのアクセスを許可できる人、などを制限する必要がある
    • このように、制限したい一般的な事柄を考え、それを組織全体のガードレールにバブルアップしていく
    • このガードレールの1つがデータ境界である
• データ境界
  • なぜデータ境界を設定する必要があるか
    • 4つの理由
      • コンプライアンス要件への対応
      • 企業バウンダリー（境界）の構築
      • 開発者の自由度を提供する
      • 深層部の防御
  • データ境界とは何か
    • AWS環境における予防的なガードレールのセットであり、信頼できるアイデンティティが想定されたネットワークからリソースにアクセスすることを保証するのに役立つ
  • データ境界を構成するもの
    • 信頼されたアイデンティティ
      • 組織内のユーザーや役割、あるいはあなたの代わりに運用されるAWSサービスなど
    • 信頼されたリソース
      • S3バケット、Lambda関数、SQSキュー、SNSトピックなど
    • 期待されるネットワーク
      • オンプレミスのデータセンター、VPCなどの使用しているネットワークなど
• 次のベストプラクティス

  Use conditions in IAM policies to further restrict access

  • さらにアクセスを制限するために、コンディションを使用することをオススメしている
    • 条件について話すときは、"only if "という言葉を考えてみてほしい
      • つまり、アクションへのアクセスを許可したいが、それは条件を満たした場合のみ、ということ
  • "only if "による、きめ細かなアクセスコントロールの4つの例
    • これらのアクションへのアクセスを許可する。ただし、以下の条件を満たす場合のみ
    • アクションやリソースへのアクセスを許可する。ただし、アクセス要求が特定の条件を満たす場合のみ
    • Lambda関数を作成できるようにする。ただし、AWS CloudFormationを使用する場合のみ
    • Lambda関数の作成を許可する。ただし、VPC内の場合のみ
  • アクセス権を付与したり、アクセスを制限したい場合、この条件を満たした場合のみ、という条件をつけるとよい。
  • どのように条件（Condition）が動作するか
    • 条件には3つの要素がある。
      • 演算子
      • キー（Keys）
      • 値（Value）
    • その中で唯一、自分の組織独自のものを指定できるのが値である
    • 演算子はStringEquals、StringLikeなどがあり、自分で演算子を作ることはできない。
    • キーは私たちが定義するもので、ポリシーに照らして評価するためにコンテキストに入れるもの
    • キーはPrincipalIsAWSService、ResourceTag、ViaAWSService、PrincipalArnなど様々なものがある
  • Matt Luttrellさんの好きな条件キー
    • Global condition keyがいいと思っている
    • Global condition keyとは、すべてのAWSサービスで利用できるもので、データ境界にも適用できる
    • PrincipalOrgIDとaws:ResourceOrgID、この2つの組み合わせがお気に入り
    • PrincipalOrgIDは、プリンシパルが私の組織内にいる場合のみこのリソースにはアクセスできる
    • ResourceOrgIDは、リソースが私の組織内にある場合のみアクセスできる
    • この2つの組み合わせが、データ境界の基礎になる
  • Brigid Johnsonさんの好きな条件キー
    • 多くのお客様が、お客様に代わってアクションを実行するサービスを利用していますが、Access Analyzerもその一つ
    • そこで「この特定のアクションへのアクセスを、AWSのサービスを通じてのみ許可する」と言うことができる
    • これがViaAWSServiceというcondition keyで、あなたの代わりに実行するAWSサービスであれば、このアクセスを許可しますということである

Tools to guide you

• アクセスを制御するすべての方法と、そのために条件を使用して最小特権を適用するベストプラクティスについて話をした
  • これらのベストプラクティスを導くのに役立つツールを紹介する
• 最小特権の考え方は、一夜にして実現するものではなく、旅であり、その旅には3つの段階がある
  • パーミッションの設定（Set）、パーミッションの確認（Verify）、そしてパーミッションをさらに洗練（Refine）させるという3つのステップをループしていくことになる
  • そして、より快適になり、自分が何を作っているのかがわかり、本番になればなるほど、このループはますますきつくなっていく
• 次のベストプラクティス

  Get started with AWS managed policies and move toward least-privilege permissions

  • AWSマネージドポリシーを使い始め、最小特権の方向へ進んでほしい
    • AWSマネージドポリシーは、すべてのAWSカスタマーに対して一般的なものである
    • あなたのユースケースに特化したものではありませんので、そこから始めて探索することも可能ですが、次に進む必要がある
  • どんな時にAWSマネージドポリシーを使うのかの例
    • AWSを始めるにあたって
      • PowerUserAccess（AWSのサービスやリソースへのフルアクセスを提供するが、ユーザーやグループの管理はできない）
    • 新しいAWSサービスを使うとき（対象サービスの読み書き権限を持ったマネージドポリシーを選ぶ）
      • SeceretsManagerReadWrite（AWSマネジメントコンソール経由でAWS Secrets Managerへの読み書きアクセスを提供する）
    • 一般的なアクセスを必要とする人（職務に応じたマネージドポリシーを選ぶ）
      • Network Administrator（AWSネットワークリソースの設定と構成に必要なフルアクセス権限を付与する）
    • AWS service-linked roles
      • AccessAnalyzerServiceRolepolicy（Access Analyzerによるリソースのメタデータ解析の許可）
• 次のベストプラクティス

  Use IAM Access Analyzer to generate least-privilege policies based on access activity

  • IAM Access Analyzerを使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成することができる
    • これは2021年に発表された機能なので、もしまだチェックしていないのであれば、ぜひチェックしてみてほしい
  • IAM Access Analyzerによるポリシー生成
    1. アプリケーションやタスクの実行
    2. IAM Access Analyzerからポリシーを要求する
    3. IAM Access AnalyzerはCloudTrailのログを分析し、ポリシーを生成
    4. このポリシーが生成されると、さらにカスタマイズすることができる
       • 追加のアクションを追加したり、リソースを指定したり、そのためのテンプレートを提供したり、途中で条件を追加できる
  • （IAM Access Anlyzerを使ったLambda用IAMロールのポリシー生成のデモを披露）
• 次のベストプラクティス

  Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions

  • ポリシーの検証について話をしたが、IAM Access Analyzerを使ってポリシーの検証ができる
  • IAM Access Analyzerによるポリシー検証でチェックされるカテゴリ
    • Security
      • ポリシーに含まれるアクセスは、過度に寛容になることがある
    • Errors
      • ポリシーにエラーがあり、ポリシーが機能しない
    • General warnings
      • ポリシーがベストプラクティスに適合していないが、問題はセキュリティリスクではない
    • Suggesions
      • ポリシーには改善すべき記述があるが、ポリシーのパーミッションには影響しない
  • ポリシーが安全で機能的であることを確認するために、100以上のチェックがあり、上記4つの方法でそれを行うことができる
    • セキュリティに関するチェック、ポリシーのエラーに関するチェック、一般的な警告、そして提案
    • 各チェックには実際の推奨事項があり、さらに詳しい情報を提供するためにドキュメントに移動する
    • ポリシーのどこに記載されているかがわかる
    • この機能は、ポリシーを作成する際や既存のポリシーにも適用できる
  • CICDパイプラインにポリシーの検証を導入しているお客様は、出てくるセキュリティチェックと出てくるエラーを本当に見ている
    • これらは、infrastructure as codeとしてポリシーをデプロイする際に自動化しておきたい
  • （ポリシー検証のデモを披露）
• 次のベストプラクティス

  Verify public and cross-account access to resources with IAM Access Analyzer

  • パブリックアクセスとクロスアカウントアクセスの検証
  • データの境界について説明すると、信頼できる範囲を超えて外部からのアクセスを許可するものはすべて検証する必要がある
    • IAM Access Analyzerで外部からのアクセスを点検・確認できる
  • IAM Access Analyzerによる調査
    • まず、IAM Access Analyzerを有効化にする（無料）
    • 7種類のリソースのアクセス制御を継続的に監視し、レビューする
    • 自動推論により、パブリックアクセスやクロスアカウントアクセスを判断し、パブリックへのパスがあるかどうかを確認し、その結果が報告される
    • 結果を見て「ああ、そのデータ処理アカウントは本番のPicklesへのアクセスが許可されていることに同意する」と言うことができる
      • あるいは「あのサードパーティーからのアクセスはダメだ」と言うこともできる
        • 結果に基づきポリシーを更新する
• 次のベストプラクティス

  Regularly review and remove unused users, roles, permissions, policies, and credentials

  • 継続的なモニタリングとレビューについては、ユーザー、ロール、パーミッション、ポリシー、認証情報をレビューし、それらが使用されているかどうかを確認し、使用されていない場合は削除する必要がある
  • 使用されていないものを削除すれば、セキュリティポスチャに貢献することになる
  • 最後にアクセスしたデータで、未使用のエンティティを削除
    • IAMロールとIAMユーザー
      • ロールとアクセスキーは最後にいつ使用したか（最終アクセス情報）
    • 未使用のパーミッション
      • 最後にアクセスしたサービス・アクション
    • マルチアカウント制限
      • SCPが最終アクセスしたサービス
  • 組織かつSCP（サービス・コントロール・ポリシー）を使っている場合、使用しないサービスへのアクセスを制限することも可能
    • つまり、あるサービスを利用しないことに決めた場合、そのサービスがビジネス・ユースケースにとって価値がない場合、そのサービスを制限すれば、それ以降、心配する必要はなくなる
    • 組織全体に対して制限をかけることができる

What to take back（持ち帰るもの）

• 人および作業負荷へのアクセスに一時的なクレデンシャルを使用していることを確認する。
• 長期的なクレデンシャルの使用を検査し、異議を唱える
• チームによる構築と革新を可能にするガードレールの確立
• 継続的に権限を検証し、改善する

セッションに登場したベストプラクティスまとめ

セッションに登場したベストプラクティスの一覧です。

• Require human users to use federation with an identity provider to access AWS using temporary credentials
• Require workloads to use temporary credentials with IAM roles to access AWS
• Require multi-factor authentication（MFA）
• Rotate access keys regularly for use cases that require long-term credentials
• Safeguard your root user credentials and don't use them for everyday tasks
• Apply least-privilege permissions
• Establish permissions guardrails across multiple accounts
• Use conditions in IAM policies to further restrict access
• Get started with AWS managed policies and move toward least-privilege permissions
• Use IAM Access Analyzer to generate least-privilege policies base on access activity
• Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions
• Verify public and cross-account access to resources with IAM Access Analyzer
• Regularly review and remove unused users, roles, permissions, policies, and credentials

IAMのセキュリティベストプラクティスは本記事の執筆時点で14個あるのですが、時間の都合上か以下のものが省略されているか、私が聞き逃しているかもしれません。一応紹介だけしておきます。（何度か再チェックしたのですが含まれてなさそうでした）

アクセス権限の境界を使用して、アカウント内のアクセス許可の管理を委任します。

記事の冒頭でも紹介しましたが、IAMのセキュリティのベストプラクティスは以下のページに載っていますので詳細はそちらをご確認ください。

感想

IAMのセキュリティのベストプラクティスが更新されていたことに気づいてなかったので、私自身の知識もアップデートできました。特に、一時的な認証情報を使うべき、という流れからのIAM Roles Anywhereの紹介は必要性がよく理解できました。それにしてもセッション中にピクルスと馬がしばしば登場してきて、何かのスラングかな？セキュリティの用語なのだろうかと調べてみたのですが、どうやらスピーカーの方のお友達として、ピクルスという名前の馬がいるようです。やんちゃなピクルスとパーミッションの相性がいいってそういうことかと納得しました。

参考情報

• IAM でのセキュリティのベストプラクティス
• [レポート]AWS re:Inforce 2022 re:Cap Seminar
• [レポート] 『What “security is our top priority” means to AWS』 #reInforce
• AWS IAMポリシーのConditionを書くときの勘所 #devio2022
• 7 年間溜めた AWS IAM AWS 管理ポリシーへの愛を語りました #devio2022
• 信頼ポリシーにおいてスイッチロールできるIAMユーザーを複数指定する方法
• AWS IAMリソース パスのススメ