Machine-to-machine gerenciamento de identidade

Machine-to-machine A autenticação (M2M) permite que serviços e aplicativos executados na AWS se comuniquem com segurança entre si para acessar recursos e dados. Em vez de usar credenciais estáticas de longo prazo, os sistemas de autenticação de máquinas emitem credenciais ou tokens temporários para identificar máquinas confiáveis. Eles permitem um controle preciso sobre quais máquinas podem acessar partes específicas do ambiente sem intervenção humana. A autenticação de máquina bem projetada ajuda a melhorar sua postura de segurança, limitando a ampla exposição de credenciais, permitindo a revogação dinâmica de permissões e simplificando a rotação de credenciais. Os métodos típicos de autenticação de máquinas incluem perfis de EC2 instância, a concessão de credenciais do cliente Amazon Cognito, conexões TLS mutuamente autenticadas (mTLS) e IAM Roles Anywhere. Esta seção fornece orientação sobre a implementação de fluxos de autenticação M2M seguros e escaláveis na AWS.

EC2 perfis de instância

Para cenários em que você tem um aplicativo ou serviço em execução na Amazon Elastic Compute Cloud (Amazon EC2) que precisa chamar a AWS APIs, considere usar perfis de EC2 instância. Os perfis de instância permitem que aplicativos executados em EC2 instâncias acessem com segurança outros serviços da AWS sem exigir chaves de acesso do IAM estáticas e de longa duração. Em vez disso, você deve atribuir uma função do IAM à sua instância para fornecer as permissões necessárias por meio do perfil da instância. A EC2 instância pode então obter automaticamente credenciais de segurança temporárias do perfil da instância para acessar outros serviços da AWS. 

O diagrama a seguir ilustra esse cenário.

1. Um aplicativo na EC2 instância que precisa chamar uma API da AWS recupera as credenciais de segurança fornecidas pela função do item de metadados da instância. iam/security-credentials/<role-name> 

2. O aplicativo recebe oAccessKeyId,SecretAccessKey, e um token secreto que pode ser usado para assinar solicitações de API da AWS.

3. O aplicativo chama uma API da AWS. Se a função permitir a ação da API, a solicitação será bem-sucedida.

Para saber mais sobre o uso de credenciais temporárias com recursos da AWS, consulte Como usar credenciais temporárias com recursos da AWS na documentação do IAM.

Benefícios

• Segurança aprimorada. Esse método evita a distribuição de credenciais de longo prazo para EC2 as instâncias. As credenciais são fornecidas temporariamente por meio do perfil da instância. 

• Fácil integração. Os aplicativos executados na instância podem obter credenciais automaticamente sem qualquer codificação ou configuração adicional. A AWS usa SDKs automaticamente as credenciais do perfil da instância.

• Permissões dinâmicas. Você pode alterar as permissões que estão disponíveis para a instância atualizando a função do IAM atribuída ao perfil da instância. Novas credenciais que refletem as permissões atualizadas são obtidas automaticamente. 

• Rotação. A AWS alterna automaticamente as credenciais temporárias para reduzir o risco de credenciais comprometidas. 

• Revogação. Você pode revogar as credenciais imediatamente removendo a atribuição de função do perfil da instância.

Considerações sobre design

• Uma EC2 instância pode ter somente um perfil de instância anexado.

• Use papéis do IAM com privilégios mínimos. Atribua somente as permissões que seu aplicativo exige à função do IAM para o perfil da instância. Comece com permissões mínimas e adicione mais permissões posteriormente, se necessário. 

• Use as condições do IAM na política de funções para restringir as permissões com base em tags, intervalos de endereços IP, hora do dia e assim por diante. Isso limita os serviços e recursos que o aplicativo pode acessar.

• Considere quantos perfis de instância você precisa. Todos os aplicativos executados em uma EC2 instância compartilham o mesmo perfil e têm as mesmas permissões da AWS. Você pode aplicar o mesmo perfil de instância a várias EC2 instâncias para reduzir a sobrecarga administrativa reutilizando perfis de instância quando apropriado.

