Parceiros – Modelos de função aplicados aos clientes

Modelos de Função resolvem um problema específico da sua operação: definir os acessos uma vez e aplicá-los em toda a sua carteira, sem recriar funções cliente por cliente.

O que é um modelo de função

A própria tela define: funções reutilizáveis, apenas com permissões, concedidas à sua MSSP. Aplicar um modelo a um cliente cria ali uma função gerenciada centralmente, cujas permissões permanecem sincronizadas com o modelo.

E ela deixa claro o que não vem do modelo: o escopo, ou seja, frameworks e documentos, é definido por cliente.

Essa divisão é o coração do recurso, e vale entender bem:

Dois tipos de modelo

A função de operador tem um comportamento próprio, e a tela informa: ela é aplicada automaticamente ao seu próprio ambiente quando concedida, sem nenhuma ação por cliente.

Alguns modelos aparecem marcados como Sistema. A tabela mostra também o nome do modelo, o tipo e a quantidade de permissões.

Os modelos são concedidos pela Imara

Este é o ponto que costuma gerar dúvida no primeiro acesso.

Você não cria modelos nesta tela. Eles são concedidos à sua MSSP, e quando ainda não há nenhum, a tela informa que nenhum modelo de função foi concedido à sua MSSP ainda.

Se você precisa de um conjunto de permissões que não existe entre os modelos disponíveis, o caminho é falar com a Imara. E, enquanto isso, nada impede que você crie funções direto no ambiente de um cliente: a diferença é que uma função criada assim é local, e não fica sincronizada com nada.

Aplicar a um cliente, ou a todos

Duas ações por modelo:

Aplicar a um cliente. Você escolhe o cliente e confirma. A tela explica que isso aplica as permissões atuais do modelo àquele cliente como uma função gerenciada, e que você ainda pode definir o escopo de frameworks e documentos depois.

Aplicar a todos os clientes. A confirmação é explícita: cada cliente recebe, ou atualiza, uma função gerenciada com as permissões daquele modelo.

A palavra “atualiza” é a parte que merece atenção, e a próxima seção trata disso.

O que “aplicar a todos” realmente faz

Vale ler com cuidado antes de usar, porque a ação é ampla por natureza.

Ela não é apenas para clientes novos. Clientes que já têm aquela função gerenciada têm as permissões atualizadas para o estado atual do modelo.

Ela alcança toda a carteira de uma vez. Se você gerencia trinta clientes, são trinta ambientes afetados.

O uso legítimo é exatamente esse: quando o conjunto de permissões correto mudou e você quer padronizar. É o recurso funcionando como pretendido.

O cuidado que vale, então, é de sequência:

1. Aplique primeiro a um cliente, de preferência um de menor porte.
2. Entre naquele cliente e confira o que a função passou a permitir e a impedir.
3. Só então aplique a todos.

Esses três passos custam poucos minutos e evitam o caso desagradável: uma permissão a menos derruba o trabalho de várias pessoas ao mesmo tempo, em vários clientes, e a queixa chega por vários canais antes de você identificar a causa.

A sincronização é o valor, e é o que exige disciplina

O ponto forte do recurso é que as permissões permanecem gerenciadas centralmente. Você ajusta a definição de acesso num lugar e ela vale para a carteira.

E o outro lado é o que costuma surpreender: uma mudança sua chega ao cliente sem que ninguém ali tenha pedido.

Isso é normal em serviço gerenciado, e vale tratar com dois cuidados profissionais:

Avise antes de mudanças restritivas. Ampliar permissão raramente incomoda; retirar uma trava trabalho. Um aviso curto evita a impressão de instabilidade.

Deixe claro no contrato ou na apresentação que os acessos são padronizados por você. É a diferença entre “vocês mudaram meu acesso” e “é assim que o serviço funciona”.

O escopo é a peça que você ainda precisa definir

Vale insistir, porque é a fonte mais comum de erro de configuração: o modelo carrega permissões, e não escopo.

Depois de aplicar, para cada cliente, você ainda define a quais frameworks e documentos aquela função tem acesso.

A implicação: uma função aplicada e sem escopo definido pode não dar acesso ao que a pessoa precisa, e a queixa vai parecer um problema de permissão quando é de escopo. É a primeira coisa a conferir quando alguém diz que “a função está errada”.

Uma estrutura de modelos que funciona

Se você está decidindo quais modelos pedir, um conjunto enxuto cobre a maior parte dos casos:

Responsável de conformidade do cliente, com gestão de controles, evidências e documentos.

Colaborador, que envia evidências e cumpre tarefas, sem alterar configuração.

Leitura, para diretoria e áreas que só acompanham.

Operador da sua equipe, com o que a sua gente precisa para trabalhar na carteira.

Poucos modelos bem definidos são mais fáceis de manter, e muito mais fáceis de explicar ao cliente, do que uma coleção que cresceu por exceção.

Problemas comuns

Nenhum modelo de função foi concedido à sua MSSP ainda. Fale com a Imara para receber os modelos.

Não foi possível carregar os modelos de função. Falha momentânea. Recarregue.

Não foi possível aplicar o modelo de função. Tente novamente e confira se a função foi criada no cliente.

Apliquei e a pessoa continua sem acesso ao que precisa. Provável escopo não definido. Confira frameworks e documentos daquela função no cliente.

Alterei o modelo e um cliente não mudou. Confira se aquele cliente tem a função gerenciada aplicada. Aplicar a todos os clientes cria ou atualiza onde faltar.

A função de operador não aparece nos clientes. Correto. Ela se aplica ao seu próprio ambiente, automaticamente.