Atribuir corretamente funções administrativas no Sophos Central

A função adequada no Sophos Central segue o princípio do Least Privilege: Super Admin fica reservado à gestão de funções e APIs, Admin destina-se a uma administração abrangente, Help Desk a tarefas de suporte, Read-only apenas à consulta e User exclusivamente ao Self Service Portal. Para permissões mais granulares, utiliza-se uma Custom Role.

Qual é a função administrativa adequada?

O Sophos Central inclui cinco funções predefinidas. As funções adicionais de XDR e específicas de produtos dependem das licenças existentes.

Informação: as funções predefinidas não podem ser editadas nem eliminadas.

Super Admin

O Super Admin tem acesso total e gere adicionalmente funções, atribuições de funções, Custom Roles, API Tokens e API Credentials. A função pode abrir tickets no Sophos Support e ativar Remote Assistance.

Importante: tem de existir sempre pelo menos um Super Admin no tenant.

Admin

O Admin tem acesso alargado às funções licenciadas do Central, mas não pode gerir funções e atribuições de funções, API Tokens ou API Credentials. Um Admin também pode utilizar tickets de suporte e Remote Assistance. Na página Quarantined Messages, esta função pode libertar e-mails em quarentena.

Help Desk

O Help Desk tem, em princípio, acesso de leitura às definições, mas também pode consultar Logs e Reports sensíveis, receber Alerts e eliminá-los apenas quando a página de Alerts tiver sido aberta a partir do Dashboard, atualizar agentes Sophos, analisar computadores e alterar o Co-Branding. A função pode abrir tickets no Sophos Support, mas não ativar Remote Assistance. O Help Desk não pode gerir funções nem API Credentials.

Com uma licença Phish Threat, o Help Desk vê utilizadores, campanhas, séries, resultados e Reports. Contudo, a função não pode comunicar um e-mail como spam nem alterar os utilizadores atribuídos a uma campanha Phish Threat. Por isso, botões de edição indisponíveis e opções de funções em falta são limitações esperadas, não um erro de apresentação.

Read-only

O Read-only pode consultar definições, Logs sensíveis, Reports e Alerts, bem como abrir tickets no Sophos Support. Com uma licença Phish Threat, são visíveis utilizadores, campanhas, séries, resultados e Reports. Contudo, a função não pode ativar Remote Assistance, gerir funções ou API Credentials, atribuir Policies, alterar definições, eliminar Alerts, atualizar agentes nem analisar computadores. As ações de licença, como Start Trial e Apply License Key, também não estão disponíveis.

User

O User não tem direitos administrativos e utiliza apenas o Self Service Portal. A autorização e o ciclo de vida dos utilizadores são explicados em Configurar o acesso ao Sophos Central Self Service Portal.

Atribuir ou alterar uma função

Apenas um Super Admin pode atribuir ou alterar funções administrativas. Cada utilizador pode ter apenas uma função; uma nova atribuição substitui a anterior.

1. Abrir Global Settings > Access Control > Admins and Roles.
2. Selecionar o separador Roles e depois a função pretendida.
3. Junto de Role Members, clicar em Edit.
4. Mover utilizadores entre Available Users e Assigned Users e guardar com Save.

Depois da primeira atribuição de uma função administrativa, o utilizador recebe um e-mail para configurar a respetiva conta de administração. Verificam-se a entrega e o processo de login bem-sucedido; a presença da função na lista ainda não prova que o convite e a configuração de MFA estejam concluídos.

A função de um administrador que tenha sessão iniciada nesse momento não pode ser alterada. A pessoa afetada tem primeiro de terminar a sessão; se se tratar da própria função, outro Super Admin efetua a alteração. Em seguida, deve testar-se o login com a conta afetada e verificar se apenas estão disponíveis as páginas e ações previstas.

Verificar os detalhes da função e os direitos adicionais

