Linux: administrateurs système productifs sans racine (sécurisation de la propriété intellectuelle)?

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

Cette question relève du point de vue de la protection de la propriété intellectuelle (PI), qui dans mon cas est entièrement constitué de fichiers de code et / ou de configuration (c’est-à-dire de petits fichiers numériques faciles à copier). Notre sauce secrète nous a valu plus de succès que ne le suggère notre petite taille. De même, nous sommes une fois mordus, deux fois timides par quelques anciens employés peu scrupuleux (pas des administrateurs système) qui ont tenté de voler de la propriété intellectuelle. La position de la direction est fondamentalement la suivante: "Nous faisons confiance aux gens, mais pour des raisons personnelles, nous ne pouvons pas nous permettre de donner à une personne plus d'accès que nécessaire pour faire son travail."

Du côté des développeurs , il est relativement facile de partitionner les flux de travail et les niveaux d'accès de manière à ce que les utilisateurs puissent être productifs mais ne voient que ce dont ils ont besoin. Seules les personnes les plus qualifiées (propriétaires d’entreprise) ont la possibilité de combiner tous les ingrédients et de créer la sauce spéciale.

Mais je n'ai pas été en mesure de trouver un bon moyen de maintenir ce secret IP du côté de l'administrateur 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 se soumettre (par exemple) à un utilisateur et de sauter dans sa session tmux ou GNU Screen et de voir ce qu'il fait?

(Nous avons également des accès Internet désactivés partout qui pourraient éventuellement entrer en contact avec des informations sensibles. Mais rien n’est parfait et il pourrait y avoir des trous pour des administrateurs système intelligents ou des erreurs du côté de l’administrateur réseau. Ou même du bon vieil USB. Bien sûr, de nombreuses autres mesures sont en place, mais elles dépassent le cadre de cette question.)

Le mieux que je puisse trouver consiste à utiliser des comptes personnalisés avec sudo , similaires à ceux décrits dans Plusieurs administrateurs système Linux travaillant en tant que root . Plus précisément: personne, à l'exception des propriétaires de l'entreprise, n'aurait un accès root direct. Les autres administrateurs auraient un compte personnalisé et la possibilité de se connecter rapidement à root. En outre, une journalisation à distance serait instituée et les journaux iraient à un serveur auquel seuls les propriétaires de la société peuvent accéder. Voir la journalisation désactivée déclencherait une sorte d’alerte.

Un administrateur système intelligent pourrait probablement encore trouver quelques failles dans ce schéma. Et cela mis à part, c'est toujours réactif plutôt que proactif . Le problème avec notre propriété intellectuelle est tel que les concurrents pourraient l'utiliser très rapidement et causer beaucoup de dégâts en très peu de temps.

Il serait donc préférable de mettre en place un mécanisme qui limite ce que l’administrateur peut faire. Mais je reconnais qu'il s'agit d'un équilibre délicat (notamment à la lumière du dépannage et de la résolution des problèmes de production qui doivent être résolus maintenant ).

Je ne peux pas m'empêcher de me demander comment d'autres organisations disposant de données très sensibles gèrent ce problème? Par exemple, les administrateurs système militaires: comment gèrent-ils les serveurs et les données sans pouvoir voir les informations confidentielles?

Edit: Lors de la publication initiale, je voulais aborder de manière préventive les commentaires sur les "pratiques d’embauche" qui commencent à faire surface. Premièrement, ceci est supposé être une question technique et les pratiques de recrutement de l’OMI sont davantage orientées vers les questions sociales . Mais, deux, je dirai ceci: je crois que nous faisons tout ce qui est raisonnable pour embaucher du personnel: entretien avec plusieursles gens de l'entreprise; vérification des antécédents et des références; tous les employés signent de nombreux documents légaux, y compris un document indiquant qu'ils ont lu et compris notre manuel, qui détaille en détail les problèmes de propriété intellectuelle. Maintenant, c'est hors du champ 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 pourrait être le diable de demain; (3) La tentative de vol de code semble être quelque peu courante dans ce secteur.

