Ordinateurs d'entreprise pour les développeurs compétents, comment pouvez-vous les gérer?

Question

Ceci est un suivi Y a-t-il une raison légitime pour laquelle je devrais être obligé d'utiliser l'ordinateur de mon entreprise . Surtout parce que je vois un énorme problème dans quelques situations spécifiques.

Si j'avais été en position d'ingénieur de sécurité pour une organisation, je mettrais définitivement une politique selon laquelle seuls les ordinateurs de l'entreprise devraient être utilisés. Cela a du sens et protège non seulement les données de l'entreprise, mais également la responsabilité des employés.

Pourtant, il y a un cas où une telle politique me dérange: un développeur compétent (je ne parle pas d'un développeur junior, je parle d'un développeur de niveau moyen à senior) aura potentiellement sur sa machine de travail:

17 moteurs de base de données;
20 conteneurs dockers;
10 machines virtuelles de test (disons en utilisant quelque chose comme qemu).

C'est un scénario très courant dans les startups et les post-startups (une startup qui a réussi à survivre plusieurs années). De plus, ce développeur changera chaque semaine ses conteneurs Docker et ses machines virtuelles, car il testera probablement de nouvelles technologies.

Exiger que ce développeur se réfère à l'ingénieur de sécurité pour installer de nouveaux logiciels à chaque fois est complètement impossible. De plus, étant donné qu'une entreprise aurait plus d'un développeur de ce type, choisir les ordinateurs gérés par l'entreprise pour tout le monde présente des inconvénients:

La maintenance des ordinateurs de, disons, six de ces développeurs est un travail à plein temps pour un ingénieur en sécurité compétent.
Le manager de ces développeurs sera terriblement en colère car ce que son équipe fait pour 50% de son temps de travail, c'est d'attendre l'ingénieur sécurité.

D'un autre côté, permettre aux développeurs d'utiliser librement les machines est dangereux: un conteneur de docker escroc ou une machine virtuelle et vous avez un initié. Je dirais même que les ordinateurs de ces développeurs sont plus dangereux que ceux d'un utilisateur ordinaire (par exemple, un gestionnaire avec un tableur).

Comment faites-vous des politiques sensées pour les développeurs compétents?

Voici quelques autres solutions auxquelles j'ai pu penser (ou que j'ai vues dans le passé), dont la plupart étaient plutôt mauvaises:

