トップ > AWS > AWSアカウントとは？IAMとは？【ビギナー向け】

AWSアカウントとは？IAMとは？【ビギナー向け】

AWS
記事タイトルとURLをコピーする

技術三課の杉村です。これからAWSを本格的に利用していこうと思っている方のために、AWSにおけるセキュリティの基本であるAWSアカウントとIAM (Identity and Access Management)の違いについて解説します。 AWSビギナーの方でも理解いただけるよう表現を抽象化したり、あえて深く説明していない部分もありますが、まずは概要を理解するためのものとお考えください。

1. AWSアカウント

1-1. AWSアカウントとは

AWSアカウント（エーダブリューエスアカウント）は、身近な言葉で言うと「テナント」です。 AWSを利用したい、と思ったときは、まずAWSもしくはAWSのパートナーから "テナント" すなわちAWSアカウントを払い出してもらいます。 アカウントという言葉からは「Active Directoryのアカウント」のように個人に紐づくアカウントを想像してしまう方もいますが、AWSアカウントはそうではありません。

利用者はそのAWSアカウントの中に、VPC（仮想的なネットワーク）やEC2（仮想サーバ）、またLambdaといったFaaSサービス、S3バケットのようなストレージを持つことができます。 ※なおVPC, EC2, S3のようなAWSアカウント内の"モノ"をAWSリソースと呼びます。

1-2. 複数のAWSアカウントを利用する

もちろん、一つの会社や組織が複数のAWSアカウントを持っていても構いません。 AWSアカウントを分けることで、例えば以下のメリットがあります。

  1. AWS権限の明確な分離（セキュリティ・ガバナンス上のメリット）
  2. AWS利用料金の明確な分離（コスト管理上のメリット）

例えば、ある会社が下記のようにAWS Account AとAWS Account Bの2つを持っているとします。 開発部署AはAWS Account Aを、開発部署BがAWS Account Bを利用しています。

まず1. AWS権限の明確な分離（セキュリティ・ガバナンス上のメリット）についてです。

もし同じAWSアカウント内に開発部署AのAWSリソースと開発部署Bのリソースが混在していると、お互いのリソースが「見えている」状態になります。 すなわち、リソース一覧に表示されるし、VPC（仮想ネットワーク）の設定によっては、相互に通信ができてしまいます。 また権限設定の不備があった場合、思わぬ事故（間違って設定変更してしまった、リソースを消してしまった...）ということも起こり得ます。 AWSアカウントを分けておけば、その部署のAWSアカウント以外のリソースは「見えない」ですし、見えなければ基本的に事故は起きません。

この分け方は「開発環境」「ステージング環境」「本番環境」のような区分けでも同じことが言えるでしょう。

次に2. AWS利用料金の明確な分離（コスト管理上のメリット）についてです。

たとえ一つのAWSアカウント内に開発部署AのEC2インスタンスと開発部署BのEC2インスタンスが混在していても、どちらの部署の利用で発生したEC2利用料金なのかは、EC2インスタンスに付与したタグ（タグ別明細機能）によって分類することが可能です。

しかし、例えば「専用線（Direct Conect）のデータ転送料金」など、一部の利用料金はタグ付けが不可能です。またCloudTrailのログ保管料金など、必ず「共用管理費」のような浮いてしまう料金が発生します。 また、一部のAWSリソースにはそもそもタグ別明細に対応していないものもあります。

AWS利用料金はAWSアカウント単位で発生するため、AWSアカウントを分けることで完全に料金を分け、また請求書も分けることが可能です。

2. IAM

2-1. IAMとは

IAM (Identity and Access Management)は日本ではよく「アイアム」と発音されます。英語圏では「アイエーエム」と発音されることが多いようです。 難しく説明すると「AWSのAPIコールのための認証・認可を制御するための権限体系」などとなると思います。

重要な概念として、IAM User, IAM Roleがあります。

2-2. IAM User

先ほどの「Active Directoryのアカウント」のように個人に紐づくアカウントは、AWSにおいてはIAM Userが該当します。

ひとつのIAM Userに対して、以下を発行することができます。（払い出さないという選択も可能）

  1. マネジメントコンソールにログインのためのパスワード
  2. Access KeyおよびSecret Access Key

なおこれらはいずれも、英数字記号のテキスト情報です。

1. コンソールログインのためのパスワードを利用して、利用者はAWSアカウントのマネジメントコンソールにログインすることができます。 マネジメントコンソール（以下、マネコン）を使って、利用者はVPCやEC2などのAWSリソースを作成したり操作することができます。

