The company owns the accounts, not the people who created them.

O domínio é a raiz de tudoThe domain is the root of everything

Quase toda conta de uma empresa (AWS, Cloudflare, GitHub, Vercel, o banco, o contador) é criada com um e-mail. Quase todo "esqueci a senha" manda um link para esse e-mail. E o e-mail @suaempresa.com só funciona porque alguém controla o DNS do domínio, que por sua vez depende da conta no registrador. É uma corrente: quem controla o elo de cima controla todos os de baixo.Almost every company account (AWS, Cloudflare, GitHub, Vercel, the bank, the accountant) is created with an email address. Almost every "forgot password" sends a link to that address. And @yourcompany.com only works because someone controls the domain's DNS, which in turn depends on the account at the registrar. It is a chain: whoever controls a link controls every link below it.

Daí saem as três ideias que guiam o resto da nota:Three ideas follow from that and guide the rest of this note:

• A empresa é a titular do domínio, do e-mail e das contas, no nome e no CNPJ dela, não no CPF ou no Gmail de alguém.The company is the holder of the domain, the email and the accounts, in its own legal name, not in someone's personal ID or Gmail.
• Pessoas recebem acesso, cada uma com o próprio login e só com as permissões de que precisa. Ninguém compartilha senha.People are granted access, each with their own login and only the permissions they need. Nobody shares a password.
• Sempre existe um caminho de volta: mais de um administrador, códigos de recuperação guardados, e um inventário que diz onde está cada coisa.There is always a way back in: more than one admin, stored recovery codes, and an inventory that says where everything is.

Comprando o domínioBuying the domain

Onde registrarWhere to register

O detalhe técnico da Cloudflare (zonas, nameservers, SSL) está na nota Cloudflare: domínio, R2 e SSL. Aqui o foco é de quem é o domínio.The Cloudflare details (zones, nameservers, SSL) are in the Cloudflare: domain, R2 and SSL note. Here the focus is who owns the domain.

Registre certo desde o primeiro diaRegister it right from day one

• Titular (registrant) = a empresa. Razão social e CNPJ nos dados do registro. Se um sócio registrou no nome próprio "só para começar", transfira a titularidade agora, enquanto todos ainda se falam bem.Registrant = the company. Legal name and company ID in the registration data. If a founder registered it in their own name "just to get started", transfer the holder now, while everyone is still on good terms.
• Conta do registrador com e-mail da empresa (um grupo como dominios@ ou admin@), e não com o e-mail pessoal de quem comprou. Até o e-mail próprio existir, use um provisório e troque assim que ele funcionar.Registrar account on a company address (a group like domains@ or admin@), not the buyer's personal email. Until your own email exists use a temporary one, and switch as soon as it works.
• Renovação automática + cartão da empresa, e registro por vários anos. Domínio que expira é o jeito mais bobo de derrubar site e e-mail ao mesmo tempo.Auto-renew + company card, and register for several years. An expired domain is the silliest way to take down the site and the email at once.
• Trava de transferência (registrar lock) ligada e MFA na conta do registrador. É a conta mais valiosa da empresa e costuma ser a menos protegida.Transfer lock (registrar lock) on and MFA on the registrar account. It is the most valuable account the company has and usually the least protected.
• Compre as variações óbvias (.com e .com.br, por exemplo) e redirecione para o principal; dificulta phishing com o seu nome.Buy the obvious variations (.com and your country TLD, for example) and redirect them to the main one; it makes phishing with your name harder.

E-mail profissionalProfessional email

Com o domínio em mãos, você escolhe quem vai hospedar as caixas de e-mail. O provedor também vira, na prática, o seu provedor de identidade: as contas nome@empresa.com são as que as pessoas usam para entrar em todo o resto (inclusive via SSO).With the domain in hand, you choose who will host the mailboxes. That provider also becomes, in practice, your identity provider: the name@company.com accounts are what people use to sign in to everything else (including through SSO).

