はぐれメタルはにげだした

身近な趣味からテクニカルな話題まで幅広く取り扱っていきます

技術

【AWS】IAMユーザーとIAMロールの違いを理解して適切に権限管理する

投稿日:2018年2月27日 更新日:

この記事の所要時間: 1310

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以外のサーバに付与するためのIAMオブジェクトです。

人が使う場合

例えばサーバ運用者に業務上必要な権限を付与する場合はIAMユーザを作成します。

IAMユーザにマネージメントコンソールへのログイン権限とEC2のフルアクセス権限を付与して、そのIAMユーザにログインするためのIDとパスワードをサーバ運用者に通知します。

サーバ運用者は通知されたIDとパスワードを使うことで、EC2インスタンスの構築業務を行うことができます。

この場合、付与されている権限はEC2のアクセス権のみですのでRDSの操作は行えません。

従って、このサーバ運用者が使用するIAMユーザによってRDSインスタンスが破壊・参照されることは100%ありません。

サーバが使う場合

例えばオンプレのサーバからs3にファイルをアップロードするアプリケーションを作成する場合、IAMユーザにはs3バケットへの参照権限、書き込み権限を付与します。

さらに、IAMユーザからアクセスキーとシークレットキーを発行し、オンプレのサーバ上にクレデンシャルファイルとして保存します。

サーバからs3へアクセスする際には、このクレデンシャルファイルを参照して認証を行います。

万が一このクレデンシャルファイルが外部に流出してしまうと、第三者にs3へのアクセスを悪用されてしまう可能性があるため厳重に管理する必要があります。

IAMロール

IAMロールとは、EC2やLambdaなどのAWSリソースに権限を付与するためのIAMオブジェクトです。

例えば、EC2上でs3へのファイルアップロードアプリケーションを作るとしましょう。

IAMロールにはs3バケットへの参照権限、書き込み権限を付与します。

作成したIAMロールをEC2インスタンスにアタッチすることで、IAMロールの権限がEC2インスタンスに適用されます。

IAMロールはクレデンシャルファイルの管理が不要

オンプレではIAMユーザのクレデンシャルファイルをサーバ上で厳重に管理する必要がありましたが、IAMロールの場合はAWSの内部でIAMロールとEC2が直接紐づけられるためファイルを管理する必要がありません。

つまり、IAMロールならクレデンシャルファイルの流出リスクは100%ありません。

もちろんIAMロールを使わずにIAMユーザを使って(クレデンシャルファイルをEC2上で管理して)EC2に権限を付与することもできますが、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ユーザのアクセスキー及びシークレットアクセスキーが表示されます。

先ほどAPIを叩く際にアクセスキーが必要になると書きましたが、正確にはアクセスキーとシークレットアクセスキーが必要となります。どちらもAWSにアクセスするための認証キーとして使うものですが、両者の明確な違いは「後からこのキーを参照できるか否か」です。

アクセスキーは、IAMの管理画面からいつでも参照できます。

しかし、シークレットアクセスキーは今後AWS上では一切参照できません。

「あれ?シークレットアクセスキー忘れちゃったんだけど〜」という事態になっても、AWS側からは一切教えてくれません。

これはセキュリティを高めるため、必要以上に情報が外部に漏れることを防ぐための施策です。

シークレットアクセスキーを参照できるのは、IAMユーザを作成した今この瞬間のみとなりますので、この時点で必ず保存しておく必要があります。

ユーザを作成した本人にしか見せないシークレットな情報なので、シークレットアクセスキーと呼ばれています。(多分)

認証情報は画面右下からダウンロードできますが管理はくれぐれも適切に。

ダウンロードが済んだら、その横の「閉じる」をクリックします。

IAMユーザの確認

ダッシュボードには、今作成したIAMユーザが表示されています。

クリックすると詳細情報を表示できます。

認証情報タブを開くと先ほどのアクセスキーが確認できます。

シークレットアクセスキーはもう表示されません。

パスワードの変更

そのまま下にスクロールするとサインイン認証情報が表示されます。

