Accès prestataire

Bonjour,

je travaille dans le milieu médical et je rencontre actuellement un problème avec un éditeur de logiciel.

Auparavant l’établissement de santé était géré par un autre service informatique que le mien qui laissait l’éditeur accéder à l’un de nos serveurs via un VPN IPsec. Notre DSI qui est à cheval sur la sécurité refuse que nos prestataires aient une connexion constante sur nos infra et qu’ils puissent intervenir à tout moment sans que nous le sachions.

Afin que nos éditeurs puissent néanmoins corriger les bugs de leurs produits, les mettre à jour ou encore modifier des paramètres ou créer de nouveaux utilisateurs nous leur mettons à disposition un accès temporaire sur une machine de rebond sur simple demande par téléphone ou par mail.

Tous nos éditeurs ont bien compris que la sécurité était un point crucial et on accepté nos règles, sauf cet éditeur qui désormais, refuse de traiter les demandes des praticiens. Si bien que l’un d’eux arrivé récemment ne dispose même pas de compte pour travailler car l’éditeur refuse d’utiliser l’accès que nous lui donnons et exige que nous rétablissions leur VPN.

J’ai beau leur expliquer qu’un VPN connecté en performance n’est ni plus ni moins qu’une porte ouverte constamment sur notre infra informatique ils ne veulent rien entendre.

Puisqu’il y a de nombreux professionnels du milieu informatique qui passent ici, j’aimerais avoir des conseil sur la façon de régler ce problème.

Cela concerne tout de même le milieu médical, la prise en charge de patients et donc leur santé. Quand on sait qu’actuellement les données de santé sont justement une des cibles privilégié des hackeurs à cause justement des nombreuses malfaçons qui existent dans les infra IT des groupes et établissements de santé.
Il y a de quoi s’inquiéter de voir qu’un éditeur, spécialisé justement dans les logiciels de santé se contrefiche de la sécurisation des données mais surtout d’impacter directement la prise en charge des patients.

A quels organismes pourrais-je m’adresser pour faire décoincer la situation ?

Existe-t-il une démarche, une procédure à suivre pour obliger l’éditeur à faire son travail, ? D’autant plus que nous lui payons une maintenance pour ce serveur.

Bonjour @Crowbar.

:warning: Ce site est en accès libre à tout l’internet, mais, même s’il était en accès restreint, si j’étais toi, je n’écrirais pas en clair le nom de sociétés ou de personnes qui risquent d’être utilisés d’une manière à laquelle tu ne t’attends pas, notamment parce que cela pourrait aussi déplaire aux dites sociétés.
Et les informations que tu donnes peuvent aussi dévoiler ton identité.
De plus, tu viens d’ailleurs de divulguer des informations qui pourraient potentiellement guider un vecteur d’attaque informatique, ne serait-ce que par social engineering, tu viens d’indiquer une cible.

C’est un avertissement de ma part qui se veut bienveillant, ce n’est pas une attaque personnelle.

Désolé, mais un adminsys se doit d’être paranoïaque au moins à ce niveau, selon moi : il faut en dire le moins possible. [ EDIT @ 2021-02-13T16:11:49+0100 : Dans ce cas précis, le nom de la société, le domaine du logiciel, ton domaine professionnel, le type d’utilisateurs concernés sont superflus. ]

Ok! Cela dit, ce qui suit n’est peut-être pas une réponse directe, mais comme tu poses heureusement une question ouverte, j’essaye de prendre un peu de recul et mieux comprendre : Si j’ai bien compris, des modifications sont faites sur un environnement de production par les intervenants extérieurs, exact?

Si c’est le cas, puisque le DSI semble soucieux de la gestion des risques, j’imagine que ces mêmes modifications sont faites préalablement sur un environnement de recette ou pré-production?

Si c’est le cas, mon point est le suivant : Une manière de rapprocher les points de vues serait peut-être de laisser un accès VPN aux externes sur un environnement de recette ou de pré-production, qui en suite serait utilisé pour mettre à jour l’environnement de production par d’autres personnes - ou automatiquement.

Qu’en dis-tu?

[EDIT @ 2021-02-13T12:55:32+0100
Pour être plus clair, les externes n’auraient un accès VPN que sur la pré-prod, et ensuite soit automatiquement, soit par des internes, les mises à jour/modifications seraient effectuées sur la production.
Et implicitement, pour moi la pré-prod est complètement isolée de la production en termes d’accès.]

