AWS 無料利用枠で何かやってみる Day 5 〜IAMユーザー作成

Day 5 で何やる？

ようやく、EC2建ててみます。サーバを作りたいというよりは、AWSのVPC関連の設定に重きを置いて。

そう意気込んだ矢先、やはりルートユーザーで進むのは邪道だと思って、IAMユーザー作ったり。

IAMユーザー作らずルートで良いかなと思いつつ、お作法に乗っ取り、IAMユーザー作成。認証認可の勉強になるしね。#AWS #AWS無料利用枠
IAMユーザー作った後にMFA認証の設定権限がなく、以下を参考にポリシー作成して、IAMグループにアタッチ。事なきを得る。https://t.co/D2ZKVXPujv

— nabe_merchant (@nabe_merchant_r) 2021年5月8日

ヘッダデザイン（ナビゲーションバー含む）や、本文のデザインが気になりHTML/CSSいじってました。

AWSの勉強進めながら、ついついHatenaブログのCSSいじりに注力してしまった。
明日はVPC理解のためにEC2環境構築を行う。#AWS #はてなブログ

— nabe_merchant (@nabe_merchant_r) 2021年5月8日

CSS3は正直全然触れた事なかったですが、なるほど面白なという感覚。

ナビゲーションバーは、実装したものの、現状のコンテンツ量では「ナビゲーションするものが無い」というナビゲートをしてくれたので良しとする。

ということで、Day 5 は、

• IAMユーザー作成
• IAMユーザーでのMFA認証（ポリシーの設定）
• EC2構築　→　時間足りなかったので、後半戦で対応します！！

とする。

参考にしたサイト／書籍は以下の通り（感謝）

サイト

• (1) AWSアカウントの作成と必ずやるべきセキュリティ対策 | Avinton Japan
• (2) IAM チュートリアル: ユーザーが自分の認証情報および MFA 設定を管理できるようにする - AWS Identity and Access Management
• (3) AWS: MFA で認証された IAM ユーザーが [My Security Credentials] (マイセキュリティ資格情報) ページで自分の認証情報を管理できるようにする - AWS Identity and Access Management

書籍

• 今回はなし

IAMユーザー作成

ルートユーザーでログイン後、IAMにてユーザーの作成を行う。 なお、ルートユーザーについては、Day 1 でも触れたが、以下を参考に設定済み。

仮想 Multi-Factor Authentication (MFA) デバイスの有効化 (コンソール) - AWS Identity and Access Management

IAMユーザー作成手順は以下の通り、まずIAMに「ユーザー」選択後、「ユーザーを追加」を押下する。

次に、実際のユーザー作成だが、ここはほぼ設定することはなく、

• ユーザー名
• アクセスの種類
• パスワード関連

となる。

アクセスの種類は、IAMユーザーのコンソール以外での利用（開発端末等からの直接接続と認識）の場合、「プログラムによるアクセス」が必要となるが、現時点で不要であること。 また必要になった際に、設定不足で利用できないことを確認するために、あえて設定しない。

パスワードに関しては、自動生成＋初回ログイン時に変更がセオリーと思われるため、デフォルト設定で進む。

ここまで楽勝と思っていたら、「アクセス許可の設定」が唐突に現れる。

ただ、Day 4 にて認証認可の予習をしている私には、少し焦った程度で、生産性への影響はなかった。

AWS 無料利用枠で何かやってみる Day 4 〜認証認可とは - Reverse/Re:verse/Re:birth engineering

アクセス許可の設定は、

• ①IAMグループへのユーザー追加：IAMグループのポリシーがユーザーに適用される
• ②既存ユーザーのコピー：任意のユーザーと同等の設定（IAMグループ及び直接アタッチされたポリシー）
• ③既存ポリシーのアタッチ：左記の通り

となり、既存ユーザーは存在しないので、①③の選択となるが、IAMグループに触れる機会なので、①を選択肢、以下の通り、VPC/EC2/RDS/S3にフルアクセス可のポリシーをアタッチしたグループを作成し、ユーザーを追加した。

確認画面のキャプチャが漏れたが作成が完了すると、以下の画面が表示される。

サインイン用のURLとユーザー名、初期パスワードが提示されるので、それに従いサインインすれば、IAMユーザーでサインインできる。ただ、焦ってこのままサインインするとルートユーザーが強制ログアウトされ、上記の画面表示も消えるので注意されたし。（※私の事例となります）

なお、ダウンロードできるcsvに、サインイン用のURLとユーザー名、初期パスワードの情報があったり、ログイン手順をメールするとおそらくサインイン用のURLとユーザー名はメールされるのではないかと思います。（初期パスワードも連携されるのかな？）

※参考サイト(1)を元に進めております。

IAMユーザーでのMFA認証（ポリシーの設定）

作成したIAMユーザーでサインイン後、ルートユーザー同様MFAでの認証を設定しようと、IAMの画面で「あなた権限無いよ〜」(意訳)と指摘され、何もできません。

厳密には「IAMUserChangePassword」のポリシーは直接アタッチされている（これはIAMユーザーのデフォルトなのかな）ので、IAMの仕組みとしては、パスワード変更しかできない状態。

従って、私は上記の参考(2)(3)を元に、専用ポリシーを作成し、IAMグループ（上記とは別）にアタッチして、ユーザーを参加させることで対応した。

ポリシーの中のAllowManageOwnVirtualMFADevice/AllowManageOwnUserMFAステートメントが、本件の中では重要なため切り出すと、

この AllowManageOwnVirtualMFADevice ステートメントにより、ユーザーは自分の仮想 MFA デバイスを作成、更新、削除できます。リソース ARN は、現在サインインしているユーザーと名前が一致する MFA デバイスにのみアクセスを許可することに注意してください。ユーザーは、各自の仮想 MFA デバイス以外の MFA デバイスを作成または削除することはできません。

この AllowManageOwnUserMFA ステートメントでは、ユーザーは自分のユーザーの仮想、U2F、またはハードウェア MFA デバイスを表示または管理できます。このステートメントのリソース ARN は、ユーザー自身の IAM ユーザーにのみアクセスを許可します。ユーザーは他のユーザーの MFA デバイスを表示または管理することはできません。

{
     "Sid": "AllowManageOwnVirtualMFADevice",
     "Effect": "Allow",
     "Action": [
          "iam:CreateVirtualMFADevice",
          "iam:DeleteVirtualMFADevice"
     ],
     "Resource": "arn:aws:iam::*:mfa/${aws:username}"
},
{
     "Sid": "AllowManageOwnUserMFA",
     "Effect": "Allow",
     "Action": [
          "iam:DeactivateMFADevice",
          "iam:EnableMFADevice",
          "iam:ListMFADevices",
          "iam:ResyncMFADevice"
          ],
     "Resource": "arn:aws:iam::*:user/${aws:username}"
},

何となく読み取れますが、AWSポリシー、奥が深いですね。

EC2構築は今晩着手しますが、ブログにまとめるのは、明日以降になりそうです。