Conceda privilégio mínimo a um leitor de relatórios

Introdução

Um leitor de relatórios precisa do relatório de hoje enquanto os outros relatórios e a folha de pagamento permanecem privados. Você concederá essa leitura, restringirá seu escopo, testará o limite da permissão e a revogará antes da limpeza.

Use o que aprendeu sobre identidade de quem faz a chamada e ARNs em AWS Foundations e downloads de objetos no S3. Esta VM nova prepara a CLI e duas identidades: default gerencia o exercício; reader representa a tarefa. Trabalhe em /home/labex/project e compare solicitações com AWS View na parte superior.

Relação com as certificações

Visão geral do laboratório

Dê ao leitor acesso aos relatórios

Nesta etapa, você escreverá e associará uma política de identidade que permite ler relatórios. Uma política de identidade é associada a um usuário, grupo ou função. Ela descreve ações permitidas ou negadas; não contém chaves de acesso.

No S3, você já baixou o conteúdo de objetos. Aqui, a tarefa de relatórios precisa fazer o mesmo download com sua própria identidade restrita: o operador altera as permissões e o leitor testa o resultado. Os dados estão preparados para que você se concentre na autorização.

AWS Identity and Access Management (IAM) controla qual identidade pode executar uma ação sobre um recurso. Privilégio mínimo concede apenas o que uma tarefa precisa.

Um profile da AWS CLI seleciona credenciais e configurações; ele não concede permissões. Aqui, default é o operador do exercício, enquanto reader seleciona report-reader. Primeiro, confirme ambas as identidades. --profile reader seleciona a tarefa para um comando. get-caller-identity informa a identidade de quem faz a chamada sem exibir credenciais.

cd /home/labex/project

aws sts get-caller-identity --query Arn --output text

O ARN padrão termina com user/iam01-operator. Use esse profile de operador para administrar políticas; use o profile do leitor ao testar a tarefa. Este operador do laboratório está preparado para administração. Uma aplicação de relatórios em produção usaria uma função restrita, que você praticará depois.

aws sts get-caller-identity --profile reader --query Arn --output text

O ARN do leitor termina com user/report-reader. Um ARN, ou Amazon Resource Name, identifica um recurso. Para um objeto S3, ele inclui o bucket e a chave completa do objeto; apenas o ARN de um bucket não identifica um objeto dentro dele.

O leitor inicialmente não tem política. Teste uma leitura antes de conceder qualquer permissão:

aws s3api get-object --profile reader --bucket labex-iam01-reports --key reports/today.txt before.txt || true

Espere AccessDenied, não um download do relatório. || true permite que este comando intencionalmente malsucedido termine sem interromper uma sequência de comandos colada. Leia o erro: um erro de conexão não comprova uma negação do IAM.

Uma política JSON usa três campos essenciais: Effect é Allow ou Deny; Action nomeia uma operação de serviço; Resource limita qual ARN essa operação pode afetar. s3:GetObject permite ler bytes de objetos. O * abaixo corresponde a chaves de objetos no prefixo reports/, incluindo hoje e ontem. Ele não corresponde a private/ nem a outro bucket. Version seleciona a linguagem da política, não a versão do relatório.

O here-document seguinte grava as linhas entre os marcadores JSON em report-policy.json. > substitui esse arquivo local, e o marcador entre aspas impede o shell de expandir seu conteúdo.

