Selecione suas preferências de cookies

Usamos cookies essenciais e ferramentas semelhantes que são necessárias para fornecer nosso site e serviços. Usamos cookies de desempenho para coletar estatísticas anônimas, para que possamos entender como os clientes usam nosso site e fazer as devidas melhorias. Cookies essenciais não podem ser desativados, mas você pode clicar em “Personalizar” ou “Recusar” para recusar cookies de desempenho.

Se você concordar, a AWS e terceiros aprovados também usarão cookies para fornecer recursos úteis do site, lembrar suas preferências e exibir conteúdo relevante, incluindo publicidade relevante. Para aceitar ou recusar todos os cookies não essenciais, clique em “Aceitar” ou “Recusar”. Para fazer escolhas mais detalhadas, clique em “Personalizar”.

Proteção de dados no serviço de computação AWS paralela

Modo de foco
Proteção de dados no serviço de computação AWS paralela - AWS PCS

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á.

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á.

O modelo de responsabilidade AWS compartilhada O modelo se aplica à proteção de dados no Serviço de Computação AWS Paralela. Conforme descrito neste modelo, AWS é responsável por proteger a infraestrutura global que executa todos os Nuvem AWS. Você é responsável por manter o controle sobre o conteúdo hospedado nessa infraestrutura. Você também é responsável pelas tarefas de configuração e gerenciamento de segurança dos Serviços da AWS que usa. Para obter mais informações sobre a privacidade de dados, consulte as Data Privacy FAQ. Para obter mais informações sobre a proteção de dados na Europa, consulte a postagem do blog AWS Shared Responsibility Model and RGPD no Blog de segurança da AWS .

Para fins de proteção de dados, recomendamos que você proteja Conta da AWS as credenciais e configure usuários individuais com AWS IAM Identity Center ou AWS Identity and Access Management (IAM). Dessa maneira, cada usuário receberá apenas as permissões necessárias para cumprir suas obrigações de trabalho. Recomendamos também que você proteja seus dados das seguintes formas:

  • Use uma autenticação multifator (MFA) com cada conta.

  • Use SSL/TLS para se comunicar com os recursos. AWS Exigimos TLS 1.2 e recomendamos TLS 1.3.

  • Configure a API e o registro de atividades do usuário com AWS CloudTrail. Para obter informações sobre o uso de CloudTrail trilhas para capturar AWS atividades, consulte Como trabalhar com CloudTrail trilhas no Guia AWS CloudTrail do usuário.

  • Use soluções de AWS criptografia, juntamente com todos os controles de segurança padrão Serviços da AWS.

  • Use serviços gerenciados de segurança avançada, como o Amazon Macie, que ajuda a localizar e proteger dados sigilosos armazenados no Amazon S3.

  • Se você precisar de módulos criptográficos validados pelo FIPS 140-3 ao acessar AWS por meio de uma interface de linha de comando ou de uma API, use um endpoint FIPS. Para obter mais informações sobre os endpoints FIPS disponíveis, consulte Federal Information Processing Standard (FIPS) 140-3.

É altamente recomendável que nunca sejam colocadas informações confidenciais ou sigilosas, como endereços de e-mail de clientes, em tags ou campos de formato livre, como um campo Nome. Isso inclui quando você trabalha com o AWS PCS ou outro Serviços da AWS usando o console AWS CLI, a API ou AWS SDKs. Quaisquer dados inseridos em tags ou em campos de texto de formato livre usados para nomes podem ser usados para logs de faturamento ou de diagnóstico. Se você fornecer um URL para um servidor externo, recomendamos fortemente que não sejam incluídas informações de credenciais no URL para validar a solicitação a esse servidor.

Criptografia em repouso

A criptografia é ativada por padrão para dados em repouso quando você cria um cluster de Serviço de Computação AWS Paralela (AWS PCS) com a AWS Management Console AWS CLI,, API AWS PCS ou AWS SDKs. AWS O PCS usa uma AWS chave KMS própria para criptografar dados em repouso. Para obter mais informações, consulte Chaves do cliente e AWS chaves no Guia do AWS KMS desenvolvedor. Você também pode usar uma chave gerenciada pelo cliente. Para obter mais informações, consulte Política de chave KMS necessária para uso com volumes criptografados do EBS no PCS AWS.

O segredo do cluster é armazenado AWS Secrets Manager e criptografado com a chave KMS gerenciada pelo Secrets Manager. Para obter mais informações, consulte Trabalhando com segredos de cluster no AWS PCS.

