64 votes

Linux : sysadmins productifs sans root (sécurisation de la propriété intellectuelle) ?

Existe-t-il un moyen de rendre productif un syadmin Linux expérimenté sans lui donner un accès complet à la racine ?

Cette question s'inscrit dans une perspective de protection de la propriété intellectuelle (PI), qui, dans mon cas, est entièrement constituée de code et/ou de fichiers de configuration (c'est-à-dire de petits fichiers numériques faciles à copier). Notre sauce secrète nous a permis d'avoir plus de succès que notre petite taille ne le laisse supposer. De même, nous sommes Une fois mordu, deux fois timide de quelques anciens employés peu scrupuleux (pas des sysadmins) qui ont essayé de voler la propriété intellectuelle. La position de la direction est la suivante : "Nous faisons confiance aux gens, mais par intérêt personnel, nous ne pouvons pas prendre le risque de donner à une personne plus d'accès qu'elle n'en a absolument besoin pour faire son travail".

Sur le développeur il est relativement facile de cloisonner les flux de travail et les niveaux d'accès de manière à ce que les personnes puissent être productives mais ne voient que ce qu'elles ont besoin de voir. Seuls les dirigeants (les propriétaires réels de l'entreprise) ont la possibilité de combiner tous les ingrédients et de créer la sauce spéciale.

Mais je n'ai pas été capable de trouver un bon moyen de maintenir ce secret IP du côté de l'administration Linux. Nous faisons un usage intensif de GPG pour le code et les fichiers texte sensibles... mais qu'est-ce qui empêche un administrateur de (par exemple) se substituer à un utilisateur et de sauter sur sa session tmux ou GNU Screen pour voir ce qu'il fait ?

(Nous avons également désactivé l'accès à Internet dans tous les endroits susceptibles d'être en contact avec des informations sensibles. Mais, rien n'est parfait, et il pourrait y avoir des trous ouverts à des sysadmins intelligents ou des erreurs du côté de l'administrateur réseau. Ou même la bonne vieille clé USB. Il existe bien sûr de nombreuses autres mesures en place, mais elles dépassent le cadre de cette question).

Le mieux que j'ai pu trouver, c'est d'utiliser des comptes personnalisés avec sudo similaire à ce qui est décrit dans Plusieurs sysadmins Linux travaillant en tant que root . Plus précisément, personne, à l'exception des propriétaires de l'entreprise, n'aurait un accès direct à la racine. Les autres administrateurs auront un compte personnalisé et la possibilité de sudo dans la racine. En outre, une journalisation à distance serait instituée, et les journaux seraient envoyés sur un serveur auquel seuls les propriétaires de l'entreprise pourraient accéder. Le fait de voir la journalisation désactivée déclencherait des sortes d'alertes.

Un administrateur système astucieux pourrait probablement encore trouver des failles dans ce système. Et cela mis à part, c'est toujours réactif plutôt que proactive . Le problème de notre propriété intellectuelle est tel que les concurrents pourraient s'en servir très rapidement et causer de gros dégâts en très peu de temps.

Il serait donc encore mieux d'avoir un mécanisme qui limite ce que l'administrateur peut faire. Mais je reconnais qu'il s'agit d'un équilibre délicat (en particulier à la lumière du dépannage et de la résolution des problèmes de production qui doivent être résolus ). à l'heure actuelle ).

Je ne peux m'empêcher de me demander comment d'autres organisations possédant des données très sensibles gèrent cette question ? Par exemple, les administrateurs système de l'armée : comment gèrent-ils les serveurs et les données sans être en mesure de voir les informations confidentielles ?

Edit : Dans le message initial, je voulais répondre de manière préventive aux commentaires sur les "pratiques d'embauche" qui commencent à faire surface. Premièrement, c'est censé être un technique question, et les pratiques d'embauche de l'OMI tendent plus vers social questions. Mais, deux, je dirai ceci : Je crois que nous faisons tout ce qui est raisonnable pour embaucher des gens : entretien avec multiple personnes au sein de l'entreprise ; vérification des antécédents et des références ; tous les employés signent de nombreux documents juridiques, dont un qui indique qu'ils ont lu et compris notre manuel qui détaille en détail les problèmes de propriété intellectuelle. Maintenant, cela sort du cadre de cette question/site, mais si quelqu'un peut proposer des pratiques d'embauche "parfaites" qui filtrent 100% des mauvais acteurs, je suis tout ouïe. Les faits sont les suivants : (1) je ne crois pas qu'il existe un processus d'embauche aussi parfait ; (2) les gens changent - l'ange d'aujourd'hui peut être le diable de demain ; (3) les tentatives de vol de code semblent être quelque peu routinières dans ce secteur.

