Identidade, recurso e limite

Usando a segurança da AWS para desenvolvedores

Rahul Singh

Technical Product Manager

Qual política manda?

A edição que não muda nada

  • Capítulo um: negação explícita, ou sem permissão
  • Aqui: uma terceira causa

Uma solicitação encontra uma pilha de três verificações de política, com um ponto de interrogação onde estaria a decisão.

Usando a segurança da AWS para desenvolvedores

Qual política manda?

Até três camadas

  1. Política de identidade no chamador
  2. Política de recurso no recurso
  3. Limite acima, só subtrai

Na sua conta, qualquer uma permitindo já basta

Negada por qualquer camada que encontrar

Uma solicitação flui de cima para baixo por três verificações em ordem: uma política de identidade, uma política de recurso e um limite de permissões, antes de chegar a um resultado permitido.

Usando a segurança da AWS para desenvolvedores

Dois lugares onde uma política pode viver

Política baseada em identidade

  • Anexada ao chamador
  • O que essa identidade pode fazer
  • Um crachá que você usa

Um papel no topo carrega uma política baseada em identidade, com espaço abaixo para o lado de recurso da mesma solicitação.

Usando a segurança da AWS para desenvolvedores

Dois lugares onde uma política pode viver

Política baseada em identidade

  • Anexada ao chamador
  • O que essa identidade pode fazer
  • Um crachá que você usa

Política baseada em recurso

  • Anexada ao recurso
  • Quem pode acessá-lo
  • Necessária para chamadores de outras contas

Um papel no topo carrega uma política baseada em identidade enquanto um bucket S3 abaixo carrega uma política baseada em recurso, e uma solicitação trafega entre eles.

Usando a segurança da AWS para desenvolvedores

Gerenciada para você ou por você

Dois tipos de políticas de identidade

  • Gerenciada pela AWS: de propriedade da AWS
  • Gerenciada pelo cliente: de sua propriedade

Duas cartas empilhadas comparam uma política gerenciada pela AWS, de propriedade da AWS e ampla por padrão, com uma política gerenciada pelo cliente, de sua propriedade e limitada à tarefa.

Usando a segurança da AWS para desenvolvedores

Gerenciada para você ou por você

Dois tipos de políticas de identidade

  • Gerenciada pela AWS: de propriedade da AWS
  • Gerenciada pelo cliente: de sua propriedade

 

Conveniência ou precisão

  • Gerenciada pela AWS: ganhe velocidade
  • Gerenciada pelo cliente: menor privilégio

Duas cartas empilhadas comparam uma política gerenciada pela AWS, de propriedade da AWS e ampla por padrão, com uma política gerenciada pelo cliente, de sua propriedade e limitada à tarefa.

Usando a segurança da AWS para desenvolvedores

Um limite restringe o que a política concede

Por que uma conta a anexa

  • Devs criam papéis, ninguém escala privilégios

Limite de permissões

  • Um teto para o que uma política concede
  • Efetivo: permitido por ambas

Três permissões concedidas por uma política de identidade passam para um limite de permissões que permite apenas ações S3, onde a permissão iam:CreateUser é bloqueada e as outras duas continuam para as permissões efetivas abaixo.

Usando a segurança da AWS para desenvolvedores

Um limite restringe o que a política concede

Por que uma conta a anexa

  • Devs criam papéis, ninguém escala privilégios

Limite de permissões

  • Um teto para o que uma política concede
  • Efetivo: permitido por ambas

Por que iam:CreateUser não fez nada

  • Só subtrai, nunca concede

Três permissões concedidas por uma política de identidade passam para um limite de permissões que permite apenas ações S3, onde a permissão iam:CreateUser é bloqueada e as outras duas continuam para as permissões efetivas abaixo.

Usando a segurança da AWS para desenvolvedores

Um limite restringe o que a política concede

Por que uma conta a anexa

  • Devs criam papéis, ninguém escala privilégios

Limite de permissões

  • Um teto para o que uma política concede
  • Efetivo: permitido por ambas

Por que iam:CreateUser não fez nada

  • Só subtrai, nunca concede

Política de sessão: uma sessão AssumeRole

Três permissões concedidas por uma política de identidade passam para um limite de permissões que permite apenas ações S3, onde a permissão iam:CreateUser é bloqueada e as outras duas continuam para as permissões efetivas abaixo.

Usando a segurança da AWS para desenvolvedores

Uma condição restringe o allow

Chave de condição

  • Restringe um allow ao contexto da solicitação

  • aws:SourceIp: a rede de origem

Uma permissão para ler um objeto S3 passa por uma faixa de condição listando uma chave de rede de origem e uma chave de tag do chamador, depois se divide em um caminho permitido onde o contexto corresponde e um negado onde não corresponde.

Usando a segurança da AWS para desenvolvedores

Uma condição restringe o allow

Chave de condição

  • Restringe um allow ao contexto da solicitação

  • aws:SourceIp: a rede de origem

  • aws:PrincipalTag: uma tag no chamador

ABAC: attribute-based access control

  • Uma política, muitos principais

Uma permissão para ler um objeto S3 passa por uma faixa de condição listando uma chave de rede de origem e uma chave de tag do chamador, depois se divide em um caminho permitido onde o contexto corresponde e um negado onde não corresponde.

Usando a segurança da AWS para desenvolvedores

Uma tabela, um cliente por vez

Uma tabela compartilhada

  • DynamoDB, uma chave de partição por cliente
  • Sem isolamento por si só

Um chamador do cliente A passa por uma condição de chaves iniciais para uma tabela DynamoDB compartilhada, onde as linhas do cliente A são retornadas e as do cliente B e C são bloqueadas.

Usando a segurança da AWS para desenvolvedores

Uma tabela, um cliente por vez

"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

Uma tabela compartilhada

  • DynamoDB, uma chave de partição por cliente
  • Sem isolamento por si só

Uma condição restringe

  • ForAllValues: cada chave fornecida deve corresponder
Usando a segurança da AWS para desenvolvedores

Uma tabela, um cliente por vez

"Action": ["dynamodb:Query", "dynamodb:GetItem", "dynamodb:Scan"],
"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

Uma tabela compartilhada

  • DynamoDB, uma chave de partição por cliente
  • Sem isolamento por si só

Uma condição restringe

  • ForAllValues: cada chave fornecida deve corresponder
A lacuna que fica: nem toda solicitação nomeia uma partição
  • dynamodb:Scan não fornece nenhuma, então nada falha
Usando a segurança da AWS para desenvolvedores

Vamos praticar!

Usando a segurança da AWS para desenvolvedores

Preparing Video For Download...