DevOps e Security danno vita al DevSecOps

Bug. Falle di sicurezza. Rallentamenti. Si tratta d’imprevisti costosi, difficili da riparare, e che possono causare una reputazione negativa da cui è complicato liberarsi.

I team DevOps e di Security come possono lavorare insieme per gestire questi rischi?

Le risorse operanti in ambito DevOps e i team di Security hanno bisogno di soddisfare i propri obiettivi: il DevOps mira a sviluppare e rilasciare il software rapidamente, la Security intende mitigare e gestire il rischio controllando accuratamente qualsiasi elemento fragile o violabile all’interno del software.

La combinazione dei due si chiama “DevSecOps”.

Il “DevSecOps” è un approccio volto a perseguire un perfetto allineamento tra il DevOps e il mondo della sicurezza informatica, con l’obiettivo di:

  • ottimizzare il Risk Management;
  • accelerare l’individuazione di falle di sicurezza;
  • automatizzare e orchestrare le change necessarie nelle catene dei servizi di sicurezza.

Partendo dal presupposto secondo cui la sicurezza è e sempre sarà una parte integrante del ciclo di vita del software, il SecDevOps integra misure di sicurezza nella filosofia dello sviluppo e del deployment automatizzato.

La transizione verso il “DevSecOps” aprirà le porte ad un modo più dinamico e sicuro di gestire le infrastrutture e il deployment automatizzato, facendo della sicurezza una responsabilità condivisa da tutta l’organizzazione e una realtà ben salda a tutte le tappe del processo di sviluppo.

Come approcciarsi al DevSecOps?

Segui il webinar “New Frontier in DevSecOps”.

Scarica il whitepaper “Security and Compliance: Six Ways to Ensure Your Database Is Not a Vulnerability”.

Scopri la nuova feature di DBmaestro in ambito DevSecOps: “Policy Control Manager”.

DevOps e Security danno vita al DevSecOps

DEVSECOPS: UN SOFTWARE MIGLIORE, PIÙ VELOCE

Secondo una ricerca condotta da Sonatype, su 16 componenti open source e di terze parti almeno uno possiede una vulnerabilità nota. Questo dato potrebbe non sembrare eccessivo finchè non ci si rende conto che una società media scarica oltre 200.000 componenti all’anno. Questi componenti vengono scaricati dai team di sviluppo, i quali sono spesso inconsapevoli di eventuali vulnerabilità.

 Come verificare la qualità dei componenti utilizzati?

Ovviamente, è fuori discussione rivedere manualmente ogni componente che si desidera scaricare e utilizzare: infatti, questo genere di review richiederebbe 2/4 ore per ogni componente e nessuna azienda ha tempo o risorse per farlo.

Tuttavia, esiste un modo più semplice (e gratuito) per capire se il repository contiene componenti con rischi noti di vulnerabilità di sicurezza o di licenza. Si tratta del Repository Health Check, una soluzione che permette di analizzare il proprio repository e individuare componenti con vulnerabilità o a rischio.

screen-shot-2015-08-05-at-2.06.33-pm

Proteggere la porta d’ingresso, la casa e la porta posteriore

  • Proteggere la porta d’ingresso.

Attivando la funzionalità del Repository Health Check, il report elaborato permette di rivelare la presenza di componenti indesiderati. Inoltre, grazie a Nexus Firewall, è possibile implementare un “controllo cyber” verso la “porta d’ingresso” del repository, con l’obiettivo di prevenire futuri download di componenti con vulnerabilità note, a rischio o non aggiornati.

  • Proteggere la casa.

Il software dura quanto il latte, non quanto il vino. Ciò che è perfettamente accettabile un giorno, può diventare estremamente rischioso il giorno dopo. Pertanto, è possibile continuare ad utilizzare i report del Repository Health Check per verificare automaticamente nel corso del tempo ogni possibile cambiamento del proprio repository.

  • Proteggere la porta posteriore.

Per coloro che utilizzano repository di staging nelle proprie configurazioni, Nexus Firewall può aiutare ad analizzare le possibili release. La suite di staging (disponibile nella versione commerciale di Nexus Repository) consente ad un’azienda di creare un repository temporaneo di staging e gestire la promozione dei componenti dallo staging ad un repository di rilascio. La possibilità di creare un repository isolato di potenziali release, che possono essere scartate o promosse, permette di supportare le decisioni che vanno a certificare una determinata release. Ciò consente di controllare meglio l’esatta serie di binari che alla fine sarà rilasciata.