2. Access KeyおよびSecret Access KeyはAWSのAPIをプログラムやAWS CLIから呼び出すときにいわば「ID/パスワード」として機能します。

AWS CLIを利用してコマンドラインで、あるいはbashのスクリプトを書いてAWSのリソースを操作するときなどに利用します。 Access Key/Secret Access KeyのことをCredential（クレデンシャル）と呼ぶこともあります。

また、IAM UserにはIAM Policyという権限ポリシーを設定できます。

IAM Userはこのポリシーの範囲内でのみ、マネジメントコンソールやCLIで操作を行えます。 例えば「Aさんは、ほぼ全てのAWSリソースを閲覧・編集・削除できる管理者権限。BさんのIAM UserはEC2を閲覧と、起動・停止する権限だけ。」といった具合です。

運用としては基本的に、AWSを利用する個々人ごとにIAM Userを発行することになります。 ひとつのIAM Userを複数人で共用すると、セキュリティ上の懸念となることはご理解いただけるかと思います。

またスクリプトやプログラムからAWSを操作する目的でプログラムのためのIAM Userを発行し、Access Key/Secret Access Keyを発行してプログラムに持たせることもできます。 ただしこのような方法はできるだけ避けるべきです。 プログラムのソースコードにハードコードすることはもちろん、設定ファイルにAccess Key/Secret Access Keyを持たせることも、できるだけ避けたいです。

なぜならAccess Key/Secret Access Keyは文字情報であり、漏洩してしまうとこのIAM Userの持つ権限の範囲内であれば他人があなたのAWSアカウントのAWSリソースを操作できてしまうことになるからです。

ではどうすればよいのでしょうか？

より良い方法としては、次項のIAM Roleを利用する方法があります。

2-3. IAM Role

IAM Roleは、IAM Userに似ています。IAM RoleにはIAM Policyを設定でき、IAM Roleはその権限範囲内でAWSのリソースを操作できます。

しかしIAM Roleからは「コンソールログインのためのパスワード」「Access Key」「Secret Access Key」といったものは発行できません。 それではIAM Role何に使うのでしょうか？

IAM Roleの使い方は、概ね2通りです。

  1. EC2やLambdaなどのAWSリソースにアタッチして使う
  2. IAM Userや他のIAM Roleから"AssumeRole"（Roleの引き受け）をして使う

1個目の使い方は、簡単です。

EC2やLambdaにIAM Roleをアタッチして使います。そのEC2やIAM Role上で動作するプログラムは、IAM Roleを利用することができます。 先ほどの「IAM UserのAccess Key/Secret Access Keyを使う」方法だと、テキスト情報でID/パスワード相当の情報をプログラムの中や設定ファイルに持つ必要がありますが、このIAM Roleを利用した方法であれば、IAM RoleはEC2自体、またはLambda自体にアタッチされていますので、流出する心配がありません。

もう少し書くと、AWS CLIやAWS SDKは「もしAccess Key/Secret Access Keyが明示的に設定されていなければ自分のいるEC2/Lambdaに設定されたIAM Roleを見に行く」という動作をします。

参考: https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-configure.html#config-settings-and-precedence

2つ目の使い方は少し複雑です。

簡単に書くと、IAM UserやIAM Roleはsts:AssumeRoleというAPIコールを使うことで、他のIAM Roleの権限を一時的に引き受けることができます。

引き受けられる方のIAM Roleには「このIAM Userさんは信頼します。このIAM Roleさんは信頼します。それ以外は信頼しません」というような信頼関係ポリシーを設定することができます。信頼されているIAM UserやIAM Roleだけが、そのIAM RoleをAssumeRoleすることができるというわけです。

なぜこのようなことをする必要があるのでしょうか？ このAssumeRole機能は、大規模なAWS利用の際に「複数のAWSアカウントを運用する」という場合に非常に役に立ってきます。

AssumeRole機能を使った複数AWSアカウント運用については、次のブログで解説しようと思います。

今回はここまで。

杉村 勇馬 (記事一覧)

サーバーワークス → 株式会社G-gen 執行役員CTO

2021 Japan APN Ambassadors / 2021 APN All AWS Certifications Engineers

マルチAWSアカウント管理運用やネットワーク関係のAWSサービスに関するブログ記事を過去に執筆。

2021年09月から株式会社G-genに出向、Google Cloud(GCP)が専門に。G-genでもGoogle Cloud (GCP) の技術ブログを執筆中。