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 e permissões
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Cada um de seus usuários deve ter AWS as credenciais apropriadas para acessar os AWS recursos da sua conta. A forma recomendada de fornecer credenciais aos usuários é com [AWS Identity and Access Management](https://docs.aws.amazon.com/iam/)(IAM). OpsWorks O Stacks se integra ao IAM para permitir que você controle o seguinte:
+ Como usuários individuais podem interagir com o OpsWorks Stacks.
Por exemplo, você pode permitir que alguns usuários implantem aplicativos em qualquer pilha, mas não modifiquem a pilha em si, e, ao mesmo tempo, conceder acesso total a outros usuários, mas apenas a determinadas pilhas, e assim por diante.
+ Como OpsWorks as pilhas podem agir em seu nome para acessar recursos da pilha, como EC2 instâncias da Amazon e buckets do Amazon S3.
OpsWorks O Stacks fornece uma função de serviço que concede permissões para essas tarefas.
+ Como os aplicativos executados em EC2 instâncias da Amazon controladas pelo OpsWorks Stacks podem acessar outros AWS recursos, como dados armazenados em buckets do Amazon S3.
Você pode atribuir um perfil de instância às instâncias de uma camada que concede permissões aos aplicativos em execução nessas instâncias para acessar outros AWS recursos.
+ Como gerenciar chaves SSH com base em usuários e usar o SSH ou o RDP para se conectar a instâncias.
Para cada pilha, os usuários administrativos podem atribuir a cada usuário do uma chave SSH pessoal ou autorizar que usuários especifiquem a própria chave. Você também pode autorizar o acesso a SSH ou RDP e privilégios de administrador ou sudo nas instâncias da pilha para cada usuário.
Outros aspectos de segurança incluem o seguinte:
+ Como gerenciar a atualização do sistema operacional das instâncias com os patches de segurança mais recentes.
Para obter mais informações, consulte [Gerenciamento de atualizações de segurança](workingsecurity-updates.md).
+ Como configurar [grupos de EC2 segurança da Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) para controlar o tráfego de rede de e para suas instâncias.
Como especificar grupos de segurança personalizados em vez dos grupos de segurança padrão do OpsWorks Stacks. Para obter mais informações, consulte [Usar grupos de segurança](workingsecurity-groups.md).
**Topics**
+ [Gerenciando permissões OpsWorks de usuário do Stacks](opsworks-security-users.md)
+ [Permitindo que OpsWorks as pilhas ajam em seu nome](opsworks-security-servicerole.md)
+ [Prevenção confusa entre serviços em Stacks OpsWorks](cross-service-confused-deputy-prevention-stacks.md)
+ [Especificação de permissões para aplicativos executados em instâncias EC2](opsworks-security-appsrole.md)
+ [Gerenciamento do acesso por SSH](security-ssh-access.md)
+ [Gerenciamento de atualizações de segurança do Linux](workingsecurity-updates.md)
+ [Usar grupos de segurança](workingsecurity-groups.md)
# Gerenciando permissões OpsWorks de usuário do Stacks
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Como prática recomendada, restrinja os usuários do OpsWorks Stacks a um conjunto específico de ações ou a um conjunto de recursos do stack. Você pode controlar as permissões de usuário do OpsWorks Stacks de duas maneiras: usando a página de **permissões** do OpsWorks Stacks e aplicando uma política apropriada do IAM.
*A página OpsWorks **Permissões**, ou as ações equivalentes da CLI ou da API, permite que você controle as permissões do usuário em um ambiente multiusuário por pilha, atribuindo a cada usuário um dos vários níveis de permissão.* Cada nível concede permissões para um conjunto padrão de ações para um determinado recurso de pilha. Usando página **Permissions**, você pode controlar o seguinte:
+ Quem pode acessar cada pilha.
+ Quais ações cada usuário tem permissão para executar em cada pilha.
Por exemplo, você pode permitir que alguns usuários apenas visualizem a pilha, enquanto outros podem implantar aplicativos, adicionar instâncias e assim por diante.
+ Quem pode gerenciar cada pilha.
A gestão de cada pilha pode ser delegada para um ou mais usuários determinados.
+ Quem tem acesso SSH em nível de usuário e privilégios sudo (Linux) ou acesso RDP e privilégios de administrador (Windows) nas instâncias Amazon de cada pilha. EC2
Você pode conceder ou remover essas permissões separadamente para cada usuário a qualquer momento.
**Importante**
Negar o SSH/RDP acesso não impede necessariamente que o usuário faça login nas instâncias. Se você especificar um par de EC2 chaves da Amazon para uma instância, qualquer usuário com a chave privada correspondente poderá fazer login ou usar a chave para recuperar a senha de administrador do Windows. Para obter mais informações, consulte [Gerenciamento do acesso por SSH](security-ssh-access.md).
Você pode usar a CLI, a API ou o [console do IAM](https://console.aws.amazon.com/iam) para adicionar políticas aos seus usuários que concedem permissões explícitas para os diversos recursos e ações do OpsWorks Stacks.
+ Usar uma política do IAM para especificar as permissões é mais flexível do que usar os níveis de permissões.
+ Você pode configurar [identidades do IAM (usuários, grupos de usuários e perfis)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html), que concedem permissões às identidades do IAM, como usuários e grupos de usuários, ou definir [perfis](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que podem ser associadas a usuários federados.
+ Uma política do IAM é a única maneira de conceder permissões para determinadas ações-chave do OpsWorks Stacks.
Por exemplo, você deve usar o IAM para conceder permissões para `opsworks:CreateStack` e `opsworks:CloneStack`, que são usados para criar e clonar pilhas, respectivamente.
Embora não seja explicitamente possível importar usuários federados no console, um usuário federado pode criar implicitamente um perfil de usuário escolhendo **Minhas configurações** no canto superior direito do console OpsWorks Stacks e, em seguida, escolhendo **Usuários**, também no canto superior direito. Na página **Usuários**, os usuários federados, cujas contas foram criadas usando a API ou CLI, ou implicitamente por meio do console, podem gerenciar suas contas de maneira similar aos usuários não federados.
As duas abordagens não são mutuamente exclusivas e, às vezes, é útil combiná-las; o OpsWorks Stacks, portanto, avalia os dois conjuntos de permissões. Por exemplo, suponha que você queira permitir aos usuários adicionar ou excluir instâncias, mas não adicionar ou excluir camadas. Nenhum dos níveis de permissão do OpsWorks Stacks concede esse conjunto específico de permissões. No entanto, você pode usar a página **Permissões** para conceder aos usuários um nível de permissão **Gerenciar**, o que lhes permite executar a maioria das operações de pilha e, em seguida, aplicar uma política do IAM que nega permissões para adicionar ou remover camadas. Para obter mais informações, consulte [Controlar o acesso a recursos da AWS usando políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html).
O seguinte é um modelo típico para o gerenciamento de permissões de usuários. Em cada caso, o leitor (você) é considerado um usuário administrativo.
1. Use o [console do IAM](https://console.aws.amazon.com/iam) para aplicar AWSOpsWorks\$1FullAccess políticas a um ou mais usuários administrativos.
1. Crie um usuário do para cada usuário não administrativo com uma política que não garanta nenhuma permissão do OpsWorks Stacks.
Se um usuário precisar acessar somente OpsWorks as pilhas, talvez você nem precise aplicar uma política. Em vez disso, você pode gerenciar suas permissões com a página **Permissões** de OpsWorks pilhas.
1. Use a página OpsWorks Stacks **Users** para importar os usuários não administrativos para OpsWorks o Stacks.
1. Para cada pilha, use a página **Permissions** da pilha para atribuir um nível de permissão a cada usuário.
1. Conforme necessário, personalize os níveis de permissão dos usuários aplicando uma política do IAM adequadamente configurada.
Para obter mais recomendações sobre o gerenciamento de usuários, consulte [Melhores práticas: Gerenciamento de permissões](best-practices-permissions.md).
Para obter mais informações 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*.
**Topics**
+ [Gerenciando OpsWorks usuários do Stacks](opsworks-security-users-manage.md)
+ [Concedendo permissões por OpsWorks pilha aos usuários do Stacks](opsworks-security-users-console.md)
+ [Gerenciando permissões de OpsWorks pilhas anexando uma política do IAM](opsworks-security-users-policy.md)
+ [Exemplo de políticas](opsworks-security-users-examples.md)
+ [OpsWorks Níveis de permissões de pilhas](opsworks-security-users-standard.md)
# Gerenciando OpsWorks usuários do Stacks
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Antes de importar usuários para o OpsWorks Stacks e conceder permissões a eles, primeiro você precisa criar um usuário para cada indivíduo. Para criar usuários do IAM, comece fazendo login AWS como um usuário que recebeu as permissões definidas na política de IAMFull acesso. Em seguida, você usa o console do [IAM para criar usuários do IAM](opsworks-security-users-create-user.md) para todos que precisam acessar o OpsWorks Stacks. Em seguida, você pode importar esses usuários para o OpsWorks Stacks e conceder permissões de usuário da seguinte forma:
**Usuários regulares OpsWorks do Stacks**
Os usuários regulares não exigem uma política anexada. Se eles tiverem uma, ela normalmente não inclui nenhuma permissão do OpsWorks Stacks. Em vez disso, use a página **Permissões** de OpsWorks pilhas para atribuir um dos seguintes níveis de permissão a usuários comuns em uma stack-by-stack base.
+ As permissões **Show** permitem que os usuários visualizem a pilha, mas não executem nenhuma operação.
+ As permissões **Deploy** incluem as permissões **Show** e também permitem que os usuários implementem e atualizem aplicativos.
+ As permissões de **gerenciamento** incluem as permissões de **implantação** e também permitem que os usuários realizem operações de gerenciamento de pilhas, como adicionar camadas ou instâncias, usar a página **Permissões para definir permissões** de usuário e habilitar seus próprios privilégios SSH/RDP e de sudo/admin.
+ As permissões **Deny** negam acesso à pilha.
Se esses níveis de permissões não forem exatamente o que você deseja para um determinado usuário, você pode personalizar as permissões do usuário anexando uma política do IAM. Por exemplo, talvez você queira usar a página **Permissões** de OpsWorks pilhas para atribuir o nível de **gerenciamento** de permissões a um usuário, o que lhe concede permissões para realizar todas as operações de gerenciamento de pilhas, mas não para criar ou clonar pilhas. Em seguida, você poderia aplicar uma política que restringe essas permissões, negando a ele a permissão para adicionar ou excluir camadas, ou que aumenta essas permissões, permitindo que ele crie ou clone pilhas. Para obter mais informações, consulte [Gerenciando permissões de OpsWorks pilhas anexando uma política do IAMAnexação de uma política do IAM](opsworks-security-users-policy.md).
**OpsWorks Usuários administrativos do Stacks**
Os usuários administrativos são o proprietário da conta ou um usuário do IAM com as permissões definidas pela [AWSOpsWorks\$1FullAccess política](opsworks-security-users-examples.md#opsworks-security-users-examples-admin). Além das permissões concedidas a usuários **Manage**, essa política inclui permissões para ações que não podem ser concedidas por meio da página **Permissions**, tais como o seguinte:
+ Importação de usuários para o Stacks OpsWorks
+ Criação e clonagem de pilhas
Para a política completa, consulte [Exemplo de políticas](opsworks-security-users-examples.md). Para obter uma lista detalhada de permissões que podem ser concedidas a usuários apenas aplicando uma política do IAM, consulte [OpsWorks Níveis de permissões de pilhasNíveis de permissões](opsworks-security-users-standard.md).
**Topics**
+ [Usuários e regiões](#UsersandRegions)
+ [Criando um usuário administrativo do OpsWorks Stacks](opsworks-security-users-manage-admin.md)
+ [Criação de usuários do IAM para OpsWorks Stacks](opsworks-security-users-create-user.md)
+ [Importação de usuários para pilhas OpsWorks](opsworks-security-users-manage-import.md)
+ [Editando configurações OpsWorks do usuário do Stacks](opsworks-security-users-manage-edit.md)
## Usuários e regiões
OpsWorks Os usuários do Stacks estão disponíveis no endpoint regional em que foram criados. Você pode criar usuários em qualquer uma das seguintes regiões.
+ Região Leste dos EUA (Ohio)
+ Região Leste dos EUA (Norte da Virgínia)
+ Região Oeste dos EUA (Oregon)
+ Região Oeste dos EUA (Norte da Califórnia).
+ Região do Canadá (Central) (somente API); não disponível no Console de gerenciamento da AWS
+ Região Ásia-Pacífico (Mumbai)
+ Região Ásia-Pacífico (Singapura)
+ Região Ásia-Pacífico (Sydney)
+ Região Ásia-Pacífico (Tóquio)
+ Região Ásia-Pacífico (Seul)
+ Região Europa (Frankfurt)
+ Região Europa (Irlanda)
+ Região Europa (Londres)
+ Região Europa (Paris)
+ Região América do Sul (São Paulo)
Ao importar usuários para o OpsWorks Stacks, você os importa para um dos endpoints regionais; se quiser que um usuário esteja disponível em mais de uma região, você deve importar o usuário para essa região. Você também pode importar usuários do OpsWorks Stacks de uma região para outra; se você importar um usuário para uma região que já tenha um usuário com o mesmo nome, o usuário importado substituirá o usuário existente. Para obter mais informações sobre a importação de usuários, consulte [Importação de usuários](opsworks-security-users-manage-import.md).
# Criando um usuário administrativo do OpsWorks Stacks
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Você pode criar um usuário administrativo do OpsWorks Stacks adicionando a `AWSOpsWorks_FullAccess` política a um usuário, o que concede a esse usuário permissões de acesso total ao OpsWorks Stacks. Para obter mais informações sobre a criação de um usuário administrativo, consulte [Criar um usuário administrativo](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-set-up.html#create-an-admin).
**nota**
A AWSOpsWorks\$1FullAccess política permite que os usuários criem e gerenciem OpsWorks pilhas de pilhas, mas os usuários não podem criar uma função de serviço do IAM para a pilha; eles devem usar uma função existente. O primeiro usuário a criar uma pilha deve ter permissões do IAM adicionais, conforme descrito em [Permissões administrativas](opsworks-security-users-examples.md#opsworks-security-users-examples-admin). Quando esse usuário cria a primeira pilha, o OpsWorks Stacks cria uma função de serviço do IAM com as permissões necessárias. Portanto, qualquer usuário com permissões `opsworks:CreateStack` pode usar essa função para criar pilhas adicionais. Para obter mais informações, consulte [Permitindo que OpsWorks as pilhas ajam em seu nome](opsworks-security-servicerole.md).
Ao criar um usuário, você pode adicionar outras políticas gerenciadas pelo cliente para ajustar as permissões do usuário, conforme necessário. Por exemplo, você pode querer que um usuário administrativo seja capaz de criar ou excluir pilhas, mas não importar novos usuários. Para obter mais informações, consulte [Gerenciando permissões de OpsWorks pilhas anexando uma política do IAMAnexação de uma política do IAM](opsworks-security-users-policy.md).
Se você tiver vários usuários administrativos, em vez de definir permissões separadamente para cada usuário, poderá adicionar a AWSOpsWorks\$1FullAccess política a um grupo do IAM e adicionar os usuários a esse grupo.
Para obter informações sobre a criação de um grupo, consulte [Criando grupos de usuários no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html). Ao criar o grupo, adicione a **AWSOpsWorks\$1FullAccess**política. Você também pode adicionar a **AdministratorAccess**política, que inclui as **AWSOpsWorks\$1FullAccess**permissões.
Para obter informações sobre como adicionar permissões a um grupo existente, consulte [Anexar uma política a um grupo de usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_attach-policy.html).
# Criação de usuários do IAM para OpsWorks Stacks
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Antes de importar usuários do IAM para o OpsWorks Stacks, você precisa criá-los. Você pode fazer isso usando o [console do IAM](https://console.aws.amazon.com/iam/), a linha de comando ou a API. Para obter instruções completas, consulte [Como criar um usuário do IAM em sua AWS conta](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html).
Observe que, ao contrário dos [usuários administrativos](opsworks-security-users-manage-admin.md), você não precisa anexar uma política para definir permissões. Você pode definir permissões depois de [importar os usuários para o OpsWorks Stacks](opsworks-security-users-manage-import.md), conforme explicado em [Gerenciamento de permissões de usuário](opsworks-security-users.md).
Para obter mais informações sobre a criação de usuários e grupos do IAM, consulte [Conceitos básicos do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html).
# Importação de usuários para pilhas OpsWorks
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Usuários administrativos podem importar usuários para o OpsWorks Stacks; eles também podem importar usuários do OpsWorks Stacks de um endpoint regional para outro. Ao importar usuários para o OpsWorks Stacks, você os importa para um dos endpoints regionais do OpsWorks Stacks. Se quiser que um usuário do fique disponível em mais de uma região, você deverá importar o usuário para essa região.
Embora não seja explicitamente possível importar usuários federados no console, um usuário federado pode criar implicitamente um perfil de usuário escolhendo **Minhas configurações** no canto superior direito do console OpsWorks Stacks e, em seguida, escolhendo **Usuários**, também no canto superior direito. Na página **Usuários**, os usuários federados, cujas contas foram criadas usando a API ou CLI, ou implicitamente por meio do console, podem gerenciar suas contas de maneira similar aos usuários não federados.
**Para importar usuários para o OpsWorks Stacks**
1. Faça login no OpsWorks Stacks como usuário administrativo ou como proprietário da conta.
1. Selecione **Users** no canto superior direito para abrir a página **Users**.
![\[Página de usuários exibindo usuários de us-east-1\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/permissions_users_page.png)
1. Escolha **Importar usuários do IAM para < *region name* >** para exibir os usuários que estão disponíveis, mas que ainda não foram importados.
![\[Importar comandos na página de usuários\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/permissions_import.png)
1. Preencha a caixa de seleção **Select all** ou selecione um ou mais usuários individuais. Ao terminar, escolha **Importar para OpsWorks**.
**nota**
Depois de importar um usuário para o OpsWorks Stacks, se você usar o console do IAM ou a API para excluir o usuário da sua conta, o usuário não perderá automaticamente o acesso SSH que você concedeu por meio do OpsWorks Stacks. Você também deve excluir o usuário do OpsWorks Stacks abrindo a página **Usuários** e escolhendo **excluir** na coluna **Ações** do usuário.
**Para importar usuários do OpsWorks Stacks de uma região para outra**
OpsWorks Os usuários do Stacks estão disponíveis no endpoint regional em que foram criados. Você pode criar usuários nas regiões mostradas em [Usuários e regiões](opsworks-security-users-manage.md#UsersandRegions).
Você pode importar usuários do OpsWorks Stacks de uma região para a região para a qual sua lista de **usuários** está atualmente filtrada. Se você importar um usuário para uma região que já tem um usuário com o mesmo nome, o usuário importado substituirá o usuário existente.
1. Faça login no OpsWorks Stacks como usuário administrativo ou como proprietário da conta.
1. Selecione **Users** no canto superior direito para abrir a página **Users**. Se você tiver usuários do OpsWorks Stacks em mais de uma região, use o controle **Filtro** para filtrar a região para a qual você deseja importar usuários.
![\[Página de usuários exibindo usuários de us-east-1\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/permissions_users_page.png)
1. Escolha **Importar usuários do OpsWorks Stacks de outra região para < *current region* >**.
![\[Página de usuários exibindo usuários de us-west-2\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/permissions_import_otherregion.png)
1. Selecione a região da qual você deseja importar usuários do OpsWorks Stacks.
1. Selecione um ou mais usuários para importar ou selecione todos os usuários e, em seguida, escolha **Import to this region**. Aguarde até que OpsWorks as pilhas exibam os usuários importados na lista de **usuários**.
## Unix IDs e usuários criados fora OpsWorks de pilhas
OpsWorks atribui aos usuários em instâncias do OpsWorks Stacks valores de Unix ID (UID) entre 2000 e 4000. Como OpsWorks reserva a faixa de 2.000 a 4.000 UIDs, os usuários que você cria fora OpsWorks (usando receitas de livros de receitas ou importando usuários OpsWorks do IAM, por exemplo) podem fazer com UIDs que sejam substituídos pelo OpsWorks Stacks para outro usuário. Isso pode fazer com que os usuários que você criou fora do OpsWorks Stacks não apareçam nos resultados da pesquisa do data bag ou sejam excluídos da operação integrada `sync_remote_users` do OpsWorks Stacks.
Os processos externos também podem criar usuários com os quais o UIDs OpsWorks Stacks pode sobrescrever. Alguns pacotes de sistemas operacionais, por exemplo, podem criar um usuário como parte dos processos pós-instalação. Quando você ou um processo de software cria um usuário em um sistema operacional baseado em Linux sem especificar explicitamente um UID, que é o padrão, o UID atribuído pelo Stacks é \$1 1. OpsWorks **
Como prática recomendada, crie usuários do OpsWorks Stacks e gerencie seus acessos no console do OpsWorks Stacks ou usando um AWS SDK. AWS CLI Se você criar usuários em instâncias do OpsWorks Stacks fora da OpsWorks, use *UnixID* valores maiores que 4000.
# Editando configurações OpsWorks do usuário do Stacks
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Depois de importar os usuários, você pode editar as configurações conforme o seguinte:
**Para editar as configurações de usuário**
1. Na página **Users (Usuários)**, escolha **edit (editar)** na coluna **Actions (Ações)** do usuário.
1. Você pode especificar as seguintes configurações.
**Autogerenciamento**
Selecione **Sim** para permitir que o usuário use a MySettings página para especificar sua chave SSH pessoal.
Você também pode ativar o autogerenciamento adicionando a política do IAM à identidade do IAM que concede permissões para as [UpdateMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateMyUserProfile.html)ações [DescribeMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeMyUserProfile.html)e.
**Chave SSH pública**
(Opcional) Insira uma chave SSH pública para o usuário. Essa chave aparecerá na página **My Settings** do usuário. Se você permitir o autogerenciamento, o usuário poderá editar **My Settings** e especificar sua própria chave. Para obter mais informações, consulte [Registro de uma chave SSH pública de um usuário](security-settingsshkey.md).
OpsWorks O Stacks instala essa chave em todas as instâncias do Linux; os usuários podem usar a chave privada associada para fazer login. Para obter mais informações, consulte [Login com SSH](workinginstances-ssh.md). Você não pode usar essa chave com pilhas do Windows.
**Permissões**
(Opcional) Defina os níveis de permissões do usuário para cada pilha em um único lugar, em vez de configurá-los separadamente usando a página **Permissions** de cada pilha. Para obter mais informações sobre os níveis de permissões, consulte [Concessão de permissões por pilha](opsworks-security-users-console.md).
![\[User details page showing name, ARN, SSH settings, and permission levels for various stacks.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/permissions_edit_user.png)
# Concedendo permissões por OpsWorks pilha aos usuários do Stacks
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
A maneira mais simples de gerenciar as permissões de usuário do OpsWorks Stacks é usando a página de **Permissões** de uma pilha. Cada pilha tem sua própria página, que concede permissões para esse pilha.
Você deve estar conectado como usuário administrativo ou usuário **Manage** para modificar qualquer uma das configurações de permissões. A lista mostra somente os usuários que foram importados para o OpsWorks Stacks. Para obter informações sobre como criar e importar usuários, consulte [Gerenciamento de usuários](opsworks-security-users-manage.md).
O nível de permissão padrão é Apenas políticas do IAM, que concede aos usuários apenas as permissões que estão em sua política do IAM.
+ Quando você importa um usuário do IAM ou de outra região, o usuário é adicionado à lista para todas as pilhas existentes com um nível de permissão **Somente políticas do IAM**.
+ Por padrão, um usuário que você acabou de importar de outra região não tem acesso a pilhas na região de destino. Se você importar usuários de outra região, para permitir que eles gerenciem pilhas na região de destino, deve atribuir a eles permissões para essas pilhas depois de importá-las.
+ Quando você cria uma nova pilha, todos os usuários atuais são adicionados à lista com níveis de permissão **IAM Policies Only**.
**Topics**
+ [Configuração das permissões de um usuário](#opsworks-security-users-console-set)
+ [Visualização das suas permissões](#opsworks-security-users-console-viewing)
+ [Uso das chaves de condição do IAM para verificar credenciais temporárias](#w2ab1c14c67c15c37c21)
## Configuração das permissões de um usuário
**Para definir as permissões de um usuário**
1. No painel de navegação, selecione **Permissions (Permissões)**.
1. Na página **Permissions (Permissões)**, escolha **Edit (Editar)**.
1. Altere as configurações de **Permission level (Nível de permissão)** e **Instance access (Acesso à instância)**:
+ Use as configurações de **Permissions level** para atribuir um dos níveis de permissão padrão para cada usuário, o que determina se o usuário pode acessar essa pilha e quais ações ela pode realizar. Se um usuário tiver uma política de IAM, o OpsWorks Stacks avalia os dois conjuntos de permissões. Para ver um exemplo, consulte [Exemplo de políticas](opsworks-security-users-examples.md).
+ A configuração de **Instance access** **SSH/RDP** especifica se o usuário tem acesso SSH (Linux) ou RDP (Windows) às instâncias da pilha.
Se você autorizar o acesso **SSH/RDP**, terá a opção de selecionar **sudo/admin**, que concede ao usuário privilégios de sudo (Linux) ou administrativos (Windows) nas instâncias da pilha.
![\[Gerenciamento de usuários com a página de permissões.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/permissions-edit.png)
Você pode atribuir cada usuário a um dos seguintes níveis de permissões. Para obter uma lista das ações que são permitidas por cada nível, consulte [OpsWorks Níveis de permissões de pilhasNíveis de permissões](opsworks-security-users-standard.md).
**Negar**
O usuário não pode realizar nenhuma ação do OpsWorks Stacks na pilha, mesmo que tenha uma política do IAM que conceda às OpsWorks Stacks permissões de acesso total. Você pode usar isso, por exemplo, para negar que alguns usuários acessem pilhas de produtos não lançados.
**IAM Policies Only**
O nível padrão, que é atribuído a todos os usuários recém-importados e a todos os usuários para pilhas recém-criadas. As permissões de usuário são determinadas pela política do IAM. Se um usuário não tiver uma política de IAM ou se sua política não tiver permissões explícitas de OpsWorks pilhas, ele não poderá acessar a pilha. Os usuários administrativos costumam ser atribuídos a esse nível, pois suas políticas do IAM já concedem permissões de acesso total.
**Show (Mostrar)**
O usuário pode visualizar uma pilha, mas não pode executar nenhuma operação. Por exemplo, os gerentes podem querer monitorar as pilhas de uma conta, mas não precisariam implantar aplicativos ou modificar a pilha.
**Implante**
Inclui as permissões **Show** e também permite que o usuário implemente aplicativos. Por exemplo, um desenvolvedor de aplicativo talvez possa precisar implantar atualizações nas instâncias da pilha, mas não adicionar camadas ou instâncias à pilha.
**Gerencie**
Inclui as permissões **Deploy** e também permite que o usuário execute uma variedade de operações de gerenciamento de pilha, incluindo:
+ Adição ou exclusão de camadas e instâncias.
+ Uso da página **Permissions** da pilha para atribuir níveis de permissões a usuários.
+ Registro ou cancelamento do registro de recursos.
Por exemplo, cada pilha pode ter um gerente que é responsável por assegurar que a pilha tenha um número e um tipo apropriado de instâncias, lidar com atualizações de pacote e sistema operacional, e assim por diante.
O nível Manage não permite que os usuários criem ou clonem pilhas. Essas permissões devem ser concedidas por uma política do IAM. Para ver um exemplo, consulte [Gerencie permissões](opsworks-security-users-examples.md#opsworks-security-users-examples-manage).
Se o usuário também tiver uma política de IAM, o OpsWorks Stacks avalia os dois conjuntos de permissões. Isso permite que você atribua um nível de permissão a um usuário e, em seguida, aplique uma política para restringir ou aumentar as ações permitidas do nível. Por exemplo, você poderia aplicar uma política que permite a um usuário **Gerenciar** criar ou clonar pilhas ou que nega a esse usuário a capacidade de registrar ou cancelar o registro de recursos. Para ver alguns exemplos de tais políticas, consulte [Exemplo de políticas](opsworks-security-users-examples.md).
**nota**
Se a política do usuário permitir ações adicionais, o resultado poderá aparentar anular as configurações da página **Permissions**. Por exemplo, se um usuário tem uma política que permite a [CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html)ação, mas você usa a página **Permissões** para especificar permissões de **implantação**, o usuário ainda tem permissão para criar camadas. A exceção a essa regra é a opção **Negar**, que nega o acesso à pilha até mesmo para usuários com AWSOpsWorks\$1FullAccess políticas. Para obter mais informações, consulte [Controle do acesso aos AWS recursos usando políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html).
## Visualização das suas permissões
Se o [autogerenciamento](opsworks-security-users-manage-edit.md) estiver ativado, os usuários poderão ver um resumo dos seus níveis de permissão para cada pilha, escolhendo **My Settings** no canto superior direito. Os usuários também podem acessar **Minhas configurações** se suas políticas concederem permissões para as [UpdateMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateMyUserProfile.html)ações [DescribeMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeMyUserProfile.html)e.
## Uso das chaves de condição do IAM para verificar credenciais temporárias
OpsWorks O Stacks tem uma camada de autorização integrada que oferece suporte a casos de autorização adicionais (como o gerenciamento simplificado do acesso somente de leitura ou leitura e gravação às pilhas para usuários individuais). Essa camada de autorização se baseia no uso de credenciais temporárias. Consequentemente, você não pode usar uma condição `aws:TokenIssueTime` para verificar se os usuários estão usando credenciais de longo prazo ou bloquear ações de usuários que estão usando credenciais temporárias, como descrito em [referência a elementos da política JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_Null) na documentação do IAM.
# Gerenciando permissões de OpsWorks pilhas anexando uma política do IAM
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Você pode especificar as permissões do OpsWorks Stacks de um usuário anexando uma política do IAM. Uma política anexada é necessária para algumas permissões:
+ Permissões de usuário administrativas, como a importação de usuários.
+ Permissões para algumas ações, como a criação ou a clonagem de uma pilha.
Para obter uma lista completa de ações que exigem uma política anexada, consulte [OpsWorks Níveis de permissões de pilhasNíveis de permissões](opsworks-security-users-standard.md).
Você também pode usar uma política para personalizar os níveis de permissão que foram concedidos por meio da página **Permissões**. Esta seção fornece um breve resumo de como aplicar uma política do IAM a um usuário para especificar as permissões do OpsWorks Stacks. Para obter mais informações, consulte [Gerenciamento de acesso para AWS recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html).
Uma política do IAM é um objeto JSON que contém uma ou mais *instruções*. Cada elemento de instrução tem uma lista de permissões que tem três elementos básicos próprios:
**Ação**
As ações que a permissão afeta. Você especifica ações OpsWorks de pilhas como`opsworks:action`. Uma `Action` pode ser definida para uma ação específica, como `opsworks:CreateStack`, que especifica se o usuário tem permissão para chamar [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateStack.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateStack.html). Você também pode usar asteriscos para especificar grupos de ações. Por exemplo, `opsworks:Create*` especifica todas as ações de criação. Para ver uma lista completa das ações do OpsWorks Stacks, consulte a Referência da [OpsWorks Stacks API](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html).
**Efeito**
Se as ações especificadas são permitidas ou negadas.
**Recurso**
Os AWS recursos que a permissão afeta. OpsWorks As pilhas têm um tipo de recurso, a pilha. Para especificar permissões para um determinado recurso de pilha, defina `Resource` como o Nome de região da Amazon (ARN), que tem o seguinte formato: `arn:aws:opsworks:region:account_id:stack/stack_id/`.
Você também pode usar caracteres curinga. Por exemplo, configurar `Resource` como `*` concede permissões para todos os recurso.
Por exemplo, a seguinte política nega ao usuário a capacidade de interromper instâncias na pilha cujo ID é `2860-2f18b4cb-4de5-4429-a149-ff7da9f0d8ee`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "opsworks:StopInstance",
"Effect": "Deny",
"Resource": "arn:aws:opsworks:*:*:stack/2f18b4cb-4de5-4429-a149-ff7da9f0d8ee/"
}
]
}
```
------
Para obter informações sobre como adicionar permissões a um usuário do IAM, consulte [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console).
Para obter mais informações sobre como criar ou modificar políticas do IAM, consulte [Políticas e permissões no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html). Para ver alguns exemplos de políticas do OpsWorks Stacks, consulte[Exemplo de políticas](opsworks-security-users-examples.md).
# Exemplo de políticas
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Esta seção descreve exemplos de políticas do IAM que podem ser aplicadas aos usuários do OpsWorks Stacks.
+ [Permissões administrativas](#opsworks-security-users-examples-admin) descreve duas políticas que podem ser usadas para conceder permissões a usuários administrativos.
+ [Gerencie permissões](#opsworks-security-users-examples-manage) e [Permissões Deploy](#opsworks-security-users-examples-deploy) mostram exemplos de políticas que podem ser aplicadas a um usuário para aumentar ou restringir os níveis de permissões Manage e Deploy.
OpsWorks O Stacks determina as permissões do usuário avaliando as permissões concedidas pelas políticas do IAM, bem como as permissões concedidas pela página de **Permissões**. Para obter mais informações, consulte [Controle do acesso aos AWS recursos usando políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html). Para obter mais informações sobre as permissões da página **Permissions**, consulte [OpsWorks Níveis de permissões de pilhasNíveis de permissões](opsworks-security-users-standard.md).
## Permissões administrativas
Use o console do IAM, [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/), para acessar a AWSOpsWorks\$1FullAccess política. Anexe essa política a um usuário para conceder a ele permissões para realizar todas as ações do OpsWorks Stacks. As permissões do IAM são necessárias, entre outras coisas, para permitir que um usuário administrativo importe usuários.
Você deve criar uma [função do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que permita que o OpsWorks Stacks atue em seu nome para acessar outros AWS recursos, como EC2 instâncias da Amazon. Normalmente, você realiza essa tarefa fazendo com que um usuário administrativo crie a primeira pilha e deixe que OpsWorks as pilhas criem a função para você. Em seguida, você pode usar essa função para todos os pilhas subsequentes. Para obter mais informações, consulte [Permitindo que OpsWorks as pilhas ajam em seu nome](opsworks-security-servicerole.md).
O usuário administrativo que cria a primeira pilha deve ter permissões para algumas ações do IAM que não estão incluídas na AWSOpsWorks\$1FullAccess política. Adicione as seguintes permissões à seção `Actions` da política. Para obter uma sintaxe JSON adequada, adicione vírgulas entre as ações e remova a vírgula final no final da lista de ações.
```
"iam:PutRolePolicy",
"iam:AddRoleToInstanceProfile",
"iam:CreateInstanceProfile",
"iam:CreateRole"
```
## Gerencie permissões
O nível de permissões **Manage** permite que um usuário execute uma variedade de ações de gerenciamento de pilha, incluindo adição e exclusão de camadas. Este tópico descreve várias políticas que você pode usar para **Gerenciar** usuários para aumentar ou restringir as permissões padrão.
Negar a um usuário **Manage** a capacidade de adicionar ou excluir camadas
Você pode restringir os níveis de permissão **Gerenciar** para permitir que um usuário execute todas as ações **Gerenciar**, exceto adicionar ou excluir camadas, usando a seguinte política do IAM. Substitua *region**account\$1id*,, e *stack\$1id* por valores apropriados à sua configuração.
Permitir que um usuário **Manage** crie ou clone pilhas
O nível de permissões **Gerenciar** não permite que os usuários criem ou clonem pilhas. Você pode mudar as permissões **Gerenciar** para permitir que um usuário crie ou clone pilhas aplicando as seguintes políticas do IAM. *account\$1id*Substitua *region* e por valores apropriados à sua configuração.
Negar a um usuário Manage a capacidade de registrar ou cancelar o registro de recursos
O nível de permissões **Gerenciar** permite que o usuário [registre e cancele o registro do Amazon EBS e dos recursos de endereço IP elástico](resources-reg.md) com a pilha. Você pode restringir as permissões **Gerenciar** para permitir que o usuário execute todas as ações **Gerenciar**, exceto registrar os recursos, aplicando a política a seguir.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"opsworks:RegisterVolume",
"opsworks:RegisterElasticIp"
],
"Resource": "*"
}
]
}
```
Permitir que um usuário **Manage** importe usuários
O nível **Gerenciar** permissões não permite que os usuários importem usuários para o OpsWorks Stacks. Você pode aumentar as permissões **Gerenciar** para permitir que um usuário importe e exclua usuários aplicando a seguinte política do IAM. *account\$1id*Substitua *region* e por valores apropriados à sua configuração.
## Permissões Deploy
O nível de permissões **Deploy** não permite que os usuários criem ou excluam aplicativos. Você pode aumentar as permissões **Implantar** para permitir que um usuário crie e exclua aplicativos aplicando a seguinte política do IAM. Substitua *region**account\$1id*,, e *stack\$1id* por valores apropriados à sua configuração.
# OpsWorks Níveis de permissões de pilhas
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Esta seção lista as ações que são permitidas pelos níveis de permissões **Mostrar**, **Implantar** e **Gerenciar** na página OpsWorks Stacks **Permissions**. Ela também inclui uma lista de ações às quais você pode conceder permissões apenas aplicando uma política do IAM ao usuário.
**Show (Mostrar)**
O nível **Show** permite comandos `DescribeXYZ`, com as seguintes exceções:
```
DescribePermissions
DescribeUserProfiles
DescribeMyUserProfile
DescribeStackProvisioningParameters
```
Se um usuário administrativo permitiu o autogerenciamento para o usuário, os usuários **Show** também podem usar `DescribeMyUserProfile` e `UpdateMyUserProfile`. Para obter mais informações sobre o autogerenciamento, consulte [Edição das configurações de usuário](opsworks-security-users-manage-edit.md).
**Implante**
As ações a seguir são permitidas pelo nível **Deploy**, além das ações permitidas pelo nível **Show**.
```
CreateDeployment
UpdateApp
```
**Gerencie**
As ações a seguir são permitidas pelo nível **Manage**, além das ações permitidas pelos níveis **Deploy** e **Show**.
```
AssignInstance
AssignVolume
AssociateElasticIp
AttachElasticLoadBalancer
CreateApp
CreateInstance
CreateLayer
DeleteApp
DeleteInstance
DeleteLayer
DeleteStack
DeregisterElasticIp
DeregisterInstance
DeregisterRdsDbInstance
DeregisterVolume
DescribePermissions
DetachElasticLoadBalancer
DisassociateElasticIp
GrantAccess
GetHostnameSuggestion
RebootInstance
RegisterElasticIp
RegisterInstance
RegisterRdsDbInstance
RegisterVolume
SetLoadBasedAutoScaling
SetPermission
SetTimeBasedAutoScaling
StartInstance
StartStack
StopInstance
StopStack
UnassignVolume
UpdateElasticIp
UpdateInstance
UpdateLayer
UpdateRdsDbInstance
UpdateStack
UpdateVolume
```
**Permissões que exigem uma política do IAM**
Você deve conceder permissões para as seguintes ações aplicando uma política do IAM adequada ao usuário. Para obter alguns exemplos, consulte [Exemplo de políticas](opsworks-security-users-examples.md).
```
CloneStack
CreateStack
CreateUserProfile
DeleteUserProfile
DescribeUserProfiles
UpdateUserProfile
```
# Permitindo que OpsWorks as pilhas ajam em seu nome
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
OpsWorks O Stacks precisa interagir com uma variedade de serviços da AWS em seu nome. Por exemplo, o OpsWorks Stacks interage com EC2 a Amazon para criar instâncias e com a Amazon CloudWatch para obter estatísticas de monitoramento. Ao criar uma pilha, você especifica uma função do IAM, geralmente chamada de função de serviço, que concede às OpsWorks pilhas as permissões apropriadas.
![\[Lista de perfis do IAM na página Adicionar pilha.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/add-stack-iamrole.png)
Quando você especifica uma função de serviço nova da pilha, poderá optar por fazer o seguinte:
+ Especifique uma função de serviço padrão criada anteriormente.
Geralmente, você pode criar um serviço padrão quando cria sua primeira pilha, e então usas essa função para todos pilhas subsequentes.
+ Especifica um perfil de serviço personalizado criado usando o console IAM ou API.
Essa abordagem é útil se você quiser conceder às OpsWorks pilhas permissões mais limitadas do que a função de serviço padrão.
**nota**
Para criar sua primeira pilha, você precisa ter as permissões definidas no modelo de **AdministratorAccess**política do IAM. Essas permissões permitem que o OpsWorks Stacks crie uma nova função de serviço do IAM e permitem que você importe usuários [, conforme descrito anteriormente ](opsworks-security-users-manage-import.md). Para todas as pilhas subsequentes, os usuários podem selecionar a função de serviço criado para a primeira pilha; eles não precisam de permissões administrativas para criar uma pilha.
A função de serviço padrão oferece as seguintes permissões:
+ Execute todas as EC2 ações da Amazon (`ec2:*`).
+ Obtenha CloudWatch estatísticas (`cloudwatch:GetMetricStatistics`).
+ Use o Elastic Load Balancing para distribuir tráfego entre os servidores (`elasticloadbalancing:*`).
+ Use uma instância do Amazon RDS como um servidor de banco de dados (`rds:*`).
+ Use funções do IAM (`iam:PassRole`) para fornecer comunicação segura entre OpsWorks Stacks e suas EC2 instâncias da Amazon.
Se você criar uma função de serviço personalizada, deverá garantir que ela conceda todas as permissões que o OpsWorks Stacks precisa para gerenciar sua pilha. O exemplo de JSON a seguir é a declaração de política para a função de serviço padrão. Uma função de serviço personalizada deve incluir pelo menos as permissões a seguir na declaração de política.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:*",
"iam:PassRole",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"ecs:*",
"elasticloadbalancing:*",
"rds:*"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
]
}
```
------
Uma função de serviço também tem uma relação de confiança. As funções de serviço criadas pelo OpsWorks Stacks têm a seguinte relação de confiança.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "StsAssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "opsworks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
A função de serviço deve ter essa relação de confiança para que a OpsWorks Stacks atue em seu nome. Se você usar a função de serviço padrão, não modifique a relação de confiança. Se você estiver criando um perfil de serviço personalizado, especifique a relação de confiança fazendo uma das seguintes ações:
+ Se você estiver usando o assistente **Criar perfil** no [console do IAM](https://console.aws.amazon.com/iam/home#roles), em **Escolher um caso de uso**, escolha **Opsworks**. Esse perfil tem a relação de confiança apropriada, mas nenhuma política está implicitamente vinculada. Para conceder permissões ao OpsWorks Stacks para agir em seu nome, crie uma política gerenciada pelo cliente que contenha o seguinte, e anexe-a ao novo perfil.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarms",
"cloudwatch:GetMetricStatistics",
"ec2:*",
"ecs:*",
"elasticloadbalancing:*",
"iam:GetRolePolicy",
"iam:ListInstanceProfiles",
"iam:ListRoles",
"iam:ListUsers",
"rds:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
]
}
```
------
+ Se você estiver usando um CloudFormation modelo, poderá adicionar algo como o seguinte à seção **Recursos** do seu modelo.
```
"Resources": {
"OpsWorksServiceRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Statement": [ {
"Effect": "Allow",
"Principal": {
"Service": [ "opsworks.amazonaws.com" ]
},
"Action": [ "sts:AssumeRole" ]
} ]
},
"Path": "/",
"Policies": [ {
"PolicyName": "opsworks-service",
"PolicyDocument": {
...
} ]
}
},
}
}
```
# Prevenção confusa entre serviços em Stacks OpsWorks
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
O problema "confused deputy" é um problema de segurança em que uma entidade que não tem permissão para executar uma ação pode coagir uma entidade mais privilegiada a executar a ação. Em AWS, a falsificação de identidade entre serviços pode resultar em um problema confuso de delegado. A personificação entre serviços pode ocorrer quando um serviço (o *serviço de chamada*) chama outro serviço (o *serviço chamado*). O serviço de chamada pode ser manipulado de modo a usar suas permissões para atuar nos recursos de outro cliente de uma forma na qual ele não deveria ter permissão para acessar. Para evitar isso, a AWS fornece ferramentas que ajudam você a proteger seus dados para todos os serviços com entidades principais de serviço que receberam acesso aos recursos em sua conta.
Recomendamos usar as chaves de contexto de condição [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)global [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)e as chaves de contexto nas políticas de acesso às pilhas para limitar as permissões que o AWS OpsWorks Stacks concede a outro serviço às pilhas. Se o valor de `aws:SourceArn` não contém ID da conta, como um ARN do bucket do Amazon S3, você deve usar ambas as chaves de contexto de condição global para limitar as permissões. Se você usa ambas as chaves de contexto de condição global, e o valor `aws:SourceArn` contém o ID da conta, o valor `aws:SourceAccount` e a conta no valor `aws:SourceArn` deverão utilizar a mesma ID de conta quando na mesma declaração de política. Use `aws:SourceArn` se quiser que apenas uma pilha seja associada ao acesso entre serviços. Use `aws:SourceAccount` se quiser permitir que qualquer pilha nessa conta seja associada ao uso entre serviços.
O valor de `aws:SourceArn` deve ser o ARN de uma OpsWorks pilha.
A maneira mais eficaz de se proteger contra o problema do substituto confuso é usar a chave de contexto de condição global `aws:SourceArn` da pilha do OpsWorks Stacks com o ARN completo do recurso. Se você não souber o ARN completo ou se estiver especificando várias pilhas ARNs, use a chave de condição de contexto `aws:SourceArn` global com curingas (`*`) para as partes desconhecidas do ARN. Por exemplo, .`arn:aws:servicename:*:123456789012:*`
A seção a seguir mostra como você pode usar as chaves de contexto de condição `aws:SourceAccount` global `aws:SourceArn` e as chaves de contexto no OpsWorks Stacks para evitar o confuso problema auxiliar.
## Evite explorações confusas de delegados no Stacks OpsWorks
Esta seção descreve como você pode ajudar a evitar explorações secundárias confusas no OpsWorks Stacks e inclui exemplos de políticas de permissões que você pode anexar à função do IAM que você está usando para acessar OpsWorks o Stacks. Como prática recomendada de segurança, sugerimos adicionar as chaves de condição `aws:SourceArn` e `aws:SourceAccount` às relações de confiança que seu perfil do IAM possui com outros serviços. As relações de confiança permitem que OpsWorks as Stacks assumam a função de realizar ações em outros serviços que são necessárias para criar ou gerenciar suas pilhas de OpsWorks Stacks.
**Para editar relações de confiança para adicionar chaves de condição `aws:SourceArn` e `aws:SourceAccount`**
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação à esquerda, selecione **Perfis**.
1. Na caixa **Pesquisar**, pesquise a função que você usa para acessar OpsWorks as pilhas. A função AWS gerenciada é`aws-opsworks-service-role`.
1. Na página **Resumo** do perfil, escolha a guia **Relações de confiança**.
1. Na guia **Relacionamentos de confiança**, escolha **Editar política de confiança**.
1. Na página **Editar política de confiança**, adicione pelo menos uma das chaves de condição `aws:SourceArn` ou `aws:SourceAccount` à política. Use `aws:SourceArn` para restringir a relação de confiança entre serviços cruzados (como Amazon EC2) e OpsWorks Stacks a pilhas específicas de OpsWorks Stacks, o que é mais restritivo. Adicione `aws:SourceAccount` para restringir a relação de confiança entre serviços cruzados e OpsWorks pilhas às pilhas em uma conta específica, o que é menos restritivo. Veja um exemplo do a seguir: Observe que, se você usar as duas chaves de condição, a conta IDs deverá ser a mesma.
1. Quando terminar de adicionar as permissões à política, escolha **Atualizar política**.
Veja a seguir exemplos adicionais de funções que limitam o acesso às pilhas usando `aws:SourceArn` e `aws:SourceAccount`.
**Topics**
+ [Exemplo: acessando pilhas em uma região específica](#confused-deputy-opsworks-stacks-example1)
+ [Exemplo: adicionar mais de um ARN de pilha ao `aws:SourceArn`](#confused-deputy-opsworks-stacks-example2)
### Exemplo: acessando pilhas em uma região específica
A seguinte declaração de relação de confiança e função acessa qualquer pilha de OpsWorks Stacks na região Leste dos EUA (Ohio) (). `us-east-2` Observe que a região está especificada no valor ARN de `aws:SourceArn`, mas o valor do ID da pilha é um curinga (\$1).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "opsworks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:opsworks:us-east-2:123456789012:stack/*"
}
}
}
]
}
```
------
### Exemplo: adicionar mais de um ARN de pilha ao `aws:SourceArn`
O exemplo a seguir limita o acesso a uma matriz de duas pilhas de OpsWorks pilhas na ID da conta 123456789012.
# Especificação de permissões para aplicativos executados em instâncias EC2
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Se os aplicativos em execução nas EC2 instâncias da Amazon da sua pilha precisarem acessar outros recursos da AWS, como buckets do Amazon S3, eles devem ter as permissões apropriadas. Para outorgar essas permissões, deve-se utilizar um perfil de instância. Você pode especificar um perfil de instância para cada instância ao [criar uma pilha de OpsWorks pilhas](workingstacks-creating.md).
![\[Opção Advanced na página Add Stack.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/add-stack-instanceproflie.png)
Para especificar um perfil para instâncias de camada, [edite as configurações de camada](workinglayers-basics-edit.md).
O perfil da instância especifica uma função da IAM. Os aplicativos em execução na instância podem assumir essa função para acessar os recursos da AWS, sujeitos a permissões concedidas pela política de atribuição. Para obter mais informações sobre como um aplicativo assume uma função, consulte [Assumir a função usando uma chamada de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-assume-role.html).
Um perfil de instância pode ser criado em qualquer uma das seguintes formas:
+ Use o console de IAM ou a API para criar um perfil.
Para obter mais informações, consulte [Funções (delegação and federação)](https://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html).
+ Use um CloudFormation modelo para criar um perfil.
Para alguns exemplos de como incluir recursos de IAM em um modelo, consulte [Snippets de modelos do Identity and Access Management (IAM)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html).
Um perfil de instância deve ter uma relação de confiança e uma política anexada que conceda permissões para acessar os recursos da AWS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
O perfil da instância deve ter essa relação de confiança para que o OpsWorks Stacks atue em seu nome. Se você usar a função de serviço padrão, não modifique a relação de confiança. Se você estiver criando uma função de serviço personalizado, especifique a relação de confiança como a seguir:
+ Se você estiver usando o assistente **Create Role** no [console do IAM](https://console.aws.amazon.com/iam/home#roles), especifique o tipo de EC2 função da **Amazon** em **AWS Service Roles** na segunda página do assistente.
+ Se você estiver usando um CloudFormation modelo, poderá adicionar algo como o seguinte à seção **Recursos** do seu modelo.
```
"Resources": {
"OpsWorksEC2Role": {
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Statement": [ {
"Effect": "Allow",
"Principal": {
"Service": [ "ec2.amazonaws.com" ]
},
"Action": [ "sts:AssumeRole" ]
} ]
},
"Path": "/"
}
},
"RootInstanceProfile": {
"Type": "AWS::IAM::InstanceProfile",
"Properties": {
"Path": "/",
"Roles": [ {
"Ref": "OpsWorksEC2Role"
}
]
}
}
}
```
Quando você criar seu perfil de instância, pode-se anexar uma política apropriada para a função do perfil nesse mesmo momento. Depois de criar a pilha, use o [console do IAM](https://console.aws.amazon.com/iam/) ou a API para associar uma política apropriada à função do perfil. Por exemplo, a política a seguir concede acesso total a todos os objetos no bucket do Amazon S3 chamado amzn-s3-demo-bucket. Substitua *region* e amzn-s3-demo-bucket por valores apropriados à sua configuração.
Para obter um exemplo de como criar e usar um perfil de instância, consulte [Usar um bucket do Amazon S3](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted.walkthrough.photoapp.html).
Se seu aplicativo usa um perfil de instância para chamar a API OpsWorks Stacks a partir de uma EC2 instância, a política deve permitir a `iam:PassRole` ação, além das ações apropriadas para OpsWorks Stacks e outros serviços da AWS. A permissão `iam:PassRole` autoriza o OpsWorks Stacks; a assumir a função do serviço em seu nome. Para obter mais informações sobre a API OpsWorks Stacks, consulte [AWS OpsWorks API Reference](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html).
Veja a seguir um exemplo de uma política do IAM que permite chamar qualquer ação do OpsWorks Stacks de uma EC2 instância, bem como qualquer ação da Amazon EC2 ou do Amazon S3.
**nota**
Se você não permitir`iam:PassRole`, qualquer tentativa de chamar uma ação do OpsWorks Stacks falhará com um erro como o seguinte:
```
User: arn:aws:sts::123456789012:federated-user/Bob is not authorized
to perform: iam:PassRole on resource:
arn:aws:sts::123456789012:role/OpsWorksStackIamRole
```
Para obter mais informações sobre o uso de funções em uma EC2 instância para obter permissões, consulte [Conceder acesso aos recursos da AWS a aplicativos executados em EC2 instâncias da Amazon](https://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html) no *Guia do AWS Identity and Access Management usuário*.
# Gerenciamento do acesso por SSH
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
OpsWorks O Stacks oferece suporte a chaves SSH para pilhas Linux e Windows.
+ Em instâncias do Linux, você pode usar o SSH para fazer login em uma instância, por exemplo, para executar comandos da [CLI do agente](agent.md).
Para obter mais informações, consulte [Login com SSH](workinginstances-ssh.md).
+ Em instâncias do Windows, você pode usar uma chave SSH para obter a senha do administrador da instância, a qual você pode usar para fazer login com o RDP.
Para obter mais informações, consulte [Login com RDP](workinginstances-rdp.md).
A autenticação é baseada em um par de chaves SSH, que consiste em uma chave pública e uma chave privada:
+ Você instala a chave pública na instância.
A localização depende do sistema operacional específico, mas o OpsWorks Stacks cuida dos detalhes para você.
+ Você armazena a chave privada localmente e a passa para um cliente SSH, como o `ssh.exe`, para acessar a instância.
O cliente SSH usa a chave privada para conectar-se à instância.
Para fornecer acesso por SSH aos usuários de uma pilha, você precisa de uma maneira de criar os pares de chaves SSH, instalar as chaves públicas nas instâncias da pilha e gerenciar as chaves privadas com segurança.
EC2 A Amazon fornece uma maneira simples de instalar uma chave SSH pública em uma instância. Você pode usar o EC2 console ou a API da Amazon para criar um ou mais pares de chaves para cada região da AWS que você planeja usar. A Amazon EC2 armazena as chaves públicas na AWS e você armazena as chaves privadas localmente. Ao iniciar uma instância, você especifica um dos pares de chaves da região e a Amazon o instala EC2 automaticamente na instância. Em seguida, você pode usar a chave privada correspondente para fazer login na instância. Para obter mais informações, consulte [Amazon EC2 Key Pairs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html).
Com o OpsWorks Stacks, você pode especificar um dos pares de EC2 chaves da Amazon da região ao criar uma pilha e, opcionalmente, substituí-lo por um par de chaves diferente ao criar cada instância. Quando o OpsWorks Stacks inicia a EC2 instância correspondente da Amazon, ele especifica o par de chaves e a Amazon EC2 instala a chave pública na instância. Em seguida, você pode usar a chave privada para fazer login ou recuperar uma senha de administrador, assim como faria com uma EC2 instância padrão da Amazon. Para obter mais informações, consulte [Instalando uma Amazon EC2 Key](security-settingec2key.md).
Usar um par de EC2 chaves da Amazon é conveniente, mas tem duas limitações significativas:
+ Um par de EC2 chaves da Amazon está vinculado a uma região específica da AWS.
Se você trabalha em várias regiões, deve gerenciar vários pares de chaves.
+ Você pode instalar somente um par de EC2 chaves da Amazon em uma instância.
Se você deseja permitir que vários usuários façam login, todos eles precisam ter uma cópia da chave privada, o que não é uma prática de segurança recomendada.
Para pilhas Linux, o OpsWorks Stacks fornece uma maneira mais simples e flexível de gerenciar pares de chaves SSH.
+ Cada usuário registra um par de chaves pessoal.
Eles armazenam a chave privada localmente e registram a chave pública no OpsWorks Stacks, conforme descrito em[Registro de uma chave SSH pública de um usuário](security-settingsshkey.md).
+ Quando você define permissões de usuário para uma stack, especifica quais usuários devem ter acesso por SSH às instâncias da pilha.
OpsWorks O Stacks cria automaticamente um usuário do sistema nas instâncias da pilha para cada usuário autorizado e instala sua chave pública. O usuário pode, em seguida, usar a chave privada correspondente para fazer login, conforme descrito em [Login com SSH](workinginstances-ssh.md).
O uso de chaves SSH pessoais tem as seguintes vantagens.
+ Não há necessidade de configurar manualmente as chaves nas instâncias; o OpsWorks Stacks instala automaticamente as chaves públicas apropriadas em cada instância.
+ OpsWorks O Stacks instala somente as chaves públicas pessoais dos usuários autorizados.
Os usuários não autorizados não podem usar suas chaves privadas pessoais para obter acesso a instâncias. Com os pares de EC2 chaves da Amazon, qualquer usuário com a chave privada correspondente pode fazer login, com ou sem acesso SSH autorizado.
+ Se um usuário não precisar mais de acesso por SSH, você pode usar a página [**Permissions** para](opsworks-security-users-manage-edit.md) revogar as permissões de SSH/RDP do usuário.
OpsWorks O Stacks desinstala imediatamente a chave pública das instâncias da pilha.
+ Você pode usar a mesma chave para qualquer região da AWS.
Os usuários gerenciam apenas uma chave privada.
+ Não há necessidade de compartilhar chaves privadas.
Cada usuário tem sua própria chave privada.
+ É fácil fazer a rotação das chaves.
Você ou o usuário atualiza a chave pública em **My Settings (Minhas configurações)** e o OpsWorks Stacks atualiza automaticamente as instâncias.
# Instalando uma Amazon EC2 Key
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Ao criar uma pilha, você pode especificar uma chave EC2 SSH da Amazon que é instalada por padrão em cada instância na pilha.
![\[Lista de chaves SSH padrão na página Adicionar pilha\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/ec2_keys.png)
A lista de **chaves SSH padrão** mostra a Amazon EC2keys da sua conta da AWS. Você pode executar uma das seguintes ações:
+ Selecione a chave apropriada a partir da lista.
+ Selecione **Do not use a default SSH key** para não especificar nenhuma chave.
Se você tiver selecionado **Do not use a default SSH key**, ou se deseja substituir a chave padrão da pilha, pode especificar uma chave quando criar uma instância.
![\[Especificação de uma chave SSH\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/instance_keys.png)
Quando você inicia a instância, o OpsWorks Stacks instala a chave pública no `authorized_keys` arquivo.
# Registro de uma chave SSH pública de um usuário
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Há duas maneiras de registrar a chave SSH pública de um usuário:
+ Um usuário administrativo pode atribuir uma chave SSH pública a um ou mais usuários e fornecer-lhes a chave privada correspondente.
+ Um usuário administrativo pode habilitar o autogerenciamento para um ou mais usuários.
Esses usuários podem especificar suas próprias chaves SSH públicas.
Para obter mais informações sobre como os usuários administrativos podem habilitar o autogerenciamento ou atribuir chaves públicas a usuários, consulte [Edição das configurações de usuário](opsworks-security-users-manage-edit.md).
A conexão com instâncias baseadas em Linux usando o SSH em um terminal PuTTY requer etapas adicionais. Para obter mais informações, consulte [Conexão da sua instância Linux a partir do Windows usando PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html) e [Solução de problemas de conexão da sua instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) na documentação da AWS.
A seção a seguir descreve como um usuário com o autogerenciamento habilitado pode especificar sua chave pública.
**Para especificar sua chave SSH pública**
1. Crie um par de chaves SSH.
A abordagem mais simples é gerar o par de chaves localmente. Para obter mais informações, consulte [Como gerar sua própria chave e importá-la para a Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/generating-a-keypair.html#how-to-generate-your-own-key-and-import-it-to-aws).
**nota**
Se você usar Pu TTYgen para gerar seu par de chaves, copie a chave pública da caixa **Chave pública para colar no arquivo OpenSSH authorized\$1keys**. **Clicar em Salvar chave pública** salva a chave pública em um formato que não é suportado pelo MindTerm.
1. Faça login no console do OpsWorks Stacks como um usuário do IAM com o autogerenciamento ativado.
**Importante**
Se você fizer login como proprietário da conta ou como usuário do IAM sem autogerenciamento ativado, o OpsWorks Stacks não exibirá **Minhas** configurações. Se você é um usuário administrativo ou o proprietário da conta, pode especificar chaves SSH acessando a página **Users** e [editando as configurações do usuário](opsworks-security-users-manage-edit.md).
1. Selecione **Minhas configurações**, que exibe as configurações do usuário conectado.
![\[Link Minhas configurações no OpsWorks painel.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/permissions-mysettings-link.png)
1. Na página **My Settings**, clique em **Edit**.
![\[Botão Edit na página My Settings.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/mysettings-editbutton.png)
1. Em **Public SSH Key box**, insira sua chave pública SSH e clique em **Save**.
![\[Caixa Public SSH Key na página My Settings.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/mysettings-setsshkey.png)
**Importante**
Para usar o cliente MindTerm SSH integrado para se conectar às EC2 instâncias da Amazon, um usuário deve estar conectado como usuário do IAM e ter uma chave SSH pública registrada no Stacks. OpsWorks Para obter mais informações, consulte [Usando o cliente MindTerm SSH integrado](workinginstances-ssh-mindterm.md).
# Gerenciamento de atualizações de segurança do Linux
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
## Atualizações de segurança
Os fornecedores do sistema operacional Linux fornecem atualizações regulares, a maioria das quais são patches de segurança do sistema operacional, mas também podem incluir atualizações aos pacotes instalados. Você deve ter certeza de que os sistemas operacionais das instâncias são atuais com os patches de segurança mais recentes.
Por padrão, o OpsWorks Stacks instala automaticamente as atualizações mais recentes durante a configuração, após a conclusão da inicialização da instância. OpsWorks O Stacks não instala atualizações automaticamente depois que uma instância está on-line, para evitar interrupções, como reiniciar servidores de aplicativos. Em vez disso, você gerencia atualizações para suas instâncias online você mesmo, para que possa minimizar quaisquer interrupções.
Recomendamos que você use um dos seguintes para atualizar suas instâncias online.
+ Crie e inicie novas instâncias para substituir suas instâncias online atuais. Depois, exclua as instâncias atuais.
As novas instâncias terão o último conjunto de patches de segurança instalados durante a configuração.
+ Em instâncias baseadas em Linux no Chef 11,10 ou pilhas mais antigas, execute o comando de pilha [Atualizar dependências](workingstacks-commands.md), que instala o conjunto atual de patches de segurança e outras atualizações nas instâncias especificadas.
Para essas duas abordagens, o OpsWorks Stacks executa a atualização executando `yum update` para Amazon Linux e Red Hat Enterprise Linux (RHEL) ou `apt-get update` para Ubuntu. Cada distribuição lida com as atualizações de forma diferente, então você deveria examinar as informações nos links associados para entender exatamente como uma atualização afetará suas instâncias:
+ **Amazon Linux**: as atualizações do Amazon Linux instalam patches de segurança e também podem instalar atualizações de atributo, incluindo atualizações de pacotes.
Para obter mais informações, consulte [AMI do Amazon Linux FAQs](https://aws.amazon.com/amazon-linux-ami/faqs/#lock).
+ **Ubuntu**: as atualizações do Ubuntu são amplamente limitadas à instalação de patches de segurança, mas também podem instalar atualizações de pacotes para um número limitado de correções críticas.
Para obter mais informações, consulte [LTS - Ubuntu Wiki](https://wiki.ubuntu.com/LTS).
+ **CentOS**: as atualizações do CentOS geralmente mantêm a compatibilidade binária com versões anteriores.
+ **RHEL**: as atualizações do RHEL geralmente mantêm a compatibilidade binária com versões anteriores.
Para obter mais informações, consulte [Ciclo de vida do Red Hat Enterprise Linux](https://access.redhat.com/support/policy/updates/errata/).
Se você quiser ter mais controle sobre as atualizações, como especificar versões específicas do pacote, você pode desativar as atualizações automáticas usando as [UpdateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateLayer.html)ações [CreateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateInstance.html),, [UpdateInstance[CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html)](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateInstance.html), ou — ou os [métodos equivalentes do AWS SDK ou comandos da AWS](https://aws.amazon.com/tools/) [CLI](https://aws.amazon.com/documentation/cli/) — para definir o parâmetro como. `InstallUpdatesOnBoot` `false` Os exemplos a seguir mostram como usar o CLI da AWS para desativar `InstallUpdatesOnBoot` como configuração padrão de uma camada existente.
```
aws opsworks update-layer --layer-id layer ID --no-install-updates-on-boot
```
Depois, você deve gerenciar as atualizações você mesmo. Por exemplo, você pode empregar uma dessas estratégias:
+ Implementar uma receita personalizada que [executa o comando shell apropriado](cookbooks-101-basics-commands.md#cookbooks-101-basics-commands-script) para instalar suas atualizações preferidas.
Como as atualizações do sistema não são mapeadas naturalmente para um [evento de ciclo de vida](workingcookbook-events.md), inclua a receita em seus livros personalizados, mas [execute-a manualmente](workingcookbook-manual.md). Para atualizações de pacote, você também pode usar os recursos [yum\$1package](https://docs.chef.io/chef/resources.html#yum-package) (Amazon Linux) ou [apt\$1package](https://docs.chef.io/chef/resources.html#apt-package) (Ubuntu) em vez do comando shell.
+ [Entre em cada instância com SSH](workinginstances-ssh.md) e execute os comandos apropriados manualmente.
# Usar grupos de segurança
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
## Grupos de segurança
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Cada EC2 instância da Amazon tem um ou mais grupos de segurança associados que controlam o tráfego de rede da instância, como um firewall. Um grupo de segurança tem uma ou mais *regras*, sendo que cada uma delas especifica uma determinada categoria de permissão de tráfego. Uma regra especifica o seguinte:
+ O tipo de tráfego permitido, como SSH ou HTTP
+ O protocolo de tráfego, como TCP ou UDP
+ O intervalo de endereços IP do qual o tráfego pode ser proveniente
+ O intervalo de porta permitido do tráfego
Os grupos de segurança têm dois tipos de regras:
+ As regras de entrada regulam o tráfego de entrada da rede.
Por exemplo, as instâncias de servidor de aplicativos normalmente têm uma regra de entrada que permite a entrada de tráfego HTTP de qualquer endereço IP para a porta 80 e outra regra de entrada que permite a entrada de tráfego SSH para a porta 22 de um conjunto de endereços IP especificado.
+ As regras de saída controlam o tráfego de saída da rede.
Uma prática comum é usar a configuração padrão, que permite qualquer tráfego de saída.
Para obter mais informações sobre grupos de segurança, consulte [Amazon EC2 Security Groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html).
Na primeira vez que você cria uma pilha em uma região, o OpsWorks Stacks cria um grupo de segurança integrado para cada camada com um conjunto apropriado de regras. Todos os grupos têm regras de saída padrão que permitem todo o tráfego de saída. Em geral, as regras de entrada permitem o seguinte:
+ Tráfego TCP, UDP e ICMP de entrada das camadas apropriadas do Stacks OpsWorks
+ Tráfego de entrada TCP na porta 22 (SSH login)
**Atenção**
A configuração padrão do grupo de segurança abre o SSH (porta 22) para qualquer rede local (0.0.0.0/0). Isso permite que todos os endereços IP acessem sua instância usando o SSH. Para ambientes de produção, você deve usar uma configuração que só permite o acesso SSH de um endereço IP específico ou de um intervalo de endereços. Atualize os grupos de segurança padrão imediatamente após criá-los ou use grupos de segurança personalizados.
+ Para camadas de servidor da Web, todo tráfego de entrada TCP e UDP vai para as portas 80 (HTTP) e 443 (HTTPS)
**nota**
O grupo de segurança `AWS-OpsWorks-RDP-Server` integrado é atribuído para todas as instâncias do Windows para permitir o acesso RDP. No entanto, por padrão, ele não tem regras. Se você estiver executando uma pilha do Windows e quiser usar o RDP para acessar instâncias, deve adicionar uma regra de entrada que permita o acesso RDP. Para obter mais informações, consulte [Login com RDP](workinginstances-rdp.md).
Para ver os detalhes de cada grupo, acesse o [ EC2console da Amazon](https://console.aws.amazon.com/ec2/), selecione **Security Groups** no painel de navegação e selecione o grupo de segurança da camada apropriada. Por exemplo, **AWS- OpsWorks -Default-Server** é o grupo de segurança integrado padrão para todas as pilhas, e **AWS OpsWorks - WebApp** - é o grupo de segurança integrado padrão para a pilha de amostras do Chef 12.
**nota**
Se você excluir acidentalmente um grupo de segurança do OpsWorks Stacks, a forma preferida de recriá-lo é fazer com que o OpsWorks Stacks execute a tarefa para você. Basta criar uma nova pilha na mesma região da AWS — e na VPC, se OpsWorks presente — e o Stacks recriará automaticamente todos os grupos de segurança integrados, incluindo aquele que você excluiu. Você pode então excluir a pilha se não tiver mais uso para ela; os security groups permanecerão. Se você quer recriar o grupo de segurança manualmente, ele deve ser uma duplicata exata do original, incluindo a capitalização do nome do grupo.
Além disso, o OpsWorks Stacks tentará recriar todos os grupos de segurança integrados se alguma das seguintes situações ocorrer:
Você faz qualquer alteração na página de configurações da pilha no console OpsWorks Stacks.
Você iniciar uma das instâncias da pilha.
Você criar uma nova pilha.
Você pode usar uma das seguintes abordagens para especificar grupos de segurança. Você usa a configuração **Usar grupos de OpsWorks segurança** para especificar sua preferência ao criar uma pilha.
+ **Sim** (configuração padrão) — O OpsWorks Stacks associa automaticamente o grupo de segurança incorporado apropriado a cada camada.
Você pode ajustar um grupo de segurança integrado de uma camada adicionando um grupo de segurança personalizado nas configurações de sua preferência. No entanto, quando a Amazon EC2 avalia vários grupos de segurança, ela usa as regras menos restritivas, portanto, você não pode usar essa abordagem para especificar regras mais restritivas do que o grupo incorporado.
+ **Não** — O OpsWorks Stacks não associa grupos de segurança integrados a camadas.
Você deve criar grupos de segurança apropriados e associar pelo menos um a cada camada que criar. Use essa abordagem para especificar regras mais restritivas do que os grupos integrados. Note que ainda é possível associar um grupo de segurança integrado a uma camada se preferir. Os grupos de segurança personalizados são necessários apenas para as camadas que precisam de configurações personalizadas.
**Importante**
Se você usar os grupos de segurança integrados, não pode criar regras mais restritivas modificando as configurações do grupo manualmente. Cada vez que você cria uma pilha, o OpsWorks Stacks substitui as configurações dos grupos de segurança integrados, de modo que todas as alterações feitas serão perdidas na próxima vez que você criar uma pilha. Se uma camada exigir configurações de grupo de segurança mais restritivas do que o grupo de segurança incorporado, defina **Usar grupos de OpsWorks segurança** como **Não**, crie grupos de segurança personalizados com suas configurações preferidas e atribua-os às camadas na criação.