9voto

Steve Bonds Points 804

Il est très très difficile de sécuriser les hôtes contre ceux qui ont un accès administratif. Alors que des outils comme PowerBroker tenter de le faire, le coût est d'ajouter à la fois quelque chose d'autre qui peut se briser ET en ajoutant des obstacles aux tentatives de réparation. La disponibilité de votre système WILL Le coût de la protection des biens et des services peut baisser lorsque vous mettez en œuvre un tel projet. Il faut donc s'attendre à ce qu'il en soit ainsi dès le départ.

Une autre possibilité est de voir si votre application peut fonctionner sur des hôtes jetables via un fournisseur de cloud ou dans un cloud privé hébergé localement. Lorsque l'un d'entre eux tombe en panne, au lieu d'envoyer un administrateur pour le réparer, vous le jetez et construisez automatiquement son remplacement. Il faudra beaucoup de travail du côté des applications pour les faire fonctionner selon ce modèle, mais cela peut résoudre de nombreux problèmes opérationnels et de sécurité. Si elle est mal faite, elle peut créer des problèmes de sécurité importants, alors demandez l'aide d'une personne expérimentée si vous choisissez cette voie.

4voto

Tom Points 720

C'est votre discussion de base : https://security.stackexchange.com/questions/7801/keeping-secrets-from-root-on-linux

Vous divisez votre responsabilité en ayant des ingénieurs en sécurité dont le travail consiste à faire des configurations et des installations de systèmes, mais ils n'obtiennent aucune accréditation ou accès aux machines en production. Ils gèrent également votre infrastructure d'audit.

Vous avez des administrateurs de production qui reçoivent les systèmes mais n'ont pas les clés pour démarrer la machine sans que les politiques SELinux soient actives. La sécurité ne reçoit pas les clés pour décrypter les données sensibles stockées au repos sur le disque lorsqu'elle reçoit une machine cassée et retirée du service.

Utiliser un système d'authentification centralisé avec un audit fort comme Chambre forte et utiliser ses opérations cryptographiques. Distribuez des dispositifs Yubikey pour rendre les clés absolument privées et illisibles.

Les machines sont soit effacées en cas de bris, soit gérées conjointement par les opérations et la sécurité, et si vous en ressentez le besoin, par une supervision exécutive.

2voto

Scott Points 21

Les administrateurs, de par la nature de leur travail, ont accès à tout. Ils peuvent voir tous les fichiers du système de fichiers avec leurs identifiants d'administrateur. Vous aurez donc besoin d'un moyen de crypter les fichiers afin que les administrateurs ne puissent pas les voir, mais que les fichiers soient toujours utilisables par les équipes qui doivent les voir. Regardez dans Vormetric Transparent Encryption ( http://www.vormetric.com/products/transparent-encryption )

Il se situe entre le système de fichiers et les applications qui y accèdent. La direction peut créer une politique qui stipule que "Seul l'utilisateur httpd, qui exécute le démon du serveur web, peut voir les fichiers non cryptés". Ainsi, un administrateur avec ses informations d'identification root peut essayer de lire les fichiers et n'obtenir que la version cryptée. Mais le serveur web et tous les outils dont il a besoin les voient en clair. Il peut même faire une somme de contrôle du binaire pour rendre plus difficile le contournement par l'administrateur.

Bien entendu, vous devez activer l'audit afin que, dans le cas où un administrateur tente d'accéder aux fichiers, un message soit signalé et que les gens en soient informés.

2voto

Michael Martinez Points 2505

Le seul moyen pratique est de restreindre qui peut faire quoi avec sudo. Vous pourriez aussi potentiellement faire la plupart de ce que vous voulez avec selinux, mais cela prendrait probablement une éternité pour trouver la configuration correcte, ce qui pourrait rendre cela peu pratique.

Les accords de non-divulgation. Engagez un administrateur système, il doit signer un accord de non-divulgation, s'il ne tient pas sa promesse, poursuivez-le en justice. Cela peut ne pas prévenir de voler des secrets, mais les dommages qu'ils causent en le faisant sont récupérables en justice.

Les administrateurs système de l'armée et du gouvernement doivent obtenir des autorisations de sécurité de différents niveaux, en fonction de la sensibilité du matériel. L'idée est qu'une personne qui peut obtenir une habilitation est moins susceptible de voler ou de tricher.

1voto

Ondra Sniper Flidr Points 2563

Un autre moyen de réduire les risques (à côté de ceux mentionnés précédemment, et non à la place de) consiste à rémunérer vos administrateurs système. Payez-les si bien qu'ils n'auront pas envie de voler votre IP et de vous quitter.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X