Interdisez l'accès à Internet depuis les machines de développement:
- Vous avez besoin d'un accès Internet pour lire la documentation;
- Vous devez accéder à des référentiels, souvent trouvés sur Internet.
Donnez aux développeurs deux ordinateurs, un pour Internet et un pour les machines de développement:
- Plaintes concernant une perte de productivité: en tapant Alt+2 pour obtenir le navigateur est plus rapide que de passer à un autre ordinateur;
- L'accès au référentiel est lourd: téléchargez-le à un endroit, copiez-le à l'autre.
- Encourage le développeur à contourner la sécurité et à établir une connexion USB entre les deux machines, afin qu'il puisse travailler à partir d'un seul ordinateur (cela s'est produit plus d'une fois).
Déplacer le développement vers les serveurs (c'est-à-dire pas le développement sur les machines de bureau):
- Cela ne fait qu'aggraver le même problème, maintenant le conteneur escroc est sur le serveur;
- Sans doute pire que de permettre au développeur de faire ce qu'il veut sur sa propre machine.

Il doit y avoir un meilleur moyen.

paj28 · Accepted Answer

Développement et production séparés

Il est courant de donner aux développeurs des droits d'administrateur/root locaux sur leur poste de travail. Cependant, les développeurs ne doivent avoir accès qu'aux environnements de développement et ne doivent jamais avoir accès aux données en direct. Les administrateurs système - qui ont accès à la production - devraient disposer de postes de travail beaucoup plus contrôlés. Idéalement, les postes de travail sys-admin ne devraient pas avoir accès à Internet, bien que cela soit rare dans la pratique.

Une variante que j'ai vue est que les développeurs ont une version d'entreprise verrouillée, mais peuvent faire ce qu'ils veulent au sein des machines virtuelles. Cependant, cela peut être gênant pour les développeurs, car les machines virtuelles ont des performances réduites et les avantages de sécurité ne sont pas si grands. Il est donc plus courant de voir les développeurs avoir simplement un accès complet à leur propre poste de travail.

coteyr · Answer

Cette réponse vient donc du point de vue d'un développeur. Garde cela à l'esprit.

Tout d'abord, le fait de ne pas avoir de droits "d'administrateur local" sur ma propre machine est un signe que je dois chercher un travail ailleurs. Il est presque impossible d'écrire du code, de jouer avec des trucs et de maintenir une chaîne d'outils si vous devez demander la permission à chaque fois que vous devez mettre à jour (ou tester) une nouvelle dépendance ou un nouvel outil. Voici donc les niveaux d'autorisation I requis. Gardez à l'esprit que je suis généralement assez haut sur l'échelle pour ainsi dire.

Admin total et complet sur ma machine locale
Admin total et complet sur tout le matériel de développement et de test
Un certain niveau d'accès administrateur aux serveurs de production (cela devient difficile, je n'ai pas besoin de tout ou tout, mais j'ai besoin de suffisamment pour diagnostiquer et résoudre les problèmes qui se produisent en production, et assez pour déployer réellement le code (en supposant que je suis le seul) qui doit superviser le déploiement du code). Habituellement, ce niveau d'accès évolue avec le temps, mais commence par les fichiers journaux.

Moins que cela, et vous pouvez aller trouver un nouveau développeur.

Cela dit, ce niveau d'accès comporte beaucoup de risques. Donc, ce que je recommande normalement, c'est un réseau séparé. Mettez tous les "trucs" de développement dans son propre réseau. Son propre AD, son propre hébergement de fichiers, son propre tout, et ne le laissez jamais parler au réseau de production. (Mais laissez-le sortir sur Internet)

Oui, cela signifie du matériel en double (ou VPS), mais vous en avez besoin de toute façon pour les tests. Oui, cela signifie un peu plus de frais généraux lors de la mise à niveau ou de l'administration, mais encore une fois, cela est nécessaire pour les tests. Vous avez également besoin d'un emplacement pour voir "Qu'advient-il du logiciel X si je mets à niveau le serveur AD?" Regardez que vous disposez d'un réseau complet de machines de test prêtes pour ce type de test.

Ce que j'ai réussi à mettre en œuvre (avec l'aide d'une bonne équipe informatique) est un VLAN distinct pour tous les "trucs" de développement et un seul hôte VPS auquel le développeur a un accès complet, pour faire ce qu'il veut . Sur cet hôte se trouve un serveur AD configuré par l'informatique pour ressembler à une version plus petite du serveur AD de l'entreprise. Ensuite, un ensemble de documents et de directives pour ce qu'un serveur Web, par exemple, doit exécuter. Ce qu'un serveur DNS doit exécuter, ce qu'un serveur xyz doit exécuter. Ensuite, une partie du "développement" consiste à installer et configurer ces VPS pour notre utilisation. Tout ce qui se trouve sur ce VLAN est totalement isolé de la production et considéré comme externe à l'entreprise. Enfin, un ensemble de "punch throughs" est créé pour les actifs auxquels nous avons eu besoin d'accéder (comme le courrier électronique). Normalement, cela était traité comme si nous étions externes, et la liste de ces outils était très petite.

Ray · Answer

Du point de vue d'un développeur:

Votre travail consiste à empêcher le changement (les bogues et vulnérabilités connus sont meilleurs qu'inconnus, non?), Mais le mien est de changer les choses. Cela nous place dans une impasse. Mon travail consiste à créer/changer des choses. Si votre politique empêche cela, alors, comme tout autre obstacle, une partie de mon travail consiste à trouver un moyen de contourner cela.

Selon vous, quel est le plus dangereux, un développeur auquel vous avez accordé l'accès aux choses dont il a besoin pour faire son travail, ou celui qui a obtenu cet accès en apprenant à contourner toutes vos mesures défensives? Et pourquoi votre entreprise vous paie-t-elle, vous et vos développeurs, pour mener cette guerre les uns contre les autres alors que vous devriez travailler ensemble?

La réponse est simple: donner aux développeurs l'accès à ce dont ils ont besoin pour faire leur travail. Et parlez avec eux. Il peut y avoir des conditions rares (rétro-ingénierie de salle blanche avec des conséquences juridiques majeures, ou traitement de données gouvernementales classifiées top secrètes) où vous avez besoin d'une politique plus compliquée. Mais pour la plupart, ce n'est pas si grave. Si vous déclenchez une guerre et rendez vos développeurs ennemis, ils partiront ou deviendront beaucoup plus dangereux que si vous travaillez avec eux.

Les mesures judicieuses incluent l'interdiction des vidages de base de données de production sur les ordinateurs portables de développement (test uniquement des bases de données avec des données fausses). De cette façon, si l'ordinateur portable est volé, aucune donnée confidentielle n'est perdue. Mais si le développeur doit déboguer des choses, il a toujours besoin d'accéder à des copies de la base de données de production quelque part dans un environnement contrôlé.

Restreindre l'accès à Internet est ridicule. Vous pourriez aussi bien demander à tous vos développeurs d'écrire leur code sur papier avec une plume et de l'encre.

Discutez avec vos développeurs, trouvez un moyen de leur donner ce dont ils ont besoin pour faire leur travail tout en maintenant la sécurité dont vous avez besoin pour sécuriser les données importantes. Les détails dépendront de votre entreprise et des données avec lesquelles vous traitez. Mais il est peu probable qu'il ait besoin de mesures draconiennes.

Lucas Kauffman · Answer

Un ingénieur en sécurité n'entretient pas d'ordinateurs, c'est ce que fait le service desk. Dans votre cas, vous lui demanderez d'installer trois outils:

un hyperviseur
docker
logiciel de base de données

De là, il peut ajouter et supprimer des machines pour le développement autant qu'il le souhaite (ne devrait pas nécessiter l'intervention d'un ingénieur sec). En ce qui concerne votre "conteneur voyou". En général, vous ne déployez pas de conteneurs sur un autre serveur, vous déployez des fichiers docker qui extraient du code d'un référentiel de code ou téléchargent un binaire signé de code compilé (ce qui est encore plus sûr).

En termes de voyous, je ne peux qu'imaginer qu'un attaquant accède et ajoute plus de code. C'est pourquoi vous devez avoir une sécurité intégrée à chaque étape du SDLC pour vous assurer que tout le code est au moins examiné ou passé par un autre développeur avant de le pousser dans l'arborescence. De plus, vous pouvez également intégrer des scanners de code pour rechercher automatiquement les talons de code suspects ou vulnérables.

Sur votre troisième point, cela dépend en fait. Des entreprises comme Riot Games font exactement cela. Ils ont découvert que limiter les individus intelligents les conduirait à contourner les contrôles. Ils ont donc décidé d'utiliser des règles simples et une formation de sensibilisation efficace pour s'assurer de garder la sécurité à l'esprit et de leur accorder tous les privilèges administratifs. Ils ont distribué de petites cartes indiquant ce dont ils devaient s'occuper et faire attention.

Martijn Heemels · Answer

Nous donnons à nos développeurs un accès administrateur sur leurs ordinateurs et leur faisons savoir quelles sont les règles. La plupart exécutent Linux mais nous avons également quelques développeurs sur Windows. Ils savent tous stocker leurs documents, designs, etc. sur nos fichiers partagés (qui ont des autorisations plus spécifiques) et pousser leur code source sur notre serveur Git.

Ils savent également que je ne passerai pas beaucoup de temps à résoudre un problème avec leur système d'exploitation. En cas de dysfonctionnement de leur ordinateur, nous le nettoyons souvent et réinstallons le système d'exploitation. Les applications et les paramètres communs sont automatiquement installés via Puppet et ils devront faire le reste eux-mêmes. La plupart d'entre eux ont un dépôt Git avec des fichiers dot (les paramètres et les préférences pour leur environnement).

Le temps qu'ils perdent dans un tel cas est une motivation suffisante pour la plupart d'entre eux. Ils aiment faire le travail, au lieu de jouer avec la réparation de leur système d'exploitation. S'ils perdent un travail important parce qu'il n'a été stocké que localement, leurs collègues et leur patron les désapprouveront.

Nous ne bloquons aucun site Web ou application (à l'exception d'un filtre anti-malware basé sur DNS), mais nous avons des règles de politique d'entreprise concernant des choses comme les logiciels illégaux. Nous comptons sur la pression des pairs pour la plupart des choses. Les gens qui passent leur temps sur Facebook ne sont pas productifs et ne durent pas longtemps. Une grande partie de nos politiques sont basées sur un système d'honneur et cela semble bien fonctionner.

James_pic · Answer

Cela dépend fondamentalement du contexte. Considérez les deux configurations suivantes, que j'ai rencontrées dans la nature:

Les développeurs travaillent sur des machines dont ils sont propriétaires ou auxquels ils ont un accès complet, y compris l'installation de leurs propres systèmes d'exploitation. Il n'y a aucune restriction sur la façon dont ils écrivent l'application. Ils ont un accès SSH aux systèmes de production chaque fois qu'ils sont connectés au réseau, y compris VPN.
Tout le développement se fait dans un laboratoire de développement restreint, dans lequel les développeurs ne sont pas autorisés à introduire des appareils électroniques. Tous les ordinateurs ont tous les logiciels autorisés préinstallés. Les artefacts déployables sont livrés en toute sécurité sur un support physique à une autre équipe, qui est responsable du déploiement.

Ces deux configurations étaient appropriées dans leur contexte - en tenant compte des menaces auxquelles l'organisation était confrontée et des besoins du projet.

Il y a un compromis fondamental ici. Tout éloignement de la première possibilité, vers la seconde, réduit la productivité. Quiconque a un contrôle sur l'application est dans une position de confiance. Tout ce que vous ne pouvez pas leur faire confiance est quelque chose dont vous devrez vous passer, ou créer un processus de transfert pour que quelqu'un d'autre le fasse. Vous ne pouvez pas révoquer la confiance sans réduire la productivité.

mgjk · Answer

Cela dépend du type de logiciel que vous développez et de la taille de votre organisation.

Pour une station de travail de développeur Rockstar unique dans une petite entreprise, j'utiliserais une exception de sécurité de niveau exécutif. Les risques (y compris l'ennui de l'informatique, des cadres et des collègues développeurs) devraient être discutés, mais en fin de compte, si la rockstar ne réussit pas, il va probablement déménager dans une autre société. Ces gars ne tolèrent pas les frictions, s'ils les rencontrent, ils peuvent facilement trouver des endroits plus intéressants pour travailler.

Un scénario plus typique qu'un uber-workstation est d'avoir un cluster de développement où les opérations gèrent la vie et la mort des machines virtuelles, l'environnement est surveillé avec IDS/IPS et l'accès Internet (sur le cluster de développement) est limité mais ouvert selon les besoins . Par exemple, pour la documentation ... rien de mal à mettre en liste blanche toutes les sources de technologie liées à votre effort de développement. Les développeurs ne peuvent pas tirer le code de toute façon. Ils doivent documenter leurs sources et vérifier les licences étranges.

Si vous pouvez obtenir l'oreille de la rockstar, il peut aider à repousser les exigences des opérations et des cadres et à architecturer le cluster et les processus, et éduquer les équipes de développement sur le besoin.

S'il y a un budget et que le développeur est réticent ... alors à mon humble avis, vous n'avez pas affaire à une rockstar, mais une diva et ses gémissements devraient être portés jusqu'à l'approbation du risque exécutif.

La partie la plus difficile devient la gestion de la durée de vie des machines et la garantie que les réflexions des développeurs ne deviennent pas des systèmes de production de développeurs "comme des opérations". Mais c'est beaucoup plus facile que les VM sur les postes de travail des développeurs.

Tim X · Answer

Cette question soulève un certain nombre de questions et de défis intéressants. En tant que personne qui a travaillé en tant que développeur pendant de nombreuses années et est ensuite passée à la sécurité, je peux apprécier bon nombre des arguments et points de vue exprimés dans les réponses et les commentaires. Malheureusement, il n'y a pas de réponse définitive car la bonne solution dépend du contexte, de l'exposition au risque et de l'appétit pour le risque de l'organisation.

La sécurité n'est pas quelque chose que vous pouvez mesurer en termes absolus. Chaque fois que vous rencontrez un responsable de la sécurité qui parle constamment dans des absolus et insiste pour appliquer des politiques spécifiques, indépendamment de toute autre chose, est inexpérimenté ou incompétent. Le rôle de l'ingénieur de sécurité est de faciliter les processus métier, et non de les entraver, et de garantir la prise de décisions commerciales éclairées par les risques de sécurité pertinents. Un bon ingénieur en sécurité sait que toute politique qui empêche le personnel de faire son travail échouera inévitablement, car le personnel trouvera des moyens de contourner la politique. Le plus souvent, ces solutions de contournement seront encore moins sécurisées. Il est de la responsabilité du responsable de la sécurité de comprendre les différents rôles au sein de l'organisation et de veiller à ce que les politiques soient structurées de manière à non seulement soutenir ce que le rôle requiert, mais encourager les bonnes pratiques et décourager les mauvaises. Cela peut être difficile à varier, en particulier dans les grandes organisations. Dans le même temps, les développeurs et les autres membres de l'organisation doivent également reconnaître qu'ils peuvent ne pas disposer de toutes les informations pertinentes pour comprendre pourquoi certaines stratégies sont requises. Trop souvent, les développeurs et d'autres considèrent l'ingénieur de sécurité comme un obstacle ou un bureaucrate interférant qui ne comprend pas ce dont ils ont besoin pour faire leur travail.

Plus souvent qu'autrement, la façon d'aborder ces problèmes passe par la communication. J'ai souvent eu des développeurs frustrés parce qu'une politique qu'ils jugent inutile se met en travers de leur chemin. Une fois que nous nous sommes assis et avons discuté de la question, un certain nombre de choses se produisent généralement;

Le développeur a soit mal interprété la politique, soit y a lu des hypothèses qui sont incorrectes et, étant donné l'impression que la politique empêche quelque chose qu'elle ne fait pas. Cela se traduira souvent par une révision de la politique pour améliorer la clarté
L'ingénieur de sécurité prend conscience d'une exigence commerciale légitime qui doit être satisfaite de manière à maintenir des contrôles de sécurité adéquats. Cela entraînera probablement une révision de la politique.
Le développeur prend conscience d'une autre exigence ou d'un autre risque qui n'étaient pas évidents pour lui au départ. Cela conduit souvent le développeur à identifier des solutions alternatives pour répondre à leurs besoins
Un problème est identifié qui ne peut être résolu à la satisfaction de l'une ou l'autre partie d'une manière qui respecte l'appétit pour le risque accepté de l'organisation (c'est-à-dire les niveaux de risque acceptés). Cette situation se traduira généralement par une escalade du problème au niveau exécutif pour une décision. La difficulté de le faire dépendra de la taille et de la structure de l'organisation. Une fois la décision prise, le développeur et l'ingénieur en sécurité doivent travailler selon les paramètres définis par l'exécutif pour trouver la meilleure solution possible.

Un certain nombre de réponses ont critiqué les politiques qui ont un impact négatif sur leur niveau de productivité. Alors que tout développeur devrait soulever de telles préoccupations, en fin de compte, il doit soit accepter la décision prise par l'exécutif, soit rechercher un autre employeur. Supposer que vous savez mieux ou que vous avez un droit spécial d'ignorer la politique est arrogant et dangereux pour vous et votre employeur. Si vous êtes convaincu que vous avez raison, alors vous devriez être en mesure de convaincre la direction. Si vous ne pouvez pas, soit vous n'êtes pas aussi bon que vous le pensez, vous n'avez pas les compétences de communication adéquates pour présenter un argument convaincant, vous ne possédez pas toutes les informations ou vous travaillez pour un employeur incompétent. Après 35 ans dans l'industrie et malgré ce que Dilbert peut vous faire penser, ce dernier n'est pas aussi courant que vous ne le pensez. La source de conflit la plus courante dans ce domaine est due à de mauvaises communications et au manque d'informations.

Un échec courant parmi les développeurs (et dont je suis coupable) est de se concentrer tellement sur votre tâche ou objectif spécifique que vous manquez la vue d'ensemble que les chefs d'équipe, les gestionnaires et les cadres doivent également gérer. Environnements où les développeurs ont eu beaucoup de liberté et de confiance, ce qui a entraîné des niveaux de productivité élevés, mais cela a entraîné d'autres problèmes - la situation où un développeur clé est parti ou est tombé malade pendant une longue période et personne d'autre peut reprendre son travail car tout se trouve sur son bureau configuré et géré de manière unique ou essayer de déboguer un problème difficile qui ne peut pas être facilement reproduit en raison d'un manque de configurations/configurations standard, ou faire face à une éventuelle brèche de sécurité due à un développeur quittant accidentellement certains services en cours d'exécution étaient en cours de développement et manquaient de contrôles de sécurité standard. Être un développeur concentré sur un domaine ou une technologie spécifique ne garantit pas non plus une expertise dans tout le reste. Certains des meilleurs développeurs avec lesquels j'ai travaillé ont été parmi les pires en matière de sécurité et/ou de gestion de leur environnement. Cela est probablement dû en partie à l'accent mis sur un problème spécifique et plus probablement simplement à la capacité. Aucun de nous n'a la capacité de traverser tout et nous devons reconnaître qu'il est parfois important de s'en remettre à ceux qui se spécialisent dans des domaines que nous n'avons pas.

L'environnement en mutation

L'une des principales raisons des politiques qui restreignent ce qui peut être fait sur le bureau est due à l'hypothèse sous-jacente que les bureaux au sein du réseau local ont un niveau de confiance plus élevé que les bureaux à l'extérieur du réseau. Traditionnellement, ils se trouvent à l'intérieur du pare-feu et d'autres défenses du périmètre et ont un accès mobile aux ressources d'information. Cela signifie qu'ils présentent un risque plus élevé et ont donc besoin de plus de contrôles de sécurité. Les autres raisons des politiques/pratiques restrictives incluent la standardisation des environnements, ce qui peut réduire les coûts de support et augmenter la cohérence (ce qui était particulièrement vrai quand il y avait plus d'applications où dépendaient de la plate-forme/du système d'exploitation - rappelez-vous toutes ces horribles applications qui nécessitaient AtiveX ou une version spécifique de C'EST À DIRE).

