Modelos de operação
Customer-managed, co-managed, fully-managed. O mesmo produto, três modos de relacionamento, a fronteira imposta no código.
A WASViking® oferece três modelos de operação que correspondem a como as relações entre parceiro e cliente funcionam de fato. O modelo é declarado por acesso de cliente e imposto no código em todas as views.
Os três modelos
| Modelo | Visibilidade de postura para o parceiro | Indicado para |
|---|---|---|
| Customer-managed (gerenciado pelo cliente) | Nenhuma. O parceiro vê apenas o estado comercial. | Revendas sem uma equipe de operações de segurança. |
| Co-managed (gestão compartilhada) | Achados, inventário, SBOM, postura. O cliente mantém a responsabilidade. | MSSPs que apoiam uma equipe interna de segurança. |
| Fully managed (totalmente gerenciado) | Postura completa. O acesso do cliente é somente leitura ou desligado. | Entrega full-service de MSSP, sem operador interno de segurança. |
O que significa "apenas o estado comercial"
Em um acesso customer-managed, o parceiro vê:
- Plano, ciclo de faturamento, status da assinatura.
- Data de renovação.
- Uso e medição em relação ao plano.
- Add-ons configurados.
- Estado do trial e janelas de conversão.
O parceiro NÃO vê:
- Achados, inventário, métricas de postura.
- Histórico de scans, relatórios de scan, evidências.
- Configuração de segurança (RBAC, SAML, chaves de API).
- A trilha de auditoria do cliente.
Este é o modelo certo quando o parceiro é puramente um vendedor comercial e as operações de segurança ficam com o cliente final.
Onde a imposição acontece
A fronteira é imposta em org_link.partner_posture_visible(access):
def partner_posture_visible(access) -> bool:
return access.operating_model != "customer_managed"
Toda view de detalhe de cliente e todo widget de dashboard chama este gate antes de renderizar dados de postura. As métricas agregadas de postura no dashboard do parceiro excluem explicitamente da soma os acessos customer-managed, de modo que um parceiro com 10 clientes co-managed e 50 clientes customer-managed não vê números agregados falsos.
Definindo o modelo
O modelo de operação é definido no momento da cotação e faz parte do acesso provisionado. Para alterá-lo:
- Abra a página de detalhe do cliente.
- Operating model → Change.
- Escolha o novo modelo e informe um motivo breve.
- Confirme.
Toda alteração emite um evento PartnerAuditLog com o modelo antigo, o
novo e o operador que fez a alteração. A trilha de auditoria do próprio
cliente também reflete a alteração no lado do cliente.
O faturamento é desacoplado
O modelo de operação controla o que o parceiro vê. Ele NÃO controla o faturamento. O faturamento permanece consolidado no parceiro, qualquer que seja o modelo.
Essa separação é deliberada. Um acesso customer-managed ainda pode ser faturado ao parceiro se o acordo comercial assim determinar; a única coisa que o modelo muda é a visibilidade operacional.
Trials e modelos de operação
Os acessos de POC / trial têm customer-managed como padrão. O cliente final precisa optar explicitamente por co-managed ou fully-managed durante a configuração do trial. O motivo: em um trial, o cliente está avaliando tanto a plataforma quanto a relação com o parceiro, e abrir mão da visibilidade de postura logo no primeiro dia é uma exigência alta.
O que "fully managed" implica na operação
Quando um acesso é fully-managed, o parceiro é a parte que opera. Implicações práticas:
- O parceiro executa os scans.
- O parceiro faz a triagem dos achados.
- O parceiro cuida das janelas de SLA.
- O parceiro produz as evidências de Compliance e os Posture Shares.
Se o cliente quiser acesso somente leitura no modo fully-managed, o parceiro o convida como usuário Read-only dentro da organização do cliente. O acesso dele é independente do Partner Console.
Padrões
- Padrão de uma nova cotação: customer-managed.
- Após a conversão para pago: permanece como foi cotado. O operador altera explicitamente.
- Padrão por tier: não é configurável hoje. A escolha é por acesso.