Ce dont vous parlez est connu sous le nom de risque "Evil Sysadmin". En bref, c'est:

• Un administrateur système est une personne qui a des privilèges élevés
• Techniquement adeptes, à un niveau qui en ferait un bon "pirate informatique".
• Interaction avec les systèmes dans des scénarios anormaux.

La combinaison de ces éléments fait qu’il est essentiellement impossible d’arrêter une action malveillante. Même l'audit devient difficile, car vous n'avez pas de comparaison «normale». (Et franchement, un système défectueux pourrait bien avoir également brisé l’audit).

Il y a un tas d'étapes d'atténuation:

• Séparation des privilèges - vous ne pouvez pas empêcher un type avec racine de faire quoi que ce soit sur le système. Mais vous pouvez charger une équipe de la mise en réseau et une autre équipe de la gestion des "systèmes d'exploitation" (ou Unix / Windows séparément).
• Limitez l'accès physique au kit à une autre équipe, qui ne possède pas de compte administrateur, mais s'occupe de tout le travail manuel.
• Séparez les responsabilités de «bureau» et de «serveur». Configurez le bureau pour empêcher la suppression de données. Les administrateurs de bureau n'ont pas la possibilité d'accéder aux informations sensibles, les administrateurs de serveurs peuvent le voler, mais ils doivent sauter à travers des cerceaux pour le sortir du bâtiment.
• Audit sur un système à accès restreint - sysloget audit au niveau des événements, sur un système relativement inviolable auquel ils n'ont pas accès privilégié. Mais collecter ces informations ne suffit pas, vous devez les surveiller - et franchement, il existe de nombreuses façons de "voler" des informations qui pourraient ne pas apparaître dans un radar d'audit. (Braconnier contre les gardes-chasse)
• appliquez le cryptage "au repos", afin que les données ne soient pas stockées "en clair", et nécessite un système en direct pour y accéder. Cela signifie que les personnes ayant un accès physique ne peuvent pas accéder à un système qui n'est pas activement surveillé et que, dans un scénario «anormal» où un administrateur système y travaille, les données sont moins exposées. (par exemple, si la base de données ne fonctionne pas, les données ne sont probablement pas lisibles)
• La règle de deux hommes - si vous êtes d'accord avec votre productivité est réduite, et votre moral de même. (Sérieusement - je l'ai vu faire, et l'état de travail persistant et l'observation rendent les conditions de travail extrêmement difficiles).
• Contrôlez vos administrateurs système - il peut exister diverses vérifications d’enregistrements selon les pays. (Vérification du casier judiciaire, vous pouvez même trouver que vous pouvez demander une habilitation de sécurité dans certains cas, ce qui déclenchera une vérification)
• Occupez-vous de vos administrateurs système - la dernière chose que vous voulez faire est de dire à une personne "de confiance" que vous ne leur faites pas confiance. Et vous ne voulez certainement pas nuire au moral, car cela augmente les risques de comportement malveillant (ou «pas de négligence, mais un manque de vigilance»). Mais payez en fonction de vos responsabilités et de vos compétences. Et considérez les «avantages» - qui sont moins chers que le salaire, mais qui ont probablement plus de valeur. Comme du café gratuit ou une pizza une fois par semaine.
• et vous pouvez également essayer d’appliquer des conditions de contrat pour l’inhiber, mais méfiez-vous de ce qui précède.

Mais fondamentalement, vous devez accepter le fait qu’il s’agit d’une question de confiance et non de technique. Vos administrateurs seront toujours potentiellement très dangereux pour vous à la suite de cette tempête parfaite.

Tout ce qui a été dit jusqu'à présent ici est une bonne chose, mais il existe un moyen non technique 'facile' qui permet de s'affranchir d'un administrateur système sournois - le principe des quatre yeux, qui exige fondamentalement que deux administrateurs système soient présents pour tout accès surélevé.

