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 funzioni di integrazione con accesso.
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 in Credential Type 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 l’integrazione prevista, Health e Usage e si verifica il funzionamento dell’integrazione. 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
La vista elenco mostra:
- Healthy, Partially healthy o Unhealthy,
- un trattino invece del simbolo Health e Awaiting usage al passaggio del mouse, se non è mai stata usata,
- Last accessed, con ultimo utilizzo ed eventuali avvisi di inattività,
- Used by, con le funzioni di integrazione che possono usare la Credential,
- il Credential type,
- 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.
La pagina di dettaglio mostra anche Vendor, Vendor Identifier, Permissions e Integration Access. Usage mostra il numero delle request e l’ora dell’ultima richiesta. 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 funzionamento. Used by e Integration Access mostrano funzioni di integrazione, ma non sostituiscono un inventario interno delle singole istanze da verificare prima della modifica.
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à e sottoposta a Purge definitivo 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. Devono essere configurate regole di e-mail alert per Credential Manager. Un Super Admin apre Global Settings > Platform > Notification Settings > Configure Email Alerts e verifica destinatari, frequenza e tipi di alert. L’attivazione della prima Custom Rule disabilita le impostazioni dei destinatari esistenti: amministratori e liste necessari vanno quindi inclusi esplicitamente in una regola adatta.
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.
Sostituire i valori della Credential in modo controllato
Credential Manager non ruota autonomamente il secret nel prodotto terzo. Se il fornitore ne supporta la sostituzione, la procedura documentata va coordinata con l’aggiornamento in Central durante una finestra di manutenzione:
- Rilevare le istanze concrete, Used by, Integration Access e l’ultimo utilizzo.
- Preparare un valore sostitutivo secondo la documentazione del prodotto terzo.
- Aggiornare la Credential in Central con Actions > Edit.
- Verificare Health, Usage e le funzioni di integrazione interessate.
- Revocare il vecchio valore solo dopo la verifica e secondo la procedura del fornitore.
- Controllare audit e log delle integrazioni.
Solo il prodotto terzo stabilisce se vecchio e nuovo valore possano sovrapporsi. Se la sovrapposizione non è documentata, non si promette un cambio senza interruzioni: si pianifica e monitora una possibile interruzione.
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.
Una modifica interrompe più integrazioni
La Credential viene riutilizzata. Used by indica inizialmente l’impatto; vanno inoltre individuate nell’inventario interno tutte le istanze concrete e testate insieme.
Delete segnala un possibile utilizzo
Non ignorare l’avviso. Prima migrare o rimuovere tutte le integrazioni collegate, poi eliminare la Credential.