La croissance des machines et conteneurs virtuels, des services cloud et des services informatiques de base et l'augmentation de la capacité du réseau entraînent un certain nombre de changements qui rendront probablement bon nombre des problèmes soulevés dans ce fil de discussion. En particulier, la transition vers des réseaux de confiance zéro verra probablement des changements importants. Dans un réseau à confiance nulle, les périphériques à l'intérieur du réseau ne sont pas considérés comme ayant un niveau de confiance supplémentaire spécial par rapport aux périphériques à l'extérieur du réseau. Vous n'avez pas la possibilité d'accéder aux ressources simplement parce que vous avez la bonne adresse IP. Au lieu de cela, la confiance repose davantage sur une combinaison d'informations sur l'utilisateur et l'appareil. La politique qui détermine ce à quoi vous pouvez accéder est déterminée par vos informations d'identification et l'appareil à partir duquel vous vous connectez. L'endroit où se trouve cet appareil n'a pas d'importance. Il s'agit également d'un modèle qui correspond beaucoup mieux à la croissance du BYOD et à la mobilité accrue de la main-d'œuvre et aux demandes croissantes d'employer du personnel en fonction des seuils/capacités et non de la situation géographique.

Une fois que vous avez supprimé le niveau de "confiance" associé à l'appareil, vous n'avez plus besoin de contrôler ce que vous pouvez appliquer à l'appareil. Vous pouvez toujours exiger que les appareils prennent en charge des profils spécifiques - par exemple, vous pouvez refuser d'autoriser quiconque à accéder à vos ressources si son appareil exécute Windows XP etc., cependant, vous êtes moins préoccupé par l'appareil. De même, vous ne ferez pas autant de travail directement sur l'appareil. Dans une certaine mesure, l'appareil ressemblera plus à un client léger. Vous utiliserez des machines virtuelles et des conteneurs hébergés à distance. Cela ne résoudra pas en soi tous les problèmes et peut être vu comme simplement déplacer certains d'entre eux du bureau local vers le distant VM ou conteneur. Cependant, une fois que vous combinez cela avec diverses orchestrations de style DevOps, de nombreuses raisons pour lesquelles les développeurs peuvent avoir besoin de privilèges améliorés sont supprimés. Par exemple, il se peut que vous n'ayez pas besoin d'accéder aux systèmes de production. La promotion du nouveau code sera gérée via un système d'intégration continue orchestré et lorsque vous devrez déboguer un problème, vous recevrez un VM ou conteneur qui est un clone exact de la production système.

