Authentification réseau + répertoire personnel itinérant - quelle technologie dois-je envisager d'utiliser?


9

J'examine un logiciel qui fournit à un utilisateur une identité unique sur plusieurs ordinateurs. En d'autres termes, un utilisateur doit disposer des mêmes autorisations sur chaque ordinateur et l'utilisateur doit avoir accès à tous ses fichiers (répertoire de départ itinérant) sur chaque ordinateur. Il semble y avoir de nombreuses solutions pour cette idée générale, mais j'essaie de déterminer la meilleure pour moi. Voici quelques détails ainsi que les exigences:

  1. Le réseau de machines sont des instances Amazon EC2 exécutant Ubuntu.
    • Nous accédons aux machines avec SSH.
    • Certaines machines sur ce LAN peuvent avoir des utilisations différentes, mais je ne parle que des machines pour une certaine utilisation (exécution d'une plate-forme multi-locataire).
  2. Le système n'aura pas nécessairement un nombre constant de machines.
    • Il se peut que nous devions modifier de manière permanente ou temporaire le nombre de machines en cours d'exécution. C'est la raison pour laquelle j'examine l'authentification / stockage centralisé.
  3. La mise en œuvre de cet effet doit être sécurisée.
    • Nous ne savons pas si les utilisateurs auront un accès direct au shell, mais leur logiciel sera potentiellement exécuté (sous des noms d'utilisateurs Linux restreints, bien sûr) sur nos systèmes, ce qui équivaut à un accès direct au shell.
    • Supposons que leur logiciel puisse être potentiellement malveillant pour des raisons de sécurité.

J'ai entendu parler de plusieurs technologies / combinaisons pour atteindre mon objectif, mais je ne suis pas sûr des ramifications de chacune.

  • Un ancien article de ServerFault recommandait NFS et NIS, bien que la combinaison présente des problèmes de sécurité selon cet ancien article de Symantec . L'article suggère de passer à NIS +, mais, comme il est ancien, cet article de Wikipedia a cité des déclarations suggérant une tendance à l'écart de NIS + par Sun. Le remplacement recommandé est une autre chose dont j'ai entendu parler ...
  • LDAP. Il semble que LDAP puisse être utilisé pour enregistrer les informations utilisateur dans un emplacement centralisé sur un réseau. NFS devrait encore être utilisé pour couvrir l'exigence de «dossier de départ itinérant», mais je vois des références à leur utilisation ensemble. Étant donné que l'article de Symantec a souligné des problèmes de sécurité dans NIS et NFS, existe-t-il un logiciel pour remplacer NFS, ou devrais-je tenir compte des suggestions de cet article pour le verrouiller? Je tends vers LDAP parce qu'un autre élément fondamental de notre architecture, RabbitMQ, a un plugin d'authentification / autorisation pour LDAP. RabbitMQ sera accessible de manière restreinte aux utilisateurs du système, donc je voudrais lier les systèmes de sécurité ensemble si possible.
  • Kerberos est un autre protocole d'authentification sécurisé dont j'ai entendu parler. J'ai appris un peu à ce sujet il y a quelques années dans un cours de cryptographie, mais je ne m'en souviens pas beaucoup. J'ai vu des suggestions en ligne selon lesquelles il peut être combiné avec LDAP de plusieurs manières. Est-ce nécessaire? Quels sont les risques de sécurité de LDAP sans Kerberos? Je me souviens aussi que Kerberos était utilisé dans un autre logiciel développé par l'Université Carnegie Mellon ...
  • Andrew File System, ou AFS. OpenAFS est disponible, bien que sa configuration semble un peu compliquée. Dans mon université, AFS fournit les deux exigences ... Je peux me connecter à n'importe quelle machine et mon "dossier AFS" est toujours disponible (au moins lorsque j'achète un token AFS).

Avec des suggestions sur la voie à suivre, quelqu'un a-t-il des guides particulièrement utiles? Comme le souligne le texte en gras, LDAP semble être le meilleur choix, mais je suis particulièrement intéressé par les détails de mise en œuvre (Keberos? NFS?) En ce qui concerne la sécurité.

Réponses:


7

Authentification, autorisation et informations de répertoire

Ce n'est pas une réponse complète à votre question, mais j'ai pensé que cela pourrait aider à répondre à vos questions sur NIS vs LDAP vs Kerberos.

Commencez par cela , qui donne un bon aperçu de la différence entre l' authentification et l' autorisation , ce qui est important à comprendre pour ce type de discussion.

Kerberos n'est, comme vous le dites, qu'un protocole d'authentification. Étant donné un ensemble d'informations d'identification - par exemple, un nom d'utilisateur et un mot de passe - il vous dira si elles sont valides ou non. C'est tout ce qu'il fait.

En revanche, NIS et LDAP sont des services d'annuaire. Ils permettent à un client de leur demander des informations sur les utilisateurs (quel est votre répertoire personnel? Quel est votre ID utilisateur?). Les deux peuvent être utilisés comme sources d'authentification avec différents degrés de problèmes.

NIS n'effectue pas vraiment d'authentification par vous-même. Au lieu de cela, il expose un hachage de mot de passe aux ordinateurs clients et votre système local effectue l'étape d'authentification réelle de la même manière que pour les comptes locaux. Le problème ici est que toute personne possédant un compte sur l'un de vos clients NIS peut récupérer tous vos hachages de mot de passe, puis monter une attaque par force brute sur eux à leur guise.

LDAP est un peu plus sécurisé, car l'étape d'authentification est en fait effectuée sur le serveur. Vous devez vous assurer que vous chiffrez vos sessions LDAP avec SSL ou TLS, sinon le mot de passe est exposé en texte clair sur le câble, où il est vulnérable au reniflement de paquets.

Il est très courant d'utiliser Kerberos pour l'authentification, puis NIS ou LDAP pour l'autorisation (généralement cela signifie «appartenance au groupe») et les informations d'annuaire. Je dirais que NIS, une fois que vous avez supprimé les hachages de mot de passe (en déplaçant votre authentification vers Kerberos) n'est pas vraiment moins sécurisé que LDAP, et a l'avantage d'être disponible "prêt à l'emploi" sur toute distribution Linux moderne.

LDAP, en revanche, est généralement beaucoup plus extensible, s'adapte mieux si vous avez un grand nombre d'utilisateurs (ou d'autres objets d'annuaire), fournit des requêtes riches et est généralement plus facile à gérer. LDAP est également pris en charge nativement dans une variété d'applications, tandis que NIS a une relation incestueuse étrange avec le système d'exploitation de base qui peut être indésirable.

Si vous construisez des choses à partir de zéro, je suggère Kerberos pour l'authentification et LDAP pour votre service d'annuaire.

Systèmes de fichiers

NFS a un gros avantage: vous l'avez déjà, il est largement déployé et il est généralement stable. NFS présente deux principaux inconvénients:

  • Il n'évolue pas bien pour les E / S parallèles. Si vous avez un grand nombre de machines qui utilisent le même système de fichiers, votre serveur NFS peut avoir du mal à suivre. C'est pourquoi les clusters plus grands utilisent généralement un système de fichiers de cluster (comme Luster, GlusterFS, GPFS, GFS, etc.) qui a été conçu pour prendre en charge les E / S parallèles.

  • Il a un mauvais modèle de sécurité. En règle générale, les décisions de sécurité NFS sont entièrement basées sur votre ID utilisateur numérique. Si vous avez root sur un système capable de monter un système de fichiers NFS, vous avez accès à tous les fichiers, car vous pouvez toujours créer un utilisateur local avec l'ID utilisateur approprié. Ce n'est pas strictement vrai, car NFSv3 et NFSv4 ont différents niveaux de prise en charge pour l'authentification Kerberos, mais je n'ai encore rencontré personne utilisant cela ... donc votre kilométrage peut varier.

Pour les petits déploiements, la plupart des gens utilisent simplement NFS malgré ses limites.

Il existe une variété d'autres solutions - les systèmes de fichiers de cluster que j'ai mentionnés ci-dessus, ainsi que AFS et d'autres - mais la plupart d'entre elles nécessiteront un certain travail de votre part pour les faire fonctionner sur la distribution que vous avez sélectionnée. J'ai entendu de bonnes choses à propos de GlusterFS récemment, donc si je cherchais une alternative NFS qui pourrait être le premier endroit où je regarde.


Merci d'avoir clarifié ces choses. J'ai en fait une bonne base dans l'autorisation vs l'authentification; Je ne suis simplement pas sûr des capacités de chaque logiciel. La partie de stockage est également importante; savez-vous comment le modèle de sécurité de Kerberos / LDAP est lié à NFS?
Brian

J'ai mis à jour la réponse avec quelques informations sur NFS.
larsks

Dans ce cas, je ne vois aucune raison de se limiter à un seul serveur NFS, bien qu'un seul soit suffisant, et que d'autres puissent être ajoutés plus tard. help.ubuntu.com/community/AutofsLDAP
84104

J'ai essayé de parcourir ce guide AutofsLDAP ainsi que d'autres. Elle est soit mal écrite, soit obsolète, car mes résultats diffèrent et je ne peux pas aller au-delà d'un certain point. :(
Brian

Vous voudrez peut-être ouvrir une nouvelle question avec les détails appropriés.
larsks

0

Ceci est une réponse partielle.

NIS / NIS +
N'utilisez pas NIS. Utilisez LDAP avec le schéma nis.

OpenLDAP (alias slapd sur Ubuntu)
Assurez-vous de configurer les ACL et SSF (facteurs de sécurité) appropriés.
Il est très facile d'envoyer des mots de passe en clair si vous ne faites pas attention.
http://www.openldap.org/doc/

NFS
NFS n'est pas un chiffré.
Il peut être emballé en ssl avec quelques astuces.
Sans Kerberos, s'appuie sur ip_addr pour l'authentification.
Avec Kerberos, il est possible que SASL soit utilisé pour tout chiffrer.

Kerberos
requiert qu'OpenLDAP dispose d'une authentification unique SASL pour l'authentification LDAP. (Pas difficile.)
Devrait utiliser des entrées DNS. (Pas obligatoire, mais très utile).
GSSAPI peut être utilisé à la place des clés ssh. (Peut coexister.) Les
machines KDC doivent être distinctes de vos machines clientes.

OpenAFS chiffré
avec DES. (Pas considéré comme sécurisé.)
Nécessite soit des kerberos, soit son propre serveur d'authentification hérité.
Possède ses propres ACL de système de fichiers.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.