AWS IAM Roles Anywhere実践入門｜PKI証明書でオンプレワークロードにAWSアクセスを付与しアクセスキーを排除する設計ガイド

オンプレサーバーからAWSにアクセスするとき、IAMアクセスキーを設定ファイルに書き込んで運用していないだろうか。EC2やLambdaならインスタンスプロファイルで解決できるが、データセンターの物理サーバーや自社のJenkinsには「サービスに紐付いた一時認証」は存在しない。その結果、長期有効なアクセスキーを共有・使い回す運用が続きがちだ。

この記事では、PKI（公開鍵基盤）のX.509証明書を使ってオンプレワークロードにAWSの一時認証情報を発行する AWS IAM Roles Anywhere を解説する。Trust Anchor・Profile・Roleの3つの設定要素から、aws_signing_helper による認証情報の自動取得まで、アクセスキーを排除する設計の実践手順を順を追って説明する。

なぜIAMアクセスキーをオンプレに残してはいけないのか

AWSはIAMのベストプラクティスとして「長期認証情報（アクセスキー）を使わない」ことを推奨している。クラウドリソースであればEC2のインスタンスプロファイル、LambdaやECSのサービスロールで透過的にSTSトークンを取得できる。これらはAWSのインフラ側が一時認証情報を自動的に割り当てる仕組みであり、エンジニアがキーを管理する必要がない。

一方、オンプレの物理サーバーや他クラウドのVMには同等の仕組みが存在しないため、どうしてもアクセスキーを使わざるを得ない状況が生まれやすい。長期有効なアクセスキーは次のようなリスクをはらんでいる。

・漏洩すると無期限で悪用される：アクセスキーには有効期限がなく、漏洩が判明するまでAWSへのアクセスを許してしまう。
・Gitリポジトリへの混入事故が繰り返される：設定ファイルや環境変数ファイルにキーを書き込み、誤ってコミットする事故が後を絶たない。
・ローテーションが手動で煩雑：複数サーバーで同じキーを使い回している場合、切り替え作業が大規模になりやすい。
・CloudTrailでの追跡粒度が粗い：IAMユーザー単位の記録になるため、どの物理サーバーが操作したかを特定しにくい。

AWS IAM Roles Anywhereとは

AWS IAM Roles Anywhereは2022年7月に一般提供が開始されたサービスだ。AWS外のワークロードがX.509証明書を使ってIAM Roles Anywhereに認証し、指定したIAMロールの一時認証情報（STSトークン）を取得できる。

「EC2のインスタンスプロファイルをオンプレに拡張したもの」と理解するのが最もわかりやすい。証明書で身元を証明し、事前に紐付けたIAMロールの一時トークンを発行してもらう流れだ。発行されたトークンにはデフォルトで1時間の有効期限があり、期限後は再取得する。

認証の流れ（全体像）

技術的には次のような順序で処理される。

1. オンプレサーバー側にX.509クライアント証明書と秘密鍵を配置する。
2. aws_signing_helper（AWSが提供するOSSツール）が証明書と秘密鍵を使ってリクエストに署名し、IAM Roles Anywhereエンドポイントへ送信する。
3. IAM Roles Anywhereが証明書をTrust Anchor（登録済みCA証明書）に照らして検証する。
4. 検証が通ると、STSが一時認証情報（AccessKeyId・SecretAccessKey・SessionToken）を発行する。
5. クライアントはその一時認証情報でAWS APIを呼び出す。

3つの構成要素を理解する

IAM Roles Anywhereを設定する際、IAMコンソールまたはCLIで次の3つのリソースを作成する。

1. Trust Anchor（信頼アンカー）

「どのCAが発行した証明書を信頼するか」を登録するエンドポイントだ。認証局（CA）の証明書をここに登録することで、そのCAが発行したX.509証明書を持つクライアントを認証の対象にできる。

対応するCAは大きく2種類ある。

・AWS Private Certificate Authority（AWS Private CA）：AWSマネージドのプライベートCA。証明書のライフサイクル管理もAWS上で統合できる。詳細はAWS ACM Private CA設計入門を参照してほしい。
・外部CA：Microsoft ADCS（Active Directory証明書サービス）、HashiCorp Vault PKIエンジン、OpenSSLで構築した自己署名CAなど。既存のオンプレPKI基盤をそのまま活用できる。

2. Profile（プロファイル）

「どのIAMロールを、どんな条件で引き受けるか」を定義する設定だ。1つのTrust Anchorに複数のProfileを紐付けることができ、用途ごとに細かく権限を分けられる。

