翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Textract のIdentity and Access Management
AWS Identity and Access Management(IAM) は、管理者がリソースへのアクセスを安全に制御するために役立つAWSのサービスです。AWSIAM 管理者は、誰にできるかを制御します。*認証済み*(サインイン) と*認可*Amazon Textract リソースを使用するには (権限を持つ)。IAM は、無料で使用できる AWS のサービスです。
**Topics**
+ [対象者](#security_iam_audience)
+ [アイデンティティを使用した認証](#security_iam_authentication)
+ [ポリシーを使用したアクセスの管理](#security_iam_access-manage)
+ [Amazon Textract で IAM を使用する方法](security_iam_service-with-iam.md)
+ [Amazon Textract のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)
+ [Amazon Textract の ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)
## 対象者
の使用方法AWS Identity and Access Management(IAM) は、Amazon Textract で行う作業に応じて異なります。
**サービスユーザー**— ジョブを実行するために Amazon Textract サービスを使用する場合は、管理者が必要なアクセス許可と認証情報を用意します。さらに多くの Amazon Textract 機能を使用して作業を行う場合は、追加のアクセス許可が必要になることがあります。アクセスの管理方法を理解しておくと、管理者に適切な許可をリクエストするために役に立ちます。Amazon Textract の機能にアクセスできない場合は、「」を参照してください。[Amazon Textract の ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)。
**サービス管理者**— 社内の Amazon Textract リソースを担当している場合は、通常、Amazon Textract へのフルアクセスがあります。管理者は、従業員がアクセスできる Amazon Textract 機能とリソースを決定します。その後、IAM 管理者にリクエストを送信して、サービスユーザーの許可を変更する必要があります。このページの情報を確認して、IAM の基本概念を理解してください。お客様の会社で Amazon Textract で IAM を利用する方法の詳細については、「」を参照してください。[Amazon Textract で IAM を使用する方法](security_iam_service-with-iam.md)。
**IAM 管理者**— IAM 管理者は、Amazon Textract へのアクセスを管理するポリシーの作成方法の詳細について確認する場合があります。IAM で使用できる Amazon Textract アイデンティティベースのポリシーの例を表示するには、「」を参照してください。[Amazon Textract のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)。
## アイデンティティを使用した認証
認証は、アイデンティティ認証情報を使用して AWS にサインインする方法です。AWS マネジメントコンソールを使用したサインインの詳細については、『*IAM ユーザーガイド*』の「[IAM ユーザーまたはルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/console.html)としての AWS マネジメントコンソール へのサインイン」を参照してください。
AWS アカウント のルートユーザーもしくは IAM ユーザーとして、または IAM ロールを引き受けることによって、*認証を受ける* (AWS にサインインする) 必要があります。会社のシングルサインオン認証を使用することも、Google や Facebook を使用してサインインすることもできます。このような場合、管理者は以前に IAM ロールを使用して ID フェデレーションを設定しました。他の会社の認証情報を使用して AWS にアクセスした場合、ロールを間接的に割り当てられています。
[AWS マネジメントコンソール](https://console.aws.amazon.com/)に直接サインインするには、パスワードとルートユーザーの E メールまたは IAM ユーザー名を使用します。ルートユーザーまたは IAM ユーザーのアクセスキーを使用して AWS にプログラム的にアクセスできます。AWS は、ユーザーの認証情報を使用してリクエストに暗号的で署名するための SDK とコマンドラインツールを提供します。AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。これには、インバウンド API リクエストを認証するためのプロトコル、*署名バージョン 4* を使用します。リクエストの認証の詳細については、*「AWS 全般のリファレンス」*の [「署名バージョン 4 の署名プロセス」](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) を参照してください。
使用する認証方法を問わず、追加のセキュリティ情報の提供を要求される場合もあります。例えば、AWS では多要素認証 (MFA) を使用してアカウントのセキュリティを高めることを推奨しています。詳細については、『*IAM ユーザーガイド*』の「[AWS での多要素認証 (MFA) の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)」を参照してください。
### AWS アカウント ルートユーザー
AWS アカウント を初めて作成する場合は、このアカウントのすべての AWS サービスとリソースに対して完全なアクセス権限を持つシングルサインインアイデンティティで始めます。このアイデンティティは AWS アカウント *ルートユーザー* と呼ばれ、アカウントの作成に使用した E メールアドレスとパスワードでサインインすることによってアクセスできます。強くお勧めするのは、日常的なタスクには、それが管理者タスクであっても、ルートユーザーを使用しないことです。代わりに、[初期の IAM ユーザーを作成するためにのみ、ルートユーザーを使用するというベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users)に従います。その後、ルートユーザーの認証情報を安全な場所に保管し、それらを使用して少数のアカウントおよびサービス管理タスクのみを実行します。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、単一のユーザーまたはアプリケーションに対する特定の許可を持つ AWS アカウント 内のアイデンティティです。IAM ユーザーは、ユーザー名とパスワード、アクセスキーのセットなど、長期的な認証情報を持つことができます。アクセスキーの生成方法の詳細については、『*IAM ユーザーガイド*』の「[IAM ユーザーのアクセスキーの管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)」を参照してください。IAM ユーザーにアクセスキーを生成するとき、必ずキーペアを表示して安全に保存してください。後になって、シークレットアクセスキーを回復することはできません。新しいアクセスキーペアを生成する必要があります。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) は、IAM ユーザーのコレクションを指定するアイデンティティです。グループとしてサインインすることはできません。グループを使用して、一度に複数のユーザーに対してアクセス許可を指定できます。多数の組のユーザーがある場合、グループを使用すると管理が容易になります。例えば、*IAMAdmins*という名前のグループを設定して、そのグループに IAM リソースを管理するアクセス許可を与えることができます。
ユーザーは、ロールとは異なります。ユーザーは 1 人の特定の人またはアプリケーションに一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。ユーザーには永続的な長期の認証情報がありますが、ロールではテンポラリ認証情報が利用できます。詳細については、『*IAM ユーザーガイド*』の「[IAM ユーザーの作成が適している場合 (ロールではなく)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* は、特定のアクセス許可を持つ、AWS アカウント 内のアイデンティティです。これは IAM ユーザーに似ていますが、特定のユーザーには関連付けられていません。[ロールを切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)ことによって、AWS マネジメントコンソールで IAM ロールをテンポラリに引き受けることができます。ロールを引き受けるには、AWS CLI または AWS API 演算を呼び出すか、カスタム URL を使用します。ロールを使用する方法の詳細については、『*IAM ユーザーガイド*』の「[IAM ロールの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html)」を参照してください。
IAM ロールとテンポラリ認証情報は、次の状況で役立ちます。
+ **テンポラリ IAM ユーザーアクセス許可** - IAM ユーザーは、特定のタスクに対して複数の異なるアクセス許可をテンポラリに IAM ロールで引き受けることができます。
+ **フェデレーティッドユーザーアクセス** - IAM ユーザーを作成する代わりに、Directory Service、エンタープライズユーザーディレクトリ、またはウェブ ID プロバイダーからの既存のアイデンティティを使用できます。このようなユーザーは *フェデレーティッドユーザー* と呼ばれます。AWS では、[ID プロバイダー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)を通じてアクセスがリクエストされたとき、フェデレーティッドユーザーにロールを割り当てます。フェデレーティッドユーザーの詳細については、『[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-roles)』の「*フェデレーティッドユーザーとロール*」を参照してください。
+ **クロスアカウントアクセス** - IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを別のアカウントの人物 (信頼済みプリンシパル) に許可できます。ロールは、クロスアカウントアクセスを許可する主な方法です。ただし、一部の AWS のサービスでは、(ロールをプロキシとして使用する代わりに) リソースにポリシーを直接アタッチできます。クロスアカウントアクセスでのロールとリソースベースのポリシーの違いの詳細については、『*IAM ユーザーガイド*』の「[IAM ロールとリソースベースのポリシーとの相違点](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)」を参照してください。
+ **[Cross-service access]** (クロスサービスアクセス) – 一部の AWS のサービスは、AWS の他のサービスの機能を使用します。例えば、サービスで呼び出しを行う場合、そのサービスでは Amazon EC2 でアプリケーションを実行したり、Amazon S3 にオブジェクトを保存したりするのが一般的です。サービスは、呼び出し元プリンシパルのアクセス許可、サービスロール、またはサービスリンクロールを使用してこれを行う場合があります。
+ **[Principal permissions]** (プリンシパル許可) – IAM ユーザーまたはロールを使用して AWS でアクションを実行する場合、そのユーザーはプリンシパルとみなされます。ポリシーは、プリンシパルにアクセス許可を付与します。一部のサービスを使用する場合、別のサービスで別のアクションをトリガーするアクションを実行することがあります。この場合、両方のアクションを実行するための許可が必要です。アクションがポリシーで追加の依存アクションを必要とするかどうかを確認するには、を参照してください。[Amazon Textract のアクション、リソース、および条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazontextract.html)の*サービス認証リファレンス*。
+ **[Service role]** (サービスロール) – サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、*「IAM ユーザーガイド」*の[「AWS のサービスにアクセス権限を委任するロールの作成」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。
+ **[Service-linked role]** (サービスリンクロール) – サービスリンクロールは、AWS のサービスにリンクされたサービスロールの一種です。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールは、IAM アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
+ **Amazon EC2 で実行されているアプリケーション** – EC2 インスタンスで実行され、AWS CLI または AWS API リクエストを作成しているアプリケーションの一時的な認証情報を管理するために、IAM ロールを使用できます。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。AWS ロールを EC2 インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスに添付されたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムはテンポラリ認証情報を取得することができます。詳細については、『*IAM ユーザーガイド*』の「[Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)」を参照してください。
IAM ロールと IAM ユーザーのどちらを使用するかについては、*IAM ユーザーガイド*の「[（IAMユーザーではなく）IAM ロールをいつ作成したら良いのか?](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role)」を参照してください。
## ポリシーを使用したアクセスの管理
AWS でのアクセスは、ポリシーを作成し、それらを IAM アイデンティティまたは AWS リソースに添付することで制御できます。ポリシーは AWS のオブジェクトであり、ID やリソースに関連付けて、これらのアクセス許可を定義します。ルートユーザーまたは IAM ユーザーとしてサインインすることも、IAM ロールを引き受けることもできます。その後リクエストを行うと、AWS が関連するアイデンティティベースまたはリソースベースのポリシーを評価します。ポリシーでのアクセス許可により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWS に保存されます。JSON ポリシードキュメントの構造と内容の詳細については、『*IAM ユーザーガイド*』の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
すべての IAM エンティティ (ユーザーまたはロール) は、アクセス許可のない状態からスタートします。言い換えると、デフォルト設定では、ユーザーは何もできず、自分のパスワードを変更することすらできません。何かを実行するアクセス許可をユーザーに付与するには、管理者がユーザーにアクセス許可ポリシーを添付する必要があります。また、管理者は、必要なアクセス許可があるグループにユーザーを追加できます。管理者がグループにアクセス許可を付与すると、そのグループ内のすべてのユーザーにこれらのアクセス許可が付与されます。
IAM ポリシーは、演算の実行方法を問わず、アクションのアクセス許可を定義します。例えば、`iam:GetRole` アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からロールの情報を取得できます。
### アイデンティティベースのポリシー
アイデンティティベースポリシーは、IAM user ユーザー、ユーザーのグループ、ロールなど、アイデンティティに添付できる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーを作成する方法については、『*IAM ユーザーガイド*』の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
アイデンティティベースのポリシーは、さらに*インラインポリシー*または*マネージドポリシー*に分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれています。管理ポリシーは、AWS アカウント 内の複数のユーザー、グループ、およびロールに添付できるスタンドアロンポリシーです。管理ポリシーには、AWS 管理ポリシーとカスタマー管理ポリシーが含まれます。マネージドポリシーまたはインラインポリシーのいずれかを選択する方法については、*「IAM ユーザーガイド」*の[「マネージドポリシーとインラインポリシーの比較」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline)を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーの例は、IAM *ロールの信頼ポリシー* および Amazon S3 *バケットポリシー*です。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。ポリシーが添付されているリソースの場合、ポリシーは、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件を定義します。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または AWS のサービスを含めることができます。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーで IAM の AWS 管理ポリシーを使用することはできません。
### アクセスコントロールリスト (ACL)
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするための許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
Amazon S3、AWS WAF、および Amazon VPC は、ACL をサポートするサービスの例です。ACL の詳細については、*「Amazon Simple Storage Service デベロッパーガイド」* の [「アクセスコントロールリスト (ACL) の概要」](https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html)を参照してください。
### その他のポリシータイプ
AWS では、別のあまり一般的ではないポリシータイプもサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の許可を設定できます。
+ **許可の境界** - 許可の境界は、ID ベースのポリシーが IAM エンティティ (IAM ユーザーまたはロール) に付与できる許可の上限を設定する高度な機能です。エンティティの許可の境界を設定できます。結果として得られる許可は、エンティティの アイデンティティベースポリシーとその許可の境界の共通部分です。`Principal`フィールドでユーザーまたはロールを指定するリソースベースのポリシーは、許可の境界では制限されません。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。許可の境界の詳細については、『*IAM ユーザーガイド*』の「[IAM エンティティの許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **[Service control policies (SCPs)]** (サービスコントロールポリシー SCP) – SCP は、AWS Organizations で組織や組織単位 (OU) に最大アクセス許可を指定する JSON ポリシーです。AWS Organizations は、お客様のビジネスが所有する複数の AWS アカウントをグループ化し、一元的に管理するサービスです。組織内のすべての機能を有効にすると、サービス制御ポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP はメンバーアカウントのエンティティ (各 AWS アカウント ルートユーザーなど) に対するアクセス許可を制限します。Organizations と SCP の詳細については、『*AWS Organizations ユーザーガイド*』の「[SCP の仕組み](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html)」を参照してください。
+ **セッションポリシー** - セッションポリシーは、ロールまたはフェデレーティッドユーザーのテンポラリセッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果として得られるセッションの許可は、ユーザーまたはロールのアイデンティティベースポリシーとセッションポリシーの共通部分です。また、リソースベースのポリシーから許可が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。詳細については、*「IAM ユーザーガイド」* の [「セッションポリシー」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成される許可を理解するのがさらに複雑になります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWSが決定する方法の詳細については、『*IAM ユーザーガイド*』の[ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)を参照してください。