Linux: des administrateurs système productifs sans root (sécurisation de la propriété intellectuelle)?
Existe-t-il un moyen de rendre un syadmin Linux chevronné productif sans lui donner un accès root complet?
Cette question vient du point de vue de la protection de la propriété intellectuelle (IP), qui dans mon cas, est entièrement constituée de fichiers de code et/ou de configuration (c'est-à-dire de petits fichiers numériques faciles à copier). Notre sauce secrète nous a fait plus de succès que ne le suggère notre petite taille. De même, nous sommes une fois mordu, deux fois timide de quelques anciens employés sans scrupules (pas des administrateurs système) qui ont tenté de voler la propriété intellectuelle. La position de la haute direction est fondamentalement: "Nous faisons confiance aux gens, mais par intérêt personnel, nous ne pouvons pas risquer de donner à une personne plus d'accès qu'elle n'en a absolument besoin pour faire son travail.
Du côté développeur, il est relativement facile de partitionner les flux de travail et les niveaux d'accès de telle sorte que les gens peuvent être productifs mais ne voient que ce dont ils ont besoin. Seules les meilleures personnes (propriétaires réels de l'entreprise) ont la capacité 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é administrateur Linux. Nous utilisons largement GPG pour le code et les fichiers texte sensibles ... mais qu'est-ce qui empêche un administrateur de (par exemple) poursuivre un utilisateur et sauter sur son tmux ou GNU Session d'écran et voir ce qu'ils font?
(Nous avons également un accès Internet désactivé partout qui pourrait éventuellement entrer en contact avec des informations sensibles. Mais, rien n'est parfait, et il pourrait y avoir des trous ouverts pour des administrateurs système intelligents ou des erreurs du côté de l'administrateur du réseau. Ou même un bon vieux 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 est essentiellement d'utiliser des comptes personnalisés avec Sudo, similaire à ce qui est décrit 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 en fait un accès root direct. D'autres administrateurs auraient un compte personnalisé et la possibilité de Sudo en root. En outre, une journalisation à distance serait instituée et les journaux seraient envoyés à un serveur auquel seuls les propriétaires de l'entreprise pouvaient accéder. Voir la journalisation désactivée déclencherait une sorte d'alertes.
Un administrateur système intelligent pourrait probablement encore trouver des trous dans ce schéma. Et cela mis à part, c'est toujours réactif plutôt que proactif. Le problème avec notre IP est tel que les concurrents pourraient l'utiliser très rapidement et causer beaucoup de dégâts en très peu de temps.
Un mécanisme qui limiterait ce que l'administrateur peut faire serait donc encore mieux. 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 dès 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?
Modifier: Dans la publication initiale, je voulais répondre de manière préventive aux commentaires sur les "pratiques d'embauche" qui commencent à faire surface. Premièrement, cela est censé être une question technique, et les pratiques d'embauche de l'OMI tendent davantage vers les questions sociales. Mais, deux, je dirai ceci: je crois que nous faisons tout ce qui est raisonnable pour embaucher des personnes: entretien avec multiple personnes dans 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 les problèmes de propriété intellectuelle en détail. Maintenant, c'est hors de portée de cette question/du site, mais si quelqu'un peut proposer des pratiques d'embauche "parfaites" qui filtrent 100% des mauvais acteurs, je suis à l'écoute. 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 cette industrie.
Ce dont vous parlez est connu sous le nom de risque "Evil Sysadmin". Le long et le court c'est:
- Un administrateur système est une personne disposant de privilèges élevés
- Techniquement adepte, à un niveau qui ferait d'eux un bon "hacker".
- Interagir avec les systèmes dans des scénarios anormaux.
La combinaison de ces éléments rend essentiellement impossible l'arrêt des actions malveillantes. Même l'audit devient difficile, car vous n'avez pas de "normal" avec lequel comparer. (Et franchement - un système cassé peut aussi avoir cassé l'audit).
Il existe de nombreuses mesures d'atténuation:
- Séparation des privilèges - vous ne pouvez pas empêcher un gars avec root de faire n'importe quoi sur le système. Mais vous pouvez désigner une équipe responsable de la mise en réseau et une autre équipe responsable des "systèmes d'exploitation" (ou Unix/Windows séparément).
- Limitez l'accès physique au kit à une autre équipe, qui n'obtient pas de comptes d'administrateur ... mais s'occupe de tout le travail `` manuel ''.
- Séparez la responsabilité "bureau" et "serveur". Configurez le bureau pour empêcher la suppression des données. Les administrateurs de bureau n'ont pas la possibilité d'accéder aux éléments sensibles, les administrateurs de serveur peuvent le voler, mais doivent sauter à travers des cerceaux pour le faire 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 un accès privilégié. Mais la collecte ne suffit pas, vous devez la surveiller - et franchement, il existe un tas de façons de `` voler '' des informations qui pourraient ne pas apparaître sur un radar d'audit. (Braconnier contre gardiens) - appliquer le cryptage "au repos", afin que les données ne soient pas stockées "en clair" et nécessitent 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)
- Règle de deux hommes - si vous êtes d'accord avec votre productivité paralysée, et votre moral également. (Sérieusement - je l'ai vu faire, et l'état persistant de travailler et d'être surveillé rend les conditions de travail extrêmement difficiles).
- Contrôlez vos administrateurs système - divers contrôles de dossiers peuvent exister selon le pays. (Vérification de casier judiciaire, vous pourrait même trouver que vous pouvez demander une habilitation de sécurité dans certains cas, ce qui déclenchera la vérification)
- Prenez soin de vos administrateurs système - la dernière chose absolue que vous voulez faire est de dire à une personne "de confiance" que vous ne lui faites pas confiance. Et vous ne voulez certainement pas nuire au moral, car cela augmente la possibilité d'un comportement malveillant (ou "pas tout à fait négligence, mais une baisse de vigilance"). Mais payez selon la responsabilité et les compétences. Et considérez les "avantages" - qui sont moins chers que le salaire, mais probablement plus valorisés. Comme du café gratuit ou de la pizza une fois par semaine.
- et vous pouvez également essayer d'appliquer des conditions contractuelles pour l'inhiber, mais méfiez-vous de ce qui précède.
Mais assez fondamentalement - vous devez accepter que c'est une chose de confiance, pas une chose technique. Vos administrateurs système seront toujours potentiellement très dangereux pour vous, à la suite de cette tempête parfaite.
Tout ce qui a été dit jusqu'à présent est une bonne chose, mais il existe un moyen non technique `` facile '' qui aide à annuler un administrateur sys voyou - le principe des quatre yeux qui nécessite essentiellement que deux administrateurs système soient présents pour tout accès élevé.
EDIT: Les deux plus gros éléments que j'ai vus dans les commentaires discutent du coût et de la possibilité de collusion. L'un des plus grands moyens que j'ai envisagés pour éviter ces deux problèmes est d'utiliser une société de services gérés utilisée uniquement pour la vérification des mesures prises. Fait correctement, les techniciens ne se connaissent pas. En supposant la prouesse technique qu'un MSP devrait avoir, il serait assez facile d'avoir une approbation des actions entreprises ... peut-être même aussi simple qu'un oui/non à quelque chose de néfaste.
Si les gens ont vraiment besoin d'un accès administrateur à un système, vous ne pouvez pas faire grand-chose pour restreindre leurs activités sur cette boîte.
Ce que la majorité des organisations font est faites confiance, mais vérifiez - vous pouvez donner aux gens l'accès à certaines 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 auditez leurs activités dans un journal avec lequel ils ne peuvent pas interférer.
Il y a un équilibre ici; vous devrez peut-être protéger vos systèmes, mais vous devrez également faire confiance aux gens pour faire leur travail. Si l'entreprise était auparavant "mordue" par un employé sans scrupules, cela pourrait suggérer que les pratiques d'embauche des entreprises sont en quelque sorte médiocres, et ces pratiques ont probablement été créées par les "cadres supérieurs". La confiance commence à la maison; que font-ils pour fixer leurs choix d'embauche?
Sans vous mettre dans une folie d'esprit technique pour essayer de trouver un moyen de donner un pouvoir d'administrateur système sans leur donner le pouvoir (c'est probablement faisable, mais serait finalement imparfait d'une certaine manière).
Du point de vue des pratiques commerciales, 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 intéressent sont divisés et que seules les personnes au sommet ont le pouvoir de les voir. C'est essentiellement votre réponse. Vous devez avoir plusieurs administrateurs, et AUCUN d'entre eux ne doit être administrateur sur suffisamment de systèmes pour rassembler l'image complète. Bien sûr, vous auriez 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. Peut-être même les étaler. disons que vous avez 4 administrateurs et 8 informations. admin 1 peut accéder aux systèmes qui ont les morceaux 1 et 2, admin 2 peut aller aux morceaux 2 et 3, admin 3 peut aller aux 3 et 4, et admin 4 peut aller aux 4 et 1. Chaque système a un administrateur de sauvegarde, mais pas l'administrateur est en mesure de compromettre l'image complète.
Une technique que les militaires utilisent également est la limitation des 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 une clé USB, tous les autres systèmes sont limités. Et la capacité à utiliser ce système est extrêmement limitée et nécessite une approbation documentée spécifique par des autorités supérieures avant que quiconque ne soit autorisé à mettre des données sur tout ce qui pourrait entraîner un déversement d'informations. Sur le même jeton, 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, et vos administrateurs serveur/poste de travail s'assurent que toutes les données vers et depuis un système sont configurées pour être cryptées, donc que vos administrateurs réseau ne peuvent pas exploiter le réseau et accéder aux données.
Tous les ordinateurs portables/postes de travail doivent avoir des disques durs chiffrés, et chaque employé doit avoir un casier personnel, il est nécessaire de verrouiller les disques/ordinateurs portables à la fin de la nuit pour s'assurer que personne n'arrive tôt/ne part tard et n'accède à quelque chose ils ne sont pas censés le faire.
Chaque serveur doit à tout le moins être dans son propre rack verrouillé, sinon sa propre salle verrouillée, afin 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 soit blesser/aider. Contrats limités. Si vous pensez que vous pouvez payer suffisamment pour continuer à attirer de nouveaux talents, l'option de ne conserver qu'un administrateur pour un laps de temps prédéterminé (IE 6 mois, 1 an, 2 ans) vous permettrait de limiter le temps que quelqu'un aurait pour tenter de rassembler toutes les pièces de votre adresse IP.
Ma conception personnelle serait quelque chose dans le sens de ... Divisez vos données en autant de pièces, disons pour avoir un numéro 8, vous avez 8 serveurs git, chacun avec son propre ensemble de matériel redondant, chacun administré par un ensemble différent d'administrateurs.
Disques durs chiffrés pour tous les postes de travail qui toucheront l'IP. avec un répertoire "projet" spécifique sur le lecteur qui est le seul répertoire auquel les utilisateurs sont autorisés à placer 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 sûr).
Chaque bit du projet a un administrateur différent qui lui est affecté, donc un utilisateur n'interagirait 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 affecté. Leurs systèmes ne devraient pas avoir de capacités de gravure et devraient utiliser un programme de sécurité pour empêcher l'utilisation de lecteurs flash USB pour transférer des données sans autorisation.
prenez de cela ce que vous voulez.
Ce serait semblable au défi d'embaucher un concierge pour un immeuble. Le concierge peut avoir toutes les clés, peut ouvrir n'importe quelle porte, mais la raison en est que le concierge en a besoin pour faire le travail. Même chose avec les administrateurs système. Symétriquement, on peut penser à ce problème séculaire et regarder comment la confiance est accordée historiquement.
Bien qu'il n'y ait pas de solution technique claire, le fait qu'il n'y en ait pas ne devrait pas être une raison pour laquelle nous n'en essayons pas, une agrégation de solutions imparfaites peut donner des résultats quelque peu excellents.
Un modèle où la confiance est gagnée :
- Donnez moins d'autorisations pour commencer
- Augmentez progressivement les autorisations
- Mettez un pot de miel et surveillez ce qui se passe 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 du système d'exploitation
Créez toujours un environnement où l'accès total par une seule personne n'est pas possible :
- Systèmes fractionné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
- Exiger un administrateur de cluster1 et cluster2 pour les modifications de base
Faites confiance et vérifiez :
- Enregistrez tout
- Surveillance des journaux et alertes
- Assurez-vous que toutes les actions se distinguent
Formalités administratives :
- Leur faire signer des documents pour que le système judiciaire puisse vous aider en les poursuivant s'ils vous font du mal, cela les incite davantage à ne pas le faire
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 tentent de le faire, le coût ajoute à la fois quelque chose d'autre qui peut casser [~ # ~] et [~ # ~] ajout d'obstacles aux tentatives de correction. La disponibilité de votre système [~ # ~] diminuera [~ # ~] lorsque vous implémenterez quelque chose comme ça, définissez donc cette attente au plus tôt comme coût de protection des choses .
Une autre possibilité consiste à voir si votre application peut fonctionner sur des hôtes jetables via un fournisseur de cloud ou dans un cloud privé hébergé localement. Quand on casse, au lieu d'envoyer un administrateur pour le réparer, vous le jetez et créez automatiquement un remplacement. Cela nécessitera beaucoup de travail du côté des applications pour les faire fonctionner dans ce modèle, mais cela peut résoudre de nombreux 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 obtenez de l'aide expérimentée si vous suivez cette voie.
Ceci 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 de sécurité dont le travail consiste à faire des configurations et des installations de système, mais ils n'obtiennent aucune information d'identification ni accès aux machines en production. Ils exécutent également votre infrastructure d'audit.
Vous avez des administrateurs de production qui reçoivent les systèmes, mais vous n'avez pas les clés pour démarrer la machine sans que les politiques SELinux 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 lorsqu'une machine cassée est retirée du service.
Utilisez un système d'authentification centralisé avec un audit solide comme Vault et utilisez ses opérations de cryptage. Distribuez des appareils Yubikey pour rendre les clés absolument privées et illisibles.
Les machines sont soit essuyées en cas de casse, soit traitées ensemble par les opérations et la sécurité, et si vous ressentez le besoin d'une surveillance de la part des cadres.
Les administrateurs, par la nature du travail, ont accès à tout. Ils peuvent voir tous les fichiers du système de fichiers avec leurs informations d'identification d'administrateur. Ainsi, vous aurez besoin d'un moyen de crypter 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 le cryptage transparent Vormetric ( http://www.vormetric.com/products/transparent-encryption )
La façon dont cela fonctionnerait est qu'il se situe entre le système de fichiers et les applications qui y accèdent. La direction peut créer la stratégie qui dit "Seul l'utilisateur httpd, exécutant le démon du serveur Web peut voir les fichiers non chiffrés". Ensuite, un administrateur avec ses informations d'identification root 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 additionner le binaire pour compliquer la tâche de l'administrateur.
Bien sûr, 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 le sachent.
Le seul moyen pratique est de restreindre qui peut faire quoi avec Sudo. Vous pouvez également faire la plupart de ce que vous voulez avec selinux, mais il faudrait probablement une éternité pour déterminer la configuration correcte, ce qui peut la rendre impossible.
Accords de non-divulgation. Embaucher un administrateur système, ils doivent signer un NDA, s'ils ne respectent pas leur promesse, les traduire en justice. Cela ne peut pas empêcher les empêcher de voler des secrets, mais tout dommage qu'ils causent en le faisant est récupérable en justice.
Les administrateurs système militaires et gouvernementaux doivent obtenir des autorisations de sécurité de différentes qualités en fonction de la sensibilité du matériel. L'idée étant 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 précédemment, pas à la place de) consiste à payer beaucoup d'argent à vos administrateurs système. Payez-les si bien qu'ils ne veulent pas voler votre adresse IP et vous quitter.
Je pense que cette question pourrait ne pas être possible de répondre pleinement sans plus de détails, tels que:
Combien d'administrateurs système vous attendez-vous à garder "restreint"?
À quoi les gens ont-ils besoin d'un accès "administrateur système"?
Tout d'abord, sachez ce que vous pouvez faire avec Sudo. Avec Sudo, vous pouvez autoriser des autorisations élevées à exécuter une seule commande (ou des variantes, comme des commandes commençant par "mount -r" mais d'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 simple de permettre à quiconque (qui possède une clé SSH) de pouvoir effectuer certaines opérations spécifiques sans les laisser 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 généralement nécessiter une quantité plus élevée d'autorisations et peut-être un accès pour exécuter une grande variété de commandes et/ou écrire 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 sur 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 restaure la machine à une image correcte), sans nécessairement lui donner accès à lire beaucoup de données, ou apporter de petites modifications (comme la combinaison d'un correctif mineur avec l'introduction d'une porte arrière non autorisée). Ensuite, vous devez faire confiance aux personnes qui réalisent les images, mais vous réduisez le nombre de personnes auxquelles vous devez faire confiance pour faire les petites choses.
En fin de compte, cependant, une certaine confiance doit être fournie à un nombre non nul de personnes qui aident à concevoir le système et qui opèrent au plus haut niveau.
Une grande chose que font les grandes entreprises est de s'appuyer sur des choses comme les serveurs SQL, qui stockent des données accessibles à distance par un plus grand nombre de machines. Ensuite, un plus grand nombre de techniciens peuvent avoir un accès root complet sur certaines machines, sans avoir accès root aux serveurs SQL.
Une autre approche consiste à être trop gros pour échouer. Ne pensez pas que les grandes armées ou les sociétés géantes 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 poursuites
- ont des processus pour aider à limiter l'exposition indésirable à la presse et ont des plans pour influencer la rotation de toutes les histoires négatives qui se développent
L'hypothèse de base est que les dommages qui se produisent sont simplement un risque et un coût de leur activité. Ils prévoient de continuer à fonctionner, et les développements et améliorations en cours au fil des ans limiteront les dommages qu'un seul incident est susceptible d'affecter réellement leur valeur à long terme sur une période de temps.
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 travailleront toujours ensemble, en observant les activités des autres. Ce devrait être la seule machine contenant la clé privée à se connecter en tant que root.
Certaines activités peuvent ne pas nécessiter de droits root, donc seule une partie du travail nécessiterait d'aller dans cette salle pour la "programmation par paires"
Vous pouvez également enregistrer des activités vidéo 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 les grandes polices).
La 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 sont disponibles) sont très efficaces pour appliquer la responsabilité sysadmin.