Utilisation des stratégies basées sur l'identité (stratégies IAM) pour Amazon Route 53

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Cette rubrique fournit des exemples de stratégies basées sur l'identité qui montrent comment un administrateur de compte peut lier des stratégies d'autorisations à des identités IAM et accorder ainsi des autorisations pour effectuer des opérations sur les ressources Amazon Route 53.

Voici un exemple de stratégie d'autorisation. Le Sid, ou ID de l'instruction, est facultatif :

{
    "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": "*"
        }
    ]
}

La stratégie comprend deux déclarations :

Pour une liste des actions et l'ARN que vous spécifiez pour accorder ou refuser l'autorisation d'utiliser chaque action, consultez la section Autorisations d'API Amazon Route 53 : référence des actions, ressources et conditions.

Autorisations requises pour utiliser la console Amazon Route 53

Pour accorder un accès complet à la console Amazon Route 53, vous accordez les autorisations dans la stratégie d'autorisations suivante :

{
    "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"
        }
    ]
}

Voici pourquoi les autorisations sont obligatoires :

Exemples d'autorisations pour un propriétaire d'enregistrement de domaine

Avec les autorisations d'ensemble d'enregistrements de ressources, vous pouvez définir des autorisations granulaires qui limitent ce que l' AWS utilisateur peut mettre à jour ou modifier. Pour de plus amples informations, veuillez consulter Utilisation de conditions de politique IAM pour un contrôle d’accès précis.

Dans certains scénarios, un propriétaire de zone hébergée peut être responsable de la gestion globale de la zone hébergée, tandis qu'une autre personne de l'organisation est responsable d'un sous-ensemble de ces tâches. Un propriétaire de zone hébergée qui a activé la signature DNSSEC, par exemple, peut souhaiter créer une politique IAM qui inclut l'autorisation pour quelqu'un d'autre d'ajouter et de supprimer des enregistrements d'ensembles de ressources (RRs) dans la zone hébergée, entre autres tâches. Les autorisations spécifiques qu'un propriétaire de zone hébergée choisit d'activer pour un propriétaire d'enregistrement ou d'autres personnes dépendent de la stratégie de leur organisation.

Voici un exemple de politique IAM qui permet au propriétaire d'un enregistrement d'apporter des modifications aux RRs politiques de trafic et aux contrôles de santé. Un propriétaire d'enregistrement doté de cette stratégie n'est pas autorisé à effectuer des opérations au niveau de la zone, telles que la création ou la suppression d'une zone, l'activation ou la désactivation de la journalisation des requêtes, la création ou la suppression d'un jeu de délégations réutilisable ou la modification des paramètres 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": [
        "*"
      ]
}

Autorisations de clé gérées par le client Route 53 requises pour la signature DNSSEC

Lorsque vous activez la signature DNSSEC pour Route 53, Route 53 crée une clé de signature clé (KSK) basée sur une clé gérée par le client dans (). AWS Key Management Service AWS KMS Vous pouvez utiliser une clé gérée par le client existante qui prend en charge la signature DNSSEC ou en créer une nouvelle. Route 53 doit être autorisé à accéder à votre clé gérée par le client afin de pouvoir créer la clé KSK pour vous.

Pour activer Route 53 pour accéder à votre clé gérée par le client, assurez-vous que votre stratégie de clé gérée par le client contient les instructions suivantes :

{
            "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
                }
            }
        }

Le problème de député confus est un problème de sécurité dans lequel une entité sans autorisation pour une action peut contraindre une entité plus privilégiée à le faire. Pour vous AWS KMS en protéger, vous pouvez éventuellement limiter les autorisations accordées à un service sur une ressource dans le cadre d'une politique basée sur les ressources en fournissant une combinaison de aws:SourceArn conditions (aws:SourceAccountles deux ou une seule). aws:SourceAccountest l'identifiant de AWS compte du propriétaire d'une zone hébergée. aws:SourceArnest l'ARN d'une zone hébergée.

Voici deux exemples d'autorisations que vous pouvez ajouter :

