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á.
# Autentique-se com o AWS Secrets Manager Amazon Data Firehose
O Amazon Data Firehose se integra AWS Secrets Manager para fornecer acesso seguro aos seus segredos e automatizar a rotação de credenciais. Essa integração permite que o Firehose recupere um segredo do Secrets Manager no runtime para se conectar aos destinos de streaming mencionados anteriormente e entregar seus fluxos de dados. Com isso, seus segredos não são visíveis em texto simples durante o fluxo de trabalho de criação do stream, Console de gerenciamento da AWS nem nos parâmetros da API. Ele fornece uma prática segura para gerenciar seus segredos e dispensa você de atividades complexas de gerenciamento de credenciais, como a configuração de funções do Lambda personalizadas para gerenciar as alternâncias de senhas.
Para obter mais informações, consulte o [Guia do usuário do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide).
**Topics**
+ [Noções básicas sobre segredos](secrets-manager-whats-secret.md)
+ [Criar um segredo](secrets-manager-create.md)
+ [Uso do segredo](secrets-manager-how.md)
+ [Alternância do segredo](secrets-manager-rotate.md)
# Noções básicas sobre segredos
Um segredo pode ser uma senha, um conjunto de credenciais, como nome de usuário e senha, um OAuth token ou outras informações secretas que você armazena de forma criptografada no Secrets Manager.
Para cada destino, você deve especificar o par de valores-chave do segredo no formato JSON correto, conforme mostrado na seção a seguir. O Amazon Data Firehose não conseguirá se conectar ao seu destino se o seu segredo não tiver o formato JSON correto de acordo com o destino.
**Formato de segredo para bancos de dados como MySQL e PostgreSQL**
```
{
"username": "",
"password": ""
}
```
**Formato de segredo para o cluster provisionado do Amazon Redshift e o grupo de trabalho Amazon Redshift sem servidor**
```
{
"username": "",
"password": ""
}
```
**Formato de segredo para o Splunk**
```
{
"hec_token": ""
}
```
**Formato de segredo para o Snowflake**
```
{
"user": "",
"private_key": "", // without the beginning and ending private key, remove all spaces and newlines
"key_passphrase": "" // optional
}
```
**Formato secreto para endpoint HTTP, Coralogix, Datadog, Dynatrace, Elastic, Honeycomb, Logz.io, MongoDB Cloud e New Relic LogicMonitor**
```
{
"api_key": ""
}
```
# Criar um segredo
Para criar um segredo, siga as etapas em [Criar um AWS Secrets Manager segredo](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) no *Guia do AWS Secrets Manager usuário*.
# Uso do segredo
Recomendamos que você use AWS Secrets Manager para armazenar suas credenciais ou chaves para se conectar a destinos de streaming, como Amazon Redshift, endpoint HTTP, Snowflake, Splunk, Coralogix, Datadog, Dynatrace, Elastic, Honeycomb, Logz.io, MongoDB Cloud e New Relic. LogicMonitor
É possível configurar a autenticação com o Secrets Manager para esses destinos por meio do Console de Gerenciamento da AWS no momento da criação do fluxo do Firehose. Para obter mais informações, consulte [Definição de configurações do destino](create-destination.md). Como alternativa, você também pode usar as operações [CreateDeliveryStream](https://docs.aws.amazon.com/firehose/latest/APIReference/API_CreateDeliveryStream.html)e da [UpdateDestination](https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html)API para configurar a autenticação com o Secrets Manager.
O Firehose armazena os segredos em cache com uma criptografia e os usa em todas as conexões com os destinos. Ele atualiza o cache a cada 10 minutos para garantir que as credenciais mais recentes sejam usadas.
É possível optar por desativar a capacidade de recuperar segredos do Secrets Manager a qualquer momento durante o ciclo de vida do fluxo. Se você não quiser usar o Secrets Manager para recuperar segredos, você pode usar a chave de API username/password ou em vez disso.
**nota**
Embora não haja custo adicional para esse atributo no Firehose, você será cobrado pelo acesso e pela manutenção do Secrets Manager. Para obter mais informações, consulte a página de definição de preços do [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing/).
## Concessão de acesso ao Firehose para recuperar o segredo
Para que o Firehose recupere um segredo AWS Secrets Manager, você deve fornecer ao Firehose as permissões necessárias para acessar o segredo e a chave que criptografa seu segredo.
Ao usar AWS Secrets Manager para armazenar e recuperar segredos, há algumas opções de configuração diferentes, dependendo de onde o segredo está armazenado e de como é criptografado.
+ Se o segredo estiver armazenado na mesma AWS conta da sua função do IAM e estiver criptografado com a chave AWS gerenciada padrão (`aws/secretsmanager`), a função do IAM que a Firehose presume só precisará de `secretsmanager:GetSecretValue` permissão sobre o segredo.
```
// secret role policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "Secret ARN"
}
]
}
```
Para obter mais informações sobre políticas do IAM, consulte [Exemplos de políticas de permissão para o AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html).
+ Se o segredo estiver armazenado na mesma conta do perfil, mas criptografado com uma [chave gerenciada pelo cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (CMK), o perfil precisará de ambas as permissões `secretsmanager:GetSecretValue` e `kms:Decrypt`. A política da CMK também precisa permitir que o perfil do IAM seja execute `kms:Decrypt`.
+ Se o segredo estiver armazenado em uma AWS conta diferente da sua função e for criptografado com a chave AWS gerenciada padrão, essa configuração não será possível, pois o Secrets Manager não permite acesso entre contas quando o segredo é criptografado com a chave AWS gerenciada.
+ Se o segredo for armazenado em uma conta diferente e criptografado com uma CMK, o perfil do IAM precisará da permissão `secretsmanager:GetSecretValue` sobre o segredo e da permissão `kms:Decrypt` na CMK. A política de recursos do segredo e a política de CMK na outra conta também precisam permitir que o perfil do IAM tenha as permissões necessárias. Para obter mais informações, consulte [Acesso entre contas](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html).
# Alternância do segredo
A *alternância* é quando você atualiza periodicamente um segredo. Você pode configurar AWS Secrets Manager para alternar automaticamente o segredo para você em uma programação especificada por você. Dessa forma, é possível substituir segredos de longo prazo por segredos de curto prazo. Isso ajuda a reduzir o risco de comprometimento. Para obter mais informações, consulte [Rotacionar AWS Secrets Manager segredos](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) no *Guia do AWS Secrets Manager usuário*.