AWSのIAMベストプラクティスをちゃんとやる(見る)
IAM のベストプラクティスをちゃんと理解しようというお話。
目的
このエントリでは、細かいやり方は書かない。 (ドキュメントを見ればいいし、コンソールを開けばわかる) こういうことをしたほうがいいんだよ。という内容を把握し、いざ、必要な時がきたときに知ってるいる状態にすることが目的
対象読者
- AWSはEC2とかたてたりするけど、*1ルートアカウントでコンソールをいじってる人
- EC2にIAMインスタンスプロファイルのロールを付けるとは??な人
- 権限とか難しいから、フルアクセス付けてるよ?な人
IAMとは?
AWS Identity and Access Management (IAM)
の略
アイアムって読んでます。(正しいかは知らない)
IAMを使うと、どんな事ができるのか
- ルートアカウント以外にアカウントを作成できる。
- 作成したアカウントに対して、*2リソースごとにアクセスを制限できる
ルートアカウントを共有しない。 フルアクセス権限を全員に渡さない。 誰が何のリソースをどこまで操作できるか。を制限しよう。 というのがIAMを使う理由の認識です。
やること
AWS アカウント(ルート)のアクセスキーをロックする
ルートアカウントはすべての権限があるため、 ルートアカウントの権限を用いて、AWSコマンド等を使用すると、請求情報まで取得できる。 見られて困るものは、見れないようにしましょうね。という話し
- アクセスキーを持ってるなら削除する
- IAMで、管理権限を持つユーザーを作成する。
- ルートアカウントのパスワードは強度の高いものを設定しよう。
- ルートアカウントにMFAを設定する。
個々の IAM ユーザーを作成する
AWSにアクセスする必要がある場合は、IAMでユーザーを作成する。 IAMユーザーのアクセス許可は、いつでも、有効、無効にすることができる。 ※ルートアカウントは他人に絶対に教えてはいけない。 たとえ、個々のIAMユーザーに管理権限を付与するとしても、 ルートアカウントでない限りはアクセスを制限できるので、 必ず、IAMユーザーを都度、作る。
AWS 定義のポリシーを使用して可能な限り権限を割り当てる
ポリシーとは AWSではアクセス権限を制御するのにポリシーという定義を利用する。
ポリシー例
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "aws-portal:*Billing", "aws-portal:*Usage", "aws-portal:*PaymentMethods", "budgets:ViewBudget", "budgets:ModifyBudget" ], "Resource": "*" }] }
AWS内でデフォルトで定義されているポリシーを使って可能な限り、権限を割り当てる。 メリットとしては、簡単。 デメリットとしては、権限の単位がざっくりしている。
例 - AdministratorAccess - フルアクセス権限 - AWSCloudTrailReadOnlyAccess - ClourTrailの読み取り権限
職務によって、ポリシーがAWSで定義されている。 職務機能の AWS 管理ポリシー
IAM ユーザーへのアクセス許可を割り当てるためにグループを使います。
ポリシーをIAMユーザー一人ひとりに付けるのは面倒だし、 複数人いても大体同じ権限になる。という場合に、グループを使う。
ここらへんで、単語が増えてきて混乱してきたと思うので、 以下にユーザ、ポリシー、グループの関係を整理。
- グループ作成
- グループにポリシーをアタッチ(付与】
- ユーザーをグループに追加
ポリシーはユーザーに直接アタッチも可能。
最小限の特権を認める。
まずは、最小限のアクセス(特定サービスへの権限、リードオンリー)を割当て、 必要になった際に権限を解放していくようにしよう。という話し
Access Advisorを使う アクセスアドバイザーは、コンソールでIAMユーザーを見る場合にタブの1つである。 該当ユーザーが、権限が付与されているサービスにいつアクセスしたかがわかる。 この項目を参照し、1度もアクセスをしていないサービスがあれば、 その権限はそのユーザーには不要な可能性があるため、 権限の見直しに使える。
ユーザーのために強度の高いパスワードポリシーを設定する。
IAMユーザーのパスワードに、パスワードポリシーを設定できる
特権ユーザーに対して、MFA を有効化する。
AWS での多要素認証 (MFA) の使用 ルートアカウント同様に、重要なリソースへの権限を持っているユーザーにはMFAを設定しようという話し。 例えば、(どのサービスでも)削除権限を持ってる人とか。
Amazon EC2 インスタンスで作動するアプリケーションに対し、ロールを使用する。
EC2上から別AWSサービスにアクセスすることはよくある。 そのアクセス権限は適切に定義しよう。という話し
ロールとは、AWSのリソースにアクセスできる権限の役割の定義
また新しい言葉が出てきたので、整理する。
- IAM ポリシー
- AWS上で扱う権限の一番小さい単位
- IAM ユーザー
- AWSにアクセスするユーザーの単位
- グループに含めたり、ポリシーをアタッチして権限を付与する
- IAM グループ
- 複数のポリシーをまとめたもの
- 複数のユーザーに同一の権限を与えるために使う
- IAM ロール
認証情報を共有するのではなく、ロールを使って委託する。
さっきのロールの使い方での他AWSアカウントへは、アクセスキーを共有するんじゃなくて、 ロールを使おうね。という話し
認証情報を定期的にローテーションする。
定期的に認証情報を更新しようという話し
不要な認証情報の削除
使われていない認証情報があったら消そう。という話し
認証情報レポートや、awsコマンドで最後に使用した日付とかがわかるので、 それを見て、消す対象を精査できる。
追加セキュリティに対するポリシー条件を使用する。
ポリシーに対して、IPアドレスの制限が時間の制限を行うことができるので、 可能な限り、制限したほうがいいよ。という話し
AWS アカウントのアクティビティの監視
- cloudfront
- cloudtrail
- cloudwatch
- aws config
- S3
の、アクセスログを利用して、不正なアクセス、利用と監視しようという話し
まとめ
全部やるのは過剰なのかな?という気もしますが、 そこは自分たちのやり方に合わせて、うまくやっていくのがいいのかなと思います。