Administração, identidade e governança

Equipe e funções: convidar membros, funções nativas e funções personalizadas

O acesso a uma organização no Plexicus é baseado em funções, e a página Team mostra uma função por membro.

Convidar um membro

Abra Settings Team , clique em Add member e preencha a caixa de diálogo Invite a team member com um Email address e uma Role. Depois, clique em Send invitation.

Os convites são para novos usuários. A pessoa convidada recebe um e-mail para criar uma conta no Plexicus e entrar na sua organização. Um endereço que já tem conta no Plexicus não pode ser convidado, e a resposta é propositalmente genérica para não revelar se essa conta existe. Peça aos novos colegas que aguardem o seu convite em vez de se cadastrarem antes: um cadastro por conta própria normalmente cria uma organização separada, com essa pessoa como Admin. Cada usuário pertence a exatamente uma organização; não há seletor de organizações.

O membro aparece como Invited até aceitar e, depois, como Active. Os links de convite expiram; se um colega perder o prazo, convide o endereço novamente. Convidar de novo um endereço pendente com outra função atualiza esse convite. Escolha uma função nativa ao convidar e passe o membro para uma função personalizada pela página Team depois que ele entrar.

Com SSO e provisionamento just-in-time, as pessoas recebem a conta no primeiro login pelo seu provedor de identidade, então você não precisa convidá-las uma a uma (aula 2).

Alterar funções e remover membros

Use o menu suspenso de função na linha de um membro para alterar a função dele. A nova função é atribuída, a anterior é revogada, e a notificação “Role assignment updated” confirma a mudança. Remove, em uma linha, remove um membro ativo ou cancela um convite pendente. As duas ações são gravadas no registro de auditoria. Quando um engenheiro sair da empresa, remova-o no mesmo dia e depois filtre o registro de auditoria pelo e-mail dele para revisar as ações recentes.

Funções nativas

Por padrão, as funções nativas dividem as responsabilidades assim:

Função	Perfil típico	O que pode fazer	O que não pode fazer
Admin	Responsável pela plataforma, líder de segurança	Configurações e conectores da organização, membros, funções, achados, repositórios e scans, AI pentests, tickets e automações, faturamento, o registro de auditoria	Configurar o SSO pode exigir direitos separados de administração de SSO (aula 2)
Cyberoper	Engenheiro de segurança	Fazer a triagem de achados (atualizar, marcar como falso positivo, excluir, enviar aos desenvolvedores), importar relatórios, gerar remediações e issues, criar, executar e cancelar AI pentests, solicitar scans, gerenciar repositórios, registries e conexões de controle de código-fonte; ler automações	Abrir pull requests, convidar membros, gerenciar funções, ler o registro de auditoria
Developer	Engenheiro que corrige o código	Ver achados, remediações, repositórios, execuções de scan e resultados do AI Pentest; abrir pull requests e issues, enviar tickets, baixar relatórios e exportações (PDF e JSON); ler automações	Alterar o status de achados ou marcar falsos positivos, gerar correções, iniciar scans, executar pentests, administrar a organização

Com as funções padrão, um Cyberoper prepara e revisa uma correção, e um Developer abre o pull request. O módulo 7 aborda esse repasse.

Funções personalizadas

Dependendo do seu plano, os Admins podem criar funções em Settings Roles . A tabela lista todas as funções com Role Name, Description, Type (um selo Built-in ou Custom) e Members, o número de pessoas que têm aquela função.

Clique em Create role, informe um Role Name e uma Description e marque as permissões na grade. A grade é agrupada por recurso, como Client, Finding, Repository, Remediation e Scan, e cada item traz uma ação read, write ou admin. Save fica desabilitado até a função ter um nome e pelo menos uma permissão, e os nomes precisam ser únicos na sua organização.

As funções nativas não podem ser renomeadas nem excluídas. Na página Roles, a linha delas oferece apenas Duplicate, que abre o formulário de criação preenchido com as permissões daquela função; as funções personalizadas mostram Edit e Delete.

Por exemplo, você quer um “Security Lead” que trabalhe como um Cyberoper, mas sem poder excluir achados. Duplique a função Cyberoper, dê à cópia o nome Security Lead, desmarque a permissão de exclusão de achados no grupo Finding, salve e atribua a função pela página Team.

Identidade: single sign-on, SCIM, autenticação de dois fatores e passkeys