Em Global Settings > Access Control > Admins and Roles > Roles, um clique no nome da função abre a página de detalhes. Esta mostra o Access Level Full, Help Desk ou Read-only, Capabilities especializadas e a lista dos administradores atribuídos. Um clique num nome abre os respetivos detalhes completos de utilizador.

Os campos de Capability mais importantes significam:

• Access sensitive logs & reports permite aceder a Logs e Reports sensíveis, incluindo Audit Logs.
• Access policy management permite alterar as definições das Policies.
• Access policy assignment permite atribuir Policies existentes a utilizadores e dispositivos.
• Start Live Response sessions on computers ou servers permite estabelecer uma ligação direta para investigar e limpar o respetivo tipo de dispositivo.
• Manage Data Collection and Investigation settings for computers ou servers permite ativar Live Response e uploads para o Data Lake na respetiva Data Collection and Investigation Policy.

Live Response e Data Collection and Investigation só estão disponíveis para Super Admins ou Custom Roles em que o produto necessário e a Capability adequada estejam selecionados em conjunto. Por esse motivo, a página de detalhes é verificada antes de uma atribuição e no controlo trimestral; o nome da função, por si só, não prova os direitos efetivos.

Funções personalizadas

Apenas os Super Admins podem criar Custom Roles em Global Settings > Access Control > Admins and Roles > Roles > Add role. Seleciona-se uma função base e atribui-se a cada produto o Access Type Full, Help Desk, Read-only ou None. Outras opções, por exemplo para Logs, Policies ou Live Response, dependem do produto, do Access Type e do âmbito da licença.

Um exemplo prático é uma função Endpoint Help Desk com a função base Read-only, o produto Endpoint Protection e o Access Type Help Desk. Os produtos não necessários recebem None. Os direitos adicionais para Logs, atribuição de Policies ou Live Response são autorizados individualmente.

Ao criar a função, depois de Add role, introduzem-se o nome e a descrição, seleciona-se uma Base Role e define-se um Access Type próprio para cada produto necessário. Deste modo, Endpoint Protection pode, por exemplo, receber Help Desk, Mobile Read-only e todos os restantes produtos None. Seguem-se apenas os direitos adicionais expressamente necessários. Save cria a função; só depois esta é atribuída a um administrador e testada com a respetiva conta.

Policy Management e Policy Assignment

Nas Custom Roles, Policy Management e Policy Assignment não são a mesma coisa:

• Policy Management permite criar, alterar e eliminar Policies.
• Policy Assignment permite atribuir Policies existentes a utilizadores, grupos ou dispositivos.

As duas opções são mutuamente exclusivas. Policy Management é mais abrangente e pode conceder direitos de alteração significativos a uma base Help Desk ou Read-only originalmente limitada.

Ter em conta as Shared Settings

Determinadas definições globais são utilizadas em conjunto por Endpoint e Server, e algumas também por Encryption. Entre elas estão Tamper Protection, Allowed Applications, Website Management, Proxy Configuration, Blocked Items, Bandwidth Usage com acesso adicional a Encryption, DLP Rules, Manage Content Control List, Reject Network Connections e o XDR Threat Analysis Center.

Se uma Custom Role não tiver acesso a um dos produtos envolvidos, a definição partilhada poderá estar disponível apenas para leitura. Não se trata de um erro da UI, mas de uma consequência do âmbito combinado.

Direitos adicionais críticos e respetivos requisitos

Os direitos adicionais não entram em vigor apenas por a caixa de verificação estar visível. A Base Role, o produto e o Access Type também têm de ser compatíveis:

O Logs & Reports access aplica-se a todos os produtos e Access Types da Custom Role. O mesmo se aplica a Policy Management e Policy Assignment, embora estes dois direitos continuem a ter efeitos distintos. Cada combinação é verificada com uma conta de teste: a ação autorizada tem de funcionar e uma ação não autorizada tem de falhar. Em particular, Live Response, upload para o Data Lake, desativação de Tamper Protection e remoção de isolamento recebem um Owner identificado e são verificados trimestralmente.

