IAM Roles Anywhere で AWS IAM ロールを AWS 外部のワークロードに拡張する

この記事は Extend AWS IAM roles to workloads outside of AWS with IAM Roles Anywhere を訳したものです。

IAM Roles Anywhere のリリースの通り、AWS Identity and Access Management (IAM) を用いて AWS 外部で稼働しているワークロードに IAM ロールを簡単に使用できるようになりました。この機能は、IAM ロールの機能を AWS 外部のワークロードに拡張します。IAM Roles Anywhere を利用することで、オンプレミスのサーバー、コンテナ、またはアプリケーションが一時的な AWS クレデンシャルを取得するセキュアな方法を提供し、長い有効期間の AWS クレデンシャルを作成・管理する必要性を無くすことができます。

この投稿では、IAM Roles Anywhere の仕組みについて簡単に説明します。IAM Roles Anywhere のいくつかの一般的なユースケースについても触れます。そして最後に、この実装がどのように機能するかを示すために、シナリオの例をご紹介します。

背景

アプリケーションが AWS のサービスとリソースにアクセスするには、AWS API リクエストを行うための有効な AWS クレデンシャルをアプリケーションに提供する必要があります。AWS 上で動作するワークロードの場合、アプリケーションをホストしているコンピューティングプラットフォームに応じて、IAM ロールを Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、または AWS Lambda リソースに関連付けることによって行います。これは、AWS で実行されているアプリケーションの AWS クレデンシャルを配布・管理する必要がなく、セキュアで利便性の高い手法です。代わりに、IAM ロールは、アプリケーションが AWS API を呼び出すときに使用できる一時的なクレデンシャルを与えます。

IAM Roles Anywhere は、AWS 上のワークロードが IAM ロールを使用するのと同じ方法で、AWS 外部にあるアプリケーションが IAM ロールを使用して AWS API にセキュアにアクセスできるようにします。IAM Roles Anywhere により、短い有効期間のクレデンシャルを、オンプレミスのサーバー、コンテナ、または他のコンピューティングプラットフォームに対して提供できます。IAM Roles Anywhere を使用して短い有効期間のクレデンシャルを払い出すと、長い有効期間の AWS アクセスキーとシークレットを利用する必要がなくなり、セキュリティが向上し、長い有効期間のクレデンシャルを管理およびローテーションする運用オーバーヘッドが無くなります。さらに IAM Roles Anywhere を使用して、ハイブリッドワークロード間でクレデンシャル管理のための一貫したエクスペリエンスを備えることができます。
この記事では、IAM の基礎知識を持っていることを仮定しており、IAM ロールについては詳しく説明しません。IAM ロールの詳細は、IAM のドキュメントをご覧ください。

IAM Roles Anywhere の機能

IAM Roles Anywhere は、公開鍵基盤 (PKI) の上に成り立っており、AWS アカウントおよび、オンプレミスワークロードに対して証明書を発行する認証局 (CA) との間で信頼を確立します。AWS 外部のワークロードは、IAM Roles Anywhere を使って、X.509 証明書を一時的な AWS クレデンシャルと交換します。証明書は、IAM Roles Anywhere の信頼アンカー (trust anchor, root of trust) として登録した CA によって発行されます。CA は、既存の PKI システムの一部でもよく、あるいは AWS Certificate Manager Private Certificate Authority (ACM PCA) で作成した CA にすることもできます。

アプリケーションは、(証明書の中にエンコードされている) 公開鍵と、それに対応する秘密鍵で署名した認証リクエストを IAM Roles Anywhere に対して行います。アプリケーションはリクエストの中で、引き受けるロールも指定します。IAM Roles Anywhere はリクエストを受け、まず公開鍵で署名を検証し、さらに証明書が、アカウントにおいて事前に構成された信頼アンカーが発行したものであることを検証します。詳細は、署名検証のドキュメントをご覧ください。

両方の検証が成功すると、ついにアプリケーションは認証され、IAM Roles Anywhere は AWS Security Token Service (AWS STS) を呼び出すことで、リクエスト中で指定されたロールの新しいロールセッションを作成します。このロールセッションの実効権限は、対象となるロールのアイデンティティベースポリシーと、IAM Roles Anywhere で作成したプロファイル内のセッションポリシー (指定されている場合) の共通部分となります。他の IAM ロールセッションと同様に、アクセス許可境界 (Permission Boundary) やサービスコントロールポリシー (SCP) など、設定されている可能性のある他のポリシータイプにも従います。

