Container vs. VM: qual è il piu sicuro?

Facebooktwittergoogle_plusredditlinkedin

I container sono davvero meno sicuri di una VM?

James Bottomley, ingegnere di IBM Research e sviluppatore del kernel Linux, ha fatto notare come non esistesse di fatto un metodo standard per misurare il livello di sicurezza di ciascuna tecnologia, riducendo tutto il dibattito a una questione di “sensazioni” da parte dell’utente:

Hypervisors ‘feel’ more secure than containers because of the interface breadth.

Gli hypervisor “sembrano” più sicuri rispetto ai container per l’ampiezza (in termini di user experience, nda) dell’interfaccia.

Basarsi sulle “sensazioni” per definire un qualcosa come sicuro o meno non è sicuramente il modo giusto per effettuare un paragone scientifico ed imparziale.

Prima di tutto, Bottomley è partito col definire un Vertical Code Attack Profile (VAP), ovvero tutto il codice che viene attraversato per erogare un servizio. Come tutti i software, il codice contiene dei bug più o meno importanti. Ovviamente, più codice si attraversa, maggiori sono i rischi di trovare falle nella sicurezza.

Nella seconda fase di questa ricerca, è stato creato un Horizotal Attack Profile (HAP) per misurare di fatto quante righe di codice vengono effettivamente utilizzate per una data applicazione.

A questo punto sono stati lanciati dei benchmark standard:

  • redis-benchmark, che simula l’esecuzione di comandi effettuata da N client nello stesso momento, inviando N query;
  • python-tornado, un web framework in grado di scalare fino a decine di migliaia di connessioni che richiedono connessioni long-lived;
  • node-express, web framework per Node.js su cui sono stati installati due web server con alcuni client esterni.

Questi test sono stati effettuati con Docker, gVisor, gVisor-kvm, Kata Containers, l’hypervisor built-in di Linux e Nabla (l’ultimo rilasciato in casa IBM).

I risultati?

  • Nabla si è comportato meglio rispetto a Kata, risultando cosi più sicuro di un hypervisor;
  • Docker con un profilo seccomp (che blocca chiamate di sistema non attese) configurato a modo, fornisce lo stesso livello di sicurezza di un hypervisor;
  • gVisor in alcuni casi si è comportato al pari di Docker ma in uno dei test è stato decisamente il peggiore. gVisor infatti cerca di migliorare le performance del container riscrivendo le syscall in Go, incrementando notevolmente il codice che necessita di essere eseguito.

Questo ovviamente è solo un punto di partenza, ma l’avreste mai detto che i container sono sicuri come una virtual machine?

Truffe a PostePay tramite Facebook. Ma Poste Italiane ci mette del suo…

Facebooktwittergoogle_plusredditlinkedin

I truffatori si inseriscono contattando i clienti PostePay che chiedono assistenza e cercano di estorcergli informazioni per rubargli denaro. I social media, per le aziende, non sono solo uno strumento di promozione e pubblicità. Sempre più spesso vengono utilizzati come piattaforma per comunicare con i loro clienti e offrire, per esempio, servizi di assistenza attraverso […]

L’articolo Truffe a PostePay tramite Facebook. Ma Poste Italiane ci mette del suo… proviene da Securityinfo.it.

‘Run simple’: implementazione semplificata di SAP HANA con virtualizzazione vSphere 6.5

Facebooktwittergoogle_plusredditlinkedin

La digitalizzazione ha creato numerose sfide, tra cui una maggiore complessità per Endress+Hauser, fornitore internazionale di strumenti di misurazione, servizi e soluzioni per l’ingegneria e l’automazione dei processi industriali. L’azienda a conduzione familiare possiede oltre 100 società in 44 Nazioni, incluse start-up nei settori dell’IoT e dell’Information Technology.

Per affrontare tali sfide, Endress+Hauser InfoServe, l’IT service provider indipendente della società, è impegnato a perseguire e implementare una strategia “run-simple” che guidi la standardizzazione, riducendo la complessità e aumentando l’automazione.

La via elegante della virtualizzazione

