Olá pessoal tudo bem? Bem vindos de volta a nossa Jornal da Cloud. Vamos estar falando agora sobre uma das features de segurança mais importantes da AWS quando estou falando de aplicações. Vamos falar agora sobre o AWS Secret Manager. O que é isso aqui? Ele é basicamente o nosso gerenciador de segredos dentro da AWS. Então, qual a importância de eu ter esse cara dentro do meu ecossistema? É exatamente eu poder ter um lugar, um cofre, onde eu deixo as minhas senhas armazenadas, minhas senhas guardadas, para que eu possa estar recuperando isso por aplicação. Por exemplo, vamos dizer que você tem um banco de dados. para que eu possa estar recuperando isso por aplicação. Por exemplo, vamos dizer que você tem um banco de dados. Você foi lá, inicializou um banco de dados no RDS, inicializou um banco de dados na SQL, por exemplo. Então, ali você vai ter o usuário e senha desse banco. Você poderia só pegar, colocar um usuário e senha nesse banco e jogar isso para a sua aplicação, colocar lá nos seus properties, deixar isso lá para que todos acessem. Mas isso também compromete a integridade do seu banco, porque uma vez que essa aplicação ficasse comprometida, eu comprometeria também aquilo com que ela se integra de fato nos bancos. ficasse comprometida, eu comprometeria também aquilo com que ela se integra de fato nos bancos. Então, um invasor ali poderia ter múltiplos acessos, ainda que a gente tenha formas de evitar isso, mas estou dizendo que não é seguro que eu deixe os meus segredos atrelados à minha aplicação. Isso são dados, então eles estão em features apartadas. É bom que a minha aplicação possa fazer uso disso. Então, eu posso criar ali, por exemplo, usuário e senha do meu banco de dados, em vez de armazenar em um properties da minha aplicação, eu posso armazenar no Secrets Manager, que há dentro da minha aplicação, uma forma da minha aplicação buscar esse segredo, se conectar e fazer ali todo o gerenciamento de configuração que ela necessitar tá bom dentro das features que ela precisa acessar a partir daquele segredo que pode ser um banco de dados pode ser um cache, um redis, pode ser qualquer outra feature aí dentro disso inclusive vamos dizer que sua aplicação ela consome aplicações de terceiros né então você tá aí no protocolo de autenticação o alvo 2 onde você vai ter aí um client secret um client id e eu deixar isso exposto na minha aplicação também compromete a minha integração eu poderia dentro do secret manager guardar as chaves da minha api client id client secret e usar isso claro que eu posso guardar isso em algum cache em memória, eu não preciso toda hora ficar requisitando o secret manager eu posso guardar isso ali mas a aplicação não é dona dessa chave sempre que ela precisar e não tiver ela vai lá no secret manager e pergunta qual que é a partir de um nome de chave, a partir de um nome de segredo, quais são as chaves que estão vindo e ali eu posso ter puro texto, como eu posso ter chave e valor. Eu poderia ali dentro do mesmo segredo armazenar client ID em uma linha, client secret no outro. Poderia armazenar em banco de dados usuário em uma linha, senha do banco em outra linha. Então, eu tenho várias formas de usar o Secrets Manager. Então, ele é basicamente um gerenciador de credenciais, vamos chamar assim, tá? Ele garante a criptografia, ele garante o armazenamento, ele garante que isso vai estar lá disponível para mim e ele é gerenciado pela própria AWS, eu tenho como simplesmente usar, é mais um dos serviços de prateleira da AWS, tá? Falando um pouco de preço, por incrívelmente isso aqui é muito barato, tá gente, de se ter, e é uma forma muito legal de se usar aí pra gerenciar, e ele é muito barato. Por exemplo, criei agora um segredo eu posso sair no período de teste então dentro do período de teste eu tenho aí os primeiros 30 dias eu não vou cobrar posso armazenar e o período de teste do secret manager começa quando se armazena o primeiro segredo não vai começar no seu fruit começa com seu primeiro segredo então não tenho nenhum segredo armazenado na ws criei meu primeiro segredo. Então, não tenho nenhum segredo armazenado na AWS. Criei meu primeiro segredo, eu vou começar a entrar aí o período de teste disso, né? Ele não vai me cobrar durante os primeiros 30 dias. Após isso, o que eu pago? 40 centavos de dólar, tá bom? Por segredo, por mês. Então, eu tenho dois segredredos 80 centavos e por aí vai tá bom então o segredo de réplica né tipo eu tenho dois segredos eu repliquei um é cópia do outro também vou pagar ele entende-se como um novo segredo tá bom é e se eu não ficar por exemplo criei o segredo passou um um mês, não estou com esse segredo, ficou 15 dias só de ele ter esse segredo. Ele vai me cobrar pelas horas usadas, tá bom? E como tudo na AWS, ele também tem a chamada de API. Então, 10 mil chamadas de API, 5 centavos de dólar, tá? Não é nada caro, não é uma coisa muito difícil de acessar, na verdade ela é de fato um serviço de prateleira que a gente pode estar fazendo uso aqui dentro da nossa AWS. Agora o que a gente vai fazer? Vamos fazer um testezinho. Eu vou criar aqui uma Lambda, tá bom? Somente para a gente recuperar o segredo, para você ver como que usa o Secrets Manager, o quanto que ele é usual, tá bom somente a gente recuperar o segredo pra você ver como que usa o secret manager o quanto que ele é usual bom ter uma lenda eu vou colocar um log logo isso pra guardar eu quero lugar segredo só pra você ver a recuperação isso não é bom fazer segredo não se loga, tá pessoal? Deixa claro isso, que isso aqui é somente pra gente fazer um teste de uso pra você ver que eu tenho um item na AWS, que eu tenho uma Lambda com capacidade de acessar isso, e ela poderia estar fazendo uso desse segredo em um banco de dados, ela poderia estar fazendo uso desse segredo em uma API, tá bom? Mas segredo, por favor, não coloque log no seu segredo, tá? Isso acaba comprometendo muito a segurança da sua aplicação, tá bom? Então, vou pegar aqui o aws secret manager minha chave de segredos e a Lambda vai buscar. Eu vou fazer um evento HTTP now. Pronto. Vou fazer um evento HTTP na Lambda. Não vou expor gate. E vou apenas fazer esse evento. Ela vai buscar um segredo que eu já vou ter criado. Vai logar esse segredo aí. Só para a gente ver a recuperação. Ver que de fato isso funciona. Que ele vem decriptografado. E tudo mais para pra gente, ok? Então, vamos lá, vamos ver o que a gente pode estar criando de feature pra isso. Primeiramente, eu vou criar o meu segredo. Então, eu venho aqui, digito Secrets Manager, posso até salvar aqui os meus favoritos. É uma feature que a gente usa sempre. Então, se eu for armazenar chaves de banco de dados, se eu for armazenar chaves de API, se eu for armazenar chaves de cache, de algum elástico cache da vida, vou estar aqui dentro. Se eu clicar em segredos, eu vou ter a lista, se não, eu posso armazenar aqui um novo segredo. Vamos armazenar um novo segredo. Aqui eu posso ter o que eu quero. Segredos do RDS, segredos de um banco de DocumentDB. O DocumentDB, pessoal, ele é o MongoDB dentro da AWS. Ele não tem ali as mesmas características de ponta a ponta, mas ele tem a mesma estrutura de armazenamento de documentos, então o DocumentDB e o MongoDB é assim, similar, claro o Mongo tem as suas particularidades por ser uma ferramenta de mercado, a AWS tem a sua feature de armazenamento de documentos, de banco baseado em documentos também como MongoDB, que é o DocumentDB, então poderia guardar aqui as armazenadas dele, do DocumentDB, poderia armazenar aqui um warehouse, ou para outro banco de dados, ou outro tipo, eu vou em outro tipo aqui, eu vou armazenar um banco, eu vou em outro tipo aqui, eu não vou armazenar um banco, eu posso colocar o nome do usuário, senha, documento, não vou colocar nada disso, nada disso aqui, vou colocar outro segredo, porque eu posso, como eu falei, armazenar em linha ou eu posso armazenar texto simples aqui vou armazenar um texto simples vou colocar aqui como se fosse uma senha e isso é a minha senha textos simples como eu falei poderia ser chave valor e eu ter várias linhas ali ele chegaria no modelo JSON, se eu fizesse o SQL DEVELO e disso, na hora que eu buscasse via aplicação, ele armazenaria via JSON isso para mim, tá bom? Mas eu vou colocar aqui como texto simples, tá? Para que a gente possa estar acessando. Criptografia, eu posso usar um KM1 ou outra KMS, adicionar uma nova chave, eu posso usar o da própria AWS, tal como o S3 S3 não tem o SSE S3 lá o SQS, SSE, SQS que é a chave de criptografia gerenciada pela própria AWS aqui no Secrets Manager eu posso fazer uso da própria AWS também como eu posso atrelar o meu KMS e novamente se eu atrelar o meu KMS eu vou pagar por esse KMS além de pagar pelo segredo, tá bom? Então vale a pena a gente olhar o que a gente quer nisso. Vem próximo, nome do segredo, vou colocar aqui como deve, barra, deixa eu ver aqui. Acho que não vai ser o dev. Barra. My. Barra. 60. Vamos ver se dá certo. Tag. Não preciso de permissões. Não vou replicar. Lembra, se eu replicar, pago por outro. Alternância. Não vou mexer em nada. Não vou desfazer. Função. Vou apenas seguir aqui. Tip tipo de segredo, outro tipo, nome do segredo, não tem tag, não tem nada, aqui ele já dá uma amostra de código para você recuperar isso dentro da AWS usando a própria SDK, então ele tem aqui em Java, em Python, tá vendo? Então ó, tem várias coisas que a gente pode estar fazendo aqui ó, busca o segredo depois você faz aqui a conecta no banco, faz alguma coisa que você queira aqui tem um segredo dev my secret então agora eu tenho um segredo aqui dentro que eu vou armazenar vou fazer uso dele lá a minha lanza ó pode notar ele não vem o valor aberto não é como lá no parâmetro store no parâmetro que você vai basear no parâmetro na hora que você entra dentro do parâmetro, o parâmetro está lá aberto ah, mas eu tenho KMS lá eu posso entrar lá o KMS, sim, o KMS é uma coisa do trânsito, da abertura e do fechamento do parâmetro, na hora que se a pessoa tem vamos lá para ver se eu criasse um parâmetro lá e eu tivesse esse parâmetro ele viria aberto aqui ele vem fechado para mim então vamos dizer que você tem uma organização e você tem ali os devs que tem acesso a sua conta WS e vamos dizer que você tem ali uma conta de desenvolvimento e uma conta de homologação e uma conta de produção você pode colocar uma policy para esse dev em desenvolvimento e em homologação na conta de produção. Você pode colocar uma pólice para esse dev em desenvolvimento e em homologação, onde esse dev vai estar nesses ambientes abrindo essas chaves, ele pode ver, mas vamos dizer que eu não quero que meus desenvolvedores tenham acesso à produção ao meu banco de dados diretamente, ele não tem que saber usuário e senha, quem tem que saber isso é quem? É a aplicação que ele codificou. Então, eu poderia ali falar, olha, dentro de produção esse usuário ele não tem a policy de GetSecretValue, ele não pode. Então, ele iria tentar recuperar aqui o valor de segredo e não conseguiria ver. Hoje eu consigo ver. Por quê? Porque a minha policy é a minha root. Mas se eu tivesse aqui, se eu não tivesse essa senha, se eu não tivesse essa permissão, se a pólice fosse uma pólice que não incluísse isso, fosse uma pólice ali para um usuário que não pudesse ver, ele simplesmente não veria o segredo. Então, é muito bom porque a AWS te garante que vai ver esse segredo apenas quem puder ver. Quem tiver policy pra isso. E aí se a pessoa, mas ele pode ir lá e editar a policy dele? Não. Você pode colocar lá na policy dele que ele não pode editar policy. Entendeu? Então ele não vai criar segredos, ele não vai alterar segredos, ele não vai buscar esses segredos pra gente fazer pra fazer uso do banco de dados por exemplo, conforme ele desejar, então é isso o valor do segredo ele não iria recuperar vamos para a nossa lambda vamos fazer uma lambda que busque esse segredo aqui e logo ele, como eu falei, de novo não é o correto, é apenas para a gente fazer um teste. Para você ver que via aplicação você consegue recuperar os itens do segredo. Vamos criar uma função, vou criar do zero. Vou chamar de Lambda Secret. Vou falar que ela é Python. Vou colocar aquela nossa role criei aqui a função, já tenho o código onde eu vou estar passando então, toda vez que ele buscar esse segredo, ele vai colocar aqui o Secret Galo e vai logar para a gente. Ele já consegue fazer esse acesso? Não, ele ainda não consegue fazer esse acesso. Por que ele não consegue fazer esse acesso? Porque minha lã ainda não tem a minha pólice para Secret. Então, vamos lá? Vamos alterar, incluir essa policy, vamos no política vou criar política secret manager eu quero leitura getSecretValue somente isso que eu quero aqui não vou buscar versões, não, somente valores vou marcar como tudo poderia ser ciclado por causa do segredo próximo nome da política secret sm split manager policy sm-secretmanager-policy criar a política vamos na função vamos anexar prontinho então aqui já está a minha política de Secret Management. Minha lâmpada já está aqui. Vamos testar? Vamos ver se isso sai pra gente? Vou só testar, não fiz eventos detalhados, vamos só testar. Opa! Peg pegou olha aqui ó olha o log secret value isso é a minha senha vamos dar uma olhadinha lá no nosso cloud watch vamos ver se logou tudo certinho vamos lá no nosso grupo de log lambda secret, isso é minha senha. Então pessoal, porque que eu uso isso? Novamente, é onde eu deixo os meus segredos, eu deixo o usuário de banco, senha de banco de dados, usuário de cache, de banco de cache. Eu deixo ali, usuário para acessar um banco de documentos. Então, eu deixo ali as chaves de API, client secret, client ID. Eu mitigo isso em produção para que ninguém veja, tiro essas folhas para que ninguém acesse. E isso vai estar, de fato, dentro de um cofre na AWS. Ele está criptografado, ele está com garantia de trânsito, ele está com garantia de criptografia ali também, enquanto ela estiver parada. A chave não é recuperável se não tiver uma política que permita isso. Então, Secret Manager é uma feature de segurança importantíssima pra sua aplicação não armazene não vá sair, não coloque senha de banco em properties de aplicação, não coloque senha de de APIs, né? Chaves de APIs em properties de aplicação use o Secret Manager ainda que você precise do entanto por exemplo poxa é uma epcs né usando ali um java com spring boot faz um bem dessa se decide secret bom e pode até usar um memória lhe pra poxa enquanto aquela pede que vamos ver que você está usando essa task com o Firegate e o Java, tá? Enquanto essa task estiver rodando aqui, ó, na task em si, mantenha ali a senha na memória do Java, guardadinha, tá? Subiu uma, ela vai lá, busca a senha, pra que ninguém fique de fato olhando pra isso, vendo isso, tá bom? Guarda os seus segredos de forma segura e a AWS ela te dá uma forma quase de graça pra você fazer isso, né? 40 centavos de dólar pra guardar usuários senhas de banco, garantir criptografia e eu tenho 10 mil requisições por mês pagando 5 centavos de dólar por requisição, gente, a segurança é algo que não tem um preço, né? Porque a não segurança pode ser muito mais caro do que esses 40 centavos que às vezes a gente quer economizar. Eu já vi pessoas colocando senha em parâmetro store. Não faça isso. Isso é ruim. Como eu falei ali, o parâmetro store ele é uma informação aberta, tá bom? ele é uma informação aberta então não faça isso, não coloque senhas em parâmetro store, não deixe essas senhas armazenadas dentro de properties de aplicação uma coisa interessante você pode dentro do ECS, ECS com Firegate ECS com EC2 independente você pode fazer do ECS, ECS com Firegate, ECS com EC2, independente, você pode fazer variáveis de ambiente, e as suas variáveis de ambiente, pode usar um value from. Então, dentro dessa variável de ambiente, você pode apontar para um segredo, e aí quando ele está fazendo o deploy disso na task, ele traz esse valor para uma variável de ambiente, entendeu? E quando você olha ali na console da AWS, você abre lá você vai ver as variáveis de ambiente a variável de ambiente que é de segredo ela vai tá com o value from apontando pro segredo e não o segredo em si dentro da variável ali pelo console, claro que dentro da task essa variável vai estar com o valor aberto, então é uma coisa de você olhar também e garantir as policies corretinhas para que você não ganhe lá um getenv dentro da sua obrigação e exponha os seus segredos para a forma, mas isso aí é uma outra forma de uso. Então, segredos na AWS estão dentro de Secret Manager. Use, é barato, é importante, é muito bom para o seu uso e para o seu dia a dia. Tá bom? É isso, mais uma vez, obrigado e boa sorte, pessoal.