Os usuários fazem login com GitHub, Google ou Microsoft, com e-mail e senha, com uma passkey ou por Login via SSO, onde digitam o slug de login SSO da sua organização. As configurações de autenticação ficam em Settings Authentication , com as linhas Two-factor authentication, SAML / SSO, Passkey e Active sessions.

Configurar o SSO

Abra o hub de SSO em Settings Authentication SAML / SSO Configure SSO . Configurar o SSO exige direitos de administração de SSO, que a documentação atribui aos Admins; se a página negar o seu acesso, pergunte ao suporte da Plexicus quem na sua organização tem esses direitos. O hub mostra o status, o modo e o SSO Login Slug, o seletor de provedores, Verified Domains, SCIM 2.0 Provisioning, o link Advanced settings para a página Advanced SSO Settings e Disable SSO, que exclui a configuração. Os provedores que você pode usar dependem do seu plano.

Opção no seletor	Protocolo	O que você informa
Okta, Azure AD / Entra ID	SAML 2.0	Assistente guiado
Google Workspace	OIDC (recomendado) ou SAML 2.0	Assistente guiado
Ironchip	SAML 2.0 ou OIDC	Assistente guiado
Generic SAML 2.0	SAML 2.0	IdP Entity ID, IdP SSO URL e certificado X.509; asserções assinadas exigidas por padrão
Generic OIDC	OpenID Connect	Client ID, Client Secret, Discovery URL e escopos; PKCE ativado por padrão

O slug tem de 3 a 64 caracteres, entre letras minúsculas, dígitos, hifens ou pontos, e precisa ser único entre todas as organizações do Plexicus. Os valores do provedor de serviço que os assistentes mostram, como ACS URL, Entity ID e redirect URI do OIDC, contêm o slug; por isso, se você alterar o slug, atualize esses valores no seu provedor de identidade. Cada assistente guiado termina com Test, uma validação simulada (dry run) que não salva nada, e Activate, que salva a configuração.

Configurações avançadas: modo, JIT e mapeamento de grupos

Na página Advanced SSO Settings (o link Advanced settings no hub), você escolhe o Authentication Mode. As mudanças passam a valer no próximo login de cada usuário.

Modo	Comportamento
Coexist (padrão)	O SSO e o login com senha funcionam
SSO Preferred	O SSO é o padrão; o login com senha continua como alternativa
SSO Enforced	Pensado para ser a única forma de acesso; o produto descreve os logins com senha e com passkey como desativados

JIT Provisioning, ativado por padrão, cria uma conta no primeiro login SSO de um usuário, com a função padrão (developer, a menos que você a altere). Group → Role Mappings têm precedência sobre esse padrão: o primeiro grupo do IdP que corresponder define a função. Se a sua organização tiver domínios verificados, apenas os e-mails desses domínios são provisionados, e um e-mail que pertence a outra organização é rejeitado. Nas versões atuais, os mapeamentos são reavaliados a cada login SSO: se você mover alguém para outro grupo do IdP, a função dessa pessoa muda no próximo login, com uma entrada no registro de auditoria. Para usuários que pertencem a um grupo mapeado, gerencie a função no seu provedor de identidade; uma mudança feita na página Team pode ser sobrescrita no próximo login.

Provisionamento com SCIM

O hub mostra o seu SCIM Endpoint. Create SCIM Token emite um token válido por 365 dias e o mostra uma única vez. Rotate emite um novo token e mantém o antigo funcionando por 7 dias; Revoke invalida um token imediatamente. Tokens com menos de 30 dias de validade restante mostram Expiring soon. O SCIM abrange usuários e grupos, então um usuário desativado pelo seu provedor de identidade perde o acesso sem nenhuma etapa manual.

Autenticação de dois fatores e passkeys

Para ativar o 2FA, clique no toggle da linha Two-factor authentication, escaneie o QR code com um app autenticador e digite o código de 6 dígitos. A linha passa a mostrar Manage.

Uma passkey permite fazer login com a impressão digital, o reconhecimento facial ou uma chave de segurança: clique em Set up na linha Passkey e depois em Continue em Link this device. Com SSO, a linha Passkey mostra Managed by SSO, e as passkeys passam a ser configuradas no seu provedor de identidade. A linha Two-factor authentication não muda.

