Enterprise
Controlo de acesso baseado em funções em workspaces e projetos
Privilégio mínimo para uma plataforma em que um pedido pode alterar a produção — funções de workspace, delimitação por projeto, e políticas do Guardrails que encaminham alterações arriscadas para os revisores certos.
O controlo de acesso baseado em funções do Ciao sobrepõe funções de workspace, permissões ao nível do projeto e a governação do Guardrails. Ao contrário de ferramentas em que o acesso é tudo ou nada, o RBAC delimita o que cada pessoa pode administrar, construir e aprovar — e as políticas do Guardrails em linguagem simples podem encaminhar alterações arriscadas para revisores séniores designados, registando a revisão humana atrás de cada merge num registo de auditoria apenas de acréscimo.
Publicado 2026-07-03 · Última atualização 2026-07-03
Privilégio mínimo quando um pedido pode alterar a produção
O controlo de acesso numa plataforma de desenvolvimento sempre importou; a IA eleva a fasquia porque a distância entre a intenção e a alteração de produção é menor. Uma pessoa com acesso alargado deixa de ser apenas alguém que pode ler demasiado — passa a ser alguém cujo pedido em linguagem simples pode tornar-se código em execução. O privilégio mínimo deixa de ser um preciosismo de conformidade e passa a ser o controlo principal sobre o que a plataforma vai fazer, e em nome de quem.
O modelo do Ciao responde a três perguntas separadas com três camadas separadas: quem pode administrar o workspace, quem pode trabalhar em que projetos, e quem pode aprovar que alterações. Os revisores devem avaliar cada camada por si só, porque reduzi-las a um único interruptor 'admin versus utilizador' é exatamente a fragilidade de conceção para a qual esta categoria tende.
O ganho de acertar nas camadas é tanto velocidade como segurança. Quando as alterações rotineiras fluem sob revisão ligeira e só as áreas protegidas exigem olhos séniores, a governação deixa de ser o estrangulamento que as equipas contornam — e os controlos que as pessoas não contornam são os únicos controlos que se mantêm.
O que o Ciao fornece
Cinco mecanismos, cada um verificável de forma independente durante a avaliação:
- Funções de workspace — A capacidade administrativa — configuração de identidade, adesão, definições do workspace — é uma função atribuída deliberadamente, não uma predefinição.
- Permissões ao nível do projeto — O acesso é delimitado aos projetos em que uma pessoa realmente trabalha, para que um prestador de serviços numa construção não herde visibilidade sobre o resto do portefólio.
- Políticas do Guardrails com senioridade — O Guardrails aplica políticas em linguagem simples a alterações arriscadas e regista a revisão humana — e as políticas podem nomear quem é sénior o suficiente para rever alterações em áreas de negócio protegidas.
- Integração de identidade — O SSO via SAML e OIDC com MFA opcional autentica as pessoas; o mapeamento de grupos para funções via SCIM mantém as funções alinhadas com o seu diretório.
- Administração registada — A atribuição de funções e as alterações de permissões são ações administrativas no registo de auditoria apenas de acréscimo, para que as revisões de acesso citem registos, não memória.
Níveis de senioridade no Guardrails
Nem toda a alteração merece o mesmo revisor. Um ajuste de texto numa página de marketing e uma modificação à lógica de pagamentos são eventos diferentes, e um modelo de governação que os trate de forma idêntica ou vai atrasar tudo ou não vai rever nada devidamente. O Guardrails mapeia o código em áreas de negócio e deteta alterações arriscadas, o que permite à política distinguir as duas coisas — em linguagem simples, legível pela equipa de conformidade que tem de aprovar a própria política. Esse mapeamento é o que torna a senioridade significativa: a plataforma sabe que área de negócio uma alteração toca, para que a política possa dizer quem está qualificado para a avaliar.
A senioridade entra como política: as alterações que tocam áreas protegidas podem ser encaminhadas para revisores séniores designados, enquanto as alterações rotineiras fluem com revisão mais ligeira. A revisão que acontece fica registada, para que o registo de auditoria mostre não só que uma alteração foi aprovada, mas que foi aprovada por alguém que a política considerou qualificado. E porque as políticas estão em linguagem simples, as pessoas responsáveis pelo controlo — conformidade, risco, liderança de engenharia — conseguem lê-las e contestá-las diretamente, sem nenhuma camada de tradução entre a política que foi aprovada e a regra que corre.
Lançar o RBAC
1. Mapeie as funções face à realidade
Liste quem administra, quem constrói, quem revê e quem apenas observa — a partir do seu organograma, não das predefinições da ferramenta.
2. Ligue a identidade
Coloque a autenticação atrás do SSO, e mapeie os grupos do IdP para funções via SCIM, para que o diretório oriente o acesso.
3. Delimite os projetos
Atribua permissões ao nível do projeto para que o alcance de cada pessoa corresponda ao seu trabalho, com prestadores de serviços e fornecedores delimitados de forma mais restrita.
4. Escreva políticas do Guardrails
Defina, em linguagem simples, que áreas de negócio estão protegidas e que revisores são séniores o suficiente para aprovar alterações nelas.
5. Reveja com evidência
Execute a sua primeira revisão de acesso a partir do registo de auditoria — a atribuição de funções, as alterações de permissões e os merges registados dão à revisão a sua base de evidência.
Três camadas, três perguntas
Cada camada responde a uma pergunta diferente do revisor — pontue-as separadamente:
| Camada de acesso | Pergunta a que responde | Mecanismo |
|---|---|---|
| Funções de workspace | Quem pode administrar o workspace? | Capacidade administrativa atribuída deliberadamente |
| Permissões de projeto | Quem pode trabalhar onde? | Delimitação de acesso por projeto |
| Políticas do Guardrails | Quem pode aprovar que alterações? | Políticas em linguagem simples com revisão humana registada |
| Identidade | Afinal, quem é esta pessoa? | SSO via SAML e OIDC, MFA opcional, mapeamento via SCIM |
| Evidência | O que aconteceu efetivamente? | Registo de auditoria apenas de acréscimo de ações administrativas e merges |
Notas de verificação
As afirmações sobre RBAC verificam-se melhor tentando fazer coisas. Durante a avaliação, peça a um utilizador delimitado que tente chegar a um projeto fora da sua atribuição, e a um revisor não sénior que tente aprovar uma alteração numa área protegida — depois leia os dois eventos no registo de auditoria. O dossiê de segurança, disponível a pedido através da página de contacto, documenta o modelo de acesso por escrito, e os relatórios SOC 2 Type II sob NDA cobrem os controlos de gestão de acesso auditados.
Leve o seu próprio organograma para a avaliação: nomeie um prestador de serviços real, um engenheiro júnior real e um sistema protegido real, e configure o teste em conformidade. As demonstrações abstratas de RBAC parecem sempre bem; a sua estrutura é o teste que importa.
Perguntas frequentes
Um programador júnior pode fazer merge de alterações numa área de negócio protegida?
O Guardrails deteta alterações arriscadas e aplica as políticas em linguagem simples que o seu workspace define — incluindo o encaminhamento de alterações em áreas protegidas para revisores séniores designados, com a revisão humana registada. Verifique o comportamento face à sua própria política durante a avaliação, em vez de aceitar um sim/não vindo de uma página web.
Podemos delimitar os prestadores de serviços a um único projeto?
As permissões ao nível do projeto existem exatamente para isto: o acesso de um prestador de serviços é delimitado aos projetos em que trabalha. Combine-as com o SCIM para que o fim do contrato no seu diretório também termine o acesso.
Como são auditadas as próprias alterações a funções e permissões?
A atribuição de funções e as alterações de permissões são ações administrativas, registadas no registo de auditoria apenas de acréscimo, juntamente com pedidos, merges e deploys. As revisões de acesso conseguem, por isso, seguir quem alterou o acesso de quem, e quando.
O controlo de acesso aplica-se ao que a IA faz, ou só a humanos?
As alterações geradas por IA passam pelo mesmo caminho governado que as humanas: o Guardrails mapeia-as em áreas de negócio, deteta o risco, aplica a política e regista a revisão humana atrás de cada merge. Os controlos que a sua revisão avalia para as pessoas são os mesmos que governam o próprio resultado da plataforma.
As funções podem ser orientadas pelos nossos grupos de IdP?
Sim — o provisionamento SCIM mapeia os grupos do IdP para funções do Ciao, para que a atribuição de funções siga o diretório que a sua equipa já governa. O mapeamento é acordado durante o onboarding e as suas alterações ficam registadas como ações administrativas.