DEV Community

Cover image for AWS Certified Solutions Architect Associate: Design de arquiteturas seguras - Parte 1
Marcelo Amorim
Marcelo Amorim

Posted on • Updated on

AWS Certified Solutions Architect Associate: Design de arquiteturas seguras - Parte 1

📚 Série de textos com dicas de estudo para a Certificação AWS Solutions Architect - Associate (SAA - C03)

Image description

Olá, essa série de textos é dedicada a ajudar quem está se preparando para a certificação da AWS Solutions Architect - Associate (SAA - C03). São algumas dicas de preparação seguindo o Guia do Exame, tópico a tópico.

📝 Antes de qualquer coisa, devemos ler o Guia do Exame.O Guia do Exame é fundamental e traz com muita clareza os tópicos importantes a serem estudados e que devemos manter em foco nos estudos.

Nesta parte 1, vou me limitar a analisar a definição de tarefa 1.1 do Domínio 1. Vamos item por item. Bom lembrar que esse texto contém apenas algumas dicas e apoios para quem está se preparando para a prova.

A imagem abaixo é o trecho do Guia do Exame que contém a definição de tarefa 1.1:

Image description

Para uma preparação completa, deixo como recomendação os seguintes cursos (tem muitos outros cursos muito bons, mas selecionei três para tentar ser mais objetivo aqui):

1) Skill Builder,

2) Cloud Guru

3) Udemy - Stephane Maarek.

[Guia do Exame] 🏛️ Domínio 1: Design de arquiteturas seguras.

[Guia do Exame] 🛡️ Declaração de tarefa 1.1: Projetar acesso seguro aos recursos da AWS.

[Guia do Exame] 📚 Conhecimento sobre:

  • [Guia do Exame] Controles de acesso e gerenciamento em várias contas.

Esse tópico é muito importante e mostra logo de início como o Guia do Exame deve ser nosso norte do início ao fim da preparação para a prova. Por isso recomendo uma leitura muito atenta ao Guia, isso pode ajudar muito na preparação.

Nesse tópico podemos pensar em alguns serviços da AWS como AWS Control Tower, AWS Organizations, IAM etc e entendermos o que significa uma SCP (Service Control Policy), por exemplo. Acho importante também reforçarmos o escopo de várias contas em nossos cenários de estudo, já que é um contexto que vai transpassar inúmeros cenários no mundo real (logo, importante darmos bastante atenção).

  • [Guia do Exame] Serviços de identidade e acesso federado da AWS (por exemplo, AWS Identity and Access Management [IAM], AWS Identity Center [AWS Single Sign-On]).

Comentário:

O IAM permite controlar o acesso a recursos da AWS de forma detalhada, oferecendo a capacidade de criar e gerenciar usuários, grupos e políticas de segurança. Com o IAM, você pode definir permissões precisas para cada entidade, garantindo que apenas as ações necessárias sejam permitidas.

Definição documentação: "AWS IAM Identity Center é o recomendado AWS service (Serviço da AWS) para gerenciar o acesso de usuários humanos aos AWS recursos. É um único lugar em que você pode atribuir aos usuários da força de trabalho, também conhecidos como workforce identities, acesso consistente a várias aplicações da Contas da AWS . O IAM Identity Center é oferecido sem custo adicional.

Com o IAM Identity Center, você pode criar ou conectar usuários da força de trabalho e gerenciar centralmente seu acesso em todos os aplicativos Contas da AWS . Você pode usar permissões de várias contas para atribuir acesso aos usuários da sua força de trabalho às Contas da AWS. Você pode usar as atribuições de aplicativos para atribuir aos usuários acesso a aplicativos AWS gerenciados e gerenciados pelo cliente.".

Deixo aqui uma parte da documentação oficial da AWS para evitarmos confusão entre as nomenclaturas AWS SSO e AWS Identity Center:

Image description

  • [Guia do Exame] Infraestrutura global da AWS (por exemplo, Zonas de Disponibilidade, Regiões AWS).

Aqui é importante termos bem definidos os conceitos de Região e Zona de Disponibilidade. Isso vai ser muito importante quando estivermos num estudo de caso a respeito de algum contexto arquitetural e possíveis soluções. São conceitos fundamentais.

  • [Guia do Exame] Práticas recomendadas de segurança da AWS (por exemplo, o princípio de menor privilégio).

Esse tópico é bastante importante. Se observamos com atenção a documentação sobre o assunto, podemos ver que tem uma série de conceitos importantes aí. Princípio de menor privilégio, SCP (Service Control Policy como barreira de proteção para múltiplas contas), Autenticação Multifator, uso do IAM Access Analyzer para revisão das políticas vigentes (uso apenas do que for necessário) etc.

Essa imagem resume bem

