As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Segurança em AWS Device Farm A segurança na nuvem AWS é a maior prioridade. Como AWS cliente, você se beneficia de uma arquitetura de data center e rede criada para atender aos requisitos das organizações mais sensíveis à segurança. A segurança é uma responsabilidade compartilhada entre você AWS e você. O [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) descreve isso como segurança *da* nuvem e segurança *na* nuvem: + **Segurança da nuvem** — AWS é responsável por proteger a infraestrutura que executa AWS os serviços na AWS nuvem. AWS também fornece serviços que você pode usar com segurança. Auditores terceirizados testam e verificam regularmente a eficácia de nossa segurança como parte dos Programas de Conformidade Programas de [AWS](https://aws.amazon.com/compliance/programs/) de . Para saber mais sobre os programas de conformidade que se aplicam AWS Device Farm, consulte [Serviços da AWS no escopo do programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/) . + **Segurança na nuvem**: sua responsabilidade é determinada pelo serviço da AWS que você usa. Você também é responsável por outros fatores, incluindo a confidencialidade de seus dados, os requisitos da empresa e as leis e regulamentos aplicáveis. Esta documentação o ajuda a entender como aplicar o modelo de responsabilidade compartilhada ao usar o Device Farm. Os tópicos a seguir mostram como configurar o Device Farm para atender aos seus objetivos de segurança e conformidade. Você também aprenderá a usar outros serviços da AWS que o ajudam a monitorar e proteger os recursos do Device Farm. **Topics** + [ # Gerenciamento de identidade e acesso no AWS Device Farm ](security-iam.md) + [ # Validação de conformidade do AWS Device Farm ](ATP-compliance.md) + [ # Proteção de dados em AWS Device Farm ](data-protection.md) + [ # Resiliência no AWS Device Farm ](disaster-recovery-resiliency.md) + [ # Segurança da infraestrutura em AWS Device Farm ](infrastructure-security.md) + [ # Análise e gerenciamento de vulnerabilidades de configuração no Device Farm ](security-vulnerability-analysis-and-management.md) + [ # Resposta a incidentes no Device Farm ](security-incident-response.md) + [ # Registrar em log e monitorar no Device Farm ](security-logging-monitoring.md) + [ # Práticas recomendadas de segurança para o Device Farm ](security-best-practices.md) # Gerenciamento de identidade e acesso no AWS Device Farm ## Público A forma como você usa AWS Identity and Access Management (IAM) difere com base na sua função: + **Usuário do serviço**: solicite permissões ao seu administrador se você não conseguir acessar os atributos (consulte [Solução de problemas de identidade e acesso ao AWS Device Farm](security_iam_troubleshoot.md)). + **Administrador do serviço**: determine o acesso do usuário e envie solicitações de permissão (consulte [Como o AWS Device Farm funciona com o IAM](security_iam_service-with-iam.md)) + **Administrador do IAM**: escreva políticas para gerenciar o acesso (consulte [Exemplos de políticas baseadas em identidade do AWS Device Farm](security_iam_id-based-policy-examples.md)) ## Autenticação com identidades A autenticação é como você faz login AWS usando suas credenciais de identidade. Você deve estar autenticado como usuário do IAM ou assumindo uma função do IAM. Usuário raiz da conta da AWS Você pode fazer login como uma identidade federada usando credenciais de uma fonte de identidade como Centro de Identidade do AWS IAM (IAM Identity Center), autenticação de login único ou credenciais. Google/Facebook Para ter mais informações sobre como fazer login, consulte [Como fazer login em sua Conta da AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) no *Guia do usuário do Início de Sessão da AWS *. Para acesso programático, AWS fornece um SDK e uma CLI para assinar solicitações criptograficamente. Para ter mais informações, consulte [AWS Signature Version 4 para solicitações de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) no *Guia do usuário do IAM*. ### Conta da AWS usuário root Ao criar um Conta da AWS, você começa com uma identidade de login chamada *usuário Conta da AWS raiz* que tem acesso completo a todos Serviços da AWS os recursos. É altamente recomendável não usar o usuário-raiz em tarefas diárias. Consulte as tarefas que exigem credenciais de usuário-raiz em [Tarefas que exigem credenciais de usuário-raiz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) no *Guia do usuário do IAM*. ### Grupos e usuários do IAM Um *[usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* é uma identidade com permissões específicas para uma única pessoa ou aplicação. É recomendável usar credenciais temporárias, em vez de usuários do IAM com credenciais de longo prazo. Para obter mais informações, consulte [Exigir que usuários humanos usem a federação com um provedor de identidade para acessar AWS usando credenciais temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) no *Guia do usuário do IAM*. Um [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica um conjunto de usuários do IAM e facilita o gerenciamento de permissões para grandes conjuntos de usuários. Para ter mais informações, consulte [Casos de uso de usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) no *Guia do usuário do IAM*. ### Perfis do IAM Uma *[perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* é uma identidade com permissões específicas que oferece credenciais temporárias. Você pode assumir uma função [mudando de um usuário para uma função do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou chamando uma operação de AWS API AWS CLI ou. Para saber mais, consulte [Métodos para assumir um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) no *Manual do usuário do IAM*. Os perfis do IAM são úteis para acesso de usuário federado, permissões de usuário do IAM temporárias, acesso entre contas, acesso entre serviços e aplicações em execução no Amazon EC2. Consulte mais informações em [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*. # Como o AWS Device Farm funciona com o IAM Antes de usar o IAM para gerenciar o acesso ao Device Farm, você deve entender quais recursos do IAM estão disponíveis para uso com o Device Farm. Para ter uma visão geral de como o Device Farm e outros AWS serviços funcionam com o IAM, consulte [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Guia do usuário do IAM*. **Topics** + [ ## Políticas baseadas em identidade do Device Farm ](#security_iam_service-with-iam-id-based-policies) + [ ## Políticas baseadas em recursos do Device Farm ](#security_iam_service-with-iam-resource-based-policies) + [ ## Listas de controle de acesso ](#security_iam_service-with-iam-acls) + [ ## Autorização baseada em tags do Device Farm ](#security_iam_service-with-iam-tags) + [ ## Perfis do IAM do Device Farm ](#security_iam_service-with-iam-roles) ## Políticas baseadas em identidade do Device Farm Com as políticas baseadas em identidade do IAM, é possível especificar ações ou recursos permitidos ou negados, além das condições sob as quais as ações são permitidas ou negadas. O Device Farm oferece suporte a ações, recursos e chaves de condição específicos. Para conhecer todos os elementos usados em uma política JSON, consulte [Referência de elementos de política JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) no *Guia do usuário do IAM*. ### Ações Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. O elemento `Action` de uma política JSON descreve as ações que podem ser usadas para permitir ou negar acesso em uma política. Incluem ações em uma política para conceder permissões para executar a operação associada. As ações de política no Device Farm usam o seguinte prefixo antes da ação: `devicefarm:`. Por exemplo, para conceder permissão a alguém para iniciar sessões do Selenium com a operação de API `CreateTestGridUrl` de teste de navegador de desktop do Device Farm, você inclui a ação `devicefarm:CreateTestGridUrl` na política. As instruções de política devem incluir um elemento `Action` ou `NotAction`. O Device Farm define seu próprio conjunto de ações que descrevem as tarefas que você pode executar com esse serviço. Para especificar várias ações em uma única instrução, separe-as com vírgulas, como segue: ``` "Action": [ "devicefarm:action1", "devicefarm:action2" ``` Você também pode especificar várias ações usando caracteres curinga (\$1). Por exemplo, para especificar todas as ações que começam com a palavra `List`, inclua a seguinte ação: ``` "Action": "devicefarm:List*" ``` Para ver uma lista de ações do Device Farm, consulte [Actions defined by AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions) na *Referência de autorização de serviço do IAM*. ### Recursos Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. O elemento de política JSON `Resource` especifica o objeto ou os objetos aos quais a ação se aplica. Como prática recomendada, especifique um recurso usando seu [nome do recurso da Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Para ações que não oferecem compatibilidade com permissões em nível de recurso, use um curinga (\$1) para indicar que a instrução se aplica a todos os recursos. ``` "Resource": "*" ``` O recurso de instância do Amazon EC2 tem o seguinte ARN: ``` arn:${Partition}:ec2:${Region}:${Account}:instance/${InstanceId} ``` Para obter mais informações sobre o formato de ARNs, consulte [Amazon Resource Names (ARNs) e AWS Service Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). Por exemplo, para especificar a instância `i-1234567890abcdef0` na instrução, use o seguinte ARN: ``` "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0" ``` Para especificar todas as instâncias que pertencem a uma conta, use o caractere curinga (\$1): ``` "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*" ``` Algumas ações do Device Farm, como as de criação de recursos, não podem ser executadas em um recurso. Nesses casos, é necessário utilizar o caractere curinga (\$1). ``` "Resource": "*" ``` Muitas ações da API do Amazon EC2 envolvem vários recursos. Por exemplo, `AttachVolume` anexa um volume do Amazon EBS a uma instância, portanto, um usuário do IAM deve ter permissões para usar o volume e a instância. Para especificar vários recursos em uma única instrução, separe-os ARNs com vírgulas. ``` "Resource": [ "resource1", "resource2" ``` Para ver uma lista dos tipos de recursos do Device Farm e seus ARNs, consulte [Tipos de recursos definidos AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-resources-for-iam-policies) na *Referência de autorização de serviço do IAM*. Para saber com quais ações você pode especificar o ARN de cada recurso, consulte [Actions defined by AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions) na *Referência de autorização de serviço do IAM*. ### Chaves de condição Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. O elemento `Condition` especifica quando as instruções são executadas com base em critérios definidos. É possível criar expressões condicionais que usem [agentes de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), como “igual a” ou “menor que”, para fazer a condição da política corresponder aos valores na solicitação. Para ver todas as chaves de condição AWS globais, consulte as [chaves de contexto de condição AWS global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*. O Device Farm define seu próprio conjunto de chaves de condição e também permite o uso de algumas chaves de condição globais. Para ver todas as chaves de condição AWS globais, consulte [Chaves de contexto de condição AWS global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*. Para ver uma lista das chaves de condição do Device Farm, consulte [Condition keys for AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-policy-keys) na *Referência de autorização de serviço do IAM*. Para saber com quais ações e recursos você pode usar uma chave de condição, consulte [Actions defined by AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions) na *Referência de autorização de serviço do IAM*. ### Exemplos Para ver exemplos de políticas baseadas em identidade do Device Farm, consulte [Exemplos de políticas baseadas em identidade do AWS Device Farm](security_iam_id-based-policy-examples.md). ## Políticas baseadas em recursos do Device Farm O Device Farm não é compatível com políticas baseadas em recursos. ## Listas de controle de acesso O Device Farm não suporta listas de controle de acesso (ACLs). ## Autorização baseada em tags do Device Farm Você pode anexar tags aos recursos do Device Farm ou passar tags em uma solicitação para o Device Farm. Para controlar o acesso baseado em tags, forneça informações sobre as tags no [elemento de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de uma política usando as `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou chaves de condição `aws:TagKeys`. Para obter mais informações sobre a marcação de recursos do Device Farm, consulte [Marcação de recursos do AWS Device Farm](tagging.md). Para visualizar um exemplo de política baseada em identidade para limitar o acesso a um recurso baseado em tags desse recurso, consulte [Visualizando projetos de teste do navegador de desktop Device Farm com base em tags](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-view-project-tags). ## Perfis do IAM do Device Farm Uma [função do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) é uma entidade na sua AWS conta que tem permissões específicas. ### Uso de credenciais temporárias com o Device Farm O Device Farm é compatível com o uso de credenciais temporárias. Você pode usar credenciais temporárias para fazer login com a federação e assumir um perfil do IAM ou um perfil entre contas. Você obtém credenciais de segurança temporárias chamando operações de AWS STS API, como [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). ### Perfis vinculados ao serviço [As funções vinculadas ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) permitem que AWS os serviços acessem recursos em outros serviços para concluir uma ação em seu nome. Os perfis vinculados a serviço aparecem em sua conta do IAM e são de propriedade do serviço. Um administrador do IAM pode visualizar, mas não pode editar, as permissões das funções vinculadas a serviços. O Device Farm usa perfis vinculados ao serviço no recurso de teste do navegador de desktop do Device Farm. Para obter informações sobre esses perfis, consulte [Using Service-Linked Roles in Device Farm desktop browser testing](https://docs.aws.amazon.com//devicefarm/latest/testgrid/using-service-linked-roles.html) no guia do desenvolvedor. ### Perfis de serviço O Device Farm não é compatível com perfis de serviço. Esse atributo permite que um serviço assuma um [perfil de serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role) em seu nome. O perfil permite que o serviço acesse recursos em outros serviços para concluir uma ação em seu nome. Os perfis de serviço aparecem em sua conta do IAM e são de propriedade da conta. Isso significa que um administrador do IAM pode alterar as permissões para esse perfil. Porém, fazer isso pode alterar a funcionalidade do serviço. ## Gerenciar o acesso usando políticas Você controla o acesso AWS criando políticas e anexando-as a AWS identidades ou recursos. Uma política define permissões quando associada a uma identidade ou recurso. AWS avalia essas políticas quando um diretor faz uma solicitação. A maioria das políticas é armazenada AWS como documentos JSON. Para ter mais informações sobre documentos de política JSON, consulte [Visão geral das políticas JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) no *Guia do usuário do IAM*. Por meio de políticas, os administradores especificam quem tem acesso a que, definindo qual **entidade principal** pode realizar **ações** em quais **recursos** e sob quais **condições**. Por padrão, usuários e perfis não têm permissões. Um administrador do IAM cria políticas do IAM e as adiciona aos perfis, os quais os usuários podem então assumir. As políticas do IAM definem permissões, independentemente do método usado para realizar a operação. ### Políticas baseadas em identidade As políticas baseadas em identidade são documentos de políticas de permissão JSON que você anexa a uma identidade (usuário, grupo ou perfil). Essas políticas controlam quais ações as identidades podem realizar, em quais recursos e sob quais condições. Para saber como criar uma política baseada em identidade, consulte [Definir permissões personalizadas do IAM com as políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*. As políticas baseadas em identidade podem ser políticas *em linha* (incorporadas diretamente em uma única identidade) ou *políticas gerenciadas* (políticas autônomas anexadas a várias identidades). Para saber como escolher entre uma política gerenciada e políticas em linha, consulte [Escolher entre políticas gerenciadas e políticas em linha](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) no *Guia do usuário do IAM*. A tabela a seguir descreve as políticas gerenciadas pela AWS do Device Farm. | Alteração | Descrição | Data | | --- | --- | --- | | [AWSDeviceFarmFullAccess](https://console.aws.amazon.com/iam/home?region=us-east-1#/policies/arn:aws:iam::aws:policy/AWSDeviceFarmFullAccess$jsonEditor) | Fornece acesso total a todas as operações do AWS Device Farm. | 15 de julho de 2015 | | [AWSServiceRoleForDeviceFarmTestGrid](https://docs.aws.amazon.com//devicefarm/latest/testgrid/using-service-linked-roles.html) | Permite que o Device Farm acesse recursos da AWS em seu nome. | 20 de maio de 2021 | ### Outros tipos de política AWS oferece suporte a tipos de políticas adicionais que podem definir o máximo de permissões concedidas por tipos de políticas mais comuns: + **Limites de permissões**: definem o número máximo de permissões que uma política baseada em identidade pode conceder a uma entidade do IAM. Para saber mais sobre limites de permissões, consulte [Limites de permissões para identidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) no *Guia do usuário do IAM*. + **Políticas de controle de serviço (SCPs)** — Especifique as permissões máximas para uma organização ou unidade organizacional em AWS Organizations. Para saber mais, consulte [Políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) no *Guia do usuário do AWS Organizations *. + **Políticas de controle de recursos (RCPs)** — Defina o máximo de permissões disponíveis para recursos em suas contas. Para obter mais informações, consulte [Políticas de controle de recursos (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) no *Guia AWS Organizations do usuário*. + **Políticas de sessão**: políticas avançadas transmitidas como um parâmetro durante a criação de uma sessão temporária para um perfil ou um usuário federado. Para saber mais, consulte [Políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) no *Guia do usuário do IAM*. ### Vários tipos de política Quando vários tipos de política são aplicáveis a uma solicitação, é mais complicado compreender as permissões resultantes. Para saber como AWS determinar se uma solicitação deve ser permitida quando vários tipos de políticas estão envolvidos, consulte [Lógica de avaliação de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) no *Guia do usuário do IAM*. # Exemplos de políticas baseadas em identidade do AWS Device Farm Por padrão, os perfis e usuários do IAM não têm permissão para criar ou modificar recursos do Device Farm. Eles também não podem realizar tarefas usando a AWS API Console de gerenciamento da AWS AWS CLI, ou. Um administrador do IAM deve criar políticas do IAM que concedam aos usuários e perfis permissão para executarem operações de API específicas nos recursos especificados de que precisam. O administrador deve anexar essas políticas aos usuários ou grupos do IAM que exigem essas permissões. Para saber como criar uma política baseada em identidade do IAM usando esses exemplos de documentos de política JSON, consulte [Criar políticas na guia JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) no *Guia do usuário do IAM*. **Topics** + [ ## Práticas recomendadas de política ](#security_iam_service-with-iam-policy-best-practices) + [ ## Permitir que os usuários visualizem suas próprias permissões ](#security_iam_id-based-policy-examples-view-own-permissions) + [ ## Acesso a um projeto de teste de navegador de desktop do Device Farm ](#security_iam_id-based-policy-examples-access-one-project) + [ ## Visualizando projetos de teste do navegador de desktop Device Farm com base em tags ](#security_iam_id-based-policy-examples-view-project-tags) ## Práticas recomendadas de política As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do Device Farm em sua conta. Essas ações podem incorrer em custos para sua Conta da AWS. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações: + **Comece com as políticas AWS gerenciadas e avance para as permissões de privilégios mínimos — Para começar a conceder permissões** aos seus usuários e cargas de trabalho, use as *políticas AWS gerenciadas* que concedem permissões para muitos casos de uso comuns. Eles estão disponíveis no seu Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo AWS cliente que sejam específicas para seus casos de uso. Para saber mais, consulte [Políticas gerenciadas pela AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [Políticas gerenciadas pela AWS para funções de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) no *Guia do usuário do IAM*. + **Aplique permissões de privilégio mínimo**: ao definir permissões com as políticas do IAM, conceda apenas as permissões necessárias para executar uma tarefa. Você faz isso definindo as ações que podem ser executadas em recursos específicos sob condições específicas, também conhecidas como *permissões de privilégio mínimo*. Para saber mais sobre como usar o IAM para aplicar permissões, consulte [Políticas e permissões no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*. + **Use condições nas políticas do IAM para restringir ainda mais o acesso**: é possível adicionar uma condição às políticas para limitar o acesso a ações e recursos. Por exemplo, é possível escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usando SSL. Você também pode usar condições para conceder acesso às ações de serviço se elas forem usadas por meio de uma ação específica AWS service (Serviço da AWS), como CloudFormation. Para saber mais, consulte [Elementos da política JSON do IAM: condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) no *Guia do usuário do IAM*. + **Use o IAM Access Analyzer para validar suas políticas do IAM a fim de garantir permissões seguras e funcionais**: o IAM Access Analyzer valida as políticas novas e existentes para que elas sigam a linguagem de política do IAM (JSON) e as práticas recomendadas do IAM. O IAM Access Analyzer oferece mais de cem verificações de política e recomendações práticas para ajudar a criar políticas seguras e funcionais. Para saber mais, consulte [Validação de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) no *Guia do Usuário do IAM*. + **Exigir autenticação multifator (MFA**) — Se você tiver um cenário que exija usuários do IAM ou um usuário root, ative Conta da AWS a MFA para obter segurança adicional. Para exigir MFA quando as operações de API forem chamadas, adicione condições de MFA às suas políticas. Para saber mais, consulte [Configuração de acesso à API protegido por MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) no *Guia do Usuário do IAM*. Para saber mais sobre as práticas recomendadas do IAM, consulte [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) no *Guia do usuário do IAM*. ## Permitir que os usuários visualizem suas próprias permissões Este exemplo mostra como criar uma política que permita que os usuários do IAM visualizem as políticas gerenciadas e em linha anexadas a sua identidade de usuário. Essa política inclui permissões para concluir essa ação no console ou programaticamente usando a API AWS CLI ou 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": "*" } ] } ``` ## Acesso a um projeto de teste de navegador de desktop do Device Farm Neste exemplo, você deseja conceder a um usuário do IAM em sua AWS conta acesso a um dos seus projetos de teste do navegador de desktop Device Farm,. `arn:aws:devicefarm:us-west-2:111122223333:testgrid-project:123e4567-e89b-12d3-a456-426655441111` Você deseja que a conta seja capaz de ver itens relacionados ao projeto. Além do endpoint `devicefarm:GetTestGridProject`, a conta deve ter os endpoints `devicefarm:ListTestGridSessionArtifacts` `devicefarm:ListTestGridSessions`, `devicefarm:GetTestGridSession` e `devicefarm:ListTestGridSessionActions`. Se estiver usando sistemas de CI, você deverá fornecer a cada executor de CI credenciais de acesso exclusivas. Por exemplo, é improvável que um sistema de CI precise de mais permissões do que `devicefarm:ScheduleRun` ou `devicefarm:CreateUpload`. A política de IAM a seguir descreve uma política mínima para permitir que um executor de CI inicie um teste de um novo aplicativo nativo do Device Farm criando um upload e usando-o para agendar uma execução de teste: ## Visualizando projetos de teste do navegador de desktop Device Farm com base em tags Você pode usar condições em sua política baseada em identidade para controlar o acesso aos recursos do Device Farm com base em tags. Este exemplo mostra como você pode criar uma política que permite a visualização de projetos e sessões. A permissão será concedida se a tag `Owner` do recurso solicitado corresponder ao nome de usuário da conta solicitante. É possível anexar essa política aos usuários do IAM na sua conta. Se um usuário chamado `richard-roe` tentar visualizar um projeto ou uma sessão do Device Farm, o projeto deverá ser marcado com `Owner=richard-roe` ou `owner=richard-roe`. Caso contrário, o usuário terá o acesso negado. A chave da tag de condição `Owner` corresponde a `Owner` e a `owner` porque os nomes de chaves de condição não diferenciam letras maiúsculas de minúsculas. Para obter mais informações, consulte [IAM JSON Policy Elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) (Elementos da política JSON do IAM: Condição) no *Guia do usuário do IAM*. # Solução de problemas de identidade e acesso ao AWS Device Farm Use as informações a seguir para ajudá-lo a diagnosticar e corrigir problemas comuns que você pode encontrar ao trabalhar com o Device Farm e o IAM. ## Não estou autorizado a realizar uma ação no Device Farm Se você receber uma mensagem de erro Console de gerenciamento da AWS informando que você não está autorizado a realizar uma ação, entre em contato com o administrador para obter ajuda. O administrador é a pessoa que forneceu a você o seu nome de usuário e senha. O exemplo de erro a seguir ocorre quando o usuário do IAM, `mateojackson`, tenta usar o console para visualizar detalhes sobre uma execução, mas não tem permissões `devicefarm:GetRun`. ``` 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 ``` Nesse caso, Mateo pede ao administrador para atualizar suas políticas para que ele tenha acesso ao `devicefarm:GetRun` no recurso `arn:aws:devicefarm:us-west-2:123456789101:run:123e4567-e89b-12d3-a456-426655440000/123e4567-e89b-12d3-a456-426655441111` usando a ação `devicefarm:GetRun`. ## Não estou autorizado a realizar iam: PassRole Se você receber um erro informando que não está autorizado a executar a ação `iam:PassRole`, suas políticas deverão ser atualizadas para permitir que você passe um perfil para o Device Farm. Alguns Serviços da AWS permitem que você passe uma função existente para esse serviço em vez de criar uma nova função de serviço ou uma função vinculada ao serviço. Para fazer isso, é preciso ter permissões para passar o perfil para o serviço. O exemplo de erro a seguir ocorre quando um usuário do IAM chamado `marymajor` tenta usar o console para executar uma ação no Device Farm. No entanto, a ação exige que o serviço tenha permissões concedidas por um perfil de serviço. Mary não tem permissões para passar o perfil para o serviço. ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` Nesse caso, as políticas de Mary devem ser atualizadas para permitir que ela realize a ação `iam:PassRole`. Se precisar de ajuda, entre em contato com seu AWS administrador. Seu administrador é a pessoa que forneceu suas credenciais de login. ## Quero visualizar minhas chaves de acesso Depois de criar suas chaves de acesso de usuário do IAM, é possível visualizar seu ID da chave de acesso a qualquer momento. No entanto, você não pode visualizar sua chave de acesso secreta novamente. Se você perder sua chave secreta, crie um novo par de chaves de acesso. As chaves de acesso consistem em duas partes: um ID de chave de acesso (por exemplo, `AKIAIOSFODNN7EXAMPLE`) e uma chave de acesso secreta (por exemplo, `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`). Como um nome de usuário e uma senha, você deve usar o ID da chave de acesso e a chave de acesso secreta em conjunto para autenticar suas solicitações. Gerencie suas chaves de acesso de forma tão segura quanto você gerencia seu nome de usuário e sua senha. **Importante** Não forneça as chaves de acesso a terceiros, mesmo que seja para ajudar a [encontrar o ID de usuário canônico](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId). Ao fazer isso, você pode dar a alguém acesso permanente ao seu Conta da AWS. Ao criar um par de chaves de acesso, você é solicitado a guardar o ID da chave de acesso e a chave de acesso secreta em um local seguro. A chave de acesso secreta só está disponível no momento em que é criada. Se você perder sua chave de acesso secreta, será necessário adicionar novas chaves de acesso para seu usuário do IAM. Você pode ter no máximo duas chaves de acesso. Se você já tiver duas, você deverá excluir um par de chaves para poder criar um novo. Para visualizar as instruções, consulte [Gerenciar chaves de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) no *Guia do usuário do IAM*. ## Sou um administrador e quero permitir que outras pessoas acessem o Device Farm Para permitir que outras pessoas acessem o Device Farm, você deve conceder permissão às pessoas ou aplicações que precisam de acesso. Se você estiver usando o Centro de Identidade do AWS IAM para gerenciar pessoas e aplicações, atribua conjuntos de permissões a usuários ou grupos para definir o nível de acesso. Os conjuntos de permissões criam e atribuem automaticamente políticas do IAM aos perfis do IAM associados à pessoa ou aplicação. Para ter mais informações, consulte [Conjuntos de permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) no *Guia do usuário do Centro de Identidade do AWS IAM *. Se você não estiver usando o Centro de Identidade do IAM, deverá criar entidades do IAM (usuários ou perfis) para as pessoas ou aplicações que precisam de acesso. Em seguida, você deve anexar uma política à entidade que concede a ela as permissões corretas no Device Farm. Depois que as permissões forem concedidas, forneça as credenciais ao usuário ou desenvolvedor da aplicação. Eles usarão essas credenciais para acessar AWS. Para saber mais sobre como criar grupos, políticas, permissões e usuários do IAM, consulte [Identidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) e [Políticas e permissões no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*. ## Quero permitir que pessoas fora da minha AWS conta acessem meus recursos do Device Farm É possível criar um perfil que os usuários de outras contas ou pessoas fora da organização podem usar para acessar seus recursos. É possível especificar quem é confiável para assumir o perfil. Para serviços que oferecem suporte a políticas baseadas em recursos ou listas de controle de acesso (ACLs), você pode usar essas políticas para conceder às pessoas acesso aos seus recursos. Para saber mais, consulte: + Para saber se o Device Farm é compatível com esses recursos, consulte [Como o AWS Device Farm funciona com o IAM](security_iam_service-with-iam.md). + Para saber como fornecer acesso aos seus recursos em todos os Contas da AWS que você possui, consulte Como [fornecer acesso a um usuário do IAM em outro Conta da AWS que você possui](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) no *Guia do usuário do IAM*. + Para saber como fornecer acesso aos seus recursos a terceiros Contas da AWS, consulte Como [fornecer acesso Contas da AWS a terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) no *Guia do usuário do IAM*. + Para saber como conceder acesso por meio da federação de identidades, consulte [Conceder acesso a usuários autenticados externamente (federação de identidades)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) no *Guia do usuário do IAM*. + Para conhecer a diferença entre perfis e políticas baseadas em recurso para acesso entre contas, consulte [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*. # Validação de conformidade do AWS Device Farm Auditores de terceiros avaliam a segurança e a conformidade do AWS Device Farm como parte de vários programas de conformidade da AWS. Isso inclui SOC, PCI, FedRAMP, HIPAA e outros. O AWS Device Farm não está no escopo de nenhum programa de conformidade da AWS. Para obter uma lista de serviços da AWS no escopo de programas de conformidade específicos, consulte [Serviços da AWS no escopo pelo programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/). Para obter informações gerais, consulte [Programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/). É possível fazer download de relatórios de auditoria de terceiros usando AWS Artifact. Para obter mais informações, consulte [Fazer download de relatórios no AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html). Sua responsabilidade de conformidade ao usar o Device Farm é determinada pela sensibilidade de seus dados, pelos objetivos de conformidade de sua empresa e pelas leis e regulamentações aplicáveis. A AWS fornece os seguintes recursos para ajudar na conformidade: + [Guias de início rápido de segurança e compatibilidade](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance): esses guias de implantação abordam as considerações de arquitetura e fornecem etapas para implantação de ambientes de linha de base focados em compatibilidade e segurança na AWS. + [Recursos de conformidade da AWS](https://aws.amazon.com/compliance/resources/): essa coleção de manuais e guias pode ser aplicada a seu setor e local. + [Avaliação de recursos com regras](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) no *Guia do desenvolvedor AWS Config*: AWS Config avalia a conformidade das configurações de seus recursos com práticas internas, diretrizes do setor e regulamentos. + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html): esse serviço da AWS fornece uma visão abrangente do estado da segurança na AWS que ajuda verificar a conformidade com os padrões e as práticas recomendadas de segurança do setor. # Proteção de dados em AWS Device Farm O modelo de [responsabilidade AWS compartilhada modelo](https://aws.amazon.com/compliance/shared-responsibility-model/) de se aplica à proteção de dados em AWS Device Farm (Device Farm). Conforme descrito neste modelo, AWS é responsável por proteger a infraestrutura global que executa todos os Nuvem AWS. Você é responsável por manter o controle sobre o conteúdo hospedado nessa infraestrutura. Você também é responsável pelas tarefas de configuração e gerenciamento de segurança dos Serviços da AWS que usa. Para obter mais informações sobre a privacidade de dados, consulte as [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). Para obter mais informações sobre a proteção de dados na Europa, consulte a postagem do blog [AWS Shared Responsibility Model and RGPD](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) no *Blog de segurança da AWS *. Para fins de proteção de dados, recomendamos que você proteja Conta da AWS as credenciais e configure usuários individuais com Centro de Identidade do AWS IAM ou AWS Identity and Access Management (IAM). Dessa maneira, cada usuário receberá apenas as permissões necessárias para cumprir suas obrigações de trabalho. Recomendamos também que você proteja seus dados das seguintes formas: + Use uma autenticação multifator (MFA) com cada conta. + Use SSL/TLS para se comunicar com AWS os recursos. Exigimos TLS 1.2 e recomendamos TLS 1.3. + Configure a API e o registro de atividades do usuário com AWS CloudTrail. Para obter informações sobre o uso de CloudTrail trilhas para capturar AWS atividades, consulte Como [trabalhar com CloudTrail trilhas](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) no *Guia AWS CloudTrail do usuário*. + Use soluções de AWS criptografia, juntamente com todos os controles de segurança padrão Serviços da AWS. + Use serviços gerenciados de segurança avançada, como o Amazon Macie, que ajuda a localizar e proteger dados sensíveis armazenados no Amazon S3. + Se você precisar de módulos criptográficos validados pelo FIPS 140-3 ao acessar AWS por meio de uma interface de linha de comando ou de uma API, use um endpoint FIPS. Para obter mais informações sobre os endpoints FIPS disponíveis, consulte [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/). É altamente recomendável que nunca sejam colocadas informações confidenciais ou sensíveis, como endereços de e-mail de clientes, em tags ou campos de formato livre, como um campo **Nome**. Isso inclui quando você trabalha com o Device Farm ou outro Serviços da AWS usando o console AWS CLI, a API ou AWS SDKs. Quaisquer dados inseridos em tags ou em campos de texto de formato livre usados para nomes podem ser usados para logs de faturamento ou de diagnóstico. Se você fornecer um URL para um servidor externo, recomendemos fortemente que não sejam incluídas informações de credenciais no URL para validar a solicitação a esse servidor. ## Criptografia em trânsito Os endpoints do Device Farm suportam somente HTTPS assinado (SSL/TLS) requests except where otherwise noted. All content retrieved from or placed in Amazon S3 through upload URLs is encrypted using SSL/TLS. Para obter mais informações sobre como as solicitações HTTPS são registradas AWS, consulte [Assinatura de solicitações da AWS API](https://docs.aws.amazon.com//general/latest/gr/signing_aws_api_requests.html) na Referência AWS geral. É sua responsabilidade criptografar e proteger qualquer comunicação que seus aplicativos testados façam e quaisquer aplicativos extras instalados no processo de execução de testes no dispositivo. ## Criptografia em repouso O recurso de teste do navegador de desktop do Device Farm oferece suporte à criptografia em repouso para artefatos gerados durante os testes. Os dados de teste do dispositivo móvel físico do Device Farm não são criptografados em repouso. ## Retenção de dados Os dados no Device Farm são retidos por um tempo limitado. Depois que o período de retenção expira, os dados são removidos do armazenamento de backup do Device Farm. | Tipo de conteúdo | Período de retenção (dias) | Período de retenção de metadados (dias) | | --- | --- | --- | | Aplicativos carregados | 30 | 30 | | Pacotes de teste carregados | 30 | 30 | | Logs | 400 | 400 | | Gravações de vídeo e outros artefatos | 400 | 400 | É sua responsabilidade arquivar qualquer conteúdo que você queira reter por períodos mais longos. ## Gerenciamento de dados Os dados no Device Farm são gerenciados de forma diferente, dependendo de quais recursos são usados. Esta seção explica como os dados são gerenciados durante e após o uso do Device Farm. ### Teste do navegador de desktop As instâncias usadas durante as sessões do Selenium não são salvas. Todos os dados gerados como resultado de interações do navegador são descartados quando a sessão termina. Atualmente, esse recurso oferece suporte à criptografia em repouso para artefatos gerados durante o teste. ### Teste de dispositivo físico As seções a seguir fornecem informações sobre as etapas AWS necessárias para limpar ou destruir dispositivos depois de usar o Device Farm. Os dados de teste do dispositivo móvel físico do Device Farm não são criptografados em repouso. #### Frotas de dispositivo público Após a conclusão da execução do teste, o Device Farm realiza uma série de tarefas de limpeza em cada dispositivo da frota pública de dispositivos, incluindo a desinstalação do seu aplicativo. Se não conseguirmos verificar a desinstalação do aplicativo ou qualquer uma das outras etapas de limpeza, o dispositivo receberá uma redefinição de fábrica antes de ser recolocado em uso. **nota** Em alguns casos, é possível que os dados persistam entre as sessões, especialmente se você usar o sistema do dispositivo fora do contexto do seu aplicativo. Por esse motivo, e como o Device Farm captura vídeos e logs de atividades que ocorrem durante o uso de cada dispositivo, recomendamos que você não insira informações confidenciais (por exemplo, conta do Google ou ID da Apple), informações pessoais e outros detalhes sensíveis à segurança durante o teste automatizado e as sessões de acesso remoto. #### Dispositivos privados Após a expiração ou o encerramento do contrato de dispositivos privados, o dispositivo é removido do uso e destruído de maneira segura de acordo com políticas de destruição da AWS. Para obter mais informações, consulte [Dispositivos privados no AWS Device Farm](working-with-private-devices.md). ## Gerenciamento de chaves Atualmente, o Device Farm não oferece nenhum gerenciamento de chaves externas para criptografia de dados, em repouso ou em trânsito. ## Privacidade do tráfego entre redes O Device Farm pode ser configurado, apenas para dispositivos privados, para usar os endpoints da Amazon VPC para se conectar aos seus recursos na AWS. O acesso a qualquer AWS infraestrutura não pública associada à sua conta (por exemplo, EC2 instâncias da Amazon sem um endereço IP público) deve usar um endpoint Amazon VPC. Independentemente da configuração do endpoint da VPC, o Device Farm isola seu tráfego de outros usuários em toda a rede do Device Farm. Não é garantido que suas conexões fora da AWS rede sejam seguras ou protegidas, e é sua responsabilidade proteger todas as conexões de internet que seus aplicativos fizerem. # Resiliência no AWS Device Farm A infraestrutura global da AWS é criada com base em regiões da AWS e zonas de disponibilidade. As regiões da AWS As regiões fornecem várias zonas de disponibilidade separadas e isoladas fisicamente, conectadas com baixa latência, throughput elevado e redes altamente redundantes. Com as zonas de disponibilidade, é possível projetar e operar aplicações e bancos de dados que automaticamente executam o failover entre as zonas sem interrupção. As zonas de disponibilidade são altamente disponíveis, tolerantes a falhas e escaláveis que uma ou várias infraestruturas de data center tradicionais. Para obter mais informações sobre regiões e zonas de disponibilidade da AWS, consulte [Infraestrutura global da AWS](https://aws.amazon.com/about-aws/global-infrastructure/). Como o Device Farm está disponível somente na região `us-west-2`, é altamente recomendável que você implemente processos de backup e recuperação. O Device Farm não deve ser a única fonte de qualquer conteúdo enviado. O Device Farm não oferece garantias quanto à disponibilidade de dispositivos públicos. Esses dispositivos são inseridos e retirados do grupo de dispositivos públicos dependendo de diversos fatores, como a taxa de falhas e o status de quarentena. Não recomendamos que você dependa da disponibilidade de nenhum dispositivo do grupo de dispositivos públicos. # Segurança da infraestrutura em AWS Device Farm Como serviço gerenciado, AWS Device Farm é protegido pela segurança de rede AWS global. Para obter informações sobre serviços AWS de segurança e como AWS proteger a infraestrutura, consulte [AWS Cloud Security](https://aws.amazon.com/security/). Para projetar seu AWS ambiente usando as melhores práticas de segurança de infraestrutura, consulte [Proteção](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) de infraestrutura no *Security Pillar AWS Well‐Architected* Framework. Você usa chamadas de API AWS publicadas para acessar o Device Farm pela rede. Os clientes devem oferecer compatibilidade com: + Transport Layer Security (TLS). Exigimos TLS 1.2 e recomendamos TLS 1.3. + Conjuntos de criptografia com perfect forward secrecy (PFS) como DHE (Ephemeral Diffie-Hellman) ou ECDHE (Ephemeral Elliptic Curve Diffie-Hellman). A maioria dos sistemas modernos, como Java 7 e versões posteriores, comporta esses modos. Além disso, as solicitações devem ser assinadas usando um ID da chave de acesso e uma chave de acesso secreta associada a uma entidade principal do IAM. Ou é possível usar o [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) para gerar credenciais de segurança temporárias para assinar solicitações. ## Segurança da infraestrutura para teste de dispositivos físicos Os dispositivos são fisicamente separados durante o teste de dispositivos físicos. O isolamento da rede impede a comunicação entre dispositivos por meio de redes sem fios. Os dispositivos públicos são compartilhados, e o Device Farm faz o melhor esforço para manter os dispositivos seguros ao longo do tempo. Determinadas ações, como tentativas para adquirir direitos de administrador completos em um dispositivo (uma prática referida como *enraizamento* ou *fuga*), faz com que os dispositivos públicos sejam colocados em quarentena. Eles são removidos do grupo público automaticamente e transferidos para a análise manual. Os dispositivos privados só podem ser acessados por AWS contas explicitamente autorizadas a fazer isso. O Device Farm isola fisicamente esses dispositivos de outros dispositivos e os mantém em uma rede separada. Em dispositivos gerenciados de forma privada, os testes podem ser configurados para usar um endpoint Amazon VPC para proteger conexões dentro e fora da sua conta. AWS ## Segurança da infraestrutura para teste de navegador de desktop Quando você usa o recurso de teste de navegador de desktop, todas as sessões de teste são separadas umas das outras. As instâncias do Selenium não podem se comunicar de forma cruzada sem um terceiro intermediário, externo a. AWS Todo o tráfego para os WebDriver controladores Selenium deve ser feito por meio do endpoint HTTPS gerado com. `createTestGridUrl` Você é responsável por garantir que cada instância de teste do Device Farm tenha acesso seguro aos recursos que testa. Por padrão, as instâncias de teste do navegador de desktop do Device Farm têm acesso à Internet pública. Quando você anexa sua instância a uma VPC, ela se comporta como qualquer outra instância do EC2, com acesso aos recursos determinados pela configuração da VPC e os respectivos componentes de rede associados. A AWS fornece [grupos de segurança](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-security-groups.html) e [listas de controle de acesso (ACLs) de rede](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html) para aumentar a segurança em sua VPC. Os grupos de segurança controlam o tráfego de entrada e saída de seus recursos, e a rede ACLs controla o tráfego de entrada e saída de suas sub-redes. Os grupos de segurança fornecem controle de acesso suficiente para a maioria das sub-redes. Você pode usar a rede ACLs se quiser uma camada adicional de segurança para sua VPC. Para obter diretrizes gerais sobre as melhores práticas de segurança ao usar a Amazon VPCs, consulte [as melhores práticas de segurança](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-security-best-practices.html) para sua VPC no Guia do *usuário da Amazon Virtual Private Cloud*. # Análise e gerenciamento de vulnerabilidades de configuração no Device Farm O Device Farm permite que você execute software que não é ativamente mantido ou corrigido pelo fornecedor, como o fornecedor do sistema operacional, o fornecedor do hardware ou a operadora de telefonia. A Device Farm se esforça ao máximo para manter o software atualizado, mas não garante que qualquer versão específica do software em um dispositivo físico esteja atualizada, permitindo que softwares potencialmente vulneráveis sejam colocados em uso. Por exemplo, se um teste for realizado em um dispositivo executando o Android 4.4.2, o Device Farm não garante que o dispositivo tenha sido corrigido contra a [vulnerabilidade no Android conhecida como](https://en.wikipedia.org/wiki/Stagefright_(bug)). StageFright É responsabilidade do fornecedor (e às vezes da operadora) do dispositivo fornecer atualizações de segurança para os dispositivos. Não há garantias de que um aplicativo mal-intencionado que use essa vulnerabilidade seja capturado pela nossa quarentena automatizada. Os dispositivos privados são mantidos de acordo com seu contrato com AWS. O Device Farm se esforça ao máximo para impedir que as aplicações do cliente realizem ações como *root* ou *jailbreak*. O Device Farm remove os dispositivos que estão em quarentena do pool público até que sejam revisados manualmente. Você é responsável por manter atualizadas todas as bibliotecas ou versões de software que usar em seus testes, como wheels do Python e gemas do Ruby. O Device Farm recomenda que você atualize suas bibliotecas de teste. Esses recursos podem ajudar a manter as dependências de teste atualizadas: + Para obter informações sobre como proteger gemas Ruby, consulte [Práticas de segurança](https://guides.rubygems.org/security/) no RubyGems site. + [Para obter informações sobre o pacote de segurança usado pela Pipenv e aprovado pela Python Packaging Authority para verificar seu gráfico de dependências em busca de vulnerabilidades conhecidas, consulte Detecção de vulnerabilidades de segurança em.](https://github.com/pypa/pipenv/blob/master/docs/advanced.rst#-detection-of-security-vulnerabilities) GitHub + Para obter informações sobre o verificador de dependência Maven do Open Web Application Security Project (OWASP), consulte OWASP no site da [ DependencyCheckOWASP](https://owasp.org/www-project-dependency-check/). É importante lembrar que, mesmo que um sistema automatizado não acredite que haja problemas de segurança conhecidos, isso não significa que não haja problemas de segurança. Sempre tenha cuidado ao usar bibliotecas ou ferramentas de terceiros e verifique as assinaturas criptográficas quando possível ou razoável. # Resposta a incidentes no Device Farm O Device Farm monitora continuamente os dispositivos em busca de comportamentos que possam indicar problemas de segurança. Se AWS for informado de um caso em que os dados do cliente, como resultados de testes ou arquivos gravados em um dispositivo público, podem ser acessados por outro cliente, ele AWS entra em contato com os clientes afetados, de acordo com as políticas padrão de alerta e emissão de relatórios de incidentes usadas em todos AWS os serviços. # Registrar em log e monitorar no Device Farm Esse serviço oferece suporte AWS CloudTrail, que é um serviço que registra AWS chamadas para você Conta da AWS e entrega arquivos de log em um bucket do Amazon S3. Usando as informações coletadas por CloudTrail, você pode determinar quais solicitações foram feitas com sucesso Serviços da AWS, quem fez a solicitação, quando ela foi feita e assim por diante. Para saber mais sobre CloudTrail, inclusive como ativá-lo e encontrar seus arquivos de log, consulte o [Guia AWS CloudTrail do usuário](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/). Para obter informações sobre como usar CloudTrail com o Device Farm, consulte[Registro em log de chamadas de API do AWS Device Farm com o AWS CloudTrail](logging-using-cloudtrail.md). # Práticas recomendadas de segurança para o Device Farm O Device Farm oferece vários recursos de segurança que devem ser considerados ao desenvolver e implementar suas próprias políticas de segurança. As práticas recomendadas a seguir são diretrizes gerais e não representam uma solução completa de segurança. Como essas práticas recomendadas podem não ser adequadas ou suficientes para o seu ambiente, trate-as como considerações úteis em vez de prescrições. + Conceda a qualquer sistema de integração contínua (CI) que você usar o mínimo de privilégios possível no IAM. Considere o uso de credenciais temporárias para cada teste de sistema de CI para que, mesmo que um sistema de CI esteja comprometido, ele não possa fazer solicitações falsas. Para obter mais informações sobre credenciais temporárias, consulte o [Guia do usuário do IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerole). + Use comandos `adb` em um ambiente de teste personalizado para limpar qualquer conteúdo criado pelo aplicativo. Para obter mais informações sobre ambientes de teste personalizados, consulte [Ambiente de teste personalizado no AWS Device Farm.](custom-test-environments.md)