Комментарии 36
Все хорошо, только разваливается при требовании некоей странички учёта времени на корпоративном портале ввести юзера и пароль. Да менять пароль раз в три месяца.
Я к тому что некоторым внутренним приложениям вообще нужна неаутентификация, а только идентификация. Тут все средства хороши лишь бы не вводить ничего.
Аутентификация это и есть идентификация. Возможно вы имели ввиду авторизацию? Т.е. далеко не всем нужна авторизация (факт наличия прав на некое действие), а достаточно только аутентификации (т.е. подтверждения что вы это вы).
Э нет. Аутентификация гораздо больше идентификации. Это если хотите гарантированая идентификация. А просто идентификация это "я Вася". Без доказательств. И этого достаточно многим некритичнам внутренним приложениям.
Ок. Вы убедили меня что идентификация и аутентификация это разные понятия. Но тогда я в упор не понимаю где применяется именно идентификация. Оффтопик конечно, но не расскажете ли?
Если доступен извне и прозрачная доменная аутентификация невозможна, есть альтернативные варианты. Наиболее популярные сейчас — SAML и OpenID Connect
6. LDAP-аутентификация и современные сервисы аутентификации взаимоисключают друг друга
Приложение, использующее LDAP для аутентификации, всегда будет вынуждено опираться на имена пользователей и пароли. Попытка реализовать современные технологии, такие как многофакторная аутентификация и единый вход, практически невозможна
Простите, что? Если взять AD как реализацию LDAP, то он отлично интегрируется с AAD и AD FS — вот вам и MFA, и SSO.
Это же код писать надо в своей приложеньки. Местами сложный.
А по логину с паролем достаточно с so скопипастить.
Интересный вопрос, в AD DS вокруг каталога Kerberos и NTLM, ещё и сам каталог не совсем соответствует ntds.dit.
Автор, насколько я понимаю, обсуждает проблему простой аутентификации через открытие ldap каталога. Какой-нибудь HP BladeCenter или Zabbix, которые просто открывают LDAP каталог с вашим логином и плейн-текстовым паролем, и если всё получилось — ура, пароль был верным. Заодно одно ваши группы прочитать для авторизации, а можно и не только ваши, и не только почитать.
Может быть вы тогда можете посоветовать небольшой сервер для авторизации\аутентификации для self-hosting?
Все сервера для OpenID и OAUTH, что я находил являются огромными монстрами на Java, которые запустить и настроить является заметной проблемой.
Доступ злоумышленника к незаблокированному компьютеру в любом случае даст ему доступ ко всему к чему есть доступ у пользователя.
Запустить один бинарник на незаблокированном компе не выглядит сложной задачей.
Только вот на таком работать нельзя. У обычного разработчика ноут с полными правами и всеми портами.
Девочка с браузером это предел для такой конфигурации. А у нее и не должно быть доступов никуда. Надо по умолчанию считать что все что у нее есть она сольет.
Впрочем, кроме разработчиков и девочек, существует ещё масса промежуточных категорий пользователей, которые могут заказывать или отпускать товары, совершать денежные и материальные трансферы, выписывать пропуска и виды на жительство, принимать на работу или увольнять, объявлять в розыск или наоборот, не говоря уже о возможности влияния на производственый цикл или управление энергопотоками — и да, всё это чисто мышкой и клавиатурой, иногда ещё джойстиком и аналогичными присоблениями.
SSO это конечно удобно, но вовсе не панацея и имеет свои недостатки.
И ничего. Все безопасно и ничего по вине Гугла не утекает. Значит дело не в правах на ноутах, а в бумерах которые думают что дело в ноуте или вообще в одежде.
Ну так делим по такому же принципу. Доступ только к тому к чему он нужен. Операции разумно ограничены. По простому «Полная выгрузка базы не нужна среднему пользователю. Да и рейт лимитер полезно прикрутить.» Ну и так далее в зависимости от предметной области.
Да какие мышки с джойстиками. Мы тут вроде как разработчики. На Питоне наговнокодить все можно. С любой машины. Питона нет, так я и на Баше напишу. Апи хоть какое-то есть и дальше дело техники. Соответвенно исходим из того что любой злоумышленник устроившийся на работу может сделать тоже самое.
SSO это как раз панацея. Один пароль можно заставлять делать сложным и учить наизусть. С привязкой к компу вообще хорошо. Логин с другого компа это сразу алярм.
А вот если пароль надо вводить по 10 раз для начала работы, то уже так не выйдет. Если пароли разные, то вообще можно сразу тушить свет. Люди извернутся, но придумают как сделать так чтобы попроще печатать было. Люди они такие.
Ещё раз напомню — речь не только (и не столько) о разработчиках, если на терминале работает клерк с доступом к счетам в банке, и он с этого терминала может всё после логина — значит пока он вышел я могу себе на счёте выставить кредитный лимит на миллион, или списать любой долг (да, есть и такая возможность, правда зависит от ранга клерка).
Разумеется, любой злоумышленник который устроится клерком сможет ровно то же самое (хотя это тоже тот ещё квест), но одно дело если он это сделает со своего аккаунта (тогда будут искать его), и совсем другое если с чужого (его могут и не найти, а шишки повалятся на другого).
SSO в чистом виде применим только в очень доверенной среде, и его слепое использование «потому что удобно» открывает много рисков (погуглите «sso risks»).
Это не значит что от него нужно отказываться — но риски нужно учитывать и принимать меры, вплоть до того чтобы применять SSO селективно, в зависимости от конкретной среды или даже конкретной транзакции.
Простите, если не у разработчиков то у кого доступ к проду должен быть? Кто будет править ошибки когда все сломалось? Кто новые версии разворачивать и мониторить будет? Кто ошибки которые появляются только на проде ловить будет? Эльфы?
Если у вас в системе клерк может кредитный лимит просто выставить или долг списать так что об этом через минуту не узнают все, то у вас проблемы с процессами. Большие проблемы. Не надо валить проблемы с больной головы на здоровую.
Устроится на работу в банк клерком сложно? Вы это серьезно? Естесвенно со своего, а с какого еще? К другим аккаунтам доступа быть не должно вообще.
Нет. SSO закрывает самую главную дыру. Пароли пользователей с возможность авторизации по сети с любого оборудования. Основная дыра это человек. Как раз ее SSO и прикрывает.
Нет, его надо просто использовать. Можно добавить 2fa для логина в места где ну совсем секретно. Или там для перевода миллиона долларов. И раздать токены кому надо. Главное чтобы эти операции были не по 100 раз на дню. Иначе пользователи автоматизируют и упростят.
Простите, если не у разработчиков то у кого доступ к проду должен быть? Кто будет править ошибки когда все сломалось? Кто новые версии разворачивать и мониторить будет? Кто ошибки которые появляются только на проде ловить будет? Эльфы?
К проду доступа быть не должно ни у кого, кроме как у CD (continuous delivery) системы. Ошибки править будут разработчики, но никак не на продакшне. Новые версии разворачивает CD тулсет. Мониторит система мониторинга. Ошибки, которые появляются только на проде, отлично видно в логах и в мониторинге прода.
Так а кто настраивает CD? Кто ее входными данными кормит? А если данные на проде разошлись? Или просто прилетело что-то странное и роняющее все. А перешардировать прод кто будет?
Править не на проде хорошо конечно. Но как сказал один умный человек "Когда у вас петабайты данных, то теста нет. Тест становится слишком дорогим. И что делают разработчики? Правильно! Тестируют на проде" Отсюда весь этот девопс и доступы для разработчиков.
Логи, кодревью, аппрув от 2 человек. Это все нормальные практики для защиты прода.
если ваша вики/вебприложение крутится на стеке линукс+апач+PHP, то надо перетащить на виндовый апач и установить mod_auth_sspi и удостовериться что сайт вики находится в доверенной зоне браузера
docs.ipi-manager.ru/AdministratorGuide/Configuration/ActiveDirectory/Apache
www.johnthedeveloper.co.uk/single-sign-on-active-directory-php-ubuntu
blog.stefan-macke.com/2011/04/19/single-sign-on-with-kerberos-using-debian-and-windows-server-2008-r2
serverfault.com/questions/699641/how-to-avoid-frequent-kvno-increases-when-using-apache-httpd-with-mod-auth-kerb
последняя ссылка для тех, у кого перестает работать авторизация ровно через неделю после настройки keytab
Читаем RFC 4513:
6.3.2. Name/Password Mechanism Security Considerations
The name/password authentication mechanism of the simple Bind method
discloses the password to the server, which is an inherent security
risk. There are other mechanisms, such as SASL DIGEST-MD5
[DIGEST-MD5], that do not disclose the password to the server.
> Существует риск, что приложение будет получать пароль по небезопасному каналу.
Если кто-то передает пароли в открытом виде в своем приложении, то чем здесь LDAP провинился?
Защищает ли этот механизм от переиспользования учётных данных? От выполнения сервером или mitm любых действий в каталоге от вашего имени?
Для DIGEST аутентификации сервер должен уже знать пароль пользователя, притом открытым текстом. Точнее, достаточно особого хеша от него, но это не играет особой роли: зная этот хеш, можно выдать себя за пользователя, то есть этот хеш на самом деле и есть "digest-пароль" в открытом виде.
Единственное что тут можно сделать — это каждому серверу свой realm назначать, но это же надо писать свой плагин для LSA контроллера домена, что так себе затея.
К тому же, все мечты о безопасности разбиваются о MD5.
В общем, в домене DIGEST-MD5 безопасным методом не является ни разу.
LDAP-«аутентификация» — это антипаттерн