Fala galera, beleza? Vamos falar mais um pouquinho agora de segurança? Vamos falar um pouquinho do IAM, eu coloquei ele aqui no capítulo de EC2, mas na verdade ele é pra tudo Mas a gente vai falar no EC2, que foi o primeiro que a gente tocou no assunto, então vamos falar de segurança, né? O IAM, ele é o seu gerenciador de acessos, tá? No fim das contas, ele vai fazer toda a sua ferramenta de gerenciar acesso segurança e recursos da wf ali que você fala quem pode o que quem não pode o que é o lugar onde você define critérios de quem vai conseguir mexer em qual coisa é onde você define mais ou menos o perfil de cada um ali que vai acessar suas contas então esse cara é bem interessante vai mexer nele bastante tá e é legal você tem aí no seu controle. Vamos falar um pouquinho de algumas coisas que eles fazem. Aqui, quando a gente está falando do DC2, ele também serve para o PC2, assim como qualquer peça da AWS, a gente vai acabar usando ele para fazer gestão de acessos e recursos, beleza? Vamos lá. Primeiro, a gente vai falar um pouquinho dos principais componentes que a gente tem no IAM. Quando você olha no IAM, ele vai ter uma definição de quebra, tá? De camadas de perfis, tá? Então vamos pensar nos perfis que a gente tem aqui pra fazer gestão de segurança. A primeira é o usuário. O usuário é pessoa, mas nem só pessoa, tá? Então às vezes a gente pensa assim, putz, o usuário pode ser eu, por exemplo, um outro colaborador da minha empresa, uma outra pessoa que está tendo acesso e assim por diante. Isso sim é usuário. Mas também são os serviços que podem estar acessando um outro. Então se você pensar em outros serviços acessando o seu serviço direto, ele também vai ter que ter privilégio de usuário para fazer isso. Então ele também é considerado usuário, não só uma pessoa, mas um serviço que acessa ao seu EC2. Nesse caso, ele também tem que ter privilégio para isso. Então, você vai ter que gerenciar ele como se fosse um usuário. Outra parte são os grupos. Grupo não é nada mais do que um grupo de usuários, que pode ser de pessoas, pode ser de serviços. Ficou até fácil, né? Então, quando a gente está falando de grupo, se você tiver perfis para conseguir gerenciar, você não precisa gerenciar o CPF ou o serviço tal. Você consegue gerenciar o grupo de serviços ou o grupo de CPFs. E daí vai te ajudar a fazer essa gestão de forma mais simples. Você tem também as funções. Quando a gente está falando de funções, elas são mais chamadas de roles. Então poucas vezes a galera vai falar funções. A galera fala mais roles ou roles, depende do português ou do inglês de cada um e da sua pronúncia. Mas a galera vai falar muito mais de roles. Quando a gente está falando de roles, a gente está falando do seguinte. São as definições de permissões que a gente vai dar para o usuário ou para o grupo, beleza? Só que ela tem carácter temporário. Muita gente acaba deixando essas roles para sempre, mas a ideia é deixar ela de carácter temporárioON, onde você tem sim toda a configuração ali de permissão de segurança e ela é mais imutável, você deixa ela mais quietinha, ela é mais a longo prazo para você já deixar organizado quais são os serviços, principalmente como poder usar o seu serviço e quais são as pessoas que vão poder mexer naquele seu serviço. a gente estava falando do EC2, então façam um paralelo aqui com o EC2 de como funcionaria. A gente também tem, dentro das políticas do IAM, a gente tem basicamente o seguinte, essas políticas são o coração do sistema de controle de acesso no fim do dia. São elas que vão definir, porque quando você fala das roles, elas são muito mais, você vai fazer isso mais a toque de caixa, já as políticas têm que ser muito bem pensadas e assim por diante. Elas vão ser usadas para você negar ou permitir acesso de usuário ou grupo de funções, como a gente falou. E elas são quebradas em basicamente dois níveis, que eu vou falar aqui para vocês. O primeiro são as políticas gerenciadas. Elas são criadas e administradas lá pela AWS ou pelos administradores da conta AWS para uso repetido. Então, essas AWS para uso repetido. Então essas daqui são as políticas gerenciadas. E tem as inline que a gente fala que elas vão ser escritas diretamente para um usuário ou para um grupo de usuário independente, de forma independente. Você não vai fazê-la gerenciada total, você vai fazê-la direto num usuário ou num grupo de usuário. Tem aqui a segurança a nível de API também. E a Emory vai permitir que você controle as APIs que são acessadas ali, e isso vai ser crucial para você decidir ali, no caso do EC2, quais são as operações que podem criar, configurar, deletar instâncias, ou assim por diante. Você pode subir isso e criar ou deletar seu EC2, ou coisa nesse sentido, e isso com chamadas de API. Então é interessante você pensar na configuração que você vai colocar nessas chamadas também, para ela conseguir criar ou deletar. Muita gente acaba criando, por exemplo, APIs que automatizam a criação de alguma instância, no caso, e quando você vai fazer a criação ela dá pau porque ela não tem acesso àquela criação ou àquela deleção. Então é interessante você pensar também como é que você vai configurar no IAM quais são as configurações de acesso dessa API, beleza? Quando a gente está falando de EC2 também, você tem algumas boas práticas. São boas práticas de segurança, perdão, de EC2 não, de IAM. São boas práticas de segurança. Na verdade, a gente só trouxe isso de forma mais clara para dentro do IAM, do seu gestor de segurança aqui. Primeira coisa é o básico da segurança, que é o princípio de menor privilégio. Se você não conhece o princípio de menor privilégio, é basicamente o seguinte. Quando a gente cria algo, a gente dá o menor privilégio possível, ou seja, você não vai ter acesso a nada. Então, a zero de jogo, você vai ver que quando você criar algum tipo de instância, algum tipo de serviço AWS, ele vai vir sem nada dando os acessos conforme é necessário. Então, a cabeça, o tempo todo de segurança tem que ser, eu só vou dando acesso conforme é necessário. O que muita gente faz e que é um erro grotesco, tá? Cria um grupo lá, um JSON com um grupo X que nem é tão pensado e daí vai liberando esse grupo com acesso pra todo mundo. Ou seja, você pega um grupo, você tem um menor acesso criado no IAM, aí você vai gerenciar um grupo que tem acesso a quase tudo e dá esse acesso para todo mundo. Não, a ideia é que você pense no contrário. Pensa no menor acesso e só vai dando acesso conforme necessário para cada tipo de serviço, para cada pessoa e assim por diante. Então, menor privilégio primeiro, tá? Uma outra coisa também é auditoria regular. De tempos em tempos você voltar pra ver se não tem nada esquisito, ou seja quem que deletou alguma coisa esquisita ou pra quem que movimentou alguma coisa que não deveria, olhar quem tá fazendo o que ali pra ver se o seu ambiente ainda tá ainda tá legal, então quando você vai fazer isso, uma ferramenta que tem na AWS pode te ajudar, é o CodeTrail que ele vai ajudar também, depois a gente vai acabar falando dele mais pra frente, mas ele vai te ajudar a fazer essa gestão da sua conta, você conseguir entender quem fez o que e quando. Uma outra coisa também interessante, de novo, a gente tá falando aqui de segurança, como qualquer item de segurança, se rotacionar a credencial. De tempo em tempo você troca as credenciais, não vai deixar aquela credencial fixa lá, aquela admin, admin, sabe? Não vai deixar uma senha admin de mim e nunca vai mudar, brincadeira à parte, mas você pega a credencial e troca ela de tempos em tempos para você não ter mais problema também de essa credencial vazar, alguma coisa assim. E por último, você pode colocar lá o Multifactorial Authenticator, que é o MFA, e com ele você cria mais uma camada ainda de segurança dentro da sua aplicação, aqui dentro dos seus itens da AWS.