Configurando o Google Workspace (o caminho mais comum)Setting up Google Workspace (the most common path)

1. Assine com o domínio da empresa. A primeira conta criada vira super admin: use um nome de função, como admin@empresa.com, e não joao@.Sign up with the company domain. The first account created becomes super admin: use a role name like admin@company.com, not john@.
2. Verifique o domínio com o registro TXT que o Google mostra.Verify the domain with the TXT record Google shows you.
3. Aponte o MX para o Google e publique SPF, DKIM (gerado no Admin console) e DMARC. Sem os três, seu e-mail cai no spam, e Google, Yahoo e Microsoft já exigem autenticação de quem envia em volume.Point MX to Google and publish SPF, DKIM (generated in the Admin console) and DMARC. Without all three your mail lands in spam, and Google, Yahoo and Microsoft already require authentication from bulk senders.
4. Crie uma conta por pessoa e grupos para funções (financeiro@, seguranca@, infra@). Grupo não é caixa compartilhada com senha: é uma lista de entrega, e você troca os membros sem trocar nenhuma senha.Create one account per person and groups for roles (billing@, security@, ops@). A group is not a shared mailbox with a password: it is a distribution list, and you change members without changing any password.
5. Em Segurança, obrigue a verificação em duas etapas para todos, com um período de adesão curto.Under Security, enforce 2-Step Verification for everyone, with a short enrollment period.

# DNS records for Google Workspace (example.com)
example.com.          MX   1  smtp.google.com.
example.com.          TXT  "v=spf1 include:_spf.google.com ~all"
google._domainkey     TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."     # copied from Admin console
_dmarc                TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

# Start DMARC at p=none to watch the reports, then move to quarantine, then reject.
# A domain that never sends email should say so, so nobody can spoof it:
#   TXT "v=spf1 -all"   and   _dmarc TXT "v=DMARC1; p=reject"

O que cada registro faz e como o e-mail viaja está em SMTP: como o e-mail viaja.What each record does and how email travels is covered in SMTP: how email travels.

Os endereços de funçãoRole addresses

A regra prática: contas em provedores são abertas com endereços de função, nunca com o de uma pessoa. Pessoas saem; a função fica.The rule of thumb: provider accounts are opened with role addresses, never a person's address. People leave; the role stays.

Contas nos provedoresProvider accounts

Todo provedor sério separa dois conceitos: o usuário (uma pessoa que faz login) e a organização (chamada de conta, time, team ou organization), que é quem possui os recursos e paga a fatura. O erro clássico é criar tudo dentro do usuário pessoal do fundador, porque é o que aparece primeiro depois do cadastro.Every serious provider separates two concepts: the user (a person who signs in) and the organization (called account, team or organization), which owns the resources and pays the bill. The classic mistake is creating everything inside the founder's personal user, because that is what shows up right after sign-up.

Cloudflare

• Crie a conta com admin@. Zonas (domínios), Workers, R2 e Pages pertencem à conta, não ao usuário.Create the account with admin@. Zones (domains), Workers, R2 and Pages belong to the account, not the user.
• Convide cada pessoa em Manage Account → Members, com o seu próprio e-mail, e escolha papéis: Super Administrator para no máximo dois, Administrator ou papéis restritos (DNS, Analytics, Billing) para o resto, opcionalmente limitados a um domínio.Invite each person under Manage Account → Members with their own email, and pick roles: Super Administrator for two people at most, Administrator or narrower roles (DNS, Analytics, Billing) for everyone else, optionally scoped to one domain.
• Para automação, API Tokens com escopo (uma zona, uma permissão), nunca a Global API Key.For automation, scoped API Tokens (one zone, one permission), never the Global API Key.

AWS

