メニュー
AWS Identity and Access Management
ユーザーガイド

ビジネスユースケース

IAM の簡単なビジネスユースケースを紹介します。お客様のユーザーが持っている AWS アカウントを制御するサービスを実装できる基本的な方法を解説します。ユースケースでは、お客様が求めている結果を得るために IAM API を使用する方法を、一般的に説明しています。

このユースケースでは、Example Corp という架空の企業が IAM を使用する典型的な 2 つの方法を検討します。最初のシナリオでは、Amazon Elastic Compute Cloud が考慮されます (Amazon EC2)。2 つめは、Amazon Simple Storage Service が考慮されます (Amazon S3)。

IAM と AWS の他のサービスとの連携の詳細については、「IAM と連携する AWS サービス」を参照してください。

Example Corp の初期設定

Joe は、Example Corp. の創立者です。業務を開始するにあたって、まず自分の AWS アカウントを作成して AWS 製品を使用します。そして、開発者、管理者、テスター、マネージャー、そしてシステム管理者として働く従業員を雇います。

Joe は、AWS account root user 認証情報で AWS マネジメントコンソール を使用し、本人用として Joe という名前のユーザーと、Admins という名前のグループを作成します。AWS 管理ポリシー (AdministratorAccess) を使用して、AWS アカウントの全リソースに対するすべてのアクションを実行するためのアクセス許可を Admins グループに付与します。 次に、Joe というユーザーを管理者グループに追加します。自身で管理者グループと IAM ユーザーを作成し、ユーザーを管理者グループに追加するの詳細な手順については、「最初の IAM 管理者のユーザーおよびグループの作成」を参照してください。

この時点で、Joe は AWS の操作に root user の認証情報を使用することを中止できます。代わりに、本人のユーザー認証情報を使用します。

Joe は、AllUsers というグループを作成して、アカウント全体のアクセス権限を AWS アカウントのすべてのユーザーに簡単に適用できるようにします。そして、自分自身をグループに追加します。そして、Developers グループ、Testers グループ、Managers グループ、SysAdmins グループを作成します。各従業員用ユーザーを作成し、各グループに割り当てます。さらに全ユーザーを AllUsers グループに追加します。グループ作成の詳細については、「IAM グループの作成」を参照してください。ユーザー作成の詳細については、「AWS アカウント内での IAM ユーザーの作成」を参照してください。グループへのユーザーの追加については、「IAM グループの管理」を参照してください。

Amazon EC2 を用いた IAM のユースケース

一般的に、Example Corp のような会社は IAM を使用して Amazon EC2 などのサービスとやり取りします。ユースケースの当該部分を理解するには、Amazon EC2 の基本的な理解が必要となります。Amazon EC2 の詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」を参照してください。

グループ用 Amazon EC2 アクセス許可

「境界」制御を提供するために、Joe は AllUsers グループにポリシーを添付します。このポリシーは、元の IP アドレスが Example Corp の企業ネットワークの外部にある場合、ユーザーからの AWS 要求を拒否します。

Example Corp では、グループごとに異なるアクセス許可が必要です。

  • System Administrators – AMI、インスタンス、スナップショット、ボリューム、セキュリティグループなどの作成および管理のアクセス許可が必要です。Joe は、すべての Amazon EC2 アクションを使用するためのアクセス許可をグループのメンバーに付与するポリシーを SysAdmins グループにアタッチします。

  • Developers – インスタンスのみを使用する機能が必要です。従って Joe は、DescribeInstancesRunInstancesStopInstancesStartInstances および TerminateInstances の呼び出し許可を開発者に与えるため、Developers グループにポリシーをアタッチします。

    注記

    Amazon EC2 は SSH キー、Windows パスワードおよびセキュリティグループを使用して、特定の Amazon EC2 インスタンスのオペレーティングシステムへのアクセス許可を持つユーザーをコントロールします。IAM システムには、特定のインスタンスのオペレーティングシステムへのアクセスを許可または拒否するメソッドは存在しません。

  • Managers – 現在使用可能な Amazon EC2 リソースにリストされているものを除き、いかなる Amazon EC2 アクションも実行することはできません。このため Joe は、Amazon EC2 の "describe" API の呼び出しのみを許可するポリシーを Managers グループにアタッチします。

これらのポリシーの記述例については、『Linux インスタンス用 Amazon EC2 ユーザーガイド』の「ポリシーの例」および「AWS Identity and Access Management の使用」を参照してください。