EDIT: Les deux plus gros articles que j'ai vus dans les commentaires traitent du coût et de la possibilité de collusion. L'un des principaux moyens que j'ai envisagés pour éviter ces deux problèmes consiste à utiliser une société de services gérés utilisée uniquement pour la vérification des actions prises. Fait correctement, les techniciens ne se connaitraient pas. En supposant les prouesses techniques qu'un MSP devrait avoir, il serait assez facile de se faire avaliser des actions entreprises… peut-être même aussi simple qu'un oui / non à quelque chose de néfaste.

Si les personnes ont vraiment besoin d'un accès administrateur à un système, vous ne pouvez rien faire pour limiter leurs activités sur cette boîte.

Ce que la majorité des entreprises font, c’est faire confiance, mais vérifier - vous pouvez donner aux personnes un accès à des parties du système, mais vous utilisez des comptes d’administrateur nommés (par exemple, vous ne leur donnez pas un accès direct à root ), puis vous contrôlez leurs activités dans un journal qu’elles enregistrent. ne peut pas interférer avec.

Il y a un acte d'équilibre ici; vous aurez peut-être besoin de protéger vos systèmes, mais vous devez aussi faire confiance aux gens pour faire leur travail. Si la société était autrefois "mordue" par un employé peu scrupuleux, cela pourrait laisser penser que les pratiques de recrutement de la société sont médiocres, et que ces pratiques ont probablement été créées par les "cadres supérieurs". La confiance commence à la maison Que font-ils pour améliorer leurs choix d'embauche?

Sans vous mettre dans un état d'esprit technique insensé, essayez de trouver un moyen de donner à un administrateur système sans lui donner le pouvoir (c'est probablement faisable, mais serait finalement imparfait d'une manière ou d'une autre).

Du point de vue de la pratique commerciale, il existe un ensemble de solutions simples. Pas une solution bon marché, mais simple.

Vous avez mentionné que les éléments de propriété intellectuelle qui vous préoccupent sont divisés et que seuls les dirigeants ont le pouvoir de les voir. Ceci est essentiellement votre réponse. Vous devez avoir plusieurs administrateurs, et AUCUN d'entre eux ne devrait être un administrateur sur suffisamment de systèmes pour constituer une image complète. Vous aurez bien sûr besoin d’au moins 2 ou 3 administrateurs pour chaque pièce, au cas où un administrateur serait malade ou dans un accident de voiture ou quelque chose du genre. Peut-être même les décaler. Disons que vous avez 4 administrateurs et 8 informations. admin 1 peut accéder aux systèmes comportant les pièces 1 et 2, admin 2, 2 et 3, admin 3, 3 et 4, et admin 4, 4 et 1. Chaque système dispose d'un administrateur de sauvegarde, mais aucune admin est capable de compromettre l'image complète.

L’armée utilise également une technique qui limite les données en mouvement. Dans une zone sensible, il ne peut y avoir qu'un seul système capable de graver un disque ou d'utiliser un lecteur flash USB. Tous les autres systèmes sont restreints. Et la capacité à utiliser ce système est extrêmement limitée et nécessite une approbation documentée spécifique de la part des instances supérieures avant que quiconque ne soit autorisé à mettre des données sur tout ce qui pourrait conduire à une fuite d'informations. De la même manière, vous vous assurez que le trafic réseau entre différents systèmes est limité par des pare-feu matériels. Vos administrateurs réseau qui contrôlent les murs coupe-feu n’ont pas accès aux systèmes qu’ils acheminent. Ils ne peuvent donc pas accéder spécifiquement aux informations. Les administrateurs de votre serveur / station de travail veillent à ce que toutes les données à destination et en provenance d’un système soient configurées pour être chiffrées.