O registro de auditoria: o que fica gravado, filtros e integridade

O registro de auditoria responde a “quem fez o quê, e quando” em toda a sua organização. Dependendo do seu plano, os Admins podem abri-lo em Settings Audit Log ; as outras funções, não.

O que você vê

Cada linha tem Timestamp, Actor Type (User, System ou Integration), Actor, Action, Resource Type, Resource e Details. O ícone de olho em Details abre a entrada completa, com os metadados. Senhas, tokens, chaves de API, client secrets, certificados e cookies são substituídos por [redacted] antes de uma entrada ser armazenada, para que o registro de auditoria não vire uma segunda cópia dos seus segredos.

Filtros

Você pode combinar quatro filtros: um seletor de Date range (com predefinições como Last 7 days, Last 14 days e Last 30 days), Actor email (correspondência parcial), Action Type e Resource Type (User, Client, Repository, Finding, Remediation, Connector ou Role). Os resultados vêm em páginas de 50, com botões de anterior e próxima, e um botão de redefinição limpa os filtros.

A lista Action Type abrange as ações administrativas mais comuns:

Recurso	Ações
Usuários	user.invited, user.removed
Organização	client.settings_updated
Repositórios	repository.created, repository.deleted, repository.scan_triggered
Conectores	connector.added, connector.removed
Remediação	remediation.created, remediation.updated
Achados	finding.status_changed
Funções	role.created, role.deleted, role.assigned, role.revoked

O registro grava mais do que essa lista. Ele também captura logins e logouts, mudanças de senha, criação e revogação de tokens de API, cadastro de passkeys, exportações de achados em CSV e JSON (SARIF), mudanças em automações, mudanças de usuários e grupos via SCIM, mudanças na configuração de SSO e logins por SSO, além de mudanças de função vindas do mapeamento de grupos do IdP. Abrir o registro de auditoria também fica gravado, então revisá-lo deixa o seu próprio rastro.

Verificar a integridade

O registro torna qualquer adulteração evidente. Cada entrada armazena um hash SHA-256 encadeado à entrada anterior da sua organização. Se alguém modificar ou excluir uma entrada, a cadeia se rompe nesse ponto, e esconder isso exigiria reescrever todas as entradas posteriores.

Você verifica a cadeia pela API do Plexicus. Um Admin pode chamar o endpoint Verify Audit Log Chain Integrity em /audit-logs/integrity-verification. Ele recalcula a cadeia e retorna valid: true quando tudo confere, ou valid: false com um ponteiro first_break para a primeira entrada em que a cadeia se rompe. As entradas gravadas antes de o encadeamento de hashes chegar à sua implantação são contadas como registros anteriores à cadeia e ficam fora do veredito, e a verificação abrange apenas as entradas que a sua organização ainda retém. O módulo 9 aborda os tokens de API e as chamadas à API.

Usar como evidência

A retenção depende do seu plano e, em instalações auto-hospedadas, da sua configuração. Se um auditor precisar de um período maior, extraia as entradas necessárias pela API List Audit Logs antes que elas saiam do período de retenção.

O registro de auditoria apoia revisões de acesso, linhas do tempo de incidentes e solicitações de auditores. O Plexicus fornece o registro e a prova de integridade; cabe aos seus auditores decidir se os seus controles atendem a um framework.

Configurações da organização: perfil, regulamentações, idioma, propriedade, IA e planos

Toda a administração fica em Settings, na barra lateral esquerda, dividida em três grupos. Organization reúne Organization, Team, Roles e Ownership Verification. Configuration reúne Integrations, Platform, Billing e BYOAI. My Account reúne a sua própria conta, a autenticação, os tokens e o Audit Log. Roles e Audit Log ficam visíveis apenas para Admins; quem não é Admin e abre esses endereços diretamente recebe uma página “Page not found”. Billing e BYOAI aparecem conforme o seu plano.

Perfil da empresa e regulamentações

Abra Settings Organization . A página tem três abas, e cada uma salva apenas a própria seção com Save changes:

Profile mostra, como somente leitura, o nome da organização, o e-mail de cobrança, o ID da organização e o proprietário, além de dados editáveis da empresa: razão social, e-mail comercial, URL da empresa, empresa controladora, identificador global de identidade e categoria.
Locations reúne a sede, as filiais, os locais de prestação de serviço e de processamento de dados e as subsidiárias.
Regulations é onde você acompanha os frameworks pelos quais a sua organização é auditada. O Plexicus mapeia os achados para eles e gera evidências (módulo 8); alguns frameworks dependem do seu plano.

