はじめに
自社のAWS環境のリソースを協力会社などの方に一部委ねて触ってもらう際に利用できる、IAMロールによる権限付与の方法です。
概要
社外からアクセスする人それぞれに自社のIAMユーザーを付与する方法もありますが、協力会社のAWSにIAMロールで自社AWSへのアクセス権を提供する方法がお勧めです。IAMユーザーを利用するのに比べて下記のようなメリットがあります。
- IAMユーザーのパスワードやアクセスキーの管理を相手に委ねることができて、ID管理の手間が減る。
- 招かれる側も複数のIDとパスワードを使い分ける必要が無いので手間が減る。
設定
下記のような前提でawsが2アカウントがあると仮定します。
| アカウント | ID | 内容 |
|---|---|---|
| aws-a | 111111111111 | 自社のアカウント。外部から招く側。 |
| aws-b | 222222222222 | 他社のアカウント。招かれる側。 |
awsのアカウントIDは12桁の数字です。
aws-aの設定
外部アクセス用のロールを作成して、そこに委ねたい権限のポリシーをアタッチします。
社外からアクセスされるためのロールを作成する
コンソールから下記のタイプのロールを選択し
別のAWSアカウントを選択してaws-bのアカウントIDを指定します。下記のオプションを設定することができます。
- 外部 ID を要求する
- cli等のプログラムアクセス時に、接続先を明確にするためにキーワードを指定します。外部IDなしでは接続できませんが、パスワードではありません。
- MFA が必要
- aws-bのコンソールにMFAでログインしたユーザーだけを受け付けます。これを設定しておくと、結果的に協力会社内でのパスワード漏洩の対策にもなりますし、IAMユーザーの使いまわしもほぼ防ぐことができます。
MFAアクセスだけを設定すると下記のようになります。ロールの名前は会社名やプロジェクト名にするとよいと思います。
[role] ex-for-aws-b
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::222222222222:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
このロールにaws-bから必要な操作を許可するポリシーをex-for-aws-bにアタッチします。必要最低限のポリシーに絞って提供するようにしましょう。
aws-bの設定
ポリシーを作って対象のIAMユーザーにアタッチします。
社外からアクセスするためのポリシーを作成する
aws-aで作ったロールを引き受けるためのポリシーを作成します。
[policy]get-access-aws-a
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111111111111:role/ex-for-aws-b"
}
]
}
aws-aにアクセスさせたいIAMユーザーにポリシーをアタッチします。
アクセス
- aws-bでポリシーがアタッチされたIAMユーザーでログインします。
- ロールの切替を行います。
- aws-aが利用できるようになります。
この設定ではaws-bのログイン時にMFAが設定されていない場合、スイッチロールができません。
アクセスログの確認
CloudTrailでイベント履歴をユーザー名で検索すると、だれが何を行っているか分かるので、チェックできるようにしておきましょう。
おわりに
設定は簡単なので、社内で複数のAWSアカウントを利用する場合にも有用だと思います。
参考文献