ユーザーのロール変更

ある時点において、開発者の 1 人である Don のロールが、マネージャーへと変更されたとします。Joe は、Don を Developers グループから Managers グループへと移行します。これで Don は Managers グループに所属することとなり、Don が Amazon EC2 インスタンスについて行使できる権限は限定されます。Don はインスタンスの起動や開始をすることができません。また Don がインスタンスを起動または開始させた人物だったとしても、既存のインスタンスの停止や終了をすることができません。Don は、Example Corp のユーザーが起動するインスタンスを表示することのみできます。

Amazon S3 を用いた IAM のユースケース

Example Corp のような会社では、IAM と Amazon S3 も使用するのが一般的です。Joe は、example_bucket という会社用に Amazon S3 バケットを作成しました。

その他のユーザーおよびグループの作成

従業員として、Don と Mary はそれぞれ会社のバケットに独自のデータを作成する必要があります。また、すべての開発者が作業する共有データを読み取りや書き込みをする必要があります。これらを可能にするため、Joe は下図のとおり Amazon S3 キープレフィックススキームを使用し、example_bucket 内のデータを論理的に配置します。

/example_bucket
    /home
        /don
        /mary
    /share
        /developers
        /managers

Joe は、マスターの /example_bucket を、各従業員用の一連のホームディレクトリと、開発者グループおよびマネージャーグループ用の共有エリアに分割します。

そして、Joe はユーザーおよびグループにアクセス許可を割り当てるための一連のポリシーを作成します。

  • Don のホームディレクトリアクセス – Joe は、Amazon S3 キープレフィックス /example_bucket/home/don/ を持つすべてのオブジェクトの読み取り、書き込み、一覧表示を許可するポリシーを Don にアタッチします。

  • Mary のホームディレクトリアクセス – Joe は、Amazon S3 キープレフィックス /example_bucket/home/mary/ を持つすべてのオブジェクトの読み取り、書き込み、一覧表示を許可するポリシーを Mary にアタッチします。

  • Developers グループの共有ディレクトリアクセス – Joe は、/example_bucket/share/developers/ 内のすべてのオブジェクトの読み取り、書き込み、一覧表示を開発者に許可するポリシーをこのグループにアタッチします。

  • Managers グループの共有ディレクトリアクセス – Joe は、/example_bucket/share/managers/ 内のオブジェクトの読み取り、書き込み、一覧表示をマネージャーに許可するポリシーをこのグループにアタッチします。

注記

Amazon S3 はバケットまたはオブジェクトを作成するユーザーに対し、当該バケットあるいはオブジェクトでその他のアクションを実行する許可を自動的に付与することはありません。従って、IAM ポリシーでは、作成する Amazon S3 リソースを使用してもよいという明示的なユーザー許可を付与する必要があります。

これらのポリシーがどのようなものであるかの例は、Amazon Simple Storage Service 開発者ガイドアクセスコントロールを参照してください。ランタイムでのポリシーの評価方法の詳細については、「IAM ポリシーの評価論理」を参照してください。

ユーザーのロール変更

ある時点において、開発者の 1 人である Don のロールが、マネージャーへと変更されたとします。彼は、share/developers ディレクトリ内のドキュメントにアクセスする必要がなくなったとみなされます。Joe(管理者)は、Don を Developers グループから Managers グループへ移行します。簡単な再割り当てをするだけで、Don には自動的に Managers グループへのすべてのアクセス許可が与えられますが、share/developers ディレクトリ内のデータにはアクセスできなくなります。

サードパーティビジネスとの統合

組織は、頻繁に提携会社、コンサルタント、請負業者と組んで仕事をすることがあります。Example Corp は Widget Company と提携しています。Widget Company には Example Corp の使用しているバケットにデータを入力する Natalie という従業員がいます。Joe は、WidgetCo というグループと Natalie というユーザーを作成し、WidgetCo グループに Natalie を追加します。また Joe は、Natalie が使用できるよう example_partner_bucket という特別なバケットも作成します。

Joe が、パートナーの Widget Company に提供するために、既存のポリシーの更新または新規ポリシーの追加を行います。たとえば、WidgetCo グループのメンバーに対し、書き込み以外のいかなるアクションも拒否するという新規ポリシーを作成することができます。このポリシーは、広範囲にわたる一連の Amazon S3 アクションへのアクセス許可をすべてのユーザーに与えるような広義のポリシーが存在する場合にのみ必要となります。