Le 25/03/21 à 21:13, Nathan delhaye contact@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.