0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@555hamano(Akr)

【AWSプロフェッショナルへの道】現役エンジニアが贈るクラウド実践ガイド - 第20回 セキュリティの基礎固め！IAMの深掘りとベストプラクティス

0
Posted at

セキュリティの基礎固め！IAMの深掘りとベストプラクティス

こんにちは！現役クラウドエンジニアの[あなたの名前/ハンドルネーム]です。

「【AWSプロフェッショナルへの道】現役クラウドエンジニアが贈る実践ガイド」の第20回をお届けします。前回はAWSアカウントの監査ログサービスであるCloudTrailを学び、アカウントの操作履歴を追跡・分析するスキルを身につけましたね。CloudTrailが「何が起きたか」を記録するのに対し、今回は「誰が何をする権限を持っているか」を定義する、AWSセキュリティの根幹をなすサービスに焦点を当てます。

今回徹底的に解説するのは、AWS IAM (Identity and Access Management) です。第1回でもIAMの基本的な概念に触れましたが、今回はより深く掘り下げ、本番環境で必須となる「最小権限の原則」に基づいた詳細なIAMポリシーの作成、IAMロールの応用、そして複数のAWSアカウントを安全に管理するための実践的な方法までを網羅的に学びます。

「IAMポリシーってどうやって書けばいいの？」「IAMロールはいつ使えばいいの？」「複数のアカウントをどうやって行き来するの？」といった、運用における具体的な疑問を解決していきましょう。本記事を通じて、AWS環境をセキュアに保つための、より高度なIAMスキルを身につけます。

1. IAMの再確認：基本コンポーネントとポリシーの構造

IAMの主要なコンポーネントは以下の通りです。

  • IAMユーザー: AWSリソースにアクセスする個人やアプリケーション。
  • IAMグループ: IAMユーザーの集まり。複数のユーザーに同じ権限を付与する際に便利です。
  • IAMロール: 特定の権限セットを持つ一時的なID。長期的な認証情報を持たず、信頼されたエンティティ（EC2インスタンスなど）が引き受けて使用します。
  • IAMポリシー: 権限を定義するドキュメント（JSON形式）。ユーザー、グループ、ロールにアタッチされます。

IAMポリシーは、Statementという要素の中に、Effect、Action、Resource、Conditionなどの要素を記述することで、細かな権限を定義します。

