IAMによるAWS権限管理 – プロジェクトメンバーへの権限付与方針に潜む闇

#AWS IAM

#AWS

都元ダイスケ

2014.02.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

よく訓練されたアップル信者、都元です。今日もIAMです。

先日のエントリで、プロジェクトメンバーにはIAMユーザを配布しましょう、というプラクティスを示しました。ではそのIAMユーザの権限はどの程度与えれば良いのでしょうか、というのが今日のテーマ。先に断っておきますと、このエントリーは結論が出ません。非常に難しいです。では、いきましょう。

AWSは「よくあるポリシー」としていくつかのテンプレートを提供してくれています。

上記の他に、UI上で様々なポリシーテンプレートが利用できるようになっています。これらの権限をいくつか見ていきましょう。

2014-02-25_2020

プロジェクトメンバー全員に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のログによって自分たちの責任ではないことを証明する、という体制が現実的なのかなぁ、と思っています。

この辺り、非常に制御が難しく、頭の痛い問題です。今日もまた、権限管理の闇を見た気分です。何か良いアイデアがあったら教えてください。