D’hab c’est le vendredi les trolls^^ Le systeme preco par l’ANSSI est tellement contraignant que les develos utilisent leur pc/mac portable en 4G et s’envoie le code. ils utilisent les postes uniquement pour l’envoyer dans git. Tout la chaine CD est géré par l’IT.
…J’avais pas compris pourquoi, à mon arrivée à l'IT, ils m’avaient fourni une caisse de doliprane/nurofen… Sans OS multi-niveau comme le decrit la spec de Clip pour faire tourner des machines en // pas de moyen de consolider les infrastructures de poste client. Pr On 29 June 2019 at 16:55:04, Florent CARRÉ (colund...@gmail.com) wrote: Bonjour tout le monde, /* début du risque de troll */ Incroyable, l'ANSSI aurait enfin compris que c'était stupide d'interdire la virtualisation pour le poste d'administration. Ils auraient pu éviter d'attendre aussi longtemps. Concernant Clip OS, ça fait depuis 2006 qu'ils sont dessus la chose et puis leur plus gros concurrent (qui est en production), c'est SEDUCS ( http://www.c-s.fr/file/174062) de C&S (Communications & Systèmes). Peut être qu'un jour il y aura une release stable de Clip OS, quand il aura 18 ans (on s'en approche rapidement). /* fin du risque de troll */ Pourquoi ne pas envisager Qubes (https://www.qubes-os.org) ? C'est du basé sur Xen, un système qui permet de faire un copier/coller entre les vm où il faut utiliser une option spéciale quand on veut le faire mais ça fonctionne. Ça répond à tout le besoin out of box. Le côté encore supplémentaire, c'est qu'il faut que l'administration se fasse sur une patte dédiée donc vpn ... Et c'est là où la vm est pratique parce qu'on ne donne pas la patte admin à tout le système. Le plus difficile, c'est que l'ANSSI ne veut pas que les admin soit root de leur poste d'admin. On utilisait du SaltStack (à work-N) et sur le dernier en date c'était du Ansible (avec plus de problèmes que de solutions mais ça allait avec la mentalité des gars) pour gérer la configuration du poste et le password root était caché au coffre. Toute interaction avec le root étant interdite. Là où cela avait été une stupidité d'être avec Ansible c'est le manque d'agent sur le poste donc lancer manuellement l'update ou via un systemd-timer. Mais cela reste bancal et sans la possibilité de révoquer l'accès si le poste se fait voler (ok, bypasser le password efi, luks et session, faut vraiment le vouloir) ou même de forcer l'update des postes via le salt-master (bien pratique en cas de release urgente d'une update interne ...) Le process en utilisant SaltStack était simple, si on avait besoin du password, cela signifiait qu'on avait briqué le système via SaltStack donc via une maj des dépôts Git. C'était efficace mais je ne me relancerai pas dans la migraine absolue de cette chose. Bon courage à ceux/celles qui doivent mettre en place une solution de ce type. Bon weekend On Sat, Jun 29, 2019, 08:45 Thierry CHICH <thierry.ch...@ac-clermont.fr> wrote: > Pour notre part, nous voudrions tenter de fonctionner à base de machines > virtuelles au dessus d’un système durci. > D’un côté on lancerait des machines « utilisateurs » et de l’autre des > machines « admin ». > Pour avoir utilisé un prototype sommaire, le gros souci, c’est de rendre > possible les échanges entre les catégories de machines de manière fluide. > Il n’est pas concevable de ne plus pouvoir copier des bouts de code. Il > faut donc que le copier coller et la circulation de fichiers puisse se > faire sans trop d’entrave. > > Cordialement > Thierry > > > Le 29 juin 2019 à 08:44, professor geek <prg...@gmail.com> a écrit : > > > > Hello, > > > > Oui je suis confronté aussi a ce pb et comme tu le dis encore plus dans > > notre environnement DevSecOps.. > > l’ANSSI developpe un OS sécurisé qui permetrait d’avoir une machine admin > > et une LAN sur le meme hardware. > > la solution se base sur un GENTOO securisé, la solution et sa roadmap > sont > > sur GitHub : CLipOS. > > aujourd’hui la solution est en Alpha. j’attends la release … mais comme > > d’hab avec les services d’etats c’est long ! les devs repondent > rapidement > > aux questions, c’est deja ca ! > > > > Le poste admin c’est qu’une partie. Ne pas oublié la zone réseau dédié, > etc… > > > > > > On 28 June 2019 at 18:39:29, Thierry Del-Monte (tdelmo...@integra.fr) > wrote: > > > > Bonjour à tous, > > > > L'ANSSI dans son guide sur l'administration sécurisée de SI > > ( > > > https://www.ssi.gouv.fr/uploads/2015/02/guide_admin_securisee_si_anssi_pa_022_v2.pdf > ), > > > > préconise dans sa recommandation R9 l'utilisation d'un poste > > d'administration dédié ou à multi-niveaux. > > > > Est-ce que l'un de vous a déjà mis en place ou rencontré ce > > fonctionnement dans son entreprise ? > > Je suis à la recherche d'un retour d'expérience aussi bien sur la > > solution choisie que sur son exploitabilité au quotidien (la contrainte > > me semble très forte pour les sysops et netops). > > > > Merci par avance pour votre partage > > > > Thierry > > > > --------------------------- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