cat > report-policy.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::labex-iam01-reports/reports/*"
    }
  ]
}
JSON

Apenas escrever um arquivo não autoriza o leitor. put-user-policy associa uma política inline, uma política armazenada diretamente neste usuário. --policy-name identifica essa política; usar o mesmo nome depois a atualiza. file:// indica à CLI que leia o documento do arquivo local.

aws iam put-user-policy \
  --user-name report-reader \
  --policy-name ReportRead \
  --policy-document file://report-policy.json

Uma atualização bem-sucedida normalmente não exibe saída. Agora solicite os relatórios usando as credenciais do leitor. O último argumento é o arquivo de destino local.

aws s3api get-object \
  --profile reader \
  --bucket labex-iam01-reports \
  --key reports/today.txt today.txt

cat today.txt

Espere Daily orders: 145. Campos da resposta S3, como ETag, identificam o objeto baixado; o próprio arquivo contém os bytes do relatório.

aws s3api get-object \
  --profile reader \
  --bucket labex-iam01-reports \
  --key reports/yesterday.txt yesterday.txt

Ontem também é bem-sucedido porque a política cobre todo o prefixo de relatórios. O negócio precisa apenas do relatório de hoje, portanto você reduzirá esse escopo agora.

Restrinja o recurso ao relatório de hoje

Nesta etapa, você substituirá uma concessão por prefixo por um ARN de objeto e comprovará que os outros recursos continuam inacessíveis. Uma negação implícita significa que nenhuma política aplicável permite a solicitação. Você não precisa de um Deny separado para cada objeto não relacionado.

Substitua a política local. A única mudança é Resource: a chave exata reports/today.txt substitui reports/*.

cat > report-policy.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::labex-iam01-reports/reports/today.txt"
    }
  ]
}
JSON

Atualize a mesma política inline no mesmo leitor. Editar o arquivo não atualiza IAM até você enviar este comando.

aws iam put-user-policy \
  --user-name report-reader \
  --policy-name ReportRead \
  --policy-document file://report-policy.json

Leia a política armazenada. --query PolicyDocument seleciona o documento da resposta; não altera as permissões.

aws iam get-user-policy \
  --user-name report-reader \
  --policy-name ReportRead \
  --query PolicyDocument

Confira que Resource termina em reports/today.txt. Depois, teste o leitor novamente.

aws s3api get-object \
  --profile reader \
  --bucket labex-iam01-reports \
  --key reports/today.txt today.txt

O relatório necessário ainda é baixado. Cada solicitação seguinte deve falhar com AccessDenied porque seu ARN de objeto não corresponde à concessão.

aws s3api get-object --profile reader --bucket labex-iam01-reports --key reports/yesterday.txt yesterday-denied.txt || true

aws s3api get-object --profile reader --bucket labex-iam01-reports --key private/payroll.txt payroll-denied.txt || true

aws s3api get-object --profile reader --bucket labex-iam01-reference --key reference.txt reference-denied.txt || true

Esses objetos existem; o operador pode lê-los. Uma resposta NoSuchKey diagnosticaria um objeto ausente, enquanto estes erros de permissão demonstram o limite de recursos do leitor. No AWS View, hoje está Readable e os outros três objetos estão Denied. Esta visualização envia solicitações efetivas de leitura como o mesmo leitor.

Distinga uma negação explícita de um Allow ausente

Nesta etapa, você protegerá explicitamente o prefixo privado e testará o limite de ações. Uma negação explícita é uma instrução Deny correspondente. Ela tem precedência sobre um Allow de outra política de identidade aplicável. A ordem das instruções não faz um Allow prevalecer sobre ela.

Adicione uma segunda instrução mantendo a concessão exata de leitura. s3:* corresponde a todas as ações S3, mas este Deny está limitado a objetos sob o prefixo private/ deste bucket. Ele não nega acesso ao relatório de hoje.

cat > report-policy.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::labex-iam01-reports/reports/today.txt"
    },
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::labex-iam01-reports/private/*"
    }
  ]
}
JSON

aws iam put-user-policy \
  --user-name report-reader \
  --policy-name ReportRead \
  --policy-document file://report-policy.json

O Deny reforça o limite privado. Para observar sua precedência, associe temporariamente uma segunda concessão de leitura a este bucket. Este é um teste controlado; remova-a imediatamente depois.

cat > temporary-read.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam01-reports/*"}]}
JSON

aws iam put-user-policy \
  --user-name report-reader \
  --policy-name TemporaryRead \
  --policy-document file://temporary-read.json

aws s3api get-object --profile reader --bucket labex-iam01-reports --key private/payroll.txt payroll-denied.txt || true

Espere AccessDenied mesmo que TemporaryRead permita esta chave. A negação explícita correspondente prevalece. Remova a concessão temporária para restaurar o privilégio mínimo.

aws iam delete-user-policy --user-name report-reader --policy-name TemporaryRead

Uma concessão de leitura não permite gravações. upload.txt é uma substituição não aprovada fornecida. put-object tenta armazenar seus bytes na chave de hoje, e o leitor deve ser recusado.

aws s3api put-object --profile reader --bucket labex-iam01-reports --key reports/today.txt --body upload.txt || true

Espere AccessDenied para PutObject; não trate arquivos ausentes ou falhas do serviço como esse resultado. Leia hoje novamente para confirmar que a gravação malsucedida não o alterou.

aws s3api get-object \
  --profile reader \
  --bucket labex-iam01-reports \
  --key reports/today.txt today.txt

cat today.txt

Ele ainda deve conter Daily orders: 145. Leia a política final e confirme o Allow restrito e o Deny privado.

aws iam get-user-policy \
  --user-name report-reader \
  --policy-name ReportRead \
  --query PolicyDocument

Revogue o acesso e limpe os recursos do exercício

Nesta etapa, você retirará a política do leitor e removerá apenas o bucket de relatórios deste exercício. Limpeza de políticas IAM e limpeza de dados são separadas: excluir uma política não exclui objetos, e excluir objetos não revoga credenciais.

Use o operador padrão para remover ReportRead. delete-user-policy remove uma política inline pelo nome.

aws iam delete-user-policy --user-name report-reader --policy-name ReportRead

aws iam list-user-policies --user-name report-reader

Espere que PolicyNames esteja vazio. Enquanto o relatório ainda existe, teste que o leitor perdeu o acesso.

aws s3api get-object --profile reader --bucket labex-iam01-reports --key reports/today.txt revoked.txt || true

Espere AccessDenied. Agora remova as três chaves exatas do exercício como operador. O bucket de referência pertence ao recurso preparado da plataforma e deve permanecer intacto.

aws s3api delete-object --bucket labex-iam01-reports --key reports/today.txt

aws s3api delete-object --bucket labex-iam01-reports --key reports/yesterday.txt

aws s3api delete-object --bucket labex-iam01-reports --key private/payroll.txt

aws s3api list-objects-v2 --bucket labex-iam01-reports

Confira que KeyCount é 0 e que nenhum objeto aparece em Contents. Esta resposta autenticada bem-sucedida mostra que o bucket do exercício está vazio antes da exclusão.

aws s3api delete-bucket --bucket labex-iam01-reports

aws s3api list-buckets --query 'Buckets[].Name'

Resta apenas labex-iam01-reference. Confirme seus bytes originais:

aws s3api get-object --bucket labex-iam01-reference --key reference.txt reference.txt

cat reference.txt

Espere Platform reference: keep. AWS View agora mostra No inline policy e Reports bucket removed. Uma indisponibilidade do serviço seria mostrada como indisponível, não como uma limpeza bem-sucedida. As identidades descartáveis preparadas são recuperadas quando seu ambiente de laboratório termina; você removeu as permissões criadas pelo aluno e os dados do exercício preservando o recurso fornecido não relacionado.

Resumo

Você associou e revisou uma política de identidade IAM, usou Action e Resource para restringir uma tarefa de relatórios, comparou negações implícitas e explícitas e comprovou que permissão de leitura não autoriza uma gravação. Você revogou a política e removeu apenas os dados do exercício. Teste tanto o sucesso pretendido quanto as operações proibidas sempre que revisar acesso; apenas uma política armazenada não comprova que uma aplicação está corretamente autorizada.

Para aprofundar o tema, consulte a documentação da AWS: Tipos de políticas e declarações de permissões IAM.