@Crowbar Whasssup Bro? :thinking:

On est là sur un différent commercial. À priori ils ne sont pas les seuls à pouvoir exercer ce genre de prestation, me trompe-je ? S’ils sont incapables de seulement penser à évoluer, je pense que la meilleure solution est d’aller voir ailleurs, sinon c’est se préparer des « Nervous Breakdown » à tenter de les faire changer de méthodes. En toute première chose, privilégier la demande avec pour réponse négative un changement de crèmerie. Sérieusement, dans le domaine médical, ne pas pivilégier la sécurité est pour le moins meurtrier !

Je comprends que ça puisse leur déplaire mais je ne fais que relater leurs exigences, rien de plus.

Par contre là où tu as raison c’est que c’est une grosse boulette de ma part, car si un hackeur lit mon poste je lui indique directement à quelle société s’en prendre pour ensuite, par rebond, potentiellement accéder à de nombreux établissements.
J’ai donc édité mon premier post en conséquence, merci de ta bienveillance. ^^

C’est bien cela et cela ne concerne qu’un seul presta extérieur.

A ma connaissance il n’y a aucun environnement de pré-prod chez nous, j’imagine que le prestataire a lui un labo sur lequel il teste ses mise à jours et leurs déploiements.

C’est une bonne idée, mais comme dit l’environnement de pré-prod n’est pas chez nous.
Et avoir un environnement de pré-prod en local implique des ressources matérielles supplémentaires, qui ont un coût que l’on ne peut pas se permettre, surtout s’il en fallait pour chaque environnement, logiciel, applicatif utilisé.

Le gros souci c’est qu’on ne sait pas quand le presta se connecte chez nous, nous ne savons rien de sa politique de sécurité en interne et nous ne savons pas ce qu’il fait quand il se connecte.
Je ne dit pas que c’est un mauvais presta, sans doute travaille-t-il correctement. Mais il rentre chez nous quand bon lui semble, avec un accès permanent. C’est donc une porte ouverte sur notre infra et sur laquelle nous n’avons que peu de contrôle hormis de couper purement et simplement leur VPN.

Tu ne te trompes pas, il existe d’autres éditeurs à proposer le même genre de prestation.
J’ai reparlé de ce sujet aujourd’hui avec mon DSI, il a été très clair, soit l’éditeur se plie à notre PSSI, soit nous iront tout simplement voir ailleurs. Pourtant leurs applicatifs marchent bien, les utilisateurs en sont contents, mais question sécurité ça ne va pas du tout, surtout dans ce domaine et quand on voit l’actualité de ces derniers jours, ils serait temps qu’il comprennent que l’informatique ne se pratique plus comme il y a 20 ans quand tout le monde s’interconnectait avec un minimum de précautions.

1 J'aime

Ouf! Tant mieux, je pense que tu as saisi les risques que j’évoquais.

  1. Je n’ai jamais dit qu’un environnement de recette/pre-prod doive être proche physiquement de la prod.
  • Un environnement de recette doit être équi-fonctionnel, le but est de tester les livraisons et modifications
  • Une environnement de pré-prod va encore plus loin, et doit permettre de tester encore mieux, notamment sur les aspects charge/performances et infrastructure. Une pré-prod est théoriquement identique {données en qualité et quantité, paramétrage, fonctions, matériel, logiciel, infrastructure, réseau} à la production.
  1. Il n’y a aucune obligation à réunir/rapprocher physiquement les environnements.

  2. Tu dis :

