AWS Security Foundation: Segurança em ambientes AWS

Sejam bem vindos ao treinamento AWS Security Foundation!

Nesta primeira aula, faremos uma pequena abertura, trazendo informações gerais do curso e também do professor que lhe escreve.

Nesta aula, conheceremos quais são os objetivos deste treinamento. Resumidamente, temos como objetivo macro “estudarmos conceitos de segurança base em nuvem AWS para provermos sua fundação de forma segura e escalável, minimizando impactos decorrentes de sua má configuração”.

Além dos objetivos, trago para vocês também quais foram os motivadores para o desenvolvimento deste curso.

Uma aula de extrema importância, pré-requisitos.

Nesta aula, conversaremos quais são os conhecimentos importantes que devemos ter resolvidos antes de iniciarmos o treinamento. É muito importante que você só avance no curso, se todos os requisitos já tiverem sido aplicados. Abaixo, os requisitos necessários:

• Ter realizado o treinamento “AWS, na prática”.

• Conhecimentos em nuvem AWS;

  • Fundamentos AWS (regiões, AZs e afins)

  • Criação de contas AWS;

  • Amazon EC2;

  • Amazon VPC;

  • IAM;

• Sistemas Operacionais Linux;

• Protocolos de redes (especialmente TCP/IP);

Aula destinada à apresentação do cronograma (agenda) do treinamento. Abaixo, os módulos pertinentes ao mesmo:

1. Introdução

2. IAM

3. AWS Organizations

4. IAM Identity Center

5. Recomendações de segurança

6. AWS Security Assessments

Além disso, veremos também o processo de atualização que será abordado no curso, e alguns pontos importantes, principalmente sobre certificações e suporte.

Nesta aula, veremos um pouco sobre um assunto de extrema importância: modelo de responsabilidade compartilhada.

Em resumo, segurança e conformidade constituem uma responsabilidade compartilhada entre a AWS e o cliente. Esse modelo compartilhado pode auxiliar a reduzir os encargos operacionais do cliente à medida que a AWS opera, gerencia e controla os componentes do sistema operacional do host e a camada de virtualização, até a segurança física das instalações em que o serviço opera.

Finalmente, chegamos a nosso primeiro módulo técnico, IAM. E como já disse anteriormente, este é o nosso principal módulo sobre o principal serviço de nuvem AWS destinado a segurança.

E o porquê disso? Já pensaram a respeito?

Para entendermos sua criticidade, temos de conhecer um pouco sobre o Control Plane AWS. Nesta aula, veremos os detalhes, trazendo, inclusive, alguns estudos de casos reais decorrentes do mesmo.

Trabalhar com IAM, em resumo, significa trabalhar com inúmeras políticas JSON. Para isso, devemos entender sua estrutura e composição.

Nesta aula, veremos os detalhes sobre uma política JSON, os principais pontos que devemos nos preocupar e entendermos antes de começar a “codificar” um novo documento.

Além de sua estrutura, veremos também alguns exemplos de políticas que podemos encontrar em nosso dia-a-dia.

Provavelmente vocês já se depararam com uma política de identidade e/ou política de recursos. Caso não, me companhe nesta aula (do contrário também :))

Nesta aula, conversaremos um pouco sobre políticas de recursos e identidades que existem dentro da AWS, como elas são construídas, e quais as diferenças entre elas.

Em um ambiente de nuvem AWS, existem vários tipos de políticas: políticas de recursos, políticas de identidades, boundaries, SCP, dentre outras.

O objetivo desta aula, é conhecermos quais são essas políticas para podermos avançar com o módulo conscientemente.

Além disso, veremos também um fluxograma para troubleshooting referentes a políticas AWS, seguindo uma ordem de interpretação, facilitando muito nosso dia-a-dia.

Nesta aula estudaremos Permissions Boundaries, sendo um tipo de política que apesar de não liberar nenhum tipo de acesso, tem um papel fundamental: controlar os limites de permissões de uma determinada entidade.

Deny explícito, se ainda não ocorreu com você, ainda vai.

Isso é de fato a proibição master que podemos ter dentro da AWS. Uma ausência de permissões (deny implícito) é possível de resolver facilmente, já o deny explícito, não.

Nesta aula veremos todos os detalhes sobre.

