【AWS】IAMかんたん入門

# IAMとは
>AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスを安全に管理するためのウェブサービスです。IAM を使用して、リソースを使用するために認証 (サインイン) され、許可された (アクセス許可を持つ) ユーザーを制御します。

参考：[IAM とは](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction.html)
AWSのリソースへアクセスするための権限管理はIAMで行います。
例えばログインアカウントの作成や、プログラムからAWSのリソースへアクセスするためにキーの発行を行います。
AWSへのアクセスの管理を行うにはIAMの利用が必須となります。


## ユーザー
まずユーザーには2種類存在します。

- AWS マネジメントコンソールへのアクセス
- プログラムによるアクセス

の2種類です。

### AWS マネジメントコンソールへのアクセス
これは文字通りAWSコンソールへログインするためのユーザー（アカウント）となります。基本的には人に紐づくアカウントとなっており、一人に付き一つアカウントを発行することが推奨されています。
一つのアカウントを発行して、それを全員で使うことも可能ですが、以下の点で問題となります。

- 誰がいつログインしたかわからない
- 権限管理ができない


例えばEC2のフルの権限を全員に渡すこととなり、意図せずインスタンスを削除したり立ち上げたりということが行われてしまいます。
また上記のような事が起きても誰がやったのか全く履歴からわからないという事態となるため、必ず人ごとにユーザーを発行することが推奨されます。

### プログラムによるアクセス
プログラムによるアクセスは文字通りPHPやPythonなどのプログラムからアクセスするためのユーザーです。プログラムによるアクセスするだけのユーザーはAWSコンソールへはログインができません。
こちらもプログラムごとにユーザーを発行することが推奨されます。

## ロール
ユーザーとロールの違いが最初分かりづらいのですが、ロールは人ではなくAWSリソースに紐付いて権限管理ができます。
たとえばAWS Glueを利用してETL処理を書く時いS3への権限管理が可能となります。
S3へのフルアクセスを渡すことも可能ですし、読み取りだけ、書き込みだけ、特定のバケットだけにアクセスすることを制限可能です。

ロールは認証情報（パスワードやキー）が存在しません。ロールは特定の誰か（サービス）にではなく、必要に応じて誰でも引き受ける事のできるものとなっています。

後述しますが、スイッチロール[Switching to a Role](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)することで、ユーザーに一時的に別の権限を与えるロールも作成が可能です。

## グループ
>IAM グループとは、IAM ユーザーの集合です。グループを使用すると、複数のユーザーに対してアクセス許可を指定でき、それらのユーザーのアクセス許可を容易に管理することができます。たとえば、Admins というグループを作成し、管理者が一般的に必要とするようなアクセス許可をそのグループに付与できます。そのグループのすべてのユーザーは、そのグループに割り当てられたアクセス権限を自動的に取得します。管理者権限を必要とする新しいユーザーが組織に参加した場合、そのユーザーを Admins グループに追加することで、適切な権限を割り当てることができます。同様に、組織内で、あるユーザーの担当業務が変わった場合、そのユーザーのアクセス権限を編集する代わりに、そのユーザーを古いグループから削除して適切な新しいグループに追加することができます。

参考：[IAM グループ](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_groups.html)
基本的にはグループは上記引用のままです。ユーザー一人ひとりに権限を付与していくことが可能ですが、ユーザーをグループに所属させ、そのグループに権限を与えることで一括に権限管理が可能となります。
例えばエンジニアというグループを作成し、EC2・RDS・S3のフルアクセスを与えることで一括で漏れなく、余計な権限を与えることもなく権限管理が可能となります。RDSの利用がなくなったら、エンジニアグループからRDSの権限を削除すれば簡単に変更が可能となります。
一方でCSというチームにはS3のリードオンリーの権限を与えることで、部署ごとにわかりやすく権限管理できます。
ユーザー一人ひとりに権限を与えると、ミスも発生しやすく、作業工数も大きくなります。

## ポリシー
ポリシーは権限自体の内容です。ポリシーはデフォルトでAWS側が設定しておいてくれていますが、全ての権限があるわけではありません。
例えばS3においては

- AmazonS3FullAccess
- AmazonS3ReadOnlyAccess