Idioma

Duas configurações de idioma são fáceis de confundir. Scan & Report Language, em Settings Platform , vale para toda a organização: a análise de IA, as descrições dos pull requests de correção e os relatórios exportados em PDF e JSON são produzidos nesse idioma. App Language, uma aba em Settings Account , muda apenas a sua própria interface. As duas oferecem inglês e espanhol. A página Platform também reúne os padrões de scan e de correção (módulos 3 e 7).

Verificação de propriedade

A página Settings Ownership Verification é onde os Admins gerenciam os domínios de toda a organização. Um alvo de pentest precisa de um domínio verificado, que cobre os subdomínios, ou de uma verificação de aplicação feita no assistente do AI Pentest. App Verification, aqui, é um registro somente leitura dessa segunda opção e pode estar vazio, dependendo da sua versão. Os domínios verificados também definem quais domínios de e-mail o provisionamento JIT do SSO aceita. O módulo 6 explica os dois métodos passo a passo.

Configuração de IA

Por padrão, os scans rodam nos modelos da plataforma Plexicus, e o código dos clientes não é usado para treinar modelos de IA. Se o seu plano incluir esse recurso, BYOAI, em Settings BYOAI , permite substituí-los pelos seus próprios modelos, por meio do endpoint do seu provedor: um modelo Fast, um modelo Smart e um endpoint de Embeddings obrigatório, salvos juntos com Save BYOAI configuration. Cada bloco tem Test connection, e um único Reset to Plexicus default limpa os três. O módulo 7 explica para que serve cada slot.

Planos e recursos incluídos

O seu plano define quais recursos e quanto uso de IA a sua organização tem. Settings Billing (Billing & Usage) mostra o plano, a data de renovação, a sua cota de uso de IA com o consumo deste mês e a data de reinício, o uso de sessões de pentest e o Invoice History. O menu do seu perfil mostra os mesmos medidores. Quando a sua versão incluir, uma página Usage em Settings acrescenta um detalhamento por ação e o histórico. As cotas são reiniciadas no dia 1º de cada mês do calendário (UTC). Um recurso fora do seu plano mostra um aviso de upgrade ou uma caixa de diálogo Request Priority Access. O módulo 7 explica o que consome a cota e o que acontece quando ela acaba.

No Plexicus SaaS, a Plexicus não recebe pagamentos dentro do aplicativo. Um Admin seleciona Request a plan change em Billing, escolhe o plano e o período de cobrança, descreve o uso esperado e envia a solicitação. Uma organização pode ter uma solicitação aberta por vez, que você acompanha em Settings Billing Plan requests .

Status	Significado
Received	A Plexicus recebeu a sua solicitação
In contact	A equipe está tratando dela com você
Offer sent	Há uma oferta pronta para você analisar
Invoiced	Você aceitou a oferta e a fatura foi emitida
Paid	A fatura foi paga
Plan applied	O seu novo plano está ativo
Rejected / Cancelled	A solicitação foi encerrada; você pode enviar uma nova

Opções de implantação para responsáveis pela plataforma

O Plexicus roda como SaaS ou auto-hospedado; o air-gapped é uma variante do auto-hospedado.

Opção	Onde roda	Quem opera
SaaS na UE	Hospedado pela Plexicus em app.plexicus.ai; por padrão, os dados do SaaS ficam na UE	A Plexicus, incluindo as atualizações
Auto-hospedado	O seu cluster Kubernetes, on-premises ou em uma conta de nuvem que você controla, instalado com o Helm chart do Plexicus	A sua equipe
Air-gapped (variante auto-hospedada)	A instalação auto-hospedada, sem acesso de saída à internet	A sua equipe

Durante a manutenção, o aplicativo mostra a página System Under Maintenance, ou Upcoming Update System enquanto uma nova versão é implantada, e alguns recursos podem ficar indisponíveis por alguns instantes.

Auto-hospedado com o Helm chart

