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.
Prévention du cas de figure de l’adjoint désorienté entre services
Le problème de l’adjoint confus est un problème de sécurité dans lequel une entité qui n’a pas l’autorisation d’effectuer une action peut contraindre une entité plus privilégiée à effectuer cette action. En AWS, l'usurpation d'identité interservices peut entraîner la confusion des adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le service appelant) appelle un autre service (le service appelé). Le service appelant peut être manipulé pour utiliser ses autorisations afin d'agir sur les ressources d'un autre client de sorte qu'il n'y aurait pas accès autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services avec des principaux de service qui ont eu accès aux ressources de votre compte.
Pour limiter les autorisations qui AWS IoT confèrent un autre service à la ressource, nous vous recommandons d'utiliser les clés contextuelles de condition aws:SourceAccount
globale aws:SourceArn
et les clés contextuelles dans les politiques de ressources. Si vous utilisez les deux clés de contexte de condition globale, la valeur aws:SourceAccount
et le compte de la valeur aws:SourceArn
doit utiliser le même ID de compte lorsqu’il est utilisé dans la même déclaration de stratégie.
Le moyen le plus efficace de se protéger contre le problème de confusion lié aux adjoints consiste à utiliser la clé de contexte de condition aws:SourceArn
globale avec le nom complet de la ressource Amazon (ARN). En AWS IoT effet, vous aws:SourceArn
devez respecter le format : arn:
pour les autorisations spécifiques aux ressources ouaws
:iot:region
:account-id
:resource-type/resource-id
arn:
. L'identifiant de ressource peut être le nom ou l'ID de la ressource autorisée, ou une déclaration générique de la ressource autorisée. IDs Assurez-vous que le aws
:iot:region
:account-id
:*
region
correspond à votre AWS IoT région et au account-id
correspond à l'identifiant de votre compte client.
L'exemple suivant montre comment éviter le problème de confusion des adjoints en utilisant les clés de contexte aws:SourceArn
et de condition aws:SourceAccount
globale dans la politique de confiance dans les AWS IoT rôles. Pour obtenir plus d’exemples, consultez Exemples détaillés de prévention de la confusion chez les adjoints.
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":"iot.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"
123456789012
" }, "ArnLike":{ "aws:SourceArn":"arn:aws
:iot:us-east-1
:123456789012
:*
" } } } ] }
Note
Si vous recevez des erreurs de refus d'accès, cela peut être dû au fait que l'intégration du service avec AWS
Security Token Service (STS) ne prend pas en charge les clés de aws:SourceAccount
contexte aws:SourceArn
et.
Exemples détaillés de prévention de la confusion chez les adjoints
Cette section fournit des exemples détaillés de la manière de prévenir le problème de confusion des adjoints en utilisant les clés de contexte aws:SourceArn et les clés de contexte de condition aws:SourceAccount globale de la politique de confiance dans les AWS IoT rôles.
Mise en service de flotte
Vous pouvez configurer le provisionnement du parc à l'aide d'une ressource de modèle de provisionnement. Lorsqu'un modèle de provisionnement fait référence à un rôle de provisionnement, la politique de confiance de ce rôle peut inclure les clés de aws:SourceAccount
condition aws:SourceArn
et. Ces clés limitent les ressources pour lesquelles la configuration peut invoquer la sts:AssumeRole
demande.
Le rôle associé à la politique de confiance suivante ne peut être assumé que par le principal IoT (iot.amazonaws.com
) pour le modèle de provisionnement spécifié dans leSourceArn
.
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":"iot.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"
123456789012
" }, "ArnLike":{ "aws:SourceArn":"arn:aws
:iot:us-east-1
:123456789012
:provisioningtemplate/example_template
" } } } ] }
JITP
Dans just-in-time provisioning (JITP), vous pouvez soit utiliser le modèle de provisionnement en tant que ressource distincte de l'autorité de certification, soit définir le corps du modèle et le rôle dans le cadre de la configuration du certificat de l'autorité de certification. La valeur de la politique de confiance aws:SourceArn
in the AWS IoT role dépend de la manière dont vous définissez le modèle de provisionnement.
Si vous définissez votre modèle de provisionnement en tant que ressource distincte, la valeur de aws:SourceArn
peut être"arn:aws:iot:
. Vous pouvez utiliser le même exemple de politique dansMise en service de flotte.region
:account-id
:provisioningtemplate/example_template
"
Si vous définissez votre modèle de provisionnement dans une ressource de certificat CA, la valeur de aws:SourceArn
peut être "arn:aws:iot:
ouregion
:account-id
:cacert/cert_id
""arn:aws:iot:
. Vous pouvez utiliser un caractère générique lorsque l'identifiant de la ressource, tel que l'ID d'un certificat CA, est inconnu au moment de la création.region
:account-id
:cacert/*
"
Le rôle associé à la politique de confiance suivante ne peut être assumé que par le principal IoT (iot.amazonaws.com
) pour le certificat CA spécifié dans leSourceArn
.
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":"iot.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"
123456789012
" }, "ArnLike":{ "aws:SourceArn":"arn:aws
:iot:us-east-1
:123456789012
:cacert/8ecde6884f3d87b1125ba31ac3fcb13d7016de7f57cc904fe1cb97c6ae98196e
" } } } ] }
Lorsque vous créez un certificat CA, vous pouvez faire référence à un rôle de provisionnement dans la configuration d'enregistrement. La politique de confiance du rôle de provisionnement peut être utilisée aws:SourceArn
pour limiter les ressources pour lesquelles le rôle peut être assumé. Cependant, lors de l'egisterCACertificateappel R initial pour enregistrer le certificat CA, vous n'auriez ARN pas le certificat CA à spécifier dans la aws:SourceArn
condition.
Pour contourner ce problème, c'est-à-dire pour spécifier la politique de confiance du rôle d'approvisionnement pour le certificat CA spécifique enregistré auprès de celui-ci AWS IoT Core, vous pouvez effectuer les opérations suivantes :
-
Tout d'abord, appelez R egisterCACertificate sans fournir le
RegistrationConfig
paramètre. -
Une fois le certificat CA enregistré AWS IoT Core, appelez-nous à ce pdateCACertificate sujet.
Dans l'pdateCACertificate appel U, fournissez un
RegistrationConfig
qui inclut la politique de confiance du rôle d'approvisionnement,aws:SourceArn
définie sur ARN le certificat CA nouvellement enregistré.
Fournisseur d'informations d'identification
Pour le fournisseur AWS IoT Core
d'informations d'identification, utilisez le même Compte AWS que celui que vous utilisez pour créer l'alias de rôle dans aws:SourceAccount
et spécifiez une instruction qui correspond à la ressource ARN du type de ressource rolealias dans. aws:SourceArn
Lorsque vous créez un IAM rôle à utiliser avec le fournisseur AWS IoT Core d'informations d'identification, vous devez inclure dans la aws:SourceArn
condition tous les alias ARNs de rôle susceptibles de devoir assumer le rôle, autorisant ainsi la demande interservices. sts:AssumeRole
Le rôle soumis à la politique de confiance suivante ne peut être assumé que par le principal du fournisseur d' AWS IoT Core informations d'identification (credentials.iot.amazonaws.com
) pour les informations roleAlias spécifiées dans leSourceArn
. Si un principal tente de récupérer les informations d'identification pour un alias de rôle autre que celui spécifié dans la aws:SourceArn
condition, la demande sera refusée, même si cet autre alias de rôle fait référence au même IAM rôle.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "credentials.iot.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "
123456789012
" }, "ArnLike": { "aws:SourceArn": "arn:aws
:iot:us-east-1
:123456789012
:rolealias/example_rolealias
" } } } ] }