翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Route 53 での ID ベースのポリシー (IAM ポリシー) の使用
このトピックでは、アカウント管理者が IAM アイデンティティに許可ポリシーをアタッチし、そうすることによって Amazon Route 53 リソースで操作を実行する許可を付与する方法を示す、アイデンティティベースのポリシーの例を提供します。
**重要**
初めに、Route 53 リソースへのアクセスを管理するための基本概念とオプションについて説明する概要トピックをお読みになることをお勧めします。詳細については、「[Amazon Route 53 リソースに対するアクセス許可の管理の概要](access-control-overview.md)」を参照してください。
**注記**
アクセスを許可する場合、ホストゾーンと Amazon VPC は同じパーティションに属している必要があります。パーティションは のグループです AWS リージョン。各 AWS アカウント は 1 つのパーティションにスコープされます。
サポートされているパーティションは以下のとおりです。
`aws` - AWS リージョン
`aws-cn` - 中国リージョン
`aws-us-gov` - AWS GovCloud (US) Region
詳細については、「*AWS 一般参照*」の「[アクセス管理](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」と「[Amazon Route 53 エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/r53.html)」を参照してください。
**Topics**
+ [Amazon Route 53 コンソールを使用するために必要なアクセス許可](#console-required-permissions)
+ [ドメインレコード所有者のアクセス許可の例](#example-permissions-record-owner)
+ [DNSSEC 署名に必要な Route 53 カスタマー管理キーアクセス許可](#KMS-key-policy-for-DNSSEC)
+ [カスタマーマネージドポリシーの例](#access-policy-examples-for-sdk-cli)
以下の例に示しているのは、アクセス許可ポリシーです。`Sid` (ステートメント ID) はオプションです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid" : "AllowPublicHostedZonePermissions",
"Effect": "Allow",
"Action": [
"route53:CreateHostedZone",
"route53:UpdateHostedZoneComment",
"route53:GetHostedZone",
"route53:ListHostedZones",
"route53:DeleteHostedZone",
"route53:ChangeResourceRecordSets",
"route53:ListResourceRecordSets",
"route53:GetHostedZoneCount",
"route53:ListHostedZonesByName"
],
"Resource": "*"
},
{
"Sid" : "AllowHealthCheckPermissions",
"Effect": "Allow",
"Action": [
"route53:CreateHealthCheck",
"route53:UpdateHealthCheck",
"route53:GetHealthCheck",
"route53:ListHealthChecks",
"route53:DeleteHealthCheck",
"route53:GetCheckerIpRanges",
"route53:GetHealthCheckCount",
"route53:GetHealthCheckStatus",
"route53:GetHealthCheckLastFailureReason"
],
"Resource": "*"
}
]
}
```
------
ポリシーには、2 つのステートメントが含まれています。
+ 最初のステートメントでは、パブリックホストゾーンとそのレコードの作成と管理に必要なアクションに対する権限が付与されます。Amazon リソースネーム (ARN) のワイルドカード文字 (\$1) は、現在の AWS アカウントが所有するすべてのホストゾーンへのアクセスを許可します。
+ 2 番目のステートメントでは、ヘルスチェックの作成と管理に必要なすべてのアクションに対する権限が付与されます。
各アクションを使用するアクセス許可を付与または拒否するために指定するアクションおよび ARN のリストについては、「[Amazon Route 53 API のアクセス許可: アクション、リソース、条件のリファレンス](r53-api-permissions-ref.md)」を参照してください。
## Amazon Route 53 コンソールを使用するために必要なアクセス許可
Amazon Route 53 コンソールへのフルアクセスを許可するには、次のアクセス許可ポリシーでアクセス許可を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"route53:*",
"route53domains:*",
"tag:*",
"ssm:GetParametersByPath",
"cloudfront:ListDistributions",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticbeanstalk:DescribeEnvironments",
"s3:ListAllMyBuckets",
"s3:GetBucketLocation",
"s3:GetBucketWebsite",
"ec2:DescribeRegions",
"ec2:DescribeVpcs",
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:ModifyNetworkInterfaceAttribute",
"sns:ListTopics",
"sns:ListSubscriptionsByTopic",
"sns:CreateTopic",
"kms:ListAliases",
"kms:DescribeKey",
"kms:CreateKey",
"kms:CreateAlias",
"kms:Sign",
"cloudwatch:DescribeAlarms",
"cloudwatch:PutMetricAlarm",
"cloudwatch:DeleteAlarms",
"cloudwatch:GetMetricStatistics"
],
"Resource":"*"
},
{
"Effect": "Allow",
"Action": "apigateway:GET",
"Resource": "arn:aws:apigateway:*::/domainnames"
}
]
}
```
------
アクセス許可が必要な理由は次のとおりです。
**`route53:*`**
以下を*除く*すべての Route 53 アクションを実行できます。
+ [**エイリアス先**] の値が CloudFront ディストリビューション、Elastic Load Balancing ロードバランサー、Elastic Beanstalk 環境、または Amazon S3 バケットであるエイリアスレコードを作成および更新する。(これらの権限があると、[**Alias Target**] (エイリアス先) の値が同じホストゾーン内の別のレコードであるエイリアスレコードを作成できます)
+ プライベートホストゾーンを操作する。
+ ドメインを操作する。
+ CloudWatch アラームを作成、削除、および表示する。
+ Route 53 コンソールで CloudWatch メトリクスをレンダリングします。
**`route53domains:*`**
ドメインの操作を許可します。
`route53` のアクションを個別にリストする場合は、`route53:CreateHostedZone` を含めてドメインを操作する必要があります。ドメインを登録すると同時にホストゾーンも作成されるため、ドメインを登録する権限を含むポリシーにはホストゾーンを作成する権限も必要です
(ドメイン登録について、Route 53 は個別のリソースへのアクセス許可の付与または拒否をサポートしていません)。
**`route53resolver:*`**
Route 53 VPC Resolver を操作できます。
**`ssm:GetParametersByPath`**
新しいエイリアスレコード、プライベートホストゾーン、ヘルスチェックを作成するときに、公開されているリージョンを取得できます。
**`cloudfront:ListDistributions`**
**[Alias Target]** (エイリアス先) の値が CloudFront ディストリビューションとなるエイリアスレコードを作成および更新できます。
Route 53 コンソールを使用していない場合、これらのアクセス許可は必要ありません。Route 53 は、ディストリビューションのリストを取得してコンソールに表示する場合のみ、これを使用します。
**`elasticloadbalancing:DescribeLoadBalancers`**
[**Alias Target(エイリアス先)**] の値が ELB ロードバランサーとなるエイリアスレコードを作成および更新できます。
Route 53 コンソールを使用していない場合、これらのアクセス許可は必要ありません。Route 53 は、ロードバランサーのリストを取得してコンソールに表示する場合のみ、これを使用します。
**`elasticbeanstalk:DescribeEnvironments`**
**[Alias Target]** (エイリアス先) の値が Elastic Beanstalk 環境となるエイリアスレコードを作成および更新できます。
Route 53 コンソールを使用していない場合、これらのアクセス許可は必要ありません。Route 53 は、環境のリストを取得してコンソールに表示する場合のみ、これを使用します。
**`s3:ListAllMyBuckets`、`s3:GetBucketLocation`、および `s3:GetBucketWebsite`**
**[Alias Target]** (エイリアス先) の値が Amazon S3 バケットとなるエイリアスレコードを作成および更新できます。(Amazon S3 バケットのエイリアスは、バケットがウェブサイトエンドポイントとして設定されている場合のみ作成できます。`s3:GetBucketWebsite` は必要な設定情報を取得します)。
Route 53 コンソールを使用していない場合、これらのアクセス許可は必要ありません。Route 53 は、バケットのリストを取得してコンソールに表示する場合のみ、これを使用します。
**`ec2:DescribeVpcs`: 、および `ec2:DescribeRegions`**
プライベートホストゾーンの操作を許可します。
**すべてのリストされている `ec2` アクセス許可**
Route 53 VPC Resolver を操作できます。
**`sns:ListTopics`, `sns:ListSubscriptionsByTopic`, `sns:CreateTopic`, `cloudwatch:DescribeAlarms`, `cloudwatch:PutMetricAlarm`, `cloudwatch:DeleteAlarms`**
CloudWatch アラームを作成、削除、および表示できます。
**`cloudwatch:GetMetricStatistics`**
CloudWatch メトリクスヘルスチェックを作成することができます。
Route 53 コンソールを使用していない場合、これらのアクセス許可は必要ありません。Route 53 は、統計を取得してコンソールに表示する場合のみ、これを使用します。
**`apigateway:GET`**
[**エイリアス先**] の値が Amazon API Gateway の API であるエイリアスレコードを作成および更新できます。
Route 53 コンソールを使用していない場合、このアクセス許可は必要ありません。Route 53 は、API のリストを取得してコンソールに表示する場合のみ、これを使用します。
**`kms:*`**
を使用して DNSSEC 署名 AWS KMS を有効にできます。
## ドメインレコード所有者のアクセス許可の例
リソースレコードセットのアクセス許可を使用すると、 AWS ユーザーが更新または変更できる内容を制限する詳細なアクセス許可を設定できます。詳細については、「[詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions-route53.md)」を参照してください。
場合によっては、ホストゾーンの所有者がホストゾーンの全体的な管理を担当し、組織内の別のユーザーがそれらのタスクのサブセットを担当することがあります。例えば、DNSSEC 署名を有効にしたホストゾーンの所有者は、他のユーザーがホストゾーンの Resource Set Records (RR) を追加および削除するためのアクセス許可などを含む IAM ポリシーを作成したい場合があります。ホストゾーン所有者がレコード所有者または他のユーザーに対して有効にする特定のアクセス許可は、組織のポリシーによって異なります。
以下は、レコード所有者に RR、トラフィックポリシー、ヘルスチェックの変更を許可する IAM ポリシーの例です。このポリシーを持つレコード所有者は、ゾーンの作成と削除、クエリログの有効化または無効化、再利用可能な委任セットの作成と削除、DNSSEC 設定の変更など、ゾーンレベルの操作を実行できません。
```
{
"Sid": "Do not allow zone-level modification ",
"Effect": "Allow",
"Action": [
"route53:ChangeResourceRecordSets",
"route53:CreateTrafficPolicy",
"route53:DeleteTrafficPolicy",
"route53:CreateTrafficPolicyInstance",
"route53:CreateTrafficPolicyVersion",
"route53:UpdateTrafficPolicyInstance",
"route53:UpdateTrafficPolicyComment",
"route53:DeleteTrafficPolicyInstance",
"route53:CreateHealthCheck",
"route53:UpdateHealthCheck",
"route53:DeleteHealthCheck",
"route53:List*",
"route53:Get*"
],
"Resource": [
"*"
]
}
```
## DNSSEC 署名に必要な Route 53 カスタマー管理キーアクセス許可
Route 53 の DNSSEC 署名を有効にすると、Route 53 は AWS Key Management Service () のカスタマーマネージドキーに基づいてキー署名キー (KSK) を作成しますAWS KMS。DNSSEC 署名をサポートしている既存のカスタマー管理キーを使用することも、新しいカスタマー管理キーを作成することもできます。Route 53 は、KSK を作成できるようにカスタマー管理キーにアクセスするアクセス許可を持っている必要があります。
Route 53 がカスタマー管理キーにアクセスできるようにするには、カスタマー管理キーポリシーに次のステートメントが含まれていることを確認します。
```
{
"Sid": "Allow Route 53 DNSSEC Service",
"Effect": "Allow",
"Principal": {
"Service": "dnssec-route53.amazonaws.com"
},
"Action": ["kms:DescribeKey",
"kms:GetPublicKey",
"kms:Sign"],
"Resource": "*"
},
{
"Sid": "Allow Route 53 DNSSEC to CreateGrant",
"Effect": "Allow",
"Principal": {
"Service": "dnssec-route53.amazonaws.com"
},
"Action": ["kms:CreateGrant"],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": true
}
}
}
```
混乱した使節の問題は、アクションを実行するためのアクセス許可を持たないエンティティが、自分より特権があるエンティティにアクションの実行を強制できてしまう状況が発生するセキュリティ上の問題です。 AWS KMS から を保護するために、オプションで `aws:SourceAccount`条件と `aws:SourceArn`条件 (両方または 1 つ) の組み合わせを指定することで、サービスが持つアクセス許可をリソースベースのポリシーのリソースに制限できます。 `aws:SourceAccount`はホストゾーンの所有者の AWS アカウント ID です。 はホストゾーンの ARN `aws:SourceArn`です。
以下の内容は追加できる許可の例を 2 つ示したものです:
```
{
"Sid": "Allow Route 53 DNSSEC Service",
…
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:route53:::hostedzone/HOSTED_ZONE_ID"
}
}
},
```
- または -
```
{
"Sid": "Allow Route 53 DNSSEC Service",
…
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": ["1111-2222-3333","4444-5555-6666"]
},
"ArnLike": {
"aws:SourceArn": "arn:aws:route53:::hostedzone/*"
}
}
},
```
詳細については、*IAM ユーザーガイド* の [混乱した代理問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) を参照してください。
## カスタマーマネージドポリシーの例
独自のカスタム IAM ポリシーを作成して、Route 53 アクションにアクセス許可を付与することもできます。これらのカスタムポリシーは、指定された許可を必要とする IAM グループにアタッチできます。これらのポリシーは、Route 53 API、 AWS SDKs、または AWS CLI を使用している場合に機能します。次の例では、いくつかの一般的ユースケースのアクセス許可を示します。Route 53 へのフルアクセスをユーザーに許可するポリシーについては、「[Amazon Route 53 コンソールを使用するために必要なアクセス許可](#console-required-permissions)」を参照してください。
**Topics**
+ [例 1: すべてのホストゾーンへの読み取りアクセスを許可する](#access-policy-example-allow-read-hosted-zones)
+ [例 2: ホストゾーンの作成と削除を許可する](#access-policy-example-allow-create-delete-hosted-zones)
+ [例 3: すべてのドメインに対するフルアクセスを許可する (パブリックホストゾーンのみ)](#access-policy-example-allow-full-domain-access)
+ [例 4: インバウンドおよびアウトバウンドの Route 53 VPC Resolver エンドポイントの作成を許可する](#access-policy-example-create-resolver-endpoints)
### 例 1: すべてのホストゾーンへの読み取りアクセスを許可する
以下の権限ポリシーは、すべてのホストゾーンをリストし、ホストゾーン内のすべてのレコードを表示するユーザー権限を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"route53:GetHostedZone",
"route53:ListResourceRecordSets"
],
"Resource":"*"
},
{
"Effect":"Allow",
"Action":["route53:ListHostedZones"],
"Resource":"*"
}
]
}
```
------
### 例 2: ホストゾーンの作成と削除を許可する
次の権限ポリシーは、ホストゾーンの作成と削除、および変更の進行状況の追跡をユーザーに許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":["route53:CreateHostedZone"],
"Resource":"*"
},
{
"Effect":"Allow",
"Action":["route53:DeleteHostedZone"],
"Resource":"*"
},
{
"Effect":"Allow",
"Action":["route53:GetChange"],
"Resource":"*"
}
]
}
```
------
### 例 3: すべてのドメインに対するフルアクセスを許可する (パブリックホストゾーンのみ)
次の権限ポリシーは、ドメインの登録権限やホストゾーンの作成権限など、ドメイン登録に関するすべてのアクションの実行をユーザーに許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"route53domains:*",
"route53:CreateHostedZone"
],
"Resource":"*"
}
]
}
```
------
ドメインを登録すると同時にホストゾーンも作成されるため、ドメインを登録する権限を含むポリシーにはホストゾーンを作成する権限も必要です (ドメイン登録について、Route 53 は個別のリソースへのアクセス許可の付与をサポートしていません)。
プライベートホストゾーンを操作するために必要なアクセス許可については、「[Amazon Route 53 コンソールを使用するために必要なアクセス許可](#console-required-permissions)」を参照してください。
### 例 4: インバウンドおよびアウトバウンドの Route 53 VPC Resolver エンドポイントの作成を許可する
次のアクセス許可ポリシーは、ユーザーが Route 53 コンソールを使用して Resolver のインバウンドおよびアウトバウンドエンドポイントを作成することを許可します。
これらのアクセス許可の一部は、コンソールでエンドポイントを作成するためにのみ必要です。インバウンドおよびアウトバウンドエンドポイントのみをプログラムで作成するアクセス許可を付与する場合は、これらのアクセス許可を省略できます。
+ `route53resolver:ListResolverEndpoints` では、インバウンドまたはアウトバウンドエンドポイントのリストが表示されるため、ユーザーはエンドポイントが作成されたことを確認できます。
+ `DescribeAvailabilityZones` は、アベイラビリティーゾーンのリストを表示するために必要です。
+ `DescribeVpcs` は VPC のリストを表示するために必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"route53resolver:CreateResolverEndpoint",
"route53resolver:ListResolverEndpoints",
"ec2:CreateNetworkInterface",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
}
]
}
```
------