• Cada conta AWS tem um usuário root preso a um e-mail. Use um grupo da empresa (aws-root+prod@), ative MFA no root (dá para registrar mais de um dispositivo), não crie chaves de acesso para ele e só o use para as poucas tarefas que exigem root.Every AWS account has a root user tied to one email. Use a company group (aws-root+prod@), turn on MFA for root (more than one device can be registered), never create access keys for it and use it only for the few tasks that require root.
• Com AWS Organizations, a primeira conta vira a management account (só cobrança e governança) e você cria contas-membro por ambiente: prod, staging, dev. Uma fatura, isolamento real entre ambientes.With AWS Organizations, the first account becomes the management account (billing and governance only) and you create member accounts per environment: prod, staging, dev. One bill, real isolation between environments.
• Pessoas entram pelo IAM Identity Center (SSO), com permission sets por conta, e de preferência federado ao Google Workspace ou Entra ID: desativar a pessoa no diretório corta o acesso à AWS. Evite usuários IAM com chave de longa duração para humanos.People sign in through IAM Identity Center (SSO), with permission sets per account, ideally federated with Google Workspace or Entra ID: disabling the person in the directory cuts their AWS access. Avoid IAM users with long-lived keys for humans.
• Preencha os contatos alternativos (cobrança, operações, segurança) com os grupos, e crie um AWS Budget com alerta de gasto no primeiro dia.Fill in the alternate contacts (billing, operations, security) with the groups, and create an AWS Budget with a spend alert on day one.

Organizations, IAM e SCPs em detalhe: AWS. CI sem chaves guardadas: GitHub para AWS com OIDC.Organizations, IAM and SCPs in detail: AWS. CI without stored keys: GitHub to AWS with OIDC.

Google Cloud

• Com Google Workspace (ou o Cloud Identity Free, se o e-mail for outro), o primeiro acesso ao console cria o nó Organization do seu domínio. Projetos criados sob ela pertencem à empresa; projetos criados com um Gmail pessoal ficam em "Sem organização" e pertencem àquela pessoa.With Google Workspace (or Cloud Identity Free if your email lives elsewhere), the first console sign-in creates your domain's Organization node. Projects created under it belong to the company; projects created with a personal Gmail sit under "No organization" and belong to that person.
• Hierarquia: Organization → Folders (prod, dev) → Projects. Conceda papéis a grupos do Workspace (gcp-devs@) em vez de a pessoas, e no nível mais baixo que resolva.Hierarchy: Organization → Folders (prod, dev) → Projects. Grant roles to Workspace groups (gcp-devs@) rather than people, at the lowest level that works.
• A Billing Account é um recurso separado, com administradores próprios. Mantenha pelo menos dois Billing Account Administrators e dois Organization Administrators.The Billing Account is a separate resource with its own admins. Keep at least two Billing Account Administrators and two Organization Administrators.

Netlify eand Vercel

• Os dois têm conta pessoal e Team. Projetos comerciais vão num Team da empresa: o plano Hobby da Vercel é só para uso pessoal e não comercial.Both have a personal account and a Team. Commercial projects go in a company Team: Vercel's Hobby plan is for personal, non-commercial use only.
• Papéis: na Vercel, Owner, Member, Developer, Billing e Viewer; no Netlify, Owner, Developer, Billing Admin e Reviewer. Deixe Owner com dois fundadores e Developer para o resto.Roles: on Vercel, Owner, Member, Developer, Billing and Viewer; on Netlify, Owner, Developer, Billing Admin and Reviewer. Keep Owner with two founders and Developer for everyone else.
• O repositório Git conectado deve estar numa organização do GitHub da empresa, não no usuário de quem criou. Projetos criados na conta pessoal podem ser transferidos para o Team.The connected Git repository should live in the company's GitHub organization, not the creator's user. Projects created in a personal account can be transferred to the Team.

Supabase

• Projetos pertencem a uma Organization; a cobrança é por organização. Crie uma para a empresa, com cartão da empresa, e transfira para ela projetos que nasceram na organização pessoal.Projects belong to an Organization; billing is per organization. Create one for the company, on the company card, and transfer into it any project born in a personal organization.
• Papéis: Owner, Administrator, Developer e Read-only. A senha do banco e a chave service_role são credenciais de máquina: ficam no gerenciador de segredos, nunca no front-end.Roles: Owner, Administrator, Developer and Read-only. The database password and the service_role key are machine credentials: they live in the secrets manager, never in the front end.

