Spostamento dei servizi nel cloud

Suppongo che tu stia interpretando il cloud come un'istanza basata sul tenant dove sei su un server ospitato, con centinaia di altre società. Questo non è sempre il caso. Usando AWS come esempio, o Softlayer, puoi lanciare le tue istanze e utilizzare gli stessi principi per bloccare le cose. Ad esempio, lancia SOLO un firewall ACL consentendo connessioni alla tua istanza dalle fonti che desideri.

Ho avuto problemi con la consegna delle chiavi ai regni dei fornitori di servizi cloud. Una cosa che non faccio mai è fidarsi praticamente di tutto ciò che dicono. Vado a bloccare le mie istanze nello stesso modo in cui lo farei se fossero fisicamente presenti. Il problema più grande che ho anche con quel modello è che le persone falliscono, i servizi falliscono, quindi sono disposto a cogliere questa occasione?

Pensa a quanto segue, crei un'istanza bloccandola all'ennesima potenza. Un dipendente razionale di Softlayer scatta un'istantanea del tuo ospite ESX, lo esporta. Non lo sapresti mai, non importa quello che hai messo sul tuo ospite. Questo non vuol dire che qualcuno in Softlayer o in un'altra azienda lo farebbe, ma c'è questa possibilità. Sei in balia di un'altra organizzazione e speri che siano in cima al loro gioco per quanto riguarda la sicurezza. Questo è di per sé ridicolo considerando la quantità di aziende che sono state violate.

Quindi per me ... Avrei dovuto buttare su un server di chat, certo, sarebbe stato criptato sul filo, in transito, logging fuori sede, blocco completo come tutto il resto. Vorrei vomitare dire che i miei database memorizzano cose mission critical? No grazie. Questo sono solo io.

Per il tuo primo punto, sì, ci può essere un rischio maggiore. A seconda di ciò che un attaccante è dopo, un fornitore di cloud è un grande obiettivo. Puoi potenzialmente ottenere molte informazioni succose sugli obiettivi o forse anche sui materiali di autenticazione. Un grande esempio di questo è la violazione di MongoHQ che ha comportato la compromissione del Buffer in quanto avevano memorizzato i loro token di accesso non criptati.

La buona notizia è che se stai spostando servizi verso servizi di terze parti, presumibilmente avrai più risorse per rivedere questi fornitori. Ovviamente come niente non c'è un proiettile d'argento, ma ho trovato un buon successo con i fornitori di auditing prima di accettare di pagarli. L'importante è che questo processo sia leggero, ma dal momento che sei un professionista della sicurezza sono sicuro che è una delle prime cose nella tua mente. I processi che coinvolgono l'attrito spesso non vengono seguiti.

Ho avuto la fortuna di creare un questionario di 20 domande per chiedere potenziali venditori di cloud. Chiedendo cose come il loro team di sicurezza è strutturato (oh non ce l'hai, grazie per aver giocato), come eseguono la sicurezza operativa, qualsiasi standard cui aderiscono, ecc. Può aiutarti a fare una scelta.

Il processo dovrebbe essere trasparente e consentire di valutare ogni categoria e fornire un punteggio complessivo. Questo è importante per i tuoi utenti interni in modo che capiscano perché non possono archiviare i tuoi dati importanti in un ambiente di un fornitore con un punteggio scarso. Le tue politiche di classificazione dei dati potrebbero essere diverse dalle mie, ma in pratica non utilizzeresti un provider con un punteggio basso con dati sensibili. Se stanno ospitando una directory aziendale che è solo foto e informazioni di contatto, forse il rischio non è così grande. Se ospitano i tuoi registri di chat, che potresti segnalare correttamente potrebbero contenere informazioni sensibili, vorresti che siano più abbottonati.

Hai il conforto che quando il tuo fornitore di servizi cloud viene compromesso o si blocca, sarai in compagnia di molti altri.