通常は、異なるペルソナによって実行される 3 つの主要なタスクがあり、IAM Roles Anywhere のセットアップと使用に関係しています:

IAM Roles Anywhere の初期設定 – このタスクには、信頼アンカーの作成、IAM Roles Anywhere が引き受けるロールの信頼ポリシーの設定、およびロールプロファイルの定義が含まれます。これらのアクティビティは AWS アカウント管理者によって行われ、IAM ポリシーによる制限が可能です。
AWS 外部のワークロードへの証明書のプロビジョニング – このタスクでは、CA によって署名された X.509 証明書が、AWS との間で認証が必要な、AWS 外部のサーバー、コンテナ、またはアプリケーションにインストールされ利用可能であることを確実にします。この確認は、ご利用中のオンプレミス環境で、インフラストラクチャ管理者またはプロビジョニング実施者によって、通常は既存の自動化手法や構成管理ツールを用いて実行されます。
IAM Roles Anywhere の利用 – このタスクでは、クレデンシャルプロバイダチェーンを構成し、IAM Roles Anywhere クレデンシャルヘルパーツールを使用した証明書とセッションクレデンシャルとの交換ができるようにします。これは通常、AWS API によってやりとりを行うアプリケーションの開発者が実施します。

各タスクの詳細については、この投稿の後半にあるシナリオ例を通して説明していきます。

IAM Roles Anywhere の一般的なユースケース

IAM Roles Anywhere は、AWS API にアクセスするためのクレデンシャルを必要とする、データセンターや他のクラウドプロバイダで実行されている任意のワークロード向けにお使いいただけます。
これまでに見聞きしていた会話やパターンに基づいて、お客様が興味を持たれるであろうユースケースをいくつかご紹介します:

オンプレミスのデータを Amazon Simple Storage Service (Amazon S3) にバックアップする
オンプレミスの Kubernetes ワークロードに対して、Amazon DynamoDB や Amazon Simple Queue Service (Amazon SQS) などのネイティブ AWS サービスへのアクセスを提供する
AWS Secrets Manager に保存されているシークレットに対して AWS 外部のワークロードからアクセスする
オンプレミスのソースから AWS Security Hub にセキュリティ検出結果を送信する
ハイブリッドワークロードが段階的にマイグレーションしていく過程で AWS サービスにアクセスできるようにする

シナリオ例とウォークスルー

IAM Roles Anywhere が実際にどのように機能するかを示すために、S3 API を呼び出してデータセンター内のサーバーからデータをアップロードするという簡単なシナリオを見ていきましょう。

前提条件

IAM Roles Anywhere をセットアップする前に、次の要件を満たす必要があります:

独自の CA の証明書バンドル、または IAM Roles Anywhere と同じ AWS リージョン内のアクティブな ACM PCA の CA があること
オンプレミスのサーバーで使用可能なエンドエンティティ証明書および紐づいている秘密鍵
IAM ロールと IAM Roles Anywhere に対する管理者権限

セットアップ

ここでは、IAM Roles Anywhere コンソールを使用してセットアッププロセスを実行する方法を示します。代わりに AWS API またはコマンドラインインターフェイス (CLI) を使用して、これらのアクションを実行することもできます。ここでは、主に 3 つのアクティビティがあります:

信頼アンカーの作成
IAM Roles Anywhere を信頼するロールを作成および設定する
プロファイルを作成する

信頼アンカーを作成するには

IAM Roles Anywhere コンソールに移動します。
[信頼アンカー] で、[信頼アンカーの作成] を選択します。
[信頼アンカーの作成] ページで、信頼アンカーの名前を入力し、リストから既存の AWS Certificate Manager Private CA を選択します。または独自の外部 CA を使用する場合は、[外部証明書バンドル] を選択し、証明書バンドルを指定します。

図 1: IAM Roles Anywhere で信頼アンカーを作成

IAM Roles Anywhere を信頼するロールを作成および構成するには

AWSコマンドラインインターフェイス (AWS CLI) を使用して、オンプレミスサーバーが IAM Role Anywhere に対する認証後に引き受ける、適切な権限を持つ IAM ロールを作成します。以下の信頼ポリシーを rolesanywhere-trust-policy.json としてお使いのコンピューターに保存します。
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "rolesanywhere.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:SetSourceIdentity",
                "sts:TagSession"
            ]
        }
    ]
}
```
以下のアイデンティティベースポリシーを onpremsrv-permissions-policy.json として保存します。このポリシーは、指定された S3 バケットにオブジェクトを書き込むためのアクセス許可を、ロールに付与します。
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<DOC-EXAMPLE-BUCKET>/*"
        }
    ]
}
```

