AWS を安全に使うために（IAM のベストプラクティス）
はじめに
AWS を利用するにあたり、セキュリティをいかに確保するかが最優先事項となります。
今回は AWS を利用する際に一番最初に設定するであろう IAM で必要な設定について、AWS が推奨しているベストプラクティスに添って可能な限り分かり易く説明していきます。
IAM とは
AWS の操作をより安全に行うため、AWS リソースへのアクセスを制御するためのサービスです。
IAM により、複数のユーザーに AWS リソースへの安全なアクセスを簡単に提供できます。
とある会社の場合
例として以下のような会社を定義します。
- 社長 x 1人
- 部長 x 2人（営業部、開発部）
- 営業部社員 x 3人
- 開発部社員 x 3人
- 開発部外注先 x 1人
ルートユーザーは誰が使う？
ルートユーザーあまりにも強力な権限を持っているため、実際にはめったに使うことはありませんし、使わないようにすべきです。
めったに使わないので、この組織では社長に管理していただきましょう。
ただし、厳密な管理が必要なので然るべき部署があれば管理担当を専任で設けましょう。
また、ルートユーザーの権限が必要なプログラムなどありませんので、セキュリティリスクを低減するためにもルートユーザーにはアクセスキーを設定しないようにしましょう。
設定している場合は使っているプログラムを修正し、ルートユーザーのアクセスキーは今すぐ削除してください。
さらにパスワードが漏洩した時のリスク軽減のため、多要素認証（MFA）を設定しましょう。
クリアできる推奨事項
AWS アカウントのルートユーザーのアクセスキーをロックする
不要な認証情報を削除する
特権ユーザーに対して MFA を有効化する
パスワードポリシーを決めましょう
AWS アカウントを入手した時にはルートユーザーしかありませんのでルートユーザーでログインします。
まず最初に、パスワードのルール（パスワードポリシー）を設定しましょう。
どのようなルールにするか悩んでいるのでしたら、PCIDSS の要件を満たす以下のルールはどうでしょうか。
- パスワードの最小長：8文字
- 少なくとも 1 つの大文字が必要
- 少なくとも 1 つの小文字が必要
- 少なくとも 1 つの数字が必要
- パスワードの有効期間（日数）：90日
Pマークで「パスワードの定期的な変更」が審査基準から廃止されたように、必要とされるルールは様々です。
自社で必要な要件について一度考え、運用に無理が無い内容にしましょう。
決定したパスワードポリシーに従い、ルートユーザーのパスワードを変更しておきます。
IAM の変更権限を持っていないユーザーの場合、AWS マネジメントコンソールの以下の場所からパスワードが変更できます。
クリアできる推奨事項
ユーザーの強力なパスワードポリシーを設定
認証情報を定期的にローテーションする
部長用 IAM ユーザーを作りましょう
社長がいつまでも現場の作業をしていられませんので、基本ルールの設定が終わったら後は部長に任せましょう。
まずそれぞれの部長用に IAM ユーザーを作成します。
ユーザーは必ず1人に1つ作成してください。全く同じ権限を付与する場合もです。
AWS では「どの IAM ユーザーが何をしたか」まで記録することができますが、共通のユーザーで作業するとその IAM ユーザーを使っている「誰」を特定できなくなり、何かあった時に調査ができなくなってしまいます。
パスワードが漏洩した時のリスク軽減のため、このユーザーにも多要素認証（MFA）を設定しましょう。
クリアできる推奨事項
個々の IAM ユーザーの作成
特権ユーザーに対して MFA を有効化する
部長用 IAM ユーザーに権限を与えましょう
この組織では管理する部署がありませんので、部長の2人に IAM の管理も任せる必要があります。
各部長には管理者として、ルートユーザーの次に最大の権限が設定してある「AdministratorAccess」ポリシーを付与します。
権限の付与方法ですが、各 IAM ユーザーに対して設定せず、IAM グループを作成してそこに付与しましょう。
IAM ユーザーは IAM グループに所属することでその権限を使えるようになります。
IAM グループを使うと以下のようなメリットがあります。
- 部長全員の権限変更作業が IAM グループの権限変更だけで済む
- 新しい部長を追加する時にどの権限を付けるかを確認する必要が無く、IAM グループに追加するだけで済む
管理作業の省力化や設定漏れの防止のため、積極的に IAM グループを使いましょう。
クリアできる推奨事項
IAM ユーザーへのアクセス権限を割り当てるためにグループを使用する
営業部社員のユーザーを作成しましょう
営業部部長が営業部に所属する社員それぞれに IAM ユーザーを作成します。
部長用 IAM グループの時と同じように、営業部用の IAM グループを作成しますがどのような権限が必要でしょうか？
営業部社員の要件を以下とし、権限を検討してみます。
- EC2 インスタンスを立ち上げたり、設定を変更するといった作業はしない
- 何かあった時に AWS リソースの状況が見たい
- プログラムを使わないのでアクセスキーは不要
これらの条件を満たす権限として、AWS が定義している「ReadOnlyAccess」ポリシーを付与します。
AWS が定義しているポリシーを使うと、新しいサービスが追加されたとしても保守や更新が AWS によって行われ、常に最新の状態になるというメリットがあります。
自分でポリシーを作成するのではなく、可能な限り AWS 定義のポリシーを使うことで管理が楽になります。
また、プログラムを使わない事がわかっているので、余計な認証情報であるアクセスキーは付与してはいけません。
しつこいようですが、パスワードが漏洩した時のリスク軽減のため、このユーザーにも多要素認証（MFA）を設定しましょう。
クリアできる推奨事項
個々の IAM ユーザーの作成
AWS 定義のポリシーを使用して可能な限りアクセス権限を割り当てる
不要な認証情報を削除する
特権ユーザーに対して MFA を有効化する
開発部社員のユーザーを作成しましょう
開発部部長が開発部に所属する社員それぞれに IAM ユーザーを作成します。
開発部社員の要件を以下のように設定します。
- 各種 AWS リソースの設定変更作業がある
- IAM の管理権限は与えない（必要な場合は部長に依頼）
- 自分のPCから aws-cli を使って AWS リソースを管理する
- 会社からしかアクセスできないようにする
これらの要件を満たすポリシーとして、開発部用 IAM グループには AWS が定義している「PowerUserAccess」ポリシーを付与します。
「PowerUserAccess」ポリシーでは IAM に対して参照権限だけになっていますので、勝手に権限を与える・変更するといった事はできません。
また、個人PCから aws-cli を使うのでアクセスキーを発行します。アクセスキーは個人PCに保存するため漏洩の危険が常にありますので、定期的にローテーション（アクセスキーの削除と作成）します。
会社からのアクセスのみを許可する場合、オリジナルのポリシーを作成して json の中に「Conditionエレメント」を記述し、IAM グループに作成したポリシーを割り当てます。
もうわかっていると思いますが、パスワードが漏洩した時のリスク軽減のため、このユーザーにも多要素認証（MFA）を設定しましょう。
クリアできる推奨事項
個々の IAM ユーザーの作成
AWS 定義のポリシーを使用して可能な限りアクセス権限を割り当てる
認証情報を定期的にローテーションする
追加セキュリティに対するポリシー条件を使用する
特権ユーザーに対して MFA を有効化する
開発部外注先にもユーザーを用意するのか？
外注先に委託する場合にユーザーを用意すると、パスワードやアクセスキーなどの認証情報を渡す必要がありますので漏洩するリスクが発生します。
代わりに IAM ロールを用意して必要な権限のみを付与し、外注先が持っている AWS アカウントの IAM ユーザーがそのロールを使用できるように信頼関係を設定します。
委託した作業が完了したら、外注先用に作成した IAM ロールは速やかに削除しましょう。
クリアできる推奨事項
開発するシステムと必要な権限
例として外注先に開発してもらうシステムは以下のような内容とし、必要な権限の内容を考えてみます。
- EC2 インスタンスが S3 バケットA から取得した情報を処理し、S3 バケットBに保存するプログラムを開発する
EC2 インスタンス用の IAM ロールの権限は、以下のように設定します。
- S3 バケットA に対しては読み取り権限のみ
- S3 バケットB に対しては書き込み権限のみ
- その他の S3 バケットの中のオブジェクトは参照できない
EC2 インスタンスが必要とする権限は IAM ロールを作成してそれに付与し、その IAM ロールを割り当てることで必要な権限を EC2 インスタンスが使用できます。
こうすることで EC2 インスタンスやプログラムソースにアクセスキーを保存する必要が無くなり、セキュリティが高まります。
このように必要最小限の権限を付与することで、この EC2 インスタンスへ侵入されたとしても被害は最小限に抑えることができます。
クリアできる推奨事項
Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
アクセスレベルを使用して、IAM 権限を確認する
最小権限を付与する
安全に使っても監視は必要
ユーザーのアクティビティをチェックしたり監視してアラートを発生させるためにも、CloudTrail を有効にしましょう。 アラームを作成しておけば、AWS リソースへの変更に対して通知する事も可能です。
クリアできる推奨事項
さいごに
いかがでしたでしょうか。
できる限り具体例に沿って IAM のベストプラクティスに従う方法を説明してみました。
このブログエントリーを読んでいる方の現状とマッチするものがあれば、セキュリティを確保するためにも導入を検討してみてください。
また、IAM ベストプラクティスのビデオを AWS が用意してくれていますので一度ご覧になってみてください。
クリアできる推奨事項
参考ページ
以下のページを参考にさせていただきました。
ありがとうございました。
IAM のベストプラクティス - AWS Identity and Access Management