Inoltre, con la soluzione Nexus Firewall, ogni componente nel repository di staging può essere valutato in base alle vulnerabilità note di sicurezza, alle versioni non aggiornate/indesiderate, o alle licenze rischiose. Utilizzato in questo modo, Nexus Firewall non solo protegge la “porta d’ingresso” del repository nel momento in cui si effettua il download dei componenti, ma custodisce anche la “porta posteriore” prima degli effettivi rilasci.

screen-shot-2016-01-25-at-11.38.41-am

Risolvere grandi problemi

Come affermato da Deming, pioniere del DevOps, “per risolvere un grosso problema, è necessario innanzitutto rendersi conto di avere uno”.

Tutti noi abbiamo una supply chain del software che alimenta i componenti all’interno dei nostri repository manager ed è per questo motivo che una migliore visibilità sui componenti utilizzati potrebbe permetterci di individuare e risolvere le problematiche esistenti, a favore di un software migliore, ancora più veloce.

Questo topic copre solo un aspetto della DevSecOps. Infatti, c’è molto di più da imparare su questo argomento.

Partecipa al DevSecOps survey: rispondi ad alcune brevi domande e potrai vincere il nuovo MacBook Air.

DEVSECOPS: UN SOFTWARE MIGLIORE, PIÙ VELOCE

Supply Chain del software: il ruolo della “governance transformation”

Il mondo software degli ultimi anni è stato condizionato da molteplici e inevitabili cambiamenti, di cui la proliferazione dell’Open Source e l’implementazione del DevOps sono una dimostrazione.

Questi cambiamenti, come degli “spostamenti tettonici”, presentano un rovescio della medaglia: la mancata gestione dei componenti Open Source può portare in “superficie” aree a rischio, difficili da controllare e mantenere.

Le aziende leader nei settori bancario e assicurativo, ad esempio, hanno cercato di far fronte a queste problematiche molto presto, definendo programmi di governance dell’Open Source centralizzati e altamente strutturati. Generalmente, questi programmi prevedono dei processi attraverso i quali gli sviluppatori richiedono il permesso di utilizzare determinati componenti; le richieste sono poi valutate da esperti di sicurezza e architetture, che hanno stilato la lista di componenti “accettabili per l’uso”, spesso creando un “repository d’oro” accessibile agli sviluppatori.

Fino a poco tempo fa, questo genere di approccio rappresentava una vera e propria best practice. Oggi, invece, questi programmi sono incongruenti con le moderne pratiche di sviluppo per quattro semplici ragioni:

Tempo: i tempi delle richieste di approvazione variano generalmente dalle 6 alle 12 settimane. A volte sono più lunghi per i progetti di più grandi dimensioni, o più brevi per incrementi di versione di progetti già approvati.

Esigenze contrastanti: i lunghi cicli di approvazione non sono compatibili con le richieste di innovazione da parte del business e gli sviluppatori utilizzano spesso metodi creativi per aggirare mandati incompatibili. Un esempio è quello di un team di sviluppo che utilizza i componenti ritenuti necessari, rinominandoli però in modo tale da farli apparire come se fossero presenti all’interno della lista.

Deterioramento: il software dura quanto il latte, non quanto il vino. Ciò che è perfettamente accettabile un giorno, può diventare estremamente rischioso il giorno dopo.

Volume: più di 7.000 nuovi progetti e 70.000 componenti Open Source (versioni) vengono rilasciati ogni settimana! Le interdipendenze tra questi componenti sono quasi incalcolabili e i volumi di utilizzo sono notevoli (nel 2016 sono state conteggiate 52 miliardi richieste di download di componenti).

Quindi? Sta diventando sempre più evidente che, così come abbracciamo la DevOps transformation, dovremmo anche abbracciare una “governance transformation”.

Quali sono i concetti che consentono il successo delle iniziative DevOps?

Scalare: la funzione di governance deve operare in tempo reale all’interno del flusso DevOps. Ovviamente, questo è possibile solo attraverso l’automazione.

