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.

1voto

Vincent Points 376

Je pense qu'il n'est pas possible de répondre complètement à cette question sans plus de détails, par exemple :

Combien de sysadmins pensez-vous garder "restreint" ?

Pour quoi les gens ont-ils besoin d'un accès "sysadmin" ?

Tout d'abord, soyez conscient de ce que vous pouvez faire avec sudo. Avec sudo, vous pouvez accorder des permissions élevées pour exécuter une seule commande (ou des variations, comme des commandes qui commencent par "mount -r" mais dont les autres commandes ne sont pas autorisées). Avec les clés SSH, vous pouvez attribuer des informations d'identification qui permettent à une personne d'exécuter uniquement une certaine commande (comme "sudo mount -r /dev/sdd0 /media/backup"). Par conséquent, il existe un moyen relativement facile de permettre à n'importe qui (qui possède une clé SSH) d'effectuer certaines opérations spécifiques sans lui permettre de faire absolument tout le reste.

Les choses deviennent un peu plus difficiles si vous voulez que les techniciens réparent ce qui est cassé. Cela peut nécessiter un plus grand nombre de permissions, et peut-être l'accès à l'exécution d'une grande variété de commandes, et/ou l'écriture dans une variété de fichiers.

Je suggère de considérer l'approche des systèmes basés sur le web, comme CPanel (qui est utilisé par un certain nombre de FAI) ou les systèmes basés sur le cloud. Ils peuvent souvent faire disparaître les problèmes d'une machine, en faisant disparaître la machine entière. Ainsi, une personne peut être en mesure d'exécuter une commande qui remplace la machine (ou la restaure à une image connue), sans nécessairement lui donner accès à la lecture d'un grand nombre de données ou à de petits changements (comme la combinaison d'une correction mineure avec l'introduction d'une porte dérobée non autorisée). Vous devez donc faire confiance aux personnes qui créent les images, mais vous réduisez le nombre de personnes à qui vous devez faire confiance pour effectuer les petites tâches.

En fin de compte, cependant, un certain degré de confiance doit être accordé à un nombre non nul de personnes qui contribuent à la conception du système et qui opèrent au plus haut niveau.

Les grandes entreprises s'appuient notamment sur des éléments tels que les serveurs SQL, qui stockent des données auxquelles un grand nombre de machines peuvent accéder à distance. Ensuite, un plus grand nombre de techniciens peuvent avoir un accès complet à la racine sur certaines machines, sans pour autant avoir un accès à la racine sur les serveurs SQL.

Une autre approche consiste à être trop gros pour faire faillite. Ne pensez pas que les grandes armées ou les entreprises géantes ne connaissent jamais d'incidents de sécurité. En revanche, elles savent comment s'y prendre :

  • récupérer,
  • limiter les dégâts (en séparant les objets de valeur)
  • disposer de contre-mesures, y compris des menaces de litige
  • disposer de processus permettant de limiter l'exposition indésirable à la presse et de plans permettant d'influer sur la tournure de toute histoire négative qui se développe.

L'hypothèse de base est que les dommages qui se produisent sont simplement un risque et un coût de leur activité. Ils s'attendent à poursuivre leurs activités, et les développements et améliorations constants au fil des ans limiteront l'ampleur des dommages qu'un incident unique est susceptible d'affecter réellement leur valeur à long terme sur une période donnée.

0voto

WilliamKF Points 6819

Il est très difficile de procéder à une vérification proactive.

Des solutions comme http://software.dell.com/solutions/privileged-management/ (Je ne travaille pas pour Dell et d'autres solutions similaires sont disponibles) sont très efficaces pour renforcer la responsabilité des administrateurs système.

0voto

h22 Points 224

Placez la machine d'administration racine dans la pièce verrouillée avec deux clés, et donnez-en une seule pour chacun des deux administrateurs. Les administrateurs travailleront toujours ensemble, en observant leurs activités respectives. Cette machine doit être la seule à contenir la clé privée permettant de se connecter en tant que root.

Certaines activités peuvent ne pas nécessiter de droits d'accès à la racine, de sorte que seule une partie du travail nécessite de se rendre dans cette pièce pour la "programmation en binôme".

Vous pouvez également enregistrer sur vidéo les activités qui se déroulent dans cette pièce, principalement pour vous assurer que personne ne travaille seul (ce qui est facilement visible). Assurez-vous également que le lieu de travail est tel que l'écran est facilement visible pour les deux personnes (peut-être un grand écran de télévision avec de grandes polices de caractères).

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