La securité de Lokad

Vision Base de connaissances Technologie

Moteur de prévision

Plateforme

Keep learning with
LOKAD TV

Lokad est, avant tout, un spécialiste de la supply chain et notre objectif principal est de fournir des décisions de qualité supérieure en matière de supply chain grâce à l'ingéniosité technologique. Cela dit, nous manipulons quotidiennement des données financières importantes. La sécurité de notre plateforme logicielle est donc une priorité que nous traitons avec le plus grand sérieux. Plutôt que d'aborder la sécurité comme une réflexion après coup à gérer par la bureaucratie, nous croyons fermement en une approche de principe qui met l'accent sur la planification et la proactivité, comme en témoignent nos choix spécifiques en matière de conception de logiciels, de personnel et de formation.

Public visé : Le département informatique Dernière modification : 27 janvier 2023

Principes de sécurité

L'une des illusions les plus nuisibles dans le milieu des logiciels d'entreprise est l'idée que la sécurité peut être abordée à l'aide de listes de contrôle de conformité, de certifications et, plus généralement, de toutes sortes de travaux bureaucratiques. Malheureusement, les détails des problèmes de sécurité sont toujours en évolution. Les problèmes surviennent lorsque des acteurs mal intentionnés profitent des logiciels ou des personnes (ou des deux). La sécurité ne peut donc être abordée que par l'application judicieuse de principes généraux.

Une conception plus sûre

Nous pensons que la conception est l'un des aspects les plus sous-estimés de la sécurité des logiciels. Ici, la conception couvre les décisions fondamentales qui ont été prises pour développer le logiciel. Les décisions de conception prises par une entreprise ont des répercussions considérables sur la sécurité, notamment sur la surface d'attaque. Grâce à une conception judicieuse du logiciel, Lokad a éliminé des catégories entières de problèmes de sécurité. Par exemple, Lokad n'utilise pas une base de données SQL - mais un simple stockage blob - comme couche de stockage strictement passive. Ce choix permet à lui seul d'éviter des groupes entiers de problèmes de sécurité, tels que les attaques par injection SQL, car il n'y a tout simplement pas de base de données SQL à attaquer. De même, toutes nos couches de persistance ne sont que des appendices. C'est comme le contrôle de version où les modifications sont ajoutées à la fin des données existantes, plutôt que d'écraser l'ensemble des données. Tous les changements sont tracés et peuvent être inversés. Cette étape complique grandement la suppression de toute donnée (par quiconque, y compris les attaquants), et tempère les journaux de Lokad.

