Cet article est aussi disponible en :
Cet article est traduit à l’aide d’un outil de traduction automatique. Il peut contenir des erreurs ou présenter quelques incohérences. Nous pensons néanmoins qu'il est utile que vous puissiez lire cet article d'aide dans votre langue maternelle. N’hésitez pas à nous indiquer en bas de l'article si celui-ci vous a été utile ou si vous avez d'autres commentaires.

Ce document contient les principes directeurs sur la manière dont Easy LMS assure la sécurité et la confidentialité de ses clients.

La sécurité se décline en plusieurs couches et nous avons cinq principes directeurs qui nous permettent d'avoir des couches de sécurité plus nombreuses et meilleures au sein de notre organisation et de notre produit. Chacun de ces cinq principes sera examiné séparément dans le présent document. Nos cinq grands principes de sécurité sont les suivants :

Donner la priorité au principe de sécurité
Discuter du principe de sécurité
Pas de principe de logiciel non entretenu
Principe des 4 + 2 yeux au moins
Principe de l'accès le moins privilégié

Donner la priorité au principe de sécurité

Quoi qu'on fasse, on répare d'abord la sécurité.

Aucun logiciel n'est exempt de bogues, et même si nous faisons de notre mieux pour avoir la meilleure qualité possible de notre produit, nous ne faisons pas exception à la règle. Cela signifie que nous rencontrons parfois des problèmes de sécurité (potentiels) au sein de notre système. Chaque fois que le problème est présent dans notre installation de production, le bogue enregistré reçoit la priorité absolue afin de garantir qu'il n'existe pas de retard dans les problèmes de sécurité non résolus. Si plusieurs problèmes de sécurité sont détectés, c'est le problème de sécurité le plus grave qui est prioritaire.

Dans le cas où un problème de sécurité est détecté avant qu'il n'affecte notre environnement de production, un processus existe pour s'assurer que les déploiements ultérieurs du code vulnérable sont empêchés jusqu'à ce que la sécurité soit résolue. Comme cela pourrait nous empêcher de déployer de nouvelles fonctionnalités, ces problèmes sont également prioritaires pour les corrections.

On dit souvent qu'il vaut mieux être sûr que désolé. Nous pensons qu'assurer la sécurité d'un produit ne consiste pas à corriger les problèmes rencontrés, mais à s'assurer que ces problèmes n'existeront jamais au départ. C'est pourquoi nous pensons que la sécurité doit être une priorité dès les premières étapes du développement pour concevoir la sécurité directement dans notre produit, plutôt que d'appliquer des correctifs par la suite.

Discuter du principe de confidentialité/sécurité

Si nous ne réfléchissons pas et ne discutons pas sur la manière de nous améliorer, nous ne le ferons jamais.

Bien que la sécurité soit discutée et mise en œuvre au cœur de nos logiciels, nous pensons qu'il est toujours possible de l'améliorer. Le fait d'avoir une conversation nous aide à rester concentrés et attentifs à la façon dont nous abordons la sécurité. De plus, une discussion est un moyen de transformer de bonnes idées en grandes idées, et de bons designs en grands designs. Plus important encore, puisqu'il y a toujours place à l'amélioration, une discussion peut nous permettre de découvrir ce que nous devons améliorer plutôt que ce que nous peuvons améliorer. La sécurité est toujours aussi forte que la partie la plus faible et lorsqu'il s'agit d'améliorer la sécurité, seules les améliorations apportées à la partie la plus faible amélioreront réellement votre sécurité. C'est pourquoi nous pensons que la conversion en cours devrait toujours être maintenue en éveil sur ce qu'est notre partie la plus faible et comment nous pouvons l'améliorer.

Pas de principe de logiciel non entretenu/non sécurisé

Notre logiciel n'est pas sûr si la plate-forme sur laquelle il fonctionne ne l'est pas.

Nous n'avons pas inventé la roue, et nous n'avons certainement pas écrit notre propre système d'exploitation. Donc, oui, nous dépendons du code de tierces parties. Cela signifie que nous devons également nous assurer que ce code est sécurisé. Pour le système d'exploitation (une saveur de linux), l'environnement du langage de programmation (php / node), notre serveur http (apache), et les systèmes de base de données (MariaDB), nous nous assurons de toujours utiliser une version qui au moins reçoit encore des patches de sécurité. Cela signifie que notre logiciel est régulièrement mis à jour pour fonctionner avec une version actualisée. De plus, cela garantit que nous restons sécurisés tout au long du processus, car pour ces composants, nous exigeons que les patchs de sécurité soient installés automatiquement.