Role-based Access Control e Attribute-based Access Control são duas estratégias de autorização disponíveis na AWS. Nesta aula, entenderemos como funciona cada uma dessas duas estratégias e como elas podem ser utilizadas em nosso dia-a-dia.

Nesta aula, veremos de forma prática, como utilizar a estratégia padrão da AWS conhecida como Role-based Access Control.

Nesta aula, entenderemos de forma prática, todos os detalhes da estratégia conhecida como ABAC (Attribute-based Access Control), que permite o controle de acessos dentro da AWS baseado em atributos, ou seja, em TAGs.

Após termos o entendimento sobre ABAC e RBAC, tanto de forma teórica quanto prática, chegou a hora de definirmos qual a melhor opção.

E como de costume, vocês já sabem a resposta, né?

Nesta aula, começaremos a trabalhar com Roles do IAM, uma solução para autenticação de aplicações, serviços e/ou qualquer outra identidade que necessite consumir recursos AWS seguramente. Uma Role do IAM é bem parecida com um usuário do IAM, entretanto, ela não é vinculada de fato a uma pessoa, e sim a quem precisar utilizá-la.

Spoiler: utilizar IAM Role é infinitamente mais recomendado e mais seguro do que usuários do IAM. Fica a dica :)

Uma das magias de uma Role do IAM é a sua capacidade de reciclagem automática de suas credenciais de acesso (access key, secret access key e secret token). Isso só é possível, graças ao Security Service Token, mais conhecido como STS. Nesta aula entenderemos de fato o que é este serviço e como as Roles do IAM utilizam do mesmo para este fim.

Antes de começarmos de fato a trabalharmos com as Roles do IAM, faremos um pequeno tour sobre as Roles do IAM dentro da console web da AWS.

Já vimos que existem diferentes tipos de Roles do IAM que podemos trabalhar. Nesta aula, conheceremos um pouco mais a respeito da IAM Service Role, amplamente utilizada em todo ambiente de nuvem AWS.

Certamente, se você nunca precisou criar uma integração entre recursos AWS de contas distintas, ainda vai, posso lhe garantir. Dentro da AWS, quando existe a necessidade de autenticarmos, liberarmos acessos de recursos localizados em contas distintas (cross account), podemos utilizar uma Role do IAM para isso, preferencialmente a um usuário programático (como já vimos os benefícios).

Nesta aula, veremos na prática como aplicar essa configuração, deforma simples, direta e segura.

Complementando o assunto de IAM Roles, existe um problema bastante conhecido que é o Confused Deputy, ou “substituto confuso”, que basicamente indica o acesso a uma Role do IAM (assume role) por pessoas não autorizadas, por explorações laterais.

Nesta aula veremos um pouco mais sobre este assunto, e claro, como minimizar os impactos.

Certamente, esta é a aula chave para todo o treinamento: o conceito de Least Privilege, ou mínimo privilégio. Ao logo de todo o curso, vocês irão cansar (sério mesmo) de ouvir este termo.

A partir desta aula começaremos de fato a explorar um pouco mais este tópico, entendendo o grande problema de fato que isso pode gerar no ambiente caso não aplicado.

Provavelmente, em algum momento, você já recebeu uma demanda para liberação de acessos superiores aos que você determina para uma entidade (usuário e/ou Role).  Muitas das vezes, os acessos liberados não são utilizados, ficando uma brecha de segurança enorme ao ambiente.

Mas e aí, como resolver tal situação?

Seguindo a linda de Least Privilege, nesta aula falaremos um pouco sobre o serviço (ou sub-serviço) conhecido como Access Advisor. Resumidamente, este serviço ajuda a refinar as permissões de nossos usuários, roles do IAM baseando-se nos últimos acessos a determinadas permissões.

“De graça até injeção na testa”.

Certamente você já escutou essa expressão. Mas será que é verdade? Posso garantir que não, não para tudo.

Na AWS existem vários serviços categorizados como Free Tier Ever, ou seja, gratuito, 0800, de graça! Mesmo assim, muitas pessoas insistem em não utilizá-los (spoiler: em nosso curso, veremos vários desses serviços).

Um desses serviços gratuitos da AWS é o Access Analyzer, que possibilita uma análise detalhada de nossos usuários, Roles para nos auxiliarmos na criação de políticas pensando no mínimo privilégio, e evitar exposição de recursos de forma pública.

