Sai mantenere un segreto? E l’ambiente dei dati della tua organizzazione?

In una rete IT, un “segreto” è qualsiasi dato che deve rimanere riservato. Tipicamente, i “segreti” sono usati per l’autenticazione o come input per un algoritmo crittografico. I “segreti” comuni includono:

• Credenziali di account privilegiati
• Chiavi SSH
• Chiavi e credenziali API e di altre applicazioni, comprese quelle utilizzate all’interno di container, sistemi CI/CD, processi di automazione, software RDP (Remote Desktop Protocol) e persino software di sicurezza
• Password dei database e altre password system-to-system.
• Certificati TLS/SSL e altri certificati privati per la comunicazione sicura
• Chiavi di crittografia private

Dal momento che i secrets della rete IT sbloccano l’accesso a sistemi e dati altamente privilegiati, proteggere i segreti è fondamentale per prevenire i cyberattacchi tanto quanto proteggere le password degli utenti finali. Circa il 75% degli attacchi ransomware coinvolgono credenziali compromesse – la maggior parte delle volte, credenziali RDP.

Come i “segreti” vengono compromessi

Una delle più grandi sfide alla gestione dei “segreti” è la dispersione dei “segreti”, che si verifica quando le organizzazioni utilizzano un approccio ad-hoc alla loro gestione. Diversi dipartimenti, team e persino membri del team gestiscono autonomamente i “segreti” sotto il loro controllo.

Questo approccio può sembrare ragionevole all’inizio. Per esempio, un nuovo microsito ha bisogno di accedere a un database. L’amministratore ha già un file di configurazione con dati sensibili, quindi perché non mettere al sicuro la chiave di accesso al database nello stesso file di configurazione, quindi assicurarsi che quel file sia protetto? Questo funziona quando un’organizzazione ha un numero relativamente basso di “segreti” da proteggere.

Tuttavia, quando le organizzazioni crescono, crescono anche i loro ambienti dei dati – e i “segreti” memorizzati al loro interno. Prima che il team IT se ne renda conto, i “segreti” si sono moltiplicati – solo le chiavi SSH possono essere migliaia – e sono sparsi in tutta la rete, senza un ordine particolare.

Le credenziali hardcoded o embedded sono un altro ostacolo alla gestione dei “segreti”. Molte soluzioni software, dispositivi IoT e altro hardware sono forniti con credenziali predefinite hardcoded. Se questi dispositivi e app vengono distribuiti senza cambiare le credenziali di default, i criminali informatici possono facilmente accedervi utilizzando strumenti di scansione insieme a dizionari brute-force o altri attacchi di password – o possono semplicemente consultare il manuale del dispositivo o dell’app, che contiene le credenziali di default.

Negli ambienti DevOps, i comuni strumenti di pipeline CI/CD come Jenkins, Ansible, Github Actions e Azure DevOps utilizzano segreti per accedere a database, server SSH, servizi HTTP e altri sistemi sensibili. Questi segreti sono memorizzati in un file di configurazione per il sistema di deployment o in uno di una dozzina di diversi vault di archiviazione, tutti che forniscono capacità diverse a seconda del prodotto. In uno scenario in cui gli amministratori non stanno memorizzando le credenziali nei file di configurazione o nei sistemi, è probabile che siano memorizzati nei loro ambienti DevOps. Qualunque sia il caso, gli amministratori possono o non possono avere alcun avviso sull’uso di questi segreti.

Mentre alcuni strumenti includono secrets managers integrati, che consentono alle organizzazioni di rimuovere le credenziali hardcoded/incorporate, i secrets managers funzionano solo con quegli strumenti, il che non risolve il problema della dispersione dei “segreti”.

Keeper Secrets Manager: Sicurezza Zero-Trust, Zero-Knowledge per i segreti della tua rete

Keeper è lieta di annunciare il lancio di Keeper Secrets Manager, la prima e unica piattaforma zero-knowledge basata su cloud e completamente gestita per proteggere le chiavi segrete dell’infrastruttura, quali chiavi API, password di database, chiavi di accesso, certificati e qualsiasi tipo di dato riservato.

Keeper Secrets Manager sfrutta lo stesso modello di sicurezza zero-knowledge della piattaforma Enterprise Password Management (EPM) di Keeper.

Con Keeper Secrets Manager, tutti i server, le pipeline CI/CD, gli ambienti di sviluppo e le applicazioni sviluppate in casa estraggono i segreti da un endpoint API sicuro. Ogni “segreto” viene crittografato con una chiave AES a 256 bit, e poi nuovamente crittografato da un’altra chiave applicativa AES-256. Il dispositivo client recupera il testo cifrato dal cloud Keeper, e i “segreti” vengono decifrati e utilizzati localmente sul dispositivo – non sui server di Keeper.

Inoltre, tutte le richieste del server sono ulteriormente crittografate con una chiave AES-256 via TLS per evitare attacchi Man-in-the-Middle. Questa crittografia multistrato è gestita in modo trasparente attraverso i nostri SDK lato client, che sono facili da integrare in qualsiasi ambiente.

Mentre le soluzioni concorrenti di secrets management richiedono ai clienti di acquistare hardware speciale, installare un servizio proxy o utilizzare un fornitore di servizi cloud specifico, Keeper Secrets Manager si integra perfettamente in quasi tutti gli ambienti, senza hardware aggiuntivo o infrastruttura cloud-hosted richiesta. Offre integrazioni out-of-the-box con una vasta gamma di strumenti DevOps, tra cui Github Actions, Kubernetes, Ansible e altro.

Keeper Secrets Manager è un’estensione naturale di Keeper Enterprise Password Manager (EPM). È incorporato in Keeper Web Vault, Desktop App e Admin Console, con integrazioni nel modulo Advanced Reporting and Alerts di Keeper, BreachWatch, Webhooks, integrazione con soluzioni SIEM di terze parti e strumenti di conformità. Per esempio, qualsiasi credenziale hardcoded o embedded memorizzata nel Keeper Vault di un’organizzazione sarà soggetta alle scansioni di BreachWatch, e gli amministratori IT saranno avvisati se una di queste credenziali viene compromessa.

Fonte: Keeper Security