Olá pessoal tudo bem? Bem vindos de volta a nossa Jornada Cloud e vamos continuar aprendendo hoje sobre um dos itens mais importantes da AWS, tá bom? É um dos itens que tem a capacidade de garantir basicamente toda a segurança de acesso tanto à nossa conta como também aos nossos serviços, tá bom? Estamos falando do IAN Identity Access Management, tá bom? O que é isso? Ele é basicamente o lugar na AWS onde nós criamos nossos usuários, permissões, políticas de acesso, além de gerenciar, inclusive, todos os acessos que nós podemos ter a nossa conta AWS. Inclusive, por exemplo, acesso programático, múltiplo fator de autenticação, todas essas configurações são coisas que nós configuramos dentro do IAN, tá bom? Então, por exemplo, se você está aí dentro da sua conta AWS e neste momento você está fazendo login nela usando apenas o usuário e senha, saiba que você pode estar colocando aqui sua conta em risco. E sendo que dentro da AWS nós pagamos pelo uso, você também está colocando então o seu orçamento em risco. Por quê? Porque se você tiver um vazamento de usuário e senha, alguém pode simplesmente entrar na sua conta AWS e começar a instanciar em máquinas EC2, fazer outras coisas aí que para o bem dele vai ser legal, ele vai fazer vários usos aí, mas que vai gerar custos. No final, você que paga a conta, tá bom? E lembrando que a AWS, ela é um item de responsabilidade dividida. A AWS, ela garante que seus recursos vão ser íntegros, que sua conta vai estar segura, desde que você use os recursos corretos, tá bom? Então, uma das dicas importantes para você que ainda não configurou, procure aí dentro da AWS, no IAM, o múltiplo fator de autenticação, tá bom? Porque é uma das coisas também que vai ajudar por segurança na sua conta. Mas, vamos lá. Então, o que a gente pode fazer aí dentro do IAM, tá bom? A gente pode criar políticas de acesso por usuários, tá bom? Por exemplo, imagina que uma empresa, a gente tem aí uma equipe de desenvolvimento e a gente tem, vamos dizer assim, uma outra equipe que ela é só de analytics, tá bom? Ela precisaria ter acesso ali às bases para fazer análise de dados, tá bom? Vamos dizer que minha equipe de desenvolvimento, ela pode ter acesso às máquinas e aos serviços das aplicações, as minhas máquinas EC2, por exemplo, mas ela não pode ter acesso direto na base de dados. Ela pode, por exemplo, com suas aplicações, salvar, produzir esses dados, mas os usuários em si, eles não deveriam, por exemplo, ter um acesso à modificação desses dados, ter um acesso direto a poder executar insetos, updates, envases e coisas desse tipo. Já a equipe de analytics, ela pode ter acesso às bases de dados para ter uma visualização mais abrangente. Então, mais essa equipe também não poderia ter acesso às máquinas EC2. Então, vamos dizer assim, meus desenvolvedores têm acesso às minhas máquinas, têm acesso aos seus programas, e não têm acesso direto à base de dados. Já a minha equipe de analítica tem acesso ali as bases de dados, mas não tem que ter o poder de encontrar as máquinas, de poder dar stop nessas máquinas ou mesmo de excluí-las, tá? Então, a gente usa o IAN para fazer esse tipo de configuração, tá bom? Então, aí no IAN, nós podemos criar basicamente quatro tipos de configuração, tá bom? Então aí no EAN nós podemos criar basicamente quatro tipos de configurações, tá bom? Nós podemos criar usuários, que eles são basicamente contas da AWS, tá bom? Contas ali de usuários dentro da AWS, melhor dizendo. Grupos de usuários, eu poderia agrupar esses usuários, poderia criar ali, por exemplo, um grupo de analytics e colocar todos os usuários, eu poderia agrupar esses usuários, poderia criar ali, por exemplo, um grupo de analytics e colocar todos os usuários de analytics ali dentro com as mesmas permissões. Poderia criar ali um grupo de desenvolvedores e colocar todos os desenvolvedores ali dentro desse grupo para terem as mesmas permissões. Criar um grupo ali de DBA, por exemplo, colocar todos os DBAs dentro desse grupo com as mesmas permissões. Enfim, a gente vai fazer aquilo que faz sentido semântico para a topologia da nossa empresa. Se a sua empresa tem esse grupo onde eu posso ter ali engenheiros e arquitetos com acessos diferentes, eu vou criar perfis diferentes de acesso para esses funcionários, no caso. Eu também posso criar lá dentro funções, que basicamente são regras de acesso, basicamente o que pode acessar, e as políticas que elas trabalham ali em casal com as funções. A política vai lá nos serviços da AWS e fala, olha, aquele que tiver essa política aqui, se agrega ela a uma função, por exemplo, ele pode fazer isso, isso, isso, isso, mas não pode fazer isso, eu posso dar permissões, como eu posso negar também, tá bom? Eu posso fazer uma negação explícita, tá? Dentro dos módulos do IAM. dentro dos módulos do Aean. Lembrando uma coisa interessantíssima, que o Aean, por definição, tudo nasce negado. Então, se eu não dei permissão, automaticamente a premissa é que ele negue. Então, eu posso sim, dentro das políticas, criar negativas? Eu posso criar negativas. Mas, se eu não criar as negativas explícitas, naturalmente aquele serviço já é negado. Por que eu posso ter um grupo de buckets que eu posso acessar e dar permissões para aqueles buckets e negar outra classe de buckets. Falar, olha, ele pode, tal perfil que tem essa policy aqui, ele pode criar buckets e deletar buckets e eu posso colocar um outro grupo aí de pessoas que trabalham no S3 e falar, olha, é esse aqui que trabalha com S3, não pode nem criar e não pode deletar Bust, ele pode criar arquivo e deletar arquivo, por exemplo, entendeu? Então, dessa forma a gente acaba segregando muito do que a gente tem dentro do nosso ecossistema e garantindo também a confiabilidade. Mas aí tá, como que eu acesso a IAM para ter acesso a todos esses recursos? Novamente, você pode simplesmente digitar aqui dentro, IAM, vou colocar como meu favorito, ou se você é favoritão, você pode clicar aqui, e aqui está o IAM. Então aqui como eu falei, basicamente eu posso ter quatro coisas. Existem mais coisas. Existe acesso estéreo, acesso programático, várias coisas que a gente pode colocar aqui dentro. Sim, posso colocar, por exemplo, acesso programático. É uma das coisas que eu poderia colocar para tokenizar aplicações locais. Enquanto o Dev está trabalhando lá na máquina dele, desenvolvendo a aplicação dele, que está buscando determinado serviço na AWS, eu posso fazer um acesso programático e através do cliente em máquina da AWS, eu posso fazer com que minha máquina tenha acesso a esses recursos de forma tokenizada, e não necessariamente por dentro do console, que é um outro item que a gente vai acabar abordando mais aos finais das nossas aulas aqui na cloud, tá bom? Então, por hora, a gente vai focar um pouco no console e é um pouco disso aqui. Eu posso ter aqui meus grupos de usuários, meus usuários, minhas funções e as minhas políticas de acesso, tá? funções e as minhas políticas de acesso. Você vai notar que já tem várias políticas aqui dentro da AWS. Internamente, pessoal, ela é um JSON. Então, a gente vai entender um pouquinho mais sobre isso nos próximos momentos. Por quê? Porque para poder avançar nas nossas aulas, nós vamos precisar de fato entender um pouco mais profundamente sobre o que são as funções e as políticas, porque uma das coisas mais interessantes do IAM é que ele não é usado apenas para gerenciar políticas de acesso dos meus usuários ou dos meus grupos de usuários, no caso também, ela vai poder gerenciar o acesso das minhas aplicações, tá bom? Exatamente, então eu posso ter aqui aplicações com permissões diferentes. Então, imagine que uma aplicação tem acesso a determinado contexto, né? Essa aplicação aí que, por exemplo, manutencia uma base de dados, ela é exposta na internet, ela deve, melhor dizendo, consultar uma base de dados. Vamos dizer que você tem uma API ali, ela não é uma API RESTful, ela é uma API apenas de consulta, tá bom? Então, eu vou lá e tenho uma Pay apenas de consulta e ela teria que ter a permissão de leitura na base de dados. Ela só precisa ler na base de dados, ela não precisa efetivamente gravar ou atualizar na base de dados. Mas vamos dizer que por pressa, o desenvolvedor que criou essa política de acesso foi lá e deu um acesso completo às bases de dados para essa aplicação que está exposta na internet. Ou seja, ela teria uma responsabilidade atribuída de apenas leitura, mas ela tem ali a capacidade de gravação. Só que aí o desenvolvedor, ele errou uma vez na política de acesso e ele errou também na hora de programar. Ele não colocou ali, por exemplo, os bloqueios a SQL Inject, ele não colocou ali tratamentos. E aí alguém atacou essa aplicação. Então, neste momento, essa aplicação que teria uma responsabilidade de leitura, consegue agora, indevidamente, gravar em base de dados por meio de um ataque cibernético. errasse na programação e a programação permitisse esse tipo de comunicação, a política iria barrar, porque a política iria falar, opa, na hora que a minha aplicação aqui está chegando no meu recurso, a política que está ali no meio iria falar, opa, até te conheço, até sei quem você é, mas você não pode executar essa ação aqui dentro porque você não tem uma ação para gravar, para criar itens aqui. Entendeu? Então, é muito interessante esse tipo de política, tá? Exemplificando, isso aqui é um exemplo muito bobo que eu estou dando, mas é para ficar claro de que, olha, o IAM não vai apenas gerenciar as minhas aplicações, os meus usuários, mas ele vai gerenciar também as minhas aplicações. Ele também vai falar o que eu posso ter acesso. Um outro exemplo disso seriam aplicações que estariam ali expostas à internet, que teriam que ter, por exemplo, uma consulta em uma base de dados, mas o que ela estaria fazendo com acesso aos meus buckets, se ela não tivesse essa necessidade? Por exemplo, eu estaria também expondo outros serviços, tá bom? A risco por causa disso, comprometendo todo ali o meu ecossistema. Então, resumindo, pessoal, o IAN, ele é a peça na AWS responsável por gerenciar os acessos, os usuários e o que esses recursos podem ou não podem também fazer em conta. Pensando de forma mais prática a nível de usuários, poderíamos definir um grupo de usuários, como eu falei, que poderia criar e deletar recursos e bases de dados, e usuários que não podem fazer isso, garantindo assim a integridade da nossa conta e também bloqueando os acessos às aplicações que não precisam ter determinados acessos, garantindo também a confiabilidade de todo o nosso sistema, tá bom? de todo o nosso sistema, tá bom? Então, é isso, pessoal. Esse é o IAM. É um recurso que você vai usar para tudo dentro das suas aplicações, de coisas que você vai fazer aqui dentro, tá? Porque pensando a nível de usuário e de aplicação, esses perfis precisam ter determinados controles de acesso para que você respeite isso que a AWS chama de responsabilidade dividida. Exatamente o fato de você poder criar coisas e delegar determinadas responsabilidades para determinados itens. É isso por o momento. Nos próximos momentos você vai ver a usabilidade disso nas próximas aulas. E vai ser muito interessante. E mais uma vez, muito obrigado e boa sorte.