Tous les ordinateurs portables / postes de travail doivent avoir des disques durs chiffrés et chaque employé doit disposer d'un casier personnel dans lequel il est obligé de verrouiller les disques / ordinateurs portables à la fin de la nuit pour s'assurer que personne ne rentre tôt / part en retard et ne peut accéder à quelque chose ils ne sont pas censés le faire.

Chaque serveur doit à tout le moins se trouver dans son propre rack verrouillé, sinon dans sa propre salle verrouillée, de sorte que seuls les administrateurs responsables de chaque serveur y aient accès, car à la fin de la journée, l'accès physique l'emporte sur tout.

Ensuite, il y a une pratique qui peut blesser / aider. Contrats limités. Si vous pensez que vous pouvez payer suffisamment pour attirer de nouveaux talents, l'option de ne garder qu'un administrateur pendant un laps de temps prédéterminé (IE 6 mois, 1 an, 2 ans) vous permettrait de limiter le temps dont dispose quelqu'un. pour tenter de rassembler toutes les pièces de votre IP.

Ma conception personnelle ressemblerait à ... Franchissez vos données en plusieurs parties. Disons que, pour avoir le numéro 8, vous avez 8 serveurs git, chacun avec son propre ensemble de matériel redondant, administrés chacun par un ensemble différent d'administrateurs.

Les disques durs cryptés pour tous les postes de travail qui vont toucher l’IP. Avec un répertoire "projet" spécifique sur le lecteur qui est le seul répertoire, les utilisateurs sont autorisés à mettre leurs projets. À la fin de chaque nuit, ils doivent nettoyer leurs répertoires de projet avec un outil de suppression sécurisé, puis les disques durs sont retirés et enfermé (juste pour être en sécurité).

Chaque bit du projet est affecté à un administrateur différent. Par conséquent, un utilisateur n'interagit qu'avec l'administrateur du poste de travail auquel il est affecté. Si son affectation de projet change, ses données sont effacées, un nouvel administrateur lui est attribué. Leurs systèmes ne devraient pas avoir de capacité de gravure et devraient utiliser un programme de sécurité pour empêcher l'utilisation de clés USB pour transférer des données sans autorisation.

Prends-en ce que tu veux.

Ce serait semblable au défi d'embaucher un concierge pour un immeuble. Le concierge a toutes les clés, peut ouvrir n'importe quelle porte, mais la raison en est que le concierge a besoin d'eux pour faire le travail. Même chose avec les administrateurs système. Symétriquement, on peut penser à ce problème séculaire et examiner les moyens par lesquels la confiance est accordée de manière historique.

Bien qu'il n'y ait pas de solution technique nette, le fait qu'il n'y en ait pas ne devrait pas être une raison pour ne pas en essayer aucune, un regroupement de solutions imparfaites peut donner des résultats plutôt excellents.

Un modèle où la confiance est gagnée :

• Donne moins d'autorisations pour commencer
• Augmenter progressivement les autorisations
• Mettez un pot de miel et surveillez ce qui se passera dans les prochains jours
• Si l'administrateur système le signale au lieu d'essayer d'en abuser, c'est un bon début

Mettre en œuvre plusieurs niveaux de pouvoirs administratifs :

• Niveau 1: Peut modifier le niveau inférieur des fichiers de configuration
• Niveau 2: Peut modifier un niveau légèrement supérieur de fichiers de configuration
• Niveau 3: Peut modifier un niveau légèrement supérieur de fichiers de configuration et de paramètres de système d'exploitation

Toujours créer un environnement où l'accès total par une personne n'est pas possible :

• Systèmes divisés en grappes
• Donner des pouvoirs d'administrateur de cluster à différents groupes
• Minimum 2 groupes

Utilisez la règle des deux hommes lorsque vous effectuez des modifications de base de haut niveau :

• https://en.wikipedia.org/wiki/Two-man_rule
• Requiert un administrateur de cluster1 et cluster2 pour les modifications principales

Faites confiance et vérifiez :

