この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
よく訓練されたアップル信者、都元です。今日もIAMです。
先日のエントリで、プロジェクトメンバーにはIAMユーザを配布しましょう、というプラクティスを示しました。ではそのIAMユーザの権限はどの程度与えれば良いのでしょうか、というのが今日のテーマ。先に断っておきますと、このエントリーは結論が出ません。非常に難しいです。では、いきましょう。
AWSは「よくあるポリシー」としていくつかのテンプレートを提供してくれています。
上記の他に、UI上で様々なポリシーテンプレートが利用できるようになっています。これらの権限をいくつか見ていきましょう。
プロジェクトメンバー全員にAdministratorAccess権限を与えると…
AdministratorAccessというのはコレです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}要するに何でもできる権限です。さてこの権現は一見大きな問題はなさそうです。EC2やRDS、CloudFormatuon、Beanstalk等、あらゆるリソースが利用でき、スムーズに開発・運用が進められそうですね。組織が完全にフラットで、メンバー相互で信用がある場合は、特に問題は無いと思います。
ただ、冷静に考えると「IAMアカウントの新規発行や削除の権限」や「パスワードのリセット権限」等についても、全員が持っていることになります。平たくいえば、他人のアカウントのパスワードを変更して乗っ取りができます。信頼関係に不安があったり、組織がフラットではない *1場合、管理上の問題が発生することが予想されます。
プロジェクトメンバーにPowerUserAccess権限を与えると…
PowerUserAccessというのはコレです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"NotAction": "iam:*",
"Resource": "*"
}
]
}これはテンプレの中で2番目に強い権限を持ったポリシーで、IAM以外の操作が全て行えます。アカウント管理者だけがAdministratorAccessを持ち、一般メンバーはPowerUserAccessを持つ、という体制によって、前述の問題は解決します。しかし、別の問題が発生してしまいます。
IAMのアクションが実行できないとできなくなることが、結構多いのです。
- 自分のパスワードが変更できない。MFAの設定もできない。
- 自分のアカウントのアクセスキーを発行・削除できない。
- ELB等で利用するサーバ証明書のアップロード・削除等ができない。
これらが出来ないと、IAMアカウントの自己管理が難しいですね。また、サーバ証明書については、開発運用タスクにも稀に影響がありそうです。ただ、これらはポリシーをカスタムすることで、何とか乗り越えられます。1つ目の「自分のパスワード変更」や「MFA管理」が出来るようにするには下記のようなポリシーが使えます。
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"NotAction": "iam:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [ "iam:ChangePassword" ],
"Resource": "arn:aws:iam::(アカウントID):user/${aws:username}"
},
{
"Effect": "Allow",
"Action": [ "iam:*MFADevice" ],
"Resource": "arn:aws:iam::(アカウントID):mfa/${aws:username}"
},
{
"Effect": "Allow",
"Action": [ "iam:Get*", "iam:List*" ],
"Resource": "*"
}
]
}上記ポリシーは、2015年8月時点で試したところ、上手く動かなかったようです。対応についてはIAMユーザ本人にMFAを管理してもらうためのIAMポリシーを御覧ください。
同じようにカスタムすれば「自分のアクセスキー管理」や「サーバ証明書管理」もポリシーに記述できると思います。
しかし、もっと問題なのが…。
- IAM Roleが作れない。IAM Roleの権限調整もできない。
- IAM Roleを管理者に作ってもらったとしても、それを付与してEC2を起動できない。
これは結構痛いですね。IAM Roleが使えないとなると、開発にだいぶ大きな影響が出ます。確かに、IAM Roleが作れたり、IAM Roleを適用したインスタンスが作れてしまうと、「自分の持つ権限を超えた権限をEC2に与え、EC2経由で悪事を働く」ことができてしまうので、これらのアクションが禁止されているのでしょう。
まとめ
まぁ「メンバーの悪事を疑う」ような状況は、IAM云々ではなくてそもそもさぁ…、って話ではあると思います。ただ、そういう状況ではなかったとしても、「不必要な権限を持たない」ことは「疑われない」ための自己防衛手段でもあります。例えば複数の会社が共同で作業するようなAWS環境では、トラブル発生時に「自分たちの責任ではないこと」を「権限が無いこと」を以って証明したいという機会もあるかもしれません。悪意の無い人にとっては、要らない権限は是非とも持ちたくないものなのです。
ただし、「開発運用を阻害せずに、悪事は出来ないようにする」という条件を満たす権限ポリシーの設計は非常に大変ですし、私の現在の知識の範囲内では「とことんカンペキで理想的なポリシーは作れないような気がする」という結論に至っています。従って結局は、メンバーがAdministratorAccessを持ち、万一のトラブル発生時にはCloudTrailのログによって自分たちの責任ではないことを証明する、という体制が現実的なのかなぁ、と思っています。
この辺り、非常に制御が難しく、頭の痛い問題です。今日もまた、権限管理の闇を見た気分です。何か良いアイデアがあったら教えてください。
脚注
- 「アカウント管理者」がいて、アカウント発行・削除やパスワード紛失時の手続きは、その管理者を介して行う等 ↩
8