• Monitore a atividade. Use ferramentas como CloudTrail a AWS para monitorar chamadas de API que usam as credenciais do perfil da instância. Fique atento a atividades incomuns que possam indicar credenciais comprometidas. 

• Exclua credenciais desnecessárias. Remova as atribuições de função dos perfis de instância não utilizados para evitar o uso de credenciais. Você pode usar o consultor de acesso do IAM para identificar funções não utilizadas. 

• Use a PassRole permissão para restringir qual função um usuário pode passar para uma EC2 instância ao iniciar a instância. Isso impede que o usuário execute aplicativos que tenham mais permissões do que as concedidas ao usuário.

• Se sua arquitetura abrange várias contas da AWS, considere como as EC2 instâncias em uma conta podem precisar acessar recursos em outra conta. Use funções entre contas de forma adequada para garantir acesso seguro sem precisar incorporar credenciais de segurança de longo prazo da AWS.

• Para gerenciar perfis de instância em grande escala, você pode usar uma dessas opções:

  • Use os runbooks do AWS Systems Manager Automation para automatizar a associação de perfis de instância às EC2 instâncias. Isso pode ser feito no momento da inicialização ou após a execução de uma instância.

  • Use CloudFormation a AWS para aplicar perfis de instância às EC2 instâncias de forma programática no momento da criação, em vez de configurá-los por meio do console da AWS.

• É uma boa prática usar VPC endpoints para se conectar de forma privada a serviços compatíveis da AWS, como Amazon S3 e Amazon DynamoDB, a partir de aplicativos executados em instâncias. EC2 

Concessão de credenciais de cliente do Amazon Cognito

O Amazon Cognito é um serviço gerenciado de gerenciamento de identidade e acesso de clientes. O Amazon Cognito fornece fluxos OAuth de autenticação compatíveis, incluindo a capacidade de autenticar máquinas ou aplicativos em vez de usuários por meio do tipo de concessão de credenciais do cliente. Essa concessão permite que um aplicativo recupere diretamente credenciais temporárias da AWS para acessar os serviços da AWS. As credenciais do cliente Amazon Cognito são uma forma segura de fornecer permissões da AWS para aplicativos sem interação humana com o usuário. Os aplicativos apresentam o ID do cliente e o segredo do cliente ao endpoint do token Amazon Cognito. Em troca, eles recebem um token de acesso, que podem ser usados para autenticar solicitações subsequentes a vários recursos e serviços. O escopo desse acesso é determinado pelas permissões associadas à ID do cliente. O aplicativo que recebe a solicitação deve validar o token verificando sua assinatura, data e hora de expiração e público. Após essas verificações, o aplicativo verifica se a ação solicitada é permitida validando as declarações no token.

O diagrama a seguir ilustra esse método.

1. O aplicativo (App Client) que deseja solicitar recursos de um servidor (Servidor de Recursos) solicita um token do Amazon Cognito.

2. Os grupos de usuários do Amazon Cognito retornam um token de acesso.

3. O App Client envia uma solicitação ao Resource Server e inclui o token de acesso.

4. O Resource Server valida o token com o Amazon Cognito.

5. Se a validação for bem-sucedida e a ação solicitada for permitida, o Servidor de Recursos responderá com o recurso solicitado.

Benefícios

• Autenticação da máquina. Esse método não requer contexto ou logins do usuário. O aplicativo se autentica diretamente com tokens.

• Credenciais de curto prazo. Os aplicativos podem obter um token de acesso primeiro do Amazon Cognito e depois usar o token de acesso com limite de tempo para acessar dados do servidor de recursos.

• OAuth2 apoio. Esse método reduz as inconsistências e ajuda no desenvolvimento de aplicativos porque segue o padrão estabelecido OAuth2 .

• Segurança aprimorada. O uso da concessão de credenciais do cliente fornece segurança aprimorada, porque o ID e o segredo do cliente não são transferidos para o servidor de recursos, ao contrário de um mecanismo de autorização de chave de API. O ID e o segredo do cliente são compartilhados e usados somente ao fazer chamadas para o Amazon Cognito para obter tokens de acesso com limite de tempo.