• Tout enregistrer
• Journal de surveillance et d'alerte
• S'assurer que toutes les actions sont distinguables

Paperasserie :

• Demandez-leur de signer des papiers pour que le système judiciaire puisse vous aider en les poursuivant en justice s'ils vous font mal, cela les incite davantage à ne pas le faire

Il est très difficile de sécuriser les hôtes contre ceux qui ont un accès administrateur. Tandis que des outils tels que PowerBroker tentent de le faire, le coût ajoute à la fois quelque chose qui peut casser ET des obstacles à la résolution du problème . La disponibilité de votre système SERA DIMINUE lorsque vous implémenterez quelque chose comme ceci, alors définissez cette attente dès que possible afin de protéger les coûts.

Une autre possibilité est de voir si votre application peut être exécutée sur des hôtes jetables via un fournisseur de cloud ou dans un cloud privé hébergé localement. Quand on se casse, au lieu d’envoyer un administrateur pour le réparer, on le jette et on construit automatiquement un remplaçant. Cela nécessitera beaucoup de travail du côté des applications pour les faire fonctionner dans ce modèle, mais cela peut résoudre beaucoup de problèmes opérationnels et de sécurité. Si cela est mal fait, cela peut créer des problèmes de sécurité importants, alors faites appel à de l'aide expérimentée si vous suivez cette voie.

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

Vous partagez votre responsabilité en confiant à des ingénieurs en sécurité le soin de réaliser les configurations et les installations du système, mais ils n’obtiennent pas d’informations d’identité ni d’accès aux machines en production. Ils gèrent également votre infrastructure d'audit.

Certains de vos administrateurs de production reçoivent les systèmes, mais ne disposent pas des clés pour démarrer la machine sans que les règles SELinux ne soient actives. La sécurité n'obtient pas les clés pour déchiffrer les données sensibles stockées au repos sur le disque, car une machine défectueuse est retirée du service.

Utilisez un système d'authentification centralisé avec un audit puissant comme Vault et utilisez ses opérations cryptographiques. Distribuez des appareils Yubikey pour rendre les clés absolument privées et illisibles.

Les machines sont soit effacées en cas de panne, soit gérées conjointement par les opérateurs et les agents de sécurité, et si vous en ressentez le besoin, une supervision par la direction.

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

Cela fonctionnerait normalement entre le système de fichiers et les applications qui y ont accès. La direction peut créer la stratégie indiquant "Seul l'utilisateur httpd, exécutant le démon serveur Web, peut voir les fichiers non chiffrés". Ensuite, un administrateur avec ses informations d'identification racine peut essayer de lire les fichiers et obtenir uniquement la version cryptée. Mais le serveur Web et les outils dont il a besoin les voient non chiffrés. Il peut même contrôler le fichier binaire pour que l’administrateur ait plus de difficultés à se déplacer.

Bien sûr, vous devez activer l’audit de sorte que, dans le cas où un administrateur essaie d’accéder aux fichiers, un message soit signalé et les gens le connaissent.

Le seul moyen pratique consiste à limiter qui peut faire quoi avec sudo. Vous pourriez aussi potentiellement faire la plupart de ce que vous voulez avec selinux, mais il vous faudra probablement une éternité pour déterminer la configuration correcte, ce qui peut la rendre impraticable.

Accords de non-divulgation. Embaucher un administrateur système, ils doivent signer une NDA. S'ils rompent leur promesse, poursuivez-les. Cela ne les empêchera peut-être pas de voler des secrets, mais les dommages qu’ils auront causés seront recouvrables devant un tribunal.

Les administrateurs militaires et gouvernementaux doivent obtenir des cotes de sécurité de différentes qualités en fonction de la sensibilité du matériel. L'idée est que quelqu'un qui peut obtenir une autorisation est moins susceptible de voler ou de tricher.

Une autre façon de réduire les risques (à utiliser à côté de ceux mentionnés ci-dessus, pas à la place de) est de payer beaucoup d'argent à vos administrateurs système. Payez-les si bien qu'ils ne veulent pas voler votre IP et vous laisser.

