概要
昨日書く予定だった7日目ですが、残念ながらまた深い眠りについていました。
6日目までAWSの全体像を振り返っていたわけですが、
とりあえずもう実機を触っていって覚えていこうと思います。
1日目でAWSのアカウントを作ったわけですが、全ての権限を有している
ルートアカウントを使用していると非常に危険です。
万が一ですが、アカウントを乗っ取られたりするとやりたい放題になってしまいます。
というわけでIAMと呼ばれるサービスを使ってアカウントを作成する手順を覚えておきます。
[1] アカウントの作成とログイン
IAMというのはIdentity and Access Managementの略で
要はAWSにおけるアカウント管理サービスです。
AWSのリソースに対する細かいアクセス権を含めて設定することができます。
1.IAMユーザーの作成
(1)AWSマネジメントコンソールにログインします
(2)メニューの中から[セキュリティアイデンティティ]-[Identity & Access Management]をクリックします
(3)[ユーザー]をクリックします
(4)[新規ユーザーの作成]をクリックします
(5)[ユーザー名の入力]欄に任意の名前を入力して[作成]ボタンをクリックします
※[ユーザーごとにアクセスキーを生成]にはチェックを入れたままにします
アクセスキーを生成した場合、AWS CLIやSDKを使用する際、認証情報として必要になります
(生成しない場合はパスワードのみとなるのでしょうか…セキュリティ的によろしくないですね)
(6)[認証情報のダウンロード]をクリックします
クリックするとCSV形式で出力された認証情報を保存することができます
※画面にも書いてある通り、ここで生成されたアクセスキーを忘れた場合、
同じアクセスキーは2度と使えなくなりますので大事な保管してください
2.IAMポリシーの作成
IAMアカウントは以下、2種類のポリシーにより管理されます。
①管理ポリシー
②インラインポリシー
①AWS管理ポリシー(管理ポリシー)
AWS側で定義してくれている権限セット。
複数のユーザ、グループ、ロールに付与することができます。
管理者権限、閲覧のみの権限、EC2に対するフルアクセス権限などが用意されています。
使用するメリットとしては設定するのは簡単というところです。
デメリットというか、注意しなければならないポイントとして、
AWSが管理を行っているため、自動でポリシーが更新されてしまう点です。
なので、極論を言えば、前までこの権限でこの機能を使用できていたのにみたいなことが起きます。
ちなみにAmazon様がご丁寧に図で説明してくれています。
②カスタマー管理ポリシー(管理ポリシー)
AWS管理ポリシーをユーザでアレンジし、定義する権限セット。
複数のユーザ、グループ、ロールに付与することができます。
こちらもAWS管理ポリシーと同様に説明用の図があります。
③インラインポリシー
特定のユーザのみに権限を付与したい場合に行う場合に利用します。
管理ポリシーとは根本的に違うのはプリンシパルエンティティ(ユーザー、グループ、ロールのことです)に対して権限が埋め込まれる形式になっていることです。
つまり、ポリシー単独で存在することはなく、必ず紐づくアカウントやグループ、ロールが存在しているという違いがあります
※2016/9/19 記事修正
最初はAWS管理ポリシーとインラインポリシーの2種類と記載していましたが、
ちゃんと調べてみたところ、広義の意味では上記2種類ですが、
正確にはカスタマー管理ポリシーを含めた3種類になります。
これらの違いは実際に画面で確認してみましょう。
AWS管理ポリシーをコピーして、EC2に対する管理者権限のポリシーを作成する手順を確認します。
(1)IAMダッシュボードメニューの中から[ポリシー]-[ポリシーの作成]をクリックします
(2)赤枠箇所の[選択]をクリックする
(3)一覧の中から[AmazonEC2FullAccess]を見つけて[選択]をクリックします
(4)[ポリシー名]と[説明]を入力して[ポリシーの作成]をクリックします
※ちなみにポリシー名に使用できるのは英数字と「 +=,.@-_ 」だそうです。
画面通り、怒られちゃってます…
(5)一覧に作成したポリシーが表示されていれば、作成完了です
ポリシーの実態はJSONで定義されています。
JSONが分かる人は中身を変えて、詳細にアクセス権を変更することが可能です。
(私はJSONに詳しくないし、あまり興味がないので作って頂いたままにしておきます…)
各Statementの意味は以下の通りだそうです。
・Effect
↓のAction、Resourceで指定した対象をどうするか、
許可(Allow)または拒否(Deny)で指定できます。
・Action
設定対象のサービスと対象の操作を指定できます。
*の場合はすべてのサービス、すべての操作を意味しています。
例を挙げるとEC2の全サービス、全操作を許可したい場合は以下のように記述します。
"ec2:*"
・Resource
設定対象のリソースを指定できます。
例を挙げるとEC2の特定のインスタンスのみに許可を行いたい場合は
Resourceに以下のように記述します。
arn:aws:ec2:"リージョン名":"アカウント名":instance/"インスタンスID",
特定ではなく、すべてのインスタンスに対して許可したい場合は
Resourceに以下のように記述します
arn:aws:ec2:*
と書きましたが、正直、非常に分かりづらいです。
世の中、JSONに詳しい人ばっかじゃないなと気づいてくれたAmazon様は
Policy Generatorなるものを作ってくれました。
というわけで実際に使ってみましたよ。
(1)ポリシーの作成画面で[Policy Generator]の横の[選択]をクリックします
選択してみるとこんな画面でました。
(2)AWSサービスという中には管理コンソール上に表示されている沢山のサービス名があります
(3)今回はサービスにEC2を選択して進めます[アクション]には
"CreateVPC"なるものがありましたのでそちらを選んでみますよ
要は指定されたインスタンスに対してVPCを作成できる権限ですね。
(リソースの指定は以下で行います)
※複数のアクションを選択できるようです…
(4)ここで気づきましたがARNってなんじゃ？ですね。
Amazon様、ご丁寧に入力欄の横にリンクが貼ってあったので、そちらへ飛んで確認して参りました。
そこに書いてある内容を要約しますと以下の様です。
ARN:
AWSリソースを一意に識別する値。
IAMポリシー、RDSタグ、APIの呼び出しなど、明らかに
全AWSに渡るリソースを指定する場合、ARNが必要です。
あ～これって先ほど確認したJSONのResource Statementのことですね。
ここにARNの構文と例文が記載されていますのでアクセス権をカスタマイズされたい方はどうぞ。
[参考]Amazon リソースネーム（ARN）と AWS サービスの名前空間
http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-ec2
(5)とりあえず、ARNにはEC2自体にはをイメージして
以下の内容を入力し、[ステートメントの追加]をクリックします
arn:aws:ec2:*
(6)すると画面が変わって以下のような感じになったので[次のステップ]をクリックします
(7)JSONのポリシーが出来ました。
試しに[ポリシーの検証]をクリックしますと[有効]と表示されました。
(8)では[ポリシーの作成]をクリックします
すると一覧画面が表示されて対象のポリシーが保存されていることが分かります
AWS管理ポリシーはポリシー画面の一覧上にAWSのマークが表示されているものです。
(※これを編集することはできません)
逆に表示されていないポリシーのことをカスタマー管理ポリシーになります。
カスタマー管理ポリシーも仕様の変更によって、
突然、操作ができなくなった!?みたいなことは起きません。
なぜなら、AWS管理ポリシーの権限を引用しているだけで、
カスタマー管理ポリシーとして登録された段階で
オリジナルのポリシーとして扱われることになるからです。
ただし、個別にメンテナンスが発生するというデメリットもあります。
※2016/9/19 記事修正
以前、上記にAWSマークが表示されていないポリシーが
インラインポリシーという形で記載していましたが
カスタマー管理ポリシーの間違いでしたので訂正しました。
さぁ、ここまででアカウントとそれを管理するためのポリシーが出来ました。
これらを結びつける必要があるのですが、いま出先でこれを書いているので、
いったん家に戻って続きを整理していこうと考えています(寝なければ…)