Là, je pense qu’il y a confusion. Ce qu’ils ont peut-être, c’est un environnement de pré-recette, ou encore appelé environnement de test.
Hélas, souvent, c’est plus « bon marché » que cela, et l’environnement de dév. tient lieu d’environnement de test (pré-recette)(là aussi je vais simplifier, je l’appelle « test ».

  1. En tant que client, tu ne peux pas être dans l’ignorance de l’existence d’un envt de recette, pour une seule et bonne raison : Idéalement, les devz n’ont pas accès à la recette. La recette est le domaine normalement exclusif du client/maîtrise d’ouvrage.

  2. A ce stade, je récapitule.
    Dans un monde idéal, qui a le temps, le personnel et les moyens :

  • Chaque dev a son propre envt (sa sandbox) et met au point ses items
  • Les devz livrent leurs items dans un environnement de dev et valident une version
  • Suivant les moyens, la version est testée dans un envt de test (pré-recette) par les experts fonctionnel de l’éditeur, protégé des devz
  • Les sysAdmin (normalement du client) récupèrent et livrent la version en recette
  • Le client valide la version en recette avec ses valideurs
  • (optionnel et coûteux) : Le client valide la version en pré-prod avec ses valideurs, si possible avec outils/automates
  • Les sysAdmin (normalement du client) livrent la version en prod.

Les règles de l’art IT (Best Practices) recommandent :

  • Que l’éditeur/devz/fournisseur n’a accès à rien en modification dès l’environnement de recette. Il peut en revanche accéder à la prod pour surveillance/audit en lecture seule en cas d’urgence (et encore, pas chez les paranos comme moi. Je leur donnerais copie d’info, pas d’accès).
  • Que toute modification de la production a été exactement testée et validée dans un environnement autre, validé par le client (sanctionné par un procès-verbal de recette).
  • En application des Règles (Policies), les modifications en production (par ex. gestion des comptes, tâches administratives) sont gérées par des personnes-pilotes d’application qui appliquent des SOP (Standard Operating Procedures) en suivant des WI (Work Instructions). Les pilotes d’applications sont soit internes, soit ne répondent qu’au client, et sont indépendants des éditeurs/devz/fournisseurs. Et plus les besoins en prod sont automatisés et en self-service utilisateur, mieux c’est selon … moi. :sweat_smile:

Commentaires :

  • Dans la vie réelle, on constate que les règles de l’art IT sont dégradées, l’idéal n’est pas appliqué
  • La complexité augmente quand l’aspect matériel (hardware) fait partie du problème au même niveau d’enjeux et de risques que le logiciel, par exemple dans les domaines industrie/santé/alimentaire/aviation/spatial.
  • La complexité augmente quand le domaine comprend des risques vitaux humains
  1. Je résume sur la base des infos disponibles ce que tu décris dans votre SI :
    a) L’éditeur livre des versions sans recette+procès-verbal du client => non conforme
    b) Le client n’a pas exigé d’environnement de recette en bonne et due forme=> non conforme
    c) Des fournisseurs interviennent directement sur votre prod pour livrer des versions => non conforme
    d) Le fournisseur pilote directement l’application en prod => non conforme

Je parle de conformité à des règles de l’art, mais je peux me tromper, je serais heureux d’avoir des contradictions qui me permettront d’apprendre.

  1. J’ai bien parlé d’automatiser les livraisons en production, sans intervention humaine, ou très réduite, et uniquement orchestrée par les personnes pilotes d’application en prod, qui sont soit internes, soit employés par le client, sans lien avec le fournisseur-éditeur.
    En creux, je souligne un manque de moyen et d’application des règles de l’art du côté des pilotes/responsables de production.

Je ne veux pas tirer sur le pianiste, à savoir le service informatique interne, qui par manque de moyens et de personnel, doit porter plusieurs casquettes.

Je sais juste que les règles de l’art que j’ai citées ont des effets positifs, et ne pas les appliquer revient à prendre des risques.

Bonus:

  • Les Policies+SOP+WI ne sont pas l’apanage de la production, cela s’applique à tous les environnements, et il doit absolument y en avoir pour répondre à tous les besoins en production.
  • Les ProcèsVerbaux existent en théorie pour tout environnement, pas uniquement la prod.
  • La tendance est d’automatiser le plus possible, tous travaux, tests compris.
    HTH :vulcan_salute:

[Edit 2021-02-17T07:34:18+0100 Les systèmes qualités peuvent différer et les normes évoluer, on ne parle peut-être pas de Policy/SOP/WI dans tous les domaines (voir les ISO9000).
Cela étant, quel que soit le système de gestion de la qualité, il définit La Stratégie : Pour Quoi + Pourquoi, puis Qui, Quand, Quoi, Combien, puis le Comment.
Puis, une fois qu’on a bien écrit ce qu’on allait faire, on le fait et on le prouve (Procès Verbal/Enregistrement => Traçabilité) Bon, ce n’est qu’un résumé succint. ]

