[アップデート] AWS Sign-in がリソースベースポリシーに対応し、マネジメントコンソールへのサインインをネットワーク条件で制限できるようになりました
いわさです。
AWS マネジメントコンソールへのアクセスをネットワーク境界で制御したいケースは多いと思います。
従来は AWS Management Console Private Access で VPC エンドポイント経由のアクセスに限定し、エンドポイントポリシーでサインインできるアカウントを制限する方法がありました。
先日のアップデートではインターネット接続なしでもコンソールにアクセスできるようになり、閉域網での運用も現実的になっています。
Console Private Access は VPC エンドポイントの作成や DNS レコードの設定が必要なので、閉域網でのアクセスが求められるケースに適しています。
一方で、「オフィスの IP アドレスからだけサインインさせたい」のようにライトに接続元を制限したいケースも結構あると思います。
こうしたケースでは IAM ポリシーで aws:SourceIp 条件キーを使って API 操作を Deny する方法がありましたが、これはサインイン自体はブロックせず、サインイン後のコンソール操作が拒否される挙動でした。
今回のアップデートで、AWS Sign-in がリソースベースポリシーをサポートし、マネジメントコンソールへのサインイン自体を送信元 IP アドレスや VPC の条件で直接制限できるようになりました。
IAM ポリシーとの違いは、サインインの認証フロー自体がブロックされてコンソールに入ること自体ができなくなる点です。
リソースベースポリシーは個別の AWS アカウント単位で適用できます。
VPC エンドポイントの設定なしに、送信元 IP アドレスだけでサインインを制限できるのがポイントですね。
Console Private Access と組み合わせることで、「どのネットワークからサインインできるか」と「どのアカウントにアクセスできるか」の両方を制御することも可能とのことです。
なお、今回のポリシーはマネジメントコンソールへのサインインのみに適用され、アクセスキーを使った API 呼び出し(AWS CLI / SDK)には影響しません。
公式ドキュメントにも以下のように記載されています。
These controls do not apply to programmatic access using access keys (AWS SDKs or API calls signed with SigV4).
そのため、万が一 IP アドレスの設定を間違えてコンソールにアクセスできなくなっても、AWS CLI からポリシーの削除や設定変更で復旧が可能です。
今回こちらを確認してみたので紹介します。
リソースベースポリシーで単独アカウントに IP 制限をかけてみる
リソースベースポリシーを使って、単独の AWS アカウントに対してサインインの IP 制限をかけてみます。
設定は AWS CLI から行います。本日時点ではマネジメントコンソール上に設定画面は用意されていないようです。
なお、RCP を使えば Organizations で OU 単位に適用することもできるようですが、こちらは別の機会に試してみたいと思います。
前提
公式ドキュメントによると、設定には以下が必要とのこと。
- AWS CLI がインストール・設定済みであること
AWSSignInResourcePolicyManagement管理ポリシー相当の権限を持つ IAM ユーザーまたはロール- 書き込み系の操作はすべて
us-east-1リージョンを指定する必要がある(ポリシーは us-east-1 からグローバルにレプリケーションされる)
なお、AWS CLI のバージョンが古いと signin のサブコマンドが利用できないみたいです。
私の環境では v2.34.63 では認識されず、v2.35.6 にアップデートしたところ利用できるようになりました。
リソースパーミッションステートメントの作成
自分のグローバル IP アドレスのみ許可するパーミッションステートメントを作成します。
aws signin put-resource-permission-statement \
--source-ip "203.0.113.5/32" \
--client-token $(uuidgen) \
--region us-east-1
{
"statementId": "aERNi/T4gHdlZ8aIcuWBjGJxEkzKxK/Cz3xWzrf9AdBcfonvAEBKJLKBFxvoymaa"
}
statementId が返ってきたら作成成功です。
--source-ip に指定した CIDR のネットワークからのみサインインが許可されるようになります。
なお、--excluded-principal パラメータで特定のプリンシパルをネットワーク制限から除外することもできますが、今回は設定しませんでした。
コンソール認可設定の有効化
パーミッションステートメントを作成しただけではポリシーは評価されません。
以下のコマンドでコンソール認可設定を有効化する必要があります。
aws signin put-console-authorization-configuration \
--target-id 123456789012 \
--region us-east-1
{
"targetId": "123456789012",
"scope": "ACCOUNT",
"consoleAuthorizationEnabled": true
}
consoleAuthorizationEnabled: true になれば有効化完了です。
この時点から、パーミッションステートメントの条件に合致しないネットワークからのサインインがブロックされます。
許可された IP からのサインイン確認
有効化後、許可した IP アドレスからマネジメントコンソールにサインインしてみます。


問題なくサインインできました。
許可されていない IP からのサインイン確認
次に、許可していない IP アドレスからサインインを試みます。

「Authentication failed / Invalid request」と表示されてサインインがブロックされました。
IP 制限が原因であることは明示されないようですね。
CLI での復旧
コンソールにはアクセスできなくなっていますが、CLI はポリシーの影響を受けないのでそのまま操作できます。
以下のコマンドで認可設定を無効化して復旧します。
aws signin delete-console-authorization-configuration \
--target-id 123456789012 \
--region us-east-1
{
"targetId": "123456789012",
"scope": "ACCOUNT",
"consoleAuthorizationEnabled": false
}
consoleAuthorizationEnabled: false に戻り、サインイン制限が解除されました。
復旧後、再びサインインできることも確認できました。

コンソールにアクセスできなくなっても CLI から復旧できることが確認できました。
スイッチロールの場合はどうなるか
別アカウント(A アカウント)にサインインした状態で、IP 制限をかけた B アカウントのロールにスイッチロールするとどうなるか試してみました。
A アカウントには今回のポリシーを設定しておらず、B アカウントにのみ IP 制限をかけています。
スイッチロールの操作は B アカウントで許可していない IP から行っています。
コンソール標準の「ロールの切り替え」
コンソール標準の「ロールの切り替え」機能を使った場合、制限された IP からでも B アカウントにスイッチロールできてしまいました。
コンソール標準のスイッチロールは既存セッション内での AssumeRole であり、サインインの認証フローを通らないためポリシーが評価されないようです。
ブラウザ拡張(AWS Extend Switch Roles)経由
一方、AWS Extend Switch Roles(ブラウザ拡張)を使ってスイッチロールした場合は「400 Bad Request」が表示されてブロックされました。

コンソール標準のスイッチロールとブラウザ拡張経由で挙動が異なる理由は不明ですが、ポリシーが評価されるタイミングやフローに違いがあるのかもしれません。
つまり、今回の Sign-in リソースベースポリシーはあくまでサインインのフロー(認証処理)に対して評価されるものであり、コンソール標準のスイッチロールのように既存セッション内で完結する操作には効かないみたいですね。
さいごに
本日は AWS Sign-in にリソースベースポリシーのサポートが追加されたので確認してみました。
手軽にマネジメントコンソールのサインインに制限を加えたい時にとても良いですね。
従来は IAM ポリシーなどで制御が必要でしたが、リソースベースポリシーで一括気味に設定できるのが良いです。RCPも対応しているみたいなので、特定の AWS アカウント群だけ IP アドレス制限を入れるみたいな使い方できますね。