パスワードを変更するために「パスワードの管理」をクリックします。

初期パスワードの設定

まず、パスワードをランダムで自動作成するか、任意で作成するかを選択します。

デフォルトは自動作成です。

カスタムを選択すると、パスワードの入力フォームが表示されます。

企業の運用ポリシーなどでデフォルトパスワードが固定されている場合はこちらを選択すると良いでしょうが、今回は自動作成にします。

その下の「次回のサインインで新しいパスワードを作成するようにユーザーに求める」は初回サインイン時に強制的にパスワードを変更させるか否かです。

自分以外の人にIAMユーザを発行する場合は、ここにチェックをつけておきましょう。

試しに今回もチェックを付けてみます。

最後に、画面右下の「適用」をクリックします。

パスワードの確認

先ほどのアクセスキーと同じレイアウトでパスワードが確認できます。

同様に、認証情報をダウンロードしてから「閉じる」をクリックします。

パスワード変更完了

これでadminユーザに対するパスワードが生成されました。

管理画面からも「パスワード」が「はい」になっていることが確認できます。

また、同じ画面でMFAの設定を行うことも可能です。

こちらも設定しておいたほうが良いですが今回は省略します。

設定する場合は、前回書いたAWSルートアカウントのMFA設定方法の手順2以降を実施すればOKです。

管理者権限グループの作成

adminユーザに管理者権限を与えますので、管理者権限グループを作成し、そのグループにadminユーザを追加します。もちろんユーザ個々に権限を与えることもできますが、管理が煩雑になってしまうので用途が明確な権限はグループ単位で定義しておいたほうが良いでしょう。

画面左から「グループ」を選択し、「新しいグループの作成」をクリック。

グループ名の設定

管理者権限グループなので、Administrators にしておきます。

ポリシーのアタッチ

グループに与える権限をここで定義します。

今回は管理者権限を与えるので、一番上に表示されている「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ユーザのパスワードポリシー設定方法の記事も参考に設定してみください。

-技術
-,

関連記事

AWSルートアカウントのMFA設定方法

この記事の所要時間: 432

この記事の所要時間: 約 4分32秒 通常のログインメージ MFA設定後のログインメージ ルートアカウントはAWSに対するフルアクセス権限を持っているため、もし第三者に流出し悪用されてしまうと甚大な損 …

AWSアカウントの作成方法と無料で使い続けるたった1つの方法

この記事の所要時間: 746

この記事の所要時間: 約 7分46秒 多くのクラウドサービスでは、サービスを試用するための無料枠が用意されています。 AWSでも色々なサービスの無料枠が提供されていますが、EC2などほとんどのサービス …

AWSでIAMユーザのパスワードポリシー設定方法

この記事の所要時間: 42

この記事の所要時間: 約 4分2秒 IAMのデフォルトのパスワードポリシーは非常に低セキュリティです。 どれくらい低セキュリティかというと aaaaaa とか 123456 とか6文字以上の文字列なら …

AWS WAFでWordPressを保護するための設定例

この記事の所要時間: 1538

この記事の所要時間: 約 15分38秒 AWS WAFはセットアップするだけならクリックぽちぽちでいけるので非常に簡単なんですが、いざ運用を検討しだすとハマりポイントがいくつも出てきて頭を悩ませてしま …

AWS無料枠の使用状況や残りの期間を確認する方法

この記事の所要時間: 320

この記事の所要時間: 約 3分20秒 AWSを使う上で最も気になることの1つが利用コストですよね。特に無料枠のみでやりくりしたいと考えている場合、「今月分の無料枠の使用状況を確認する方法」と「無料期間 …

プロフィール

プロフィール



はぐれん@フリーランサー

10代〜20代前半くらいまではガンガンいこうぜ。20代半ばで鼻っ柱を砕かれて一度はめいれいさせろの支配下に置かれかけたものの、いや逃げりゃいいんじゃんって気付いてからはまた違う世界が見えて来た。30代半ばに差し掛かった今、いろいろやろうぜ。