je veux lancer un site mais n'ayant aucune compétence en dev je vais mandater des devs

mais un truc de chifonne si un dev décide par la suite de me hacker ou me saboter il a les clés du site vu qu'il l'a construit

d'ailleurs je soupçonne les attaques sur Twitter comme du sabotage en interne

c'est quoi les dispositifs généralement pour empêcher ça ?

Le 18 juillet 2020 à 17:47:03 Juvdocom a écrit :

c'est quoi les dispositifs généralement pour empêcher ça ?

Bosser le code.

Dans ce cas là tu ne fais plus confiance à personne. Qui te dit que le serrurier ne fait pas des doublons de tes clés. Qui te dit que le technicien dans le datacenter n'accède pas aux disques durs. Qui te dit que le garagiste ne sabote pas ta voiture. Qui te dit ... tu as compris le principe

Des que tu fais faire par quelqu'un d'autre il y a un risque malheureusement.

Le 18 juillet 2020 à 19:14:22 gunrell a écrit :
Dans ce cas là tu ne fais plus confiance à personne. Qui te dit que le serrurier ne fait pas des doublons de tes clés. Qui te dit que le technicien dans le datacenter n'accède pas aux disques durs. Qui te dit que le garagiste ne sabote pas ta voiture. Qui te dit ... tu as compris le principe

Des que tu fais faire par quelqu'un d'autre il y a un risque malheureusement.

Ouai puis un dev en a rien a foutre du contenu de ton site c'est juste le code qui l'interesse

Je suis dev et j'ai accès à la prod, donc je m'estime légitime à répondre

La question m'a déjà traversé l'esprit par curiosité intellectuelle (parce qu'il n'existe pas que le sabotage, il y a également la part non intentionelle qui est la maladresse, et en tant qu'être humain je ne m'en estime pas dépourvu).

Je dirais que le dev risque gros, suffisamment pour ne pas prendre sa chance :
- On peut t'identifier personnellement
- Il peut (très souvent) y avoir des répercussions pénales
- Par le bouche à oreille tu vas te faire blacklister de partout
- Corrollaire du pénal, ça risque de te coûter cher financièrement

Généralement, ce genre de problématique trouve une partie de sa réponse dans la gestion des niveaux d'accès et les journaux d'actions. Typiquement, un⋅e développeur⋅euse ne doit peut-être pas avoir accès à une production et doit sans doute être limité⋅e à la préproduction. Chaque personne doit avoir son propre identifiant et les actions doivent être journalisées afin de savoir qui a fait quoi et quand (accès SSH, push GIT, connexion au backoffice, etc.).
Tu peux aussi autoriser des choses à une personne puis révoquer ses droits pour diminuer les risques (accès serveur, accès au backoffice, etc.).

Tout cela ne traite pas des potentielles backdoor mais en cas de litige, tu pourras faire analyser le code par un cabinet d'expertise et éventuellement prouver (ou pas) la volonté de casser des trucs.

Dans ma carrière actuelle, je n'ai jamais été confronté à ça. Je ne dis pas que je ne peux pas le faire ou que les collègues n'ont jamais pu le faire mais c'est juste qu'on s'en tape de ton site.

En tant que dev en agence, je vais répondre au même titre que villeArgileuse et deepblue : on a bien souvent accès à tout pour foutre le site qu'on a fait en l'air mais on s'en tape. Déjà parce qu'on connait les risques si ça nous retombe dessus (identification via les logs) et ensuite on a pas grand chose à faire de défoncer un site.

A moins que le dev soit un ami à toi et que tu t'embrouilles personnellement avec lui, si c'et quelqu'un que tu as engagé il va faire son travail tout simplement