Dit artikel is ook beschikbaar in:
Dit artikel is vertaald met behulp van machinevertaling. Hierin zijn mogelijk foutieve of vreemde vertalingen aanwezig. Vooralsnog denken we dat het waardevol is om dit hulpartikel in jouw moedertaal te kunnen lezen. Laat ons onderaan het artikel weten of het artikel nuttig was en of je nog andere feedback voor ons hebt.

Dit document bevat de leidende principes bij hoe we bij Easy LMS de veiligheid en privacy van onze klanten bewaren.

Veiligheid komt in lagen en we hebben vijf leidende principes die ons in staat stellen meer en betere lagen van veiligheid binnen onze organisatie en ons product te hebben. Elk van deze vijf principes wordt in dit document apart besproken. Onze vijf belangrijkste beveiligingsprincipes zijn:

Geef prioriteit aan het beveiligingsprincipe
Bespreek beveiliging principe
Geen niet-onderhouden software principe
Minstens 4 + 2 ogen principe
Minst bevoorrechte toegang principe

Geef prioriteit aan het beveiligingsprincipe

Wat we ook doen, we repareren eerst de beveiliging.

Geen enkel stukje software is zonder bugs, en ook al doen we ons best om de hoogst mogelijke kwaliteit van ons product te hebben, we zijn hierop geen uitzondering. Dit betekent dat we soms wel (potentiële) beveiligingsproblemen in ons systeem vinden. Als het probleem zich in onze productie-installatie voordoet, krijgt de gelogde bug de hoogste prioriteit om te voorkomen dat er een achterstand van onopgeloste beveiligingsproblemen ontstaat. Worden er meerdere beveiligingsproblemen gevonden, dan krijgt het beveiligingsprobleem met de hoogste ernst voorrang.

In het scenario waarin een beveiligingsprobleem ontdekt wordt voordat het in onze productie-omgeving terecht komt, bestaat een proces om te zorgen dat verdere inzettingen van de kwetsbare code voorkomen worden totdat de beveiliging opgelost is. Omdat het ons zou kunnen afhouden van het inzetten van nieuwe functies, krijgen deze problemen ook voorrang voor reparaties.

We zeggen vaak dat het beter om veilig te zijn dan sorry is. We denken dat het verzekeren van een veilig product niet gaat om het patchen van problemen die zich voordoen, maar om ervoor te zorgen dat die problemen in de eerste plaats nooit zouden bestaan. Vandaar dat we vinden dat beveiliging vanaf het allereerste stadium van ontwikkeling een prioriteit moet zijn, om beveiliging in ons product in te bouwen in plaats van het achteraf te patchen.

Bespreek privacy/beveiligingsprincipe

Als we niet nadenken en discussiëren over hoe we kunnen verbeteren, zullen we het nooit doen.

Hoewel beveiliging in het hart van onze software besproken en geïmplementeerd wordt, denken we dat er altijd ruimte is voor verbetering. Een gesprek voeren helpt ons om gericht en scherp te blijven over hoe we beveiliging benaderen. Ook is een gesprek een manier om goede ideeën om te zetten in geweldige ideeën, en goede ontwerpen in geweldige ontwerpen. Belangrijker nog, omdat er altijd ruimte is voor verbetering, kan een gesprek ons in staat stellen uit te zoeken wat we moeten verbeteren in plaats van wat we kunnen verbeteren. Beveiliging is altijd zo sterk als het zwakste deel en als het om verbetering van de beveiliging gaat, zullen alleen verbeteringen aan je zwakste deel je beveiliging werkelijk verbeteren. Vandaar dat we geloven dat de voortdurende conversie over wat ons zwakste deel is, en hoe we dat kunnen verbeteren, altijd levend gehouden moet worden.

Geen niet-onderhouden/onbeveiligd software principe

Onze software is niet veilig als het platform waarop ze draait dat ook niet is.

We hebben het wiel niet uitgevonden, en zeker niet ons eigen besturingssysteem geschreven. Dus, ja, we zijn afhankelijk van de code van derden. Dat betekent dat we er ook voor moeten zorgen dat die code veilig is. Voor het besturingssysteem (een linux smaak), de programmeertaal omgeving (php / node), onze http server (apache), en de databasesystemen (MariaDB), zorgen we ervoor dat we altijd een versie gebruiken die ten minste nog beveiligingspatches krijgt. Dit betekent dat onze software regelmatig wordt bijgewerkt om op een actuele versie te draaien. Ook zorgt het ervoor dat we steeds veilig blijven, want voor deze componenten eisen we dat beveiligingspatches automatisch geïnstalleerd worden.

