# Proteção de dados no Amazon API Gateway
O [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) da AWS se aplica à proteção de dados no Amazon API Gateway. Conforme descrito nesse modelo, a AWS é responsável por proteger a infraestrutura global que executa toda a Nuvem AWS. Você é responsável por manter o controle sobre seu 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 [Perguntas Frequentes sobre Privacidade de Dados.](https://aws.amazon.com/compliance/data-privacy-faq/). Para obter mais informações sobre a proteção de dados na Europa, consulte a postagem do blog [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) no *Blog de segurança da AWS*.
Para fins de proteção de dados, recomendamos que você proteja as credenciais da Conta da AWS e configure as contas de usuário individuais com Centro de Identidade do AWS IAM ou AWS Identity and Access Management (IAM). Dessa maneira, cada usuário receberá apenas as permissões necessárias para cumprir suas obrigações de trabalho. Recomendamos também que você proteja seus dados das seguintes formas:
+ Use uma autenticação multifator (MFA) com cada conta.
+ Use SSL/TLS para se comunicar com os recursos da AWS. Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Configure a API e atividade do usuário logando com AWS CloudTrail. Para obter mais informações sobre como usar as trilhas do CloudTrail para capturar atividades da AWS, consulte [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) no *Guia do Usuário do AWS CloudTrail*.
+ Use as soluções de criptografia AWS, juntamente com todos os controles de segurança padrão em 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 a AWS por meio de uma interface de linha de comando ou uma API, use um endpoint do FIPS. Para obter mais informações sobre os endpoints FIPS disponíveis, consulte [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
É altamente recomendável que nunca sejam colocadas informações de identificação confidenciais, como endereços de e-mail dos seus clientes, em marcações ou campos de formato livre, como um campo **Nome**. Isso inclui quando você trabalha com o API Gateway ou outros Serviços da AWS usando o console, a API, a AWS CLI ou os AWS SDKs. Quaisquer dados inseridos em tags ou campos de texto de formato livre usados para nomes podem ser usados para logs de faturamento ou de diagnóstico. Se você fornecer um URL para um servidor externo, recomendemos fortemente que não sejam incluídas informações de credenciais no URL para validar a solicitação a esse servidor.
# Criptografia de dados no Amazon API Gateway
Proteção de dados refere-se à proteção de dados em trânsito (à medida que são transferidos para e do API Gateway) e em repouso (enquanto estão armazenados na AWS).
## Criptografia de dados em repouso no Amazon API Gateway
Se você optar por habilitar o armazenamento em cache para uma API REST, poderá habilitar a criptografia de cache. Para saber mais, consulte [Configurações de cache para APIs REST no API Gateway](api-gateway-caching.md).
Consulte mais informações sobre proteção de dados na publicação do blog [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) no *Blog de segurança da AWS*.
### Criptografia e decodificação da chave privada do seu certificado
Quando você cria um nome de domínio personalizado para APIs privadas, seu certificado do ACM e chave privada são criptografados usando uma chave do KMS gerenciada pela AWS que tem o alias **aws/acm**. Você pode ver o ID da chave com esse alias no console do AWS KMS, **Chaves gerenciadas pela AWS**.
O API Gateway não acessa diretamente seus recursos do ACM. Ele usa o AWS TLS Connection Manager para proteger e acessar as chaves privadas do seu certificado. Quando você usa seu certificado do ACM para criar um nome de domínio personalizado do API Gateway para APIs privadas, o API Gateway associa seu certificado ao AWS TLS Connection Manager. Isso é feito criando uma concessão no AWS KMS em relação à sua chave gerenciada pela AWS com o prefixo **aws/acm**. Uma concessão é um instrumento de política que permite que o TLS Connection Manager usem chaves do KMS em operações de criptografia. A concessão permite que a entidade principal autorizada (TLS Connection Manager) chame as operações de concessão especificadas na chave do KMS para decifrar a chave privada do seu certificado. Em seguida, o TLS Connection Manager usa o certificado e a chave privada descriptografada (texto simples) para estabelecer uma conexão segura (sessão SSL/TLS) com clientes de serviços do API Gateway. Quando o certificado é desassociado de um nome de domínio personalizado do API Gateway para APIs privadas, a concessão é removida.
Se você quiser remover o acesso à chave do KMS, recomendamos substituir ou excluir o certificado do serviço usando o Console de gerenciamento da AWS ou o comando `update-service` na AWS CLI.
### Contexto de criptografia para o API Gateway
[Contexto de criptografia](https://docs.aws.amazon.com/kms/latest/developerguide/encrypt_context.html) é um conjunto opcional de pares de chave/valor que pode conter mais informações contextuais sobre o possível uso da chave privada. O AWS KMS vincula o contexto de criptografia aos dados criptografados e usa dados adicionais autenticados para permitir criptografia autenticada.
Quando suas chaves TLS são usadas com o API Gateway e o TLS Connection Manager, o nome do serviço API Gateway é incluído no contexto de criptografia usado para criptografar sua chave em repouso. A fim de verificar para qual nome de domínio personalizado do API Gateway seu certificado e sua chave privada estão sendo usados, visualize o contexto de criptografia em seus logs do CloudTrail, conforme apresentado na próxima seção, ou examine a guia **Recursos associados** no console do ACM.
Para descriptografar os dados, o mesmo contexto de criptografia é incluído na solicitação. O API Gateway usa o mesmo contexto de criptografia em todas as operações criptográficas do AWS KMS, no qual a chave é `aws:apigateway:arn` e o valor é o nome do recurso da Amazon (ARN) do recurso `PrivateDomainName` do API Gateway.
O seguinte exemplo mostra o contexto de criptografia na saída de uma operação como `CreateGrant`:
```
"constraints": {
"encryptionContextEquals": {
"aws:acm:arn": "arn:aws:acm:us-west-2:859412291086:certificate/9177097a-f0ae-4be1-93b1-19f911ea4f88",
"aws:apigateway:arn": "arn:aws:apigateway:us-west-2:859412291086:/domainnames/denytest-part1.pdx.sahig.people.aws.dev+cbaeumzjhg"
}
},
"operations": [
"Decrypt"
],
"granteePrincipal": "tlsconnectionmanager.amazonaws.com"
```
## Criptografia de dados em trânsito no Amazon API Gateway
As APIs criadas com o Amazon API Gateway expõem apenas endpoints HTTPS. O API Gateway não é compatível com endpoints não criptografados (HTTP).
O API Gateway gerencia os certificados dos endpoints `execute-api` padrão. Ao configurar um nome de domínio personalizado, [você especifica o certificado para o nome de domínio](how-to-custom-domains.md#custom-domain-names-certificates). Como prática recomendada, não [fixe certificados](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-pinning.html).
Para obter maior segurança, é possível escolher uma versão mínima do protocolo TLS (Transport Layer Security) a ser aplicada ao seu domínio personalizado do API Gateway. As APIs WebSocket e HTTP são compatíveis apenas com TLS 1.2. Para saber mais, consulte [Escolher uma política de segurança para o domínio personalizado no API Gateway](apigateway-custom-domain-tls-version.md).
Também é possível configurar uma distribuição do Amazon CloudFront com um certificado SSL personalizado em sua conta e usá-la com APIs regionais. Depois, você pode configurar a política de segurança para a distribuição do CloudFront com TLS 1.1 ou superior com base nos seus requisitos de segurança e conformidade.
Para obter mais informações sobre proteção de dados, consulte [Proteger as APIs REST no API Gateway](rest-api-protect.md) e a publicação do blog [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) no *Blog de segurança da AWS*.
# Privacidade do tráfego entre redes
Usando o Amazon API Gateway, é possível criar APIs REST privadas que podem ser acessadas somente a partir da Amazon Virtual Private Cloud (VPC). A VPC usa um [VPC endpoint de interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html), que é uma interface de rede de endpoint criada na VPC. Com as [políticas de recursos](apigateway-private-api-create.md#apigateway-private-api-set-up-resource-policy), você pode permitir ou negar o acesso à sua API de alguns VPCs e VPC endpoints, incluindo nas contas da AWS. Cada endpoint pode ser usado para acessar várias APIs privadas. Você também pode usar o Direct Connect para estabelecer uma conexão a partir de uma rede local para a VPC da Amazon e acessar sua API privada nessa conexão. O tráfego para a API privada sempre usa conexões seguras e não deixa a rede da Amazon; ele é isolado da Internet pública. Para saber mais, consulte [APIs REST privadas no API Gateway](apigateway-private-apis.md).