Em um cluster AWS PCS, os seguintes dados estão em repouso:

  • Estado do agendador — inclui dados sobre trabalhos em execução e nós provisionados no cluster. Esses são os dados nos quais o Slurm persiste, StateSaveLocation conforme definido em seu. slurm.conf Para obter mais informações, consulte a descrição StateSaveLocationna documentação do Slurm. AWS O PCS exclui os dados do trabalho após a conclusão do trabalho.

  • Segredo de autenticação do agendador — O AWS PCS o usa para autenticar todas as comunicações do agendador no cluster.

Para obter informações sobre o estado do agendador, o AWS PCS criptografa automaticamente os dados e os metadados antes de gravá-los no sistema de arquivos. O sistema de arquivos criptografados usa o algoritmo de criptografia AES-256 padrão do setor para dados em repouso.

Criptografia em trânsito

Suas conexões com a API AWS PCS usam criptografia TLS com o processo de assinatura Signature Version 4, independentemente de você usar o AWS Command Line Interface (AWS CLI) ou AWS SDKs. Para obter mais informações, consulte Assinatura de solicitações de AWS API no Guia AWS Identity and Access Management do usuário. AWS gerencia o controle de acesso por meio da API com as políticas do IAM para as credenciais de segurança que você usa para se conectar.

AWS O PCS usa TLS para se conectar a outros AWS serviços.

Em um cluster do Slurm, o agendador é configurado com o plug-in de autenticação que fornece auth/slurm autenticação para todas as comunicações do agendador. O Slurm não fornece criptografia no nível do aplicativo para suas comunicações. Todos os dados que fluem pelas instâncias do cluster permanecem locais na VPC e, portanto, estão sujeitos à criptografia da EC2 VPC se essas instâncias oferecerem suporte à criptografia em trânsito. Para obter mais informações, consulte Criptografia em trânsito no Guia do usuário do Amazon Elastic Compute Cloud. A comunicação é criptografada entre o controlador (provisionado em uma conta de serviço) e os nós do cluster em sua conta.

Gerenciamento de chaves

AWS O PCS usa uma AWS chave KMS própria para criptografar dados. Para obter mais informações, consulte Chaves do cliente e AWS chaves no Guia do AWS KMS desenvolvedor. Você também pode usar uma chave gerenciada pelo cliente. Para obter mais informações, consulte Política de chave KMS necessária para uso com volumes criptografados do EBS no PCS AWS.

O segredo do cluster é armazenado AWS Secrets Manager e criptografado com a chave KMS gerenciada pelo Secrets Manager. Para obter mais informações, consulte Trabalhando com segredos de cluster no AWS PCS.

Privacidade do tráfego entre redes

AWS Os recursos de computação do PCS para um cluster residem em 1 VPC na conta do cliente. Portanto, todo o tráfego interno do serviço AWS PCS em um cluster permanece na AWS rede e não viaja pela Internet. A comunicação entre o usuário e os nós AWS PCS pode viajar pela Internet e recomendamos o uso de SSH ou Systems Manager para conectar-se aos nós. Para obter mais informações, consulte O que é AWS Systems Manager? no Guia do AWS Systems Manager usuário.

Você também pode usar as seguintes ofertas para conectar sua rede local a: AWS

Você acessa a API AWS PCS para realizar tarefas administrativas para o serviço. Você e seus usuários acessam as portas do endpoint do Slurm para interagir diretamente com o agendador.

Criptografia do tráfego da API

Para acessar a API AWS PCS, os clientes devem oferecer suporte ao Transport Layer Security (TLS) 1.2 ou posterior. Exigimos TLS 1.2 e recomendamos TLS 1.3. Os clientes também devem ter suporte a pacotes de criptografia com sigilo de encaminhamento perfeito (PFS) como Ephemeral Diffie-Hellman (DHE) ou Ephemeral Elliptic Curve Diffie-Hellman (ECDHE). A maioria dos sistemas modernos, como Java 7 e versões posteriores, comporta esses modos. Além disso, as solicitações devem ser assinadas usando um ID da chave de acesso e uma chave de acesso secreta associada a uma entidade principal do IAM. Você também pode usar AWS Security Token Service (AWS STS) para gerar credenciais de segurança temporárias para assinar solicitações.

Criptografia do tráfego de dados

A criptografia de dados em trânsito é habilitada a partir de EC2 instâncias compatíveis que acessam o endpoint do agendador e entre ComputeNodeGroup instâncias de dentro do. Nuvem AWS Para obter mais informações, consulte Criptografia em trânsito.

PrivacidadeTermos do sitePreferências de cookies
© 2025, Amazon Web Services, Inc. ou suas afiliadas. Todos os direitos reservados.