(Прошу прощения, если я задаю неправильный вопрос или не в том месте.)
Мы занимаемся ИТ для нашей ассоциации (все волонтеры). У нас есть сервер с базой данных в OpenLDAP, почтовый сервер, ftp и куча самодельных веб-приложений.
По большей части это нормально, за исключением базы данных членов OpenLDAP. Люди, которые его создали, давно ушли, и нынешняя ИТ-группа не в состоянии вносить изменения.
Итак, я думал о перемещении членской базы данных из OpenLDAP в базу данных MySQL. Это кажется возможным, наши электронная почта и FTP-сервер поддерживают источники SQL, и мы можем соответствующим образом модифицировать наши веб-приложения. Но я все еще не могу решить, есть ли в этом недостаток. Отсюда мои вопросы:
Я не мог найти здесь аналогичного вопроса. И информация, которую я нахожу извне, переносит меня на страницы, которым больше 10 лет.
Это обширная тема, на которую нет однозначного ответа, поскольку она зависит от множества факторов.
Некоторые преимущества (открытого) LDAP как базы данных пользователей:
К сожалению, на самом деле управление LDAP намного сложнее по сравнению с простой базой данных SQL, и если все ваши системы могут полностью работать с одной и той же базой данных пользователей SQL, нет реальной причины, по которой вы необходимость вместо этого использовать LDAP. С другой стороны, я бы подумал очень долго и упорно о том, если это не на самом деле проще сесть и понять, LDAP до копирования его и заменить его чем-то другим. Подобные изменения, как правило, кажутся легкими, когда вы начинаете, но по ходу всегда появляются проблемы, которые вы не учли, которые значительно усложняют задачу, чем предполагалось.
Можете ли вы использовать базу данных MySQL в качестве общего источника учетных записей пользователей? Определенно да. Я установил такую систему, и она хорошо работает с несколькими приложениями.
Итак, каковы недостатки использования базы данных MySQL вместо LDAP?
а) Вам необходимо адаптировать все приложения для использования вашей базы данных.
Обычно не так много работы, чтобы адаптироваться ан применение. Часто вы можете просто решить эту проблему, создав представление, которое адаптирует имена столбцов. Иногда вам может потребоваться добавить немного кода для обслуживания другого формата хеширования паролей или для создания плагина аутентификации.
Однако вам нужно будет это сделать для каждого приложения. И когда завтра вас попросят установить новое веб-приложение (например, кто-то решит добавить блог Wordpress), вам нужно будет еще раз изучить приложение и посмотреть, как его адаптировать.
«Все» поддерживают аутентификацию по LDAP. Это де-факто стандарт, и вы найдете плагины для выполнения аутентификации LDAP в любом приложении с приличным размером (а для тех, которые этого не делают, есть ясный случай для реализации этого). Есть несколько (очень мало) альтернатив, и они мало поддерживают использование для аутентификации.
Также обратите внимание, что если приложение использует другой механизм базы данных (предположим, что есть новая разработка, требующая использования PostgreSQL), может быть сложнее дополнительно заставить его поддерживать пользовательскую таблицу из другого механизма (mysql).
Конечно, саму адаптацию вы можете сделать только в том случае, если это ваша собственная разработка или открытый исходный код. Забудьте о том, чтобы Microsoft Windows поддерживала такую нестандартную схему!
б) Централизация безопасности
Использование центрального сервера аутентификации имеет несколько преимуществ:
Во-первых, если у вас есть центральный сервер, и кто-то пытается подобрать пароль для пользователя john, обычная настройка - блокировать пользователя на некоторое время (или до тех пор, пока его не разблокируют вручную). Если у вас есть дюжина служб, даже если бы все они имели некоторые меры регулирования (подсказка: они, вероятно, не имеют), каждая из них будет разделена, и, атакуя несколько служб, злоумышленник фактически будет иметь N попыток, умноженное на количество служб. . Вам нужно будет согласовать эти метаданные с общей базой данных, а также все службы, чтобы проверить их и реализовать таким же образом (дополнительный код для добавления в приложения, почтовые и ftp-серверы ...).
Во-вторых, централизованная вырубка. Выполнение аутентификации в одной службе позволяет вам иметь единый журнал аутентификации, а не разбивать его на несколько мест.
В-третьих, это единая точка для обновлений. Вы хотите отказаться от хешей MD5 и использовать pdkdf2 или Argon2? Вам нужно только обновить сервер аутентификации для его поддержки. В противном случае вам нужно будет получить каждая услуга для поддержки этого нового формата.
В-четвертых, большая изоляция. Если вся проверка подлинности проходит через центральный сервер, ее следует настроить так, чтобы он был единственным, кто мог читать конфиденциальные данные, и вы могли сосредоточить свои усилия на обеспечении безопасности. Однако, если каждой службе необходимо проверять пароли пользователей, у вас есть гораздо большая поверхность: уязвимость SQL-инъекции на любой из них позволит сбросить список пользователей и хэшей (и я уже предполагаю, что он был сделан только для чтения, иначе они могут даже изменить их или вставить поддельных пользователей).
Обратите внимание, что вы можете решить (b), имея центральный сервер, который вообще не использует LDAP. Но с учетом (а) имеет смысл продолжать использовать протокол LDAP для аутентификации.
Нет причин, по которым сервер LDAP, в основном используемый для аутентификации, не может использовать базу данных MySQL для хранения. Фактически, LDAP намного эффективнее, чем при обычном использовании (вот почему он выглядит таким устрашающим). Однако мне не известно о какой-либо реализации, делающей это.
Я рекомендую сохранить текущий сервер LDAP и при необходимости создать интерфейс для выполнения на нем наиболее распространенных действий (существует несколько интерфейсов LDAP, возможно, один из них покроет потребности вашей ИТ-группы?).
Если вы хотите изменить процесс входа в пользовательские веб-приложения, я бы сделал их так, чтобы они поддерживали решение единого входа, такое как SAML, но, тем не менее, я бы по-прежнему использовал этот бэкэнд LDAP, который будет использоваться совместно с вашим FTP, почтой и другие услуги.
Просто хотел добавить то, что (пока) не указано в других ответах: сравнение LDAP и SQL - это сравнение яблок и апельсинов, поскольку они находятся на разных уровнях в стеке.
Вы можете реализовать LDAP, используя базы данных SQL, но помните, что они поддерживают разные функции. (Фактически, большинство решений LDAP, вероятно, используют некоторый SQL или другую базу данных за кулисами.)
LDAP - это промышленный стандарт для служб каталогов. Возможно, что многие из ваших нижестоящих служб полагаются на службу LDAP для аутентификации, авторизации и т. Д., И в этом случае вам все равно потребуется создать слой, совместимый с LDAP, поверх вашей новой базы данных SQL.
В то же время возможно, что другие ваши приложения не нуждаются в этой совместимости с LDAP, и может быть проще перейти на ваше собственное управление пользователями SQL. Но даже в этом случае я подозреваю, что вам может понадобиться ваша собственная логика управления пользователями в приложениях (если они не поддерживают OAuth или что-то подобное).
Я бы порекомендовал сначала взглянуть на другие ваши ИТ-приложения, чтобы увидеть, насколько они привязаны к службе LDAP для служб входа и авторизации, а затем решить, насколько легко или болезненно будет перейти на настраиваемое решение для базы данных SQL.