Pleins accès serveurs pour un nouvel employé IT — enquête de sécurité obligatoire ?

En vertu de la loi fédérale allemande sur la protection des données, la collecte de données sur les salariés est soumise aux principes de nécessité et de proportionnalité. Demander le casier judiciaire n'est recevable que si le poste l'exige strictement ; des infractions passées sans lien avec la fonction ne peuvent motiver un refus d'embauche. Cadrer la procédure avec un juriste en droit du travail évite tout risque de contentieux.

Ne configurez jamais d'accès root nominatif direct. L'authentification à double facteur via clé matérielle doit être obligatoire pour se connecter, et chaque commande 'sudo' doit partir instantanément vers un serveur de logs centralisé et non modifiable. L'employé doit savoir que chaque commande laisse une trace d'audit indépendante. Cette dissuasion est bien plus efficace que n'importe quelle enquête.

Ne donnez pas tous les accès au candidat dès demain. En Allemagne, la période d'essai légale (Probezeit) est le meilleur moyen de tester la confiance. Débloquez les accès progressivement au cours des six premiers mois ; commencez par les environnements de test et de dev et conditionnez l'accès à la prod à du binômage avec le lead tech.

Avez-vous pris des engagements spécifiques concernant le contrôle du personnel dans vos contrats de niveau de service (SLA) ou vos accords de traitement des données (AVV) signés avec vos clients ? Les grands comptes exigent parfois que les collaborateurs détiennent certaines certifications de sécurité ou suivent des formations annuelles obligatoires.

Il y a dix ans, paranoïa similaire : on avait imposé de telles restrictions au nouvel admin sys qu'il s'est barré au bout de deux mois en disant « si vous ne me faites pas confiance, pourquoi m'avoir embauché ? ». Et il avait raison. Plutôt que de chercher à faire des enquêtes d'habilitation, on pousse désormais les prises de références à fond. Parler directement à ses anciens managers et sonder son intégrité en situation de crise nous apprend bien plus de choses que n'importe quelle vérif sur papier.

lenquete officielle c pour letat de tte facon on nous laissera pas faire. nous on demande un extrait de casier judiciaire et on a totalement coupe le login root sur les serveurs chacun se connecte avec son compte et fait sudo, les logs partent direct sur un cloud externe.

PS : c'est demandé plus bas, j'ai répondu dans le deuxième message.

Pour sécuriser l'infrastructure, appliquez ces trois mesures : 1) Limitez l'accès direct aux bases de données de prod via VPN et restriction IP. 2) Imposez le principe des quatre yeux pour toute modif de conf critique. 3) Mettez en place un fournisseur d'identité centralisé permettant de révoquer tous les accès d'un employé en un seul clic en cas de départ.

C'est une bonne idée d'avoir ouvert ce sujet.

Je vais raconter ce qui m'est arrivé, ça pourrait vous servir. La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Merci d'avoir écrit cela, c'est exactement ça. Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé.

Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé. Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Je parle du point de vue du fournisseur c'est mon côté. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

Voilà désolé si je me suis étendu.

Merci d'avoir écrit cela, c'est exactement ça. Une sauvegarde non testée n'est pas une sauvegarde.

À votre place, j'irais par cette voie.

Exactement, et ce n'est pas si connu que ça. La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort.

chez nous, ça s'est passé comme ça. lors de la prise de décision, écrivez aussi le pire scénario pas seulement le meilleur.

si vous obtenez trois réponses différentes sur un sujet, la question est mal posée. bref corrigez-moi si je me trompe.

Merci de partager le résultat.

On en parle beaucoup, mais chez nous, cela ne s'est jamais passé ainsi. Si c'est une première, commencez petit, l'échelle viendra plus tard.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Je vais résumer le sujet, car plusieurs réponses différentes ont été données. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

Si c'est une première, commencez petit l'échelle viendra plus tard. Bien sûr cela change si votre situation est différente.

Je suis entièrement d'accord. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.