L’automazione richiede policy chiare, metadati estremamente precisi e la capacità di identificare esattamente un determinato componente.

Presto: l’identificazione del problema, su scala, è relativamente priva di valore di per sé. Affinché un programma di governance DevOps possa realizzare il suo pieno potenziale, i problemi devono essere identificati il più presto possibile, con dettagli di risoluzione nitidi, chiari e facilmente utilizzabili dagli sviluppatori con gli strumenti già utilizzati. La riduzione o l’eliminazione del rework è un valore trainante fondamentale.

Ovunque: la governance automatizzata dovrebbe riguardare l’intera catena DevOps, e non solo alcuni processi.

Ironia della sorte, le aziende che per prime hanno compreso le sfide dello sviluppo software moderno seguono ora i programmi di governance più radicati e tradizionali (manuali). Senza dubbio, per quanto impegnativo possa essere rimodellare questi programmi, i processi umani sono incompatibili con il DevOps e con gli obiettivi di Continuous Delivery.

In futuro, concetti e competenze waterfall giocheranno ancora un ruolo fondamentale, ma all’interno dei pattern dei processi DevOps.

Vuoi sapere come gestire i componenti Open Source, implementare una governance automatizzata e migliorare la qualità delle applicazioni? Scarica l’infografica “2016 Stato della Supply Chain del Software”.

Supply Chain del software: il ruolo della “governance transformation”

7 segnali per capire se state gestendo male il DevOps

ID-10055997

Segnale n. 1: credete di poter acquistare il DevOps

Il DevOps non può essere implementato nell’arco di una notte o acquistato con un assegno.

L’adozione del DevOps non può essere né affrettata né comprata: si tratta di un approccio rivoluzionario che richiede tempo, dedizione e soprattutto un team desideroso di cambiare e crescere. Se si vuole intraprendere con successo la strada verso il DevOps occorre lavorare sodo e credere in una vera e propria trasformazione culturale dell’azienda, senza alcuna fretta.

In breve… se avete un “budget DevOps”, state gestendo il DevOps nel modo sbagliato.

Segnale n. 2: equiparate software e strumenti al DevOps

Il DevOps presenta molte sfaccettature e va ben oltre il Configuration Management. Di conseguenza, è un errore adottare un unico approccio verso il DevOps, in quanto non esiste un’unica soluzione, un unico tool o tecnica per mettere in pratica questa metodologia.

In breve…se avete acquistato, ad esempio, Chef o Puppet come soluzione per soddisfare le vostre necessità DevOps, state gestendo il DevOps nel modo sbagliato.

Segnale n. 3: utilizzate checklist o runbook per gestire il Deploy

Il DevOps, grazie alla Smart Automation, consente di liberare se stessi e la propria azienda da procedure legacy e processi rigidi.

Quando si tratta di DevOps, ogni elemento viene automatizzato: deploy, test, policy di check-in del codice, server build, ecc.

In breve… se spendete ore studiando attentamente le checklist per assicurarsi che il codice sia pronto per il deploy, state gestendo il DevOps nel modo sbagliato.

Segnale n. 4: rilasciate il codice in produzione solo una volta ogni tanto

DevOps è sinonimo di concetti quali “Continuous Integration” e “Continuous Implementation”. Si noti che la parola chiave in entrambi i termini è “Continuous”. Dunque, per le vere rockstar DevOps è fondamentale inviare il codice in produzione il più spesso possibile attraverso la Continuous Implementation.

Ragion per cui se il codice, una volta testato e approvato, va automaticamente sui server di produzione siete all’apice del successo DevOps.

In breve… se la vostra azienda rilascia raramente change del codice state gestendo il DevOps nel modo sbagliato, indipendentemente da quanto siano piccole le change o da quanto voi siate veloci a realizzarle.

Segnale n. 5: considerate inaccettabili le failure

Non abbiate paura di commettere errori e failure o di assumervi dei rischi.

Il DevOps rafforza il vostro talento, con l’obiettivo di creare un ecosistema software forte e collaborativo, spingendo l’azienda verso il successo.

In breve… se siete timorosi nel rilasciare il codice in produzione, perché avete fatto o potreste fare un errore, state gestendo il DevOps nel modo sbagliato.

