hero background ibexa-apla

Sécurité

La sécurité des produits chez Ibexa

Le XXIe siècle nous a appris à tous que la sécurité de l’information est primordiale et ne peut être prise à la légère. Ce n’est pas quelque chose que l’on peut faire quand on a du temps libre, ni une préoccupation secondaire. Cela doit être au cœur des préoccupations de toute entreprise du secteur des technologies de l’information – et quelle entreprise ne fait pas appel aux technologies de l’information aujourd’hui ? Avec des clients professionnels dans des secteurs tels que le commerce, la finance, la distribution et la défense, nous connaissons mieux que quiconque les exigences en matière de sécurité.

Sécurité et vie privée

Il existe un lien étroit entre sécurité et vie privée. Parfois, ces deux aspects s’opposent : si un service ne conserve aucun journal d’activité et ne nécessite aucune connexion, la vie privée des utilisateurs est bien protégée, mais les attaques et les abus sont difficiles à gérer. D’autres fois, ils se renforcent mutuellement : un système de connexion sécurisé préserve la vie privée de ses utilisateurs contre les attaques. Ibexa considère la sécurité comme une condition nécessaire à la protection de la vie privée. La « protection de la vie privée dès la conception » (PbD) est un ensemble de principes généraux que Ibexa soutient. Elle reste toutefois vague, avec peu de détails techniques, ce qui rend difficile de déterminer si un produit donné est conforme ou non. Le RGPD de l’UE entre davantage dans les détails en intégrant les principes de la « protection de la vie privée dès la conception ». Ibexa s’efforce de permettre à ses clients et à sa communauté d’être conformes au RGPD et au PbD grâce aux fonctionnalités de ses produits et à sa documentation, car le facteur déterminant pour la conformité réside dans la manière dont nos produits sont mis en œuvre et configurés par eux.

La sécurité est une priorité pour toute l’entreprise

Chez Ibexa, nous mettons tout en œuvre pour maintenir des normes de sécurité élevées dans nos produits. L’équipe d’assistance reçoit les incidents signalés par les partenaires et les clients, et collabore avec eux pour en identifier la cause. L’équipe chargée de la réussite client interagit avec les clients pour identifier les points sensibles et fait valoir en interne les intérêts prioritaires des clients au sein de l’organisation. L’équipe d’ingénierie corrige les problèmes détectés et est chargée de mettre en œuvre les meilleures pratiques afin de minimiser le risque que de tels problèmes surviennent. L’équipe d’assurance qualité vérifie que les problèmes corrigés le sont bel et bien et, grâce à des tests approfondis, joue un rôle central dans la détection de nouveaux problèmes. L’équipe de maintenance diffuse les correctifs, informe sur la gravité et les conséquences possibles, et recommande les mesures à prendre pour résoudre les problèmes. L’équipe de sécurité élabore des bonnes pratiques en collaboration avec l’ingénierie, recherche de nouvelles méthodes de détection des problèmes et partage des informations en interne et en externe sur les pratiques de développement et d’utilisation sécurisées.

Voici comment nous nous efforçons de rendre nos produits plus sûrs :

Prévention

Les meilleurs problèmes de sécurité sont ceux qui n’existent pas. Ibexa DXP s’appuie sur des outils de pointe tels que Symfony, qui dispose de ses propres routines de sécurité rigoureuses. Là où Symfony a « inventé la roue » en matière de sécurité, nous n’avons pas besoin de la réinventer. Nous bénéficions également de la sécurité éprouvée de la pile LAMP, qui comprend Linux/Unix, Apache/Nginx, MySQL/MariaDB et PHP. Nos meilleures pratiques de développement incluent une révision par les pairs rigoureuse et obligatoire au sein de l’équipe d’ingénierie. Dans la mesure du possible, ce processus de révision est entièrement ouvert, ce qui nous permet également de bénéficier des avis de nos pairs au sein de notre vaste communauté diversifiée et de notre écosystème de partenaires. De plus, nous recourons largement aux tests automatisés pour détecter les problèmes avant qu’ils ne soient intégrés à notre base de code, en complément des tests effectués par notre équipe d’assurance qualité.

Détection

La découverte des problèmes peut provenir de diverses sources. Elle peut être interne, le fait de nos propres équipes. Elle peut provenir de partenaires, tant en amont qu’en aval (par exemple, nous sommes intégrés au processus de sécurité de Symfony, ce qui signifie que celui-ci partage des informations avec nous, nous permettant ainsi de publier des correctifs en même temps que lui).

Nous encourageons la communauté, les chercheurs et toute autre partie intéressée à nous faire part de leurs découvertes de manière sécurisée et responsable ; voir https://doc.ibexa.co/en/latest/infrastructure_and_maintenance/security/reporting_issues/

NB : Nous apprécions le travail et la réflexion qui sous-tendent la recherche et le signalement en matière de sécurité, et nous ne les sanctionnerons pas par des poursuites judiciaires ou toute autre mesure. Nous estimons que les vulnérabilités corrigées dans le code public doivent être portées à la connaissance du public ; c’est pourquoi nous ne demandons pas aux personnes qui signalent ces vulnérabilités de signer des accords de confidentialité. Nous demandons uniquement que les vulnérabilités soient signalées via nos canaux sécurisés et qu’un délai raisonnable nous soit accordé pour résoudre le problème avant sa divulgation.

Résolution

Notre processus de résolution des problèmes se déroule comme suit :

  • Lorsqu’un problème est découvert par une tierce partie, nous tenons le signalant informé pendant les phases de développement et de test, et nous lui permettons de l’examiner avant sa divulgation.
  • Nous collaborons avec les projets en amont et en aval lorsque cela s’avère pertinent, par exemple avec Symfony.
  • Les problèmes de sécurité sont traités en priorité absolue au sein de l’équipe d’ingénierie, sauf s’ils sont jugés présenter un risque ou une gravité très faibles.
  • Les informations relatives au problème restent internes (sauf lorsque nous tenons les signalants externes informés) jusqu’à ce que le correctif soit disponible.
  • Une fois le correctif approuvé, nous l’appliquons à toutes les versions maintenues de nos produits commerciaux et le rendons public.

Publication

Ibexa DXP distribue ses nouvelles versions via Composer. Les entreprises abonnées sont informées des correctifs de sécurité via le portail de services et par e-mail (et, dans certains cas, par un contact plus direct). La divulgation publique s’effectue via les canaux suivants : https://developers.ibexa.co/security-advisories et les avis de sécurité GitHub pour les dépôts publics.

Lorsque le signalant est une partie externe, nous le mentionnons dans l’avis de sécurité, l’avis GitHub et le « Hall of Fame », s’il le souhaite. Nous évitons de publier des correctifs de sécurité pendant ou juste avant les week-ends et les jours fériés importants, afin de donner aux administrateurs de sites le plus de temps possible pour appliquer rapidement les correctifs ou mettre à jour leurs sites. Les vulnérabilités de type « zero-day » peuvent faire l’objet d’une publication à tout moment.