Nesta aula, veremos a primeira parte deste assunto, fazendo uma pequena introdução e entendermos ali quais são os benefícios reais para nosso dia-a-dia.

O treinamento nem havia sido lançado, e a AWS já tinha lançado uma atualização interessante para nosso treinamento. E como de costumo, já trouxe aqui para vocês de primeira mão :)

Qualquer dúvida, só me chamar!

Após a teoria, vamos à prática!

Nesta aula faremos a configuração inicial do nosso IAM Access Analyzer.

Um dos recursos disponíveis do IAM Access Analyzer é a validação de políticas. Durante a criação de nossas políticas do IAM, quando temos o Access Analyzer habilitado, ele nos auxilia, dando dicas de segurança e alertando problemas de sintaxe e/ou críticos (exposição).

Nesta aula, veremos isso de forma prática, em detalhes.

Outra possibilidade bem interessante disponível no IAM Access Analyzer é a geração de políticas Com base nos logs do Cloud Trail (estudaremos mais a fundo sobre ele futuramente em nosso curso), ele cria uma nova política, trazendo a fundo o conceito de mínimo privilégio.

Nesta aula, faremos um laboratório prático a respeito.

Nesta aula, veremos um pouco sobre a monitoração de recursos utilizando o serviço IAM Access Analyzer.

Já vimos que o IAM Access Analyzer traz vários findings sobre os eventos encontrados. Em alguns casos, esses eventos podem ser falsos positivos. Nestes casos, podemos determinar o arquivamento dos mesmos. Entretanto, ficar fazendo isso manualmente acaba sendo complexo. Para isso, existe a possibilidade de criarmos regras automáticas de arquivamentos de findings. E é isso que veremos/faremos nesta aula.

Hora de encerrarmos o assunto (por enquanto) do IAM Access Analyzer :)

Já solicitaram para você criar um relatório do IAM contendo todas as credenciais e suas particularidades? Se sim, você teve que acessar o serviço do IAM e copiar item a item ou utilizou o relatório pronto que existe? (não vale mentir, srsr).

Nesta aula, veremos como gerar relatórios de credenciais do IAM de forma simples e rápida, sem sofrimento.

Assim como o IAM Access Analyzer, existem outras ferramentas que podem nos ajudar a criar políticas do IAM de forma simples, rápida e o melhor, aplicando o conceito de mínimo privilégio.

Nesta aula, veremos um pouco (caminho das pedras) de uma ferramenta desenvolvida em Python para este viés, o Parliament.

Mais uma ferramenta de mínimo privilégio para conta, o Cloudsplaining.

E continuamos nossa saga para alcançar o mínimo privilégio (ferramentas é o que não falta. :))

Steampipe é mais uma ferramenta fantástica. Tão fantástica que teremos um módulo para falarmos muito, muito sobre ela.

Chegamos ao final de nosso primeiro módulo técnico. Foram mais de 8 horas de muito conteúdo técnico de extrema importância para nossa fundação de nuvem AWS.

E para fecharmos com chave de ouro, nesta aula, faremos uma espécie de revisão, trazendo as considerações finais e boas práticas sobre o serviço do IAM.

O AWS Organizations, é um serviço (gratuito) da AWS que possibilita o gerenciamento centralizado de todas as contas pertencentes a uma mesma organização, mediante a uma conta master.

Nesta aula, veremos uma pequena introdução para podermos nivelar o conhecimento de todos, e avançarmos adiante no treinamento.

Após a introdução realizada na aula passada sobre o AWS Organizations, nesta aula veremos um pequeno overview sobre o processo de implementação deste serviço, abrangendo todas as etapas necessárias, previamente, antes de fato de sua implementação.

Então, segure um pouco sua ansiedade, e não pule esta aula :)

Antes de avançarmos, veremos nesta aula, algumas boas práticas para aplicarmos em nossas contas AWS. Essas recomendações foram retiradas da documentação da própria AWS, e também, através dos meus 9 anos de experiência trabalhando com ambientes de nuvem AWS.

Lembre-se: recomendações não são regras. Você decide!

Agora, sim, sem mais delongas, vamos à ativação do serviço AWS Organizations.

