Gestire Sophos Central Integration Credential Manager
L’Integration Credential Manager gestisce le credenziali di prodotti terzi usate dalle integrazioni Sophos Central, per esempio API Token o account per Data Ingestion e Response Actions.
Non va confuso con API Credentials. Le API Credential permettono a un’applicazione esterna di accedere a Sophos Central. Nel Credential Manager, Sophos Central conserva invece credenziali per accedere a un prodotto terzo.
Quando usare il Credential Manager
Una Credential viene creata qui quando un’integrazione Sophos supportata deve accedere a un prodotto esterno e il relativo tipo è disponibile in Central. Il Manager può riutilizzare credenziali in più integrazioni dello stesso tipo e mostra Health, ultimo utilizzo, autorizzazioni e integrazioni collegate.
Non è possibile conservare qualsiasi tipo di secret. Per le integrazioni non supportate resta determinante il secret store aziendale centrale.
Pianificare prima le autorizzazioni
Prima della creazione si definiscono:
- prodotto terzo e istanza di destinazione,
- azioni Read o Write consentite,
- funzioni Sophos che accedono alla Credential,
- responsabile tecnico e contatto di emergenza,
- scadenza e procedura di rotazione,
- limite di inattività,
- test e ripristino.
L’accesso Write viene concesso solo se le Response Action sono realmente necessarie e limitate anche nel prodotto terzo. Un’integrazione che legge soltanto telemetria non riceve diritti di modifica.
Creare una Credential
Il percorso è Global Settings > Access Control > Integration Credential Manager. Con Add si apre prima la pagina Type, dove si sceglie un tipo supportato, per esempio Okta API Token, e si conferma con Next.
In Details si inseriscono nome e descrizione, autorizzazione Read o Write e, in Integrations with Access, solo le funzioni Sophos necessarie, per esempio Data Ingestion o Response Action. Facoltativamente seguono Inactivity limit e, se disponibile per il tipo, Expiration date. A destra, dopo aver verificato le implicazioni di sicurezza, si conferma l’avviso in Vendor and Product documentation and disclaimer.
Se la casella Disclaimer non viene confermata in Details, Central ripropone la conferma nella pagina successiva. Senza conferma consapevole la Credential non viene abilitata in produzione; il dialogo aggiuntivo non sostituisce la verifica interna dell’accesso al fornitore.
Nella pagina Credential si inseriscono i valori richiesti dal prodotto terzo, nell’esempio Okta URL e API Token. Provengono dalla configurazione del prodotto e non da un esempio estraneo. Save crea la Credential; in seguito si controllano integrazione dipendente, Health, Usage e un evento di test. In alternativa, un’integrazione supportata può creare durante il setup una Credential con diritti standard, da restringere poi nel Manager.
Anche l’account esterno deve applicare Least Privilege. Un’impostazione limitata in Central non compensa un account sovra-autorizzato nel prodotto terzo.
Monitorare Health e utilizzo
A seconda della Credential, Central mostra:
- Healthy, Partially healthy o Unhealthy,
- un trattino invece del simbolo Health e Awaiting usage al passaggio del mouse, se non è mai stata usata,
- ultimo utilizzo,
- integrazioni utilizzatrici,
- autorizzazioni e tipo di Credential,
- avvisi prima di sospensione o Purge.
Uno stato verde dimostra solo che l’uso tecnico funziona. Non conferma che i dati arrivino completi o che una Response Action abbia l’effetto operativo corretto. Si verificano quindi evento di test, timestamp e risultato nel sistema di destinazione.
Nella pagina di dettaglio, Usage mostra numero e ora delle request. Logs contiene solo gli ultimi 250 eventi e può essere filtrato per stato, tipo di integrazione e periodo. Per una tracciabilità più lunga, gli errori rilevanti vanno trasferiti nel monitoring operativo o in un caso di supporto prima che vengano sovrascritti.
Modificare, sospendere o eliminare una Credential
Per modificarla si apre il nome in Global Settings > Access Control > Integration Credential Manager e si seleziona Actions > Edit. Central mostra le stesse pagine del setup. In Details si cambiano nome, descrizione, diritti, accesso integrazioni, limite di inattività ed eventuale scadenza; in Credential si sostituiscono i valori del fornitore. Dopo il salvataggio si testano Health, Usage e funzione di tutte le integrazioni in Used by.
Per la sospensione manuale si seleziona la Credential, poi Actions > Suspend, e si conferma l’avviso sull’utilizzo. È utile in caso di sospetta compromissione o per un’analisi controllata, ma interrompe dati e Response di tutte le integrazioni dipendenti. Actions > Unsuspend riattiva la Credential e reimposta il termine di inattività a sei mesi o al valore configurato.
Per credenziali non più necessarie si migrano prima tutte le dipendenze. Seguono selezione, Actions > Delete e conferma dell’avviso. L’eliminazione non revoca automaticamente l’account o token corrispondente nel prodotto terzo, dove l’accesso va rimosso o ruotato separatamente.
Inattività, sospensione e Purge
Per impostazione predefinita, una Credential viene sospesa dopo sei mesi o 180 giorni di inattività ed eliminata dopo un anno. In Actions > Edit > Inactivity limit si può scegliere, per esempio, sospensione dopo un anno e Purge dopo due. La modifica avvia subito il nuovo termine e rimuove gli avvisi esistenti.
Prima di estendere il limite si chiarisce se l’integrazione serva ancora. Un’azione di emergenza usata raramente richiede un test funzionale documentato, non un secret illimitato.
Central avvisa 90 giorni prima della sospensione. Prima del Purge invia avvisi a 90, 60, 30 e 7 giorni. Le notifiche arrivano in modo affidabile solo se esistono regole di e-mail alert appropriate per il Credential Manager.
Con Actions > Reset inactivity limit il periodo residuo torna a sei mesi o al valore configurato. Actions > Unsuspend riattiva una Credential sospesa e reimposta lo stesso termine. Prima si verificano secret esterno, autorizzazioni e integrazioni dipendenti; Unsuspend non ripara un token scaduto o revocato.
La sospensione manuale ferma il trasferimento dati di tutte le integrazioni utilizzatrici. Un Purge o un’eliminazione può interrompere permanentemente più integrazioni se la Credential è condivisa.
Rotazione senza perdita di dati
Per i secret ruotabili nel prodotto terzo si usa una finestra di manutenzione:
- Rilevare integrazioni dipendenti e ultimo utilizzo.
- Generare un nuovo secret nel prodotto terzo.
- Aggiornare la Credential in Central.
- Verificare Health ed evento di test.
- Revocare il vecchio secret nel prodotto terzo.
- Controllare audit e log delle integrazioni.
Se il prodotto supporta due secret paralleli, si usa una breve sovrapposizione. Altrimenti si pianifica e monitora una piccola interruzione dei dati.
Problemi tipici
Lo stato resta Awaiting usage
La Credential non è assegnata a un’integrazione attiva, l’integrazione non è ancora stata eseguita o è stato scelto il set errato. Controllare assegnazione ed evento di test.
La Credential è healthy, ma mancano dati
Controllare periodo, fonte, integrazione, filtri e autorizzazioni nel prodotto terzo. Health non conferma ogni quantità operativa di dati.
La rotazione interrompe più integrazioni
La Credential è stata riutilizzata. In Used by si rilevano tutte le dipendenze e le si testa insieme.
Delete segnala un possibile utilizzo
Non ignorare l’avviso. Prima migrare o rimuovere tutte le integrazioni collegate, poi eliminare la Credential.