Con un progetto importante, Endress+Hauser InfoServe ha implementato SAP HANA in tutte le aree della società per ridurre la complessità dell’IT e guidare la digitalizzazione. L’obiettivo principale consisteva nel convertire tutti i sistemi SAP nella nuova piattaforma dati in-memory SAP HANA.

Tuttavia, SAP HANA non era compatibile con i mainframe IBM esistenti. Per evitare una conversione superata e molto costosa ai server bare metal, Endress+Hauser InfoServe ha optato per una strategia di virtualizzazione del server e, avendo ottenuto ottimi risultati con la virtualizzazione di VMware vSphere in altri settori dell’organizzazione, l’azienda non ha avuto dubbi sul provider più adatto.

Nell’estate 2016, Endress+Hauser InfoServe ha implementato un Software-Defined-Data Center (SDDC) basato sulla tecnologia VMware. L’obiettivo, questa volta, era di creare un “Data Center-in-a-Box” con una rete e una piattaforma standardizzate e in grado di gestire tutte le applicazioni SAP in modo affidabile, senza le complessità dell’ambiente precedente. Nel processo di progettazione e specifica del progetto, InfoServe ha stabilito che l’approccio “run-simple” di SAP poteva essere effettivamente ottenuto solo utilizzando la virtualizzazione di VMware vSphere. Il progetto è stato supportato da DELL, in qualità di appaltatore principale, e da Fritz & Macziol, consulente partner, in grado di offrire esperienza specializzata nell’implementazione di SAP HANA su vSphere.

Risparmio e vantaggi competitivi

Ralf Straub, Director of IT Operations di InfoServe spiega: “VMware vSphere 6.5 è stata l’unica scelta logica per gestire il nostro ambiente SAP HANA. Rappresentava l’unico modo per ottenere l’obiettivo di riduzione della complessità dell’ambiente IT nel suo complesso e aprire le porte alla standardizzazione e all’automazione del data center.”

Ne sono conseguiti una serie di benefici, inclusa la facilità di gestione. Inizialmente 900 macchine virtuali (VM) funzionavano su vSphere, ora questo numero è cresciuto a 1.600 VM, gestite centralmente – un livello di flessibilità che non sarebbe stato raggiungibile con il solo hardware convenzionale.

Dal punto di vista operativo, InfoServe risparmia sui costi delle competenze specialistiche che sarebbero altrimenti richiesti per gestire piattaforme diverse. Inoltre, Straub e i suoi colleghi riportano un aumento del risparmio di tempo nelle operazioni quotidiane, poiché dev’essere gestita solo una piattaforma comune, anche se nel complesso vengono amministrate più VM.

Questo ha conferito a InfoServe la flessibilità di unire due team in precedenza distinti, poiché entrambi i team non devono più occuparsi degli stessi servizi IT, come i backup e la site recovery. A lungo termine, questo porterà Endress+Hauser a un maggior vantaggio competitivo strategico e i team IT potranno dedicarsi a soluzioni orientate al business.

Ciò che è interessante dal punto di vista del business è che sarà possibile ottenere un ROI entro tre anni, nonostante i costi aggiuntivi che verranno sostenuti durante una fase di migrazione di due anni, durante la quale il nuovo ambiente SAP virtualizzato e il vecchio ambiente mainframe IBM funzioneranno in parallelo.

Uno sguardo al futuro

La migrazione a SAP HANA non è stata ancora completata e i vecchi sistemi sono ancora in esecuzione contemporaneamente. Tuttavia, il risultato principale è già chiaro: la migrazione fluida di tutti e sette i sistemi ERP e SAP BW di base a vSphere 6.5 e l’operazione eseguita con successo all’interno dell’ambiente virtualizzato.

InfoServe prevede di espandere vSphere 6.5 in data center di medie dimensioni nella sua architettura tier-3 mentre l’organizzazione lavora per raggiungere l’obiettivo di implementare un’infrastruttura iperconvergente. Inoltre, Straub sta prendendo in considerazione l’aggiunta di vRealize Suite Business for Cloud. Sono in progetto anche piani per sostituire i sistemi Citrix esistenti con VMware Horizon nel prossimo futuro, al fine di avvicinarsi ancora di più agli obiettivi di uniformità e di amministrazione semplificata.