ポリシーの具体例:
特定のS3バケットへのファイルアップロードのみを許可するポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-application-bucket/*"
    }
  ]
}
  • Effect: "Allow": このアクションを許可する。
  • Action: "s3:PutObject": PutObjectというAPIアクションのみを許可する。
  • Resource: "arn:aws:s3:::my-application-bucket/*": my-application-bucketというバケット内のすべてのオブジェクトのみを対象とする。

このポリシーは、ユーザーにS3バケットの作成や削除といった不要な権限を与えず、必要最低限の権限のみを付与している点で、「最小権限の原則」に則っています。

2. IAMロールの深掘り：信頼ポリシーとユースケース

IAMロールは、AWSセキュリティの要です。特に、AWSサービス間での権限付与や、複数のAWSアカウントを安全に連携させる際に不可欠なコンポーネントです。

2.1. 信頼ポリシー (Trust Policy)

IAMロールには、誰がそのロールを引き受けられるかを定義する「信頼ポリシー」が必ずアタッチされています。この信頼ポリシーによって、IAMロールは長期的な認証情報を必要としません。

信頼ポリシーの具体例:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
  • Principal: 信頼されたエンティティ（この場合はec2.amazonaws.comというAWSサービス）。
  • Action: "sts:AssumeRole": sts:AssumeRoleというAPIアクションを許可することで、指定されたプリンシパルがこのロールの権限を引き受けることを許可しています。

この信頼ポリシーを持つIAMロールは、EC2インスタンスにアタッチすることで、インスタンスが一時的な認証情報を取得し、ロールにアタッチされた権限（例: S3へのアクセス）でAWS APIを呼び出せるようになります。これにより、EC2インスタンスにアクセスキーを直接埋め込む必要がなくなり、認証情報漏洩のリスクがなくなります。

2.2. IAMロールの主要なユースケース

  1. AWSサービスへの権限付与: EC2、Lambda、ECSなどのAWSサービスに、S3やDynamoDBへのアクセス権限を付与する場合。
  2. クロスアカウントアクセス (Cross-Account Access): 複数のAWSアカウント（例: 開発アカウントと本番アカウント）間で、ユーザーが安全にアクセスする場合。
  3. フェデレーション (Federation): 組織の既存のIDプロバイダー（Active Directory, Oktaなど）を使って、AWSコンソールにサインインする場合。

3. 実践！クロスアカウントアクセスとロールの引き受け

ここでは、IAMロールを使って複数のAWSアカウントを安全に行き来する方法を実践します。

シナリオ:

  • アカウントA（開発者アカウント）にいるIAMユーザーが、アカウントB（本番アカウント）のS3バケットを閲覧できるようにしたい。
  • アカウントBのリソースに直接アクセスできるIAMユーザーは作成せず、アカウントAのIAMユーザーがロールを引き受けることでアクセスさせる。

3.1. アカウントB（本番アカウント）でのロール作成

まず、アクセス先のアカウントBで、アカウントAからのアクセスを許可するIAMロールを作成します。

  1. アカウントBのIAMコンソールで「ロール」を選択し、「ロールを作成」をクリックします。
  2. 信頼されたエンティティタイプ: 「AWSアカウント」を選択します。
  3. 別のアカウント: アカウントAのAWSアカウントIDを入力します。
  4. 許可を追加: AmazonS3ReadOnlyAccessポリシーを検索して選択します。
  5. ロール名: ProdS3ReadOnlyRoleと入力し、「ロールを作成」をクリックします。

これで、アカウントBにProdS3ReadOnlyRoleというロールが作成されました。このロールは、アカウントAからのアクセスを信頼し、S3への読み取り専用アクセスを許可します。

3.2. アカウントA（開発者アカウント）でのポリシー作成

次に、アクセス元のアカウントAで、IAMユーザーがアカウントBのロールを引き受けることを許可するポリシーを作成します。

  1. アカウントAのIAMコンソールで「ポリシー」を選択し、「ポリシーを作成」をクリックします。

  2. 「JSON」タブを選択し、以下のポリシーを貼り付けます。

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::ACCOUNT_B_ID:role/ProdS3ReadOnlyRole"
    }
  ]
}
    • ACCOUNT_B_IDの部分をアカウントBのAWSアカウントIDに置き換えます。

  3. ポリシー名にAssumeProdS3ReadOnlyRolePolicyと入力し、「ポリシーを作成」をクリックします。

  4. このポリシーを、アカウントBにアクセスしたいアカウントAのIAMユーザーにアタッチします。

3.3. クロスアカウントアクセスを試す

  1. アカウントAのIAMユーザーとしてAWSマネジメントコンソールにサインインします。
  2. 右上のユーザー名をクリックし、「ロールの切り替え」を選択します。
  3. アカウント: アカウントBのAWSアカウントIDを入力します。
  4. ロール: ProdS3ReadOnlyRoleと入力します。
  5. 「ロールの切り替え」をクリック。

これで、コンソールの表示がアカウントBの権限に切り替わります。アカウントBのS3コンソールに移動してバケットが閲覧できることを確認し、EC2コンソールに移動してインスタンスの操作ができないことを確認してください。

4. IAMのベストプラクティス

  • 多要素認証 (MFA) の有効化: ルートアカウントと特権ユーザーには、必ずMFAを有効にしましょう。
  • 長期的な認証情報の排除: IAMユーザーのアクセスキーは極力使わず、IAMロールやAWS SSO、フェデレーションを積極的に活用しましょう。
  • IAM Access Analyzerの活用: IAM Access Analyzerは、外部エンティティと共有されているアクセス権限を自動で検出してくれます。
  • タグ付けによる権限管理: リソースにタグを付け、IAMポリシーのCondition要素でそのタグに基づいてアクセスを制御できます（例: env:productionのタグが付いたリソースのみ操作を許可）。
  • インラインポリシーの使用は最小限に: 再利用可能な顧客管理ポリシーを作成し、グループにアタッチすることで、権限管理をシンプルに保ちましょう。
  • アクセスレビューの実施: 定期的にIAMユーザーやロールのアクセス権限を見直し、不要な権限がないか確認しましょう。

まとめ

今回は、AWSセキュリティの基盤であるIAMについて、より深く、実践的に学びました。

  • IAMポリシーの構造を理解し、「最小権限の原則」に基づいたポリシーの書き方を再確認しました。
  • IAMロールは、信頼ポリシーを通じて一時的な権限を付与する強力なツールであり、AWSサービスへの権限付与やクロスアカウントアクセスに不可欠であることを学びました。
  • 実践的なシナリオを通じて、複数のAWSアカウントを安全に行き来するロールの作成と引き受けの手順を習得しました。

IAMを正しく理解し、ベストプラクティスに従って運用することは、AWS環境全体のセキュリティを確保するために最も重要です。この知識は、あなたのキャリアにおける大きな強みとなるでしょう。

この記事が皆さんのAWS学習の一助となれば幸いです。

もしこの記事が役に立ったと感じたら、ぜひ「いいね」👍をお願いします！励みになります！

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?