AWS を安全に使うために（IAM のベストプラクティス）

セキュリティインシデントを止めるには IAM　から。IAM　の正しい使い方を一度覚えればセキュリティリスクは低減できます。AWS　のドキュメント「IAM のベストプラクティス」をできるだけ具体的に解説してみましたのでご一読ください。

#セキュリティ

#AWS IAM

#AWS

菅野昌孝

2018.05.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

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 ユーザーがそのロールを使用できるように信頼関係を設定します。