の2つが用意されており、S3にアクセスを全て許可する場合は`AmazonS3FullAccess`の権限を、読み取りだけなら`AmazonS3ReadOnlyAccess`の権限があります。
ただ書き込みだけの権限は用意されておらず、書き込みだけの権限が欲しい際はそのポリシーを作成する必要があります。
また読み取りだけだが、特定のバケットのみ読み取りを許可したい場合も`AmazonS3ReadOnlyAccess`だけでは達成できないのでそれ用のポリシーを作成する必要があります。
ポリシーはJson形式で作成しますが、0からJsonを記述することも可能ですし、ビジュアルエディタで権限を選んでいってJsonを生成する方法もあります。

## スイッチロール
あるユーザーでログインしている際にスイッチロールすることで、そのロール先の権限を一時的に得ることが可能です。例えば、普段はリードオンリーの権限でログインしているが、一時的にインスタンス作成や設定の変更などで、admin権限がほしいときは、その権限を用意したロールにスイッチロールすることで、別アカウントでログインすることなく別の権限を得ることが可能になります。
ロールにアクセスできるユーザーは制限可能です。

またスイッチロールは別のAWSアカウントのロールでも可能です。複数AWSアカウントを運用している際に、単純にログイン・ログアウトの手間が面倒な際に利用することもできます。

ロールした履歴を残すことも可能なので、ロールをユーザーごとに作る必要はありません。

## AWS CloudTrail
これはIAMではなく別サービスのAWS CloudTrailの紹介です。
>CloudTrail を使用すると、AWS インフラストラクチャ全体でアカウントアクティビティをログに記録し、継続的に監視し、保持できます。

つまりCloudTrailを設定していると誰がいつどのAPIを利用したのかがログとして残るようになります。CloudTrailを利用していたとしても、全員が同じIAMユーザーを利用していた場合は"誰が"という部分がわからなくなってしまうので、再度になりますが必ずユーザーは分けましょう。
ログはS3にファイルとして保存されます。Athenaを利用して解析すると簡単に見ることができます。

## S3バケットポリシー
S3にアクセスできるユーザーの設定はIAMユーザーに対してだけでなく、バケット自体にも設定が可能です。
設定可能な内容は基本同じなので、どちらにも権限内容を書くことができます。
拒否設定はどんな許可設定があっても拒否可能となるので、絶対にアクセスさせたくない場合などは拒否設定をバケットポリシーに記述するのがいいかもしれません。

[S3バケットポリシーであるユーザーを特定のバケットにしかアクセスできないように設定する](https://qiita.com/YujiHamada3/items/821e19a95aa4760cf889#%E8%A8%B1%E5%8F%AF%E3%81%BE%E3%81%9F%E3%81%AF%E6%8B%92%E5%90%A6%E3%81%AE%E6%B1%BA%E5%AE%9A%E3%81%AE%E4%BB%95%E6%96%B9)
上記リンク先でバケットポリシーの書き方や考えを記載しています。


## 基本のセキュリティ対応
IAMのダッシュボードを開くと以下の5点は対応する用意という注意が書かれています。

### ルートアカウントの MFA を有効化
多要素認証、IDパスワード以外に別の端末も認証に使うことでセキュリティを高めます。ルートアカウントにまずMFAを適用することを勧めています。

### 個々の IAM ユーザーの作成
上述しましたが、IAMユーザーは共用ではなく、必ず一人ひとりに割り当てます。

### グループを使用したアクセス許可の割り当て
こちらも上述の通り、グループを利用して、一人ひとりに直接権限を与えません。

### IAM パスワードポリシーの適用
IAMのパスワードの要件を決めます。何文字以上・記号を含むか…などの条件です。

### アクセスキーのローテーション
アクセスキー（プログラムからアクセス）を定期的に変更します。

## IAMの定期チェック
ユーザー一覧ページをみると、ユーザー名の他に

- アクセスキーの古さ
- パスワードの古さ
- 最後のアクティビティ

の3点も表示されています。アクセスキーはアクセスキーの古さはローテーションでも述べたように、古くなっている場合はキーのローテーションを検討しましょう。明確にローテーションしべき期間は決まっていない（AWSエンジニアにも確認しましたが、一概には決められないそう）のですが、画面上では1年を超えると赤く表示されます。少なくともそれを目安にローテーションをさせましょう。
パスワードの古さも同様で、あまりにも長期期間変更されていないのであれば変更したほうがいいかもしれません。
最後のアクティビティは最後にログインなどの利用があった日からどれくらい経過したかです。長期期間利用されていないアカウントは削除など検討すべきと思われます。