La réponse est vraiment: il n'y a pas de réponse simple oui ou non. Mais la sécurité est au moins aussi importante pour vos utilisateurs de développement que pour n'importe qui d'autre.
D'une part, oui, les développeurs ont tendance à être techniquement plus avertis. D'un autre côté, leur travail est souvent stressant et leurs étapes de développement sont susceptibles de prendre le pas sur les soins supplémentaires nécessaires pour maintenir leur propre système en tant qu'environnement sécurisé. Ce n'est pas une critique des développeurs; c'est une considération directe de leurs tâches quotidiennes.
Si vous allez donner aux développeurs un accès complet et sans entrave à leurs systèmes, vous devriez vraiment envisager les mesures supplémentaires suivantes:
- Fournissez un autre système, verrouillé autant que les systèmes utilisateur normaux, pour une utilisation normale sans dev.
- Ils mettent leurs machines de développement à accès complet dans un VLAN spécial, avec accès uniquement aux ressources de développement.
- Demandez si quelque chose empêcherait un système infecté de mettre en danger la base de code. Une machine détournée pourrait-elle archiver du code malveillant ou effacer la base de code entre les mains d'un pirate hostile? Prenez les mesures appropriées pour atténuer ce risque.
- De même, demandez si quelque chose protège les données commerciales détenues dans les systèmes auxquels les développeurs ont accès.
- Effectuez régulièrement un inventaire des logiciels et un audit de sécurité des systèmes de développement.
- Faites-vous une idée de ce qu'ils exécutent et utilisez ces informations pour créer vos images de redéploiement de système de développement.
- Tôt ou tard, vous aurez un développeur qui devient négligent et installe des choses clairement dangereuses ou complètement sans rapport avec le travail. En envoyant rapidement des avertissements lorsque cela se produit, vous informerez la communauté des développeurs que oui, quelqu'un regarde et qu'ils ont la responsabilité de respecter des normes raisonnables.
- Faites-vous régulièrement des analyses de logiciels malveillants? Dans certains cas, les développeurs se plaindront à juste titre de la taxe sur les performances perçue par les systèmes audiovisuels à l'accès (ces systèmes audiovisuels qui sont toujours activés, scannant toujours à chaque accès aux fichiers). Il peut être préférable de passer à une stratégie d'analyse nocturne et / ou de créer des exclusions de fichiers / dossiers à votre analyse sur accès. Assurez-vous cependant que les fichiers exclus sont analysés d'une autre manière.
- Vos développeurs avec admin peuvent-ils désactiver toutes les analyses AV? Comment pourriez-vous détecter et corriger cela?
Si vous envisagez de verrouiller des systèmes de développement, vous devez prendre en compte les éléments suivants:
- Avez-vous la capacité d'assistance pour répondre rapidement à leurs demandes d'assistance? Tenez compte du taux de rémunération moyen de vos développeurs et demandez-leur s'ils méritent ou non un SLA à temps de réponse plus rapide. Il n'est probablement pas logique de laisser votre développeur de 120 000 $ (qui est la clé d'un projet de plusieurs millions de dollars) attendre pendant que vous gérez les demandes d'assistance de 60 000 $ par an.
- Avez-vous une politique claire et sans ambiguïté sur les demandes de support que vous répondrez ou non à vos développeurs? S'ils commencent à ressentir que le soutien est arbitraire, vous finirez par ressentir la douleur.
Quoi qu'il en soit, vous devez admettre que les développeurs sont un cas spécial et qu'ils ont besoin d'un support supplémentaire quelconque. Si vous ne prévoyez pas de budget pour cela, les problèmes s'atténuent probablement en ce moment ... ou le seront à l'avenir.
En remarque, j'ai vu des arguments très similaires se produire avec les administrateurs système. Sur au moins deux tâches différentes, j'ai vu des administrateurs système se disputer assez acrimoniquement lorsqu'il a été suggéré qu'ils devraient eux-mêmes avoir verrouillé les systèmes, ou au moins utiliser deux connexions (une avec des privilèges root / admin; une sans). De nombreux administrateurs système ont estimé qu'ils ne devaient en aucun cas être verrouillés et ont vigoureusement plaidé contre de telles mesures. Tôt ou tard, un administrateur opposé au verrouillage aurait un incident de sécurité et l'exemple aurait un effet éducatif sur nous tous.
J'étais l'un de ces administrateurs système qui fonctionnaient avec des privilèges d'administrateur tout le temps. Lorsque j'ai changé de compte double et que je n'ai augmenté que si nécessaire, j'avoue que c'était assez frustrant au cours des premiers mois. Mais la médaille d'argent dans le cloud était que j'en apprenais beaucoup plus sur la sécurité des systèmes que j'administrais, lorsque mon compte normal vivait sous les mêmes restrictions que celles que j'imposais aux utilisateurs. Cela m'a fait un meilleur administrateur! Je soupçonne que c'est la même chose pour les développeurs. Et heureusement, dans le monde Windows, nous avons maintenant l'UAC, ce qui facilite l'exécution en tant qu'utilisateur limité et n'élève que lorsque cela est nécessaire.
Personnellement, je ne pense pas que quiconque devrait être au-dessus d'une certaine forme de pratiques de sécurité. Tout le monde (administrateurs système, développeurs, cadres supérieurs inclus) devrait être soumis à suffisamment de procédures de sécurité et de surveillance pour les garder sur leurs gardes. Dire le contraire, c'est dire que les systèmes et les données de l'entreprise ne valent pas la peine d'être protégés.
Mettons les choses autrement. Si Mark Russinovich peut être capturé par un rootkit , tout le monde le peut!