Le 25/03/21 à 21:13, Nathan delhaye <cont...@nathan-delhaye.fr> a écrit : > Si tu t'assoie sur les pratiques Micro$oft, PCI/DSS, les reco de l'ANSSI > (et probablement toutes les autres agences équivalentes à l'international), > ISO 27001, etc... oui > > Sinon la bonne pratique est de pouvoir suivre qui fait quoi dans un système > informatique en général.
Je suis bien d'accord, mais là il s'agit de comptes d'applis, ceux qui peuvent y accéder sont bien identifiés et traçables. J'avoue ne pas comprendre l'intérêt d'obliger admin42 à se connecter à son compte admin42 pour faire ensuite du `sudo -u foo -i` et se retrouver sur le compte foo plutôt que de l'autoriser à se connecter directement sur le compte foo. Ok, on doit sûrement pouvoir interdire le sudo -i pour obliger ensuite à ce que toutes les commandes passent par sudo et soient loggées. Ici c'est moi qui ait décidé de mettre là le curseur flicage/simplicité, et je l'assume très bien ;-) (On parle d'une asso où le nb d'admins avec clés ssh se comptent sur les doigts d'une main, et ceux qui ont une clé pour se connecter à foo peuvent aussi passer root, voire mettre le host en rescue et y accéder) > Si tu te fais pwn ton SI avec le compte "foo" : > - Est-ce que c'est une personne en interne qui a mis le bazar ? > (volontairement ou pas) > - Est-ce que c'est une attaque externe via une faille dans l'application > foo ? Y'a les logs déportés pour ça, facile de voir s'il y a eu un accès ssh à foo ou pas, quelles étaient les requêtes http qui ont précédé, etc. -- Daniel Il faut pleurer les hommes à leur naissance et non pas à leur mort. Montesquieu _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