Je pense que cette question pourrait ne pas être possible de répondre pleinement sans quelques détails supplémentaires, tels que:

Combien d'administrateurs comptez-vous garder "restreints"?

Qu'est-ce que les gens ont besoin d'un accès "sysadmin"?

Tout d’abord, soyez conscient de ce que vous pouvez faire avec sudo. Avec sudo, vous pouvez autoriser les autorisations élevées à exécuter une seule commande (ou des variantes, telles que les commandes commençant par "mount -r" mais 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 commande donnée (comme "sudo mount -r / dev / sdd0 / media / backup"). Par conséquent, il existe un moyen relativement facile de permettre à quiconque (disposant d'une clé SSH) de pouvoir effectuer certaines opérations spécifiques sans le laisser effectuer absolument tout le reste.

Les choses deviennent un peu plus difficiles si vous voulez que les techniciens effectuent des corrections sur ce qui ne fonctionne pas. Cela peut généralement nécessiter un nombre d'autorisations plus important et peut-être même un accès pour exécuter une grande variété de commandes et / ou écrire dans divers fichiers.

Je suggère d'envisager l'approche des systèmes basés sur le Web, tels que CPanel (qui est utilisé par plusieurs FAI) ou des systèmes basés sur le cloud. Ils peuvent souvent faire disparaître des problèmes sur une machine en faisant disparaître toute la machine. Ainsi, une personne peut être en mesure d'exécuter une commande qui remplace la machine (ou la restaure sur une image en bon état), sans nécessairement lui permettre d'accéder à de nombreuses données, ou d'effectuer de petites modifications (comme combiner un correctif mineur avec l’introduction d’une porte arrière non autorisée). Ensuite, vous devez faire confiance aux personnes qui créent les images, mais vous réduisez le nombre de personnes en qui vous avez confiance pour faire des tâches plus petites.

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

Les grandes entreprises ont notamment recours à des serveurs tels que SQL Server, qui stockent des données accessibles à un plus grand nombre de machines à distance. Ensuite, un plus grand nombre de techniciens peuvent avoir un accès root complet sur certaines machines, sans avoir un accès root aux serveurs SQL.

Une autre approche consiste à être trop gros pour échouer. Ne croyez pas que les grandes armées ou les grandes entreprises n’ont jamais d’incidents de sécurité. Cependant, ils savent comment:

• récupérer,
• limiter les dégâts (en séparant les objets de valeur)
• avoir des contre-mesures, y compris des menaces de procès
• avoir des processus pour aider à limiter l'exposition indésirable à la presse et des plans pour influencer la tournure des histoires négatives qui se développent

L’hypothèse de base est que les dommages qui surviennent ne sont que le risque et le coût de leurs affaires. Ils s'attendent à continuer à fonctionner, et les développements et améliorations en cours au fil des années limiteront les dommages qu'un incident unique est susceptible d'affecter réellement leur valeur à long terme sur une période donnée.

Faire une vérification proactive est très difficile.

Des solutions telles que http://software.dell.com/solutions/privileged-management/ (je ne travaille pas pour Dell et d'autres solutions similaires disponibles) sont très efficaces pour faire appliquer la responsabilité de l'administrateur système.

Placez la machine d'administration racine dans la pièce verrouillée avec deux clés et n'en donnez qu'une pour chacun des deux administrateurs. Les administrateurs vont toujours travailler ensemble, en observant les autres activités. Ce devrait être la seule machine contenant la clé privée pour vous connecter en tant que root.

Certaines activités peuvent ne nécessiter aucun droit racine, de sorte que seule une partie du travail nécessiterait l'accès à cette salle pour la "programmation en binôme".

Vous pouvez également enregistrer des activités d’enregistrement vidéo dans cette salle, 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 (par exemple, un grand écran de télévision avec les grandes polices).