De forma objetiva, podemos pensar que a AWS é responsável pela infraestrutura das máquinas, do cabeamento, segurança física dos data centers etc. Uma forma legal de pensar caso tenhamos alguma dúvida em alguma questão que aborde o assunto é: consigo realizar essa ação no console ou via AWS CLI? Se sim, provavelmente (reforço o provavelmente, não quero criar uma generalização), a responsabilidade é do cliente e não da AWS.

🛠️ Habilidades em:

  • [Guia do Exame] Aplicar as práticas recomendadas de segurança da AWS a usuários do IAM e usuários-raiz (por exemplo, autenticação com multifator [MFA]).

Image description

Quer entender mais sobre o processo de configuração da autenticação com multifator? Lá vai mais uma documentação.

Sobre as práticas recomendadas de segurança também podemos consultar a documentação sobre o assunto.

  • [Guia do Exame] Projetar um modelo de autorização flexível que inclua usuários, grupos, funções e políticas do IAM.

Entre os quatro conceitos listados aqui gosto de pensar numa definição comparativa. Usuários são identificações que estabelecemos numa relação 1x1 (cada usuário pode possuir um Usuário do IAM criado). Em seguida, podemos agrupar esses usuários de acordo com o seu contexto (Grupos ou User Groups).

As funções não são estruturas de identificação que se estruturam numa relação 1x1 (eu utilizando a AWS sou um único usuário, mas posso ter múltiplas funções). Então comparativamente já identificamos uma diferença entre uma Role (Função) e um User (Usuário). A função não tem compromisso em identificar unicamente uma entidade. Ela pode ser reaproveitada em vários contextos que demandem a mesma função, por exemplo.

Por fim, a política é o documento onde indicaremos o que pode e o que não pode ser feito (allow ou deny) - posso vincular uma ou mais política(s) a um grupo de usuários ou uma função, por exemplo.

Exemplo de uma política:

Image description

Detalhamento estrutural completo baseado na documentação:

Image description

  • [Guia do Exame] Projetar uma estratégia de controle de acesso baseada em função (por exemplo, AWS Security Token Service [AWS STS], mudança de função, acesso entre contas).

O STS é um serviço muito interessante em cenários que precisamos de acessos temporários, com uma duração bem determinada, evitando que credenciais tenham validade indeterminada e possam se tornar riscos de segurança. Confira essa documentação que vai trazer uma introdução interessante de cenários em que precisamos utilizar credenciais de modo temporário.

STS

  • [Guia do Exame] Projetar uma estratégia de segurança para várias contas da AWS (por exemplo, AWS Control Tower, políticas de controle de serviço [SCPs]).

O Control Tower é um serviço da AWS que agrega vários outros serviços, como AWS Organizations, Catálogo de Serviços, IAM, etc. É uma maneira mais rápida e segura de manter uma padronização e boas práticas ao se pensar numa estrutura de múltiplas contas.

Image description

As políticas de controle de serviços podem ser definidas como uma forma de criar políticas de permissionamento que sejam aplicadas em toda a organização. Desse modo conseguimos estabelecer padrões e garantir segurança em múltiplas contas sem termos que nos preocupar em configurar uma por uma. Na imagem abaixo, reforço a importância de prestarmos muita atenção aos avisos de importante na documentação oficial da AWS, geralmente trazem cenários bastante importantes para pensar e nos ajudam na preparação para as certificações.

SCP

Exemplo de uma SCP:

Image description

  • [Guia do Exame] Determinar o uso apropriado de políticas de recursos para os serviços da AWS.

Políticas de recursos são documentos JSON que definem permissões para serviços da AWS, especificando quem pode acessar e o que pode ser feito com esses recursos. Elas são usadas para controlar o acesso a recursos específicos, como buckets do S3, filas do SQS e tópicos do SNS. Ao criar uma política de recursos, é importante seguir os princípios de menor privilégio, permitindo apenas as ações necessárias para usuários ou serviços específicos. Isso melhora a segurança ao restringir acessos desnecessários.

Exemplo:

Image description

  • [Guia do Exame] Determinar quando federar um serviço de diretório com funções do IAM.

Federar um serviço de diretório com funções do IAM é útil quando você precisa permitir que usuários existentes em um diretório corporativo, como o Active Directory, acessem recursos da AWS sem criar novas contas de usuário no IAM.

Isso é particularmente benéfico para organizações que já gerenciam identidades e acessos centralmente. A federação permite que os usuários façam login na AWS usando suas credenciais corporativas, facilitando a gestão de acesso e simplificando o processo de login.

Aqui estamos basicamente dizendo que vamos confiar num sistema de identidades já estruturado e vigente.

Por fim, reforço que este texto é bem introdutório e contém apenas algumas dicas e orientações para essa parte do Guia do Exame. Estou evoluindo o texto sempre que posso aqui, então aos poucos vou acrescentando conteúdos e trazendo mais dicas para essa seção. Desejo ótimos estudos a todos!

Top comments (0)