Segnale n. 6: date la colpa agli altri per i problemi di sistema

I veri esperti DevOps ritengono che quando qualcosa va male la colpa non sia dell’individuo che usa il sistema ma del sistema stesso. Affinché gli sviluppatori e le operations vadano d’accordo, occorre smettere di cercare un capro espiatorio.

Supponiamo che uno sviluppatore crei un’applicazione, la verifichi sul proprio computer e ne invii il codice alle operations. Se si verifica un problema quando le operations rilasciano il codice in produzione, non si può incolpare lo sviluppatore per la scrittura di codice scadente, né gli sviluppatori possono incolpare le operations per una gestione non corretta dei server.

In breve…se la vostra azienda sta cambiando le persone a causa della produzione troppo lenta, state gestendo il DevOps nel modo sbagliato, a prescindere da presunti ruoli o responsabilità da attribuire a coloro che sono coinvolti.

Segnale n. 7: sviluppo e operations sono differenti

DevOps unisce le parole “development” e “operations”. Il DevOps è sinonimo di collaborazione e implica che i team si uniscano per aiutare l’azienda, nel suo insieme, a raggiungere il proprio obiettivo.

Quindi, se le operations si rifiutano di comunicare con gli sviluppatori, o viceversa, state gestendo male il DevOps.

In breve… se lo sviluppo e le operazioni comunicano unicamente attraverso messaggi di code commit, state gestendo il DevOps nel modo sbagliato.

Il DevOps non è per tutte le aziende. Tuttavia, anche se la vostra azienda non è pienamente impegnata a costruire una cultura DevOps, ci sono molti aspetti di questa metodologia che possono essere ugualmente applicati con successo ai vostri processi.

Scarica il whitepaper “DevOps Misconceptions and Best Practices” per scoprire quali sono i falsi miti e le best practices del DevOps.

Image courtesy of 89studio at FreeDigitalPhotos.net

 

7 segnali per capire se state gestendo male il DevOps

Raggiungere il successo DevOps seguendo tre principi fondamentali

successo DevOpsRelease e update trimestrali? Dimenticateli! Ora, grazie al DevOps, le aziende sono in grado di rilasciare software continuamente e costantemente, senza dover attendere mesi, o addirittura anni, per nuovi rilasci o aggiornamenti. Con l’aiuto dell’automazione e con un’inversione di tendenza nella cultura aziendale, i processi di sviluppo e di deploy sono cambiati in meglio, favorendo un incremento in termini di valore e di velocità dei rilasci.

Tuttavia, persiste un disallineamento tra ciò che il DevOps dovrebbe essere e ciò che è realmente. In alcuni casi il DevOps viene utilizzato troppo tardi nel processo di sviluppo o a volte viene implementato quando un’azienda incontra dei problemi con un rilascio. In altri casi, le aziende riscontrano delle difficoltà nell’implementare il DevOps con la propria infrastruttura legacy.

In ogni caso, questi problemi possono essere evitati. Il successo del DevOps spesso è riconducibile a tre principi:

  1. Non aspettare ad automatizzare

Introdurre automazione e test fin dall’inizio è, prima di tutto, la chiave del successo. Spesso, giovani imprese e start-up si affrettano a rilasciare i propri prodotti sul mercato, mettendo insieme tutto ciò che funziona, senza ricorrere all’automazione. Anche se questo può essere un modo efficace per portare il software sul mercato, può portare successivamente a molteplici problemi.

Se un prodotto trova il successo ed è pronto per essere scalato, una base povera di code automation può provocare nel processo uno stallo abbastanza lungo da causare la perdita dei propri clienti. Le aziende che non riescono a seguire questo principio spesso perdono migliaia di ore-uomo e ingenti quantità di denaro per riparare e riscrivere il codice errato.

Lo sviluppo test-driven è una pratica che poche aziende seguono fin dall’inizio. Il test non è divertente, eppure non testando fin dall’inizio si rischia di avere problemi ed errori su tutta la linea. Quindi, è meglio dedicare fin dalle prime fasi dello sviluppo più tempo al test al fine di garantire un “lieto fine”.

  1. DevOps Stack

