A infraestrutura clássica não tem roles
A infraestrutura clássica NÃO usa roles pré-construídas. O acesso é concedido por permissões individuais, selecionadas uma a uma ou em bloco por um permission set. Era isso que o dataset anterior representava errado: inventava 83 'roles' clássicas que a IBM não publica.
As seis categorias de permissão
No console, em Manage > Access (IAM) > Users > Classic infrastructure, as permissões aparecem divididas nestas seis categorias. Elas são selecionadas uma a uma, ou em bloco por um permission set: View only, Basic user ou Super user.
Gestão da conta clássica: usuários, notas, notificações, entrega de e-mail, log de eventos e acesso físico a datacenter e colo cage.
Permissões sobre dispositivos — hardware, virtual guest e dedicated host. O acesso aos dispositivos ESPECÍFICOS é atribuído à parte, por dispositivo ou por tipo, com opção de acesso automático a dispositivos futuros.
Rede: DNS, firewall, load balancer, gateway, VLAN, security group e administração de VPN. O acesso às VPN subnets é atribuído à parte e pode ser automático conforme o acesso a dispositivos.
Pedido, upgrade e cancelamento de servidores, serviços e storage — permissões que geram ou encerram cobrança.
Certificados SSL/TLS (inclusive chave privada), chaves SSH e configuração de autenticação SAML.
Software instalado nos dispositivos: antivírus, firewall de software, imagens, licenças e credenciais de painéis (cPanel, Plesk, Helm, QuantaStor, Urchin).
As 71 permissões, uma a uma
Lista completa da documentação oficial. Nome e descrição são verbatim da IBM — nenhum texto aqui foi escrito por nós. A busca atravessa as seis categorias.
| Permissão | Descrição |
|---|---|
| Activate Partner Customer Account | Enable partner accounts to begin managing customer resources and billing |
| Add Brand Account | Create sub-brand accounts for reseller or partner organizational hierarchies |
| Add Customer Account | Create new customer accounts within the account structure |
| Manage Account Notes | Add, edit, and delete internal notes for account documentation and tracking |
| Manage E-mail Delivery Service | Configure e-mail delivery service accounts for system notifications |
| Manage Notification Subscribers | Create and manage notification subscribers for usage warnings and overages |
| Manage Users | Add, remove, and modify user access and classic infrastructure permissions |
| Physically Access a Customer's Colo Cage | Authorize physical entry to customer colocation cages in data centers |
| Physically Access a Datacenter | Authorize physical entry to IBM Cloud data center facilities |
| View Event Log | Access the account-wide event log history for audit and troubleshooting purposes |
Lista enumerada extraída do doc-fonte iam-mnginfra.md (ibm-cloud-docs/iam), atualizado pela IBM em 2026-06-04. Nomes e descrições são verbatim da IBM.
Regras que valem para todo o modelo clássico
Da documentação oficial da IBM. Vale ler antes de desenhar qualquer atribuição — a hierarquia de usuário do clássico não existe no IAM.
- ▸Para acessar: Manage > Access (IAM) > Users > [usuário] > Classic infrastructure.
- ▸No convite ao usuário há três permission sets de atribuição em bloco: View only, Basic user e Super user. O ajuste fino é feito depois, permissão a permissão.
- ▸Quem edita precisa da permissão 'Manage Users' da infraestrutura clássica e ser ancestral do usuário na hierarquia clássica.
- ▸Account owners têm acesso total e não veem a página de permissões. Ninguém edita as próprias permissões.
- ▸Acesso a dispositivo NÃO vem no convite: é atribuído depois, por dispositivo ou por tipo, com a opção 'Enable future access' para dispositivos novos.
- ▸VPN subnets são atribuídas à parte. Para alterar a de terceiros é preciso a permissão 'VPN Administration' mais política IAM de Viewer (ou superior) no serviço User Management — ou ser master user.
- ▸As permissões de account management e support que existiam na infraestrutura clássica foram MIGRADAS para access groups do IAM e por isso não estão nas seis categorias.
- ▸Recomenda-se dar acesso de account management do support center a quem trabalha com recursos clássicos: criar ou excluir uma instância exige poder abrir caso de suporte.
Fontes de dados
- Platform and service access roles for permissions
Platform roles e service roles, com a descrição oficial de cada uma.
- Managing classic infrastructure access
Fonte das SEIS categorias e da lista enumerada das 71 permissões clássicas, além de device access, VPN subnet e permission set.
- Managing migrated SoftLayer account permissions
As permissões clássicas de billing e suporte que viraram access groups do IAM — não aparecem mais nas seis categorias.
Documento oficial atualizado pela IBM em 2026-06-04.
O que existe aqui no site
As páginas desta cloud, com o que cada uma cataloga hoje. As contagens vêm dos datasets, não são escritas à mão.
Números, distribuição por tier e atalhos para as listas filtradas.
As 4 platform roles e 3 service roles oficiais do IAM.
O modelo de acesso da infraestrutura clássica — permissões, não roles.
Access Groups e Trusted Profiles, os dois primitivos de acesso.
Ferramentas multi-cloud
Não pertencem a nenhuma cloud e é o que o IAM Scope tem de próprio. Ficam repetidas em todas as referências porque quem chega direto numa página interna não tem outro caminho para descobri-las.
Procura por nome, slug, GUID ou ARN em todas as roles e policies das seis clouds.
Busca reversa: dada uma permission, mostra quem a concede em cada cloud.
Equivalência de função entre as seis plataformas.
Regras de segregação de funções em cinco plataformas, e a matriz de conflito.
Script somente leitura para rodar no seu tenant e medir o risco real.
Cole uma role e veja a cloud detectada e a classificação.
Descreva a tarefa e receba candidatas de menor privilégio.
O que conta como Tier 0 em cada cloud, lado a lado.