{
    "Sid": "Allow Route 53 DNSSEC Service",
    …
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:SourceAccount": "111122223333"
        },
        "ArnEquals": {
            "aws:SourceArn": "arn:aws:route53:::hostedzone/HOSTED_ZONE_ID"
        }
    }
},

- Ou -

{
    "Sid": "Allow Route 53 DNSSEC Service",
    …
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:SourceAccount": ["1111-2222-3333","4444-5555-6666"]
        },
        "ArnLike": {
            "aws:SourceArn": "arn:aws:route53:::hostedzone/*"
        }
    }
},

Pour de plus amples informations, veuillez consulter Le problème du député confus dans le Guide de l'utilisateur IAM.

Exemples de politiques gérées par le client

Vous pouvez créer vos propres stratégies IAM personnalisées pour accorder des autorisations pour des actions Route 53. Vous pouvez attacher ces politiques personnalisées aux groupes IAM qui nécessitent les autorisations spécifiées. Ces politiques fonctionnent lorsque vous utilisez l'API Route 53 AWS SDKs, la ou la AWS CLI. Les exemples suivants présentent des autorisations pour plusieurs cas d'utilisation courants. Pour accéder à la stratégie qui accorde à un utilisateur l'accès complet à Route 53, consultez Autorisations requises pour utiliser la console Amazon Route 53.

Exemple 1 : Autoriser l'accès en lecture à toutes les zones hébergées

La stratégie d'autorisation suivante accorde à l'utilisateur l'autorisation de répertorier toutes les zones hébergées et d'afficher tous les enregistrements d'une zone hébergée.

{
    "Version": "2012-10-17",
    "Statement":[
        {
            "Effect":"Allow",
            "Action":[
                "route53:GetHostedZone", 
                "route53:ListResourceRecordSets"
            ],
            "Resource":"*"
        },
        {
            "Effect":"Allow",
            "Action":["route53:ListHostedZones"],
            "Resource":"*"
        }
    ]
}

Exemple 2 : Autoriser la création et la suppression de zones hébergées

La stratégie d'autorisation suivante accorde aux utilisateurs l'autorisation de créer et de supprimer des zones hébergées, et de suivre l'avancement des modifications.

{
    "Version": "2012-10-17",
    "Statement":[
        {
            "Effect":"Allow",
            "Action":["route53:CreateHostedZone"],
            "Resource":"*"
        },
        {
            "Effect":"Allow",
            "Action":["route53:DeleteHostedZone"],
            "Resource":"*"
        },
        {
            "Effect":"Allow",
            "Action":["route53:GetChange"],
            "Resource":"*"
        }
    ]
}

Exemple 3 : Autoriser l'accès complet à tous les domaines (zones hébergées publiques uniquement)

La stratégie d'autorisation suivante accorde aux utilisateurs l'autorisation d'exécuter toutes les actions sur les enregistrements de domaines, y compris l'enregistrement de domaines et la création de zones hébergées.

{
    "Version": "2012-10-17",
    "Statement":[
        {
            "Effect":"Allow",
            "Action":[
                "route53domains:*",
                "route53:CreateHostedZone"
            ],
            "Resource":"*"
        }
    ]
}

Lorsque vous enregistrez un domaine, une zone hébergée est créée simultanément. Une stratégie qui inclut l'autorisation d'enregistrer des domaines doit donc également inclure l'autorisation de créer des zones hébergées. (Pour l'enregistrement de domaine, Route 53 ne prend pas en charge l'octroi d'autorisations à des ressources individuelles.)

Pour plus d'informations sur les autorisations requises pour utiliser des zones hébergées privées, consultez Autorisations requises pour utiliser la console Amazon Route 53.

Exemple 4 : Autoriser la création de points de terminaison Route 53 Resolver entrants et sortants

La stratégie d'autorisations suivante permet aux utilisateurs d'utiliser la console Route 53 pour créer des points de terminaison Resolver entrants et sortants.

Certaines de ces autorisations sont nécessaires uniquement pour créer des points de terminaison dans la console. Vous pouvez omettre ces autorisations si vous souhaitez accorder des autorisations uniquement pour créer des points de terminaison entrants et sortants par programmation :

{
    "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": "*"
        }
    ]
}