開発をスムーズに行うための、たった 2 つの AWS/IAM プラクティス

2016年02月29日

もりもり / aws, iam, practice

はじめに

AWS を使った開発をしていて、こんな困ったことがありました。

○○を操作する権限が欲しいのに、IAM を操作できる担当者が捕まらなくて開発が進められない
特定のプロジェクトに関するリソースだけアクセス許可したいけど、○○にはリソースによる制限ができない
マネジメントコンソールを使えるようにしようと思うと、あまり権限を絞れない

これらによって、開発スピードが上がらないというのが大きな問題になりました。

さて、原因はなんでしょうか。

○○を操作する権限が欲しいのに、IAM を操作できる担当者が捕まらなくて開発が進められない
⇒ 開発者に権限が与えられていないから、権限を持った人に頼らなければならない
特定のプロジェクトに関するリソースだけアクセス許可したいけど、○○にはリソースによる制限ができない
⇒ 開発者にアクセスさせられないリソースがあるから、開発者の権限を絞らなければならない
マネジメントコンソールを使えるようにしようと思うと、あまり権限を絞れない
⇒ 開発者にアクセスさせられないリソースがあるから、開発者の権限を絞らなければならない

後ろの二つは同じ原因ですね。
つまり、開発者の権限を絞らなければならない環境だから、開発者に権限が与えられていないわけです。

ならば開発者の権限を絞らなくてもいい環境なら、開発者に権限を与えられるということで、次のプロジェクトでは 2 つの対策を講じてみました。

基本的には公式のベストプラクティスの通りなので、まずはこちらを読みましょう。

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html

2 つの対策

AWS アカウントをサンドボックスにする

つまり、プロジェクト毎に AWS アカウント自体を分けてしまいます。
これによって、その AWS アカウントの中ではリソースによる制限をかける必要がなくなるため、開発者の権限を絞らなくてもいい環境になります。

AWS アカウントを分けることによるデメリットは

Elastic IP の上限など、リソースの制限解除は AWS アカウント毎に行わなければならない
そのままだと請求が分かれてしまうので、必要であれば一括請求の設定をしなければならない

等が考えられますが、開発スピードを落とさないためには十分受け入れられるものだと思います。

この方針は、新規に開発を始める際にはいいのですが、既存の AWS アカウントに複数のプロジェクトを運用していて、そこから別の AWS アカウントに切り出すとなると、かなり大変だなぁというのが悩みどころです。
（DocBase はまさにこの悩みを抱えているところです。。。）

開発者はみんな Administrator

AWS アカウントをサンドボックスにしたことで、開発者に権限を与えられるようになったので、Administrator 権限を与えてしまいます。
公式の「最小限の特権を認める」というプラクティスを真っ向から否定してしまうようですが、開発をスムーズに行うためにはとても効果的です。
これによって、開発者は特権ユーザとなるため、「特権ユーザーに対して、MFA を有効化する」という公式のプラクティスも、開発者全員に適用することになります。

さらにもう 1 つ、以下の制限を課しています。

開発者用の IAM ユーザにはアクセスキーを発行しない

開発者には Administrator 権限を付与するので、その IAM ユーザでアクセスキーを発行すると、そのキーで全ての操作ができてしまいます。
万が一これが漏洩してしまった場合に影響が大きすぎるので、開発者用の IAM ユーザにはアクセスキーを発行しないようにします。
アクセスキーを使って操作する必要がある場合、別途必要な権限だけを与えた IAM ユーザを作成して、そのユーザに対してアクセスキーを発行します。