Questo articolo è disponibile anche in:
Questo articolo è tradotto usando un traduttore automatico. Potrebbe contenere alcuni errori o traduzioni che suonano strane. Pensiamo lo stesso che possa esserti utile leggere questo articolo nella tua lingua madre. Facci sapere se ti è stato di aiuto, o facci avere il tuo feedback, in fondo all'articolo.

Questo documento contiene i principi guida su come noi di Easy LMS manteniamo la sicurezza e la privacy dei nostri clienti.

La sicurezza arriva a strati e noi abbiamo cinque principi guida che ci permettono di avere più e migliori strati 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 principi di sicurezza principali sono:

Dare priorità al principio di sicurezza
Discutere il principio della sicurezza
Nessun principio di software non mantenuto
Principio di almeno 4 + 2 occhi
Principio del minimo accesso privilegiato

Principio della priorità della sicurezza

Qualunque cosa facciamo, sistemiamo prima la sicurezza.

Nessun pezzo di software è senza bug, e anche se facciamo del nostro meglio per avere la massima qualità possibile del nostro prodotto, non facciamo eccezione a questo. Questo significa che a volte troviamo dei (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 assicurare che non esista un arretrato di problemi di sicurezza non risolti. Se vengono trovati più problemi di sicurezza, allora viene data priorità al problema di sicurezza con la maggiore gravità.

Nello scenario in cui un problema di sicurezza viene trovato prima che atterri nel nostro ambiente di produzione, esiste un processo per assicurarsi che ulteriori distribuzioni del codice vulnerabile siano impedite fino a quando la sicurezza è risolta. Poiché potrebbe impedirci di distribuire nuove funzionalità, a questi problemi viene anche data priorità per le correzioni.

Diciamo spesso che è meglio essere sicuri che dispiaciuti. Pensiamo che assicurare un prodotto sicuro non significhi mettere una toppa ai problemi che si incontrano, ma assicurarsi che questi problemi non siano mai esistiti in primo luogo. Quindi, pensiamo che la sicurezza dovrebbe essere una priorità fin dalle prime fasi di sviluppo per progettare la sicurezza nel nostro prodotto piuttosto che applicare le patch dopo.

Discutere il principio di privacy/sicurezza.

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

Anche se la sicurezza è discussa e implementata nel cuore del nostro software, pensiamo che ci sia sempre spazio per migliorare. Avere una conversazione ci aiuta a mantenerci concentrati e acuti su come affrontiamo la sicurezza. Inoltre, una discussione è un modo per trasformare le buone idee in grandi idee, e i buoni progetti in grandi progetti. Ancora più importante, dal momento che c'è sempre spazio per il miglioramento, una discussione può permetterci di scoprire cosa abbiamo bisogno di migliorare piuttosto che cosa abbiamo potuto migliorare. La sicurezza è sempre forte come la parte più debole e quando si tratta di migliorare la sicurezza, solo i miglioramenti alla vostra parte più debole miglioreranno effettivamente la vostra sicurezza. Quindi, crediamo che la conversione in corso dovrebbe essere sempre mantenuta viva su quale sia la nostra parte più debole e come possiamo migliorarla.

Nessun principio di software non mantenuto/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. Questo significa che dobbiamo anche assicurarci che questo codice sia sicuro. Per il sistema operativo (un flavor di linux), l'ambiente del linguaggio di programmazione (php / node), il nostro server http (apache), e i sistemi di database (MariaDB), ci assicuriamo di usare sempre una versione che almeno riceve ancora patch di sicurezza. Questo significa che il nostro software viene regolarmente aggiornato per funzionare su una versione aggiornata. Inoltre, ci assicura di essere sempre sicuri, poiché per questi componenti, richiediamo che le patch di sicurezza siano installate automaticamente.

Per le librerie che usiamo nel nostro codice, usiamo strumenti automatici dove possibile per assicurarci 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.

Almeno 4 + 2 occhi di principio.

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

Per mantenere la qualità a cui miriamo, crediamo che, indipendentemente dalle circostanze, il nostro software non dovrebbe mai essere affrettato. Questo significa che un ciclo completo di revisione è richiesto per ogni cambiamento che facciamo al nostro prodotto. Questo significa che il codice deve essere visto e approvato da almeno due sviluppatori e poi testato da uno del nostro 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 riviste da almeno un altro sviluppatore. L'effettivo merging è fatto da qualcuno del nostro team di test. Quindi, uno sviluppatore non è in linea di principio in grado di fare il merge back di 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 i comuni errori di sicurezza per prevenire inutili fughe nel nostro sistema.

Una menzione speciale dovrebbe essere fatta sull'infrastruttura/amministrazione del sistema. Poiché il ciclo di sviluppo del codice permette di valutare la sicurezza e la qualità prima che arrivi in produzione, ci sforziamo di gestire la nostra intera infrastruttura come codice. Questo ci permette di automatizzare la maggior parte delle funzioni, il che significa che facciamo meno errori umani. Inoltre, un singolo amministratore di sistema può apportare modifiche senza notifica che potrebbero influenzare la sicurezza del nostro sistema.

Principio dell'accesso con il minimo privilegio.

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 perdita di dati è assicurarsi che non ci siano dati da perdere. La prossima cosa migliore è assicurarsi che nessuno possa accedere alle informazioni non necessarie. Per esempio, uno sviluppatore non ha bisogno di accedere ai nostri dati di produzione per sviluppare nuove funzionalità. Allo stesso modo, un traduttore ha solo bisogno di vedere ciò che può essere tradotto nel nostro sistema, e non ha bisogno di accedere al nostro codice base o alle informazioni sui clienti. Vogliamo assicurarci che chiunque nella nostra organizzazione possa vedere ed eseguire solo i compiti richiesti dal suo ruolo.

Il principio del minimo accesso privilegiato si applica agli esseri umani, ma anche ai sistemi e ai servizi. Se una parte del nostro sistema viene compromessa, puntiamo a minimizzare l'impatto che può avere. Pertanto, miriamo a separare i servizi che possono accedere solo alle informazioni di cui hanno bisogno. Per esempio, non abbiamo bisogno di elaborare informazioni di pagamento quando visualizziamo contenuti di apprendimento. Quindi, i sistemi responsabili dei contenuti di apprendimento non dovrebbero avere accesso al nostro sistema di pagamento. Inoltre, questo è possibile anche per altri servizi. Puntiamo a disconnettere i servizi dall'internet pubblico, se possibile. Questo è preferibilmente fatto mettendo i servizi in una rete privata, dalla quale possono essere accessibili solo da quella rete. Se il servizio non è destinato all'uso pubblico, ma è destinato ad essere accessibile su Internet, lavoriamo con una lista bianca di indirizzi IP, per minimizzare l'esposizione.

Note finali

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