L’utilizzo del DevOps stack consiste nell’automazione dei processi manuali. Lo stack si riferisce ad una stratificazione di diversi strumenti di automazione, volti a semplificare ogni fase del processo di sviluppo.

Le attività che una volta richiedevano giorni, possono ora essere gestite da una semplice AI. Gli sviluppatori, automatizzando il testing per semplificare la Continuous Integration, prendendo i dati in produzione e accelerando il Continuous Deployment, sono liberi da responsabilità quali la scrittura e il controllo del codice sorgente iniziale.

  1. Shock culturale

Una società DevOps che non dispone di un CIO o di un VP engineering è come un treno senza conducente. Infatti, la transizione al DevOps è un processo intensivo che richiede qualcuno che non abbia paura di fare cambiamenti organizzativi in grado di scuotere l’azienda.

Il DevOps è una transizione culturale e un buon CIO sa bene come gli sviluppatori e i team operativi debbano lavorare insieme. Ciò comporta la rimozione delle gerarchie e favorisce il decentramento dell’IT, per far sì che gli sviluppatori creino team altamente efficaci.

Per scoprire quali sono i luoghi comuni sul DevOps e le best practices da seguire, scaricate il whitepaper “DevOps Misconceptions and Best Practices”.

Raggiungere il successo DevOps seguendo tre principi fondamentali

Come iniziare a prendere sul serio la Database Security?

id-100410579Nonostante un security breach del DB possa essere disastroso, costando milioni di euro e causando la perdita di clienti e di posti di lavoro, la Database Security non sta ricevendo l’attenzione che merita.

Da un recente sondaggio, a cui hanno partecipato 209 dipendenti informati sul Database Management della propria azienda, è emerso che:

  • nel 47% delle aziende non vi è nessuno che si occupi di sicurezza del DB;
  • il 39% delle aziende non ha la possibilità di monitorare real-time il proprio database, dando ai potenziali hacker il tempo sufficiente per operare sul DB prima che qualcuno se ne accorga;
  • solo il 19% degli intervistati considera “eccellente” la visibilità che ha del proprio database, mentre più della metà (il 59%) non sa con certezza quali utenti, clienti o applicazioni abbiano effettivamente accesso al DB.

Quali sono le più grandi preoccupazioni delle aziende circa la sicurezza del database? 

Mentre il 50% degli intervistati ritiene che la compromissione delle credenziali costituisca il più grande rischio per l’azienda, il 47% afferma che l’incapacità di anticipare l’individuazione delle violazioni di dati sia invece una delle questioni più gravi. A queste preoccupazioni si aggiungono i tempi d’inattività provocati da eventuali infiltrazioni all’interno del network.

A causa delle numerose minacce alla sicurezza del database, sempre più aziende stanno diventando consapevoli del problema e si stanno attivando per risolverlo. Secondo le previsioni, nel corso del prossimo anno, l’enfasi sulla sicurezza del DB dovrebbe aumentare dal 40% al 54%.

Le aziende possiedono le giuste competenze e tecnologie per gestire la Database Security?

Molti intervistati hanno sostenuto di avere un database estremamente vulnerabile a potenziali security breaches. Il 39% ha affermato di non avere strumenti di rilevamento in grado di individuare una violazione delle credenziali. Solo il 21% ha dichiarato di essere in grado di scoprire immediatamente una compromissione delle credenziali, mentre il 34% ha detto che ci sarebbe voluto un giorno, e il 18% ha detto che avrebbe bisogno di una settimana per risolvere il problema. Il resto degli intervistati avrebbe bisogno di almeno un mese, o più.

Come iniziare a prendere sul serio la sicurezza del database?

Il mondo della sicurezza del DB ha ancora una lunga strada da percorrere prima che le aziende possano sentirsi veramente sicure circa la sicurezza dei propri dati. Organizzazioni e aziende devono ancora fare molto per garantire che le informazioni personali dei propri clienti siano sicure e che i dati riservati dell’azienda siano visibili solo a chi di dovere.

Il primo step da seguire è senza dubbio l’allineamento della sicurezza aziendale con l’implementazione della metodologia DevOps, con l’intento di migliorare la qualità dei processi, automatizzando le operazioni e accelerando l’individuazione delle falle di sicurezza.