Propriedade e acessoOwnership and access

O cenário que você quer evitar: um sócio sai brigado, um funcionário é desligado, ou alguém simplesmente perde o celular, e descobre-se que o domínio, a AWS ou o banco de produção estavam no login pessoal dele. Recuperar isso pode levar semanas de suporte, documentos societários e, às vezes, advogado.The scenario you want to avoid: a partner leaves on bad terms, an employee is let go, or someone simply loses their phone, and it turns out the domain, AWS or the production database were on their personal login. Getting that back can take weeks of support tickets, company documents and sometimes a lawyer.

As regrasThe rules

• Toda conta raiz/owner usa um e-mail de função da empresa (um grupo), nunca um e-mail pessoal nem o e-mail individual de um funcionário.Every root/owner account uses a company role address (a group), never a personal address nor one employee's individual address.
• Toda fatura vai num cartão da empresa, em nome da empresa. Cartão pessoal na conta é, na prática, prova de que a conta é da pessoa.Every bill goes on a company card, in the company's name. A personal card on the account is, in practice, evidence that the account is that person's.
• Pelo menos dois owners/admins em cada organização, e nunca mais que o necessário. Um só é ponto único de falha; muitos é superfície de ataque.At least two owners/admins per organization, and never more than needed. One is a single point of failure; many is attack surface.
• Recursos vivem na organização (team, account, org), nunca no espaço pessoal de um usuário, mesmo que seja só um teste que "depois a gente move".Resources live in the organization (team, account, org), never in a user's personal space, even if it is just a test "we will move later".
• Fornecedores e freelancers recebem convite como membros da organização da empresa, com papel limitado e data para sair. Nunca o contrário (a empresa sendo convidada na conta deles).Vendors and freelancers get invited as members of the company's organization, with a limited role and an end date. Never the other way round (the company being invited into theirs).

O inventário de contasThe account inventory

Uma planilha ou página interna, sem senhas, que responde "onde está cada coisa e quem manda nela". Ela é o que torna offboarding, auditoria e recuperação possíveis.A spreadsheet or internal page, with no passwords, that answers "where is everything and who controls it". It is what makes offboarding, audits and recovery possible.

SegurançaSecurity

MFA em tudo, e do tipo certoMFA everywhere, and the right kind

Compre duas chaves físicas por administrador: uma no chaveiro, outra guardada em local seguro. Registre as duas em cada conta crítica. Quem tem uma chave só tem, na verdade, um plano de perder o acesso.Buy two hardware keys per administrator: one on the keyring, one stored somewhere safe. Register both on every critical account. Someone with a single key actually has a plan to lose access.

Contas administrativas separadasSeparate admin accounts

• Super admin do Workspace, root da AWS e owner da organização não são para o uso diário. O Google recomenda ter mais de um super admin e não usá-lo para tarefas comuns; a AWS diz o mesmo do root.Workspace super admin, AWS root and organization owner are not for daily use. Google recommends having more than one super admin and not using it for everyday tasks; AWS says the same about root.
• Para quem administra, considere duas identidades: ana@ (e-mail, docs, papel de Developer) e ana.admin@ (só para tarefas administrativas, MFA com chave física, sem e-mail lendo links de fora).For admins, consider two identities: ana@ (email, docs, Developer role) and ana.admin@ (admin tasks only, hardware-key MFA, no inbox clicking outside links).
• Uma conta de break-glass (emergência) por plataforma crítica: credencial e chaves guardadas offline, uso registrado e alerta quando alguém entra nela.One break-glass (emergency) account per critical platform: credentials and keys stored offline, use logged, and an alert when anyone signs in.

Permissões individuais e menor privilégioIndividual permissions and least privilege

