Автентифікація мережі + домашній каталог роумінгу - яку технологію я повинен використовувати?

Я вивчаю програмне забезпечення, яке надає користувачеві єдину ідентичність на кількох комп'ютерах. Тобто, користувач повинен мати однакові дозволи на кожному комп’ютері, а користувач повинен мати доступ до всіх своїх файлів (домашнього каталогу роумінгу) на кожному комп’ютері. Здається, існує багато рішень для цієї загальної ідеї, але я намагаюся визначити найкраще для мене. Ось деякі деталі та вимоги:

1. Мережа машин - це екземпляри Amazon EC2, на яких працює Ubuntu.
   • Ми отримуємо доступ до машин із SSH.
   • Деякі машини в цій локальній мережі можуть мати різне використання, але я обговорюю лише машини для певного використання (запуск платформи, що надає багато користувачів).
2. Система не обов’язково матиме постійну кількість машин.
   • Можливо, нам доведеться постійно або тимчасово змінювати кількість працюючих машин. Це причина, чому я розглядаю централізовану аутентифікацію / зберігання.
3. Реалізація цього ефекту має бути безпечною.
   • Ми не впевнені, що користувачі матимуть прямий доступ до оболонки, але їх програмне забезпечення потенційно буде працювати (під обмеженими іменами користувачів Linux, звичайно) в наших системах, що так само добре, як і прямий доступ до оболонки.
   • Припустимо, що їх програмне забезпечення могло б бути зловмисним заради безпеки.

Я чув про декілька технологій / комбінацій для досягнення своєї мети, але не впевнений у наслідках кожної з них.

• Старіший пост ServerFault рекомендував NFS & NIS, хоча комбінація має проблеми із безпекою відповідно до цієї старої статті Symantec . У статті запропоновано перейти до NIS +, але, як це вже давно , ця стаття у Вікіпедії цитує твердження, що пропонують тенденцію від NIS + від Sun. Рекомендована заміна - ще одна річ, про яку я чув ...
• LDAP. Схоже, LDAP можна використовувати для збереження інформації про користувачів у централізованому місці в мережі. NFS все ще потрібно використовувати для покриття вимоги "домашня папка роумінгу", але я бачу, що посилання на них використовуються разом. Оскільки стаття Symantec вказала на проблеми безпеки як в NIS, так і в NFS, чи існує програмне забезпечення для заміни NFS, або я повинен прислухатися до пропозицій цієї статті щодо його блокування? Я прагну до LDAP, оскільки інший фундаментальний фрагмент нашої архітектури, RabbitMQ, має плагін для автентифікації / авторизації для LDAP. RabbitMQ буде доступним обмеженим чином для користувачів в системі, тому я хотів би, якщо можливо, зв’язати системи безпеки разом.
• Kerberos - це ще один безпечний протокол аутентифікації, про який я чув. Я дізнався про це трохи років тому в класі криптографії, але не пам’ятаю багато про це. Я бачив пропозиції в Інтернеті про те, що він може поєднуватися з LDAP декількома способами. Це потрібно? Які ризики для безпеки LDAP без Kerberos? Я також пам’ятаю, що Керберос використовувався в іншому програмному забезпеченні, розробленому університетом Карнегі Меллон ...
• Ендрю файлова система або AFS. OpenAFS доступний для використання, хоча його налаштування здається дещо складним. У моєму університеті AFS надає обидві вимоги ... Я можу увійти на будь-яку машину, і моя "папка AFS" завжди доступна (принаймні, коли я набуваю маркер AFS).

Поряд із пропозиціями, на який шлях я повинен звернутись, чи є у когось посібники, які були б особливо корисними? Як вказував сміливий текст, LDAP є найкращим вибором, але мене особливо цікавлять деталі реалізації (Keberos? NFS?) Щодо безпеки.

Інформація про автентифікацію, авторизацію та каталог

Це не є повною відповіддю на ваше запитання, але я подумав, що це може допомогти вирішити ваші запитання щодо NIS проти LDAP проти Kerberos.

Почніть з цього , що дає хороший огляд різниці між автентифікацією та авторизацією , що важливо розуміти для такого роду обговорень.

Kerberos, як ви кажете, просто протокол аутентифікації. Враховуючи набір облікових даних - наприклад, ім’я користувача та пароль - він підкаже, чи дійсні вони чи ні. Це все, що вона робить.