:wave: :smiley: @Crowbar
Coucou, puis-je avoir ton commentaire juste sur les non-conformités que je proposais à ta réflexion?

Quand j’aurais le temps et le courage de faire une réponse, je croule sous le travail en ce moment au point de devoir même aller bosser tout ce samedi.

Je t’envoie tous mes encouragements sur ton chemin et je te souhaite toute réussite dans tes projets. :vulcan_salute:

Bonsoir,
Alors pour commencer, vous pouvez me jeter la pierre car ce fil a un niveau technique de gestion de sécurité réseau qui me dépasse.

Je vais me concentrer sur le principal :

-Réseau informatique ERP (établissement recevant du public).

Pour des raisons évidentes de sécurité, on ne sais pas quel type de données vas gérer ce prestataire récalcitrant.

Je vais donc emettre une hypothèse :

Si d’une manière ou d’une autre sa presataion ou l’accées vpn qu’il exige implique de manière directe ou indirecte a des données de patients.

Dans ce cas là on entre dans la RGPD 2018, et donc la cnil pour être gentil.

En résumé, si l’accès que votre prestataire exige lui permet d’accéder à des données personnelles de citoyens, il y a moyen de motiver le refus avec la cnil.

Bien que ce texte soit de 2018, il n’est toujours pas dans les moeurs de notre société. Globalement, tout les système de traitement de données français sont hors normes, en particulier les entreprises qui imposent un mail « prenom.nom@entreprise.com » à leur salariés alors que selon ce texte, il faut leur accord ou la pseudonomysation.

par exemple.

Sauf erreur, le but de @Crowbar n’est pas d’interdire au prestataire externe l’accès au données, c’est de restreindre l’accès à distance comme il l’a spécifié.
Donc dans ce cas, je ne vois pas ce que l’aspect RGPD change par rapport au besoin de sécurité exprimé par @Crowbar, mais je ne demande qu’à apprendre si j’ai raté quelque chose.

Il me semblait que sur le fond le problème était plus d’ordre « juridique » et « contractuel » que technique.
Donc, déjà un accèes vpn direct de l’éditeur sur le réseau de travail de Crowbar, on ne peux pas trop savoir ce qu’il fait.
Plutôt que d’utiliser une machine intermédiaire mise à disposition.

Donc un des motifs de refus que je propose, de cette connection que le prestataire tente d’imposer. C’est le caractère ERP de l’établissement et la RGPD si cela touche des ou consulte des données patients.
Juridiquement, un peu comme les établissements classés sensible qui ont des règles d’exceptions, il doit y avoir une piste à fouiller s’agissant d’un lieu médical.
Peut être poser son problème au service juridique de son établissement.

Bien, évidemment la piste la plus évidente.
Que dit le contrat de ce prestataire ?
Là aussi → Service juridique.

Non, ce que j’en ai compris, c’est que le problème est d’ordre sécuritaire :

  • @Crowbar veut bien que le prestataire intervienne sur leur système, mais en respectant une simple procédure plus contraignante, qui ne laisse pas une porte ouverte en permanence sur leur production
  • Le prestataire ne l’entend pas de cette oreille, et on peut deviner pourquoi : Le prestataire veut avoir le confort organisationnel de pouvoir intervenir à distance sur la production quand cela lui convient, et sans rendre de compte ni demander de permission à chaque fois, sans transparence sur ses interventions.
  • Dans la mesure où les deux parties sont en désaccord, la suite sera soit amiable soit juridique.
  • Encore faut-il que si @Crowbar voulait remplacer les presta actuels, il devrait trouver des prestataires disponibles et compétents, et peut-être même fournissant un logiciel identique si j’ai bien compris car le presta est éditeur.
  • Un tel changement dans un tel domaine dans un tel contexte est tout sauf simple. :sweat:

Cela dit, j’ai clairement indiqué les quatre non-conformités qui me semblent exister.
A commencer par le fait que le prestataire modifie données et programmes directement sur la prod, enfin, bref, je me suis déjà exprimé. Mais je n’ai pas de réponse de @Crowbar le surbooké :wink:.

Bonne :+1:chance, @Crowbar
Tiens-nous informés.

1 J'aime