Operar o Sophos Fusion Integration Credential Manager
O Integration Credential Manager gere credenciais de produtos de terceiros utilizadas pelo Sophos Fusion (anteriormente Sophos Central) em integrações. Entre os exemplos encontram-se API Tokens ou contas para Data Ingestion e Response Actions.
Não deve ser confundido com API Credentials. As API Credentials permitem que uma aplicação externa aceda ao Sophos Fusion. No Credential Manager, pelo contrário, o Sophos Fusion guarda credenciais para aceder a um produto de terceiros.
Quando utilizar o Credential Manager
Cria-se uma Credential nesta área quando uma integração Sophos suportada necessita de acesso a um produto externo e esse tipo de Credential está disponível no Central. O Manager pode reutilizar credenciais em várias integrações do mesmo tipo e mostra o Health, a última utilização, as permissões e as funções de integração com acesso.
Não é possível guardar qualquer tipo de secret. Para integrações não suportadas, o Secret Store central da empresa continua a ser a referência.
Planear previamente as permissões
Antes da criação, definem-se:
- o produto de terceiros e a instância de destino,
- as ações Read ou Write permitidas,
- as funções Sophos com acesso à Credential,
- o responsável técnico e o contacto de emergência,
- a data de expiração e o processo de rotação,
- o limite de inatividade,
- o teste e a reversão.
O acesso Write só é concedido quando as Response Actions são efetivamente necessárias e também estão limitadas no produto de terceiros. Uma integração que apenas lê telemetria não recebe direitos de alteração.
Criar uma Credential
O caminho é Global Settings > Access Control > Integration Credential Manager. Add abre a página Type, onde em Credential Type se seleciona um tipo suportado, por exemplo Okta API Token, e se confirma com Next.
Em Details, introduzem-se o nome e a descrição, a permissão Read ou Write e, em Integrations with Access, selecionam-se apenas as funções Sophos necessárias, por exemplo Data Ingestion ou Response Action. Opcionalmente, definem-se o Inactivity limit e, se disponível para esse tipo, a Expiration date. À direita, confirma-se a indicação em Vendor and Product documentation and disclaimer depois de verificar as implicações de segurança.
Se a caixa de confirmação do disclaimer ainda não tiver sido selecionada em Details, o Central volta a disponibilizar a confirmação na página seguinte. Sem uma confirmação consciente, a Credential não é disponibilizada para produção; o diálogo adicional não substitui a análise interna do acesso de terceiros.
Na página Credential, introduzem-se os valores exigidos pelo produto de terceiros, no exemplo do Okta, o URL e o API Token. Estes valores provêm da configuração do produto em causa e não de um exemplo externo. Save cria a Credential; em seguida, verificam-se a integração prevista, o Health e a Usage e testa-se o funcionamento da integração. Em alternativa, durante a configuração, uma integração suportada pode criar uma Credential com permissões predefinidas, que posteriormente são restringidas no Manager.
A própria conta externa também recebe Least Privilege. Uma configuração restritiva no Central não compensa uma conta com privilégios excessivos no produto de terceiros.
Monitorizar o Health e a utilização
A vista de lista mostra:
- Healthy, Partially healthy ou Unhealthy,
- um traço em vez do símbolo de Health e Awaiting usage ao passar o cursor, caso nunca tenha sido utilizada,
- Last accessed, com a última utilização e possíveis avisos de inatividade,
- Used by, com as funções de integração que podem utilizar a Credential,
- o Credential type,
- avisos antes da suspensão ou do Purge.
Um estado verde da Credential apenas demonstra que a utilização técnica funciona. Não confirma que os dados chegam na íntegra ou que uma Response Action produz o efeito operacional correto. Por isso, verificam-se o evento de teste, o timestamp e o resultado no sistema de destino.
A página de detalhes também mostra Vendor, Vendor Identifier, Permissions e Integration Access. Usage mostra a quantidade de Requests e a data/hora do último pedido. Logs contém apenas os 250 eventos mais recentes e pode ser filtrado por estado, tipo de integração e período. Para permitir uma rastreabilidade mais longa, os erros relevantes são transferidos para a monitorização operacional ou para um caso de suporte antes de serem substituídos.
Editar, suspender ou eliminar uma Credential
Para editar, abre-se o nome da Credential em Global Settings > Access Control > Integration Credential Manager e seleciona-se Actions > Edit. O Central mostra as mesmas páginas de configuração utilizadas durante a criação. Em Details, podem alterar-se o nome, a descrição, as permissões, o acesso das integrações, o limite de inatividade e, se aplicável, a expiração; em Credential, substituem-se os valores reais do fornecedor. Depois de guardar, testam-se Health, Usage e funcionamento. Used by e Integration Access mostram funções de integração, mas não substituem um inventário próprio das instâncias concretas que devem ser verificadas antes da alteração.
Para uma suspensão manual, seleciona-se a Credential, utiliza-se Actions > Suspend e confirma-se novamente o aviso de utilização. Isto é útil em caso de suspeita de comprometimento ou para uma análise de erros controlada, mas interrompe a utilização de dados e Response por todas as integrações dependentes. Actions > Unsuspend reativa a Credential e repõe o prazo de inatividade em seis meses ou no valor configurado individualmente.
No caso de Credentials que já não são necessárias, todas as dependências são primeiro alteradas. Em seguida, seleciona-se a Credential, utiliza-se Actions > Delete e confirma-se o aviso. A eliminação não revoga automaticamente a conta ou o token associado no produto de terceiros; esse acesso também tem de ser removido ou rodado nesse produto.
Inatividade, suspensão e Purge
Por predefinição, uma Credential é suspensa após seis meses, ou 180 dias, de inatividade e submetida a Purge definitivo após um ano. Em Actions > Edit > Inactivity limit, pode selecionar-se, por exemplo, a suspensão após um ano e o Purge após dois anos. Uma alteração inicia imediatamente o novo prazo e remove os avisos existentes.
Antes de prolongar um limite de inatividade, clarifica-se se a integração ainda é necessária. Uma ação de emergência raramente utilizada precisa de um teste de função documentado e não apenas de um secret sem limite.
O Central avisa 90 dias antes da suspensão. Antes de um Purge, são enviados avisos com 90, 60, 30 e 7 dias de antecedência. É necessário configurar regras de E-mail Alert para Credential Manager. Um Super Admin abre Global Settings > Platform > Notification Settings > Configure Email Alerts e verifica destinatários, frequência e tipos de alerta. Ativar a primeira Custom Rule desativa as definições de destinatários existentes; por isso, os administradores e as listas necessários devem ser incluídos explicitamente numa regra adequada.
Com Actions > Reset inactivity limit, o prazo de inatividade restante é novamente definido para seis meses ou para o valor configurado. Actions > Unsuspend reativa uma Credential suspensa e reinicia o mesmo prazo. Antes disso, verificam-se o secret externo, as permissões e as integrações dependentes; Unsuspend não corrige um token expirado ou revogado.
Uma suspensão manual interrompe a transmissão de dados de todas as integrações que utilizam a Credential. Um Purge ou uma eliminação pode interromper permanentemente várias integrações se a Credential for reutilizada.
Substituir os valores da Credential de forma controlada
O Credential Manager não roda por si próprio o secret no produto de terceiros. Se o fornecedor suportar a substituição, o procedimento documentado deve ser coordenado com a atualização no Central durante uma janela de manutenção:
- Registar as instâncias concretas, Used by, Integration Access e a última utilização.
- Preparar um valor de substituição segundo a documentação do produto de terceiros.
- Atualizar a Credential no Central através de Actions > Edit.
- Verificar Health, Usage e as funções de integração afetadas.
- Revogar o valor antigo apenas após a verificação e segundo o procedimento do fornecedor.
- Verificar os Audit Logs e os registos da integração.
Só o produto de terceiros determina se os valores antigo e novo podem sobrepor-se. Se isso não estiver documentado, não se promete uma mudança sem interrupção; planeia-se e monitoriza-se uma possível interrupção.
Problemas típicos
O estado permanece em Awaiting usage
A Credential ainda não está atribuída a uma integração ativa, a integração ainda não foi executada ou foi selecionado o conjunto de Credentials errado. Verificar a atribuição e o evento de teste.
A Credential está saudável, mas faltam dados
Verificar o período, a fonte de dados, a integração, os filtros e as permissões no produto de terceiros. O Health não confirma todos os volumes de dados funcionais.
Uma alteração interrompe várias integrações
A Credential é reutilizada. Used by dá uma primeira indicação do impacto; além disso, identificam-se no inventário próprio todas as instâncias concretas e testam-se em conjunto.
Delete indica uma possível utilização
O aviso não é ignorado. Primeiro, alteram-se ou removem-se todas as integrações associadas; só depois se elimina a Credential.