Dit artikel is ook beschikbaar in:
Dit document bevat de richtlijnen voor de manier waarop we bij Easy LMS de veiligheid en privacy van onze klanten waarborgen.

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

Prioriteit voor veiligheidsprincipe
Bespreek het beveiligingsprincipe
Geen onbeheerd softwareprincipe
Minimaal 4 + 2 ogen principe
Minst geprivilegieerde toegang principe

Prioriteit voor het beveiligingsprincipe

Wat we ook doen, we repareren de beveiliging eerst.

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 daar geen uitzondering op. Dit betekent dat we soms wel (potentiële) beveiligingsproblemen vinden binnen ons systeem. Wanneer het probleem zich voordoet binnen onze productie-installatie, krijgt de gelogde bug de hoogste prioriteit om er zeker van te zijn dat er geen backlog bestaat van onopgeloste beveiligingsproblemen. Als er meerdere beveiligingsproblemen worden gevonden, dan krijgt het beveiligingsprobleem met de hoogste prioriteit.

In het scenario waarin een beveiligingsprobleem wordt gevonden voordat het op onze productieomgeving is geland, bestaat er een proces om ervoor te zorgen dat verdere implementaties van de kwetsbare code worden voorkomen totdat de beveiliging is opgelost. Omdat het ons misschien weerhoudt om nieuwe functies te implementeren, krijgen deze problemen ook prioriteit bij het oplossen van de problemen.

We zeggen vaak dat het beter is om veilig te zijn dan sorry. We denken dat het garanderen van een veilig product niet gaat over het patchen van problemen die men tegenkomt, maar dat het erom gaat ervoor te zorgen dat deze problemen nooit zouden bestaan. Daarom denken we dat beveiliging een prioriteit zou moeten zijn vanaf de vroegste stadia van de ontwikkeling om beveiliging direct in ons product te ontwerpen in plaats van dingen achteraf te patchen.

Bespreek het privacy-/beveiligingsprincipe

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

Hoewel beveiliging in het hart van onze software wordt besproken en geïmplementeerd, denken we dat er altijd ruimte is voor verbetering. Het voeren van een gesprek helpt ons om gefocust en scherp te blijven op de manier waarop we de 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, aangezien er altijd ruimte is voor verbetering, kan een discussie ons in staat stellen om uit te vinden wat we moeten verbeteren in plaats van wat we kunnen verbeteren. De beveiliging is altijd zo sterk als het zwakste deel en als het gaat om het verbeteren van de beveiliging, zullen alleen verbeteringen aan je zwakste deel je beveiliging daadwerkelijk verbeteren. Daarom geloven we dat de voortdurende conversie altijd in leven moet worden gehouden over wat ons zwakste deel is, en hoe we dat kunnen verbeteren.

Geen onbeheerde/onbeveiligde software principe

Onze software is niet veilig als het platform waarop het draait niet veilig is.

We hebben het wiel niet uitgevonden en zeker niet ons eigen besturingssysteem geschreven. Dus ja, we zijn afhankelijk van de code van derden. Dit betekent dat we er ook voor moeten zorgen dat deze code veilig is. Voor het besturingssysteem (een linux flavor), de programmeertaal omgeving (php / node), onze http server (apache), en database systemen (MariaDB), zorgen we ervoor dat we altijd een versie gebruiken die tenminste nog steeds veiligheidspatches ontvangt. Dit betekent dat onze software regelmatig wordt geüpdatet om op een up-to-date versie te draaien. Het zorgt er ook voor dat we altijd veilig blijven, want voor deze componenten vereisen we dat er automatisch beveiligingspatches worden geïnstalleerd.

Voor bibliotheken die we in onze code gebruiken, gebruiken we waar mogelijk geautomatiseerde tools om ervoor te zorgen dat deze een actuele versie hebben, maar vooral 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 ervoor te zorgen dat onze php-bibliotheken veilig zijn.

Minstens 4 + 2 ogen principe

Elke verandering, hoe triviaal ook, moet op kwaliteit worden gecontroleerd.

Om de kwaliteit waar we naar streven te handhaven, geloven we dat onze software nooit overhaast moet worden gemaakt, ongeacht de omstandigheden. Dit betekent dat een volledige revisiecyclus nodig is voor elke verandering die we aan ons product aanbrengen. Dit betekent dat de code moet worden gezien en goedgekeurd door ten minste twee ontwikkelaars en vervolgens moet worden getest door een van onze testteams. Dit principe is verankerd in onze workflow. Voordat code kan worden ingezet op een staging of productieomgeving, moet het een pull verzoek doorstaan. Pull-verzoeken moeten worden beoordeeld door ten minste een andere ontwikkelaar. De eigenlijke merging back wordt gedaan door iemand van ons testteam. Een ontwikkelaar is dus in principe niet in staat om een pull verzoek terug te voegen. Beveiliging is (uiteraard) onderdeel van de review cyclus. De andere ontwikkelaar zal de code beoordelen 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 moet worden gemaakt over infrastructuur/systeembeheer. Aangezien de code-ontwikkelingscyclus het mogelijk maakt om de veiligheid en kwaliteit te beoordelen voordat deze de productie raakt, streven we ernaar om onze volledige infrastructuur als code te beheren. Dit stelt ons in staat om de meeste functies te automatiseren, waardoor we minder menselijke fouten maken. Bovendien kan een enkele systeembeheerder zonder kennisgeving wijzigingen aanbrengen die de veiligheid van ons systeem kunnen beïnvloeden.

Minst geprivilegieerde toegang principe

Elke persoon moet alleen toegang hebben tot wat hij of zij nodig heeft en elk programma moet alleen toegang hebben tot wat het nodig heeft.

De meest betrouwbare manier om elke vorm van datalekken te voorkomen, is door ervoor te zorgen dat er geen enkele vorm van datalekken is. Het volgende wat het beste is, is ervoor te zorgen dat niemand toegang heeft tot de onnodige informatie. Een ontwikkelaar heeft bijvoorbeeld geen toegang tot onze productiedata nodig om nieuwe functies te ontwikkelen. Ook hoeft een vertaler alleen maar te zien wat er in ons systeem vertaald kan worden en heeft hij geen toegang nodig tot onze codebasis of klantinformatie. We streven ernaar dat iedereen in onze organisatie alleen de taken kan zien en uitvoeren die nodig zijn voor zijn of haar rol.

Het principe van de minst geprivilegieerde toegang geldt voor mensen, maar het wordt ook toegepast op systemen en diensten. Als een deel van ons systeem wordt gecompromitteerd, proberen we de impact die het kan hebben tot een minimum te beperken. Daarom proberen we diensten die alleen toegang hebben tot de informatie die ze nodig hebben, te scheiden. Zo hoeven we bijvoorbeeld geen betalingsinformatie te verwerken bij het weergeven van leerinhouden. Daarom zouden de systemen die verantwoordelijk zijn voor de leerinhouden geen toegang moeten hebben tot ons betaalsysteem. Bovendien is dit ook mogelijk voor andere services. We streven ernaar om diensten indien mogelijk los te koppelen van het openbare internet. Dit gebeurt bij voorkeur door diensten in een privénetwerk te plaatsen, van waaruit ze alleen toegankelijk zijn vanuit dat netwerk. Als de dienst niet bedoeld is voor publiek gebruik, maar bedoeld is om via het internet te worden benaderd, werken we met een witte lijst van IP-adressen, om de exposure te minimaliseren.

Laatste notities

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