La plupart des fournisseurs de logiciels d'entreprise ne reconnaissent pas le fait que les choix de conception de base constituent le fondement même de leurs produits logiciels. Par conséquent, leurs problèmes de sécurité sont sans fin. Par exemple, si la configurabilité - presque toujours une exigence pour les logiciels d'entreprise - est assurée par un langage de programmation polyvalent (comme Python ou JavaScript), des problèmes de sécurité se poseront invariablement. En effet, il est pratiquement impossible de sécuriser totalement un langage de programmation à usage général. En revanche, Lokad a fait le choix délibéré de canaliser toute la configurabilité à travers un DSL (langage de programmation spécifique à un domaine) appelé Envision. Envision est beaucoup plus sûr parce qu'il n'a pas - par conception - la capacité d'interagir directement avec l'OS (système d'exploitation) et ses sous-systèmes, comme le système de fichiers.

Cultiver la sécurité

Aucune technologie, et certainement aucun processus, ne peut rendre un logiciel sûr si les gens ne s'en soucient pas. C'est pourquoi nous nous efforçons de faire de Lokad - tant ses technologies que ses processus - quelque chose qui mérite une véritable attention. Dans le contexte des logiciels d'entreprise, cela est difficile car l'objet d'intérêt est abstrait et déconnecté des perspectives et motivations individuelles des personnes^[a].

Tout d'abord, Lokad aligne, autant qu'il est humainement possible, ses messages marketing sur la réalité de son activité. Nous le faisons, que cela nous attire les faveurs ou les critiques. Cela contraste fortement avec de nombreux fournisseurs d'entreprises qui font des déclarations publiques déraisonnables (et souvent fantaisistes) ^[b]. Lorsque cela se produit, les employés pointus - ceux qui sont capables d'identifier le décalage entre la réalité de l'entreprise et ce qui est communiqué au monde extérieur - cessent de s'en soucier. Cette indifférence engendre la complaisance, et les problèmes de sécurité s'ensuivent. Souvent, ces employés quittent l'entreprise, laissant derrière eux les "crédules" - ceux qui ne voient pas la déconnexion. La crédulité, tout comme l'indifférence, n'est pas un trait souhaitable en matière de sécurité.

Deuxièmement, Lokad encourage chez ses employés un mélange de curiosité et de scepticisme sain sur tous les aspects de notre activité, qu'ils soient techniques ou non, y compris la sécurité. Cela crée une certaine souplesse lorsqu'il s'agit de réviser et d'actualiser les pratiques, car les employés sont formés et encouragés à contribuer. Une telle plasticité est utile pour anticiper les acteurs mal intentionnés, étant donné qu'ils sont connus pour concevoir des moyens d'attaque toujours plus créatifs. Heureusement pour Lokad, cet état d'esprit est également très souhaitable pour la supply chain, car les comportements indésirables - sans être nécessairement criminels - sont courants dans la supply chain ^[c].

Former pour la sécurité

Nous formons activement l'ensemble de notre personnel afin de mieux comprendre les cybermenaces et les moyens de les atténuer. Contrairement à la conception et à la culture, la formation à la sécurité est en grande partie un processus descendant. Bien que la pensée ascendante ait sa place, ce type de formation est intrinsèquement faible face à la plupart des risques de sécurité informatique. En d'autres termes, même si les gens sont formés à ne pas faire quelque chose, Lokad ne peut pas supposer que personne ne la fera jamais ^[d]. Ainsi, nous adoptons une approche plus stricte. Dans le cadre de notre formation, nous décourageons les clés USB et autres dispositifs USB qui pourraient compromettre les machines. Nous veillons à ce que l'authentification à deux facteurs soit utilisée chaque fois que possible. Nous formons notre personnel à fonctionner avec le moins de privilèges possible sur leurs postes de travail. Nous nous assurons que chacun est conscient du fonctionnement de l'ingénierie sociale, qui peut être utilisée pour tromper même les personnes les plus intelligentes.

Plus généralement, la formation à la sécurité vise à sensibiliser les gens à la façon dont les logiciels et les processus peuvent être détournés et corrompus par des acteurs mal intentionnés. Étant donné l'ampleur de la formation, des compétences et du savoir-faire requis pour prévenir des attaques aussi nuancées, Lokad compte généralement très peu de stagiaires, par rapport à la plupart des entreprises de taille comparable dans ce domaine. En bref, nous préférons miser sur une équipe stable et bien formée à long terme.

[a] Dans le secteur des jeux vidéo, de nombreux employés, si ce n'est la plupart, sont réellement passionnés par les jeux vidéo, pas seulement par ceux qui ont été développés par l'employeur, mais par le marché dans son ensemble. Nombre de ces employés ne se contentent pas de "faire leur travail" ; ils sont émotionnellement investis dans le résultat de leur travail. En revanche, l'état par défaut des employés des logiciels d'entreprise est, franchement, un immense ennui. Faire en sorte que les gens s'intéressent à un logiciel d'entreprise est un combat difficile, mais nécessaire.

[b] Les technologies de prévision, ingrédient clé des solutions d'optimisation de la chaîne logistique, sont particulièrement sujettes à des exagérations spectaculaires, tant en termes de précision des prévisions que de résultats positifs pour les entreprises clientes. See Top 10 des mensonges des fournisseurs de prévisions

[c] La corruption épistémique est une catégorie fascinante de problèmes de sécurité. Elle dégrade les logiciels non pas par le code, mais par la propagation de croyances erronées ou nuisibles parmi les spécialistes qui dirigent le développement du logiciel. Voir Etude de marché contradictoire pour les logiciels d’entreprise

[d] Même les personnes les plus fiables sont parfois épuisées, malades, en détresse. Le vieil adage dit que tout système (informatique) qui repose sur la fiabilité humaine n'est pas fiable.

Frequently Asked Questions (FAQ)

1. Pratiques

1.1 Disposez-vous d’une assurance sécurité

Oui. L'assurance de la sécurité est un terme générique qui recouvre toute une série de pratiques telles que le renforcement de la sécurité, les tests de sécurité et la gestion des vulnérabilités. Le renforcement de la sécurité, chez Lokad, est avant tout abordé par la conception. Grâce à des choix de conception spécifiques, nous éliminons des classes entières de vulnérabilités qui, à leur tour, éliminent le besoin même de durcissement. Par exemple, Lokad ne repose pas sur une couche de stockage "programmatique" - telle qu'une base de données relationnelle - mais sur un simple magasin clé-valeur. Cela élimine tous les vecteurs d'injection SQL. En outre, les tests de sécurité sont abordés par le biais de diverses méthodes, certaines automatisées et d'autres manuelles, comme les tests de pénétration effectués par des tiers. En ce qui concerne la gestion des vulnérabilités, nous disposons d'un programme de prime aux bugs et d'un processus de gestion des versions largement automatisé afin de garantir le déploiement rapide des correctifs.

1.2 Respectez-vous la norme ISO 27001 (ISMS) et/ou au SOC 2 ?

Non. Nous croyons fermement que ces certifications sont des distractions qui rendent les entreprises de logiciels moins sûres. Ces processus de conformité mettent l'accent sur un état d'esprit bureaucratique qui est à l'opposé de ce qui est nécessaire pour rendre les logiciels sûrs. Par exemple, ces certifications exigent la production de documents et l'installation de comités. Franchement, l'idée que la paperasserie et les comités apportent quelque chose de concret à la sécurité des logiciels est profondément discutable et Lokad ne l'accepte pas du tout.

Dans le milieu des logiciels, la sécurité est généralement obtenue en faisant moins, et non plus, en tirant parti des efforts des ingénieurs logiciels spécialisés dans la sécurité des logiciels, et non en créant des équipes supplémentaires de non-spécialistes. À titre de preuve anecdotique, il suffit de considérer certaines des catastrophes les plus graves en matière de cybersécurité, comme Heartbleed ou Log4Shell. Ces catastrophes auraient probablement été évitées si les milliers d'entreprises de logiciels "certifiés" avaient choisi de donner la priorité à la vérification du code tiers - souvent à l'origine des problèmes - plutôt qu'à la recherche de sceaux d'approbation commerciaux arbitraires.

Dans l'ensemble, nous pensons que ces certifications sont des gadgets marketing qui bercent les entreprises d'un faux sentiment de sécurité (au sens figuré comme au sens propre).

1.3 Suivez-vous les pratiques de l'OWASP ?

Oui. L'OWASP fournit, par le biais de ses guides, une liste de contrôle exhaustive des vulnérabilités couramment rencontrées dans les logiciels. Il s'agit d'une compilation étendue et de haute qualité que les ingénieurs de Lokad utilisent pour protéger nos logiciels contre tous les problèmes identifiés par l'OWASP. Cependant, par ses choix de conception, Lokad élimine en grande partie des classes entières de vulnérabilités courantes mises en évidence par l'OWASP. Par exemple :

Gestion des mots de passe : En déléguant l'authentification par le biais de la fonctionnalité SSO (single sign-on, recommandée par Lokad), Lokad n'a plus à "gérer" les mots de passe, ce qui rend caduque toute la liste de contrôle relative aux mots de passe.

Enregistrement : La conception de l'approvisionnement par événement adoptée par Lokad enregistre tout par nécessité. Si une action n'est pas enregistrée, le système considère qu'elle n'a jamais eu lieu. Cela annule la plupart de la liste de contrôle de l'exploitation forestière.

Sécurité de la base de données : La couche de persistance de Lokad ne comprend pas de base de données relationnelle, mais seulement deux composants non programmatiques, à savoir une source d'événements et un magasin clé-valeur. Ce choix de conception annule entièrement la liste de contrôle de la base de données.

De manière plus générale, nous préférons, dans la mesure du possible, éviter les modèles de conception technique susceptibles d'entraîner des erreurs, qui sont à l'origine de la nécessité de ces listes de contrôle.

1.4 Êtes-vous conforme au GDPR ?

Oui. Cependant, l'optimisation de la chaîne d'approvisionnement - telle que fournie par Lokad - ne nécessite pas de données personnelles. Nous considérons les données personnelles comme un passif plutôt que comme un actif. Ainsi, nous recommandons vivement à nos clients de ne pas nous transférer de données personnelles. Cette recommandation fait généralement partie de nos accords contractuels. En n'ayant pas de données personnelles en dépôt, et donc en ne traitant pas de données personnelles, nous éliminons en grande partie les préoccupations et les protocoles liés à leur protection, tels que le GDPR ou des règlements similaires. Retour à 3.7

1.5 Tous les services/solutions tiers (qui impliquent l'accès à des informations personnelles identifiables (PII)) de la solution Lokad sont-ils conformes aux exigences du délégué à la protection des données (DPD) ?

l'optimisation de la chaîne d'approvisionnement - telle que fournie par Lokad - ne nécessite pas de données personnelles. Ainsi, nous recommandons vivement à nos clients de ne pas nous transférer de données personnelles.

Il convient de noter que la solution de Lokad comporte une liste très courte de tiers ayant accès aux données PII. À partir de janvier 2023, cette liste est limitée à Microsoft Azure.

1.6 Suivez-vous les meilleures pratiques de sécurité ?

Oui. En d'autres termes, nous faisons des choix prudents, car il n'existe pas d'accord sectoriel sur ce qui constitue "les meilleures pratiques en matière de sécurité des logiciels". De par sa nature même, la sécurité logicielle est en constante évolution, s'adaptant à un environnement rempli de nouvelles menaces et de nouveaux vecteurs d'attaque. Par conséquent, nous ne nous en remettons pas catégoriquement à des tiers pour ce qui est des meilleures pratiques en matière de sécurité logicielle. Au contraire, nous définissons ce qui est le plus adapté à nos clients. Cela nous permet d'absorber les bonnes pratiques lorsqu'elles sont disponibles, sans suivre de manière rigide celles qui sont moins recommandables simplement parce qu'elles sont populaires. Tout cela se traduit par des pratiques de sécurité logicielle qui sont d’actualité, applicables et efficaces.

1.7 Effectuez-vous régulièrement des tests de pénétration ?

Oui. Nous avons des tests de pénétration planifiés et non planifiés. Ceux qui sont prévus sont généralement financés par nos grands clients qui peuvent, conformément à l'accord contractuel signé avec eux, engager des sociétés spécialisées pour effectuer des tests de pénétration de leurs principaux fournisseurs de logiciels, dont Lokad. Il existe généralement un certain degré de coordination entre l'équipe d'ingénieurs de Lokad et ces spécialistes de la sécurité. Les tests non planifiés font généralement partie de notre programme public de prime aux bugs dans le cadre duquel des spécialistes de la sécurité indépendants peuvent tenter de trouver une faiblesse dans notre système susceptible d'être "exploitée".

1.8 Effectuez-vous régulièrement des audits externes ?

Non. Cela dit, nous sommes tout à fait disposés à nous soumettre à un audit externe si l'opération est financée par le client. Beaucoup de nos grands clients ont des dispositions pour de tels audits dans nos accords contractuels. En janvier 2023, cependant, les tests de pénétration effectués par les clients n'ont pas mis en évidence suffisamment de problèmes pour justifier la réalisation de tels audits.

1.9 Disposez-vous d'un plan de continuité des activités ?

Oui. La plus grande éventualité à laquelle Lokad a répondu est la cessation hypothétique de l'entreprise elle-même. Lokad fonctionne comme une solution SaaS, cependant, certains de nos grands clients ont prévu dans leurs accords contractuels de pouvoir demander des instantanés complets de notre base de code. Ces instantanés sont placés sous séquestre auprès d'un tiers convenu, de sorte qu'en cas de cessation des activités de Lokad, le client obtiendrait automatiquement l'accès à la base de code sous séquestre et une licence permissive pour recréer sa propre instance du service Lokad.

1.10 Disposez-vous d'un plan de communication en cas de crise ?

Oui. Pour chaque client, nous avons un point de contact identifié au sein de son organisation. De notre côté, il y a au moins deux employés chez Lokad - un principal et un suppléant (généralement deux de nos scientifiques de la chaîne d'approvisionnement) - qui supervisent la communication de tout message urgent au client. En pratique, la grande majorité des crises auxquelles nous sommes confrontés ne sont pas des problèmes de sécurité logicielle, mais de supply chain- des urgences que Lokad identifie sur la base des données que le client met à notre disposition. Dans le cas d'un événement de sécurité, ce canal est utilisé pour s'assurer que nos clients sont informés en temps utile.

1.11 Comment vous assurez-vous que les systèmes informatiques du client sont sécurisés ?

Nous recommandons fortement que Lokad n'ait pas accès aux systèmes informatiques de nos clients ; le système informatique du client ne devrait utiliser uniquement les méthodes « push » et « pull ». Cette approche vise à limiter la possibilité qu'un événement de sécurité survenu chez Lokad se propage au système informatique du client. En outre, nous recommandons vivement d'utiliser un processus d'authentification unique (SSO), car il élimine le scénario hypothétique où un mot de passe utilisé pour accéder à Lokad est intercepté (d'une manière ou d'une autre) et utilisé ultérieurement pour compromettre l'un des systèmes informatiques du client.

1.12 Comment sécurisez-vous votre réseau ?

Notre conception adopte une architecture de confiance zéro, c'est-à-dire qu'elle ne permet qu'aux bonnes personnes d'accéder aux données à un moment donné. Le simple fait d'être présent sur notre réseau ne confère pas un statut ou des privilèges automatiques (ce point est développé dans Authentification 2.1). Ainsi, bien que nous soyons attentifs à la sécurité des réseaux, nous veillons - dans un premier temps - à ce que la surface d'attaque associée à nos réseaux soit aussi réduite que possible.

Lokad utilise deux réseaux notables. Le premier est Microsoft Azure, qui est utilisé pour héberger notre solution. La sécurité du réseau Microsoft Azure est entièrement déléguée à Microsoft. Nous n'utilisons pas de capacités de mise en réseau "avancées" - telles que celles offertes par Microsoft Azure - au-delà des équilibreurs de charge de base.

Le second est le réseau local de notre siège à Paris. La sécurité du réseau local est gérée en interne par l'équipe d'ingénieurs de Lokad. Notre réseau local n'héberge aucun composant ou système qui contribue à l'environnement de production.

1.13 Garantissez-vous que tous les composants (y compris les composants tiers) et outils (y compris les outils open-source) intégrés dans la solution sont légalement valides pour le développement et l'utilisation en production ?

Oui. Lokad a, par rapport à la plupart des fournisseurs de logiciels d'entreprise, très peu de dépendances. Toutes nos principales dépendances sont des projets open-source crédibles et largement utilisés (ex : .NET de Microsoft, React de Facebook). Notre processus d'audit interne sur ce point précis est donc simple.

1.14 Comment gérez-vous les changements majeurs dans l'organisation et les processus en termes de sécurité ?

Étant donné que Lokad a adopté dès le départ des choix et des pratiques judicieux en matière de sécurité, il est rare qu'un changement, quelle que soit son ampleur (mineur ou majeur), ait un impact sur la sécurité (même en théorie). Dans toute l'histoire de Lokad, il n'y a que 3 événements qui pourraient être considérés comme réellement significatifs du point de vue de la sécurité : la migration vers Microsoft Azure en 2010 ; l'introduction de l'authentification déléguée en 2012 (pour les clients comme pour les employés) ; et, en interne chez Lokad, la migration de Google Authentication vers Microsoft Azure AD en 2022.

Pour chacun de ces événements, la migration avait été préparée des mois à l'avance par l'équipe d'ingénierie logicielle de Lokad. Des supports de formation et des sessions de formation pertinents ont été mis en place avant le changement prévu, afin de garantir la préparation de tous les employés de Lokad. Enfin, après chaque événement de migration, nous nous sommes assurés que le "chemin" précédent avait été éliminé, comme le veut la pratique standard de Lokad.

En janvier 2023, nous ne prévoyons pas de changements majeurs. Si un tel changement devait être introduit, nous procéderions presque certainement de la même manière.

1.15 Comment gérez-vous la fin d'un contrat ?

Nos accords détaillent le processus de résiliation à la fin d'un contrat, comme convenu avec le client. Le processus de résiliation se termine par la suppression définitive des données du client. Comme ce processus de résiliation représente un risque de sécurité en soi, ce point fait l'objet d'une discussion avec chaque client, et peut donc varier légèrement selon les cas. Du point de vue de la sécurité, un acteur mal intentionné pourrait essayer de se faire passer pour le client afin de déclencher une résiliation anticipée du contrat (et de perturber les opérations du client). Pour éviter cela, Lokad et le client s'efforceraient conjointement d'adopter un processus - appliqué contractuellement - qui ne soit pas trivialement vulnérable à une attaque par ingénierie sociale. Ce processus implique généralement des confirmations écrites et un délai obligatoire.

1.16 Quelle est la stratégie de licence de Lokad, le modèle de coût associé et le modèle de coût de maintenance annuel?

Lokad facture généralement un forfait mensuel associé au coût d'exploitation de la plateforme, plus un forfait mensuel associé au service fourni par les scientifiques de la chaîne d'approvisionnement dédiés au client (c'est-à-dire les ingénieurs fournis par Lokad). Les détails sont négociés et détaillés dans le contrat de service entre le client et Lokad. Ces deux frais représentent un forfait "tout compris" avec Lokad. Il n'y a pas de frais de maintenance supplémentaires, de frais de licence, d'intégrateurs tiers, de consultants tiers, etc. Le forfait est assorti de limites, en termes de portée et d'ampleur, qui sont négociées conjointement dans le cadre de l'accord contractuel relatif au service.

1.17 Pouvez-vous fournir les termes et conditions de Lokad pour la ou les licences, le ou les services, le support, la maintenance et les formations ?

Oui, à la demande du client, nous pouvons fournir un modèle de contrat qui représente un accord "de base". Cependant, les situations varient considérablement en fonction de l'ampleur de l'initiative de la chaîne d'approvisionnement, des pays concernés et de l'étendue des services attendus par Lokad. C'est pourquoi, dans la mesure du possible, nous préférons engager une discussion initiale avec un client potentiel, afin de clarifier les spécificités de l'initiative de chaîne d'approvisionnement envisagée. Cela nous aide à élaborer le cadre contractuel le plus pertinent pour la situation.

1.18 Fournissez-vous une formation (sur place/en ligne) ?

Oui, Lokad propose des formations sur place et à distance. Les détails de ces sessions sont négociés dans le cadre de l'accord contractuel. En outre, Lokad dispose à la fois d'une vaste documentation technique publique et d’une série détaillée de conférences publiques sur la supply chain. Ces conférences couvrent la technologie et la perspective de la chaîne d'approvisionnement de Lokad.

1.19 Le système de Lokad est-il conforme aux normes légales/locales pertinentes (par exemple, ISO) ?

Oui, Lokad opère en conformité avec les normes en vigueur. Cependant, Lokad fournit une optimisation prédictive de la chaîne d'approvisionnement, et en tant que tel, Lokad ne contrôle pas directement les opérations. Notre influence est largement indirecte, généralement par l'optimisation de l'allocation des ressources. Les normes ISO ne sont donc pas pertinentes ici (c'est-à-dire qu'elles ne sont pas applicables à Lokad).

2. Authentification

2.1 Appliquez-vous l'authentification pour tous les accès ?

Oui. L'accès aux données du client et/ou à toute capacité substantielle de la solution nécessite une authentification préalable. Cependant, par nécessité, certains points de contact ne sont pas soumis à l'authentification. Par exemple, l'accès à la page web de connexion ne nécessite pas d'authentification préalable (puisque l'authentification est le but même de cette page web de connexion). Retour à 1.12

Globalement, très peu de points d'extrémité techniques ne nécessitent pas d'authentification, et ils font généralement partie de l'instrumentation de la plate-forme (ex : un point d'extrémité utilisé uniquement pour vérifier qu'une machine est en marche). Il convient de noter que les points de terminaison non authentifiés n'exposent aucun type de données sensibles, et encore moins les données réelles du client.

2.2 Exigez-vous que tous les accès à distance soient sécurisés ? Appliquez-vous le protocole HTTPS pour les connexions web ?

Oui. Pour sécuriser les accès à distance, il faut disposer de l'authentification et de l'autorisation adéquates, ainsi que du cryptage du canal de transport lui-même, autant d'éléments que nous appliquons. Cette disposition concerne aussi bien les utilisateurs clients que les employés de Lokad. Même pour l'équipe d'ingénieurs de Lokad, il n'y a pas d'"accès local non sécurisé" à nos systèmes de production. Nous n'utilisons aucun type de "localité" de réseau comme contournement de sécurité.

2.3 Proposez-vous le SSO (single sign-on) ? Prenez-vous en charge Active Directory (AD) ?

Oui. Nous proposons le SSO (single sign-on) via le protocole SAML. Active Directory supporte SAML et peut être utilisé pour accéder à Lokad.

2.4 Prenez-vous en charge le protocole d'authentification OAuth2 ?

Oui. L'authentification à deux facteurs est réalisée par une authentification déléguée via SAML. Grâce à SAML, Lokad ne gère ni le premier ni le second facteur d'authentification, car ce processus est délégué.

2.5 Do you support OAuth2 authentication protocol?

Par défaut, Lokad supporte le protocole d'authentification SAML. Ce protocole est pris en charge par les principaux systèmes d'identité fédérés, comme Microsoft Office 365 ou Google Workspace. La difficulté de la prise en charge d'OAuth2 réside dans le fait qu'il ne s'agit pas réellement d'un "protocole d'authentification", mais d'un ensemble de directives très complètes visant à concevoir des "protocoles d'authentification" qui peuvent diverger de dizaines de façons.

Par conséquent, nous observons que les diverses implémentations d'OAuth2 qui existent dans le domaine des logiciels d'entreprise ont tendance à être largement incompatibles. Ainsi, si OAuth2 est une exigence absolue, par accord contractuel, nous pouvons prendre en charge une version spécifique d'OAuth2. Toutefois, cet arrangement nécessite des ressources dédiées pour assurer la compatibilité avec la variante OAuth2 telle qu'exploitée par l'entreprise cliente.

2.6 Prenez-vous en charge l'intégration LDAP?

Oui, par le biais d'un pont intergiciel superposant SAML à LDAP. Cependant, la majorité des systèmes d'identité fédérés supportant LDAP supportent également SAML. Nous recommandons donc d'utiliser directement SAML.

2.7 Appliquez-vous l'authentification à deux facteurs?

Pour les employés de Lokad, oui. Pour les employés du client, nous le recommandons fortement, mais nous ne pouvons pas l'imposer (l'authentification étant généralement déléguée par le SSO). Cette question est entre les mains du département informatique de notre client, pas les nôtres.

2.8 Pouvez-vous imposer une complexité minimale des mots de pass?

Oui, mais dans une mesure limitée. En ce qui concerne la sécurité des logiciels, il est désormais largement admis que la complexité minimale des mots de passe est une mauvaise pratique. Les utilisateurs finaux réagissent mal (et de manière prévisible) aux exigences trop strictes en matière de complexité des mots de passe, ce qui nuit au niveau général de sécurité. En outre, nous considérons ces demandes de mots de passe comme des "logiciels gonflants" qui augmentent la complexité d'un logiciel essentiel à la sécurité (la gestion des mots de passe), l'exposant ainsi (et la solution globale) à des risques excessifs. Voir https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/

Nous recommandons vivement d'utiliser le SSO au lieu des mots de passe/stratégies traditionnels. Grâce au SSO, il n'est pas nécessaire d'introduire un mot de passe dédié à Lokad.

2.9 Pouvez-vous imposer une rotation programmée des mots de passe?

Nous pourrions, mais nous ne le faisons pas. Tout comme la complexité minimale des mots de passe (see Authentification 2.8), la rotation programmée des mots de passe est désormais largement reconnue comme une mauvaise pratique de sécurité logicielle. Les utilisateurs finaux réagissent mal (et de manière prévisible) aux rotations programmées des mots de passe. La sécurité peut même s'affaiblir car les employés n'apportent souvent que des modifications mineures aux mots de passe (afin de réduire la charge cognitive associée aux rotations fréquentes). Comme pour la complexité minimale des mots de passe, nous considérons la rotation des mots de passe comme un "bloatware" qui augmente la complexité d'un logiciel essentiel à la sécurité (la gestion des mots de passe), l'exposant ainsi (et la solution globale) à des risques excessifs. Voir https://www.sans.org/blog/time-for-password-expiration-to-die/.

2.10 Utilisez-vous les hash et les salts pour vos mots de passe?

Oui. Nous utilisons "scrypt" comme fonction de hachage de mot de passe. En règle générale, nous recommandons vivement d'utiliser le SSO au lieu d'utiliser les mots de passe/stratégies traditionnels. Grâce au SSO, il n'est pas nécessaire d'introduire un mot de passe dédié à Lokad.

2.11 La solution de Lokad active-t-elle le CAPTCHA après un nombre déterminé d'échecs d'authentification ?

Oui, par délégation d'authentification (via SSO). Si les CAPTCHA constituent une approche intéressante pour atténuer quelques vecteurs d'attaque, ils entrent dans la catégorie des composants logiciels qu'il vaut mieux laisser entièrement en dehors du champ d'application d'une solution d'optimisation de la chaîne logistique telle que celle de Lokad. En outre, la valeur ajoutée des CAPTCHA dans le contexte des logiciels d'entreprise est moins évidente que pour les logiciels B2C, notamment les logiciels gratuits.

2.12 Disposez-vous d'une politique générale de sécurité pour les mots de passe ? Disposez-vous d'un processus pour le faire respecter ?

Oui. Notre politique générale de sécurité en matière de mots de passe est "pas de mots de passe". Nous recommandons vivement le SSO, qui supprime la nécessité d'introduire des mots de passe dédiés à Lokad.

2.13 Centralisez-vous la gestion des utilisateurs?

Oui. Lokad dispose de sa propre gestion centralisée des utilisateurs pour la solution que nous exploitons. Ce sous-système a été mis en place par Lokad et couvre également les accès des employés de Lokad - y compris nos équipes d'ingénieurs.

2.14 Autorisez-vous les comptes utilisateurs génériques/partagés ?

Non. Lokad met en place une relation de 1 à 1 entre les employés et les utilisateurs (comme le montre la plateforme Lokad). Nous déconseillons fortement l'utilisation de comptes d'utilisateurs partagés. En fait, l'une des raisons pour lesquelles nous ne facturons pas par utilisateur est d'éviter d'inciter nos clients à partager des comptes d'utilisateur entre leurs employés. Cependant, il y a quelques cas où il est acceptable d'avoir un compte utilisateur qui n'a pas d'employé homologue. Cela se produit généralement pour le service "robot upload" côté client chargé de pousser les données vers Lokad. Dans le cadre de notre RBAC (Role-Based Access Control), nous avons un rôle dédié (appelé "uploader") qui fournit des droits minimaux pour ce cas d'utilisation unique.

2.15 Proposez-vous des connexions VPN sécurisées ?

Non. Les connexions des utilisateurs finaux sont utilisées par le biais de canaux cryptés (généralement TLS).

2. Permettez-vous aux utilisateurs de se connecter à partir de plusieurs appareils?

Oui, dans certaines limites. En général, la limite supérieure est de 6 appareils par utilisateur (nous ne facturons pas l'autorisation de plusieurs appareils). Chaque session est limitée à une seule adresse IP. Lokad se réserve toutefois le droit de modifier cette limite afin de contrer certaines menaces et/ou abus potentiels.

2.17 La solution a-t-elle la capacité de verrouiller et/ou de déconnecter de force un utilisateur (s'il est considéré comme malveillant) ?

Oui. Cette fonctionnalité nécessite des droits d'accès "Propriétaire" dans le compte Lokad.

2.18 Le système déconnecte-t-il automatiquement un utilisateur inactif après un certain temps d'inactivité ?

Oui, bien que "l’inactivité" ne soit pas le facteur le plus important. Lokad déconnecte automatiquement les utilisateurs après un laps de temps déterminé. Les utilisateurs ne peuvent pas retarder la déconnexion en étant "actifs" ; une fois le temps spécifié écoulé, les utilisateurs doivent se réauthentifier.

3. Autorisation

3.1 La solution fournit-elle des droits d'accès à granularité fine ?

Oui. La solution Lokad comprend un sous-système RBAC (Role-Based Access Control) granulaire. Cela permet au client de contrôler quels "Projets" et "Fichiers" sont accessibles (et par qui) dans le compte Lokad. Le RBAC dispose de sa propre interface utilisateur web (tableau de bord). Il est disponible pour tous les utilisateurs ayant la désignation "Propriétaire" dans le compte Lokad. Pour en savoir plus, consultez notre documentation sur les rôles et les autorisations des utilisateurs.

3.2 La solution permet-elle au client de configurer l'accès conformément au principe du moindre privilège (PoLP)?

Oui. La solution Lokad comprend un sous-système RBAC (Role-Based Access Control) granulaire qui peut être utilisé pour mettre en œuvre le PoLP. Toutefois, grâce à Envision (le DSL de la solution), Lokad va beaucoup plus loin que la plupart des logiciels d'entreprise en ce qui concerne ce principe.

Grâce à Envision, Lokad a éliminé des suites entières de privilèges de systèmes qui ne sont tout simplement pas pertinents pour l'optimisation de la chaîne d'approvisionnement. Ce qui reste est simplifié, mais toujours largement configurable. De même, le système de fichiers sur mesure proposé par Lokad permet d'éliminer des groupes entiers de privilèges système inutiles.

3.3 Appliquez-vous les droits d'accès du moindre privilège ?

Oui, bien que ce qui constitue le privilège "le moins acceptable" soit finalement décidé par nos clients. Lokad ne peut pas déterminer unilatéralement qui bénéficie d'une désignation "Propriétaire" au sein du personnel de notre client. Toutefois, nous pouvons fournir des conseils à cet égard. En pratique, pour nos clients "gérés" - ceux qui sont soutenus par l'équipe de scientifiques de la chaîne d'approvisionnement de Lokad - nous clarifions (par écrit) l'organisation souhaitée et les droits d'accès correspondants.

3.4 La solution a-t-elle la capacité de masquer une entité particulière du système aux utilisateurs désignés ?

Oui. Il s'agit d'une forme de mise en œuvre du PoLP qui est traitée dans les réponses 3.1, 3.2 and 3.3

3.5 Avez-vous mis en place une classification des données (niveaux de sensibilité), et des contrôles ajustés en fonction de cette classification ?

Oui. En tant qu'élément intégré, Lokad restreint, par défaut, toutes les données administratives (telles que la liste des utilisateurs d'un compte) aux "propriétaires" du compte. Cette désignation est la plus élevée et la plus privilégiée des RBAC (Role-Based Access Control). Toutes les autres données du compte Lokad peuvent être segmentées selon une classification de sensibilité définie par l'utilisateur. Cette classification définie par l'utilisateur peut être appliquée à la fois aux données originales (telles que téléchargées par le client) et aux données transformées (le résultat des transformations de données effectuées au sein de la plateforme Lokad).

Pour plus d'informations sur les contrôles d'accès et les désignations, veuillez consulter les réponses 3.1, 3.2 and 3.3.

3.6 La solution peut-elle autoriser ou bloquer des utilisateurs/rôles/transactions en temps réel ?

Oui, bien que "en temps réel" nécessite une clarification dans le contexte d'un système informatique distribué (comme la solution Lokad). Les mises à jour du RBAC (Role-Based Access Control) se font de manière synchrone, ce qui signifie que les mises à jour sont actives en quelques secondes (généralement moins). Il n'y a pas de retard notable (comme une période d'attente d'une heure ou d'une journée). Retour à 4.3 Retour à IT 2.11

Quant à l'interruption des transactions, elle n'est pas pertinente car Lokad ne dispose pas d'une base de données transactionnelle. Cela dit, Lokad peut interrompre des opérations asynchrones de longue durée (appelées "Project runs" dans Lokad). Lorsqu'une interruption est déclenchée, elle garantit immédiatement (de manière synchrone) que le traitement n'affectera pas le système, par exemple en écrasant des fichiers. Toutefois, l'arrêt du traitement est asynchrone et prend généralement effet dans les 20 secondes.

3.7 La solution limite-t-elle l'accès aux informations personnelles identifiables (IPI) aux seuls utilisateurs disposant du bon niveau d'autorisation ?

Oui, bien que la solution ne soit pas destinée à contenir des données PII (au-delà des identifiants d'authentification des employés ayant accès à la solution). C'est le cas tant pour Lokad que pour le client. Dans la solution, seuls les employés ayant une désignation "Propriétaire" ont accès à la liste des utilisateurs. À des fins d'optimisation de la chaîne d'approvisionnement, Lokad n'a pas besoin (ou ne bénéficie pas) des données PII, et nous avons des stipulations contractuelles à cet effet (expliquées dans les Practiques 1.4 & Practiques 1.5).

Pour plus d'informations sur les contrôles d'accès et les désignations, veuillez consulter les réponses 3.1, 3.2 and 3.3.

3.8 La solution permet-elle aux filtres de recherche de données d'informations personnelles identifiables (PII) d'interdire les recherches par caractères génériques ?

Oui. Cependant, un utilisateur ayant la désignation "Propriétaire" dans un compte Lokad peut accéder à tous les utilisateurs (y compris le personnel du client) qui sont autorisés à accéder au compte. Lokad ne peut pas restreindre cette capacité car nos clients doivent être en mesure de vérifier, dans son intégralité, la liste des utilisateurs ayant accès à leur propre compte.

4. Gestion des données

4.1 Où hébergez-vous et traitez-vous les données?

Notre plateforme SaaS (Software as a Service) est hébergée à 100% sur Microsoft Azure ; plus précisément, elle est hébergée dans le centre de données Europe North Microsoft Azure (basé à Dublin). Nos sauvegardes sont stockées dans le centre de données Microsoft Azure Europe Ouest (basé à Amsterdam). En cas de défaillance majeure du centre de données, nous disposons de plans d'urgence pour migrer la plateforme vers Dublin. Depuis notre migration vers Microsoft Azure en 2010, nous n'avons jamais été confrontés à cette situation. Toutes les données de nos clients résident en Europe, où elles resteront même en cas de panne majeure d'un centre de données.

4.2 Qui est propriétaire des données ?

Nos clients restent les seuls propriétaires de toutes les données qu'ils téléchargent sur Lokad. Nos clients restent également les seuls propriétaires de toutes les données qu'ils génèrent, via leur compte Lokad, sur la plateforme Lokad. Lokad n'utilise pas en interne les données des clients à d'autres fins que celles qui contribuent directement à la réalisation de la ou des tâches que nos clients nous ont confiées. Lokad ne (re)vend pas l'accès aux données de ses clients à des tiers. Lokad ne partage pas l'accès aux données des clients, à l'exception des quelques hébergeurs qui contribuent directement à la tâche à accomplir (ex : location de machines virtuelles d'une plateforme de cloud computing pour exécuter les calculs demandés par nos clients).

4.3 La gestion de la base de données est-elle assurée en interne ou en externe ?

La gestion de la couche de données de Lokad est assurée par les équipes d'ingénieurs de Lokad. Comme nous l'avons déjà mentionné, la plate-forme centrale de Lokad ne comprend pas de base de données transactionnelle (voir Autorisation 3.6), car Lokad utilise plutôt un magasin d'événements. Cette boutique événementielle est mise en œuvre et exploitée entièrement par Lokad.

4.4 La solution a-t-elle la capacité de passer d'une base de données RDBMS (PostgreSQL, Oracle, MySQL) à une base de données non-SQL (Cosmos) ?

Théoriquement, oui, mais c'est discutable car la solution Lokad n'utilise pas de RDMBS. La couche de persistance des données de la solution Lokad s'appuie sur un magasin d'événements et un magasin clé-valeur. Cette approche diffère sensiblement de la conception CRUD (Create-Read-Update-Delete) que l'on trouve couramment dans les logiciels d'entreprise. Étant donné que Lokad est une solution SaaS, nous assumons l'entière responsabilité de la persistance des données et de la compatibilité future (pour garantir que les anciennes données restent accessibles).

4.5 Des tiers sont-ils impliqués dans l'exploitation de la solution?

Oui, notamment la plateforme sous-jacente de cloud computing utilisée par Lokad - Microsoft Azure. La liste des tiers impliqués dans le fonctionnement de la solution est très courte et se limite à l'hébergement d'infrastructures de niveau inférieur. Lokad ne fait pas appel à des tiers pour développer, administrer ou exploiter sa propre solution. En particulier, nos équipes d'ingénieurs et nos équipes de support technique sont internes.

4.6 Est-ce que vous séparez les couches (réseau, serveurs et applications)?

Oui, mais la gestion de bas niveau des réseaux et des serveurs est déléguée à la plateforme sous-jacente de cloud computing utilisée par Lokad - Microsoft Azure. Ainsi, la séparation des couches réseau et serveur se situe en grande partie en dehors du périmètre géré par Lokad. Dans la solution Lokad, nous limitons fortement les privilèges accordés aux couches applicatives afin qu'elles ne puissent pas administrer leur propre infrastructure (ex : les couches applicatives n'ont pas d'accès en écriture à la gestion du DNS).

4.7 Disposez-vous d'un processus permettant de garantir la suppression permanente des données?

Oui, bien que cela puisse prendre plusieurs semaines pour accomplir toutes les étapes. Le processus consiste à faire une demande écrite officielle - émise par une partie autorisée au sein de l'organisation cliente - pour que les données correspondantes soient définitivement supprimées. En pratique, les dispositions spécifiques à ces demandes sont incluses dans l'accord contractuel entre Lokad et ses clients. Les données seront d'abord supprimées de notre système de production primaire, puis de notre système de sauvegarde. Cette dernière étape est à l'origine de la relative "lenteur" de l'opération. Il s'agit d'un choix de conception, car une fois que les données sont supprimées de notre système primaire, elles ne sont plus accessibles (sauf par le biais de processus extraordinaires de reprise après sinistre).

Par défaut, la solution Lokad garantit que toutes les opérations de suppression standard sont des suppressions douces (c'est-à-dire qu'elles ne sont pas permanentes). Cette conception est nécessaire pour éviter des catégories entières de problèmes de sécurité, comme la suppression accidentelle de données par un employé du client ou la suppression malveillante par un attaquant. En outre, un processus de suppression permanente intentionnellement lent est nécessaire pour atténuer les attaques d'ingénierie sociale, comme un scénario dans lequel un attaquant se fait passer pour un employé d'un client.

4.8 La solution a-t-elle la capacité d'effacer les données de manière douce?

Oui. La solution Lokad adopte une conception d'approvisionnement par événement. Ainsi, tout est versionné par défaut, aussi bien les entrées de l'utilisateur que les changements apportés au système de fichiers de Lokad. Ainsi, toutes les suppressions de logiciels sont des suppressions logicielles, et celles-ci peuvent être retracées et annulées, comme on le souhaite.

4.9 Offrez-vous un accès direct à la base de données?

Oui, dans le sens où le système de fichiers - qui fait partie de la solution Lokad - est accessible par des protocoles tels que FTPS et SFTP. Cet accès est étendu, dans la mesure où toutes les données utilisées en entrée ou produites en sortie sont stockées dans ce système de fichiers.

Cependant, comme Lokad ne dispose pas d'une base de données transactionnelle, il n'y a pas de base de données sous-jacente qui pourrait être rendue "accessible". L'équivalent le plus proche dans l'architecture de Lokad est notre magasin d'événements et nous n'offrons pas d'accès direct au event stream (flux d'événements). Toutefois, des dispositions pourraient être prises dans l'accord contractuel si un client devait demander certaines extractions spécifiques de ce flux d'événements (en supposant qu'il existe un cas d'utilisation valide).

4.10. Comment la solution intègre-t-elle les données externes?

La solution peut utiliser plusieurs protocoles pour intégrer des données externes, notamment FTPS et SFTP. Une interface utilisateur web est également disponible pour télécharger manuellement des fichiers. La solution Lokad peut intégrer toutes les données raisonnablement tabulaires. Pour en savoir plus sur les capacités d'intégration externe de données de Lokad, voir Go to IT Perspective on Lokad 2.15.

4.11 Le système a-t-il la capacité de gérer la "saisie des données de changement (CDC)" à partir de flux de données en temps réel?

Oui, dans le cadre d'un accord contractuel spécifique avec le client. La saisie des données de changement est un modèle de conception logicielle - et non une norme de données ou un protocole de transfert de données spécifique - et les attentes en matière de "temps réel" peuvent varier d'une latence inférieure à la milliseconde à une latence inférieure à la minute. Les caractéristiques de ce domaine doivent être évaluées du point de vue de la chaîne d'approvisionnement. D'après notre expérience, les flux de données en temps réel sont rarement pertinents pour résoudre les problèmes de la chaîne d'approvisionnement.

4.12 Toutes les données de la solution peuvent-elles être exportées?

Oui, toutes les données accessibles par le système de fichiers du compte Lokad peuvent être exportées par des protocoles tels que FTPS ou SFTP.

4.13 La solution offre-t-elle des outils pour exporter les données?

Oui, la solution Lokad offre un DSL (langage spécifique au domaine) appelé Envision, adapté à l'analyse de la chaîne d'approvisionnement. Envision offre des capacités étendues pour reformater les données dans le compte Lokad.

4.14 Quel sera le format des données exportées?

La plateforme Lokad prend en charge tous les formats de tableaux courants, y compris CSV et XLS (Microsoft Excel). La plate-forme prend en charge de nombreuses options concernant le format des chiffres, des dates, des délimiteurs, de l'encodage du texte, des en-têtes, etc.

4.15 La solution dispose-t-elle d'un système de cryptage transparent des données (TDE) pour les informations personnelles identifiables (PII) dans le stockage mobile et dorsal?

Le cryptage transparent des données est utilisé à la fois sur le stockage dorsal de Lokad (par le biais du cryptage Azure Storage pour les données au repos) et sur les appareils émis par Lokad (par le biais de BitLocker). Lokad ne stocke pas de PII sur les appareils sans TDE activé.

4.16 Tous les mots de passe et les secrets utilisés dans l'application sont-ils cryptés et non accessibles en format texte libre dans le code source, les fichiers de configuration, les paramètres de construction, etc?

Oui. Tous les secrets de niveau plate-forme sont stockés dans Key Vault, un service proposé par Microsoft Azure. Les mots de passe des utilisateurs sont salés et hachés en interne avec Scrypt, conformément aux pratiques standard.

4.17 La solution a-t-elle la capacité de restreindre le téléchargement de fichiers en fonction de leur type et de leur taille, et de rechercher les contenus malveillants?

Oui, dans une certaine mesure. En ce qui concerne la taille des fichiers, l'optimisation de la chaîne d'approvisionnement nécessite souvent le traitement de fichiers volumineux. Ces tailles de fichiers reflètent l'extraction des données commerciales historiques que nous traitons en fin de compte (ex : historique des commandes de vente). Compte tenu de cette réalité, la plateforme Lokad prend en charge des fichiers d'une taille maximale de 100 Go.

En ce qui concerne le type de fichier, nous disposons d'une liste blanche des extensions connues et des formats attendus. Dans l'éventualité d'un cas d'utilisation valide, ce paramètre pourrait être ajusté. Cet ajustement serait reflété dans notre accord contractuel.

En ce qui concerne la capacité à rechercher des contenus malveillants, Lokad ne dispose pas de cette fonctionnalité. Notre solution met l'accent sur le partage du contenu "généré par la plateforme". En outre, la conception même que nous avons adoptée garantit que les fichiers générés dans Lokad sont sûrs, même si les fichiers d'entrée ne le sont pas. À l'inverse, de par sa conception, la solution Lokad ne met pas l'accent sur le partage du contenu téléchargé par l'utilisateur via Lokad.

4.18 Quelle est la période de conservation des données recommandée?

Lokad est un SaaS, ainsi, nous portons la responsabilité de choisir la durée de conservation des données appropriée, et cette durée varie en fonction du type de données. Les données historiques transactionnelles, transmises à Lokad par le client via le pipeline d'extraction de données, sont généralement conservées pendant toute la durée du service Lokad. En effet, les données historiques méritent généralement d'être conservées pour des périodes arbitrairement longues (en dehors des limites du service Lokad). À l'autre bout du spectre, il y a les données d'instrumentation, qui reflètent la performance fine de notre plateforme. Ces données ne sont utiles que pour dépanner les ralentissements inattendus de la plateforme. Ces données sont extrêmement granulaires et ne sont généralement pas conservées plus de quelques semaines.

4.19 Fournissez-vous une documentation sur la structure des données?

Oui, dans le cadre du "Manuel de procédure commune". Il convient de noter que Lokad n'utilise pas de base de données relationnelle, contrairement à la plupart des logiciels d'entreprise. Au lieu de cela, nous utilisons un paradigme d'approvisionnement en événements. Cependant, les structures de données d'intérêt (pour la société cliente) ne sont pas situées dans la source de l'événement, mais dans les fichiers plats produits par les scripts Envision au sein de la plateforme Lokad. Ces fichiers plats sont conçus pour répondre aux exigences spécifiques de l'entreprise cliente. La documentation de ces fichiers est incluse dans le "Manuel de procédure commune", qui est l'un des produits livrables dans une initiative Lokad typique.

5. Journalisation et suivi

5.1 Proposez-vous des journaux d'accès (utilisateur, date, date de la dernière connexion, etc.)?

Oui. Lokad fournit des journaux d'accès formatés en fichiers CSV. Pour l'instant, ces journaux peuvent être demandés au personnel de soutien de Lokad. L'extraction du journal sera placée dans le compte Lokad à un endroit accessible uniquement aux utilisateurs ayant la désignation "Propriétaire". Nous prévoyons d'introduire une méthode d'accès plus directe - via une interface web dédiée - à la piste d'audit complète qui existe déjà dans le back-end de la plateforme Lokad.

5.2 Centralisez-vous les logs de tous les composants de la solution?

Oui. Le concept d'approvisionnement en événements de Lokad centralise non seulement les journaux, mais aussi tous les changements d'état qui se produisent dans la solution. Les journaux, ainsi que les autres changements d'état, sont centralisés dans une petite collection de flux d'événements, gérés par le même magasin d'événements. En interne, les journaux qui n'ont pas d'impact sur l'état de la solution sont séparés de ceux qui en ont.

D'un point de vue purement technique, certains journaux liés aux performances ne sont volontairement pas centralisés dans le magasin d'événements. Ces journaux comprennent des mesures de performance à grain fin, telles que celles produites par l'instrumentation de profilage de performance interne de Lokad (ex : combien de millisecondes sont passées pour chaque appel de fonction pendant l'exécution d'un script Envision). Ces journaux de performance ne contiennent rien qui puisse être qualifié de matériel "lié à la sécurité".

5.3 Consignez-vous les modifications et les opérations effectuées dans l'application ? Gardez-vous trace de toutes les transactions?

Oui. En raison de la conception de Lokad, tout est enregistré par nécessité. En fait, la solution elle-même est la somme de l'ensemble des événements enregistrés dans la solution. La journalisation est donc un aspect fondamental de l'architecture de la solution. Cette conception de l'approvisionnement en événements empêche l'omission accidentelle d'un journal qui reflète un changement d'état. Dans un tel cadre d'approvisionnement en événements, il n'y a pas de transactions, du moins pas dans le sens habituel d'une base de données transactionnelle (ex : MySQL, Oracle, etc.). Ces transactions sont remplacées par des événements qui contiennent toutes les informations associées à un changement d'état. Retour à 8.11

5.4 Normalisez-vous les formats des journaux des différents composants à des fins médico-légales?

Oui. Les "journaux", du point de vue de l'audit et/ou de la sécurité, sont les transformations des événements sous-jacents. Les événements sont techniquement des objets sérialisés. Afin d'obtenir les journaux, la solution Lokad convertit et compile ces événements en fichiers CSV. Nous normalisons les formats de date, les formats de nombre et les identifiants d'utilisateur qui sont utilisés dans l'extraction CSV.

5.5 Proposez-vous des exportations de journaux à un tiers via un protocole de requête?

Oui, dans le cadre d'un accord contractuel avec le client.

5.6 Faites-vous le suivi de toutes les exceptions lancées dans votre solution?

Oui. Le concept d'approvisionnement par événement de Lokad nous permet de suivre toutes les exceptions lancées dans notre solution et de reproduire les conditions qui ont conduit au problème en premier lieu. Une fois identifiées, l'équipe d'ingénieurs de Lokad élimine toutes les exceptions observées. Nous avons mis au point des outils dédiés à cette fin spécifique et nous conservons un nombre très limité d'exceptions non corrigées.

5.7 La solution a-t-elle la capacité de surveiller la santé des différents composants/services en temps réel?

Oui. Nos sous-systèmes ont été conçus avec des points de surveillance dédiés aux contrôles de santé. Nous disposons d'outils de surveillance, accessibles uniquement - à partir de janvier 2023 - aux équipes d'ingénieurs de Lokad, qui consolident en permanence les informations mises à disposition par ces terminaux de surveillance.

Comme mentionné précédemment, "en temps réel" est assez vague lorsqu'il s'agit de systèmes distribués. À des fins de surveillance de l'état du système, la latence attendue varie de quelques secondes à une minute (environ).

5.8 La solution a-t-elle la capacité d'intégrer des outils de surveillance tiers ? La solution prend-elle en charge SNMP ou JMX, ou la possibilité d'envoyer des événements SNMP et JMX à des solutions de surveillance tierces?

Oui, dans le cadre d'un accord contractuel spécifique.

5.9 La solution a-t-elle la capacité de surveiller les travaux par lots qui n'ont pas démarré à la date prévue et de surveiller leur fin?

Oui. La solution Lokad dispose de son propre planificateur de tâches interne (appelé "Runflow") pour orchestrer les tâches de longue durée au sein de la plateforme Lokad - généralement l'exécution de scripts Envision. Ce planificateur peut être configuré, par le biais d'une interface utilisateur Web, pour spécifier un calendrier et un délai d'exécution pour toute séquence de travail.

5.10 La solution a-t-elle la capacité de produire des alertes proactives ? A-t-il la capacité de corréler et d'analyser les erreurs, puis de prendre des mesures proactives ?

Oui. Runflow, le planificateur de tâches de la solution, peut alerter le client/Lokad qu'une séquence d'exécution en cours est en retard. L'alerte peut être envoyée avant l'achèvement de la séquence. La solution Lokad offre des capacités étendues grâce à Envision (son DSL) pour analyser et auto-diagnostiquer les situations afin de prendre des mesures proactives. Bien que la plate-forme Lokad offre cette capacité, il faut encore qu'un ingénieur mette en œuvre - par le biais d'Envision - la logique réelle, car les situations de la chaîne d'approvisionnement qui sont qualifiées d'" erreurs " peuvent varier.

5.11 La solution dispose-t-elle de capacités de conservation des données d'audit ? Les données sont-elles archivées et purgées dans une base de données MIS pour auditer l'activité des utilisateurs?

Oui. Grâce à sa conception d'approvisionnement en événements, la solution Lokad préserve une piste d'audit étendue, bien plus importante que celle obtenue par des conceptions plus courantes qui exploitent généralement une base de données transactionnelle au lieu d'un magasin d'événements. La solution Lokad n'isole pas un système d'information de gestion (SIG) comme un sous-système distinct. En effet, le flux d'événements est la piste d'audit. Plus généralement, Lokad conserve les données de production pendant la durée de la prestation avec le client. À la fin du service, qui dépend des conditions contractuelles négociées, les données du client sont purgées, bien que la suppression finale dans le système de sauvegarde puisse avoir lieu quelques mois après la fin du contrat.

5.12 Votre système intègre-t-il un mécanisme d'autocontrôle (technique et fonctionnel)?

Oui, la plateforme Lokad intègre de multiples mécanismes d'autocontrôle à différents niveaux.

La plateforme hébergée dans le nuage est contrôlée par les équipes d'ingénierie logicielle de Lokad. Comme la plateforme Lokad est multi-tenant, cette surveillance est en grande partie effectuée dans une optique "système", en s'assurant que les capacités de la plateforme (y compris son profil de performance) sont conformes aux normes. Nous avons conçu notre propre couche d'instrumentation à cette fin. Le suivi "fonctionnel" est généralement spécifique au client car il dépend des spécificités de la chaîne d'approvisionnement donnée. Ce suivi est généralement assuré par les équipes de scientifiques de la chaîne d'approvisionnement (les ingénieurs fournis par Lokad), conformément à l'accord contractuel.

Les spécialistes de la chaîne d'approvisionnement de Lokad se spécialisent généralement dans une catégorie particulière de comptes clients (par exemple, l'aérospatiale). Ils créent des instruments de surveillance sur mesure en utilisant le compte Lokad. Ce contrôle consiste à s'assurer que les chiffres fournis par Lokad sont corrects, non seulement d'un point de vue technique, mais aussi du point de vue de l'activité du client.

6. Les employés

6.1 Les employés ont-ils des NDA (accords de non-divulgation)?

Oui, tous les employés de Lokad sont soumis à une clause NDA dans leur contrat de travail.

6.2 Les employés suivent-ils une sensibilisation à la sécurité et une formation à la sécurité?

Oui, une sensibilisation et une formation à la sécurité sont fournies aux employés de Lokad qui sont en contact avec des données confidentielles et/ou des systèmes d'ingénierie qui sont en contact avec des données confidentielles. Pour plus d'informations sur ce point, la conférence Cybersecurité et Supply Chain est consacrée aux scientifiques de la chaîne d'approvisionnement - les personnes qui manipulent les données confidentielles des clients.

6.3 Qui a accès aux données des clients chez Lokad?

Le client définit explicitement une liste d'utilisateurs qui ont accès à son compte Lokad. Ces utilisateurs, en fonction de leurs droits d'accès tels que configurés dans le compte Lokad, peuvent avoir accès à différentes classes de données du client. Il existe une application web au sein de la solution Lokad dédiée à la gestion des permissions (nommée "Hub").

Du côté de Lokad, pour chaque compte client, il y a une brève liste des employés qui ont accès. Avant tout, cette liste comprend les scientifiques de la chaîne d'approvisionnement (les ingénieurs fournis par Lokad) qui mettent en œuvre et entretiennent la solution d'optimisation de la chaîne d'approvisionnement. Ces scientifiques de la chaîne d'approvisionnement sont censés accéder aux données du client sur une base quotidienne. En interne, Lokad limite l'accès aux comptes clients aux seuls scientifiques de la chaîne d'approvisionnement affectés à ces comptes. Par exemple, le scientifique de la chaîne d'approvisionnement A ne peut pas accéder au compte client B à moins que A n'ait été explicitement désigné pour gérer ce compte (comme convenu avec le client).

Ensuite, cette liste comprend l'équipe d'ingénieurs chargée de l'administration du système de notre plateforme. En règle générale, l'accès direct aux données des clients est peu fréquent et limité à l'examen des situations signalées soit par les clients eux-mêmes, soit par les scientifiques de la chaîne d'approvisionnement qui les soutiennent. Lokad ne partage pas l'accès aux données des clients avec des tiers, à l'exception de la plateforme de cloud computing.

6.4 Comment sécurisez-vous les postes de travail des employés?

À l'exception de l'équipe d'ingénierie logicielle, les employés de Lokad fonctionnent sans privilèges administratifs sur les appareils fournis par l'entreprise. Tous les postes de travail sont configurés avec un cryptage complet du disque afin de se protéger contre le vol de données qui pourrait être causé par la perte, le vol ou la confiscation du matériel à des tiers (par exemple, pour des réparations).

Les postes de travail utilisés par nos employés ne contiennent pas les données de nos clients. En fonction de la tâche à accomplir, un employé peut télécharger quelques feuilles Excel sur sa machine - pour faire une présentation, par exemple - mais notre politique est de garder strictement toutes les données des clients en sécurité dans le cloud.

6.5 Comment sécurisez-vous les smartphones des employés?

Les employés de Lokad ne disposent pas de smartphones fournis par l'entreprise. Les données non critiques, comme les rappels de calendrier, peuvent être poussées via des appareils personnels (non émis par l'entreprise), mais les smartphones, comme les postes de travail, ne contiennent pas les données de nos clients.

6.6 Utilisez-vous un antivirus?

Oui, nos postes de travail sont équipés de Microsoft Defender, conformément aux configurations de Microsoft Windows 10+. Nous n'avons pas d'autre antivirus que Microsoft Defender, mais nous pensons que cette catégorie d'outils a tendance à faire plus de mal que de bien (en termes de sécurité informatique). À titre d'anecdote, le piratage de SolarWinds en 2020 est considéré comme l'une des plus grandes catastrophes de tous les temps en matière de sécurité informatique, et il a été causé par un logiciel qui était censé améliorer la sécurité en premier lieu. Plus généralement, presque tous les logiciels destinés à des fins de sécurité nécessitent des privilèges système assez élevés. Par conséquent, ces logiciels deviennent leurs propres vecteurs d'attaque. Notre point de vue sur la sécurité informatique est que moins est plus, et que l'ajout d'éléments technologiques très complexes dans notre paysage applicatif le rend presque invariablement moins sûr, et non plus sûr.