A Natale Emerasoft ti offre il SecDevOps ToolKit, una selezione di licenze temporanee per ottimizzare la gestione del rischio a livello Enterprise, integrando Cyber Security e DevOps: richiedilo subito scrivendo a sales@emerasoft.com

Image courtesy of Geerati at FreeDigitalPhotos.net

Come iniziare a prendere sul serio la Database Security?

L’integrazione tra DevOps e Cyber Security: nasce così il SecDevOps

id-100428844Bug. Falle di sicurezza. Rallentamenti. Si tratta d’imprevisti costosi, difficili da riparare, e che possono causare una reputazione negativa da cui è complicato liberarsi.

Il DevOps può gestire questi rischi?

Sì. Il DevOps, se implementato correttamente, può essere uno strumento estremamente utile: è stato rilevato che i reparti IT che utilizzano metodi DevOps rilasciano software (con successo) 200 volte più frequentemente rispetto a quelle imprese che non seguono pratiche DevOps. Tuttavia, è necessario che le aziende non puntino solo ed esclusivamente alla velocizzazione dei rilasci, senza prendere in considerazione il tema legato alla sicurezza.

Il DevOps ha fatto passi da gigante nel corso degli ultimi cinque anni, eppure c’è ancora un ulteriore step da compiere per ottimizzare la gestione del rischio a livello Enterprise: integrare pienamente la Cyber Security al suo interno.

Sia le risorse operanti in ambito DevOps che i team di Security hanno bisogno di soddisfare obiettivi reciproci: infatti, così come il DevOps mira a sviluppare e rilasciare il software rapidamente, la Security intende mitigare e gestire il rischio controllando accuratamente qualsiasi elemento fragile o violabile all’interno del software.

Come velocizzare dunque l’innovazione integrando all’interno della metodologia DevOps appropriate soluzioni di Cyber Security?

Se lo scopo è migliorare l’efficienza delle imprese ottimizzando la gestione della sicurezza e del rischio, la strada è avvicinare la metodologia DevOps alle pratiche di Cyber Security, avviando un processo di convergenza tra questi due approcci.

Nasce così ciò che è stato definito il “SecDevOps”, un approccio volto a perseguire un perfetto allineamento tra il DevOps e il mondo della sicurezza informatica, con l’obiettivo di:

  • ottimizzare il Risk Management;
  • accelerare l’individuazione di falle di sicurezza;
  • automatizzare e orchestrare le change necessarie nelle catene dei servizi di sicurezza.

La transizione verso il “SecDevOps” aprirà le porte ad un modo più dinamico e sicuro di gestire le infrastrutture e il deployment automatizzato, facendo della sicurezza una responsabilità condivisa da tutta l’organizzazione e una realtà ben salda a tutte le tappe del processo di sviluppo.

Richiedi il tuo SecDevOps Toolkit gratuito: scrivi a sales@emerasoft.com

Image courtesy of cookie__cutter at FreeDigitalPhotos.net

L’integrazione tra DevOps e Cyber Security: nasce così il SecDevOps

Il DevOps come soluzione per la Cyber Security

soluzione per la cyber securityLe aziende si trovano oggi strette in una trappola determinata dalla necessità di rilasciare prodotti e servizi di miglior qualità in tempi più rapidi, e al contempo dall’esigenza di tutelare i dati e le informazioni sensibili in un mercato sempre più minacciato da hacker e frodi informatiche.

Ma è possibile puntare a rilasci migliori e più veloci senza sacrificare la sicurezza aziendale?

La protezione della proprietà intellettuale e dei dati sensibili è una grande sfida per le aziende. Un sondaggio* svolto su oltre 800 Senior Business Manager e professionisti IT ha riscontrato nell’89% degli intervistati una forte preoccupazione riguardo a potenziali attacchi sull’Intellectual Property.

Infatti, nonostante le grandi imprese dedichino ingenti risorse per salvaguardare informazioni e operazioni aziendali, le violazioni dei dati rappresentano tuttora una minaccia quotidiana. I più grandi attacchi (ossia quelli che coinvolgono più di 30.000 record) sono, infatti, in grado di compromettere l’integrità dei dati delle imprese di qualsiasi settore.

