概要
やっと、投稿日とタイトルとのギャップが埋まります。
ソリューションアーキテクトの資格を受けるのにこんなにゆっくり勉強していて、
果たして、合格できるのだろうか？
まぁ、もしこれを最後までお読み頂ける方がいらっしゃるのであれば、
合否も私はお伝えしますので、どちらに転んでも参考にしていただければと幸いです。
(参考にならないかもしれませんが…)
最近、この概要は全然、概要になってないんじゃないかと感じてきています。
日記みたいになっちゃってるなぁ…
7日目で書いたアカウント設定の続きをまとめていきます。
[1] アカウントの作成とログイン
3.ポリシーとアカウントの設定
前回まででアカウントとポリシーは出来上がりました。
しかし、この二つが結びつかなきゃ意味がないですよね。
というわけでアカウントとポリシーを結びつける設定を行おうと思います。
(1)IAMダッシュボードの[ユーザー]をクリックします
(2)ポリシーを紐づけるアカウントをリスト上からダブルクリックします
(3)アクセス許可タブの配下に管理ポリシーを適用するか
インラインポリシーを適用するかを選ぶことができます
・管理ポリシー(AWS管理ポリシーまたはカスタマー管理ポリシー)を適用する場合
(4)[ポリシーのアタッチ]をクリックします
(5)一覧から適用するポリシーを選択し、[ポリシーのアタッチ]をクリックします
※事前にポリシーを作成している場合はカスタマー管理ポリシーも選択できます
(6)アカウントに管理ポリシーが設定されました
ちなみに適用したポリシーを削除する場合は画面に表示されている
[ポリシーのデタッチ]をクリックします。
・インラインポリシーを適用する場合
(4)インラインポリシー欄の赤枠箇所をクリックします
(5)[ここをクリックしてください]をクリックします
(6)ポリシーの設定方法を[Pollicy Generator]か[カスタムポリシー]のどちらで作るかを選べます
Pollicy Generatorでポリシーを設定する方法は前述したんでここには書かないです。
そもそも、目的は資格に受かることですし…
ちなみに[カスタムポリシー]で作る場合は本当にJSONを1から書いていくことになります。
こんな画面が出てきます。
とまぁ、ここまで書いたようにアカウントとポリシーは直接、紐づけることも出来ますが
それだと操作する人が増える度に設定が大変です。
それに誰にどのような権限を与えているのかもグループ単位で
権限を管理していれば簡単に把握することができます。
そこでポリシーを設定する際にはグループを使用するのが一般的なようです。
4.グループの作成とポリシーの設定
(1)IAMダッシュボードのメインメニューから[グループ]をクリックします
(2)[新しいグループの作成]をクリックします
(3)[グループ名]に任意のグループ名を入力し、[次のステップ]をクリックします
(4)一覧から設定するポリシーを選択して[次のステップ]をクリックします
※グループを作成する段階で強制的にポリシーも設定するようにできているんですね。
(5)内容に問題がなければ[グループの作成]をクリックします
(6)一覧画面に作成したグループが表示されます
5.グループへのアカウント追加
グループとポリシーの紐づけは出来ましたがグループにアカウントを追加しなければ、
管理していることになりませんよね…
グループにユーザを追加するには以下の操作を行います。
(1)IAMダッシュボードの[グループ]一覧画面でユーザを追加するグループを選択し、
[グループのアクション]-[グループにユーザーを追加]をクリックします
(2)追加する対象のアカウントを選択して[ユーザーの追加]をクリックします
(3)一覧画面に戻ってきて、[ユーザー欄]の数が0から1に増えグループ設定が完了
とまぁ、ここまでがアカウント管理の基本のようですね。
※実はロールの設定というのもありますが、それは明日、補足して載せることにします。
こんな初歩的なところにどれだけ時間かけてんだよ！
…みたいな体育会系なツッコミは勘弁してください。
…明日も仕事なんで、ここいらで今日は区切ります。
◆総括
アカウント管理の部分の勉強をしてきて、分かりにくかったのは各ポリシーの違いでした。
AWS管理ポリシーとカスタマー管理ポリシーの違いがちょっと分かりにくかったです。
(単に私のITリテラシーの問題である可能性もあります)
カスタマー管理ポリシーもAWS管理ポリシーから派生しているから、
仕様変更の影響を受けるのかと思いきやそんなことはなく…
また、PolicyGeneratorで作れるのはインラインポリシーだけかと思いきや、
カスタマー管理ポリシーも作ることができ…前回の記事で色々と誤解してました。
インラインポリシーというのはポリシー単独で存在せず、
アカウントの1つの情報として登録されるのが明確な違いでした。
それとアカウントベースではなく、AWSリソース単位でアクセス権を設定する方法や
アクセス権を委任する設定なども見つかり、IAMは奥が深かいですねぇ。
[参考]IAM ロールとリソースベースのポリシーとの相違点
http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_compare-resource-policies.html
[参考]IAM ユーザーにアクセス権限を委任するロールの作成
http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_create_for-user.html
まぁ、今回の目的はまず資格を取るということなので、
あまり深追いして時間を使いすぎないよう、後々きつくならないよう…