Pour les bibliothèques que nous utilisons dans notre code, nous utilisons des outils automatisés chaque fois que cela est possible pour nous assurer qu'elles disposent d'une version à jour, mais surtout d'une version sécurisée. En pratique, nous utilisons l'audit npm pour nous assurer que nos paquets node.js sont à jour. Et nous utilisons "roave/security-advisors" pour nous assurer que nos bibliothèques php sont sécurisées.

Principe des 4 + 2 yeux au moins

Tout changement, aussi insignifiant soit-il, doit être vérifié sur le plan de la qualité.

Pour maintenir la qualité que nous visons, nous pensons que, quelles que soient les circonstances, nos logiciels ne doivent jamais être précipités. Cela signifie qu'un cycle de révision complet est nécessaire pour chaque modification que nous apportons à notre produit. Cela signifie que le code doit être vu et approuvé par au moins deux développeurs, puis testé par un membre de notre équipe de test. Ce principe est ancré dans notre flux de travail. Avant que le code puisse être déployé dans un environnement de mise en scène ou de production, il doit faire l'objet d'une demande d'extraction. Les demandes d'extraction doivent être examinées par au moins un autre développeur. La fusion en retour est effectuée par un membre de notre équipe de test. Par conséquent, un développeur n'est en principe pas en mesure de fusionner une demande d'extraction. La sécurité fait (évidemment) partie du cycle d'examen. L'autre développeur évaluera le code afin de voir s'il y a des problèmes liés à la sécurité. Le testeur vérifie également les erreurs de sécurité courantes afin d'éviter les fuites inutiles dans notre système.

Une mention spéciale doit être faite à propos de l'administration des infrastructures/systèmes. Étant donné que le cycle de développement du code permet d'évaluer la sécurité et la qualité avant qu'il ne soit mis en production, nous nous efforçons de gérer l'ensemble de notre infrastructure sous forme de code. Cela nous permet d'automatiser la plupart des fonctionnalités, ce qui signifie que nous faisons moins d'erreurs humaines. En outre, un seul administrateur système peut apporter sans notification des modifications susceptibles d'affecter la sécurité de notre système.

Principe de l'accès le moins privilégié

Chaque personne doit avoir accès uniquement à ce dont elle a besoin et chaque programme doit pouvoir accéder uniquement à ce dont il a besoin.

La manière la plus fiable d'empêcher toute forme de fuite de données est de s'assurer qu'il n'y a aucune donnée à divulguer. Le mieux est ensuite de s'assurer que personne ne puisse accéder aux données inutiles surformation. Par exemple, un développeur n'a pas besoin d'accéder à nos données de production pour développer de nouvelles fonctionnalités. De même, un traducteur n'a besoin de voir que ce qui peut être traduit dans notre système, et n'a pas besoin d'accéder à notre base de code ou à notre client dansformation. Notre objectif est de faire en sorte que chaque membre de notre organisation puisse uniquement voir et effectuer les tâches nécessaires à son rôle.

Le principe de l'accès le moins privilégié s'applique aux humains, mais il s'applique aussi aux systèmes et aux services. Si une partie de notre système est compromise, nous cherchons à minimiser l'impact qu'elle peut avoir. C'est pourquoi nous visons à séparer les services qui ne peuvent accéder qu'aux informations dont ils ont besoin dansformation. Par exemple, nous n'avons pas besoin de traiter le paiement dansformation lorsque nous affichons un contenu d'apprentissage. Par conséquent, les systèmes responsables du contenu d'apprentissage ne devraient pas avoir accès à notre système de paiement. En outre, cela est également possible pour d'autres services. Nous nous efforçons de déconnecter les services de l'internet public si possible. Pour ce faire, il est préférable de placer les services sur un réseau privé, auquel on ne peut accéder qu'à partir de ce réseau. Si le service n'est pas destiné à un usage public, mais qu'il doit être accessible sur l'internet, nous travaillons avec une liste blanche d'adresses IP, afin de minimiser l'exposition.

Notes finales

Nous pensons qu'un effort continu est nécessaire pour maintenir un niveau de sécurité élevé. Cet effort signifie qu'il ne doit pas se limiter à des principes, mais que ces principes doivent être intégrés dans tous nos processus de travail. De cette manière, nous pouvons nous assurer que la sécurité est prioritaire au sein de notre organisation.
Cet article a-t-il répondu à vos questions ?
Annuler
Merci !