AWSビギナーハンズオンノート ~IAM編~

Created: Jun 11, 2025 | Lastmod: Jun 11, 2025 min read

IAMとは？

  • AWSのアカウントや権限を管理するサービス

ルートユーザーとIAMユーザーの差異

  • AWS登録時のメアドとパスワードを使ってログインできるユーザー = ルートユーザー
    • 全てのAWSサービスやリソースへのアクセス権限あり
    • linuxのrootと同じように、普段使いはしない方がよい
  • 日常業務は、利用者ごとにIAMユーザーを払い出して使う
    • IAMポリシーで認められた操作のみを行える
  • IAMユーザーの作り方
    • ダッシュボード→IAM→ユーザー

IAMポリシー

  • アクセス許可を定義する
  • 以下の値を持つJSONドキュメントで指定する
    • Effect
      • Allow or Deny
    • Action
      • 対象のアクションを指定する（ワイルドカードも可）
    • Resource
      • 対象のリソースを指定する（ワイルドカードも可）
        • リソースとは: AWSの各サービスによって作成・管理される具体的なオブジェクトやエンティティ
  • サービスごとに、管理者用ポリシーや参照用ポリシーがある

IAMグループ

  • IAMユーザーの集合を定義
    • 各グループに対して、IAMポリシーを割り当てられる = グループ配下のユーザーはまとめてIAMポリシーが設定される

IAMロール

  • AWSリソースに割り当て、そのリソースに権限を与える
    • リソースにかぶせるヘルメットのようなもの
    • 現実での例え: 訪問先の会社で臨時入館カードをもらう
  • 実際の使用例
    • EC2からS3を操作したい場合、IAMロールをEC2インスタンスにかぶせる
      • = S3ReadOnlyAccessポリシーをIAMロールにアタッチし、そのIAMロールをEC2インスタンスに割り当てることで、S3のバケット一覧を表示可能になる
  • IAMロールの書き方
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*"
    }
  ]
}

「07 IAMロールを試してみる」でやったこと

  • EC2への読み取り権限を持ったIAMポリシーをアタッチしたIAMロールを作成
  • IAMロールをEC2のインスタンスに付与することで、EC2に接続した際、EC2一覧を表示するコマンドを実行できるようになる

マルチアカウント戦略

  • 特定の基準によって、AWSのアカウント自体を分ける戦略のこと
    • 例
      • 本番用と開発用
      • プロジェクトや部署ごと
    • メリット
      • 環境の分離
        • 同じ環境内に開発用と本番用のリソースどちらもあったりすると、管理者が誤って本番のリソースを削除してしまうリスクがある
      • 請求
        • 請求はアカウント単位で行われるので、どのアカウントにどれだけコストかかったか分かる
        • 同じアカウント内でも、コスト配分タグを使うと可視化できるが手間がかかる
      • ガバナンスへの迅速な対応
        • いちいち権限許可をもらったりするより、最初から部門ごとにアカウントを払い出して、それぞれ適切な権限を与えておけば、社内規定も満たした上でスピード感を持てる
      • ワークロードの分離
        • 外部向け/社内向けサービスのアクセス可否を統一
        • ワークロードとは？
    • デメリット
      • アカウント管理が複雑になる
        • 例：本番用と開発用で分けた場合、各環境ごとで都度ポリシーの設定が必要になる
      • 請求をまとめたいときにむしろ不都合
  • マルチアカウント戦略のデメリットを解決するのが、AWS Organizations
    • 複数のアカウントを組織化して管理できるアカウント管理サービス
      • 請求の一本化と個々の明細の可視化を両立
    • アカウントの種類
      • 最初にOrganizationsを有効化したアカウントが管理アカウント（組織に1つだけ存在）
      • それ以外がメンバーアカウント
    • それぞれのメンバーアカウントは、OU（Organizational Unit）によってグループ化できる
      • 例
        • ログを管理するためのOU
        • セキュリティ設定を管理するためのOU
    • SCP（Service Control Policy）によって、OUやアカウント単位でIAMポリシーをアタッチできる
      • してはいけない操作（=ガードレール）を適用できる
      • 請求については、管理アカウントに紐づいた請求へ一本化できる
  • 環境ごとにアカウントを分けると、IAM設定やパスワード管理が面倒→AWS IAM Identity Centerで解消
    • 複数のAWSアカウントに対してSAOを実現するサービス
      • 使い方
        • まずユーザーはIAM Identity Centerに対してID・パスワードでログイン
        • IAM Identity Centerのユーザーには、アクセス許可セットが割り当てられている
          • それぞれのASWSアカウントにどんな権限でアクセスできるかを定義に従って各AWSアカウントにログイン
          • 許可セット ≒ IAMロールの設計書
            • 許可セットに基づいて、各アカウントに作成されるIAMロールが一時的に付与されてログインを行える
              • 各環境ごとに個別のIAMユーザーを作らなくていい
              • ユーザーは1つのID・パスワードで複数の環境に適切なロールを持ってログインできる

「09 AWS Organizationsによるマルチアカウント戦略を試してみる」でやったこと

  • AWS Organizationsで組織を作成し、検証組織・開発組織・本番組織と、それぞれに紐づくAWSアカウントを作成
    • AWS Organizations→組織作成→アカウント作成→アカウントを組織に移動
  • SCPを作成
    • ポリシー→サービスコントロールポリシー→有効にする
  • IAM Identity CenterでSSOユーザーを作成
  • このSSOユーザーでログインできる先を設定する
    • AWS Organizations「マルチアカウント許可」から、AWSユーザー3つに対して、グループ（sso-group）と許可セット（管理者権限AdministratorAccess）を紐づけ
  • Organizations SCPとIAM Identity Center許可セットどちらも許可された操作だけ許可される
    • IAM Identity Centerで管理者権限AdministratorAccessがあったとしても、SCPでEC2が拒否されれば拒否される
comments powered by Disqus