Aucun de ces changements ne résoudra par magie quoi que ce soit, mais ils fourniront une gamme plus large d'outils et de solutions plus flexibles avec potentiellement moins de complexité. La réduction de la complexité facilitera la gestion de la sécurité. Une gestion plus aisée de la sécurité entraînera des restrictions ou des obstacles moins involontaires ou inutiles à l'exécution des tâches. Cependant, au bout du compte, les principales exigences sont

Reconnaissance par tous qu'une taille unique ne convient pas à tous. Tout doit être évalué dans le contexte de l'organisation.
Volonté de donner la priorité aux besoins de l'organisation.
Bonne communication bidirectionnelle.
Volonté pour toutes les parties de rechercher des solutions mutuellement acceptables et
Volonté de compromis entre toutes les parties
Volonté de travailler au sein du système et d'ajuster votre flux de travail ou votre façon préférée de faire les choses pour s'adapter aux exigences de l'organisation

Lucas · Answer

Je suis également développeur et voici mon avis:

Le problème est pire que vous ne le pensez

Il n'y a pas de cuillère

Le développement n'est pas une question de logiciel. Le développement consiste à fabriquer ou à améliorer des produits, des services et des processus. Le logiciel est un équipement important mais n'est pas le seul. Les bons développeurs définiront les processus au sens large pour savoir quels composants logiciels créer ainsi que les processus humains, logistiques et de gestion des risques à proposer. Cela n'a aucun sens de développer un système logiciel qui dépend de processus humains, logistiques et papier qui ne sont pas mis en œuvre.