Nonostante i progressi compiuti in ambito Security, i tool di sicurezza presenti sul mercato tutelano i dati a livello perimetrale, senza securizzare al contempo la fonte di tali dati. La maggior parte delle soluzioni non riesce a mitigare completamente attacchi e frodi informatiche.

Questa sfida è aggravata dal fatto che i product team sono dispersi a livello globale, con appaltatori e partner commerciali esterni che collaborano su più asset (come codice sorgente, file binari, firmware, hardware, immagini, file e video, ecc). Spesso tali dati vengono memorizzati in repository non sicuri caratterizzati da poche restrizioni, rendendo la proprietà intellettuale vulnerabile a errori o accessi indesiderati.

Le cose si complicano ulteriormente per i settori soggetti a severe policy di compliance, come i settori alimentare, farmaceutico, medicale, automotive e aerospace, obbligati a garantire la tracciabilità dei dati, l’applicazione delle policy, e la revisione delle change per un rispetto assoluto della conformità normativa.

Quindi, come proteggere la proprietà intellettuale delle aziende consentendo al contempo di accelerare lo sviluppo, migliorandone la qualità?

Una valida soluzione è la metodologia DevOps che, oltre a favorire una miglior affidabilità e qualità dei rilasci, garantisce una migliore governance dei dati e, quindi, una maggior sicurezza. Se implementato correttamente, il DevOps non solo aiuta le aziende a rilasciare applicazioni più velocemente, ma ottimizza la Cyber Security.

Grazie a:

  • autenticazione flessibile
  • sicurezza elevata delle password
  • controlli granulari degli accessi
  • massima visibilità dei log di audit
  • riproduzione sicura
  • integrazione tra tool

è possibile catturare eventuali falle di sicurezza all’inizio dell’interno del ciclo di sviluppo.

Per saperne di più SCARICA IL WHITEPAPERPerforce Helix: Security & Compliance with Intellectual Property

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Image courtesy of jscreationzs at FreeDigitalPhotos.net

Il DevOps come soluzione per la Cyber Security

5 consigli fondamentali per evitare il downtime del database

id-100228532Il downtime del DB è un problema molto diffuso che può costare caro: in media, i tempi di inattività del DB costano $ 7.900 al minuto, con un incremento del 41% negli ultimi due anni. L’80% del downtime è dovuto a errori umani e la durata media delle interruzioni è di 90 minuti, raggiungendo un totale medio di 97 ore all’anno.

Dati gli ingenti costi, i DBA dovrebbero cercare di limitare al minimo i rischi di downtime. Ma come?

Ecco 5 consigli fondamentali:

  1. Assicurarsi di iniziare la migrazione solo dopo aver esaminato le applicazioni, i processi e gli utenti importanti, per determinare ciò che deve essere spostato e ciò che invece deve rimanere dove si trova. Non iniziare la migrazione finché non si è pensato agli ambienti esistenti e non si è considerato il potenziale impatto sui flussi di lavoro e sulle infrastrutture.
  2. Evitare di incasinare il regolare funzionamento, in modo che utenti e colleghi non si sentano frustrati. Schedulare fuori orario le operazioni di migrazione ad alta intensità di risorse può essere utile se si pensa che queste attività possano causare tempi d’inattività per il database.
  3. Se la migrazione sta richiedendo un po’ di tempo, fare in modo che gli utenti non rimangano bloccati in differenti versioni del database o in prodotti completamente diversi. Cercare di offrire una convivenza tra i vecchi e i nuovi sistemi, in modo che tutti gli utenti possano continuare a svolgere i task necessari senza alcun problema.
  4. Per evitare la perdita di dati, considerare un piano di recovery e backup. Durante la migrazione è importante non perder traccia di ciò che si deve fare per ripristinare improvvisamente i dati a metà del progetto.
  5. Non dimenticare che il project management gioca un ruolo chiave nelle migrazioni e negli aggiornamenti ben eseguiti. Infatti, il lavoro del DBA deve comprendere anche la pianificazione, la comunicazione, la gestione delle risorse e il reporting sui progressi; facendo attenzione a tutti questi task si evitano successive confusioni.

Questi sono i cinque consigli chiave per una migrazione o un update di successo. Per garantire un processo regolare, è fondamentale che ogni punto sopraelencato sia considerato accuratamente prima di procedere.

