00:00:00
Então vamos começar com o IAM. Primeiro,
00:00:02
há muitas coisas que você já deve saber
00:00:04
sobre o IAM, então não vou abordar o
00:00:05
básico, vou apenas tentar lembrar você
00:00:08
do que se trata. Os usuários têm
00:00:09
credenciais de longo prazo e, portanto,
00:00:11
são usuários da
00:00:13
AWS. Você pode agrupá-los e também pode
00:00:15
definir funções que serão credenciais de
00:00:17
curto prazo. E em seguida, usamos o
00:00:19
serviço STS para endossar essas funções
00:00:21
e obter credenciais temporárias a partir
00:00:23
delas para realizar as ações que as
00:00:25
funções estão autorizadas a fazer. Um
00:00:27
tipo específico de função que temos
00:00:28
visto ao longo dos cursos é a função de
00:00:30
instância ECDUS, onde ela vai usar o
00:00:33
serviço de metadados ECers para obter
00:00:35
essas credenciais de curto prazo em uma
00:00:37
instância EC2. E você pode atribuir
00:00:39
apenas uma função por vez para essa
00:00:40
instância, mas dessa forma sua instância
00:00:41
pode acessar, por exemplo, um bucket
00:00:43
stress ou uma tabela dinamo DB e assim
00:00:45
por diante. Há também funções de serviço
00:00:47
que são atribuídas diretamente aos
00:00:49
serviços. Portanto, se você tiver um
00:00:51
serviço como API Gateway ou Code Deploy
00:00:53
que precise realizar uma ação em um
00:00:55
grupo de escalonamento automático ou uma
00:00:56
função lâmbida ou algo assim, então essa
00:00:58
função é necessária. O serviço deve ter
00:01:00
um papel e esse papel deve ser apto e
00:01:02
preparado para realizar todas as ações
00:01:04
necessárias. OK? E então, finalmente,
00:01:08
temos papéis de conta cruzada e esses
00:01:10
papéis serão realmente úteis caso você
00:01:12
precise acessar outra conta para
00:01:14
realizar ações nessa outra conta. Você
00:01:16
nunca compartilha as credenciais de
00:01:18
usuários entre contas. Você sempre
00:01:20
permite assumir papéis e veremos isso em
00:01:22
detalhes neste
00:01:23
curso. Agora, há políticas no Yam que
00:01:26
definem o que um papel ou usuário pode
00:01:29
fazer. E assim, você tem três tipos.
00:01:31
Você tem as gerenciadas pela AWS, que
00:01:33
são políticas definidas pela AWS, que
00:01:36
podem mudar ao longo do tempo, mas que
00:01:37
farão algo muito específico, gerenciadas
00:01:40
pelo cliente, que são políticas que você
00:01:42
cria e pode atribuir a múltiplos
00:01:44
usuários ou papéis e pode atualizá-las
00:01:47
ao longo do tempo, ou políticas inline,
00:01:50
que são políticas atribuídas a um
00:01:52
usuário ou papel específico, e podem
00:01:54
evoluir ao longo do tempo, mas não podem
00:01:56
ser compartilhadas entre usuários ou
00:01:58
papéis.
00:02:00
Faremos uma discussão sobre as políticas
00:02:01
baseadas em recursos. Então isso é
00:02:03
quando você tem uma política de bucket
00:02:04
S3 ou uma política SQSQ e assim por
00:02:07
diante, o que nos permitiria realizar
00:02:08
algumas coisas realmente interessantes
00:02:10
padrões e veremos isso nesta aula.
00:02:12
Então, como é uma política IAM? Bem,
00:02:15
antes de tudo, será um documento Jon e
00:02:18
terá quatro ou cinco elementos: efeitos,
00:02:21
ação, recursos, condições e às vezes
00:02:24
variáveis de política. Faremos uma
00:02:26
análise aprofundada de todos eles, mas a
00:02:28
ideia é que uma política Jon se pareça
00:02:30
com isso. E então temos alguma
00:02:32
declaração, por exemplo, permitir que o
00:02:34
EC anexe volume. E para desanexar volume
00:02:37
no recurso, que são todas as instâncias
00:02:38
EC2. E a condição é string igual a tag
00:02:41
de recurso do Departamento de
00:02:42
Desenvolvimento, o que significa que
00:02:43
apenas as instâncias EC2 marcadas com
00:02:46
essa tag podem ser anexadas ou
00:02:47
desanxadas ao volume e assim por diante.
00:02:50
Então isso é bastante específico e você
00:02:52
pode ficar muito, muito louco com as
00:02:53
políticas de IAM, mas é assim que toda a
00:02:55
AWS funciona e já sabemos disso. Se
00:02:58
houver uma negação explícita em sua
00:03:00
política IAM, então você terá prioridade
00:03:02
sobre qualquer permissão. O que
00:03:04
significa que as negações explícitas
00:03:06
sempre têm a maior prioridade e teremos
00:03:09
uma palestra para entender como as
00:03:11
políticas IAM e tudo o mais são
00:03:13
analisadas em
00:03:14
sequência. OK? Então, a melhor prática
00:03:17
que conhecemos é usar o menor privilégio
00:03:19
para a segurança máxima. Isso quer dizer
00:03:21
que você deve garantir que as políticas
00:03:22
IAM sejam permitidas apenas para o que
00:03:24
precisam fazer e não mais.
00:03:27
Algumas ferramentas que podemos usar
00:03:28
para garantir isso são o consultor de
00:03:30
acesso IAM, onde você pode ver todas as
00:03:34
permissões que concedeu a uma política
00:03:36
IAM e quando foram acessadas pela última
00:03:38
vez. Portanto, caso você tenha uma
00:03:41
política ou algo que não foi usado por
00:03:43
um ano, talvez valha a pena removê-la da
00:03:45
política IAM para garantir que haja
00:03:47
menos privilégio. OK. Outro é o
00:03:51
analisador de acesso e isso é para
00:03:53
analisar recursos compartilhados com
00:03:55
entidades externas. como buckets stress
00:03:57
e permitirá que você veja se outros as
00:04:00
contas têm acesso ao seu bucket s free.
00:04:02
Pode ser que haja algo inesperado aqui e
00:04:04
você deseja garantir que esse bucket
00:04:06
Sjaido, OK? Se você não está muito por
00:04:09
dentro da política IAM, eu sugiro que
00:04:11
você acesse este URL para que possa
00:04:12
conferir algumas delas e entender
00:04:14
melhor, mas eu imagino que até agora
00:04:16
você já conhece como elas são e como
00:04:19
funcionam.
00:04:21
Algumas políticas IAM comuns que vamos
00:04:23
abordar incluem o acesso administrativo,
00:04:26
que significa que tudo deve ser
00:04:28
permitido em qualquer recurso. E assim,
00:04:30
esta é uma política que você precisa
00:04:32
especificar. Portanto, por padrão, se
00:04:34
você não definir nada em uma política
00:04:36
IAM, tudo será negado. Mas se você
00:04:38
adicionar essa declaração que é permitir
00:04:40
ação estrela, recurso estrela, então
00:04:42
tudo será permitido e isso lhe dará
00:04:43
acesso administrativo. E por ser algo
00:04:45
comum para administradores, a AWS
00:04:48
disponibiliza isso como uma política
00:04:51
gerenciada. Outra política interessante,
00:04:53
um pouco menos privilegiada, é chamada
00:04:55
de acesso de usuário power da AWS. E
00:04:58
assim, na primeira, nós afetamos: O
00:05:00
efeito é liberar. Não há ação nas
00:05:02
organizações e contas EAM. Portanto,
00:05:06
isso implica que não será permitido.
00:05:08
Nada pode ser executado nas organizações
00:05:11
e contas IAM e também ainda permitirá
00:05:15
algumas ações IAM, como criar um papel
00:05:18
de serviço, deletar papel de serviço,
00:05:20
listar papéis, descrever a organização e
00:05:22
listar regiões. Então você pode estar se
00:05:24
perguntando por não há uso de ação do
00:05:26
lado esquerdo e não apenas efeito de
00:05:28
negação? Então, se você usar efeito de
00:05:31
negação e depois especificar essas três
00:05:34
ações e então você diz efeito permitir e
00:05:37
essas cinco ações, essas cinco ações
00:05:39
serão negadas automaticamente devido a
00:05:42
uma negação explícita à esquerda. Aqui
00:05:44
temos um caso de uso muito interessante,
00:05:47
caso não queiramos negar tudo, pois
00:05:49
queremos permitir explicitamente algumas
00:05:52
coisas.
00:05:54
Então, podemos usar a não ação ao invés
00:05:56
de negação para permitir que essas duas
00:05:58
coisas
00:05:59
coexistam, OK? Em seguida, condições em
00:06:02
políticas e am. Então, é assim que uma
00:06:05
condição se pareceria. Temos um operador
00:06:07
de condição, uma chave de condição e um
00:06:09
valor de condição. E assim podemos fazer
00:06:11
muitas coisas malucas com condições. A
00:06:13
primeira será um operador de string.
00:06:15
Então, por exemplo, você está dizendo:
00:06:16
"Quero que minha tag principal seja
00:06:18
categoria de trabalho, administrador de
00:06:20
usuário IAM". Isso é quando você olha
00:06:22
para tags. Ou você pode olhar, por
00:06:24
exemplo, um prefixo stress para uma
00:06:26
política de bucket strace para dizer que
00:06:28
queremos que os usuários acessem apenas
00:06:29
um diretório inicial específico. Existem
00:06:32
operadores numéricos onde podemos
00:06:34
verificar se é igual, igual então ou não
00:06:36
igual e assim por diante. Datas para
00:06:39
olhar, comparar datas. Isso é muito útil
00:06:41
quando você quer fornecer acesso
00:06:42
temporário a um serviço específico.
00:06:44
Boleanos. O que será muito útil, por
00:06:47
exemplo, se você quiser avaliar SSL como
00:06:49
transporte seguro verdadeiro e também
00:06:52
quando você quiser verificar MFA usando
00:06:54
autenticação multifator presente
00:06:56
verdadeiro. Há também uma condição de
00:06:58
endereço IP ou não IP, endereço de
00:07:00
condição. E essas condições serão
00:07:02
realmente úteis para buckets, políticas
00:07:04
de SR bucket, por exemplo, ou qualquer
00:07:05
tipo de política que queremos garantir
00:07:07
que apenas um tipo específico de IP de
00:07:09
origem possa acessar um serviço. Então,
00:07:12
podemos ter um endereço IP, IP de origem
00:07:14
igual. E aqui temos um bloco
00:07:17
SIDR/24. E finalmente podemos olhar para
00:07:20
ARN igual ARN como e a condição nula,
00:07:23
que verifica se algo é nulo ou
00:07:26
não. Agora, neste momento, eu só quero
00:07:28
tranquilizá-lo. Você não precisa se
00:07:30
lembrar de todas essas coisas, certo? Eu
00:07:31
só quero mostrar que essas coisas
00:07:33
existem para que você saiba que pode ter
00:07:34
políticas de IAN muito específicas, como
00:07:37
se o exame estiver pedindo para você
00:07:38
usar uma política de IAN como resposta a
00:07:40
um problema. Isso seria possível em vez
00:07:42
de usar, por exemplo, um script
00:07:43
personalizado, certo? Mas você não
00:07:46
precisa se lembrar exatamente de todas
00:07:47
essas coisas, das condições exatas e
00:07:49
assim por diante. Certo? Próximo.
00:07:52
Existem variáveis de política e tags que
00:07:53
são realmente muito poderosas. Uma que
00:07:56
vimos é o nome de usuário do AWS
00:07:57
precedido por cifrão e este é o mais
00:08:00
usado, por exemplo, em uma política de
00:08:02
bucket S3. Então temos o recurso meu
00:08:05
bucket
00:08:06
s3/ariável nome de usuário
00:08:08
AWS/asterisco. E o que isso faz é
00:08:10
permitir que seu nome de usuário realize
00:08:13
ações, todas as ações, apenas no prefixo
00:08:16
que começa com o nome de usuário
00:08:19
AWS. Isso significa que cada usuário
00:08:21
terá seu próprio pequeno diretório no
00:08:23
seu bucket S3. E esse é um uso muito
00:08:26
comum para isso. Existem algumas
00:08:28
variáveis de política e tags específicas
00:08:30
da AWS. Por exemplo, hora atual, hora de
00:08:33
emissão do token, tipo de principal,
00:08:35
transporte seguro, que é para SSL, IP de
00:08:37
origem, ID do usuário e ARN da instância
00:08:40
de origem. E estes são fornecidos pela
00:08:42
WS. Existem regras e tags de política
00:08:44
específicas de serviço, por exemplo,
00:08:46
prefixo S3, chaves máximas, endpo SNS,
00:08:49
protocolo SNS. E finalmente você pode
00:08:52
ter variáveis de política baseadas em
00:08:53
tags. Por exemplo, se você usar tag de
00:08:55
recurso barra nome da chave ou tag de
00:08:57
principal barra nome da chave e assim
00:08:59
por diante. Assim, você pode começar a
00:09:01
ter políticas de IAM muito poderosas e é
00:09:04
por isso que eu sugiro que você use o
00:09:05
link anterior para ver algumas delas e
00:09:07
tentar entendê-las para que você possa
00:09:09
realmente ver toda a gama do que pode
00:09:11
ser feito em Ian. OK? O que realmente
00:09:14
importa e é mais relevante para o exame
00:09:16
é a diferença entre os papéis de Ian e
00:09:18
as políticas de recursos. E pode não ser
00:09:20
claro qual é a diferença, mas há uma
00:09:22
diferença bem evidente. Então, temos
00:09:25
duas alternativas, certo? Podemos
00:09:27
associar uma política a um recurso, como
00:09:29
um bucket strace, em vez de associar, ou
00:09:31
usar um papel como um proxy. Aqui está
00:09:34
um exemplo. Temos um usuário na conta A
00:09:37
e ele está tentando acessar um bucket 3
00:09:39
na conta B. Agora, há duas formas de
00:09:42
fazer isso. A primeira maneira é usar um
00:09:44
papel na conta B e estaremos assumindo
00:09:47
esse papel a partir da conta A. Assim
00:09:50
que você assumir o papel na conta B, ele
00:09:52
terá as permissões necessárias para
00:09:53
acessar o bucket strace e isso
00:09:56
funcionará. Outra opção é usar uma
00:09:58
política de bucket strace. Na política s
00:10:01
rebucket, estamos dizendo tudo bem. O
00:10:03
usuário da conta A consegue acessar meu
00:10:06
S rebucket da Amazon na conta B.
00:10:09
E ambas as soluções permitem ao usuário
00:10:11
da conta A acessar o S rebucket na conta
00:10:14
B. Mas existe uma diferença realmente
00:10:17
muito
00:10:18
grande. Qual é? Quando você assume um
00:10:21
papel, seja como usuário, aplicativo ou
00:10:24
serviço, você renuncia a todas as suas
00:10:26
permissões originais e você vai assumir
00:10:28
as permissões atribuídas ao papel.
00:10:31
Isso quer dizer que antes, quando
00:10:33
assumimos o papel na conta B, a situação
00:10:36
laranja, quando o usuário da conta A
00:10:39
renuncia a todas as suas permissões na
00:10:41
conta A enquanto assume um papel na
00:10:44
conta B, a ideia é que ao assumir um
00:10:47
papel como usuário, aplicativo ou
00:10:49
serviço, você perde suas permissões
00:10:51
originais e assume as permissões do
00:10:53
papel.
00:10:54
E quando, por outro lado, uma política
00:10:56
baseada em recursos, então o princípio
00:10:59
não precisa ser abandonar permissões.
00:11:01
Então, quando usamos políticas de
00:11:02
recursos, aqui está um exemplo, um
00:11:04
exemplo complicado. Assim, temos um
00:11:06
usuário na conta A que precisa fazer uma
00:11:08
varredura em um dinamo DB na conta A,
00:11:10
que é sua própria conta, e depois enviar
00:11:12
o conteúdo para um bucket S3 na conta B.
00:11:15
Como você pode notar, o usuário precisa
00:11:17
atuar em duas contas. Assim, precisamos
00:11:19
de um papel IAM na conta A para que isso
00:11:21
funcione e também de uma política de
00:11:22
recursos no bucket S3 da conta B para
00:11:25
que isso aconteça. É um ótimo uso para
00:11:27
políticas de recursos. As políticas de
00:11:29
recursos são suportadas por muitos
00:11:31
serviços da AWS e estão aumentando. Por
00:11:34
exemplo, buckets S3 da Amazon, tópicos
00:11:36
SNS, filas SQS, funções lambida, backup
00:11:39
SR, EFS Glacer. Quero dizer, você verá a
00:11:42
lista aqui. Na verdade, é amplamente
00:11:44
suportado pela maioria dos recursos
00:11:45
significativos na AWS.
00:11:48
Vamos discutir os limites de permissão
00:11:50
do IAM. Existem limites de permissão
00:11:52
suportados para usuários e papéis, mas
00:11:54
não para grupos. Esta é uma
00:11:56
funcionalidade avançada que vai permitir
00:11:58
que você defina o máximo permissões que
00:12:00
uma entidade IAM pode obter. Então, um
00:12:02
exemplo vai ser muito mais fácil. Então,
00:12:04
por exemplo, digamos que anexamos este
00:12:06
limite de permissão IAM dizendo S3
00:12:08
estrela, Cloudwatch estrela e EC2
00:12:10
estrela. E então esta permissão IAM.
00:12:13
Então, através desta política IAM, nós
00:12:14
apenas permitimos IAM criar usuário
00:12:16
estrela, certo?
00:12:17
Bem, essas duas coisas juntas vão se
00:12:19
misturar e então o que acontecerá é que
00:12:21
não haverá permissões. Bem, porque mesmo
00:12:23
que a ação IAM criar usuário seja
00:12:25
autorizada no lado direito, porque os
00:12:27
limites de permissão IAM só permitem as
00:12:28
permissões em S3, Cloudwatch e S2, então
00:12:32
o usuário não terá
00:12:34
permissões. Portanto, os limites de
00:12:36
permissão IAM também podem ser usados
00:12:37
com SCP da organização AWS. Então, se
00:12:39
você olhar para o SCP, no meio temos a
00:12:42
interseção do SCP, o limite de permissão
00:12:45
e as políticas baseadas em identidade.
00:12:47
Portanto, você usaria limite de
00:12:49
permissão do Yam quando quiser delegar
00:12:51
responsabilidade a um não administrador
00:12:52
dentro de seus limites de permissão, por
00:12:54
exemplo, para criar novos usuários do
00:12:55
Yam, ou para permitir que os
00:12:57
desenvolvedores atribuam políticas a si
00:12:58
mesmos e gerenciem suas próprias
00:12:59
permissões, enquanto se assegura de que
00:13:01
eles só podem realizar essas ações
00:13:03
dentro de seus direitos especiais,
00:13:05
evitando que se elevem. E também é muito
00:13:08
útil restringir um usuário específico em
00:13:10
vez de aplicar uma restrição em toda a
00:13:12
conta com organizações e SCP. Então é
00:13:15
isso sobre IAM. Espero que você saiba e
00:13:18
até mais.