Il n'y a pas de règles pour le développement car le développement définit les règles. C'est ce qui fait du développement le pire environnement à sécuriser.

Mais cela ne signifie pas que certains contrôles ne devraient pas être établis. Au contraire, de nombreux contrôles doivent être mis en place par l'équipe de développement elle-même.

Processus d'ingénierie

Il existe des entreprises qui préconisent la séparation entre les entreprises et la technologie dans un processus descendant. Ceci est en fait très populaire car suggère que les gens d'affaires sans connaissances techniques devraient être au top. Les paresseux aiment ça . Mais en ingénierie, une conception descendante ne fonctionne tout simplement pas. Feyman (1985) a fait un bel article à ce sujet dans la commission présidentielle qui a analysé l'explosion du Challenger. Fondamentalement, l'ingénierie des processus descendants finit par briser l'entreprise. Et mon expérience du marché renforce cette compréhension.

L'explosion du Challenger en est un excellent exemple. Les dirigeants de la Nasa témoignent à la caméra lors d'une commission d'enquête qu'ils ont développé un caoutchouc qui peut rester flexible à moins de 60 degrés sous le point de congélation. Une chose qui a été contredite par une simple expérience physique au lycée faite par l'un des commissaires (mettre le composant en caoutchouc dans de l'eau glacée pressée par une pince). C'était un excellent exemple parce que ce composant en caoutchouc devait être flexible pour que le booster n'explose pas; comme il avait besoin de températures estivales pour cela, le booster ne fonctionnait qu'en été. Une caractéristique d'un seul composant définit une caractéristique visible de l'ensemble du produit qui est très limitative.

