L’approfondimento di oggi è dedicato alla delicata questione della sicurezza in ambienti cloud IaaS. Negli ultimi tempi si è parlato molto tra gli addetti ai lavori di servizi agent-based (che si affidano quindi a degli agent) ed agentless (che ne fanno a meno) e di quale architettura servizi sia ideale per proteggere un’infrastruttura online. Nella prima parte del post spiegheremo sinteticamente in cosa differiscano le due soluzioni mentre nella seconda parte vedremo quale sia preferibile utilizzare.
Un workload cloud che si appoggia ad una soluzione agent-based richiede in primo luogo l’installazione di un software agent in ciascuna istanza del server: ognuno di essi si occuperà a sua volta di raccogliere informazioni importanti (traffico tra i server, setup del firewall adoperato dall’host etc.) dall’istanza in cui è stato installato, inviandole infine al sistema di controllo centrale. Le soluzioni agent-based consentono all’utente di gestire la sicurezza al livello dell’istanza/macchina virtuale.
Come mostra la figura, i vari agent presenti in ciascuna istanza inviano informazioni al centro di controllo
Un approccio agentless, come suggerisce il termine, non prevede l’impiego di agent (non occorre intervenire quindi sulle altre entità dell’ambiente come servizi database, istanze, load balancer etc.) risultando maggiormente “trasparente” alle applicazioni ed ai workload. Il sistema centrale “dialoga” infatti con l’infrastruttura IaaS sottostante grazie alle API fornite dal cloud provider. E’ anche per questo motivo che ci si riferisce ai servizi agentless con i termini cloud-native o API-based services.
Il sistema centrale riceve informazioni dall’infrastruttura IaaS grazie alle API del cloud provider
Perchè agentless?
Gli addetti ai lavori sono concordi nel ritenere le soluzioni agentless preferibili alle agent-based in quanto in grado di adattarsi meglio all’attuale “dinamicità” del cloud. Le piattaforme agent-based appartengono infatti alle “prime fasi di vita” del cloud in cui le infrastrutture non erano caratterizzate da un elevato numero di funzionalità come ora; fornendo inoltre degli strumenti simili a quelli adottati in ambienti on premise, si rivelavano ideali per facilitare la migrazione delle imprese e renderla meno “traumatica”. Al giorno d’oggi la situazione è differente; sono almeno 5 i motivi per cui una soluzione agent based non è preferibile ad una agentless, ecco quali:
1) Gestione complessa. Come abbiamo visto nel paragrafo di apertura, per raccogliere informazioni una piattaforma agent-based si affida ad un numero di agent pari a quello delle istanze presenti nell’ambiente cloud in uso. Considerando che è possibile avere a che fare con decine, centinaia o anche migliaia di istanze, ciascuna delle quali può essere anche cancellata o creata in un lasso di tempo relativamente breve, è evidente che nel cloud un compito semplice come quello della gestione degli agent possa rivelarsi arduo.
2) Impossibile installare gli agent su ogni servizio. Il cloud è in continua evoluzione: i servizi che erano disponibili cinque anni fa sono ora stati migliorati, sostituiti ed affiancati da una schiera ancora più ampia di soluzioni – anche native. Nel caso di Amazon Web Services abbiamo ad esempio le categorie: calcolo, storage e distribzione di contenuti, analisi, Internet of Things, strumenti per gli sviluppatori e così via, ognuna delle quali con le proprie sottocategorie. Impiegare soluzioni agent-based non è sempre possibile e numerosi servizi – usati di frequente dalle aziende come DynamoDB, RDS, EMR, ElasticSearch, Lambda – semplicemente non li supportano. Affidarsi ad un approccio agent-based significherebbe quindi non essere in grado di proteggere e monitorare con efficacia il proprio ambiente cloud o dover rinunciare in futuro all’uso di tali servizi.
3) Policy di sicurezza ed inclusione dei servizi cloud nativi. Le piattaforme agent-based non sono state pensate per interagire con servizi cloud nativi (Elastic Load Balancing, Relational Database Service etc.) e presentano quindi diverse limitazioni in fase di setup delle policy. Non è ad esempio possibile creare per una determinata istanza una “regola” che preveda l’invio del traffico in uscita solo ad RDS. L’unica soluzione è quella di adottare delle regole che autorizzino l’invio a qualsiasi tipologia di servizio.
4) Scarsa flessibilità della soluzione. L’approccio agent-based prevede sempre l’installazione di agent, sia che ci si affidi ad un provider nazionale come Hosting Solutions che ad uno “globale” come Google, una procedura abbastanza complessa da gestire (punto 1). L’approccio agentless è molto più flessibile: ciascuna piattaforma cloud consente di impostare le policy di sicurezza in maniera “agnostica”, quindi attraverso procedure standard che non differiscono a seconda del provider scelto – tra un’infrastruttura IaaS e l’altra cambia solo il modo in cui le regole di sicurezza saranno implementate ma questo non va ad incidere sulla prima fase di setup (a cura dell’utente).
5) Inutile consumo di risorse. Gli agent devono comunicare con il sistema centrale e di conseguenza utilizzano una piccola parte della capacità di calcolo e della banda disponibile. Cioè andrà ad influire anche sulla periodica “bolletta” da pagare al provider. Una soluzione agentless non ha alcun impatto sulle prestazioni e sulla bolletta: la piattaforma di sicurezza comunica infatti “direttamente” con l’infrastruttura sottostante grazie alle API.