次の 2 つの AWS CLI コマンドを実行してロールを作成し、アクセス許可ポリシーをアタッチします。

aws iam create-role \
--role-name ExampleS3WriteRole \
--assume-role-policy-document file://<path>/rolesanywhere-trust-policy.json

aws iam put-role-policy \
--role-name ExampleS3WriteRole \
--policy-name onpremsrv-inline-policy \
--policy-document file://<path>/onpremsrv-permissions-policy.json

オプションで、X.509 証明書から抽出された属性に基づく条件ステートメントを使用して信頼ポリシーをさらに制限し、IAM Roles Anywhere からクレデンシャルを取得可能なオンプレミスリソースを制御することもできます。IAM Roles Anywhere は SourceIdentity 値をサブジェクトの CN に設定します (この例では onpremsrv01)。また、証明書に由来する属性を持つ個々のセッションタグ(PrincipalTag/) も設定します。したがって、信頼ポリシーの条件句のプリンシパルタグを認可の追加制約として使用できます。

たとえば、この投稿で使用する証明書の Subject は次のとおりです。
Subject: … O = Example Corp., OU = SecOps, CN = onpremsrv01

そして、信頼ポリシー（rolesanywhere-trust-policy.json）に以下のような条件文を追加することができます:

...
    "Condition": {
        "StringEquals": {
            "aws:PrincipalTag/x509Subject/CN": "onpremsrv01",
            "aws:PrincipalTag/x509Subject/OU": "SecOps"
        }
    }
...

詳細については、IAM Roles Anywhere のための信頼ポリシーをご覧ください。

プロファイルを作成するには

IAM Roles Anywhere コンソールに移動します。
[プロファイル] で [プロファイルの作成] を選択します。
プロファイルの作成ページで、プロファイルの名前を入力します。
ロールで、前のステップで作成したロール（ExampleS3WriteRole）を選択します。
オプションとして、セッションポリシーを定義して、IAM Roles Anywhere から引き渡されるセッションをさらにスコープダウンすることができます。これは、複数のロールでプロファイルを構成し、すべてのロールで横断的に権限を制限したい場合に特に便利です。必要なセッションポリシーは、マネージドポリシーまたはインラインポリシーとして追加することができます。ここではデモのために、指定したIPアドレスからのリクエストのみを許可するインラインポリシーを追加しています。

図2: IAM Roles Anywhere でのプロファイルの作成

これで IAM Roles Anywhere のセットアップは完了し、利用を開始することができます。

IAM Roles Anywhere の使用

IAM Roles Anywhere は、現在のすべての AWS SDK がサポートしているクレデンシャル処理機能を用いたクレデンシャルヘルパーツールを提供します。これにより、アプリケーションの署名プロセスが簡素化されます。クレデンシャルヘルパーツールの入手方法については、IAM Roles Anywhereのドキュメントをご覧ください

まずは機能を試すために、以下のようにオンプレミスサーバーからクレデンシャルヘルパーツール (aws_signing_helper) を手動で実行します。

./aws_signing_helper credential-process \
     --certificate /path/to/certificate.pem \
     --private-key /path/to/private-key.pem \
     --trust-anchor-arn <TA_ARN> \
     --profile-arn <PROFILE_ARN> \
     --role-arn <ExampleS3WriteRole_ARN>

図 3: クレデンシャル・ヘルパー・ツールを手動で実行する

IAM Roles Anywhere から、図3の例のように、セッションのクレデンシャルを正常に受け取ることができるはずです。設定が機能することを確認したら、~/.aws/config ファイルを更新または作成し、credential_process として署名を行うヘルパーを追加します。これで、オンプレミスサーバーが人を介在せずにアクセスできるようになります。AWS CLI の設定ファイルの詳細は、設定ファイルとクレデンシャルファイルの設定をご覧ください。

# ~/.aws/config content
[default]
 credential_process = ./aws_signing_helper credential-process
    --certificate /path/to/certificate.pem
    --private-key /path/to/private-key.pem
    --trust-anchor-arn <TA_ARN>
    --profile-arn <PROFILE_ARN>
    --role-arn <ExampleS3WriteRole_ARN>