На відміну від них, і NIS, і LDAP є службами каталогів. Вони дозволяють клієнту запитувати їх щодо інформації про користувачів (який ваш домашній каталог? Який ваш ідентифікатор користувача?). Обидва можуть використовуватися як джерела аутентифікації з різним зменшенням проблем.

NIS насправді не проводить аутентифікацію для вас самостійно. Швидше, він відкриває хеш паролів на клієнтських машинах, і ваша локальна система виконує фактичний крок аутентифікації так само, як і для локальних облікових записів. Проблема тут полягає в тому, що кожен, хто має обліковий запис одного з ваших клієнтів NIS, може захопити всі ваші паролі, а потім здійснити жорстоку атаку на них у своє дозвілля.

LDAP дещо безпечніший, оскільки крок аутентифікації насправді виконується на сервері. Ви повинні переконатися, що ви шифруєте свої сеанси LDAP за допомогою SSL або TLS, інакше пароль виставляється в чіткому тексті на дроті, де він вразливий для обнюхування пакетів.

Дуже часто використовувати Kerberos для аутентифікації, а потім або NIS або LDAP для авторизації (зазвичай це означає "членство в групі") та інформацію про каталоги. Я б заперечував, що після того, як ви видалили хеші паролів (перемістивши аутентифікацію на Kerberos), NIS насправді не менш безпечний, ніж LDAP, і має перевагу бути доступним "поза коробкою" у будь-якому сучасному дистрибутиві Linux.

З іншого боку, LDAP, як правило, набагато більш розширюється, масштабується краще, якщо у вас є велика кількість користувачів (або інших об'єктів каталогів), передбачено розширені запити і, як правило, більш керовані. LDAP також підтримується на самому рівні в різних програмах, тоді як NIS має дивні інцестуальні стосунки з основною операційною системою, які можуть бути небажаними.

Якщо ви будуєте речі з нуля, я б запропонував Kerberos для автентифікації та LDAP для служби вашого каталогу.

Файлові системи

NFS має велику перевагу: у вас її вже є, вона широко розгорнута і в цілому стабільна. Є два основних недоліки NFS:

• Він не масштабується для паралельного вводу / виводу. Якщо у вас є велика кількість машин, що потрапляють на одну файлову систему, ваш єдиний сервер NFS, можливо, буде важко йти в ногу. Ось чому більші кластери зазвичай використовують файлову систему кластерів (наприклад Luster, GlusterFS, GPFS, GFS тощо), розроблену для підтримки паралельного вводу-виводу.

• У нього погана модель безпеки. Як правило, рішення щодо безпеки NFS повністю базуються на вашому числовому ідентифікаторі користувача. Якщо у вас є корінь у системі, яка може монтувати файлову систему NFS, у вас є доступ до всіх файлів - адже ви завжди можете створити місцевого користувача з відповідним ідентифікатором користувача. Це не строго вірно, тому що обидва NFSv3 і NFSv4 мають різні рівні підтримки аутентифікації Kerberos, але я ще не зустрічав , хто використовує це ... так що ваш пробіг може варіюватися.

Для невеликих розгортань більшість людей просто використовують NFS, незважаючи на її обмеження.

Існує безліч інших рішень - файлові системи кластерів, про які я згадував вище, а також AFS та інші - але для більшості з них потрібна деяка робота з вашого боку, щоб запустити їх на будь-який дистрибутив, який ви вибрали. Нещодавно я чула хороші речі про GlusterFS, тож якби я шукала альтернативу NFS, це могло б стати першим місцем.

Це часткова відповідь.

NIS / NIS +
Не використовуйте NIS. Використовуйте LDAP за схемою nis.

OpenLDAP (aka slapd на Ubuntu)
Не забудьте встановити належні ACL та SSF (коефіцієнти міцності безпеки).
Дуже легко надсилати паролі, якщо ви не обережні.
http://www.openldap.org/doc/

NFS
NFS не є зашифрованим.
Його можна загорнути в ssl з деякою хитрістю.
Без Kerberos покладається на ip_addr для авт.
З Kerberos можливо, що SASL використовується для шифрування всього.

Kerberos
Потрібен, щоб OpenLDAP мав проходити автентифікацію SASL для аутентифікації LDAP. (Не важко.)
Слід використовувати записи DNS. (Не потрібно, але дуже корисно).
GSSAPI можна використовувати замість ssh-ключів. (Може співіснувати.)
KDC-машини повинні бути окремими від ваших клієнтських машин.

OpenAFS
зашифровано з DES. (Не вважається безпечним.)
Потрібен або kerberos, або власний застарілий автосервер.
Має власні ACL файлової системи.