AWSに登録したらまずIAMの設定

テクノロジー

AWSシリーズ記事です。たぶん続かないので、今回で最終回とか言っておいて予防線引いておきます。

AWSで一番大事なサービスは何かと言われたら、間違いなくIAM (Identity and Access Management) です。

誰が、自分のAWSアカウント内でどんな操作をできるか、というのを制御するサービスです。ログインアカウントのパスワード変更なんかもIAMで行います。

個人利用では特に、以下の点を重点的に考えて設定しましょう。

ルートアカウント以外のユーザーを作る

ルートアカウント

AWSアカウントを作成したら最初にもらえるアカウント。
支払い方法管理なども含め、AWSでの全ての操作が可能。
ユーザーIDに相当する部分がメールアドレスであることが特徴。

IAMユーザー

IAMで作成するユーザー。
ルートアカウントにぶら下がる子ユーザーという認識でだいたいあってる。
ユーザーIDに相当する部分がメールアドレスではないのが特徴。
ユーザーごとにロールを割り当て、行動を制限することが可能。

まず、メールアドレスでログインすることをやめましょう

…というのはAWSのセミナーではまず言われる話。大原則です。

ルートアカウントは性質上AWS内の全サービスを好き勝手に操作可能です。
一方、IAMユーザーはロール(後述)でサービス操作の幅を広げたり狭めたりすることができます。また、ユーザーそのものを消すこともできます。

いざというとき、ユーザーなら権限を読み取り専用にするとか、ユーザーを削除するという対応がとれますが、ルートアカウントだった場合はAWSアカウントを削除するしか道がありません。

ということで、極力ルートアカウントは使わないでね!というのがAWSのベストプラクティスです。

ベストプラクティス

ベストプラクティスは、ある結果を得るのに最も効率のよい技法、手法、プロセス、活動などのこと。(Wikipediaより)
AWSではそこかしこに出てくる頻出単語。AWS公式推奨設定とも言い換えられる。これに従ったほうが無難。
Wikipediaの説明文にある「ある結果」、即ちAWSがユーザーに望んでいる最終目標は、AWS Well-Architected フレームワークに準拠すること。
理由があってWell-Architectedに沿う必要がなければ、ベストプラクティス以外の手法をとっても構わない、とはAWS講習で頻出する話。

AWS Well-Architected

AWSがオススメするアプリケーション構成のこと。
5つの柱「運用上の優秀性」「セキュリティ」「信頼性」「パフォーマンス効率」「コスト最適化」を向上させた設計になっている。
たとえば「発生しうる障害を予想する」「追跡可能性を実現する」のようなオンプレにも通じる基本から、「サーバーレスアーキテクチャの使用」「運用をコード化する」などAWS(とかGCPとかAzureとか)ならではのオススメも盛り込まれている。
紹介ページには、これらが盛り込まれたくっそでかいPDFが置いてある。読んでみてほしいけど、初学者は間違いなくチンプンカンプンなので、ある程度AWSに慣れたら読んでみよう。

早速用語がたくさん出てきてます。
AWSって独自な言葉回しが多いので、とっつきにくい面があります。
記事の中では特に重要な単語しかピックアップしてないので我慢していただけると嬉しいです。

IAMユーザーはこの画面で設定します。

ただのユーザーアカウント一覧画面みたいな感じ。
企業でAWSを使うと、ここに各社員のユーザー名がズラズラ並ぶって感じです。

さて、IAMユーザーにはIAMポリシーを割り当てることができます。

IAMポリシー

ざっくりいうとアクセス権。「この人にはこれをする権利を与える!」って宣言するもの。
たとえば「各サービスを見るだけで操作できない」とか、「EC2(VPS的なもの)だけアクセスできる」とか、思いのままに操れる。

おそらく日常使いアカウントになるIAMユーザーにはAdministrator権限(=すべての行動が許可される)を割り当てることになると思います。
言わずもがな、全権限を持つと漏洩時のリスクが高まります。
ルートアカウントと違っていつでも削除できるとはいえ、従量課金のAWSであることに変わりはありませんので、くれぐれも漏れないよう注意しましょう。

MFAを有効にする

なんとかペイで大人気になったMFA(多要素認証)。当たり前のようにAWSでも利用可能です。

セキュリティ認証情報画面なら見つけやすい場所にボタンがある
ボタンを押すと出てくるポップアップ画面

AWSでは仮想MFAデバイスとハードウェアMFAデバイスの両方に対応しています。

…といっても、たぶん多くの人は仮想MFAデバイスを選ぶことになると思います。みんな大好き「Google認証システム」が使用可能です。

対応しているハードウェアMFAデバイスの一覧はここから見れますが、いずれも海を渡ってくるので半月ぐらいかかるようです。
(個人的にはソフトウェアMFAでも十分安全性は担保できると思っています、セキュリティに詳しい人にツッコまれたらこわいので語りませんが…)

ルートアカウントのMFAは必ず有効にしましょう。
IAMユーザーのMFAを有効にするかどうかは判断次第かもしれません(設定することをオススメしますが、ルートアカウントと同じ端末で設定するのは…どうなんだろう?)

(本題と少し違うけれど)請求情報をIAMユーザーから見られるようにする

これでIAMユーザーだけ使えば満足にAWSを使えるようになる、と言いたいところですが、もうひとつだけ設定しておくと便利(設定しておくのが無難)な設定があります。

それが請求情報。

この画面がないと色々不便します。
ただ、請求情報は機密情報なので、初期設定ではルートアカウントでないと確認できないように設定されています。

ということで、見れるようにしましょう。

ルートアカウントでログインして、右上のメニューから「マイアカウント」をクリックします。

開く画面をスクロールしていくと、「IAM ユーザー/ロールによる請求情報へのアクセス」という項目があるので、右端の超目立たない「編集」をクリックします。

そして出てくるチェックボックスにチェックを入れて「更新」ボタンを押せば完了です。

あとはIAMユーザーに然るべきロール(Administratorでも可、絞るならAWS管理ロールの「Billing」ロールを割り当てると簡単)をアタッチすれば、IAMユーザーから課金情報を確認できます。

ルートアカウント以外でログインする

まあ当然なことですが、ルートアカウントをMFA有効にして、普段遣い用のIAMユーザを作って、料金も見えるようにしてしまえば、もう当分ルートアカウントは不要になります。

ということで、ルートアカウントは大切に置いておいて(AWSの講習(会社でAWSを使っている前提)では「パスワードは会社の金庫にでも仕舞っておこう」とさえ言われる)、普段はIAMユーザーでログインしましょう。

・・・あ、当然、ルートアカウントもIAMユーザーも、パスワードは他で使っていないものにしておきましょうね。


これで「CLI使ってバリバリやるぜ」な人以外(=AWSコンソールでポチポチっとやるだけの人)は概ね心配がいらなくなりました。

ここまでの内容を、まだやってない人は今すぐやってみることをオススメします。30分もかかりません。

「CLI使ってバリバリやるぜ」的な人はもうちょっと気をつけるべき点があるんですけど、それはまたおいおい…