設定が期待通りに動作するのを確認するために、aws sts get-caller-identity AWS CLI コマンドを呼び出して、引き受けたロールが IAM Roles Anywhere で設定したものであることを確認します。また、ロールセッション名には、認証に使用した証明書のシリアル番号（この例では cc:c3:...:85:37）が含まれていることが確認できるはずです。最後に、図 4 に示すように、S3 バケットにファイルをコピーすることができるようになっているはずです。

図 4: 引き受けたロールの確認

監査

他の AWS サービスと同様に、AWS CloudTrail は IAM Roles Anywhere の API コールをキャプチャします。先ほど実行したアクティビティに対応する CloudTrail のログエントリを見てみましょう。

まず興味深いログエントリーは CreateSession で、オンプレミスサーバーがクレデンシャルヘルパーツールを介して IAM Roles Anywhere を呼び出し、セッションクレデンシャルを受信して戻ってきたときのものです。

{
    ...
	"eventSource": "rolesanywhere.amazonaws.com",
    "eventName": "CreateSession",
    ...
    "requestParameters": {
        "cert": "MIICiTCCAfICCQD6...mvw3rrszlaEXAMPLE",
        "profileArn": "arn:aws:rolesanywhere:us-west-2:111122223333:profile/PROFILE_ID",
        "roleArn": "arn:aws:iam::111122223333:role/ExampleS3WriteRole",
        ...
    },
    "responseElements": {
        "credentialSet": [{
            "assumedRoleUser": {
                "arn": "arn:aws:sts::111122223333:assumed-role/ExampleS3WriteRole/00ccc3a2432f8c5fec93f0fc574f118537",
            },
            "credentials": {
                "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
                "expiration": "2022-07-06T00:46:43Z",
                "secretAccessKey": "HIDDEN_DUE_TO_SECURITY_REASONS",
                "sessionToken": "IQoJAQoDYXdzEJr..."
            },
            ...
            "sourceIdentity": "CN=onpremsrv01"
        }],
    },
    ...
}

証明書 cert と他のパラメータが IAM Roles Anywhere に送信され、ロールセッションと一時的なクレデンシャルがサーバに返却されていることがわかります。

次に確認したいのは、オンプレミスサーバーから行った s3:PutObject の呼び出しのログエントリです。

{
    ...
    "eventSource": "s3.amazonaws.com",
    "eventName": "PutObject",
    "userIdentity":{
        "type": "AssumedRole",
        "arn": "arn:aws:sts::111122223333:assumed-role/ExampleS3WriteRole/00ccc3a2432f8c5fec93f0fc574f118537",
        ...
        "sessionContext":
        {
            ...
            "sourceIdentity": "CN=onpremsrv01"
        },
    },
    ...
}

CloudTrail のログに加え、モニタリング用途に使えるメトリクスやイベントがいくつかあります。詳しくは、Monitor IAM Roles Anywhere をご覧ください。

その他注意事項

IAM Roles Anywhere の信頼アンカーを無効にすれば、AWS 外部のリソースに新しいセッションが発行されるのを直ちに停止することができます。証明書の失効は、インポートされた証明書失効リスト (CRL) の使用を通じてサポートされています。CA から生成された CRL をアップロードすると、認証に用いる証明書はその失効ステータスをチェックされます。IAM Roles Anywhere は、CRL 配布ポイント (CDP) または OCSP (Online Certificate Status Protocol) エンドポイントへのコールバックをサポートしていません。

IAM Roles Anywhere に限ったことではありませんが、秘密鍵を適切なファイルシステムの権限でサーバーに安全に保存していることを確認することも考慮しなければなりません。

まとめ

この投稿では、新しい IAM Roles Anywhere サービスが、AWS 外部のワークロードをどのようにセキュアかつ利便性高く AWS API とやりとりできるようにするか説明しました。IAM ロールの機能を AWS 外部で動作するサーバ、コンテナ、またはアプリケーションに拡張すると、長い有効期間のAWS クレデンシャルの必要性を無くすことができます。つまり、配布、保存、ローテーションのオーバーヘッドがなくなるということを意味します。

IAM Roles Anywhere の一般的なユースケースをいくつか紹介しました。また、セットアッププロセスや、IAM Roles Anywhere を使用して短い有効期間のクレデンシャルを取得する方法についても説明しました。

もし質問があれば、AWS re:Post で新しいスレッドを立ち上げるか、AWS Support にご連絡ください。

翻訳はセキュリティソリューションアーキテクト勝原が担当しました。原文はこちらです。

Amazon Web Services ブログ