はじめに
AWSで環境構築・検証を行う上でほぼ必須となるIAMの基本的な知識について、個人的に色々と悩まされたので備忘録です。
初めてAWSやIAMを利用する方への参考になれば嬉しいです。
IAMとは
IAMに関する公式の概要は以下の通りになっています。
アクセスを安全にコンソールするためのウェブサービスです。
IAM を使用して、リソースを使用するために認証 (サインイン) され、許可された (アクセス許可を持つ) ユーザーを制御します。
つまり、AWS上のリソースを安全に使用するためにIAMを使ってちゃんと認証すれば皆ハッピー。
また、IAMには以下のような様々な機能があります。
(ここでは筆者個人が主に使用する/した、主な機能をピックアップします)
アクセスの共有
パスワードやアクセスキーを共有しなくても、第三者にAWSアカウント内の管理および使用するためのアクセス権を付与できる。
多要素認証(MFA)
別途設定された物理デバイスを使用し、認証を多要素化する機能。最近ではメジャーなセキュリティ対策。
詳細なアクセス権限の付与
ポリシーを用いてユーザごと、リソースごとなどに細かくアクセス権を付与できる。最小権限の原則に法って設定することができる。
その他にも、PCI DSSへの準拠、IDフェデレーションなどの機能がある。
IAMへのアクセス
IAMを利用するには、以下のアクセス方法を使用することができる。
AWS マネジメントコンソール
お馴染みのマネジメントコンソール。サービス一覧からIAMを選択し、利用する。
AWS コマンドラインツール
業務上マネジメントコンソールにアクセスできないので、筆者が最も頻繁に使用しているアクセス方法。
・AWS Command Line Interface
・AWS Tools for Windows PowerShell
の２つが存在する。しかしWindowsでもAWS CLIを利用することは可能なので、PowerShellを使うかどうかは単純に好みの問題。
AWS SDK
Java,Python,Rubyなどのプログラミング言語などのライブラリとサンプルコードで構成されたSDK。
AWS HTTPS API
サービスにHTTPS リクエストを直接発行できる IAM HTTPS API を使用して、プログラムにより IAM と AWS にアクセスする方法。
リクエストにデジタル署名を含める必要がある。
ユーザとロール
ここからがこの記事で一番書きたかった内容です。
IAM周りの設定をしている中で、当初ユーザとロールの概念をあまり理解できていなかったのでAWS CLIでエラーを吐きまくっていました。。。
ポンコツでした。。。
AWS ルートユーザ
IAMの話をする前に、AWSのユーザについて。
AWS ルートユーザはAWS アカウントの作成時およびAWS へのサインインに使用するアカウント。アカウント内の全てのリソースに無制限にアクセスできる。
また、各サービスのマネジメントコンソールにはルートユーザーとしてサインインできる。
アカウントの作成時に指定したメールアドレスとパスワードの組み合わせをルートユーザー認証情報と呼ぶ。
ちなみに、公式ではセキュリティ的な観点から「日常のアクセスには、ルートユーザー認証情報を使用しないことを推奨」している。
IAM ユーザ
AWSで作成したエンティティ。
利用者が対話型タスクを実行するために AWS マネジメントコンソールにサインインする場合や、API または CLI を使用して AWS サービスに対しプログラムによるリクエストを行う場合に使用。
IAMユーザを作成しただけでは、該当のユーザにアクセス権は設けられていないため、いかなる操作もできない。そのため、適切に「ポリシー」をアタッチされたグループに所属させるか、ユーザに直接ポリシーをアタッチして利用する必要がある。また、 IAMユーザーはクローンを作成することができ、新しいユーザーは自動的に同じグループのメンバーとなり、同じポリシーがすべてアタッチされる仕組みも備わっている。
IAM ロール
**"ポリシーが適用されるID"**である点で、ユーザーによく似ている。ただし、ロールには、認証情報を関連付けることができない。
ロールは特定の個人ではなく、必要に応じて誰でも引き受けることができるようになっている。
IAMユーザが「特定の操作を引き受けることができる人(もしくはアカウント)」であるのに対し、
IAMロールは「特定の操作が可能な権限そのもの」であるイメージ。
〜〜余談〜〜
AWSでの環境構築開始当初、僕は疑問を持っていました。
「認証情報の有無しか違いが無いのであれば、全部IAMユーザで管理しちゃえばよいのでは？？」
しかしこれは大きな間違いでした。
筆者「EC2もRDSもS3も構築終わったし、構築のためにフルアクセスにしていたIAMユーザの権限を縮小するかー」
上司「ん？筆者くん、構築終わったんだよね？EC2からS3にファイルアップロードできないんだけど」
筆者「え、でもユーザのアクセス権は残ってますよ？」
上司「それ、IAMユーザの話だよね？ロールはどうなってるの？」
筆者「ん？ロール？？？」
IAMユーザとロールの違い
まずはIAMユーザについてイメージしてみます。
上記の説明を踏まえてまとめると、IAMユーザは以下のようなものだと言えるでしょう。
「IAMユーザは、AWS内のリソースへのアクセス権を作業者(人、アカウント、AWS外のサーバなど)に付与する場合に使用する」
つまり、作業者ごとに適切な権限を付与されたIAMユーザを利用することで、アクセスするべきではないAWSのリソースに関する誤操作を予防できます。
〜〜利用例〜〜
上図を例に説明します。
・社内NW内の作業者はIAM User "worker"としてAWSにログインすることができる
・社内NW内のサーバはIAM User "server"としてAWSにログインすることができる
・"worker"は「EC2インスタンスの起動・停止」に関わる権限を付与されている
・"server"はLambdaファンクションの実行権限を付与されている
つまり、上図の場合「作業者が"worker"としてログインした状態でLambdaファンクションを呼び出すことはできない」と言えます。
ユーザへの適切なアクセス権の付与によって、操作可能なリソースを限られた範囲に限定することができました。
では、次のような場合はどうでしょう。
「S3に特定のファイルがアップロードされたら、S3がLambdaをキックしてRDSへクエリを発行する」
S3やLambdaファンクションそのものに対しても何かしらの権限を付与する必要がありそうですね。
ということで、続きは後編へ。
最後に
IAMロールの説明を残して前編を終了とします。
後編ではプリンシパルなどの概念も説明できればいいなと思っています。
記事内に誤りがあればご指摘いただけると嬉しいです！！