Unidades Organizations, são destinadas a melhorar a organização e gerenciamento dentro do AWS Organizations. Baseando-se na aula de boas práticas, vamos, agora, criar nossa estrutura de OUs que utilizaremos durante o restante do treinamento.

Nesta aula, aprenderemos a convidar contas AWS membro para nossa organização. Neste cenário, as contas convidadas devem existir previamente, lembrem-se disso :)

Na aula passada, aprendemos a convidar contas já existentes como membros para o AWS Organizations. Nesta aula, veremos algo diferente, um processo de criar uma conta membro diretamente pelo serviço do AWS Organizations.

Na aula passada, realizamos o processo de criação de uma nova conta AWS através do AWS Organizations. Vimos assim, que, quando este processo é criado, não temos acesso à senha de root. Assim sendo, nesta aula, veremos o processo de recuperação da senha de root criada anteriormente.

Quando criamos uma nova conta através do serviço AWS Organizations, é criada automaticamente uma Role do IAM para prover o acesso às contas criadas. Nesta aula, entenderemos nos detalhes este processo e veremos na prática como funciona.

Já sabemos que o AWS Organizations permite o gerenciamento centralizado de todas as contas membros da organização. Entretanto, não são todos os serviços da AWS passíveis de gerenciamento. Existe uma lista prévia, na qual conheceremos nesta aula.

Lembrando que, por razões óbvias, não estudaremos todos. Porém, veremos, sim, alguns, ao decorrer deste módulo, e dos demais que estão por vim.

O Access Analyzer, já é um conhecido nosso aqui do treinamento. Entretanto, quando estudamos sobre ele, vimos o gerenciamento sendo realizado de forma decentralizada, o que se torna inviável em ambientes multi-account.

Desta forma, o primeiro serviço que veremos a integração com o AWS Organizations, é o Access Analyzer, no qual conseguiremos aplicar o gerenciamento do ambiente de forma centralizada.

O Cloudtrail, é conhecido como o “dedo duro” da AWS. Sua finalidade é monitorar toda e qualquer chamada de API da AWS, seja através da console, CLI, SDKs, e registrar em eventos, permitindo a realização de auditorias posteriores.

A partir desta aula, começaremos a estudar um pouco sobre este serviço, indispensável para todo e qualquer ambiente.

Após uma introdução teórica sobre o Cloudtrail, entenderemos agora como funciona este serviço dentro da AWS, detalhe por detalhe.

Nesta aula, veremos algumas arquiteturas recomendadas para se trabalhar com o serviço do Cloudtrail, independente do porte de sua organização, seja single-account ou multi-account.

Lembre-se, o que veremos aqui, são RECOMENDAÇÕES. Fique à vontade para fazer de outra forma, sob sua responsabilidade :)

Depois das introduções realizadas sobre o Cloudtrail, nesta aula, veremos um pequeno overview sobre o serviço do Cloudtrail. A ideia é trazer uma visão geral antes de iniciarmos de fatos nossas configurções dentro de nossa organização.

Então, espero vocês nesta aula!

Finalmente, chegou a hora de colocarmos em prática, os conhecimentos adquiridos até o momento sobre o serviço do Amazon Cloudtrail. Inicialmente, faremos um setup tradicional, e posteriormente, iremos incrementando o mesmo.

Lembre-se, na descrição do vídeo, encontra-se a documentação necessária. Fique à vontade :)

Agora que já vimos na prática a configuração de uma trail do Cloudtrail em uma conta, veremos também como configurar ela em modo organizacional, ou seja, aplicando a todas as contas membros de nossa organização (recomendado).

Athena é um serviço da AWS que possibilita a realização de consultas SQL em buckets do Amazon S3. Desta forma, nesta aula, veremos um exemplo de configuração do Athena para interpretar os logs da trail organizations criada anteriormente, de uma forma mais amigável (user friendly).

Nesta reta final, analisaremos as políticas disponíveis dentro do AWS Organizations. Basicamente, temos 4 tipos de políticas, sendo a de backup, de IA, de Tags e também as famosas e tão esperadas SCP. A partir desta aula, estudaremos um pouco cada uma delas, exceto a de IA, que apenas veremos que ela existe :)