・ロールARN：このProfileから引き受けを許可するIAMロールの一覧
・セッション時間：発行する一時認証情報の有効期限（900秒～43,200秒。デフォルトは3,600秒＝1時間）
・セッションポリシー（任意）：ロールの権限をさらに絞るインラインポリシーを指定できる

3. IAMロール（Role）

実際のAWS権限を定義する通常のIAMロールだ。ただし信頼ポリシー（Trust Policy）に rolesanywhere.amazonaws.com をプリンシパルとして記述する必要がある点が通常のロールと異なる。

# IAMロールのTrust Policy（rolesanywhereからのAssumeRoleを許可する）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "rolesanywhere.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:rolesanywhere:ap-northeast-1:123456789012:trust-anchor/*"
        }
      }
    }
  ]
}

3つのアクション（sts:AssumeRole・sts:TagSession・sts:SetSourceIdentity）は必ずすべて含めること。sts:TagSession が不足するとRoles Anywhereがセッションタグを付与しようとして認証に失敗する（後述のよくあるつまずきの1つだ）。

セットアップの流れ

1. 証明書の準備

クライアント（オンプレサーバー）に割り当てるX.509クライアント証明書と秘密鍵を準備する。AWS Private CAを使う場合はAWSコンソールから発行できる。外部CAを使う場合は通常の証明書発行フローで取得し、サーバーの安全な場所（/etc/pki/ 等）に配置する。秘密鍵のファイルパーミッションは 600 に設定し、root以外が読めないようにしておくこと。

2. Trust Anchorの作成

# AWS CLIコマンド例（東京リージョン・ap-northeast-1）
# CA証明書をBase64エンコードしてTrust Anchorを作成する
CA_CERT_B64=$(cat ca-cert.pem | base64 -w 0)

aws rolesanywhere create-trust-anchor \
  --name "OnPremCA-TrustAnchor" \
  --enabled \
  --source "sourceType=CERTIFICATE_BUNDLE,sourceData={x509CertificateData=${CA_CERT_B64}}" \
  --region ap-northeast-1

3. IAMロールの作成

前述のTrust Policyを持つIAMロールを作成し、ワークロードが必要とする最小限の権限ポリシーを付与する。バックアップ用途なら s3:PutObject のみ、デプロイ用途なら ecr:GetAuthorizationToken と ecr:BatchGetImage のみ、という形で最小権限を徹底すること。

4. Profileの作成

# CLIでProfileを作成する例（セッション時間を1時間に設定）
ROLE_ARN="arn:aws:iam::123456789012:role/OnPremBackupRole"

aws rolesanywhere create-profile \
  --name "OnPremBackupProfile" \
  --enabled \
  --role-arns "${ROLE_ARN}" \
  --duration-seconds 3600 \
  --region ap-northeast-1

5. aws_signing_helperの設定

AWSが公開するOSSツール aws_signing_helper をサーバーにインストールし、~/.aws/config の credential_process として登録する。これにより、AWS CLIやSDKが自動的にSTSトークンを取得・更新するようになる。

# ~/.aws/config の設定例（credential_processで自動取得）
[profile onprem-backup]
credential_process = /usr/local/bin/aws_signing_helper credential-process \
  --certificate /etc/pki/client.crt \
  --private-key /etc/pki/client.key \
  --trust-anchor-arn arn:aws:rolesanywhere:ap-northeast-1:123456789012:trust-anchor/xxxxxxxx \
  --profile-arn arn:aws:rolesanywhere:ap-northeast-1:123456789012:profile/yyyyyyyy \
  --role-arn arn:aws:iam::123456789012:role/OnPremBackupRole \
  --region ap-northeast-1

# 使用例：--profile を指定するだけで自動的にSTSトークンが取得される
# aws s3 cp /backup/daily.tar.gz s3://my-backup-bucket/ --profile onprem-backup

credential_process を使うと、API呼び出しのたびに aws_signing_helper が自動実行され、トークンが期限切れならば自動再取得する。アプリケーション側でトークン更新ロジックを書く必要がなく、既存スクリプトのプロファイル指定を変更するだけで移行できる。

ユースケース別の設計パターン

1. オンプレ物理サーバーのS3バックアップ

最も典型的なユースケースだ。想定例として、毎晩バックアップジョブを実行するサーバー群にS3書き込み専用のロールを割り当てる設計を示す。

・各バックアップサーバーに個別の証明書を発行する（1枚の証明書を複数サーバーで共有しない）
・IAMロールにはバックアップ先S3バケットへの s3:PutObject のみを許可し、削除や読み取りは除外する
・証明書のCN（Common Name）がCloudTrailのセッション名として記録されるため、どのサーバーの操作かを後から追跡できる

2. オンプレCI/CDサーバー（Jenkins・GitLab Runner）のAWSデプロイ

