Gerenciamento de acesso

01

Quem é você e o que pode fazer? Autenticação e autorização

Pense em quando você entra no prédio de uma empresa. Na portaria, o crachá prova que você é você. Depois, em cada andar, o mesmo crachá é conferido de novo para ver se você pode entrar ali. A primeira conferência é a autenticação (confirmar quem você é), e a segunda é a autorização (decidir se você pode fazer aquilo). Na nuvem é igualzinho: são as mesmas duas etapas.

Quem envia uma requisição se chama entidade de segurança (security principal), ou simplesmente entidade principal. E entidades principais não são só pessoas. Um programa que faz backup toda noite e um servidor que processa pedidos também chamam o armazenamento e os bancos de dados da nuvem, então também são entidades principais. As pessoas provam quem são com uma senha e um segundo fator; os programas, com chaves ou credenciais temporárias (capítulo 4). Experimente trocar a situação na cena abaixo.

No padrão HTTP, 401 indica uma falha de autenticação (diga de novo quem você é) e 403, uma falha de autorização (sei quem você é, mas não deixo). Só que as APIs de nuvem nem sempre seguem essa divisão. Algumas devolvem 403 para os dois casos, e outras devolvem 401 para os dois. Por isso, em vez do número do status, olhe o código e a mensagem de erro para descobrir em qual porta você foi barrado.

A conta mais poderosa é a que você não usa

A conta de nível mais alto, criada quando você abre a conta na nuvem (a conta raiz ou principal, ou o administrador máximo), pode fazer tudo — até mudar os dados de cobrança ou encerrar a conta. Por isso você ativa a MFA nela, guarda a conta no cofre e faz o trabalho do dia a dia com contas separadas, que têm só as permissões necessárias. Se essa conta for comprometida, nenhuma configuração de permissão vai salvar você.

Você viu a porta que confere quem você é. Mas, se os funcionários usam dezenas de apps, será que é preciso construir essa porta em cada um deles?

02

Uma identidade para tudo: SSO, federação, MFA e acesso condicional

Dê a cada app as próprias contas e senhas, e as pessoas acabam com mais senhas do que conseguem lembrar — então repetem a mesma em todo lugar. Quando alguém sai da empresa, é preciso passar app por app apagando a conta, e, se você esquecer um só, aquela porta continua aberta. Por isso as identidades ficam reunidas em um único lugar: o provedor de identidade (IdP). Você faz login uma vez no IdP, e os apps deixam você entrar porque confiam na prova (um token) que o IdP emite. Isso é o SSO (Single Sign-On, logon único).

Se a empresa já tem um diretório corporativo, não é preciso cadastrar as pessoas de novo na nuvem. Dá para fazer a nuvem confiar nesse diretório. Confiar assim na verificação de identidade de outra organização se chama federação, e os padrões para trocar essa prova são o SAML 2.0 e o OIDC (OpenID Connect).

Uma senha só não basta: MFA

Senhas vazam fácil — por phishing ou porque a mesma senha vazou de outro site. A MFA (autenticação multifator) acrescenta à senha uma segunda verificação: algo que você tem (um app no celular, uma chave de segurança) ou algo que você é (a impressão digital). E nem toda MFA tem a mesma força. Um código por SMS ou os seis dígitos de um app autenticador podem ser digitados direto em um site falso e repassados, mas as chaves de segurança e as passkeys (FIDO2) só funcionam no site verdadeiro, por isso resistem ao phishing.

Decidir conforme a situação: acesso condicional

Não é preciso conferir com o mesmo rigor toda vez que alguém faz login. Quem entra com o notebook da empresa, no escritório, pode passar direto, enquanto um login de um país e de um dispositivo nunca vistos pode receber um pedido de MFA ou ser bloqueado. Olhar sinais como usuário, local, dispositivo e risco para decidir entre "permitir / permitir depois de uma verificação extra / bloquear" se chama acesso condicional. E só dá para definir essas condições em um lugar só se as identidades estiverem reunidas em um lugar só (o IdP).

Agora sabemos com certeza quem é você. Em seguida vem a segunda porta — "você pode fazer isso?". Vamos ler as políticas que decidem.

03

Como ler uma política: quem, o quê, onde e em que condições

Permissões são concedidas por meio de políticas. Cada provedor escreve as políticas de um jeito, mas os campos são quase sempre os mesmos: quem (a entidade principal), o quê (a ação), onde (o recurso), em que condições (a condição) e se é uma permissão ou uma negação.

Permitir | Quem: grupo de desenvolvedores
         | O quê: ler objetos, gravar objetos
         | Onde: todos os objetos do bucket de desenvolvimento
         | Condição: só quando entrou com MFA

Quando chega uma requisição, o sistema junta todas as políticas que valem para ela e confere uma por uma. As regras do veredito cabem em três linhas.

Na cena abaixo, experimente anexar e remover a política de permissão e a política de negação.

Dois lugares para anexar uma política: o lado da identidade e o lado do recurso

Você pode anexar uma política a uma identidade, como uma pessoa, um grupo ou uma função ("esta pessoa pode fazer estas coisas"), ou a um recurso, como um bucket de armazenamento ("estas entidades principais podem entrar neste bucket"). Uma política do lado do recurso sempre tem o campo "quem". As políticas do lado do recurso pesam mais quando você deixa entrar entidades principais de outras contas ou organizações, por isso o capítulo 5 trata só delas.

Não conceda pessoa por pessoa — agrupe: grupos e funções

Se você anexar políticas a cada pessoa, uma por uma, fica impossível de gerenciar à medida que a equipe cresce. Em vez disso, você coloca quem faz o mesmo trabalho em um grupo e anexa a política ao grupo, e monta pacotes de permissões como "somente leitura" ou "operador de banco de dados" na forma de funções. Isso se chama controle de acesso baseado em função (RBAC). Usar por cima disso atributos como tags como condição — "só recursos com a mesma tag de projeto" — se chama controle de acesso baseado em atributos (ABAC).

Políticas não são só para pessoas. Então como dar permissões a um programa que roda a noite toda sem ninguém por perto?