AWSのアカウント管理の話

　　AWS Advent Calendar 2014の7日目です。あと、全部俺Advent Calendarも開催中です。

　運用絡みで何か書くと宣言したので、AWSのアカウント運用について書いてみます。テクニックや技術より、考え方の面での整理です。

AWSのアカウントの種類

　AWSで利用するアカウントは２種類あります。AWSアカウントとIAMアカウントです。AWSアカウントは、マスターアカウントと呼ぶこともあって大元のアカウントになります。AWSにサインアップ時に作るものが、AWSアカウントで１つだけ存在します。それに対して、IAMアカウントはユーザアカウントです。AWSの管理コンソールから、個々のユーザ向けなどに作成します。

AWSアカウントの取扱について

　AWSアカウントは、全権限を持っています。強力すぎるアカウントで、日常の運用に利用するには危険すぎます。日常の運用には使わないというのが基本となります。また、デフォルトではメールアドレスとパスワードのみで認証となります。アカウント作成した段階で、二要素認証の導入を強く推奨します。
　AWSでの二要素認証には、ハードウェアまたは仮想MFAデバイスを利用できます。ハードウェアについては、AWSのページから購入可能です。現在は、キータイプのものとカードタイプのものの２種類が購入可能です。仮想MFAデバイスについては、スマホやPCにインストールして利用します。iOSであれば、GoogleのAuthenticatorなどがあります。PCの場合は、Chromeの拡張などを利用すると便利です。
　AWSアカウントのMFAの選定については、どのような利用をするかがポイントになります。何故ならAWSアカウントには、接続元のIPアドレス制限が出来ません。その為、特定の場所からのみしか接続できないという運用を確実に行うには、物理MFAを設定して持ち運べないようにする必要があります。具体的なアドバイスとしては、金庫を買って放り込んでおくのが確実です。

IAMアカウントの取扱について

　IAMについては、IAMユーザとIAMグループ、IAMロールがあります。IAMユーザは個々のユーザに配布するもので、上の方でIAMアカウントと呼んでいたものです。IAMグループは、IAMユーザに所属させることにより一括で権限管理が出来るようになります。IAMロールはインスタンスに紐付けるものです。
　AWSを運用する上では、IAMの利用が基本となります。まずIAMユーザとグループの使い分けですが、組織で利用する上ではIAMユーザには基本的には認証の情報のみ設定し、権限に関する情報を付与しない方が良いと思います。理由としては、ユーザごとの設定で漏れなどを発生する確率を少しでも下げるためです。またそれ以前のAWSの仕様として、IAMユーザに付与できるポリシーのバイト数がIAMグループより小さいということがあります。その為、IAMユーザには複雑なポリシーを付与しにくいです。図でまとめると次のような形になります。

f:id:dkfj:20141207014716p:plain

IAMのポリシー設計について

　IAMで利用できるリソース等をIAMポリシーと呼びます。ポリシーについては、許可（Allow）/禁止（Deny）を組み合わせて記述します。記述の際には、３つの原則を理解しておく必要があります。

初期状態では、どの機能も利用することが出来ない（デフォルト拒否）
許可を付与することで、指定されたリソースが利用できる
同一の条件で、許可と禁止の両方を指定された場合は禁止になる（明示的拒否の優先）

　マトリックスにすると、次のようになります。

f:id:dkfj:20141207020558p:plain

　じゃぁ必要なものだけ単純に許可していけば良いかというと、そうでもなかったりします。例えば、EC2やS3といったサービスレベルであれば、それでも問題はないです。しかし、EC2のネットワーク機能を除いてといったことをすると、途端にややこしくなります。方法としては、EC2の機能を全部許可した上でネットワークに関するアクションを明示的に拒否していく（Allow-Deny）か、ネットワーク以外のアクションを許可していくということで実現できます。許可制の場合であれば、アクションが増える度に追加していく必要があり面倒くさいです。かつ、アクションが増えても明示的にアナウンスされることはないです。それならば、Allow-Denyで行くかというと都合が悪いケースもあります。
　例えば、機能単位でグループを作っていって、複数のグループに所属させることによってユーザの権限の強弱をつける場合があります。この場合のメリットとしては、個々のグループのポリシーをシンプルに保てるという点にあります。しかし、この方法だと拒否優先の原則が有るために、グループ重ねの効力が発揮されないケースが出てきます。

　そんな時に重宝するのが、NotActionです。NotActionは、指定されたものを反転して許可します。Allow-Actionでec2を指定した場合は、ec2が許可されます。Allow-NotActionでec2を指定した場合は、ec2以外の全てのリソースが許可されます。ややこしいので図にすると次のような形になります。
f:id:dkfj:20141207022153p:plain

　それぞれのポリシーは、次のような形です。

{
  "Statement":[
    {
      "Effect":"Allow",
      "Action":"ec2:*",
      "Resource":"*"
    }
  ]
}
{
  "Statement":[
    {
      "Effect":"Allow",
      "NotAction":"ec2:*",
      "Resource":"*"
    }
  ]
}