L'ingénierie doit se faire de bas en haut, car vous devez connaître les limites et les faiblesses de chaque composant pour élaborer des processus pour les atténuer. Plus souvent qu'autrement, les processus d'atténuation ne sont pas des logiciels et affecteront le coût du produit. Cela signifie que les caractéristiques et les limites des composants individuels définiront les caractéristiques des produits, services et processus.

Les processus descendants sont fondamentalement rompus. De nombreuses entreprises qui adoptent cette philosophie sur le papier connaissent toujours un certain succès sur le marché. Mais lorsque vous descendez pour enquêter sur leurs projets les plus importants et les plus réussis, vous apprenez qu'ils ont été menés en dehors des règles normales de l'entreprise. Les plus grands succès sont obtenus lorsqu'une personne ayant une connaissance approfondie de l'ingénierie et une vision du marché est informellement habilitée. Comme cela se produit de manière informelle, la direction pense que le processus descendant fonctionne. Ils considèrent que toutes les autres équipes sont incompétentes. Fermer les yeux sur le fait que l'esquisse initiale du projet lorsqu'elle a quitté la "phase supérieure" a été complètement ignorée et ne décrit pas les produits, les services et les processus mis en place.

Votre responsable peut définir que vous allez concevoir un appareil de téléportation d'ici la fin du mois, car il a conclu que cela permettrait de réaliser des bénéfices élevés dans le secteur du voyage ... mais cela ne le fera pas. Les projets descendants sont comme ça, fixent des attentes qui ne sont pas technologiquement solides.

Ne vous méprenez pas, il est bon de voir le problème sous plusieurs angles. De bas en haut, de haut en bas, de SWOT et plus sont sains pour l'analyse, mais l'effort d'ingénierie véritable est de bas en haut. Il n'y a pas de véritable objectif sans viabilité technique.

Sécurité du développement

Nous devons nous rappeler que les développeurs de logiciels changeront régulièrement le logiciel de l'entreprise et, de cette façon, ils peuvent: modifier ce qui apparaît sur l'écran de n'importe qui, envoyer des e-mails automatisés à quiconque, y compris eux-mêmes, ou ouvrir des portes dérobées à faites ce qu'ils veulent. Cela signifie qu'un criminel engagé en tant que développeur peut causer des dommages importants à l'entreprise.

Pire que cela, il existe de nombreuses entreprises qui n'appliquent pas la provenance d'un référentiel de code source, puis le développeur embauché peut fournir un binaire différent de la source indiquée. Cela permet aux développeurs criminels de détourner les systèmes de l'entreprise, s'ils ne sont pas embauchés, les choses cesseront de fonctionner bientôt.

Pour moi, la sécurité du développement doit se concentrer sur:

