1) employés d'écriture du code malveillant pour détruire votre serveur
2) employés lire toutes votre base de données des informations sensibles
Ne pas accorder aux employés l'accès au serveur, sauf pour quelle application frontale ils utilisent. (En supposant que les « employés » étant des gens qui utilisation logiciels de l'entreprise, et non les créer.)
3) généralement les programmeurs qui ont accès à votre back-end et les dommages potentiels qu'ils peuvent faire.
C'est presque impossible à réaliser. Si vous ne pouvez pas faire confiance à vos programmeurs pour ne pas endommager votre back-end, vous avez besoin de nouveaux programmeurs. Fin de l'histoire. Vous pouvez restreindre les droits d'accès à certaines parties du code, appliquer une liste de contrôle d'accès stricte, faire travailler uniquement les parties de code auxquelles ils sont affectés, etc. Mais la règle de base dans la grande majorité des projets est la suivante: Si un programmeur veut faire des dégâts, il peut peut. Surtout en PHP.
Cela peut être différent dans les projets volumineux comme Windows ou le noyau Linux, où tout code vérifié dans le référentiel central est étroitement surveillé. Mais je ne pense pas que nous parlions de ce genre de dimensions ici.
Questions connexes avec beaucoup de commentaires supplémentaires (et propositions de mesures techniques réelles, si vous souhaitez utiliser celles-ci):
+1 Mes pensées. –
Oui, la seule façon de gérer un programmeur de confiance est de le remplacer par un programmeur. Mais avant de faire cela, vos programmeurs back-end ont-ils réellement fait quelque chose pour abuser de votre confiance? Une autre approche consiste à écrire vous-même les éléments dorsaux importants en tant que composant séparé, avec des informations d'identification DB distinctes. Mais en tant que professionnel, je ne travaillerais pas en dehors du cercle de confiance ... –