• Controle de acesso refinado por meio de escopos. O aplicativo pode definir e solicitar escopos e declarações adicionais para limitar o acesso somente a recursos específicos.

• Trilha de auditoria. Você pode usar as informações coletadas pelo CloudTrail para determinar a solicitação que foi feita ao Amazon Cognito, o endereço IP a partir do qual a solicitação foi feita, quem fez a solicitação, quando ela foi feita e detalhes adicionais. 

Considerações sobre design

• Defina e restrinja cuidadosamente o escopo de acesso de cada ID de cliente ao mínimo necessário. Escopos restritos ajudam a reduzir possíveis vulnerabilidades e garantem que os serviços tenham acesso somente aos recursos necessários. 

• Proteja clientes IDs e segredos usando serviços de armazenamento seguro, como o AWS Secrets Manager, para armazenar credenciais. Não verifique as credenciais no código-fonte.

• Monitore e audite as solicitações e o uso de tokens com ferramentas como CloudTrail CloudWatch e. Fique atento a padrões de atividade inesperados que possam indicar problemas. 

• Automatize a rotação de segredos de clientes regularmente. A cada rotação, crie um novo cliente de aplicativo, exclua o cliente antigo e atualize o ID e o segredo do cliente. Facilite essas rotações sem interromper as comunicações do serviço. 

• Imponha limites de taxa nas solicitações de terminais de token para ajudar a evitar abusos e ataques de negação de serviço (DoS). 

• Tenha uma estratégia pronta para revogar tokens no caso de uma violação de segurança. Embora os tokens tenham vida curta, os tokens comprometidos devem ser invalidados imediatamente.

• Use CloudFormation a AWS para criar programaticamente grupos de usuários do Amazon Cognito e clientes de aplicativos que representam as máquinas que precisam se autenticar em outros serviços.

• Quando apropriado, armazene tokens em cache para fornecer eficiência de desempenho e otimização de custos.

• Certifique-se de que a expiração dos tokens de acesso esteja alinhada com a postura de segurança da sua organização.

• Se você usa um servidor de recursos personalizado, sempre verifique o token de acesso para garantir que a assinatura seja válida, que o token não tenha expirado e que os escopos corretos estejam presentes. Verifique todas as reivindicações adicionais conforme necessário.

• Para gerenciar as credenciais do cliente em grande escala, você pode usar uma das seguintes opções:

  • Centralize o gerenciamento de todas as credenciais do cliente em uma única instância centralizada do Amazon Cognito. Isso pode reduzir a sobrecarga de gerenciamento de várias instâncias do Amazon Cognito e simplificar a configuração e a auditoria. No entanto, certifique-se de planejar a escala e considerar as cotas do serviço Amazon Cognito.

  • Federe a responsabilidade pelas credenciais do cliente para carregar contas e permitir várias instâncias do Amazon Cognito. Essa opção promove flexibilidade, mas pode aumentar a sobrecarga e a complexidade geral em comparação com a opção centralizada.

Conexões mTLS

A autenticação TLS mútua (mTLS) é um mecanismo que permite que o cliente e o servidor se autentiquem um ao outro antes de se comunicarem usando certificados com TLS. Os casos de uso comuns do mTLS incluem setores com altas regulamentações, aplicativos de Internet das Coisas (IoT) business-to-business e aplicativos (B2B). Atualmente, o Amazon API Gateway oferece suporte ao mTLS, além das opções de autorização existentes. Você pode ativar o mTLS em domínios personalizados para autenticação em REST e HTTP regionais. APIs As solicitações podem ser autorizadas usando Bearer, JSON Web Tokens (JWTs) ou assinar solicitações com autorização baseada em IAM. 

O diagrama a seguir mostra o fluxo de autenticação do mTLS para um aplicativo que está sendo executado em uma EC2 instância e uma API configurada no Amazon API Gateway.

