Saltar para o conteudo
Avanet

Operar o Sophos Central Integration Credential Manager

O Integration Credential Manager gere credenciais de produtos de terceiros utilizadas pelo 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 Central. No Credential Manager, pelo contrário, o Sophos Central 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 integrações associadas.

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 primeiro a página Type, onde se seleciona um tipo de Credential 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 dependente, o Health, a Usage e um evento de teste. 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

Consoante a Credential, o Central 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,
  • a última utilização,
  • as integrações que a utilizam,
  • as permissões e o tipo de Credential,
  • 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.

Na página de detalhes, Usage mostra a quantidade e a data/hora dos Requests. 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, realizam-se testes de Health, Usage e função em todas as integrações identificadas em Used by.

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 removida 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. Estas notificações só são entregues de forma fiável se existirem regras de E-mail Alert adequadas para o Credential Manager.

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.

Rotação sem interrupção de dados

Para secrets que podem ser rodados no produto de terceiros, utiliza-se uma janela de manutenção:

  1. Registar as integrações dependentes e a última utilização.
  2. Gerar um novo secret no produto de terceiros.
  3. Atualizar a Credential no Central.
  4. Verificar o Health e o evento de teste.
  5. Revogar o secret antigo no produto de terceiros.
  6. Verificar os Audit Logs e os registos da integração.

Se o produto de terceiros suportar dois secrets em paralelo, utiliza-se uma sobreposição curta. Caso contrário, planeia-se e monitoriza-se uma pequena interrupção de dados.

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.

A rotação interrompe várias integrações

A Credential foi reutilizada. Em Used by, identificam-se todas as dependências 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.

Perguntas frequentes

O Integration Credential Manager é um cofre geral de palavras-passe?

Não. Suporta uma seleção limitada de tipos de Credentials para integrações Sophos. Os restantes secrets pertencem ao Secret Store da empresa.

Qual é a diferença relativamente às API Credentials?

As API Credentials dão a uma aplicação acesso ao Sophos Central. O Integration Credential Manager guarda credenciais com as quais o Sophos Central acede a um produto de terceiros. As funções, a rotação de secrets e os API Hosts são descritos em Gerir API Credentials do Sophos Central com segurança.

É possível utilizar uma Credential em várias integrações?

Sim, desde que o tipo o suporte. Isto reduz a quantidade de secrets, mas aumenta o raio de impacto em caso de rotação ou eliminação. As dependências têm de ser documentadas.