Questo articolo è disponibile anche in:
Questo documento contiene i principi guida su come Easy LMS mantiene la sicurezza e la privacy dei suoi clienti.

La sicurezza è a strati e abbiamo cinque principi guida che ci permettono di avere più e migliori livelli di sicurezza all'interno della nostra organizzazione e del nostro prodotto. Ognuno di questi cinque principi sarà discusso separatamente in questo documento. I nostri cinque principali principi di sicurezza sono:

Prioritizzare il principio di sicurezza
Discutere il principio di sicurezza
Nessun principio di software non mantenuto
Principio di almeno 4 + 2 occhi
Principio dell'accesso privilegiato

Dare priorità al principio di sicurezza

Qualunque cosa facciamo, prima di tutto sistemiamo la sicurezza._

Nessun software è privo di bug, e anche se facciamo del nostro meglio per avere la massima qualità possibile del nostro prodotto, non facciamo eccezione. Ciò significa che a volte troviamo (potenziali) problemi di sicurezza all'interno del nostro sistema. Ogni volta che il problema è presente all'interno della nostra installazione di produzione, al bug registrato viene data la massima priorità per garantire che non ci siano problemi di sicurezza non risolti. Se vengono rilevati più problemi di sicurezza, allora viene data priorità al problema di sicurezza con la massima gravità.

Nello scenario in cui si trova un problema di sicurezza prima di atterrare nel nostro ambiente di produzione, esiste un processo per assicurare che siano evitati ulteriori utilizzi del codice vulnerabile fino a quando la sicurezza non sarà risolta. Poiché potrebbe impedirci di implementare nuove funzionalità, anche questi problemi hanno la priorità per le correzioni.

Spesso diciamo che è meglio essere sicuri che dispiaciuti. Pensiamo che per garantire un prodotto sicuro non si tratti di risolvere i problemi che si incontrano, ma di fare in modo che questi problemi non esistano mai. Pertanto, pensiamo che la sicurezza dovrebbe essere una priorità fin dalle prime fasi di sviluppo per progettare la sicurezza direttamente nel nostro prodotto, piuttosto che applicare patch in seguito.

Discutere il principio di privacy/sicurezza

Se non pensiamo e discutiamo su come migliorare, non lo faremo mai._

Sebbene la sicurezza sia discussa e implementata nel cuore del nostro software, pensiamo che ci sia sempre un margine di miglioramento. Avere una conversazione ci aiuta a mantenere la concentrazione e l'attenzione su come ci avviciniamo alla sicurezza. Inoltre, una discussione è un modo per trasformare le buone idee in grandi idee, e i buoni progetti in grandi progetti. Ancora più importante, poiché c'è sempre un margine di miglioramento, una discussione può permetterci di scoprire ciò di cui abbiamo bisogno per migliorare piuttosto che ciò che possiamo migliorare. La sicurezza è sempre forte quanto la parte più debole e quando si tratta di migliorare la sicurezza, solo i miglioramenti alla parte più debole migliorano la sicurezza. Per questo motivo, crediamo che la conversione in corso debba sempre essere mantenuta viva su ciò che è la nostra parte più debole e su come possiamo migliorarla.

Nessun principio di software non manutenuto/non protetto

Il nostro software non è sicuro se la piattaforma su cui gira non lo è._

Non abbiamo inventato la ruota, e certamente non abbiamo scritto il nostro sistema operativo. Quindi, sì, dipendiamo dal codice di terzi. Ciò significa che dobbiamo anche assicurarci che questo codice sia sicuro. Per il sistema operativo (di tipo linux), l'ambiente del linguaggio di programmazione (php / nodo), il nostro server http (apache), e i sistemi di database (MariaDB), ci assicuriamo di usare sempre una versione che almeno riceva ancora patch di sicurezza. Ciò significa che il nostro software viene regolarmente aggiornato per funzionare su una versione aggiornata. Inoltre, ci assicuriamo di rimanere sicuri per tutto il tempo, in quanto per questi componenti, richiediamo che le patch di sicurezza siano installate automaticamente.

Per le librerie che utilizziamo nel nostro codice, utilizziamo strumenti automatizzati, laddove possibile, per garantire che queste abbiano una versione aggiornata, ma soprattutto una versione sicura. In pratica usiamo 'npm audit' per assicurarci che i nostri pacchetti node.js siano aggiornati. E usiamo 'roave/security-advisors' per assicurarci che le nostre librerie php siano sicure.