Como dito na aula anterior, começaremos a estudar cada uma das políticas separadamente. E a primeira delas, será a política relacionada a Inteligência Artificial (boom do momento). Infelizmente, por sair um pouco do escopo, não entraremos em grandes detalhes. Entretanto, todos os caminhos das pedras serão passados aqui.

Sem dúvidas, backup é algo crucial para todo e qualquer ambiente, e aqui dentro da AWS não seria diferente. Nesta aula, começaremos a conhecer um pouco sobre a política de backup disponível dentro do AWS Organizations. Resumidamente, o objetivo é aplicar uma política de backup padrão para todo o ambiente (contas membros) para minimizar os impacto por perda de dados, garantindo assim a disponibilidade de suas aplicações/serviços.

Nota: Quem tem um backup, não tem nenhum. Quem tem dois, tem um, e assim por diante. Lembre-se disso :)

Agora que já temos um conhecimento prévio sobre a política de backup, entenderemos os detalhes da IAM Role utilizada para configuração desta política.

Nesta aula, faremos uma pequena análise sobre a console do AWS Backup, para ilustrar um pouco sobre o processo de configuração de um plano de backup para seu ambiente.

Lembre-se que, mesmo que não nos aprofundemos no tema, é de extrema importância uma boa política de backup conforme o seu ambiente.

Finalmente, nesta aula, aplicaremos o setup de uma política de backup dentro do AWS Organizations. Lembrando que, o que será apresentado é apenas um exemplo, e cada ambiente tem suas reais particularidades.

Já sabemos que as TAGs ajudam muito dentro de nosso ambiente, em diferentes aspectos, como organização, gerenciamento, automação, billing, e também segurança. Nesta aula, começaremos a estudar um pouco sobre a política de TAG existente dentro do AWS Organizations. Em suma, o objetivo desta, é garantir o compliance nas TAGs dos recursos, garantindo assim um melhor gerenciamento do ambiente.

Agora que já sabemos o que é uma TAG Policy, vamos aplicar suas configurações (modelo) dentro da console do AWS Organizations.

As Service Control Policies, conhecidas como SCP, sem dúvidas é um grande recurso para melhorarmos a segurança de nosso ambiente de nuvem AWS, especialmente na aplicabilidade de Guardrails. Nesta aula, veremos uma pequena (não tão pequena assim, srsr) introdução sobre o que é de fato as SCP e como poderemos utilizá-las em nossos ambientes.

Lembre-se, os conceitos aqui apresentados, serão utilizados como base para aplicação de fatos das SCP.

Agora que já temos um pequeno embasamento teórico sobre SCP, podemos aprender como habilitamos ela diretamente pela console AWS, preparando para nossas próximas implementações.

Agora que já sabemos o que são SCP, e como habilitá-las em nosso ambiente, podemos seguir para alguns exemplos. Então, sem enrolações, vamos ao exemplo de número 1.

Nota: Lembre-se, isso é um exemplo, não saia aplicando em seu ambiente antes de analisar o cenário, a não ser, que goste de passar por algumas emoções inesperadas, hehehe

Mais um exemplo de SCP :)

Nosso ultimo exemplo (por enquanto) sobre SCP.

Chegamos ao fechamento de nosso módulo sobre AWS Organizations. Um módulo de extrema importância para todo e qualquer ambiente de nuvem AWS. Espero que os conceitos aqui apresentados tenham sido suficientes para vocês começarem a atuar com este serviço. Caso não seja, recomendo fortemente continuar lendo as documentações da AWS, realizando laboratórios técnicos, e afins. E acima de tudo, conte comigo para o que precisarem.

Um abraço e até o próximo módulo :)

IAM Identity Center, conhecido comumente como AWS SSO :)

Finalmente chegamos a nossa primeira aula sobre o serviço de autenticação centralizada da AWS. Nesta primeira aula, veremos um pouco sobre sua teoria, fazendo uma pequena introdução, e partir da próxima aula, já iniciarmos a implementação deste serviço.

Lembre-se, na descrição de cada aula, tem os links de consultas. Fiquem à vontade para realizarem uma leitura, é de graça :)

Após uma pequena introdução, podemos seguir com a configuração do IAM Identity Center. Entao, sem mais enrolações, vamos ao que interessa.