Scopri quali sono i vantaggi derivanti dall’automazione del database: scarica il whitepaper “Automation A Win-Win for Database Administration and DevOps”.

Vai all’articolo completo.

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Image courtesy of watcharakun at FreeDigitalPhotos.net

5 consigli fondamentali per evitare il downtime del database

Test & Quality Management: il DevOps può essere d’aiuto?

Di fronte all’attuale evoluzione dello svilppo software, come stanno reagendo il Test & Quality Management?

Una volta, occuparsi degli aspetti della qualità significava rispettare rigorosamente una lista ben definita di criteri di rilascio, come ad esempio una percentuale di test positivi superiore al 95% o il controllo del codice superiore al 65%. Tutto, infatti, doveva essere impresso su un supporto da distribuire: una scheda perforata, un floppy, un CD, un DVD. Oggi, invece, i bug si possono correggere velocemente, e si utilizzano il “cloud”, gli “utenti virtuali” o i “containers”.

Il lavoro del Test Engineer è quindi diventato più facile? Non proprio, anzi, forse è diventato più difficile, di sicuro più complicato. La Quality Assurance si trova di fronte a nuove tipologie di problemi, come ad esempio:

Quanto spesso bisogna effettuare nuovi rilasci?

Come si fa a sapere se tutto funzionerà correttamente quando verrà eseguito il deploy? Come effettuare un rollback in caso di fallimento? 

Come si può coordinare il deploy tra diverse piattaforme?

Anche se il deploy è andato bene, come sapere se il servizio continua a funzionare o se i server sono crashati, rallentati, o sono stati hackerati?

È positivo vedere che un numero crescente di aziende sta maturando le proprie pratiche QA per sostenere l’innovazione digitale nel mercato competitivo di oggi. La logica legata al business viene costantemente convalidata, sia in modo automatico che manuale.

Ma ci sono due aspetti importanti nel processo di delivery che rimangono comunemente “non testati”: il provisioning e il deploy su tutti gli ambienti. Purtroppo, infatti, molti problemi di produzione sono legati a failure durante il questi due passaggi, spesso manuali. Secondo un sondaggio 2016 di Forrester, solo il 16% delle aziende è in grado di effettuare correttamente provisioning e depoyment di build automatizzato. Questo dato implica che, anche se il team QA fosse in grado di rilevare tutti i defect nella logica di business, e lo sviluppo fosse in grado di risolvere tutti questi errori, ci sarebbero ugualmente problemi di produzione, proprio a causa della differenza di provisioning o deployment tra gli ambienti. Inoltre, il rischio di errori aumenta in modo significativo quando si usano processi manuali.

Il DevOps può essere d’aiuto?

SCARICA IL WHITEPAPER “The Value of DevOps for Test & Quality” per conoscere i benefici del DevOps nel contesto del Test & Quality Management.

Esiste una soluzione per allineare la logica di business con il provisioning e il deployment?

L’unico modo per favorire questo allineamento è trattare su tutte le piattaforme la logica di provisioning e deployment come il codice, e farla passare attraverso il processo di QA allo stesso modo della logica di business.

test & quality management

Siccome ogni ambiente ha delle impostazioni specifiche, occorrerebbe astrarre un ambiente all’interno di un template, con le variabili dell’environment e con specifici valori come mostrato nell’immagine sovrastante.

La combinazione di una logica di build, stage, provision e deploy con un corrispondente template di environment permette che la stessa logica venga utilizzata e testata in tutti gli ambienti e su tutte le piattaforme. Come risultato, la logica di delivery può diventare parte integrante del ciclo di QA e può essere testata più volte prima dell’uso effettivo in un ambiente di produzione, riducendo notevolmente il rischio di delivery ed errori correlati.

Conosci i benefici della Lean Application Delivery?

SCARICA IL WHITEPAPER “Lean Application Delivery: ROI potential” per scoprire come combinare la gestione del ciclo di vita di applicazioni e servizi, l’automazione di release e deployment e il configuration management all’interno di un unico tool, offrendo agli utenti una visione end-to-end ineguagliabile.

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Test & Quality Management: il DevOps può essere d’aiuto?