• Uma pessoa, um login. Sem isso, o log de auditoria diz "admin fez" e ninguém sabe quem.One person, one login. Without it, the audit log says "admin did it" and nobody knows who.
• Comece com o papel mais fraco que permite fazer o trabalho (Viewer, Developer) e suba só quando faltar algo concreto. Acesso a produção é exceção, não padrão.Start with the weakest role that gets the job done (Viewer, Developer) and raise it only when something concrete is missing. Production access is the exception, not the default.
• Conceda a grupos, não a pessoas (onde o provedor permitir). Entrar ou sair do grupo devs@ ajusta o acesso em todos os lugares de uma vez.Grant to groups, not people (where the provider allows it). Joining or leaving the devs@ group adjusts access everywhere at once.
• SSO quando der: com login via Google Workspace ou Entra ID, desligar a conta no diretório desliga o acesso aos serviços federados. Os planos mais baratos de alguns provedores não têm SSO; aí o offboarding manual precisa do inventário.SSO when possible: with sign-in through Google Workspace or Entra ID, disabling the directory account disables access to federated services. Some providers' cheaper plans lack SSO; then manual offboarding depends on the inventory.
• Revisão trimestral de acessos: para cada serviço do inventário, quem ainda está lá e precisa estar?Quarterly access review: for each service in the inventory, who is still there and still needs to be?

Gerenciamento de credenciaisCredential management

• Gerenciador de senhas da empresa (Bitwarden, 1Password) com cofres compartilhados por função. Ele guarda os códigos de recuperação e o raro segredo que precisa ser humano.Company password manager (Bitwarden, 1Password) with vaults shared by role. It holds recovery codes and the rare secret that has to be human.
• Segredos de máquina em gerenciador de segredos (AWS Secrets Manager, variáveis criptografadas da Vercel/Netlify, GitHub Actions secrets), nunca no repositório nem no .env commitado.Machine secrets in a secrets manager (AWS Secrets Manager, Vercel/Netlify encrypted variables, GitHub Actions secrets), never in the repository or a committed .env.
• Prefira credencial temporária: OIDC do CI para a nuvem, SSO com sessões curtas. Toda chave de longa duração tem dono, escopo mínimo e data de rotação.Prefer short-lived credentials: OIDC from CI to the cloud, SSO with short sessions. Every long-lived key has an owner, minimal scope and a rotation date.
• Quando alguém sai, rotacione todo segredo que essa pessoa pôde ver, além de remover o acesso.When someone leaves, rotate every secret that person could see, besides removing their access.

Recuperação de acessoAccess recovery

Planeje a recuperação antes de precisar dela. Para cada conta crítica, alguém deve conseguir responder: "se a pessoa X sumir hoje com o celular e as chaves, como entramos amanhã?"Plan recovery before you need it. For each critical account, someone should be able to answer: "if person X disappears today with their phone and keys, how do we get in tomorrow?"

• E-mail e telefone de recuperação são da empresa, não o celular pessoal de um sócio.Recovery email and phone belong to the company, not a partner's personal mobile.
• Códigos de recuperação gerados, impressos ou guardados no cofre, e testados uma vez.Recovery codes generated, printed or stored in the vault, and tested once.
• Segundo admin que consegue redefinir o primeiro (no Workspace, um super admin redefine o outro; na AWS, outro admin do Identity Center ou a conta de gestão).A second admin who can reset the first (in Workspace one super admin resets another; in AWS another Identity Center admin or the management account).
• Documentos à mão: contrato social e CNPJ. É o que o suporte do registrador ou da nuvem pede para provar que a conta é da empresa, e é por isso que a titularidade tem de estar no nome dela.Documents at hand: articles of incorporation and company registration. That is what registrar or cloud support asks for to prove the account is the company's, which is why ownership must be in its name.

ChecklistsChecklists

Dia 1 da empresaCompany day one

