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. # Sécurité dans AWS Device Farm La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez d'un centre de données et d'une architecture réseau conçus pour répondre aux exigences des entreprises les plus sensibles en matière de sécurité. La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit ceci comme la sécurité *du* cloud et la sécurité *dans* le cloud : + **Sécurité du cloud** : AWS est chargée de protéger l'infrastructure qui exécute les AWS services dans le AWS cloud. AWS vous fournit également des services que vous pouvez utiliser en toute sécurité. Des auditeurs tiers testent et vérifient régulièrement l'efficacité de notre sécurité dans le cadre des programmes de [AWS conformité Programmes](https://aws.amazon.com/compliance/programs/) de de conformité. Pour en savoir plus sur les programmes de conformité applicables à AWS Device Farm, consultez la section [Services AWS concernés par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/) . + **Sécurité dans le cloud** : votre responsabilité est déterminée par le service AWS que vous utilisez. Vous êtes également responsable d’autres facteurs, y compris de la sensibilité de vos données, des exigences de votre entreprise, ainsi que de la législation et de la réglementation applicables. Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de l'utilisation de Device Farm. Les rubriques suivantes expliquent comment configurer Device Farm pour répondre à vos objectifs de sécurité et de conformité. Vous apprendrez également à utiliser d'autres services AWS qui vous aident à surveiller et à sécuriser les ressources de votre Device Farm. **Topics** + [ # Gestion des identités et des accès dans AWS Device Farm ](security-iam.md) + [ # Validation de conformité pour AWS Device Farm ](ATP-compliance.md) + [ # Protection des données dans AWS Device Farm ](data-protection.md) + [ # Résilience dans AWS Device Farm ](disaster-recovery-resiliency.md) + [ # Sécurité de l'infrastructure dans AWS Device Farm ](infrastructure-security.md) + [ # Analyse et gestion des vulnérabilités de configuration dans Device Farm ](security-vulnerability-analysis-and-management.md) + [ # Réponse aux incidents dans Device Farm ](security-incident-response.md) + [ # Journalisation et surveillance dans Device Farm ](security-logging-monitoring.md) + [ # Bonnes pratiques en matière de sécurité pour Device Farm ](security-best-practices.md) # Gestion des identités et des accès dans AWS Device Farm ## Public ciblé La façon dont vous utilisez Gestion des identités et des accès AWS (IAM) varie en fonction de votre rôle : + **Utilisateur du service** : demandez des autorisations à votre administrateur si vous ne pouvez pas accéder aux fonctionnalités (voir [Résolution des problèmes d'identité et d'accès à AWS Device Farm](security_iam_troubleshoot.md)) + **Administrateur du service** : déterminez l’accès des utilisateurs et soumettez les demandes d’autorisation (voir [Comment AWS Device Farm fonctionne avec IAM](security_iam_service-with-iam.md)) + **Administrateur IAM** : rédigez des politiques pour gérer l’accès (voir [Exemples de politiques basées sur l'identité d'AWS Device Farm](security_iam_id-based-policy-examples.md)) ## Authentification par des identités L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être authentifié en tant qu'utilisateur IAM ou en assumant un rôle IAM. Utilisateur racine d'un compte AWS Vous pouvez vous connecter en tant qu'identité fédérée à l'aide d'informations d'identification provenant d'une source d'identité telle que AWS IAM Identity Center (IAM Identity Center), d'une authentification unique ou d'informations d'identification. Google/Facebook Pour plus d’informations sur la connexion, consultez [Connexion à votre Compte AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l’utilisateur Connexion à AWS *. Pour l'accès par programmation, AWS fournit un SDK et une CLI pour signer les demandes de manière cryptographique. Pour plus d’informations, consultez [Signature AWS Version 4 pour les demandes d’API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) dans le *Guide de l’utilisateur IAM*. ### Compte AWS utilisateur root Lorsque vous créez un Compte AWS, vous commencez par une seule identité de connexion appelée *utilisateur Compte AWS root* qui dispose d'un accès complet à toutes Services AWS les ressources. Il est vivement déconseillé d’utiliser l’utilisateur racine pour vos tâches quotidiennes. Pour les tâches qui requièrent des informations d’identification de l’utilisateur racine, consultez [Tâches qui requièrent les informations d’identification de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dans le *Guide de l’utilisateur IAM*. ### Utilisateurs et groupes IAM Un *[utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* est une identité qui dispose d’autorisations spécifiques pour une seule personne ou application. Nous vous recommandons d’utiliser ces informations d’identification temporaires au lieu des utilisateurs IAM avec des informations d’identification à long terme. Pour plus d'informations, voir [Exiger des utilisateurs humains qu'ils utilisent la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *guide de l'utilisateur IAM*. [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spécifient une collection d’utilisateurs IAM et permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Pour plus d’informations, consultez [Cas d’utilisation pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) dans le *Guide de l’utilisateur IAM*. ### Rôles IAM Un *[rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité dotée d’autorisations spécifiques qui fournit des informations d’identification temporaires. Vous pouvez assumer un rôle en [passant d'un rôle d'utilisateur à un rôle IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou en appelant une opération d' AWS API AWS CLI ou d'API. Pour plus d’informations, consultez [Méthodes pour endosser un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) dans le *Guide de l’utilisateur IAM*. Les rôles IAM sont utiles pour l’accès des utilisateurs fédérés, les autorisations temporaires des utilisateurs IAM, les accès intercompte, les accès entre services et les applications exécutées sur Amazon EC2. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*. # Comment AWS Device Farm fonctionne avec IAM Avant d'utiliser IAM pour gérer l'accès à Device Farm, vous devez savoir quelles fonctionnalités IAM peuvent être utilisées avec Device Farm. Pour obtenir une vue d'ensemble de la manière dont Device Farm et les autres AWS services fonctionnent avec IAM, consultez la section [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le guide de l'utilisateur *IAM*. **Topics** + [ ## Politiques basées sur l'identité de Device Farm ](#security_iam_service-with-iam-id-based-policies) + [ ## Politiques basées sur les ressources de Device Farm ](#security_iam_service-with-iam-resource-based-policies) + [ ## Listes de contrôle d'accès (ACL) ](#security_iam_service-with-iam-acls) + [ ## Autorisation basée sur les tags Device Farm ](#security_iam_service-with-iam-tags) + [ ## Rôles IAM de Device Farm ](#security_iam_service-with-iam-roles) ## Politiques basées sur l'identité de Device Farm Avec les stratégies IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées et les conditions dans lesquelles les actions sont autorisées ou refusées. Device Farm prend en charge des actions, des ressources et des clés de condition spécifiques. Pour en savoir plus sur tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*. ### Actions Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**. L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées. Les actions de politique dans Device Farm utilisent le préfixe suivant avant l'action :`devicefarm:`. Par exemple, pour autoriser quelqu'un à démarrer des sessions Selenium avec le fonctionnement de l'`CreateTestGridUrl`API de test du navigateur de bureau Device Farm, vous devez inclure l'`devicefarm:CreateTestGridUrl`action dans la politique. Les déclarations de politique doivent inclure un élément `Action` ou `NotAction`. Device Farm définit son propre ensemble d'actions décrivant les tâches que vous pouvez effectuer avec ce service. Pour spécifier plusieurs actions dans une seule déclaration, séparez-les par des virgules comme suit : ``` "Action": [ "devicefarm:action1", "devicefarm:action2" ``` Vous pouvez aussi spécifier plusieurs actions à l’aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions qui commencent par le mot `List`, incluez l’action suivante : ``` "Action": "devicefarm:List*" ``` Pour consulter la liste des actions Device Farm, reportez-vous à la section [Actions définies par AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions) dans le *IAM Service Authorization Reference*. ### Ressources Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**. L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources. ``` "Resource": "*" ``` La ressource d'instance Amazon EC2 possède l'ARN suivant : ``` arn:${Partition}:ec2:${Region}:${Account}:instance/${InstanceId} ``` Pour plus d'informations sur le format de ARNs, consultez [Amazon Resource Names (ARNs) et AWS Service Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). Par exemple, pour spécifier l’instance `i-1234567890abcdef0` dans votre instruction, utilisez l’ARN suivant : ``` "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0" ``` Pour spécifier toues les instances qui appartiennent à un compte, utilisez le caractère générique (\$1) : ``` "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*" ``` Certaines actions de Device Farm, telles que celles relatives à la création de ressources, ne peuvent pas être effectuées sur une ressource. Dans ce cas, vous devez utiliser le caractère générique (\$1). ``` "Resource": "*" ``` De nombreuses actions d'API Amazon EC2 nécessitent plusieurs ressources. Par exemple, comme `AttachVolume` attache un volume Amazon EBS à une instance, un utilisateur IAM doit avoir les autorisations nécessaires pour utiliser le volume et l'instance. Pour spécifier plusieurs ressources dans une seule instruction, séparez-les ARNs par des virgules. ``` "Resource": [ "resource1", "resource2" ``` Pour consulter la liste des types de ressources Device Farm et leurs caractéristiques ARNs, reportez-vous à la section [Types de ressources définis par AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-resources-for-iam-policies) dans le manuel *IAM Service Authorization Reference*. Pour savoir avec quelles actions vous pouvez spécifier l'ARN de chaque ressource, consultez la section [Actions définies par AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions) dans la *référence d'autorisation du service IAM*. ### Clés de condition Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**. L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*. Device Farm définit son propre ensemble de clés de condition et prend également en charge l'utilisation de certaines clés de condition globales. Pour voir toutes les clés de condition AWS globales, consultez la section [Clés contextuelles de condition AWS globale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*. Pour consulter la liste des clés de condition de Device Farm, reportez-vous à la section [Clés de condition AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-policy-keys) dans la *référence d'autorisation du service IAM*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez la section [Actions définies par AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions) dans la *référence d'autorisation du service IAM*. ### Exemples Pour consulter des exemples de politiques basées sur l'identité de Device Farm, consultez. [Exemples de politiques basées sur l'identité d'AWS Device Farm](security_iam_id-based-policy-examples.md) ## Politiques basées sur les ressources de Device Farm Device Farm ne prend pas en charge les politiques basées sur les ressources. ## Listes de contrôle d'accès (ACL) Device Farm ne prend pas en charge les listes de contrôle d'accès (ACLs). ## Autorisation basée sur les tags Device Farm Vous pouvez associer des tags aux ressources de Device Farm ou transmettre des tags dans une demande à Device Farm. Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`. Pour plus d'informations sur le balisage des ressources Device Farm, consultez[Balisage des ressources AWS Device Farm](tagging.md). Pour visualiser un exemple de politique basée sur l’identité permettant de limiter l’accès à une ressource en fonction des balises de cette ressource, consultez [Visualisation des projets de test du navigateur de bureau Device Farm basés sur des balises](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-view-project-tags). ## Rôles IAM de Device Farm Un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) est une entité de votre AWS compte dotée d'autorisations spécifiques. ### Utilisation d'informations d'identification temporaires avec Device Farm Device Farm prend en charge l'utilisation d'informations d'identification temporaires. Vous pouvez utiliser des informations d'identification temporaires pour vous connecter à la fédération afin d'assumer un rôle IAM ou un rôle entre comptes. Vous obtenez des informations d'identification de sécurité temporaires en appelant des opérations d' AWS STS API telles que [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)ou [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html). ### Rôles liés à un service Les [rôles liés aux](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) AWS services permettent aux services d'accéder aux ressources d'autres services pour effectuer une action en votre nom. Les rôles liés à un service s’affichent dans votre compte IAM et sont la propriété du service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations pour les rôles liés à un service. Device Farm utilise des rôles liés aux services dans la fonctionnalité de test du navigateur de bureau Device Farm. Pour plus d'informations sur ces rôles, consultez la section [Using Service-Linked Roles in Device Farm desktop browser testing](https://docs.aws.amazon.com//devicefarm/latest/testgrid/using-service-linked-roles.html) dans le guide du développeur. ### Rôles du service Device Farm ne prend pas en charge les rôles de service. Cette fonctionnalité permet à un service d’endosser un [rôle de service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role) en votre nom. Ce rôle autorise le service à accéder à des ressources d’autres services pour effectuer une action en votre nom. Les rôles de service s’affichent dans votre compte IAM et sont la propriété du compte. Cela signifie qu’un administrateur IAM peut modifier les autorisations associées à ce rôle. Toutefois, une telle action peut perturber le bon fonctionnement du service. ## Gestion de l’accès à l’aide de politiques Vous contrôlez l'accès en AWS créant des politiques et en les associant à AWS des identités ou à des ressources. Une politique définit les autorisations lorsqu'elles sont associées à une identité ou à une ressource. AWS évalue ces politiques lorsqu'un directeur fait une demande. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations les documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*. À l’aide de politiques, les administrateurs précisent qui a accès à quoi en définissant quel **principal** peut effectuer des **actions** sur quelles **ressources** et dans quelles **conditions**. Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Un administrateur IAM crée des politiques IAM et les ajoute aux rôles, que les utilisateurs peuvent ensuite assumer. Les politiques IAM définissent les autorisations quelle que soit la méthode que vous utilisez pour exécuter l’opération. ### Politiques basées sur l’identité Les stratégies basées sur l’identité sont des documents de stratégie d’autorisations JSON que vous attachez à une identité (utilisateur, groupe ou rôle). Ces politiques contrôlent les actions que peuvent exécuter ces identités, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*. Les politiques basées sur l’identité peuvent être des *politiques intégrées* (intégrées directement dans une seule identité) ou des *politiques gérées (politiques* autonomes associées à plusieurs identités). Pour découvrir comment choisir entre des politiques gérées et en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) dans le *Guide de l’utilisateur IAM*. Le tableau suivant décrit les politiques gérées par Device Farm AWS. | Modifier | Description | Date | | --- | --- | --- | | [AWSDeviceFarmFullAccess](https://console.aws.amazon.com/iam/home?region=us-east-1#/policies/arn:aws:iam::aws:policy/AWSDeviceFarmFullAccess$jsonEditor) | Fournit un accès complet à toutes les opérations d'AWS Device Farm. | 15 juillet 2015 | | [AWSServiceRoleForDeviceFarmTestGrid](https://docs.aws.amazon.com//devicefarm/latest/testgrid/using-service-linked-roles.html) | Permet à Device Farm d'accéder aux ressources AWS en votre nom. | 20 mai 2021 | ### Autres types de politique AWS prend en charge des types de politiques supplémentaires qui peuvent définir les autorisations maximales accordées par les types de politiques les plus courants : + **Limites d’autorisations** : une limite des autorisations définit le nombre maximum d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM. Pour plus d’informations, consultez [Limites d’autorisations pour des entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *Guide de l’utilisateur IAM*. + **Politiques de contrôle des services (SCPs)** — Spécifiez les autorisations maximales pour une organisation ou une unité organisationnelle dans AWS Organizations. Pour plus d’informations, consultez [Politiques de contrôle de service](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de l’utilisateur AWS Organizations *. + **Politiques de contrôle des ressources (RCPs)** : définissez le maximum d'autorisations disponibles pour les ressources de vos comptes. Pour plus d'informations, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*. + **Politiques de session** : politiques avancées que vous passez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*. ### Plusieurs types de politique Lorsque plusieurs types de politiques s’appliquent à la requête, les autorisations en résultant sont plus compliquées à comprendre. Pour savoir comment AWS déterminer s'il faut autoriser une demande lorsque plusieurs types de politiques sont impliqués, consultez la section [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *guide de l'utilisateur IAM*. # Exemples de politiques basées sur l'identité d'AWS Device Farm Par défaut, les utilisateurs et les rôles IAM ne sont pas autorisés à créer ou à modifier les ressources Device Farm. Ils ne peuvent pas non plus effectuer de tâches à l'aide de l' AWS API AWS Management Console AWS CLI, ou. Un administrateur IAM doit créer des politiques IAM autorisant les utilisateurs et les rôles à exécuter des opérations d'API spécifiques sur les ressources spécifiées dont ils ont besoin. Il doit ensuite attacher ces politiques aux utilisateurs ou aux groupes IAM ayant besoin de ces autorisations. Pour savoir comment créer une stratégie IAM basée sur l'identité à l'aide de ces exemples de documents de stratégie JSON, veuillez consulter [Création de stratégies dans l'onglet JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) dans le *Guide de l'utilisateur IAM*. **Topics** + [ ## Bonnes pratiques en matière de politiques ](#security_iam_service-with-iam-policy-best-practices) + [ ## Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations ](#security_iam_id-based-policy-examples-view-own-permissions) + [ ## Accès à un projet de test de navigateur de bureau Device Farm ](#security_iam_id-based-policy-examples-access-one-project) + [ ## Visualisation des projets de test du navigateur de bureau Device Farm basés sur des balises ](#security_iam_id-based-policy-examples-view-project-tags) ## Bonnes pratiques en matière de politiques Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer les ressources Device Farm de votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations : + **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*. + **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*. + **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*. + **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*. + **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*. Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*. ## Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS . ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` ## Accès à un projet de test de navigateur de bureau Device Farm Dans cet exemple, vous souhaitez autoriser un utilisateur IAM de votre AWS compte à accéder à l'un de vos projets de test du navigateur de bureau Device Farm. `arn:aws:devicefarm:us-west-2:111122223333:testgrid-project:123e4567-e89b-12d3-a456-426655441111` Vous souhaitez que le compte puisse voir les éléments associés au projet. En plus du point de terminaison `devicefarm:GetTestGridProject`, le compte doit avoir les points de terminaison `devicefarm:ListTestGridSessions`, `devicefarm:GetTestGridSession`, `devicefarm:ListTestGridSessionActions` et `devicefarm:ListTestGridSessionArtifacts`. Si vous utilisez des systèmes CI, vous devez donner des informations d'identification d'accès uniques à chaque exécuteur CI. Par exemple, il est peu probable qu'un système CI ait besoin d’autorisations autres que `devicefarm:ScheduleRun` ou `devicefarm:CreateUpload`. La politique IAM suivante décrit une politique minimale permettant à un utilisateur de CI de démarrer le test d'une nouvelle application native Device Farm en créant un téléchargement et en l'utilisant pour planifier un test : ## Visualisation des projets de test du navigateur de bureau Device Farm basés sur des balises Vous pouvez utiliser les conditions de votre politique basée sur l'identité pour contrôler l'accès aux ressources de Device Farm en fonction de balises. Cet exemple montre comment créer une stratégie qui autorise l'affichage de projets et de sessions. L'autorisation est accordée si la balise `Owner` de la ressource demandée correspond au nom d'utilisateur du compte demandeur. Vous pouvez rattacher cette politique aux utilisateurs IAM de votre compte. Si un utilisateur nommé `richard-roe` tente de consulter un projet ou une session Device Farm, le projet doit être étiqueté `Owner=richard-roe` ou`owner=richard-roe`. Dans le cas contraire, l’utilisateur se voit refuser l'accès. La clé de condition de balise `Owner` correspond à la fois à `Owner` et à `owner`, car les noms de clé de condition ne sont pas sensibles à la casse. Pour plus d'informations, consultez [Éléments de politique JSON IAM : Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*. # Résolution des problèmes d'identité et d'accès à AWS Device Farm Utilisez les informations suivantes pour vous aider à diagnostiquer et à résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec Device Farm et IAM. ## Je ne suis pas autorisé à effectuer une action dans Device Farm Si vous recevez un message d'erreur indiquant AWS Management Console que vous n'êtes pas autorisé à effectuer une action, vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui vous a fourni votre nom d'utilisateur et votre mot de passe. L'exemple d'erreur suivant se produit lorsque l'utilisateur IAM essaie d'utiliser la console pour afficher les détails d'une exécution, mais ne dispose pas des `devicefarm:GetRun` autorisations nécessaires. `mateojackson` ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: devicefarm:GetRun on resource: arn:aws:devicefarm:us-west-2:123456789101:run:123e4567-e89b-12d3-a456-426655440000/123e4567-e89b-12d3-a456-426655441111 ``` Dans ce cas, Mateo demande à son administrateur de mettre à jour ses stratégies pour lui permettre d'accéder à la ressource `devicefarm:GetRun`sur la ressource `arn:aws:devicefarm:us-west-2:123456789101:run:123e4567-e89b-12d3-a456-426655440000/123e4567-e89b-12d3-a456-426655441111` à l'aide de l'action `devicefarm:GetRun`. ## Je ne suis pas autorisé à effectuer iam : PassRole Si vous recevez un message d'erreur indiquant que vous n'êtes pas autorisé à effectuer l'`iam:PassRole`action, vos politiques doivent être mises à jour pour vous permettre de transmettre un rôle à Device Farm. Certains vous Services AWS permettent de transmettre un rôle existant à ce service au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, vous devez disposer des autorisations nécessaires pour transmettre le rôle au service. L'exemple d'erreur suivant se produit lorsqu'un utilisateur IAM nommé `marymajor` essaie d'utiliser la console pour effectuer une action dans Device Farm. Toutefois, l’action nécessite que le service ait des autorisations accordées par un rôle de service. Mary n'est pas autorisée à transmettre le rôle au service. ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` Dans ce cas, les politiques de Mary doivent être mises à jour pour lui permettre d’exécuter l’action `iam:PassRole`. Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations de connexion. ## Je veux afficher mes clés d'accès Une fois les clés d'accès utilisateur IAM créées, vous pouvez afficher votre ID de clé d'accès à tout moment. Toutefois, vous ne pouvez pas revoir votre clé d’accès secrète. Si vous perdez votre clé d'accès secrète, vous devez créer une nouvelle paire de clés. Les clés d'accès se composent de deux parties : un ID de clé d'accès (par exemple, `AKIAIOSFODNN7EXAMPLE`) et une clé d'accès secrète (par exemple, `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`). À l'instar d'un nom d'utilisateur et un mot de passe, vous devez utiliser à la fois l'ID de clé d'accès et la clé d'accès secrète pour authentifier vos demandes. Gérez vos clés d'accès de manière aussi sécurisée que votre nom d'utilisateur et votre mot de passe. **Important** Ne communiquez pas vos clés d'accès à un tiers, même pour qu'il vous aide à [trouver votre ID utilisateur canonique](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId). Ce faisant, vous pourriez donner à quelqu'un un accès permanent à votre Compte AWS. Lorsque vous créez une paire de clé d'accès, enregistrez l'ID de clé d'accès et la clé d'accès secrète dans un emplacement sécurisé. La clé d'accès secrète est accessible uniquement au moment de sa création. Si vous perdez votre clé d'accès secrète, vous devez ajouter de nouvelles clés d'accès pour votre utilisateur IAM. Vous pouvez avoir un maximum de deux clés d'accès. Si vous en avez déjà deux, vous devez supprimer une paire de clés avant d'en créer une nouvelle. Pour afficher les instructions, consultez [Gestion des clés d'accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) dans le *Guide de l'utilisateur IAM*. ## Je suis administrateur et je souhaite autoriser d'autres personnes à accéder à Device Farm Pour autoriser d'autres personnes à accéder à Device Farm, vous devez autoriser les personnes ou les applications qui ont besoin d'y accéder. Si vous utilisez AWS IAM Identity Center pour gérer des personnes et des applications, vous attribuez des ensembles d'autorisations aux utilisateurs ou aux groupes afin de définir leur niveau d'accès. Les ensembles d'autorisations créent et attribuent automatiquement des politiques IAM aux rôles IAM associés à la personne ou à l'application. Pour plus d'informations, consultez la section [Ensembles d'autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) dans le *guide de AWS IAM Identity Center l'utilisateur*. Si vous n'utilisez pas IAM Identity Center, vous devez créer des entités IAM (utilisateurs ou rôles) pour les personnes ou les applications qui ont besoin d'un accès. Vous devez ensuite associer une politique à l'entité qui lui accorde les autorisations appropriées dans Device Farm. Une fois les autorisations accordées, fournissez les informations d'identification à l'utilisateur ou au développeur de l'application. Ils utiliseront ces informations d'identification pour y accéder AWS. Pour en savoir plus sur la création d'utilisateurs, de groupes, de politiques et d'autorisations [IAM, consultez la section Identités](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html), [politiques et autorisations IAM dans le guide de l'utilisateur *IAM*](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html). ## Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder aux ressources de mon Device Farm Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources. Pour plus d’informations, consultez les éléments suivants : + Pour savoir si Device Farm prend en charge ces fonctionnalités, consultez[Comment AWS Device Farm fonctionne avec IAM](security_iam_service-with-iam.md). + Pour savoir comment fournir l'accès à vos ressources sur celles Comptes AWS que vous possédez, consultez la section [Fournir l'accès à un utilisateur IAM dans un autre utilisateur Compte AWS que vous possédez](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) dans le Guide de l'*utilisateur IAM*. + Pour savoir comment fournir l'accès à vos ressources à des tiers Comptes AWS, consultez la section [Fournir un accès à des ressources Comptes AWS détenues par des tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dans le *guide de l'utilisateur IAM*. + Pour savoir comment fournir un accès par le biais de la fédération d’identité, consultez [Fournir un accès à des utilisateurs authentifiés en externe (fédération d’identité)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dans le *Guide de l’utilisateur IAM*. + Pour en savoir plus sur la différence entre l’utilisation des rôles et des politiques basées sur les ressources pour l’accès intercompte, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*. # Validation de conformité pour AWS Device Farm Des auditeurs tiers évaluent la sécurité et la conformité dans AWS Device Farm le cadre de plusieurs programmes de AWS conformité. Il s'agit notamment du SOC, du PCI, du FedRAMP, de l'HIPAA et d'autres. AWS Device Farm n'entre dans le champ d'aucun programme de AWS conformité. Pour obtenir la liste des AWS services concernés par des programmes de conformité spécifiques, voir [Services AWS concernés par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/) . Pour des informations générales, voir Programmes de [AWS conformité Programmes AWS](https://aws.amazon.com/compliance/programs/) de . Vous pouvez télécharger des rapports d'audit tiers à l'aide de AWS Artifact. Pour plus d’informations, consultez [Téléchargement de rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html). Lorsque vous utilisez Device Farm, votre responsabilité en matière de conformité dépend de la sensibilité de vos données, des objectifs de conformité de votre entreprise et des lois et réglementations applicables. AWS fournit les ressources suivantes pour faciliter la mise en conformité : + [Guides démarrage rapide de la sécurité et de la conformité](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance). Ces guides de déploiement traitent des considérations architecturales et fournissent des étapes pour déployer des environnements de base axés sur la sécurité et la conformité sur AWS. + AWS Ressources de [https://aws.amazon.com/compliance/resources/](https://aws.amazon.com/compliance/resources/) de conformité — Cette collection de classeurs et de guides peut s'appliquer à votre secteur d'activité et à votre région. + [Évaluation des ressources à l'aide des règles](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) du *guide du AWS Config développeur* : AWS Config évalue dans quelle mesure les configurations de vos ressources sont conformes aux pratiques internes, aux directives du secteur et aux réglementations. + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Ce AWS service fournit une vue complète de l'état de votre sécurité interne, AWS ce qui vous permet de vérifier votre conformité aux normes et aux meilleures pratiques du secteur de la sécurité. # Protection des données dans AWS Device Farm Le [modèle de responsabilité AWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) s'applique à la protection des données dans AWS Device Farm (Device Farm). Comme décrit dans ce modèle, AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS Cloud. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog [Modèle de responsabilité partagée d’AWS et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécuritéAWS *. À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous : + Utilisez l’authentification multifactorielle (MFA) avec chaque compte. + SSL/TLS À utiliser pour communiquer avec AWS les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3. + Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail. Pour plus d'informations sur l'utilisation des CloudTrail sentiers pour capturer AWS des activités, consultez la section [Utilisation des CloudTrail sentiers](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *guide de AWS CloudTrail l'utilisateur*. + Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut qu'ils contiennent Services AWS. + Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3. + Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-3 pour accéder AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez [Norme FIPS (Federal Information Processing Standard) 140-3](https://aws.amazon.com/compliance/fips/). Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela inclut lorsque vous travaillez avec Device Farm ou autre Services AWS à l'aide de la console, de l'API ou AWS SDKs. AWS CLI Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur. ## Chiffrement en transit Les points de terminaison Device Farm ne prennent en charge que le protocole HTTPS signé (SSL/TLS) requests except where otherwise noted. All content retrieved from or placed in Amazon S3 through upload URLs is encrypted using SSL/TLS. Pour plus d'informations sur la façon dont les requêtes HTTPS sont connectées AWS, consultez la section [Signature des demandes AWS d'API](https://docs.aws.amazon.com//general/latest/gr/signing_aws_api_requests.html) dans le manuel de référence AWS général. Il est de votre responsabilité de chiffrer et de sécuriser toutes les communications effectuées par vos applications testées et par toutes les applications supplémentaires installée dans le cadre de l'exécution des tests sur les périphériques. ## Chiffrement au repos La fonctionnalité de test du navigateur de bureau de Device Farm prend en charge le chiffrement au repos des artefacts générés lors des tests. Les données de test des appareils mobiles physiques de Device Farm ne sont pas cryptées au repos. ## Conservation des données Les données de Device Farm sont conservées pendant une durée limitée. Une fois la période de conservation expirée, les données sont supprimées du stockage de sauvegarde de Device Farm. | Type de contenu | Période de conservation (jours) | Période de conservation des métadonnées (jours) | | --- | --- | --- | | Applications chargées | 30 | 30 | | Paquets de test chargés | 30 | 30 | | Journaux | 400 | 400 | | Enregistrements vidéo et autres artefacts | 400 | 400 | Il vous incombe d'archiver tout contenu que vous souhaitez conserver pendant des périodes plus longues. ## Gestion des données Les données de Device Farm sont gérées différemment selon les fonctionnalités utilisées. Cette section explique comment les données sont gérées pendant et après l'utilisation de Device Farm. ### Test du navigateur de bureau Les instances utilisées pendant les sessions Selenium ne sont pas enregistrées. Toutes les données générées à la suite d’interactions du navigateur sont supprimées en fin de session. Cette fonctionnalité prend actuellement en charge le chiffrement au repos pour les artefacts générés pendant le test. ### Tests d'appareils physiques Les sections suivantes fournissent des informations sur les étapes AWS à suivre pour nettoyer ou détruire les appareils après avoir utilisé Device Farm. Les données de test des appareils mobiles physiques de Device Farm ne sont pas cryptées au repos. #### Flottes d'appareils publics Une fois l'exécution du test terminée, Device Farm exécute une série de tâches de nettoyage sur chaque appareil du parc d'appareils publics, y compris la désinstallation de votre application. Si nous ne pouvons pas vérifier la désinstallation de votre application ou l'une des autres étapes de nettoyage, l'appareil fait l'objet d'une réinitialisation d'usine avant d'être remis en utilisation. **Note** Il est possible que les données persistent entre les sessions dans certains cas, en particulier si vous utilisez le système de l'appareil en dehors du contexte de votre application. Pour cette raison, et dans la mesure où Device Farm enregistre des vidéos et des journaux d'activité pendant que vous utilisez chaque appareil, nous vous recommandons de ne pas saisir d'informations sensibles (par exemple, un compte Google ou un identifiant Apple), d'informations personnelles ou d'autres informations sensibles en matière de sécurité lors de vos sessions de test automatique et d'accès à distance. #### Appareils privés Après l'expiration ou la résiliation de votre contrat d'appareil privé, celui-ci ne peut plus être utilisé et est détruit en toute sécurité conformément aux stratégies de destruction AWS. Pour de plus amples informations, veuillez consulter [Appareils privés dans AWS Device Farm](working-with-private-devices.md). ## Gestion des clés Device Farm ne propose actuellement aucune gestion de clé externe pour le chiffrement des données, qu'elles soient au repos ou en transit. ## Confidentialité du trafic inter-réseau Device Farm peut être configuré, pour les appareils privés uniquement, pour utiliser les points de terminaison Amazon VPC pour se connecter à vos ressources. AWS L'accès à toute AWS infrastructure non publique associée à votre compte (par exemple, les EC2 instances Amazon sans adresse IP publique) doit utiliser un point de terminaison Amazon VPC. Quelle que soit la configuration du point de terminaison VPC, Device Farm isole votre trafic des autres utilisateurs du réseau Device Farm. La sécurité de vos connexions en dehors du AWS réseau n'est pas garantie, et il est de votre responsabilité de sécuriser toutes les connexions Internet établies par vos applications. # Résilience dans AWS Device Farm L'infrastructure AWS mondiale est construite autour des AWS régions et des zones de disponibilité. AWS Les régions fournissent plusieurs zones de disponibilité physiquement séparées et isolées, connectées par un réseau à faible latence, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone à l’autre sans interruption. Les zones de disponibilité sont davantage disponibles, tolérantes aux pannes et ont une plus grande capacité de mise à l’échelle que les infrastructures traditionnelles à un ou plusieurs centres de données. Pour plus d'informations sur AWS les régions et les zones de disponibilité, consultez la section [Infrastructure AWS mondiale](https://aws.amazon.com/about-aws/global-infrastructure/). Device Farm n'étant disponible que dans la `us-west-2` région, nous vous recommandons vivement de mettre en œuvre des processus de sauvegarde et de restauration. Device Farm ne doit pas être la seule source de contenu mis en ligne. Device Farm ne garantit pas la disponibilité des appareils publics. Ces appareils sont introduits et retirés du parc de périphériques public en fonction de divers facteurs, tels que le taux d'échec et le statut de quarantaine. Nous vous recommandons de ne pas dépendre de la disponibilité d'un seul appareil dans le parc de périphériques public. # Sécurité de l'infrastructure dans AWS Device Farm En tant que service géré, AWS Device Farm il est protégé par la sécurité du réseau AWS mondial. Pour plus d'informations sur les services AWS de sécurité et sur la manière dont AWS l'infrastructure est protégée, consultez la section [Sécurité du AWS cloud](https://aws.amazon.com/security/). Pour concevoir votre AWS environnement en utilisant les meilleures pratiques en matière de sécurité de l'infrastructure, consultez la section [Protection de l'infrastructure](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) dans le cadre * AWS bien architecturé du pilier de sécurité*. Vous utilisez des appels d'API AWS publiés pour accéder à Device Farm via le réseau. Les clients doivent prendre en charge les éléments suivants : + Protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3. + Ses suites de chiffrement PFS (Perfect Forward Secrecy) comme DHE (Ephemeral Diffie-Hellman) ou ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes. En outre, les demandes doivent être signées à l’aide d’un ID de clé d’accès et d’une clé d’accès secrète associée à un principal IAM. Vous pouvez également utiliser [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) pour générer des informations d’identification de sécurité temporaires et signer les demandes. ## Sécurité de l'infrastructure pour les tests de périphériques physiques Pendant les tests physiques, les périphériques sont physiquement séparés. L'isolation du réseau empêche la communication entre les périphériques sur les réseaux sans fil. Les appareils publics sont partagés, et Device Farm fait de son mieux pour assurer la sécurité des appareils au fil du temps. Certaines actions, telles que les tentatives d'acquisition de droits d'administrateur complets sur un périphérique (pratique appelée *débridage* ou *jailbreak*), provoquent la mise en quarantaine de périphériques publics. Ceux-ci sont automatiquement retirés du pool public et font l’objet d’un examen manuel. Les appareils privés ne sont accessibles que par AWS des comptes explicitement autorisés à le faire. Device Farm isole physiquement ces appareils des autres appareils et les maintient sur un réseau distinct. Sur les appareils gérés de manière privée, les tests peuvent être configurés pour utiliser un point de terminaison Amazon VPC afin de sécuriser les connexions entrantes et sortantes de votre AWS compte. ## Sécurité de l'infrastructure pour les tests de navigateurs de bureau Lorsque vous utilisez la fonctionnalité de test du navigateur de bureau, toutes les sessions de test sont séparées les unes des autres. Les instances Selenium ne peuvent pas communiquer entre elles sans un tiers intermédiaire, externe à. AWS Tout le trafic vers les WebDriver contrôleurs Selenium doit être effectué via le point de terminaison HTTPS généré avec`createTestGridUrl`. Il vous incombe de vous assurer que chaque instance de test Device Farm dispose d'un accès sécurisé aux ressources qu'elle teste. Par défaut, les instances de test du navigateur de bureau de Device Farm ont accès à l'Internet public. Lorsque vous attachez votre instance à un VPC, elle se comporte comme n'importe quelle autre instance EC2, avec un accès aux ressources déterminé par la configuration du VPC et ses composants réseau associés. AWS fournit des [groupes de sécurité et des](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-security-groups.html) [listes de contrôle d'accès réseau (ACLs)](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html) pour renforcer la sécurité de votre VPC. Les groupes de sécurité contrôlent le trafic entrant et sortant pour vos ressources, et le réseau ACLs contrôlent le trafic entrant et sortant pour vos sous-réseaux. Les groupes de sécurité offrent un contrôle d’accès suffisant pour la plupart des sous-réseaux. Vous pouvez utiliser le réseau ACLs si vous souhaitez ajouter une couche de sécurité supplémentaire à votre VPC. Pour obtenir des directives générales sur les meilleures pratiques de sécurité lors de l'utilisation d'Amazon VPCs, consultez [les meilleures pratiques de sécurité](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-security-best-practices.html) pour votre VPC dans le guide de l'*utilisateur Amazon Virtual Private Cloud*. # Analyse et gestion des vulnérabilités de configuration dans Device Farm Device Farm vous permet d'exécuter des logiciels qui ne sont pas activement maintenus ou corrigés par le fournisseur, tel que le fournisseur du système d'exploitation, le fournisseur du matériel ou l'opérateur téléphonique. Device Farm fait de son mieux pour maintenir le logiciel à jour, mais ne garantit pas qu'une version particulière du logiciel sur un appareil physique soit à jour, car elle permet de par sa conception de mettre en œuvre des logiciels potentiellement vulnérables. Par exemple, si un test est effectué sur un appareil exécutant Android 4.4.2, Device Farm ne garantit pas que l'appareil est corrigé contre la [vulnérabilité Android connue sous](https://en.wikipedia.org/wiki/Stagefright_(bug)) le nom de. StageFright Il appartient au fournisseur (et parfois à l’opérateur) du périphérique de fournir les mises à jour de sécurité pour les périphériques. Il n’est pas garanti qu’une application malveillante utilisant cette vulnérabilité soit détectée par notre mise en quarantaine automatisée. Les appareils privés sont gérés conformément à votre accord avec AWS. *Device Farm met tout en œuvre pour empêcher les applications des clients de commettre des actions telles que le *rootage* ou le jailbreak.* Device Farm supprime les appareils mis en quarantaine du pool public jusqu'à ce qu'ils aient été examinés manuellement. Vous êtes responsable de la mise à jour de toutes les bibliothèques ou versions de logiciels que vous utilisez dans vos tests, telles que les roues Python et les gemmes Ruby. Device Farm vous recommande de mettre à jour vos bibliothèques de test. Ces ressources peuvent vous aider à maintenir vos dépendances de test à jour : + Pour plus d'informations sur la façon de sécuriser les gemmes Ruby, consultez [les pratiques de sécurité](https://guides.rubygems.org/security/) sur le RubyGems site Web. + Pour plus d'informations sur le package de sécurité utilisé par Pipenv et approuvé par la Python Packaging Authority pour analyser votre graphe de dépendances à la recherche de vulnérabilités connues, consultez la section [Détection des vulnérabilités de sécurité](https://github.com/pypa/pipenv/blob/master/docs/advanced.rst#-detection-of-security-vulnerabilities) sur. GitHub + Pour plus d'informations sur le vérificateur de dépendances Maven de l'Open Web Application Security Project (OWASP), consultez OWASP sur le site Web de l'[ DependencyCheckOWASP](https://owasp.org/www-project-dependency-check/). Il est important de se rappeler que même si un système automatisé n’indique pas l’existence de problèmes de sécurité connus, cela ne signifie pas qu'il n'y en a pas. Utilisez toujours avec la prudence raisonnable les bibliothèques ou outils de tiers, et vérifiez les signatures cryptographiques si c’est possible ou raisonnable. # Réponse aux incidents dans Device Farm Device Farm surveille en permanence les appareils pour détecter les comportements susceptibles d'indiquer des problèmes de sécurité. Si un autre client AWS est informé d'un cas où les données d'un client, telles que les résultats de tests ou les fichiers écrits sur un appareil public, sont accessibles par un autre client, AWS contacte les clients concernés, conformément aux politiques standard d'alerte et de signalement des incidents utilisées dans l'ensemble AWS des services. # Journalisation et surveillance dans Device Farm Ce service prend AWS CloudTrail en charge un service qui enregistre les AWS appels pour vous Compte AWS et envoie des fichiers journaux à un compartiment Amazon S3. En utilisant les informations collectées par CloudTrail, vous pouvez déterminer à quelles demandes ont été adressées avec succès Services AWS, qui a fait la demande, quand elle a été faite, etc. Pour en savoir plus CloudTrail, notamment sur la façon de l'activer et de trouver vos fichiers journaux, consultez le [guide de AWS CloudTrail l'utilisateur](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/). Pour plus d'informations sur l'utilisation CloudTrail avec Device Farm, consultez[Journalisation des appels d'API AWS Device Farm avec AWS CloudTrail](logging-using-cloudtrail.md). # Bonnes pratiques en matière de sécurité pour Device Farm Device Farm propose un certain nombre de fonctionnalités de sécurité à prendre en compte lors de l'élaboration et de la mise en œuvre de vos propres politiques de sécurité. Les bonnes pratiques suivantes doivent être considérées comme des instructions générales et ne représentent pas une solution de sécurité complète. Étant donné que ces bonnes pratiques peuvent ne pas être appropriées ou suffisantes pour votre environnement, considérez-les comme des remarques utiles plutôt que comme des recommandations. + Accordez à tout système d'intégration continue (CI) que vous utilisez le moins de privilèges possible sous IAM. Envisagez d'utiliser des informations d'identification temporaires pour chaque test de système CI, afin que même si un système CI est compromis, il ne puisse pas effectuer de demandes fallacieuses. Pour plus d'informations sur les informations d'identification temporaires, consultez le [guide de l'utilisateur IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerole). + Utilisez les commandes `adb` dans un environnement de test personnalisé pour nettoyer tout contenu créé par votre application. Pour plus d'informations sur les environnements de test personnalisés, consultez [Environnements de test personnalisés dans AWS Device Farm](custom-test-environments.md)