1. O API Gateway solicita um certificado publicamente confiável diretamente do AWS Certificate Manager (ACM).

2. O ACM gera o certificado de sua autoridade de certificação (CA).

3. O cliente que chama a API apresenta um certificado com a solicitação da API.

4. O API Gateway verifica o bucket de armazenamento confiável do Amazon S3 que você criou. Esse bucket contém os certificados X.509 nos quais você confia para acessar sua API. Para que o API Gateway continue com a solicitação, o emissor do certificado e toda a cadeia de confiança até o certificado CA raiz devem estar em seu repositório confiável.

5. Se o certificado dos clientes for confiável, o API Gateway aprova a solicitação e chama o método.

6. A ação de API associada (nesse caso, uma função do AWS Lambda) processa a solicitação e retorna uma resposta que é enviada ao solicitante.

Benefícios

• Autenticação M2M. Os serviços se autenticam diretamente em vez de usar segredos ou tokens compartilhados. Isso elimina a necessidade de armazenar e gerenciar credenciais estáticas.

• Proteção contra adulteração. A criptografia TLS protege os dados em trânsito entre os serviços. As comunicações não podem ser lidas ou alteradas por terceiros. 

• Fácil integração. O suporte ao mTLS é incorporado às principais linguagens e estruturas de programação. Os serviços podem habilitar o mTLS com o mínimo de alterações de código. 

• Permissões granulares. Os serviços confiam somente em certificados específicos, o que permite um controle refinado sobre os chamadores permitidos. 

• Revogação. Os certificados comprometidos podem ser revogados imediatamente para que não sejam mais confiáveis, impedindo novos acessos. 

Considerações sobre design

• Quando você usa o API Gateway:

  • Por padrão, os clientes podem chamar sua API usando o execute-api endpoint que o API Gateway gera para sua API. Para garantir que os clientes possam acessar sua API somente usando um nome de domínio personalizado com mTLS, desative esse endpoint padrão. Para saber mais, consulte Desabilitar o endpoint padrão para uma API REST na documentação do API Gateway.

  • O API Gateway não verifica se os certificados foram revogados.

  • Para configurar o mTLS para uma API REST, você deve usar um nome de domínio regional personalizado para sua API, com uma versão mínima de TLS 1.2. O mTLS não é compatível com o modo privado. APIs

• Você pode emitir certificados para o API Gateway de sua própria CA ou importá-los da AWS Private Certificate Authority.

• Crie processos para emitir, distribuir, renovar e revogar certificados de serviço com segurança. Automatize a emissão e a renovação sempre que possível. Se um lado da sua comunicação M2M for um gateway de API, você poderá se integrar à CA privada da AWS.

• Proteja o acesso à CA privada. Comprometer a CA compromete a confiança em todos os certificados emitidos.

• Armazene as chaves privadas de forma segura e separada dos certificados. Gire as teclas periodicamente para limitar o impacto em caso de comprometimento.

• Revogue os certificados imediatamente quando eles não forem mais necessários ou estiverem comprometidos. Distribua listas de revogação de certificados aos serviços. 

• Sempre que possível, emita certificados destinados apenas a finalidades ou recursos específicos para limitar sua utilidade se estiverem comprometidos.

• Tenha planos de contingência para expirações e interrupções de certificados da CA ou da infraestrutura da lista de revogação de certificados (CRL). 

• Monitore seu sistema em busca de falhas e interrupções nos certificados. Fique atento a picos de falhas que possam indicar problemas.

• Se você estiver usando o AWS Certificate Manager (ACM) com a CA privada da AWS, você pode usar CloudFormation a AWS para solicitar certificados públicos e privados de forma programática.

• Se você estiver usando o ACM, use o AWS Resource Access Manager (AWS RAM) para compartilhar o certificado de uma conta de segurança com a conta de carga de trabalho.

IAM Roles Anywhere