1. Registrar o domínio no nome e CNPJ da empresa, com renovação automática, trava e MFA.Register the domain in the company's name, with auto-renew, lock and MFA.
2. Contratar o e-mail, verificar o domínio, configurar MX, SPF, DKIM e DMARC.Set up email, verify the domain, configure MX, SPF, DKIM and DMARC.
3. Criar admin@, financeiro@, seguranca@, infra@ como grupos; obrigar MFA para todos.Create admin@, billing@, security@, ops@ as groups; enforce MFA for everyone.
4. Abrir as organizações (GitHub, Cloudflare, AWS, Vercel/Netlify, Supabase) com os e-mails de função e o cartão da empresa.Open the organizations (GitHub, Cloudflare, AWS, Vercel/Netlify, Supabase) with role addresses and the company card.
5. Dois owners por organização, cada um com duas chaves físicas; todos os outros com papel mínimo.Two owners per organization, each with two hardware keys; everyone else on the minimum role.
6. Gerenciador de senhas com os códigos de recuperação; inventário de contas preenchido.Password manager holding recovery codes; account inventory filled in.
7. Alertas de orçamento e de login administrativo apontando para os grupos.Budget and admin sign-in alerts pointing at the groups.

Quando alguém saiWhen someone leaves

1. Suspender a conta no diretório (corta o SSO) e transferir os arquivos e o e-mail para um responsável.Suspend the directory account (cuts SSO) and transfer files and mail to someone responsible.
2. Remover dos membros de cada serviço do inventário que não usa SSO.Remove from members of every inventory service that does not use SSO.
3. Tirar dos grupos de função e da lista de destinatários de alertas.Remove from role groups and alert recipient lists.
4. Revogar tokens pessoais, chaves SSH e chaves de API criadas pela pessoa; rotacionar segredos que ela viu.Revoke personal tokens, SSH keys and API keys the person created; rotate secrets they saw.
5. Se era owner ou admin: promover o substituto antes de remover, e conferir que ainda há dois.If they were an owner or admin: promote the replacement before removing them, and check there are still two.

Herdou uma bagunça?Inherited a mess?

• Faça o inventário primeiro, mesmo incompleto: liste o que você sabe que existe e de quem é cada login.Do the inventory first, even if incomplete: list what you know exists and whose login each one is.
• Comece pelo topo da corrente: registrador, depois e-mail, depois nuvem.Start at the top of the chain: registrar, then email, then cloud.
• Use as ferramentas de transferência (de titular no registrador, de projeto na Vercel e na Supabase, de repositório no GitHub) em vez de recriar.Use the transfer tools (registrant change at the registrar, project transfer on Vercel and Supabase, repository transfer on GitHub) instead of recreating.
• Troque o e-mail de login das contas pessoais que não dá para transferir por um e-mail de função, e então adicione os outros admins.For personal accounts that cannot be transferred, change the sign-in email to a role address, then add the other admins.

Cola e revisãoCheat sheet and review

ColaCheat sheet

Perguntas de revisãoReview questions

• Por que a conta do registrador é a mais crítica da empresa?Why is the registrar account the most critical one the company has?
• Quais registros DNS um domínio precisa para enviar e-mail sem cair no spam, e o que fazer com um domínio que não envia?Which DNS records does a domain need to send mail without landing in spam, and what do you do with a domain that never sends?
• Qual a diferença entre um e-mail de função (grupo) e uma conta compartilhada?What is the difference between a role address (group) and a shared account?
• O que acontece com um projeto do Google Cloud criado com um Gmail pessoal? Como evitar?What happens to a Google Cloud project created with a personal Gmail? How do you avoid it?
• Por que passkeys e chaves FIDO2 resistem a phishing e TOTP não?Why do passkeys and FIDO2 keys resist phishing while TOTP does not?
• Um sócio com o único acesso de owner na AWS sai da empresa amanhã. O que deveria ter sido feito antes?A partner holding the only AWS owner access leaves tomorrow. What should have been done before?