Auto-hospedado e on-premises são a mesma coisa: um chart e uma licença. Você precisa de qualquer cluster Kubernetes em conformidade com a CNCF, na v1.25 ou posterior. A Plexicus entrega um pacote com uma credencial de registry, a sua licença assinada, um arquivo de ambiente com a versão do chart e as configurações de IA e, para produção, um arquivo de values já preenchido com o seu domínio. Você fornece o cluster, um domínio com registros DNS para o aplicativo e para o host da API, um ingress controller, TLS via cert-manager ou com os seus próprios certificados, uma storage class que retenha os volumes e, de preferência, um relay SMTP. Sem e-mail, você declara que a instalação roda sem ele, e os convites passam a ser mediados pelo administrador: a resposta do convite retorna um link de verificação para o Admin que convidou, que o entrega diretamente à pessoa. Sem e-mail, criar o primeiro Admin também exige uma etapa extra de configuração descrita no guia de instalação.

Uma implantação auto-hospedada não envia telemetria para fora do seu cluster. Apenas as integrações que você configura se comunicam com sistemas externos, e os recursos que dependem dos serviços comerciais da Plexicus, como o faturamento, ficam desativados.

A licença é instalada como um secret do cluster antes da instalação do chart; sem ela, os serviços principais não iniciam. Quando faltam 30 dias ou menos para a licença expirar, a página de login mostra “License expiring soon”. Depois do vencimento, há um período de carência, de 14 dias por padrão, e então aparece “License expired”: o acesso fica restrito até você renovar com o seu gerente de contas.

Instalações air-gapped

Air-gapped é o caminho do Helm com três mudanças: espelhar todas as imagens em um registry interno, apontar o chart para esse espelho e substituir a autoridade certificadora pública pelo seu emissor interno. Transfira o arquivo de licença pelo seu processo seguro habitual; as verificações de licença continuam funcionando offline. Deixe sem configurar as integrações que precisam da internet pública e dê à plataforma um endpoint de IA que ela consiga acessar, incluindo um endpoint de embeddings; caso contrário, o Deep Code Analysis não roda. Para atualizar, espelhe primeiro a nova versão e depois execute o upgrade com exatamente essa versão.

GitOps

Se você já usa ArgoCD, ele pode reconciliar o mesmo chart a partir do Git, em vez de um helm install manual. Os manifestos de referência vêm dentro do chart. Fixe o chart em uma versão exata, mantenha os values no Git e nunca faça commit de segredos em texto puro: use sealed secrets, um operador de segredos externos ou arquivos criptografados.

Backup e restauração

O estado da plataforma fica em três lugares: o banco de dados principal (achados, usuários, repositórios, resultados de scan), o banco de dados do histórico de workflows e o armazenamento de objetos (artefatos de scan, entradas e saídas de IA, relatórios). Faça o backup dos três juntos, porque um backup só do banco de dados pode apontar para artefatos que você já não tem.

O Plexicus é uma carga de trabalho no seu cluster. O provisionamento do cluster, o hardening dos hosts, o DNS, a confiança TLS, a política de rede, o monitoramento e os backups continuam sendo responsabilidade sua.

Principais pontos

Convide as pessoas por Settings Team antes que elas se cadastrem por conta própria, dê a cada uma a função mais restrita que atenda à necessidade e use Duplicate para transformar uma função nativa em uma personalizada.
O SSO oferece SAML 2.0 e OIDC por meio de assistentes guiados ou configurações genéricas. Passe de Coexist para SSO Enforced apenas depois de uma validação simulada aprovada nas últimas 24 horas, e deixe que JIT, mapeamentos de grupos e SCIM mantenham as contas sincronizadas com o seu provedor de identidade.
Os usuários podem adicionar um app autenticador e uma passkey; quando a sua organização usa SSO, as passkeys passam a ser gerenciadas no seu provedor de identidade.
O registro de auditoria é para Admins, pode ser filtrado por data, autor, ação e recurso, oculta campos que contêm segredos e é protegido por uma cadeia de hashes SHA-256 que você verifica pela API.
As configurações da organização abrangem o perfil da empresa, as regulamentações, duas configurações de idioma separadas, a verificação de propriedade, o BYOAI e as solicitações de mudança de plano; no SaaS, a Plexicus não recebe pagamentos dentro do aplicativo.
A instalação auto-hospedada roda o mesmo produto a partir do Helm chart, com uma licença assinada; a air-gapped acrescenta o espelhamento e um emissor interno, e todo upgrade começa com um backup dos três armazenamentos de dados.