Direitos XDR dependentes da licença

Com uma licença XDR, o Central acrescenta às funções capacidades específicas de investigação e Response. Estes direitos não estão incluídos de forma geral num «acesso XDR»:

Um item de menu visível não prova a autorização. Para ações particularmente eficazes, verificam-se com uma conta de teste tanto um caso autorizado como um caso recusado, e documenta-se o estado da licença juntamente com a função.

Adicionar um administrador

Apenas um Super Admin pode atribuir uma função administrativa. Em Global Settings > Access Control > Admins and Roles > Admins, cria-se um novo utilizador como Admin ou, no separador Roles, atribui-se uma função a um utilizador existente.

Para um novo administrador, seleciona-se Add Admin no separador Admins. Na página Add User, introduzem-se o nome, o endereço de e-mail e a função prevista. Exchange Login e Manager são opcionais. Se necessário, move-se um grupo de Available groups para Assigned groups. Save conclui a criação, enquanto Save and Add Another guarda e abre diretamente o registo seguinte. Em seguida, o Central envia automaticamente o e-mail de boas-vindas para a configuração da conta administrativa.

Um utilizador já existente não é novamente criado. No separador Roles, abre-se a função de destino, seleciona-se Edit em Role Members e move-se a pessoa, com as setas de seleção, de Available Users para Assigned Users. Save aplica a atribuição. Se o utilizador já tiver outra função, a nova seleção substitui-a por completo.

O Email setup link diz respeito à proteção de um dispositivo e é distinto do e-mail de boas-vindas para acesso administrativo. Para um rollout de software gerido centralmente, não se utiliza um Setup Link pessoal como substituto.

Retirar uma função administrativa ou eliminar um utilizador

Apenas um Super Admin pode remover administradores. Existem duas intervenções diferentes: retirar a função administrativa mantém o utilizador normal do Central, enquanto Delete user elimina o objeto de utilizador.

Para retirar apenas a função, abre-se Global Settings > Access Control > Admins and Roles > Roles. Na função pretendida, seleciona-se Edit junto de Role Members. Em Assigned Users, marca-se a pessoa e remove-se com as setas de seleção. Depois disso, permanece como utilizador sem esses direitos administrativos e pode continuar a dispor de funções de utilizador específicas do produto.

Para eliminar, abre-se o nome do administrador em Global Settings > Access Control > Admins and Roles > Admins e seleciona-se Delete user. Antes disso, verificam-se dispositivos, Policies, mailboxes, Directory Owner e responsabilidade de suporte.

Um utilizador eliminado pode reaparecer automaticamente. Se iniciar sessão num dispositivo associado que continue a ser gerido pelo Central, este volta a criá-lo como utilizador. Se tiver origem em AD, Entra ID ou Google Directory e continuar no âmbito de sincronização ativo, também será recriado na próxima execução do diretório. Por isso, um offboarding sustentável começa por remover a atribuição na origem ou bloquear a conta e só depois elimina o objeto do Central.

Resolver problemas de funções causados por endereços de e-mail duplicados

Uma função administrativa requer um endereço de e-mail único no tenant e entre outras contas do Central. Se o endereço estiver em falta ou já existir o mesmo e-mail ou nome de utilizador, o Central recusa a atribuição. Em caso de conflito noutro tenant do Central, é necessário introduzir aí um endereço alternativo ou pedir ao administrador responsável que limpe o registo já desnecessário.

Para duplicados sincronizados a partir do AD, o processo controlado é o seguinte:

1. Abrir My Environment > Users & Groups e procurar o endereço de e-mail completo.
2. Se aparecerem vários resultados, definir qual utilizador deve receber a função administrativa.
3. Abrir cada outra entrada duplicada editável, selecionar Edit, remover o endereço de e-mail duplicado e confirmar com Save.
4. Repetir a procura até restar apenas o registo único pretendido.
5. Abrir esse utilizador, selecionar Edit, definir a função prevista em Role e selecionar Save.