Quando se trata de IAM Identity Center, temos um conjunto de permissões (Permissions Sets) que se resumem as políticas que serão associadas aos usuários/grupos que utilizaram desta base de autenticação centralizada. E como vocês já fizeram um módulo repleto de políticas, e já dominam o assunto, verão o quão fácil será trabalhar com Permissions Sets.

Nesta aula, veremos uma pequena introdução sobre o assunto, trazendo algumas das opções que temos.

Boa aula a todos.

Após realizarmos uma introdução referente a parte de Permissions Sets do IAM Identity Center, vamos agora, através de um cenário fictício, aplicar a configuração de uma política para cada grupo pertinente, de acordo com suas necessidades.

Então, sem mais delongas, vamos ao que interessa.

Bons estudos!

Continuando a aula passada :)

Múltiplo Fator de Autenticação já é algo que vocês estão carecas de saber. Entretanto, vale a pena reforçar esses conhecimentos, e espero que de uma vez por todas, vocês possam resolver de fato essas pendências :)

Um dos itens de extrema importância e infelizmente negligenciado por muitos, é o tempo de sessão da console do IAM Identity Center. Basicamente, esta configuração, determina por qual período a console ficará ativa, sem a solicitação de um novo login.

É importante que vocês apliquem bem essas configurações, para poderem minimizar os impactos pertinentes a vazamento de dados, por exemplo. Além disso, essas configurações, andam em conjunto com as configurações de “Session Duration”, referente ao STS.

Deixarei alguns links na descrição do vídeo.

Boa leitura e boa aula a todos!

Esta aula, é destinada aquelas pessoas que, ainda ficam insistindo na utilização de access-key e secret-access-key dentro do IAM, mesmo tendo ali, um ambiente com SSO habilitado.

Então, se você é uma dessas pessoas, assista com atenção a esta aula!

Bons estudos!

Na aula passada, nos vimos o processo de geração de credenciais programáticas através da console do IAM Identiy Center. Entretanto, vimos, também, que essas credenciais, possuem um temo limite de sessão, que esperamos não ser “ad-aeternum”, né?

Porém, em alguns casos, de fatos ter de ficar gerando nossas credenciais a cada período, pode impactar em nossos laboratórios/testes, dependendo do que estivermos executando. Desta forma, a AWS trouxe um processo de renovação automática dessas credenciais. Legal né?

Então, nesta aula, veremos como aplicar essas configurações, e acabar de vez com as desculpas de alguns “profissionais” que todos conhecemos.

Bons estudos!

Até então, trabalhamos apenas com a base de autenticação local da AWS, do próprio IAM Identity Center. Entretanto, como já comentado com vocês durante este módulo, temos a possibilidade de utilizarmos um provedor externo de identidade (IdP), para de fato, centralizarmos nossas autenticações, não apenas da AWS, mas de outras aplicações/serviços necessários.

Existem vários IdP que podemos utilizar. Entretanto, para fins didáticos, utilizaremos o Google Workspace, sendo um dos mais utilizados atualmente. Porém, você deve observar que, basicamente, o que muda de um IdP para o outro, são apenas as configurações do próprio IdP. Na AWS, o processo permanece o mesmo. E como nosso treinamento é sobre AWS, focaremos bastante nesses pontos.

Entretanto, para ajudar, deixarei um link (documentação oficial) de outro IdP muito utilizado também, sendo o Office365 da Micro$oft.

Quaisquer dúvidas, estou à disposição.

Boa aula a todos!

Nesta aula, aprenderemos a gerenciar as sessões ativas dentro do IAM Identity Center. O objetivo é trazer a criticidade deste gerenciamento, principalmente em processos de desligamentos/saídas de colaboradores da empresa. Apesar do processo ser simples, isso pode salvar o seu dia. Pense nisso.

Chagamos ao final de mais um módulo. Um módulo mais curto, mas de extrema importância para todo e qualquer ambiente. Agora é a hora de vocês revisarem o conteúdo e começarem a colocar em prática. E claro, pintando dúvidas, estou à disposição.

Ah, mas antes de finalizarmos, faremos uma pequena revisão, trazendo aqui algumas recomendações gerais, para reforçar os conhecimentos.

E lembre-se, pintando novidades no IAM Identity Center, disponibilizarei aqui para vocês (ASAP).

Obrigado por chegar até aqui, e te vejo no próximo módulo.

Abraços,

pH