Boas práticas para o uso de api-keys

A Magalu Cloud adota um modelo de autenticação flexível, permitindo que usuários pessoa física (PF) transitem entre diferentes contas de pessoa jurídica (PJ) com um único identificador, e utilizem API-keys pessoais. Este paradigma, embora prático, difere significativamente de abordagem de controle de acesso. Ou seja, uma API-key pessoal entre diferentes organizações não é um conceito padrão, e o uso de chaves de API em contextos empresariais está predominantemente atrelado a contas de serviço.

A Portabilidade da API-Key Pessoal

A dúvida central sobre a possibilidade de um usuário criar uma API-key pessoal e utilizá-la para se autenticar em diferentes organizações (tenants) encontra-se numa prática majoritariamente negativa. O modelo de segurança e governança privilegiam o isolamento e o controle granular de acesso em cada organização.

O Domínio das Contas de Serviço para API-Keys em Ambientes Corporativos

Essa segunda abordagem, sobre a obrigatoriedade de associar API-keys a uma conta de serviço (service account) em um contexto organizacional (conta PJ), identifica-se melhores práticas de segurança dos principais provedores de nuvem.

O uso de credenciais de usuários humanos (como API-keys pessoais) para aplicações e automações é fortemente desaconselhado por questões de segurança. A rotação de chaves se torna complexa, o gerenciamento de permissões é menos granular e a revogação de acesso em caso de comprometimento é mais difícil.

Em suma, embora a Magalu Cloud apresente um modelo de autenticação que visa a simplicidade e a flexibilidade para o usuário individual, a boa prática é adotar uma abordagem mais segmentada e focada em segurança granular. Na MGC, a identidade de um usuário e suas credenciais estão atreladas a uma organização específica (tenant), e o acesso entre diferentes entidades é gerenciado por mecanismos de delegação. E, para a autenticação de aplicações e serviços, o padrão é claro: o uso de identidades dedicadas, como contas de serviço (service accounts), é a prática recomendada e, na maioria dos cenários corporativos, a única abordagem viável e segura.

Ou seja, se eu criar uma api-key da minha conta pessoal (PF) e utilizar para me autenticar em diversos tenants (organizações PJ) não será possível. Certo? Para isso eu necessito que a api-key esteja relacionada ao tenant, idealmente, estar associada a uma conta de serviço daquela respectiva organização. É isso mesmo?

Exato, essa é a prática de segurança e identidade. Usuários se autenticam vinculados a uma credencial e apikeys vinculadas a contas de serviço. Tanto o usuário, como uma conta de serviço, podem estar vinculados a uma ou mais organizações - porém, as diferenciando pelo tenant.

Para reforçar:

1. Uma API-Key Pessoal é Intransferível: A chave de acesso (ou API-key) que você gera na sua conta pessoal é uma credencial de segurança vinculada estritamente àquela conta ou tenant. Não é uma boa prática ela funcionar como uma "chave mestra" que pode ser usada para acessar recursos de diferentes organizações. O modelo de segurança deverá ser desenhado para garantir o isolamento e o controle de acesso, impedindo que uma credencial de um ambiente autentique em outro.

2. Acesso Programático a uma Organização Requer Credenciais da Própria Organização: Para que um script, aplicação ou qualquer automação acesse os recursos de uma organização (conta PJ), ele precisa se autenticar com credenciais geradas dentro daquela organização. A maneira ideal e mais segura de fazer isso é através de uma conta de serviço (service account).

Criar uma chave de acesso ligada a uma conta de serviço garante que a aplicação tenha apenas as permissões necessárias para sua função (princípio do menor privilégio) e que seu ciclo de vida (criação, rotação e exclusão de chaves) seja gerenciado de forma independente das credenciais de um usuário humano.

Então em quais ocasiões eu posso usar uma api-key atrelada ao meu usuário pessoal?

No cenário onde é criado uma api-key vinculada apenas ao usuário pessoal, idealmente, é usado apenas na conta pessoal (PF) cadastrada no provedor cloud. Ou seja, se o usuário tem um conta pessoal na cloud e nessa conta tem vários recursos e serviços, o uso da api-key pessoal pode ser considerado válido para autenticação. Porém, caso o usuário esteja associado a uma conta de organização, tenant (PJ), é imprescindível que sua autenticação aconteça por meio de access token. E caso queira utilizar api-key, essa mesma chave gerada por ele deverá estar associada a uma conta de serviço (service account). Vale ressaltar que a mesma service account pode ter várias api-keys associadas a ela.