AWSアカウントを作成すると、AWSからルートアカウントが発行されますが、原則このルートアカウントは使用しないことが推奨されています。
というのも、ルートアカウントはAWSの全リソースに対するアクセス権を持っているため、万が一漏洩した場合のリスクがとても大きいからです。
例えば、ルートアカウントが流出すれば、自分が構築したシステム環境が破壊されたり、課金額の大きいハイスペックインスタンスを勝手に起動されて高額請求されるなどの被害に合う恐れがあります。
従って、AWSを利用する場合には、ルートアカウントではなく、必要最小限の権限のみを与えたIAMユーザやIAMロールを使用することがベストプラクティスです。
当記事では、まずAWSでのアカウント管理に必要な知識としてIAMユーザとIAMロールの違いをご説明します。次に、ベストプラクティス運用に準拠した設定を行うためのIAMユーザ作成手順をご紹介します。
IAM
IAMとは、AWSにアクセスするためのアカウントとその権限を一元管理するサービスです。
初心者の方にはよく誤解されますが、EC2上で作成するOSユーザやRDS上で作成するDBユーザとは全く別の概念です。
OSユーザはOSの操作を、DBユーザはDBを操作するためのアカウントであるように、IAMユーザとIAMロールはAWSを操作するために必要なアカウントです。
AWSの操作とは、例えばVPCを作成したり、EC2を起動したり、RDSのインスタンスクラスを変更したり、請求ダッシュボード(課金状況)を見たりなどです。
ルートアカウントの代わりに限定的な権限のみを付与したIAMユーザ・IAMロールを使用することで、権限過多による誤操作や、万が一のアカウント流出時に第三者からの悪意ある操作を最小限に抑えることができます。
IAMユーザとIAMロールはどちらもAWSへのアクセス権を持つIAMオブジェクトですが、それぞれ使いどころが異なります。
IAMユーザ
IAMユーザは、AWSへのアクセス権限を人やAWS以外のサーバに付与するために使用します。
人が使う場合
例えば、サーバ管理者に「EC2構築業務」に必要な権限を付与する場合は、IAMユーザを利用します。
マネージメントコンソールへのログイン権限とEC2のフルアクセス権限を付与したIAMユーザを作成し、このユーザのログインIDとパスワードをサーバ管理者へ通知します。
通知を受けたサーバ管理者は、IDとパスワードを使ってマネジメントコンソールへログインすることで、EC2インスタンスの構築業務を行うことができます。また、マネジメントコンソールを使わずにawscliなどAPIでEC2を操作することも可能です。
このIAMユーザに付与されている権限は「マネジメントコンソールへのログイン」と「EC2のアクセス権」のみですのでRDSの操作は行えません。
従って、このサーバ管理者によってRDSインスタンスが破壊・参照されることは100%ありません。
サーバが使う場合
例えば「オンプレのサーバからs3にファイルをアップロードするアプリケーション」を作成する場合、IAMユーザにs3バケットへの参照権限と書き込み権限を付与します。
IAMユーザの作成時にはアクセスキーとシークレットキーを発行されるので、アプリケーションでs3へのアップロード(Put)APIを呼び出す際にこの2つのキーを使って認証することで、s3にアクセスすることができるようになります。
キー自体はランダムな文字列ですので、テキスト形式でどこかに配置するなりDBに持たせるなり管理方法は自由ではあるのですが、絶対に第三者には知られない方法で管理してください。万が一この2つのキーが外部に流出してしまった場合、悪用されると第三者からのアクセスを許してしまうことになります。
ごく稀にですが、初心者の方がエンジニアブログやgithubなどにアクセスキーとシークレットキーをベタ書きで記載したまま公開してるのを見かけますが、これは非常に危険な行為ですので絶対にやめてください。IAMユーザは絶対に他の人には知られないように管理する必要があることを忘れないでください。
IAMロール
IAMロールは、EC2やLambdaなどのAWSリソースに権限を付与するために使用します。
例えば、EC2上でs3へのファイルアップロードアプリケーションを作るとしましょう。先ほどはオンプレサーバ上でしたが、今回はEC2上で作る場合です。
先ほどと同様に、IAMロールにはs3バケットへの参照権限、書き込み権限を付与します。
このIAMロールをEC2インスタンスにアタッチするだけで、EC2インスタンスに権限が適用されます。
IAMロールはキーの管理が不要
IAMユーザとIAMロールの違いは、キーの管理が必要か否かの違いです。
IAMユーザの場合は、キーを何かしらの形式で厳重に管理する必要がありましたが、IAMロールの場合はAWSの内部でIAMロールとEC2を直接紐づけることができるため、キーを管理する必要がありません。
つまり、IAMロールを使えばキーの流出リスクは0%になるということです。
もちろんEC2でもIAMロールを使わずにIAMユーザで権限付与することもできますが、不要なセキュリティリスクを負うだけですので、AWSとしてはEC2の権限付与はIAMロールで行うことがベストプラクティスです。
IAMグループ
ついでにIAMグループも説明します。
権限はユーザ単位やロール単位で個別に付与することもできますが、同じサーバ運用業務を行うメンバー1人1人に個別に権限付与するのはあまり賢くありません。
IAMグループに必要な権限を付与して、そのIAMグループに各メンバ個々に発行したIAMユーザを所属させることで、グループに所属する全てのユーザに同一の権限をまとめて付与することができます。
セキュリティステータス対応
AWSでは、IAMを適切に運用するためのセキュリティステータス対応が推奨されています。
前回のAWSルートアカウントのMFA設定方法の記事でルートアカウントの設定を行いましたが、今回はその続きの対応としてIAMユーザの作成手順を説明します。
もしルートアカウントのMFAが未設定の方がいる場合は、前回の記事も参考に併せて対応することをオススメします。
IAMの管理画面を開く
まずはマネジメントコンソールでIAMの管理画面を開きます。
画面下側のセキュリティステータスを見ると、残り3項目の対応が必要です。
今日はこのうちの2つ、IAMユーザとグループを作成します。
新規ユーザーの作成
左メニューから「ユーザー」を開き「新規ユーザーの作成」をクリック。
ユーザ名の入力
一度にまとめて5ユーザまで作成できます。
ユーザ名は最大64文字までとなっています。
今回は「admin」という名前のユーザを1つだけ作ります。
画面の中ほどには、アクセスキーについての記載があります。
「ユーザごとにアクセスキーを生成」にチェックをつけます。
アクセスキーとは、AWSが必要とする認証情報の1つので、アカウント(IAMユーザ)がAWSに対する処理を実施する際に使う認証キーのことです。
混同してしまいがちですが、この後設定するIAMユーザのパスワードと認証キーは別物です。
パスワードは、マネジメントコンソールにログインする際の認証に使います。
認証キーは、awscliなどAPIを使用する際の認証に使います。
おそらく、AWSの内部的にはマネジメントコンソールから実行する処理もAPIを叩いているだけなので、パスワードでログインした場合はアカウントに紐付くアクセスキーが自動で認証されているものと思われます。
名前の入力とアクセスキー生成にチェックをつけたら、画面右下の「作成」をクリック。
認証情報の確認
「ユーザーのセキュリティ認証情報を表示」をクリックすると、今作成したIAMユーザのアクセスキー及びシークレットアクセスキーが表示されます。
どちらもAWSにアクセスするための認証キーとして使うものですが、両者の明確な違いは「後からこのキーを参照できるか否か」です。
アクセスキーは、IAMの管理画面からいつでも参照できます。
しかし、シークレットアクセスキーは今後AWS上では一切参照できません。
「あれ？シークレットアクセスキー忘れちゃったんだけど〜」という事態になってしまっても、どこにも情報は残りませんし、AWSサポートなどから教えてもらうこともできません。（というよりAWS側でも把握していません）
これはセキュリティを高めるため、必要以上に情報が外部に漏れることを防ぐための施策です。
シークレットアクセスキーを参照できるのは、IAMユーザを作成した今この瞬間のみとなりますので、この時点で必ず保存しておく必要があります。
ユーザを作成した本人にしか見せないシークレットな情報なので、シークレットアクセスキーと呼ばれています。（と勝手に思っています）
認証情報は画面右下からダウンロードできますが管理はくれぐれも適切に。
ダウンロードが済んだら、その横の「閉じる」をクリックします。
IAMユーザの確認
ダッシュボードには、今作成したIAMユーザが表示されています。
クリックすると詳細情報を表示できます。
認証情報タブを開くと先ほどのアクセスキーが確認できます。
シークレットアクセスキーはもう表示されません。
パスワードの変更
そのまま下にスクロールするとサインイン認証情報が表示されます。
パスワードを変更するために「パスワードの管理」をクリックします。
初期パスワードの設定
まず、パスワードをランダムで自動作成するか、任意で作成するかを選択します。
デフォルトは自動作成です。
カスタムを選択すると、パスワードの入力フォームが表示されます。
企業の運用ポリシーなどでデフォルトパスワードが固定されている場合はこちらを選択すると良いでしょうが、今回は自動作成にします。
その下の「次回のサインインで新しいパスワードを作成するようにユーザーに求める」は初回サインイン時に強制的にパスワードを変更させるか否かです。
自分以外の人にIAMユーザを発行する場合は、ここにチェックをつけておきましょう。
試しに今回もチェックを付けてみます。
最後に、画面右下の「適用」をクリックします。
パスワードの確認
先ほどのアクセスキーと同じレイアウトでパスワードが確認できます。
同様に、認証情報をダウンロードしてから「閉じる」をクリックします。
パスワード変更完了
これでadminユーザに対するパスワードが生成されました。
管理画面からも「パスワード」が「はい」になっていることが確認できます。
また、同じ画面でMFAの設定を行うことも可能です。
こちらも設定しておいたほうが良いですが今回は省略します。
設定する場合は、前回書いたAWSルートアカウントのMFA設定方法の手順2以降を実施すればOKです。
管理者権限グループの作成
adminユーザに管理者権限を与えますので、管理者権限グループを作成し、そのグループにadminユーザを追加します。もちろんユーザ個々に権限を与えることもできますが、管理が煩雑になってしまうので用途が明確な権限はグループ単位で定義しておいたほうが良いでしょう。
画面左から「グループ」を選択し、「新しいグループの作成」をクリック。
グループ名の設定
管理者権限グループなので、Administrators にしておきます。
ポリシーのアタッチ
IAMグループに付与する権限をここで定義します。
今回は管理者権限を与えるので、一番上に表示されている「AdministratorAccess」にチェックを付けます。
この「AdministratorAccess」を始め、ここに列挙されている権限はAWSが予め用意してくれている権限テンプレートです。
IAMの権限は「何に対して」「何を」「許可・拒否」するのかをJSON形式でポリシーとして定義します。
例えば「AdministratorAccess」のポリシーは以下のようになっています。
アスタリスク * は「全て」という意味です。
ここでは全てのAWS上の全てのResourceに対して、全てのActionをAllowしています。
すなわち、AWSの全リソースに対するフルアクション権限を付与するという意味ですね。
なお、ポリシーの実体はただのJSONファイルなので、テンプレートを使わず独自に定義することもできます。
「AdministratorAccess」にチェックを付けて、画面右下の「次のステップ」をクリックします。
設定内容の確認
内容に誤りがなければ、右下の「グループの作成」をクリック。
グループの作成完了
Administratorsグループが作成されました。
まだユーザは0の状態ですので、ここにadminユーザを追加します。
グループ名をクリックすると詳細画面に移ります。
グループにadminユーザーを追加
詳細タブの「グループにユーザーを追加」をクリック。
adminユーザを選択して、右下の「ユーザーの追加」をクリック。
このように、adminユーザがAdministratorグループに追加されました。
IAMユーザ用のサインインURLを確認
では、adminユーザでマネジメントコンソールにサインインしてみましょう。
画面左から「ダッシュボード」を開くと、IAMユーザ用のサインインURLが表示されます。
https://{アカウントID}.signin.aws.amazon.com/console
12桁の数字が書いてあるかと思いますが、これはAWSのアカウントIDです。
このアカウントに対して、IAMユーザとしてサインインするための認証URLとなります。
ちなみに、ダッシュボードの下の方を見るとセキュリティステータスが更新されています。
adminユーザとAdministratorsグループを作成したので、「個々のIAMユーザーを作成」「グループを使用してアクセス許可を割り当て」
の2つが完了になりました。
IAMユーザでサインイン
ではIAMユーザでサインインしてみましょう。
先ほどのURLを開くと、デフォルトでアカウントIDが入力されています。
続けて、ユーザー名とパスワードを入力して「サインイン」をクリック。
強制パスワード変更
手順(7) で初回サインイン時に強制的にパスワードを変更するよう設定したので、まずパスワード変更を求められます。
新旧パスワードを入力してから「パスワード変更の確認」をクリック。
無事にサインインできました。
画面右上のユーザ名がadminになっています。
以上でIAMユーザの作成は完了です。
まとめ
今回は管理者権限を持つIAMユーザを作成しました。
権限的にはルートアカウントと同じことができるユーザなので厳重に管理する必要があります。
万が一adminユーザの情報が漏洩してしまった場合には、直ちに権限を剥奪したりユーザごと削除するなどの対応が必要です。
可能であれば、administrator権限を使わずにさらに限定した権限で運用することも検討してみてください。
また、AWSではパスワードの文字数や使用する文字種などのポリシーを定義することがベストプラクティスですので、AWSでIAMユーザのパスワードポリシー設定方法の記事も参考に設定してみください。
こんな記事も読まれてます
|
20代30代の客先常駐ITエンジニアが最速で年収を上げる方法 この記事の所要時間： 約 14分56秒
この記事の所要時間： 約 14分56秒 もしあなたが以下の3つ全てに該当するエンジニアであれば、今すぐにでも転職をオススメします。 客先常駐型のエンジニアとして働いている 案件の途中で契約を切られるこ … |