Recomendamos que você use o IAM Roles Anywhere para gerenciamento de identidade M2M quando máquinas ou sistemas precisam se conectar aos serviços da AWS, mas não oferecem suporte às funções do IAM. O IAM Roles Anywhere é uma extensão do IAM que usa infraestrutura de chave pública (PKI) para conceder acesso às cargas de trabalho usando credenciais de segurança temporárias. Você pode usar certificados X.509, que podem ser emitidos por meio de uma CA ou pela CA privada da AWS, para estabelecer uma âncora de confiança entre as funções da CA e do IAM Anywhere. Assim como acontece com as funções do IAM, a carga de trabalho pode acessar os serviços da AWS com base em sua política de permissão, que está anexada à função. 

O diagrama a seguir mostra como você pode usar o IAM Roles Anywhere para conectar a AWS a recursos externos.

1. Você cria uma âncora de confiança para estabelecer confiança entre sua conta da AWS e a CA que emite certificados para suas cargas de trabalho locais. Os certificados são emitidos por uma CA que você registra como âncora de confiança (raiz da confiança) no IAM Roles Anywhere. A CA pode fazer parte do seu sistema de infraestrutura de chave pública (PKI) existente ou pode ser uma CA criada por você com a Autoridade de Certificação Privada da AWS e gerenciada com o ACM. Neste exemplo, estamos usando o ACM.

2. Seu aplicativo faz uma solicitação de autenticação para o IAM Roles Anywhere e envia sua chave pública (codificada em um certificado) e uma assinatura assinada pela chave privada correspondente. Seu aplicativo também especifica a função a ser assumida na solicitação.

3. Quando o IAM Roles Anywhere recebe a solicitação, ele primeiro valida a assinatura com a chave pública e depois valida se o certificado foi emitido por uma âncora confiável. Depois que as duas validações forem bem-sucedidas, seu aplicativo será autenticado e o IAM Roles Anywhere cria uma nova sessão de função para a função especificada na solicitação chamando o AWS Security Token Service (AWS STS).

4. Você usa a ferramenta auxiliar de credenciais fornecida pelo IAM Roles Anywhere para gerenciar o processo de criação de uma assinatura com o certificado e chamar o endpoint para obter as credenciais da sessão. A ferramenta retorna as credenciais para o processo de chamada em um formato JSON padrão.

5. Ao usar esse modelo de confiança interligado entre IAM e PKI, as cargas de trabalho locais usam essas credenciais temporárias (chave de acesso, chave secreta e token de sessão) para assumir a função do IAM de interagir com os recursos da AWS sem precisar de credenciais de longo prazo. Você também pode configurar essas credenciais usando a AWS CLI ou a AWS. SDKs

Benefícios

• Sem credenciais permanentes. Os aplicativos não precisam de chaves de acesso de longo prazo da AWS com permissões amplas. 

• Acesso refinado. As políticas determinam qual função do IAM pode ser assumida para uma entidade específica. 

• Funções sensíveis ao contexto. A função pode ser personalizada com base nos detalhes da entidade autenticada.

• Revogação. A revogação das permissões de confiança impede imediatamente que uma entidade assuma uma função.

Considerações sobre design

• Os servidores devem ser capazes de oferecer suporte à autenticação baseada em certificados. 

• É uma boa prática bloquear a política de confiança para usar aws:SourceArn ou aws:SourceAccount para a conta em que a âncora de confiança foi configurada. 

• As etiquetas principais são transferidas dos detalhes do certificado. Isso inclui o nome comum (CN), o nome alternativo do sujeito (SAN), o assunto e o emissor.

• Se você estiver usando o ACM, use a AWS RAM para compartilhar o certificado de uma conta de segurança com a conta de carga de trabalho.

• Use as permissões do sistema de arquivos do sistema operacional (OS) para restringir o acesso de leitura ao usuário proprietário.

• Nunca coloque as chaves no controle de origem. Armazene-os separadamente do código-fonte para reduzir o risco de incluí-los acidentalmente em um conjunto de alterações. Se possível, considere usar um mecanismo de armazenamento seguro.

• Verifique se você tem um processo para alternar e revogar certificados.