Contrôle de version du code source : pour garantir que le code source et les composants tiers nécessaires sont stockés dans un emplacement sécurisé.
Division stratégique du travail : les développeurs juniors et temporaires doivent avoir un accès limité au code source et aux données. Ils ont seulement besoin d'accéder aux composants qu'ils changent pour éviter qu'un développeur junior puisse comprendre le fonctionnement interne de tous les systèmes et être en mesure d'exploiter cela.
Faites confiance aux développeurs principaux : Les développeurs seniors/principaux devront tout savoir, avoir accès à tout, planifier et distribuer les tâches et diagnostiquer les problèmes graves. Ce noyau doit avoir accès à l'ensemble, tant dans le développement que dans la production. Ils sont vos partenaires dans l'élaboration des politiques de sécurité. Nous devons accepter que les développeurs principaux soient propriétaires de l'entreprise. Mon ancien patron disait: "nous avons de la chance que Lucas soit de notre côté, de l'autre il nous détruirait". Les développeurs principaux peuvent faire beaucoup de dégâts s'ils le souhaitent et aucun pare-feu et contrôle de production ne peuvent empêcher cela.
Séparez l'environnement à travers des pare-feu : séparez votre réseau de développement, de votre réseau de test, de votre réseau de production. Sur une entreprise, j'ai défini le réseau 10.1. comme développement, 10.2. comme test et 10.3. comme production. Les réseaux 10.2 et 10.3 reçoivent uniquement du code via le CVS d'entreprise et les construisent automatiquement sur la commande admin. Bien que ce soit une petite startup et j'étais dans la production et dans les équipes de développement, j'ai fait quelques bureaucraties pour éviter mes propres erreurs (les développeurs peuvent être vos meilleurs alliés). J'ai également changé les couleurs du terminal par réseau: lors de la connexion à un serveur de production, l'arrière-plan du terminal était rouge, le test était jaune et le développement vert. Étant donné que tous mes serveurs utilisaient la même configuration, il était facile de les confondre si l'invite était ouverte. D'après mon expérience, la plupart des problèmes proviennent de logiciels mal testés et de nouvelles installations de logiciels. Pour être clair: où vous êtes est à mon avis une fonctionnalité de sécurité puissante. Cela n'a rien à voir avec l'accès, mais c'est la sécurité.
Embaucher un développeur de test qualifié : L'aspect clé des tests est d'avoir de grandes quantités de bonnes données simulées qui sont significatives pour les problèmes auxquels l'entreprise est confrontée. Les simulations Monte-Carlo sont bonnes pour générer de grands ensembles de données qui ont du sens pour d'autres développeurs et peuvent conduire à des logiciels et des processus plus solides et résilients. Pour moi, il n'y a pas d'échecs de "production", le développeur est toujours à blâmer. Les tâches de maintenance et les imprévus doivent être écrits. Le logiciel doit être résilient.
Révision du code source : demandez aux personnes de réviser le code source avant d'accepter la modification. Tous les projets doivent être branchés sur le contrôle de code source et la fusion doit être revue. L'examen du code source ne devrait concerner que la détection de logiciels malveillants, l'escalade d'accès, les profils d'accès et une bonne explication de ce que le code source signifie et doit faire. La qualité du code sera assurée par les tests et non par la révision du code source. Vous pouvez le voir en action dans la plupart des projets open source.
Stratégies de test les tests sont bien plus une culture d'entreprise qu'un framework. Certaines entreprises adoptent des cadres de marché, font des tests, mais la qualité de leur code est mauvaise. Cela se produit parce que vous avez besoin de personnes capables de concevoir des tests significatifs. En fait, le développement doit être piloté par les tests. Je ne connais aucun autre moyen sûr de développement. Et une chose curieuse est que les humains, les achats et la consultation doivent également être testés. Les vendeurs affirment souvent que leurs produits fonctionnent parfaitement, mais je n'ai pas encore trouvé de produit parfait.
Les politiques n'ont aucun sens si elles ne sont pas surveillées . Une entreprise que je connais a une bureaucratie selon laquelle chaque table de base de données devrait avoir une description au niveau de l'attribut. 95% des attributs sont décrits comme "le $ {nom d'attribut} de $ {nom de table}". Il n'explique pas ce qu'est réellement l'attribut, quelles valeurs peuvent contenir et autres.
Rémunération et environnement de travail appropriés . Pour avoir de bons développeurs, à la fois en compétences et en personnalité, vous devez avoir de bonnes politiques de rémunération. L'argent est important, bien sûr, mais ne suffit pas. Vous devez également avoir une perspective/stabilité, une vraie reconnaissance et un bon environnement de travail. Par exemple, au lieu d'un bureau de développement à New York où les gens vivent dans de petits appartements, vous pouvez choisir une petite ville où la même compensation permet une plus grande maison et une plus grande proximité avec le travail. De plus gros ordinateurs, de bons laboratoires sont également un atout pour les passionnés de technologie.
Sécurité des données de nombreuses activités nécessitent des données de production sensibles et doivent être accessibles dans un laboratoire spécial. À moins que vos informations ne soient publiques ou non sensibles, la meilleure politique est peut-être de placer les laboratoires dans de bons quartiers avec un accès physique contrôlé. Autorisez uniquement certaines données simulées à être placées sur des ordinateurs portables personnels et des composants qui ne sont pas sensibles. C'est possible. Par exemple, j'ai développé une archive de données de 4,5 milliards d'enregistrements très consultée pour une entreprise. Je l'ai fait chez moi et n'ai utilisé absolument aucune donnée d'entreprise à cette fin. Lorsque j'ai soumis le code, il a fonctionné comme prévu lors de la première tentative. Outre la défaillance matérielle et la migration des environnements de production, nous avons 100% de disponibilité en 10 ans. Le risque que le développeur emporte le code source avec lui n'est pas pertinent. Ce système particulier m'a pris 3 mois à développer, une grande partie de ce temps a été de comprendre les limites de performances des composants. C'est maintenant une connaissance dans ma tête. Même sans le code source, je peux re-développer cette solution dans environ une semaine maintenant.
Des journaux solides sont importants pour connaître tous ceux qui ont fait quelque chose. Le meilleur ici est que les journaux soient générés par un framework, se connectant pour des écrans détaillés de courte durée, pour des accès et des activités plus longs et encore plus pour les journaux d'entreprise. Mes systèmes critiques se connectent à chaque accès à un écran (y compris la conception de l'écran). Certaines des ressources critiques doivent être enregistrées par un déclencheur sur la base de données elle-même et les tables ou ressources critiques doivent être marquées pour l'audit du code source.
- Le filtrage des journaux est difficile à faire à la main. Apprenez à créer des filtres sur les journaux pour voir les éléments critiques. Un filtre très utile consiste à croiser les rapports de réclamation avec l'accès et les activités des utilisateurs. Si vous avez suffisamment de journaux, vous verrez des coïncidences. Par exemple: avant un problème, user1 se connecte toujours.

À propos de ne pas accéder à la production

Les règles qui exigent que les développeurs n'accèdent pas aux systèmes de production car les utilisateurs sont là pour éviter aux développeurs de soumettre du code pour montrer à leur propre utilisateur des informations privilégiées. Je pense que c'est une mesure de sécurité très, très faible et facile à détecter dans l'audit du code source. Il existe plusieurs moyens simples de contourner cela:

un développeur plus un employé à bas salaire;
s'envoyer un e-mail;
ouvrir une porte dérobée dans le système.

L'audit du code source à la recherche de portes dérobées, d'escalade d'accès et de logiciels malveillants semble plus productif. Il permet d'identifier les mauvais développeurs lorsqu'ils testent leurs exploits et de les licencier. Bien sûr, un développeur qualifié peut cacher un exploit à la vue, il est donc important d'utiliser des langages et des noms de variables clairs et clairs. Ne recourir à des solutions étranges que dans des points documentés des applications qui nécessitent des performances spéciales ou une obfuscation. Par exemple, 1 << 4 est identique à 1 * 16. Cela n'aurait de sens que si le langage ne fait pas cette optimisation par lui-même et que le point où cela se produit est un goulot d'étranglement des performances. Trop de langages symboliques sont mauvais pour cette même raison. Le code source doit être lisible par n'importe quel geek.

Le problème est pire que vous ne le pensez

