Voici un article de blog, qui présente sans trop rentrer dans les détails, la voie choisie par mon employeur pour les ordinateurs portables sous Linux des personnes qui y travaillent.
La configuration présentée est le fruit d'un long travail commencé il y a plusieurs années (certains ordinateurs ayant eu des montées de version depuis Ubuntu 16.04 !), et qui occupe les journées de ma petite équipe, que j'ai rejoint il y a quelques mois.
Je voulais faire un simple lien, mais je me dis que c'est aussi une opportunité de pouvoir répondre à des questions, comme je suis dans le coin. On prévoit d'écrire d'autres articles plus fouillés sur des sujets précis, donc s'il y a des trucs qui vous rendent curieux, ne pas hésiter, ça pourrait influencer les prochains articles. Ne le prenez pas comme une publicité masquée1 :).
L'article est en Anglais, pour résumer ça explique : qu'on peut choisir l'OS de son ordi de boulot entre Win/Lin/Mac, quelles limitations par-rapport à ce qu'on a l'habitude quand on babasse sur son Linux chez soi, comment c'est sécurisé (et audité), géré à l'échelle (ou à l'escabeau, devrais-je dire, Linux ne représente que 15% des ordis portables du parc). Il est également évoqué la volonté de garder le dialogue ouvert dans la communauté de Linuxien·nes interne.
L'article, le voici, le voilà : https://blog.ovhcloud.com/introduction-to-the-linux-laptop-pci-dss-at-ovhcloud/
-
J'ai tout de même mis le tag "publicité" car cela reste une communication d'une entreprise privée. ↩
# Quality
Posté par Xavier Verne (site web personnel) . Évalué à 10 (+10/-0).
Linux à l'échelle sur le poste client, avec un haut niveau de sécurité, tu vas faire rêver tous les geeks dans les grosses boîtes… Merci - Antoine - pour la qualité de cet article. Surtout le schéma d'architecture. Perso un post LinkedIn serait utile à mon avis et ferait de la promo pour OVH en plus de donner de la visibilité à Linux sur le desktop - parce que c'est pour cette année, hein ?
Une question, dans une boîte normale les Pc windows ne sont pas certifiés pci-dss et donc on peut chiffrer son disque sans jeton physique ?
J'ai l'impression que cela simplifierait l'architecture technique nécessaire : de beaucoup ?
[^] # Re: Quality
Posté par cg . Évalué à 7 (+5/-0).
Les PCs sous Windows utilisent un PIN et/ou Windows Hello (empreinte digitale, reconnaissance faciale ?) pour BitLocker, je crois. La grosse différence est qu'on a choisi de ne pas utiliser la puce TPM pour les ordis Linux, mais ça pourrait changer, en complément de la Yubikey (ces jetons servent à d'autres choses dans le SI, donc de toutes façons on en a besoin).
Pour LinkedIn, c'est sans doute fait aussi, mais je n'y suis pas inscrit :p.
[^] # Re: Quality
Posté par pasBill pasGates . Évalué à 7 (+6/-0).
Cette partie :
est intéressante, c'est quoi qui manque chez vous ?
[^] # Re: Quality
Posté par Xavier Verne (site web personnel) . Évalué à 1 (+2/-2).
Je tente une réponse à l'aveugle… Genre il manque TOUT. Ils ont tout fait à la main… et sans IHM, et j'imagine en contournant tout un tas de problèmes.
Paramétrage du chiffrement, partage des configuration du poste, VPN, config de chiffrement post install, etc…
Ex "simple": le VPN. dans ma boite sous windows on t'installe le client VPN par défaut qui descend dans les mises à jour, tout est préconfiguré, il se réveille quand il faut login, automatiquement, il est branché à la double authentification, et ca juste marche.
Est-ce que c'est aussi fluide sous linux ou alors il faut :
1. désactiver à la main le network manager à l'install, et peut être faire gaffe aux mises à jour OS la dessus
2. savoir quand lancer le VPN
3. remplir la passerelle à interroger à froid, etc..
pour Mme michu et le directeur financier c'est mort.
[^] # Re: Quality
Posté par cg . Évalué à 3 (+1/-0).
Alors pas à ce point quand même :).
Les installs sont automatisées à 95%, et il reste peu de manips à faire par le support1 qui s'occupe des installations. La gestion des certificats, du chiffrement, etc… Tout cela est automatisé, mais en effet on a du développer le code pour le faire, là ou avec d'autres systèmes c'est "piles incluses".
qui déchire <3 ↩
[^] # Re: Quality
Posté par ff9097 . Évalué à 9 (+7/-0).
Depuis quand faut désactiver NetworkManager pour le VPN ? Sur Fedora tu as le client open-source openconnect compatible avec plusieurs protocoles qui est installé de base et tu n'as même pas besoin d'installer un client officiel bloated
[^] # Re: Quality
Posté par cg . Évalué à 2 (+0/-0).
Openconnect est vachement bien, mais on est obligé d'utiliser les clients bloated/proprio, car ces clients supportent les "postures", qui consistent à vérifier l'état du endpoint avant d'autoriser la connexion au réseau.
Exemples de postures :
- une machine qui n'est pas à jour ne va avoir accès qu'aux repos de paquets/serveurs de patch.
- La connexion au VPN est refusée si l'antivirus est coupé.
- Le client VPN désactive le routage de paquets à la connexion.
- La connexion au VPN se coupe si un second utilisateur se loge sur la machine.
Je ne crois pas que openconnect permettre ces contrôles, peut-être qu'on pourrait le faire via des scripts type pre-up.d ?
[^] # Re: Quality
Posté par shbrol . Évalué à 2 (+1/-0).
Ici on utilise OpenConnect parce qu'il est capable de faire de l'authent PKCS#11 sous Linux, contrairement au client bloated qui ne sait le faire que sous Win et macOS (oui Cisco c'est toi que je regarde).
OpenConnect a son propre systeme de callbacks donc oui il est possible de faire des choses, mais il faut le scripter soit même.
[^] # Re: Quality
Posté par cg . Évalué à 2 (+0/-0).
Merci de ce retour !
Oui sur le client actuel qu'on utilise, et son futur remplaçant, les fonctionnalités ne sont pas les mêmes en fonction de l'OS du endpoints, et c'est pénible :-/.
[^] # Re: Quality
Posté par shbrol . Évalué à 2 (+1/-0).
Bonus avec les versions récentes de OpenConnect (>= 9.x) pour les VPN Cisco, tu as la double authentification PKCS#11, ce qui permet d'utiliser d'abord un certificat machine dans la TPM, ensuite un certificat utilisateur dans un dongle PKI, et alors tu as un certain niveau d'identification du client.
[^] # Re: Quality
Posté par cg . Évalué à 5 (+3/-0).
Nous utilisons Puppet pour gérer les configurations. C'est un outil merveilleux qui propose des abstractions permettant de gagner du temps pour des trucs simples comme dire "je veux que tel paquet soit installé", par exemple, et qui permet de développer assez "bas niveau", et il y a une forge qui permet d'installer des modules tiers. Mais ce n'est pas tout à fait un MDM super intégré comme pourrait l'être InTune ou WorkspaceOne.
Le fait que Puppet soit à mi-chemin entre un langage de programmation et un MDM fait qu'on doit développer plus de code pour avoir le même process sur Ubuntu que sur Windows ou MacOS. Par exemple, stocker les mots de passe de récup BitLocker, ça se fait tout seul avec WorkspaceOne sur Windows. Pour Ubuntu, on a du tout coder nous-même (gestion des expirations, envoi dans un stockage sécurisé).
L'autre truc, c'est que des outils commme Puppet, Ansible, Chef, Salt, sont inter-distribs. Et donc parfois ça ratisse plus large sur les cas communs entre les distribs, mais moins précis.
J'imagine que nous sommes face au paradoxe d'avoir un système ouvert : il y a mille et une façons de faire, et dans notre cas, on le "paye" pas plus de travail (qui reste agréable, je ne m'en plains pas :)).
[^] # Re: Quality
Posté par Xavier Verne (site web personnel) . Évalué à 1 (+0/-0).
Merci pour les précisions. C'est exactement ce que j'imaginais dans mon précédent post, il y a plus de travail d'intégrations et de scripting paramétrage pour que "tout marche au déballage" pour les devs qui se dotent d'un laptop Linux.
sais tu dire si cela impacte favorablement la durée de vie des laptops ? Parce que démontrer, dans un contexte pro, qu'on est pas obligé de suivre la cadence de renouvellement imposée par Teams et les mises à jour Windows grace à ce type de choix… Ca serait tout à fait intéressant pour continuer à convaincre en entreprise de la légitimité de Linux sur le desktop.
[^] # Re: Quality
Posté par cg . Évalué à 3 (+1/-0).
En terme de durée de vie, il y a des personnes qui ont des laptops qui ont 7-8 ans, et ne veulent absolument pas les rendre :).
Bien sûr, quand tu utilises des applis un peu lourdes (un IDE type Code, avec le LSP et tout le tintouin) + un anti-virus, et que tu fais de la visioconf avec 200 onglets ouverts dans ton navigateur, ça rame un peu.
À un travail précédent (post-production audiovisuelle), on avait des ordis qui avaient 15 ans et servaient encore, mis à jour de Debian 7 à 12 au fil des années.
Donc je dirais oui, Linux permet de prolonger la durée de vie des ordis, de ce que j'ai pu constater ici et là.
# root ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6 (+4/-1).
Comment faire pour bosser sans être root ?
Sous windows, c'est rare de virer le privilège d'être admin pour installer des logiciels. Et quand c'est le cas, c'est facile à contourner : beaucoup d'applications proposent des versions zip.
En tant que dev, ne pas pouvoir faire d'installation est assez infernal (pas de firefox, pas de wsl 2, pas son ide…)
Mais sous linux ? Il existe des distribs qui proposent l'installation sans être root ?
"La première sécurité est la liberté"
[^] # Re: root ?
Posté par François Chaix . Évalué à 5 (+4/-0).
Avec le gestionnaire de package nix, et par exemple home-manager (et nix-shell, flakes, etc), on peut tout à fait installer n'importe quoi sans être root.
La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.
[^] # Re: root ?
Posté par Wawet76 . Évalué à 8 (+6/-0).
Dans le fabuleux monde de l'entreprise, ce n'est pas rare du tout.
Dans l'entreprise ou je travaille, on y vient alors qu'on est seulement une trentaine. Pour des raisons de certification… Chez les grands comptes avec qui on travaille (banques, telecom, industrie,…) c'est systématique.
[^] # Re: root ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 10 (+14/-1).
Pour des dev aussi ?
C'est juste l'enfer. Au début, on nous dit il suffira de faire des tickets, ensuite on nous demande de justifier l'installation (pour un essai qui pourrait prendre 2 min ou un souci urgent), et ensuite, ils refusent car ils ne savent pas évaluer le risque, forcément les experts, c'est nous, pas l'IT qui s'occupe des postes de travail.
Ensuite, on monte un shadow IT car on à des comptes à rendre aux clients. Les personnes gérant la sécurité que j'ai rencontré refuse tout par principe, mais n'ont de compte à rendre à personne sur les retards induits. Ils refusent aussi de participer aux projets pour trouver des solution, il faudrait qu'ils se mouillent…
Je me rappelle encore de ce refus de monter un serveur ftp pour échanger des images avec un client (~2005). L'IT demandait 6 mois pour le faire, notre expert a utiliser son adresse mail… perso.
"La première sécurité est la liberté"
[^] # Re: root ?
Posté par pasBill pasGates . Évalué à 4 (+3/-0).
C'est un problème culturel ça, l'équipe sécurité a des clients , dont notamment vous, mais pas que vous, et elle est sensée satisfaire ses clients.
[^] # Re: root ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6 (+4/-1).
Les clients internes cela n'existe pas. Un vrai client paye avec ces sous.
En général, la sécurité ne dépend pas des projets mais d'un truc externe. "Allez, on arrête les distribs obsolète, tout le monde en red hat 9. - Ok, mais qui a les budgets ? - On a plein de licences ! - On est en prod, il n'y a pas de connexion internet, un serveur de licence offline, c'est 20k. - … - …On va utiliser Debian."
"La première sécurité est la liberté"
[^] # Re: root ?
Posté par pasBill pasGates . Évalué à 0 (+3/-4). Dernière modification le 20 juin 2025 à 10:45.
Les clients internes cela existe absolument.
Viens bosser chez Amazon et répète cela en meetings pendant disons 3 mois, je suis a peu près sûr qu'au mois 4 tu seras à la recherche d'un emploi.
Et ça, c'est en imaginant que tu aies passé l'interview malgré cela
[^] # Re: root ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4 (+2/-1).
C'est des cultures d'entreprises. Il n’empêche que cela entraine pas mal d'effets toxiques. Le "client" se croyant parfois tout permis, cela entraine des couts et/ou des retards pour des vrais clients qui payent, alors qu'en interne, c'est la même poche. Et quand il y a de la "refacturation interne", chacun y va de sa marge, et certains services préfèrent utiliser des services externes au lieu de faire bosser en interne. Les frais généraux sont toujours à payer, que les équipes bossent ou non, le cout réel n'est donc pas du tout le même. En gros, on calcul un cout avec R et NR lissé, mais si on prends une équipe externe, le NR est toujours à payer.
"La première sécurité est la liberté"
[^] # Re: root ?
Posté par pasBill pasGates . Évalué à 7 (+6/-0).
Non mais il faut bien comprendre ce que cela veut dire. Le client n'a pas tous les droits, et il n'y a pas qu'un seul client.
Nous par exemple on a les équipes développement d'AWS comme client mais on a aussi les clients d'AWS comme client et le leadership d'AWS. Quand on se retrouve dans certaines situations on doit peser le positif et le négatif pour chacun, et le but est de pouvoir clairement expliquer au client comment il peut faire les choses de manière sûre et pourquoi on lui dit non quand on doit dire non, et il y a évidemment un processus d'évaluation en place pour nous garder honnêtes.
Est-ce que le système est parfait ? Non bien sûr, mais j'ai trouvé que c'était infiniment moins toxique que l'approche Microsoft ou chaque groupe ne vivait que pour lui même
[^] # Re: root ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2 (+0/-1). Dernière modification le 20 juin 2025 à 16:38.
ça cela s'appelle bosser correctement.
A chaque fois que j'ai entendu parler de clients internes, ils se comportaient comme une caricature de "client roi". Cela avait des effets sur les budgets, sur qui décident quoi, sur la manière de compter les frais plus ou moins artificiels (genre l'interne à qui ont facture les frais généraux, mais pas le gars de SS2I ou l'on compte que son taux journaliers mais qui utilise aussi un bureau, une clim…).
"La première sécurité est la liberté"
[^] # Re: root ?
Posté par pasBill pasGates . Évalué à 6 (+5/-0).
Je veux pas vendre la manière Amazon, mais le truc qui m'a choqué quand je suis passé de Microsoft à Amazon c'était leur "Leadership Principles" ( https://www.amazon.jobs/content/en/our-workplace/leadership-principles )
A la base, ils me les avaient envoyé avant l'interview, je les ai lu, je me suis dit "ouais cool, tout le monde écrit le même charabia et c'est oublié dés le deuxième jour" parce qu'à Microsoft c'était ça: le même genre de truc était écrit sur le site HR interne, on le lisait le 1er jour, et après tout le monde s'en fichait.
A Amazon il se trouve que c'est leur bible, ils sont super pointilleux dessus, au début je croyais que c'était une secte, venant d'un monde diffèrent, j'arrètais pas d'entendre ces trucs dans les meetings. Mais j'ai…rejoins la secte, car je l'ai trouvé très très efficace pour au moins une chose : éviter les trous du culs brillants dont Microsoft était garni, qui ruinaient la vie de tout le monde mais qui étaient tellement bon que rien ne pouvait leur arriver. C'est aussi très bon pour assurer que les groupes collaborent, alors qu'à MS, c'était chacun pour soi pour être poli.
[^] # Re: root ?
Posté par cg . Évalué à 8 (+6/-0). Dernière modification le 19 juin 2025 à 21:50.
C'est vrai que c'est un facteur d'étonnement régulier. On voit quelqu'un arriver et dire "euh vous avez oublié de me donner le mot de passe root".
Et en fait, le compte root n'a pas de mot de passe, et sudo ne donne pas de shell root. Étrange :).
Pour prendre le métier de développeuse, qui demande en effet beaucoup d'outillage, parfois des besoins spécifiques, et de pouvoir installer la moitié de la terre sur son ordi pour pouvoir tester, on a plusieurs solutions.
Tout d'abord, il y a des machines virtuelles disponibles sur le réseau. Et puis, avec le CI/CD, c'est assez pratique d'externaliser sa chaîne de fabrication.
Ensuite, parce que c'est quand même pratique, et souvent plus rapide pour tester, on peut faire du dev en local. Il y a Docker installé sur les laptops, mais Docker sans droits root, en userspace. Ça permet de monter des plateformes de test avec Docker compose, par exemple. Surtout ça permet de garder le système du laptop un minimum propre. Il y a aussi possibilité de lancer des VMs (avec qemu, via Gnome Boxes ou virt-manager, toujouts sans droits root).
Enfin, si d'aventure ton laptop n'a pas un outil utilisé dans un Makefile, ton éditeur préféré ou
nyancatpour rigoler, et bien il y a un accès à une version limitée deapt, qui permet d'installer ce qu'il y a dans les dépôts préconfigurés (tu ne peux pas faireapt install ./untruc.deb).Et si vraiment, malgré tout cela, le besoin n'est pas comblé, alors une demande est faite, évaluée, validée, documentée comme exception et zou, en fonction du cas on va développer un patch dans notre système ou juste faire une install manuelle.
Un exemple précis de ça est que quelques personnes d'une équipe particulière avait besoin de pouvoir faire des captures réseau avec Wireshark. Mais Puppet gère les groupes, donc si on fait un ajout à la main, il est annulée par Puppet ensuite. Donc on intègre que "untel sur telle machine" a un groupe supplémentaire et voilà, les choses restent clean.
Pour les cas extrêmes ou vraiment trop spécifiques, on fourni des laptops avec accès admin, mais il sont alors hors réseau (ils n'ont accès qu'à Internet).
Je ne me fais pas trop d'illusions sur le fait qu'il y a un peu de shadow IT, qu'il y a des compilos installés dans les homedirs, des extensions VSCode mal fichues.
Mais si les choses sont pas trop mal fichues au départ, c'est tout à fait possible de travailler en tant que dev sans avoir accès au root sur ta machine.
[^] # Re: root ?
Posté par shbrol . Évalué à 4 (+3/-0).
Il y a un accès à une version limitée de apt, qui permet d'installer ce qu'il y a dans les dépôts préconfigurés (tu ne peux pas faire apt install ./untruc.deb).
Intéressant ! Cette version limitée de
apt, est-elle obtenue juste par configuration (apt.conf.doupreferences.d) ? Ou bien s'agit-il d'un wrapper par dessus la commandeaptstandard, on encore d'unaptmodifié/recompilé ?[^] # Re: root ?
Posté par cg . Évalué à 6 (+4/-0).
En effet, on utilise quelques surcouches (wrappers), pour laisser un peu de latitude à l'utilisateur sans pour autant laisser les clés sur le frigo.
Il y en a un pour apt, qui limite les opérations possibles, en particulier l'installation d'un paquet qui n'est pas dans un repo autorisé, mais qui protège aussi de l'obtention d'un shell root, par exemple quand dpkg demande quoi faire pour les fichiers de configs modifiés, ou qu'un pager complaisant à une option pour lancer une commande (par exemple
lessoumoreet leur commande!). On encore qui bride les options du type "ne pas vérifier les signatures".On a aussi un wrapper pour systemctl, qui permet de start/stop/restart des services, mais pas tous (par exemple on protège syslog, l'antivirus, cron et quelques autres…). Ce wrapper m'a permis d'apprendre les bases de Python1, j'ai bien aimé :). Le plus amusant était de protéger un service en prenant en compte ses petits noms (par exemple
sshdpeut aussi s'appelleropenssh,ssh, avec sans le .service,syslog.servicea aussi des variantes, fun).Quand on fait ce genre de développement, on doit bien faire attention, en plus de ne pas introduire de trou de sécu supplémentaires, à ne pas utiliser des options qui n'existent que sur la version courante des outils qu'on utilise, mais aussi sur les versions passées en cours d'upgrade, et dans la version future. Donc pas trop d'options toutes nouvelles et pas d'options dépréciées.
Il y a aussi un "truc" (je sais plus la terminologie), qui se charge dans le démon Docker pour vérifier que les containers sont bien lancés sans les droits root.
Enfin on s'amuse bien, et quand on trouve un trou, on le rebouche :).
même si Perl gardera une place dans mon cœur pour toujours ↩
[^] # Re: root ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2 (+0/-1).
Plusieurs fois, j'ai eu besoin du compte root pour faire des choses sur un PC, mais je me rendais bien compte que la gestion du DNS, des comptes utilisateurs entreprises, des serveurs disques, des serveurs de sauvegardes, etc… aurait dû être gérer à part.
Est-il si impensable d'avoir un superroot (metaroot ?) pour tout ce qui est en rapport avec le reste de l'entreprise, et garder le root pour avoir le pouvoir d'exploser la machine sans exploser le reste du réseau ? J'ai l'impression que ton wrapper fait une course entre l'imagination des utilisateurs pour contourner la protection et la surface des soft protégé toujours plus grande.
Cela recoupe aussi le besoin d'une distribution minimal stable, fiable pour le système de base, compléter par un truc comme snap ou flatpack pour sortir une seul fois un logiciel pour toutes les distribes.
On dirait que docker ou un VM pourrait faire ça. Sauf que gérer le disque ou le réseau avec ces trucs risquent d'être infernal.
"La première sécurité est la liberté"
[^] # Re: root ?
Posté par cg . Évalué à 2 (+0/-0).
Si je te suis bien, je pense que ce "metaroot" correspond à ce que l'on propose aux utilisateurs des laptops avec le Docker rootless : tu es root dans les containers, mais c'est un root différent de celui du système (c'est géré par les usernamespaces).
Snap est souvent vu comme un méchant truc, mais je dois dire que sur certains aspects, ça facilite l'administration. Un truc à explorer, oui.
[^] # Re: root ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
Est-ce que ton interface graphique est dans Docker rootless ? Parce que j'ai été traumatisé par l'usage forcé dans certaine boite de VM graphiques qui passaient à travers le réseau (citrix ?), perdaient une parties des fonctionnalités clavier/souris (copier/coller, drag&drop) et "laguait" peu mais suffisamment pour devenir fou.
"La première sécurité est la liberté"
[^] # Re: root ?
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Pourquoi les laisser utiliser docker, avec les risques de merder la config, plutôt qu'un équivalent rootless et daemonless comme podman?
[^] # Re: root ?
Posté par cg . Évalué à 2 (+0/-0).
Il y a deux raisons à cela : Docker étant mieux connu des utilisateurs, c'est plus simple et plus fluide pour elles et eux d'utiliser Docker. Et comme on évite de valider plusieurs outils pour rendre des services très similaires (les analyses de risques peuvent être chronophages), le choix a penché du côté de Docker.
[^] # Re: root ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
Dans ma boite, on a fait le choix de podman… MAIS les devs réclament docker, parce que c'est la mode / ce qu'ils connaissent / pas envie de changer.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: root ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
podman est pas censé avoir les mêmes options ? (la différence se fait sur le réseau, il me semble)
"La première sécurité est la liberté"
[^] # Re: root ?
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
Sous linux ce n'est quand même pas compliqué, à partir du moment où il a le bit d'execution et que t'as pas restreint led possibilitées via selinux ou apparmor, tu peux tout installer dans le home, y compris une distrib complète si besoin.
[^] # Re: root ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2 (+0/-1).
oui presque mais quelle perte de temps ! (et oublie le réseau)
"La première sécurité est la liberté"
# quelle répartition des gens ?
Posté par orfenor . Évalué à 5 (+3/-0).
Est-ce qu'il y une répartition typique selon les usages ? Comme l'équipe commerciale plutôt sous Windows, les graphistes qui préfèrent MacOs et les sysadmin Linux ?
[^] # Re: quelle répartition des gens ?
Posté par cg . Évalué à 6 (+4/-0).
Oui, je crois qu'on peut dire ça, mais pas tout à fait.
La population qui a choisi Linux est très majoritairement sur des métiers tech, comme les personnes qui s'occupent de serveurs Linux en premier lieu (que ce soit les archis de plateformes, les ingés, les SREs…), il y une partie de développeurs, aussi, et sans doute quelques autre métiers, mais plus rare.
D'ailleurs, il y a beaucoup de personnes des métiers de la tech sur Windows et Mac aussi (les 85% restants ne sont pas des équipes "non-tech", sinon bonjour le rendement ;)).
Pour résumer, je dirais que autant sur Windows et Mac, on trouve une population relativement hétérogène, on a sur Linux une sur-représentation des métiers techniques d'informatique.
Précédemment, j'ai bossé dans une entreprise (bien plus petite, 200 personnes), dans laquelle tous les ordis étaient sur Debian, sauf ceux de la compta et des graphistes (4 personnes en tout).
# Antivirus
Posté par oau . Évalué à 2 (+1/-0).
Bonjour,
de notre côté nous sommes dans une situation similaire mais plus simple. Moins de monde et uniquement des linux. Pour tout le monde. Par contre l'auditeur exige que nous ayons d'installer des antivirus. Je ne vois pas trop l'intérêt, mais on a quand même installé amavis pour faire plaisir. De votre côté quel est intérêt avez vous trouvez d'installer un antivirus sur un linux ?
oau
[^] # Re: Antivirus
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
protéger ceux qui n'ont pas la chance d'être sous Linux et qui subissent un poste défaillant sous windows ?
si au moins ce genre d'outil pouvait remonter des stats du nombre de virus évités (en les classifiant win / mac / linux… et par le biais de quel logiciel afin de se faire une vraie idée de l'efficacité de chacun) :/
[^] # Re: Antivirus
Posté par cg . Évalué à 3 (+1/-0).
Salut,
sans même réfléchir, on doit mettre un anti-virus comportemental (EDR/XDR) parce que c'est imposé par la norme PCI-DSS.
Un anti-virus qui ne fonctionne que par signature est utile pour protéger le voisin sous Windows, en effet, mais le vrai truc c'est la détection de comportement étranges, et ça, clamav ne ne fait pas :-/. Il y a des choses comme Wazuh ou OSSEC qui permettent ce genre de détection.
Bien sûr, c'est impactant en terme de performances, surtout sur des compilations de code, ou des milliers de petits fichiers sont analysés, et avec des compilateurs qui font des trucs assez intenses (genre compiler du C++ qui utilise des templates/des generics).
[^] # Re: Antivirus
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
Sous windows en compilation java, l'analyse (par défaut en lecture !!!) multipliait les temps de compile par 5. Pourquoi faire des analyses en lecture et non seulement en écriture ?
"La première sécurité est la liberté"
[^] # Re: Antivirus
Posté par cg . Évalué à 2 (+0/-0).
C'est vrai que ça peut s'évaluer en terme de risque. C'est sans doute plus facile de trouver un truc louche dans un fichier d'entrée que dans le code compilé ou compressé. À voir aussi si l'anti-virus peut-être configuré pour dire "pour tel process, n'analyser que les écritures et pas les lectures".
Bonne suggestion en tout cas, merci.
[^] # Re: Antivirus
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 02 juillet 2025 à 11:39.
C'est fou ces normes qui sont là pour empêcher de réfléchir.
Même l'ANSSI est prudente vis à vis des antivirus. Par exemple:
https://cyber.gouv.fr/publications/recommandations-pour-ladministration-securisee-des-si-reposant-sur-ad
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Antivirus
Posté par cg . Évalué à 3 (+1/-0).
Oui, même si ce que j'ai écrit est un raccourci, il y a une part de vrai : avoir un cadre prédéfini permet de gagner du temps en ne se reposant pas forcément toutes les questions. Il y a un côté confortable, mine de rien. Bon il y a aussi un côté "mais bordel foutez-moi la paix". Le tout est trouver le bon dosage sans s'énerver :).
Sans entrer dans les détails, dans d'autres entreprises, j'ai dû gérer directement les arbitrages entre ce que demande un référentiel de sécu, ce que je pensais utile ou non, ce que le patron pensais utile ou non, le prix que ça coûte, et le risque de se faire rembarrer lors des audits (de norme ou audit client direct). Ben c'est pas toujours facile, mais les personnes qui audident sont souvent ouvertes aux compromis tant que ça semble justifié et acceptable.
Au final, tu as facilement 20% des trucs que tu ne vas pas faire, parce que ça ne rentre pas dans comment fonctionne ton entreprise.
Pour reprendre le sujet de l'antivirus EDR, c'est sans doute impossible de justifier que tu n'en as pas besoin sur un équipement nomade, qui est physiquement entre les mains d'un employé qui le connecte à divers réseaux plus ou moins sûrs, et qui a accès à Internet.
[^] # Re: Antivirus
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
Le problème c'est qu'il n'existe pas d'implémentation libre d'un EDR non? Et si ce n'est pas libre, c'est un risque plus grand que l'absence d'EDR.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Antivirus
Posté par cg . Évalué à 3 (+1/-0).
Si, il y a des trucs, comme OSSEC ou Wazuh. OSSEC peut fonctionner de manière autonome, sans serveur qui centralise les infos, ce qui peut être intéressant pour des machines indépendantes.
Je dois dire que les EDRs et les antivirus, ce n'est pas la partie qui m'intéresse le plus dans l'histoire :), je ne sais pas trop ce que ça vaut.
# PCI-DSS ?
Posté par BAud (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 24 juin 2025 à 16:12.
Comme la question n'a pas été posée, je m'y colle :p
Pourquoi avoir visé une Norme de sécurité de l'industrie des cartes de paiement comme PCI-DSS et pas une autre ?
Est-ce lié au domaine de ton entreprise (ou plutôt de ses clients) et le niveau d'exigence à respecter ? Ou est-ce parce que c'est une norme qui devrait aller de soi en entreprise ?
Est-ce applicable pour le commerçant du coin ? (ou plutôt la chaîne de magasins^W^W le carrouf'market du coin< ?)
J'imagine que l'ANSSI a des exigences similaires, avez-vous essayé de vous faire certifier par des organismes similaires ? (on trouve de l'ISO 27001 a tous les coins de rue de nos jours :p)
La même stratégie (ou similaire) est-elle applicable pour les ordinateurs fixes, voire les serveurs en datacenter ?
[^] # Re: PCI-DSS ?
Posté par oau . Évalué à 2 (+1/-0).
Hello,
Oui j'ai aussi tiqué là dessus. Nous on passe iso27001 et ensuite on s'attaquera au secnumcloud car certains clients voudraient y passer.
[^] # Re: PCI-DSS ?
Posté par cg . Évalué à 5 (+3/-0).
Bonne question ! OVHcloud a un petit paquet de certifications, selon les services.
Pour le périmètre de nos laptops Linux (donc les laptops + tout le bazar autour qu'on voit sur le schéma), on passe des audits SOC, ISO27K1, PCI-DSS, et des audits internes. Certains laptops sont également soumis à SecNumCloud (c'est une autre histoire).
Donc pourquoi PCI-DSS et pas HDS ou autre chose ? Je n'ai pas forcément les tenants et aboutissants, et ça m'avait d'ailleurs surpris aussi au départ.
Déjà, ça permet d'intervenir sur des plateformes de paiement, et toutes les plateformes qui ont un niveau de sécurité inférieur. Et puis le fait que ce soit déjà utilisé ailleurs en interne est assez pratique pour les équipes qui gèrent le SMSI, ça permet de mutualiser l'effort pour elles et eux j'imagine.
Décider que l'ensemble des postes de travail va répondre à cette norme qui est quand même assez exigeante, c'est mettre la barre assez haut, certes, mais est-ce superfétatoire ? À l'ère du RGPD, considérer les données des clients comme aussi critiques que des données bancaires, c'est du bon sens, quelque part, je crois :).
[^] # Re: PCI-DSS ?
Posté par BertoX . Évalué à 1 (+1/-0).
Parce que c'est une norme parmi les plus sécurisées ?
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.