Se apenas estiver visível um utilizador que não pode ser editado ou se não for possível guardar a alteração, normalmente o e-mail já está a ser utilizado noutra conta Sophos Central ou SSP. A eliminação local de outros utilizadores sincronizados não resolve este conflito entre tenants.

Reenviar o e-mail de boas-vindas e o convite SSP

O Central envia o e-mail de boas-vindas ou a notificação do Self Service Portal apenas uma vez aquando da atribuição de uma função. O URL nele contido não tem data de expiração. Se a mensagem também não estiver no filtro de spam, não existe um botão Resend separado: depois de verificar as consequências, o utilizador tem de ser removido do Central e novamente criado com a função ou atribuição SSP adequada.

Antes da eliminação, verificam-se os dispositivos, as Policies, as mailboxes e as associações a grupos. Se o mesmo endereço de e-mail já estiver associado a outra Sophos Central Admin Account ou a um Self Service Portal de outra conta do Central, a nova criação também não enviará um e-mail de boas-vindas. Um endereço de e-mail só pode ser utilizado uma vez; é necessário resolver primeiro o conflito na outra conta.

Eliminar uma Custom Role

Apenas um Super Admin pode eliminar uma Custom Role; as funções predefinidas não podem ser removidas. Enquanto ainda existirem administradores atribuídos à Custom Role, o Central bloqueia a eliminação. Primeiro, estas pessoas são transferidas de forma controlada para outra função ou removidas da função.

O caminho é Global Settings > Access Control > Admins and Roles > Roles. Na lista de funções, marca-se a linha em causa num ponto fora do nome da função e seleciona-se Delete. Um segundo Delete confirma a eliminação definitiva. Em seguida, verificam-se as contas de teste e as atribuições de funções documentadas para garantir que nenhuma documentação de automação ou de transição continua a referir a função removida.

Um utilizador pode ter apenas uma função administrativa. A nova função substitui a anterior. Depois de cada atribuição, testa-se o login numa sessão privada do browser e verifica-se se os Logs sensíveis, as alterações de Policies, Live Response e os acessos aos produtos funcionam exatamente como previsto.

Revisão trimestral das funções

O controlo abrange:

• todos os Super Admins e a respetiva recuperação de MFA,
• utilizadores sem um Owner atual,
• Custom Roles e a respetiva função base,
• acesso aos produtos Full, Help Desk, Read-only ou None,
• Logs e Reports sensíveis,
• Policy Management ou Assignment,
• Live Response e Data Collection,
• API Credentials como identidades técnicas separadas.

As Custom Roles não utilizadas só são eliminadas depois de nenhum membro ou processo continuar a depender delas. As alterações de funções são verificadas no Audit Log.

Problemas típicos

Não é possível atribuir a função

O utilizador não tem um endereço de e-mail, o mesmo endereço de e-mail já existe no Central ou está associado a outra conta do Central. No caso de duplicados sincronizados, corrigem-se a origem do diretório e o Matching, em vez de simplesmente criar mais utilizadores.

Não é possível alterar a própria função

A própria função ativa não pode ser substituída pelo utilizador. Um segundo Super Admin efetua a alteração depois de a pessoa afetada terminar a sessão.

O Custom Admin vê um produto, mas não pode alterar as Global Settings

O acesso ao produto, a Base Role, a Capability adicional e as Shared Settings são verificados em conjunto. O acesso apenas a Endpoint ou apenas a Server pode ser insuficiente para as definições partilhadas.

O acesso de Admin funciona, mas a recuperação de MFA não

A função e a autenticação são independentes. São preparados pelo menos dois métodos de MFA e um segundo Super Admin de acordo com Proteger o login no Sophos Central com MFA, Passkeys e IdP.

Perguntas frequentes