PowerShell Direct: un nuovo modo di gestire le VM

Facebooktwittergoogle_plusredditlinkedin

Con l’arrivo di Windows Server 2016, e conseguentemente di Windows 10, Microsoft ha deciso di introdurre una funzionalità molto interessante per tutti coloro che intendono effettuare operazioni remote in ambienti virtuali.

PowerShell Direct consente di eseguire PowerShell in modo arbitrario all’interno di una macchina virtuale direttamente dall’host Hyper-V, indipendentemente dalle impostazioni di configurazione di rete o di gestione remota.

Per accedere a questa funzionalità è necessario che le VM siano basate su Windows 10 o Windows Server 2016 (e superiori).

Ma perché si dovrebbe usare questa modalità invece del classico PSSession, già disponibile dai tempi di Windows Server 2008 R2? Il motivo va ricercato nel fatto che è possibile collegarsi anche a macchine prive di network o che risiedono in reti diverse da quelle dell’host; inoltre PowerShell Direct consente di avere un canale diretto tra host e VM.

Requisiti di Configurazione

Per poter utilizzare PS Direct, è necessario assicurarsi che le seguenti condizioni siano rispettate:

  • La macchina virtuale deve essere eseguita localmente nell’host
  • La macchina virtuale deve essere attivata e in esecuzione con almeno un profilo utente configurato
  • È necessario accedere al computer host come amministratore di Hyper-V
  • È necessario specificare credenziali utente valide per la macchina virtuale

Creare una Sessione Remota

Per accedere alla macchina virtuale è sufficiente eseguire il comando: Enter-PSSession -VMName nomevm – come mostrato nella figura 1.

Figura 1 – Nuova Sessione PS

Una volta inserite, potrete iniziare a lavorare all’interno della macchina virtuale sfruttando i cmdlet messi a disposizione dalla stessa macchina, come mostra la figura 2. In questo caso è possibile eseguire comandi relativi a Docker, perché si trovano all’interno della macchina a cui mi sto collegato (comandi non disponibili nell’host Hyper-V).

Figura 2 – Esecuzione Comandi

Le connessioni basate su Enter-PSSession sono temporanee e questo significa che ogni volta che si esce, è necessario inserire nuovamente le credenziali di accesso.

Utilizzo Comandi Complessi

La semplice connessione può essere utile per quegli scenari in cui bisogna svolgere attività minori, mentre per attività più strutturate possiamo utilizzare Invoke-Command. Questo comando è perfetto per le situazioni in cui è necessario eseguire un comando, o uno script, su una macchina virtuale in modalità non controllata.

La sintassi può essere di due modi:

Comando: Invoke-Command -VMName nomevm -ScriptBlock { Get-Service }

Script: Invoke-Command -VMName nomevm -FilePath “C:\hyperv-folder\script.ps1”

Figura 3 – Esecuzione Comando

Copia File

Uno dei punti chiave di questa soluzione è sicuramente la possibilità di effettuare copia di file dall’host verso la macchina virtuale. Per usare il cmdlet Copy-Item è necessario però lavorare con una sessione persistente. Queste, una volta create, rimangono in background finché non si decide di eliminarle. Perciò è possibile fare riferimento più volte alla stessa sessione con senza passare credenziali.

Ecco un esempio per inviare dati verso una macchina virtuale:

$VM = New-PSSession -VMName nomevm -Credential (Get-Credential)

Copy-Item -ToSession $VM -Path C:\hyperv-folder\app.exe -Destination C:\guest-vm\

Figura 4 – Copia File

Le performance di questa operazione sono interessanti, perché grazie al VMBus si va a saltare lo strato di driver relativi alla scheda di rete e quindi la copia avviene in modo più rapido. Ovviamente tutto questo dipende anche dalla tipologia di file che vogliamo copiare, così come dalle prestazioni della macchina virtuale (se il vhdx si trova su un disco SSD sarà più veloce che su un disco SATA).