Les dommages les plus simples et les plus graves qu'un développeur peut causer ne sont pas liés à l'installation de l'outil. Même si l'environnement de développement est géré, cela fera peu de différence si l'entreprise ne dispose pas de pare-feu solides, de référentiels de code source, de builds basés exclusivement sur les référentiels de code source et de révision de code.

TTT · Answer

En tant que consultant, j'ai travaillé pour de nombreuses entreprises différentes, et seulement 2 d'entre elles n'ont pas accordé aux développeurs un accès administrateur à leurs machines; l'un était une petite entreprise, l'autre était une très grande entreprise.

Dans la petite entreprise, j'ai demandé un accès administrateur, expliqué pourquoi pendant environ 60 secondes, et je l'ai obtenu immédiatement.

Dans la grande entreprise, j'ai demandé un accès administrateur et on m'a dit que même s'ils acceptaient que je l'ait, la politique de l'entreprise l'interdit et ils ne pouvaient pas le changer. Donc, l'un des informaticiens est venu et a créé un compte d'administrateur local sur ma machine et m'a demandé de définir le mot de passe. À partir de là, à tout moment, je devais être administrateur, je pouvais me connecter à la machine en tant qu'administrateur local, ou simplement utiliser des runas pour démarrer Visual Studio ou le service/l'application que je devais exécuter avec un utilisateur administrateur (IIS, par exemple). Ce n'est pas bien pire que de choisir le "Run as Administrator" intégré; c'est juste un peu plus lent, mais heureusement, il ne revient pas trop souvent.

Ivan · Answer

N'oubliez pas que le plus gros problème de sécurité ici est l'exfiltration de l'IP, pas des logiciels malveillants. J'espère que vous avez en place IDS/IPS pour traiter ce dernier, ce qui devrait en faire un non-problème.

Vous pouvez vous en sortir en donnant à l'administrateur un accès aux équipements de développement, à condition que vous disposiez des éléments suivants:

Anti-eDLP (réseau, USB, etc.)
IDS/IPS
Proxy d'entreprise authentifié MITM NTLM via lequel vous forcez toutes les connexions et surveillez les violations DLP
Refusez tous les logiciels de virtualisation sur les postes de travail. Si vous avez besoin d'une machine virtuelle, approvisionnez-en une à partir d'un cloud géré où toutes les machines virtuelles exécutent la même image standardisée obsolète avec les outils ci-dessus en place.
Bloquer l'accès aux référentiels logiciels externes au niveau du réseau (cela paralyse pip, git, maven, apt, yast, zypper et tout le reste)
Bloquer l'accès à github, codeplex et aux 150 autres sites de partage de code au niveau du réseau
Bloquer l'accès à tous les 9 000+ sites de partage de fichiers au niveau du réseau
Bloquer l'accès au P2P ... etc ...

Mon employeur fait tout cela et plus encore. Un certain nombre de collègues finissent par développer leur propre équipement personnel après les heures de travail à la maison et le rejettent par-dessus la clôture par des canaux latéraux juste pour contourner l'infrastructure paralysée. Personnellement, je préfère passer mes soirées à boire et à rêver d'une surdose de tranquillisants pour chiens plutôt que de perdre 20 heures supplémentaires sans papiers à faire quelque chose qui me ferait virer de toute façon.

Nous considérons l'informatique (et par extension, le génie logiciel) comme une science. Des expériences scientifiques sont menées dans des conditions stériles pour garder les variables sous contrôle. Il n'est pas scientifique de se développer dans un environnement paralysé où les choses ne fonctionnent pas comme prévu en raison de facteurs environnementaux. Par expérience, je peux vous dire que vous n'en tirez pas de logiciels bien conçus ... tout ce qui est développé en interne est défectueux, ce qui entraîne des dépenses supplémentaires pour des solutions tierces.

Les développeurs doivent absolument avoir un environnement stérile pour se développer. Je ne peux pas vous dire combien de fois différents contrôles de sécurité ont introduit des gremlins dans l'architecture de développement et de production - donc un environnement de développement géré, stérile et basé sur le cloud est vraiment le seul moyen de aller. "Cela a fonctionné en laboratoire, le problème doit être quelque chose d'extérieur."

Vous devez simplement vous assurer que les machines virtuelles que vous leur laissez provisionner ne sont pas anémiques et vous devez automatiser le processus de provisionnement à la OpenStack ou AWS afin que les développeurs n'attendent pas des jours pour satisfaire les besoins de scaling. Les avoir tous gérés de manière centralisée vous donne beaucoup de contrôle d'audit et, franchement, donne aux développeurs de meilleures performances qu'ils n'en auraient de toute façon sur leur propre équipement.

Tyler Durden · Answer

Je suis fan de l'option # 2: avoir des ordinateurs séparés.

Permettre aux machines de l'entreprise disposant d'informations propriétaires d'être connectées à Internet ouvre la porte aux pirates. Cela permet également aux employés d'exfiltrer beaucoup plus facilement les données de l'entreprise à des fins illégitimes.

Si l'employé doit utiliser une machine spéciale pour accéder aux ressources Internet, cela crée un chemin contrôlé d'infiltration et d'exfiltration des données qui est beaucoup plus sécurisé. En outre, cela décourage les employés de naviguer sur le Web ou de perdre du temps sur les forums Internet, comme je le fais maintenant.

Drunken Code Monkey · Answer

En tant qu'administrateur, ce problème est résolu complètement et complètement grâce à une approche SaaS. Virtualisez tous vos différents environnements, placez-les sur un rack de serveur approprié au nombre de clients et configurez un accès à distance ( RDP, Terminal Services ou autres ...). Maintenant tout est sur le serveur, et vous n'avez qu'un seul environnement à maintenir pour tout le monde.