GitHub ActionsのようなSaaS型CI/CDにはAWS OIDCが使えるが、自社ネットワーク内に設置したJenkinsや自己ホスト型GitLab Runnerにはそれが使えない。こうしたケースがRoles Anywhereの主要ユースケースの一つだ。

・JenkinsサーバーにCI/CD用の証明書を配置し、ECRやCodeDeployへのアクセス権限を持つロールを割り当てる
・本番デプロイ用と開発デプロイ用でProfileとロールを分け、それぞれに異なる最小権限を設定する
・Jenkinsが複数台ある場合は各台に固有の証明書を発行し、サーバー単位でデプロイ操作を追跡できるようにする

なお、GitHub ActionsなどのSaaS型CI/CDにはRoles AnywhereよりもAWS OIDC認証の方が設定がシンプルで証明書管理も不要だ。どちらを使うべきかは後述の比較表を参照してほしい。

3. マルチクラウド環境（他クラウドVMからのAWSアクセス）

GCPのCompute EngineやAzureのVMからAWSリソースにアクセスする場合にも活用できる。各VMに証明書を配置してRoles Anywhereを経由することで、マルチクラウド環境全体でアクセスキーを排除できる。なお、GCPやAzureには独自のWorkload Identity連携もあるため、アーキテクチャのシンプルさとトレードオフになる点は念頭に置いておく。

料金の考え方

IAM Roles Anywhere自体には追加料金はかかりません（2026年10月時点）。認証リクエスト数やSTSトークンの発行回数に関わらず費用ゼロで利用できる。コストが発生するのは証明書の発行に使うCAの部分だ。

Microsoft ADCSやHashiCorp VaultなどのオンプレCAを既に持っている組織であれば、IAM Roles Anywhereの運用コストは実質ゼロで導入できる。10台以下のサーバー向けにAWS Private CAを新設する場合でも、月額$1未満の費用でサービスを構築できる（証明書1枚あたり$0.005、CA固定費$0.75の計算）。

よくあるつまずきと対処法

つまずき1：Trust PolicyのAction不足でアクセス拒否

Roles Anywhereはセッションタグを付与する際に sts:TagSession を呼び出す。Trust Policyに sts:AssumeRole しか書いていないと即座にアクセス拒否になる。sts:AssumeRole だけ書いて詰まるのが最も多いパターンだ。必ず3つのアクション（AssumeRole・TagSession・SetSourceIdentity）をセットで記述すること。

つまずき2：証明書の有効期限切れによる無言失敗

X.509証明書には有効期限があり、期限が切れると認証が失敗する。よくある状況として、証明書の期限切れに気づかず深夜のバックアップジョブが無言で止まるケースがある。対処としては以下の2点を最初から組み込んでおく。

・証明書の有効期限をCloudWatchカスタムメトリクスやAWS Configのカスタムルールで監視し、30日前にアラートを出す
・aws_signing_helper は証明書の期限切れを検出すると非ゼロ終了コードを返すため、cronジョブの終了コード監視と組み合わせておく

つまずき3：中間CAを挟む構成での証明書チェーンエラー

中間CAが挟まるPKI構成では、Trust AnchorにルートCA証明書だけ登録すると中間CAが発行したクライアント証明書の検証が通らないことがある。Trust Anchorには証明書バンドル（ルートCA＋中間CA）を連結して登録するか、中間CAを直接Trust Anchorとして登録する構成を検討する。

AWS OIDC認証との使い分け

アクセスキーを排除するアプローチとして、AWS OIDC認証とRoles Anywhereがある。どちらも「アクセスキーなしでAWSに認証する」という目的は同じだが、向いているワークロードが異なる。

GitHub ActionsなどのSaaS型CI/CDにはOIDCが適しているが、インターネットに直接出られないネットワーク内のJenkinsや物理サーバーにはRoles Anywhereの方が現実的だ。ゼロトラストセキュリティの設計を進める上では、クラウドリソースはインスタンスプロファイル・サービスロール、SaaS型CI/CDはOIDC、オンプレ・自己ホスト環境はRoles Anywhereと使い分けることで、環境全体でアクセスキーを完全に排除できる。

本記事のまとめ

AWS IAM Roles Anywhereは「EC2のインスタンスプロファイルをオンプレに拡張する仕組み」だ。X.509証明書を使うため既存のCA基盤が活用でき、IAM Roles Anywhere自体には追加コストがかからない。

アクセスキー廃止はゼロトラスト移行の具体的な第一歩だ。まず影響範囲が小さいバックアップ用途や開発環境のCI/CDから試験導入し、段階的に対象を広げていくのが着手しやすい進め方だ。