Veeam B&R e PowerShell Direct

Per offrire un livello di protezione delle macchine virtuali in modo avanzato, Veeam Backup & Replication utilizza un componente chiamato Guest Interaction Proxy, che ha il compito di eseguire i seguenti task:

  • Application-aware processing
  • Guest file system indexing
  • Transaction logs processing

Il processo viene eseguito e chiamato in ogni singola VM e consente la comunicazione anche se gli ambienti sono separati tra di loro.

Figura 5 – Guest Interaction Proxy

Importante ricordare che questo ruolo è disponibile solo per le licenze Enterprise ed Enterprise Plus. Per maggiori informazioni su come opera il GIP, potete consultare il seguente link: https://helpcenter.veeam.com/docs/backup/hyperv/guest_interaction_proxy.html?ver=95

Ovviamente la rete è uno dei punti critici di questo processo ma in caso di interruzioni o problemi, PowerShell Direct può intervenire per evitare errori in fase di backup. I requisiti lato host sono un server Hyper-V 2016, mentre le guest machine sono Windows 10 o Windows Server 2016 e superiori.

Figura 6 – PS Direct in Backup & Replication

Conclusione

PowerShell Direct consente di automatizzare facilmente le attività all’interno delle macchine virtuali senza la necessità di accedere al sistema operativo guest tramite GUI. Utile l’integrazione nativa in Backup & Replication che evita errori in caso di problemi.

Ricordate che una sessione interattiva consente di continuare l’attività di amministrazione in base all’output restituito dalla VM, ma con il comando Invoke-Command potete lanciare task avanzati.

Vivere la community diventa insostenibile e Guido van Rossum, creatore e di Python, si fa da parte

Facebooktwittergoogle_plusredditlinkedin

Python è attualmente il linguaggio di programmazione più utilizzato al mondo, poche sorprese in merito, ma più un progetto è popolare, si sa, più il numero di persone coinvolte nello stesso aumenta. In determinate circostanze, vedi quando vi è da decidere l’approvazione di una nuova funzionalità (in Python altrimenti detta PEP, Python Enhancement Proposals), l’alto numero di attori in causa può rappresentare un limite, ed è esattamente ciò che è successo con la PEP 572.

Ebbene in seguito all’approvazione della suddetta PEP, Guido van Rossum, nome centrale nel progetto Python, creatore del linguaggio e da sempre Benevolent Dictator For Life (BDFL, paritetico a ciò che Linus Torvalds è per il kernel Linux) del progetto, ha annunciato il suo ritiro.

Le motivazioni sono spiegate all’interno del suo messaggio, ma, riassumendo,  la situazione è chiara e semplice:

I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions

Non voglio più dover litigare così duramente per una PEP e vedere che così tante persone disprezzano le mie decisioni

Per essere ancora più concisi, il buon Guido ne ha piene le scatole. Gli strascichi della discussione sulla PEP 572 hanno quindi avuto un peso notevole nella scelta, principalmente per come si è svolta l’approvazione della nuova specifica, con insulti, offese ed attacchi personali che poco hanno da spartire con la professionalità che ci si aspetta all’interno di un progetto così importante come Python.

Complici anche problemi di salute, solamente accennati, per van Rossum la sostanza è comunque chiara ed il messaggio altrettanto: se pensate di poter far meglio di me, fatevi avanti.

Certo questa vicenda è solo l’ultima di molte avvenute nelle varie community dei progetti open-source, ma non per questo meno dolorosa. Il rispetto per gli altri è da sempre qualcosa di cui ci si dimentica in fretta nella sicurezza delle proprie postazioni lavorative, coperti da un monitor, armati di una tastiera.

Staremo a vedere come le cose si evolveranno nei prossimi mesi, nella speranza di un ripensamento da parte di van Rossum, al quale il merito di aver creato un linguaggio polare e funzionale non potrà essere tolto da nessuno.

Blog italiani (e in italiano) nel mondo IT/ICT