Principio di almeno 4 + 2 occhi

Ogni cambiamento, per quanto banale possa sembrare, deve essere verificato per la qualità.

Per mantenere la qualità a cui puntiamo, crediamo che, indipendentemente dalle circostanze, il nostro software non debba mai essere affrettato. Ciò significa che è necessario un ciclo di revisione completo per ogni modifica che apportiamo al nostro prodotto. Ciò significa che il codice deve essere visto e approvato da almeno due sviluppatori e poi testato da uno dei nostri team di test. Questo principio è ancorato nel nostro flusso di lavoro. Prima che il codice possa essere distribuito in un ambiente di staging o di produzione, deve passare una richiesta di pull. Le richieste di pull devono essere esaminate da almeno un altro sviluppatore. L'effettiva fusione di ritorno è fatta da qualcuno del nostro team di test. Quindi, uno sviluppatore non è in grado, in linea di principio, di ricongiungere una richiesta di pull. La sicurezza è (ovviamente) parte del ciclo di revisione. L'altro sviluppatore valuterà il codice per vedere se ci sono problemi di sicurezza. Il tester verifica anche gli errori di sicurezza comuni per evitare inutili perdite nel nostro sistema.

Una menzione speciale va fatta per quanto riguarda l'amministrazione di infrastrutture/sistemi. Poiché il ciclo di sviluppo del codice permette di valutare la sicurezza e la qualità prima che arrivi in produzione, ci sforziamo di gestire l'intera infrastruttura come codice. Questo ci permette di automatizzare la maggior parte delle funzionalità, il che significa che commettiamo meno errori umani. Inoltre, un unico amministratore di sistema può apportare modifiche senza notifica che potrebbero influire sulla sicurezza del nostro sistema.

Principio dell'accesso privilegiato

Ogni persona deve avere accesso solo a ciò di cui ha bisogno e ogni programma deve poter accedere solo a ciò di cui ha bisogno.

Il modo più affidabile per prevenire qualsiasi forma di fuga di dati è assicurarsi che non vi sia alcuna perdita di dati. La cosa migliore è assicurarsi che nessuno possa accedere alle informazioni non necessarie. Ad esempio, uno sviluppatore non ha bisogno di accedere ai nostri dati di produzione per sviluppare nuove funzionalità. Allo stesso modo, un traduttore deve solo vedere cosa può essere tradotto nel nostro sistema e non ha bisogno di accedere alla nostra base di codici o alle informazioni dei clienti. Il nostro obiettivo è quello di fare in modo che chiunque nella nostra organizzazione possa vedere ed eseguire solo i compiti necessari per il suo ruolo.

Il principio dell'accesso meno privilegiato si applica agli esseri umani, ma anche ai sistemi e ai servizi. Se una parte del nostro sistema è compromessa, puntiamo a minimizzare l'impatto che può avere. Pertanto, puntiamo a separare i servizi che possono accedere solo alle informazioni di cui hanno bisogno. Ad esempio, non abbiamo bisogno di elaborare le informazioni di pagamento quando visualizziamo i contenuti didattici. Quindi, i sistemi responsabili dei contenuti didattici non dovrebbero avere accesso al nostro sistema di pagamento. Inoltre, questo è possibile anche per altri servizi. Il nostro obiettivo è quello di scollegare i servizi da Internet pubblico, se possibile. Ciò avviene preferibilmente inserendo i servizi in una rete privata, dalla quale si può accedere solo da tale rete. Se il servizio non è destinato all'uso pubblico, ma è destinato ad essere accessibile via internet, lavoriamo con una lista bianca di indirizzi IP, per ridurre al minimo l'esposizione.

Note finali

Riteniamo che sia necessario uno sforzo continuo per mantenere un alto livello di sicurezza. Questo sforzo significa che non deve rimanere in linea con i principi, ma che questi principi devono essere incorporati in tutti i nostri processi del flusso di lavoro. In questo modo, possiamo garantire che la sicurezza abbia la priorità all'interno della nostra organizzazione.
È stato utile questo articolo?
Annulla
Grazie!