トップ > AWS Fleet Manager接続時、MFAを必須とするIAM権限とタグベースアクセス制御の実装

AWS Fleet Manager接続時、MFAを必須とするIAM権限とタグベースアクセス制御の実装

記事タイトルとURLをコピーする

こんにちは、アプリケーションサービス部の遠藤です。

今回はEC2へのFleet Manager接続のみを目的としたユーザーに対して、多要素認証を必須とする権限設計・実装した際に少々苦戦したため、備忘録として本記事を執筆しました。

AWS Systems Manager（SSM）の Fleet Manager を使用して EC2 インスタンスに接続する際、アクセス拒否エラー（AccessDenied）に直面することがあります。
特に「IAM ユーザーに MFA（多要素認証）を必須としている」かつ「タグベースのアクセス制御を導入している」環境では、権限設定が複雑になりがちです。

これらのエラーを解消し、セキュアな接続環境を構築するための IAM ポリシー設定について解説します。

直面した課題とエラー内容

1. 初期パスワード変更・MFA設定時の権限不足

私は最初、新規ユーザー作成直後のMFA 未設定の状態ではMFAに関する操作以外はさせないというポリシーを書いていました。 以下のように、BoolIfExists: aws:MultiFactorAuthPresent: "false"とNotActionで、MFA未設定の時はMFAに関する操作以外はDenyをしていました。

実際には、MFAと設定時にはパスワード変更などのMFAとなの使ない操作が発生するので、この設定だとMFA デバイスの登録自体ができなくなるデッドロックが発生しました。

実際に操作をブロックしていたポリシー

- Sid: "DenyAllExceptListedIfNoMFA"
  Effect: Deny
  NotAction:
    - iam:CreateVirtualMFADevice
    - iam:EnableMFADevice
    - iam:ListVirtualMFADevices
    # ここにパスワード変更系の権限（iam:ChangePassword等）が不足していた
  Resource: "*"
  Condition:
    BoolIfExists:
      aws:MultiFactorAuthPresent: "false"

2. Fleet Manager 接続時の 403 エラー

MFA を有効化した後も、Fleet Manager から接続しようとすると以下のエラーが発生しました。

403: An error occurred (AccessDeniedException) when calling the StartSession operation

また、SSM のコンソール上で対象の EC2 インスタンスが表示されない、あるいは GUI 接続が拒否される事象も確認されました。

解決策：IAM ポリシーの最適化

1. MFA 必須ポリシーの「例外（NotAction）」を正しく設定する

MFA 未設定時でも、自身の認証情報を管理するための最小限の操作だけは許可する必要があります。Deny ステートメントの NotAction に以下の権限を追加します。

- Sid: "AllowUAManagementWithoutMFA"
  Effect: Deny
  NotAction:
    - iam:CreateVirtualMFADevice
    - iam:EnableMFADevice
    - iam:ListMFADevices
    - iam:ListUsers
    - iam:ListVirtualMFADevices
    - iam:ResyncMFADevice
    - iam:DeleteVirtualMFADevice
    - iam:DeactivateMFADevice
    - iam:ChangePassword        # 追加：初回ログイン時のパスワード変更に必要
    - iam:UpdateLoginProfile    # 追加：ログインプロファイルの更新に必要
    - iam:CreateLoginProfile    # 追加
  Resource: "arn:aws:iam::*:user/${aws:username}"
  Condition:
    BoolIfExists:
      aws:MultiFactorAuthPresent: "false"

2. セッション管理権限の分離とタグ指定

SSM の StartSession は、操作対象（EC2 インスタンス）と、使用するツール（SSM ドキュメント）の両方に権限が必要です。これらを分離して定義することで、タグベースの制御が正確に機能します。

ポイント：ssm:ResourceTag の使用

EC2 インスタンスを対象とする場合でも、SSM 経由の操作では ec2:ResourceTag ではなく ssm:ResourceTag を条件キーとして使用する必要があります。

# A. EC2インスタンスへの接続許可（タグベース制御）
- Effect: Allow
  Action:
    - ssm:StartSession
  Resource: !Sub "arn:aws:ec2:${AWS::Region}:${AWS::AccountId}:instance/*"
  Condition:
    Bool:
      aws:MultiFactorAuthPresent: "true"
    StringEquals:
      ssm:ResourceTag/System: "my-app-name"

# B. SSMドキュメントへのアクセス許可
- Effect: Allow
  Action:
    - ssm:StartSession
  Resource: 
    - "arn:aws:ssm:*:*:document/AWS-StartSSHSession"
    - "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession"
    - "arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
  Condition:
    Bool:
      aws:MultiFactorAuthPresent: "true"

# C. 自身のセッション管理（終了・再開）
- Effect: Allow
  Action:
    - ssm:TerminateSession
    - ssm:ResumeSession
  Resource: !Sub "arn:aws:ssm:*:*:session/${aws:username}-*"

構築時の重要な注意点

  1. タグ条件キーの正確性 Fleet Manager（SSM）経由で EC2 にアクセスする場合、IAM は SSM サービスとしてのコンテキストで評価されます。そのため、条件キーは ec2:ResourceTag ではなく ssm:ResourceTag を選択してください。

  2. リソースごとの分離 ssm:StartSession アクションは、Resource に「インスタンス ARN」と「ドキュメント ARN」の両方を必要とします。一箇所にまとめるとタグ条件がドキュメント ARN に対してミスマッチとなり、エラーの原因になります。

  3. 明示的な拒否（Deny）の優先順位 IAM では、どれだけ Allow が設定されていても、一つの Deny があれば拒否が優先されます。MFA 必須ポリシーを運用する場合は、NotAction のメンテナンスが非常に重要です。

CloudFormation テンプレート（抜粋）

Resources:
  SSMUserGroup:
    Type: AWS::IAM::Group
    Properties:
      GroupName: "fleet-manager-access-group"

  FleetManagerPolicy:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName: "FleetManagerAccessPolicy"
      Groups:
        - !Ref SSMUserGroup
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Action:
              - ec2:DescribeInstances
              - ssm:DescribeInstanceInformation
              - ssm:GetConnectionStatus
            Resource: "*"
            Condition:
              Bool: { "aws:MultiFactorAuthPresent": "true" }
          
          - Effect: Allow
            Action: ["ssm:StartSession"]
            Resource: !Sub "arn:aws:ec2:${AWS::Region}:${AWS::AccountId}:instance/*"
            Condition:
              StringEquals: { "ssm:ResourceTag/System": "my-service-dev" }
              Bool: { "aws:MultiFactorAuthPresent": "true" }

          - Effect: Allow
            Action: ["ssm:StartSession"]
            Resource: "arn:aws:ssm:*:*:document/AWS-*"
            Condition:
              Bool: { "aws:MultiFactorAuthPresent": "true" }

まとめ

AWS Fleet Manager での接続トラブルの多くは、「MFA の有無による評価」と「リソースタイプごとの条件キーの不一致」に集約されます。

  • MFA 未設定時の自己管理権限を NotAction で確保する
  • インスタンス接続には ssm:ResourceTag を使用する
  • インスタンスとドキュメントのリソース定義を分ける

これらを押さえることで、安全かつスムーズな運用が可能になります。

参考資料

遠藤 広也
(エンジニアブログ記事一覧)
(サバワク記事一覧)

アプリケーションサービス本部

2024年中途入社 アプリケーションサービス本部にてAWSを活用したアプリケーション開発に携わっています！
趣味はお酒とバンドです