Voor bibliotheken die we in onze code gebruiken, gebruiken we waar mogelijk geautomatiseerde hulpmiddelen om zeker te zijn dat die een actuele versie hebben, maar belangrijker nog een veilige versie. In de praktijk gebruiken we 'npm audit' om er zeker van te zijn dat onze node.js pakketten up to date zijn. En we gebruiken 'roave/security-advisors' om er zeker van te zijn dat onze php bibliotheken veilig zijn.

Minstens 4 + 2 ogen principe

Elke verandering, hoe onbeduidend ze ook lijkt, moet op kwaliteit gecontroleerd worden.

Om de kwaliteit die we nastreven hoog te houden, vinden we dat onze software, ongeacht de omstandigheden, nooit overhaast mag zijn. Dit betekent dat een volledige beoordelingscyclus vereist is voor elke verandering die we aan ons product aanbrengen. Dit betekent dat de code door minstens twee ontwikkelaars gezien en goedgekeurd moet worden en dan door een van onze testers getest moet worden. Dit principe is verankerd in onze werkstroom. Voordat code in een staging of productie omgeving kan worden ingezet, moet hij een pull request doorstaan. Pull requests moeten door ten minste een andere ontwikkelaar worden nagekeken. Het eigenlijke terug-samenvoegen wordt gedaan door iemand van ons testteam. Vandaar dat een ontwikkelaar in principe niet in staat is een pull request terug te mergen. Beveiliging maakt (uiteraard) deel uit van de beoordelingscyclus. De andere ontwikkelaar beoordeelt de code om te zien of er problemen zijn met de beveiliging. De tester test ook op veel voorkomende beveiligingsfouten om onnodige lekken in ons systeem te voorkomen.

Een speciale vermelding verdient infrastructuur/systeembeheer. Omdat de code ontwikkelcyclus het mogelijk maakt veiligheid en kwaliteit te beoordelen voordat het in productie komt, streven we ernaar onze volledige infrastructuur als code te beheren. Dit stelt ons in staat de meeste functies te automatiseren, waardoor we minder menselijke fouten maken. Bovendien kan een enkele systeembeheerder zonder kennisgeving veranderingen aanbrengen die onze systeembeveiliging kunnen aantasten.

Minst bevoorrechte toegang principe

Ieder mens mag alleen toegang hebben tot wat hij nodig heeft en ieder programma mag alleen toegang hebben tot wat het nodig heeft.

De meest betrouwbare manier om elke vorm van gegevenslekken te voorkomen, is door ervoor te zorgen dat er helemaal geen gegevens te lekken zijn. Het op één na beste is ervoor te zorgen dat niemand bij de onnodige informatie kan komen. Een ontwikkelaar heeft bijvoorbeeld geen toegang nodig tot onze productiegegevens om nieuwe functies te ontwikkelen. Evenzo hoeft een vertaler alleen te zien wat in ons systeem vertaald kan worden, en heeft hij geen toegang nodig tot onze code base of klanteninformatie. We willen ervoor zorgen dat iedereen in onze organisatie alleen de taken kan zien en uitvoeren die voor zijn of haar rol nodig zijn.

Het principe van de minst bevoorrechte toegang geldt voor mensen, maar het wordt ook toegepast op systemen en diensten. Als een deel van ons systeem gecompromitteerd wordt, willen we de impact die dat kan hebben zo klein mogelijk houden. Daarom streven we ernaar diensten af te zonderen die alleen toegang hebben tot de informatie die ze nodig hebben. Zo hoeven we bijvoorbeeld geen betalingsinformatie te verwerken bij het tonen van leerinhoud. Vandaar dat de systemen die verantwoordelijk zijn voor leerinhoud geen toegang mogen hebben tot ons betalingssysteem. Verder is dit ook mogelijk voor andere diensten. We streven ernaar diensten zo mogelijk los te koppelen van het openbare internet. Dit gebeurt bij voorkeur door de diensten in een privé netwerk te plaatsen, van waaruit ze alleen vanuit dat netwerk te benaderen zijn. Als de dienst niet voor publiek gebruik bestemd is, maar wel via het internet benaderd moet worden, werken we met een witte lijst van IP-adressen, om de blootstelling te minimaliseren.

Slotopmerkingen

We geloven dat een voortdurende inspanning nodig is om een hoog niveau van beveiliging te handhaven. Deze inspanning houdt in dat het niet bij principes moet blijven, maar dat deze principes in al onze werkstroomprocessen ingebed moeten worden. Op die manier kunnen we ervoor zorgen dat beveiliging prioriteit heeft binnen onze organisatie.
Was dit artikel behulpzaam ?
annuleren
Dank je wel !