Комментарии 29
Куда вы денетесь.
Искал как можно не через офшоры, а по белому с документами и прочим оплатить один из продуктов известного вендора по двухфакторной аутентификации. Оказалось - все ушли.
Варианты:
Оплата через прокладку + договорится, что будет использоваться здесь
Посмотреть продукт местного пошива. Из более-менее подходящего есть только один, да и то с оговорками на проверку в их облаке и подключению локальной инфраструктуры через их коннекторы.
Была запрошена цена, ценник выше чем у DUO, RSA и прочих. На слова, а как так, ответ простой - куда вы денетесь. Поэтому все вот эти 300 требований ИБ уйдут в одно место: куда вы денетесь, когда купить нечего.
Что сделать? Реализуйте аутентификацию через Active Directory
Если потенциальный покупатель вашего продукта спрашивает про аутентификацию через AD, а вы первый раз про такое слышите - то что-то идет не так....
ЗЫ это вы еще про kerberos не слышали... ))
Вы аккуратнее, так можно и до SAML SSO дойти ненароком.
AD! А как же ПО на Linux, MacOS, мобильных платформах, да хоть через браузер через интернет?
Не, ну я знаю, что сейчас есть реализация поддержки AD для Linux (вроде в какой-то российской, но сам не юзал, не насколько оно там хорошо работает, появилось, вроде бы только в прошлом году - наверное как раз ради удовлетворения таких вот требований корпоративных клиентов - но это пока очень большое исключение)
Все основные компоненты AD давным-давно имеют аналоги на Linux, и задача ввода в домен сервера на linux или, скажем, подключения к домену linux-клиента были решены давным-давно. Я 12 лет назад находил в сети подробные инструкции.
Что и правда появилось только в прошлом году — я так и не понял, но это либо условно-готовое решение для обратной операции, когда сервера на Linux успешно притворяются доменом для windows-клиентов (причём, опять-таки, все компоненты для этого уже были, просто никто не заморачивался их сборкой в готовое решение, ведь было проще и дешевле купить готовое решение чем поддерживать велосипед). Либо же это вовсе аналогичное решение для централизованного управления linux-машинами, которое вообще не имеет к AD отношения.
Насколько я понял, сервер на Linux притворяется сервером AD для клиентов. Это как раз для случая постепенного вывода участков сети из под гегемонии Microsoft Windows
И именно об этом я и говорю - сейчас есть тренд на де-оконизацию (и не только в России), и за пределами Windows-инфраструктутры поддержка AD уже не панацея! И правильная служба ИБ уже вряд ли должна настаивать на глубокой поддержке AD более, чем на поддержки других средств аутентификации - например набирающей популярность OAuth
Вы знаете решения, позволяющие входить на рабочую станцию через OAuth? Мне подобное видится сомнительным, потому что OAuth нужен браузер, а современные браузеры сильно полагаются на то, что они уже работают в контексте какого-то системного пользователя.
Для OAuth браузер не обязателен (не смотря на то, что там применяется HTTP протокол). И не надо смешивать его с входом на рабочую станцию - всё-таки речь идёт об авторизации прикладных программ, а не ОС. И да - после входа на рабочую станцию условно ещё один раз авторизоваться уже через OAuth придётся - зато работает на всех платформах, без плясок с бубном округ притаскивания за уши поддержки AD - и это особенно актуально для тех, кто сворачивает применение инфраструктуры Microsoft Windows
А ведь есть ещё авторизация на основе токенов, как аппаратные, так и программные (к примеру: JSON Web Tokens) - ещё более современный подход чем OAuth
Браузер там именно что обязателен, ведь на одном из этапов поставщик выдаёт токен на основе своих кук, которые были установлены во время интерактивного входа через веб-интерфейс.
И не надо смешивать его с входом на рабочую станцию — всё-таки речь идёт об авторизации прикладных программ, а не ОС.
Так в том-то и дело, что цель — смешать авторизацию прикладных программ и ОС. Чтобы у пользователей не было никаких отдельных паролей для разных применений.
и это особенно актуально для тех, кто сворачивает применение инфраструктуры Microsoft Windows
Kerberos работает и на чистом линуксе, в том числе в браузерах. Зачем заменять работающую технологию не полностью работающей?
условно ещё один раз авторизоваться уже через OAuth придётся - зато работает на всех платформах
Вам ведь уже отвечали, что два базовых механизма аутентификации в AD - это LDAP и Kerberos, а они работают на всех платформах, плюс аутентифицироваться в AD можно и через OAuth (см. ADFS). Суть вопроса в том, что один фиг при внедрении в энтерпрайз придется не с нуля работать, а взаимодействовать с имеющимися инфраструктурными сервисами, будь то AD или аналоги, ее заменяющие.
Текст интересный, но остаётся послевкусие:
с одной стороны: куда вы денетесь (см. выше);
с другой стороны: появляется логичное предложение: энтерпрайз, тебе нужно 300 правил? вот и делай их сам! хоть 400!
с третьей стороны: если это проект внешней команды, то там обычно до появления ИБ выдаются другие две буквы: ТЗ. И если в тз написано про 300 правил - тогда ок. ну а если не написано ...
ещё есть вариант, что некая контора сделала некоторую систему вообще без ТЗ и после реализации пытается её продать уже готовую систему (которую трудно менять) сторонней компании. Странноватый бизнес, наверное.
Это к тому, для человека вне темы появление такой ситуации (мы сначала сделали, потом узнали про требования) выглядит алогичным. Может привести более подробный пример?
Также , иногда бывают сборник требований (у нас такой есть и называется "базис"). И там большинство требований расписано.
Про Active Directory вообще интересно. Например, у нас явное требование ухода от винды и майков. Совсем. Или AD без примесей microsoft тоже отлично работает?
Active Directory — это LDAP + Kerberos + DNS + SMB + групповые политики
Первые три компонента прекрасно работают без "без примесей microsoft". Да и четвёртый можно использовать.
с другой стороны: появляется логичное предложение: энтерпрайз, тебе нужно 300 правил? вот и делай их сам! хоть 400!
Хм, если продавец своим клиентам будет так говороить, то что же он будет кушать-то? Клиенты часто сами люди подневольные, с внешними регуляторами и должны подчиняться их правилам. Банки, например такие.
ещё есть вариант, что некая контора сделала некоторую систему вообще без ТЗ и после реализации пытается её продать уже готовую систему (которую трудно менять) сторонней компании. Странноватый бизнес, наверное.
В b2b бывает сначала делают кому-то на заказ, и даже по ТЗ, а потом, когда заказ завершен, оформляют как отдельный продукт и пытаются продать другим клиентам. Или сначала делают для себя, получается хорошо, появляется понимание, что и другим может приносить пользу, оформляют отдельным продуктом и пытаются продавать.
Странноватый бизнес, наверное.
Подсказка - этот странный бизнес называется "коробочный софт". :)
то там обычно до появления ИБ выдаются другие две буквы: ТЗ.
Это если сначала полгода описывают требования, а потом еще три пытаются внедрить. И то в таком случае ТЗ появляется не до ИБ, а пишется совместно с. А если сначала делают MVP, а потом допиливают (agile и всё такое), то на разных стадиях могут сильно разные требования к ИБ возникать.
Ну статья же не про коробочный софт, да?
Коробочный софт это: хочешь - покупай, не хочешь - есть ещё +100500 кому это можно продать. Не устраивает ИБ? Просто вы не наш клиент. Всё равно хотите ИБ? - Вот есть конторы (или мы за +денежку), которые эту ИБу сделают вам. Может быть.
По поводу связи ИБ и Agile тут уместо будет вспомнить анекдот: вы либо крестик снимите, либо трусы наденьте. ИБ она явно предполагает, что разработка идёт по заранее выставленном требованиям, которые применяются на всех модулях / коде. Agile + MVP - это попытка разработку качественного продукта превратить в дешёвую поделку по принципу "делаем то, что нужно прямо сейчас". (Пожалуйста, без холиваров! Смотрим сюда: https://ru.wikipedia.org/wiki/Гибкая_методология_разработки. И вчитываемся в цитаты: "... не обращая внимания на правильность кода ...", "... приводит к снижению качества продукта и накоплению дефектов ..."). Поэтому у вас либо ИБ и ТЗ, либо Agile и MVP (ещё есть путь "либо ишак либо падишах", но он может привести к потере денег).
хочешь - покупай, не хочешь - есть ещё +100500 кому это можно продать. Не устраивает ИБ? Просто вы не наш клиент.
Приходит Газпром такой, а ему в ответ, морща носик - "Вы просто не наш клиент! И заберите свои гроши." В реальности все выглядит иначе - начинается торг, можно ли дополнительно реализовать нужные фичи, и если да, то почем. И вот собственно о части этого торга автор и пишет. Те же продукты 1С - это, формально, именно что "коробка" (и куча людей покупает именно как голую коробку), а для крупных внедрений приходится не тупо ставить, а внедрять и допиливать.
ИБ она явно предполагает, что разработка идёт по заранее выставленном требованиям, которые применяются на всех модулях / коде.
Элементарный контрпример - изначально предполагалась работа софта в закрытом контуре, а потом бизнес-заказчик просит допилить фичи, требующие интернета. Надо ли объяснять сразу возникшую разницу в требованиях со стороны ИБ? И вот это прямо из реальной практики.
Пожалуйста, без холиваров!
Так и не начинайте холиварить сами. У подхода "всё сразу описываем в ТЗ, а потом долго и упорно все скопом внедряем" более чем достаточно рисков, вплоть до полного провала и потери всей уймы вбуханных денег. Agile не на пустом месте появился.
ИМХО - любой серьёзный продукт должен иметь несколько редакций, я идеальным считаю такой набор (от простого к более сложному):
0. Free (или Express) - Если хочется чего-то условно бесплатного в своей линейке - безопасность тут заведомо должна быть упрощённой
Base (или Express, или Start) - Самая простая конфигурация и самая дешёвая - скорее годится как бессрочная демоверсия в отсутствии Free или как база для интеграции других сервисов, или самостоятельной надстройки (в т.ч. за счёт дополнительно приобретаемых расширений/модулей) - тут особо сильно с безопасностью тоже нет смысла заморачиваться
Standart - Конфигурация ПО с минимальными не функциональными ограничениями, но достаточным набором функциональных (именно по ключевой части) возможностей, условно для большинства клиентов потенциальных клиентов. Но без каких-то узкгоспециализированных сервисов, и повышенного комфорта и скорости работы. С условно минимальным уровнем необходимой безопастности и комфорта обслуживания
Professional - Продвинутая конфигурация - вот тут уже надо не только внедоять особые специализированные фишки, чтобы охватить по ключевому функционалу уже практически все потребности (в рамках главной концепции ПО), но фишки по автоматизации и всевозможных фишек по безопасности.
Corporate - Вот эта уже конфигурация для "больших бонз" - тут надо очень глубоко сосредоточится именно на потребностях корпоративного сегмента - и именно тут стоит прогибаться под их всевозможные хотелки. Ну и выкатывать соответствующий оверпрайс за них - клиент должен быть готов платить за свои капризы (именно за капризы - всё более-менее разумное (т.е. по сути то что приведено и в данной статье) уж должно быть включено в редакцию Professional! Поэтому, для остальных будет достаточно - Professional
Enterprise (или ERP) - Почти высший уровень - тут уже не до шуток и очень мало даже очень серьёзных разработчиков смогут выпустить продукт в данной редакции - это должна быть квинтэссенция производительности безопасности и удобства (читай гибкости подстройки и простоты использования)! Если у заказчика возникают серьёзные вопросы по доработке - значит продукт ещё не дорос до этого уровня! Само собой на таком уровне все доработки должны выполняться практически беспрекословно (кроме случаев явного нарушения целостности системы, особенно её безопасности) без доп. оплаты - тут уже всё должно быть включено в немалый изначальный оверпрайс - это решение не для всех - а только для избранных ценителей - и да - его разработка врят ли когда-либо окупится - это скорее репутационное-маркетинговый продукт - выставочный образец - типа - смотрите как мы можем - мы очень серьёзный разработчик! Но и на такой продукт всегда найдётся свой клиент-кошелёк! Но выверенность продукта должна быть идеальной - тут любые проблемы - это сразу серьёзный негатив на репутации. И компания должна 1001 раз подумать - а "стоит ли овчинка выделки", прежде чем выходить на такой уровень.
Ultimate (или Absolute или ещё как) - Максимально топовая и премиальная элитная разработка - ту должно быть уже всё и 100% идеально - интересно хоть кто-то из людей когда0нибудь сможет выкатить продукт такого уровня?
Исходя из данной классификации вести разработку ПО лучше снизу вверх - постепенно наращивая уровень функционала и качества, но оставляя предыдущие редакции для более простых случаев использования. И, соответственно, раз замахиваетесь на корпоративный уровень - то и готовьте соответствующую редакцию ПО абсолютно целенаправленно! Ну или, говорите, что подводного уровня развития ПО у Вас ещё нет - и отдавайте клиента на откуп конкурентам - если они, конечно есть, а уже клиент пусть сам оценивает свои финансовые возможности функциональные преимущества. Но всегда стоит (кроме уровня выше Corporate ) говорить, что более функциональная редакция ПО у вас стоит в планах на разработку (или уже ведётся разработка) и предлагать заказчику купить что есть, а затем профинансировать (или просто ожидать) разработку того, что ему требуется на следующем этапе!
А пытаться в сжатые сроки из Standart сделать что-то похожее на Corporate по прайсу да хоть Professional - явно не стоит!
Керберос, AD... это норм, что ИБ требует именно их для аутентификации? Ну, такое..
Oauth2, OID connect не вариант?
PS статья прямо мастхев для команд планирующих 'запилить кровавый энтерпрайз' %)
Да, норм. При нормальной организации процессов в LDAP находится актуальная оргструктура с информацией о каждом сотруднике, не использовать эту информацию означает создание лишних возможностей забыть отозвать у кого-то права на пустом месте.
OID connect вполне вариант, он "подключается" к AD через AD FS (Active Directory Federation Services)
Я конкретно про Керберос и конкретно про AD, а не про LDAP в общем.
Имхо, если сейчас ИБ выдвигает такие требки возникают сомнения или в их компетентности, или в общем инфраструктурном ландшафте компании.
А где в посте было упоминание требования именно Kerberos и именно для веб-приложений?
AD, Kerberos упоминался в комментариях выше.
OAuth2, OIDC не только для веб-приложений подходят. Это частный случай. Например https://habr.com/ru/articles/658973/
RFC про любые сервисы, а не только веб-приложения.
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
Я к тому, что требовать Microsoft AD или Kerberos - плохой вариант, если это не общекорпоративный легаси и есть выбор, то требования стоит пересмотреть.
Я к тому, что требовать Microsoft AD или Kerberos — плохой вариант, если это не общекорпоративный легаси и есть выбор, то требования стоит пересмотреть.
Не уверен что активно используемая инфраструктура корпоративной сети может называться словом "легаси". Но даже если и так, то куда вы предлагаете "пересматривать" вход на рабочую станцию под корпоративной учёткой?
И ещё раз напоминаю, AD FS — это такая же часть AD.
RFC про любые сервисы, а не только веб-приложения.
Вам всё равно нужен браузер чтобы получить токен, что резко сокращает количество возможных "не только веб-приложений".
Вам всё равно нужен браузер чтобы получить токен, что резко сокращает количество возможных "не только веб-приложений".
это глубокое заблуждение. Посмотрите 4 раздел https://www.rfc-editor.org/rfc/rfc6749#section-4 ну или статью на хабре, как вариант (ссылку выше давал).
User-agent требуется далеко не во всех вариантах flow. OAuth2, OID не накладывают таких ограничений (наличие браузера в частности или user-agent в общем).
Пожалуйста разберитесь в теме прежде чем минусовать :)
Kerberos другим словом, кроме как легаси назвать затрудняюсь. Ибо это неповоротливый, сложный во всех аспектах зверь, которому уже 30 лет в обед. Современные подходы проще, дешевле и обладают не меньшей защитой.
AD - продукт Микрософт. Покажите мне российскую компанию, которая топит за продолжение использования продуктов Microsoft. Отключение 365 офиса ничему не научило что ли?
Ну да, ну да, конечно же User-agent необязателен. Только давайте посмотрим на эти самые способы работы без него:
4.3. Resource Owner Password Credentials Grant — клиент передаёт логин с паролем на сервер авторизации самостоятельно.
Мало того, что это небезопасно, так ещё и неудобно.
4.4. Client Credentials Grant
Авторизации пользователя вообще нет.
4.5. Extension Grants
"Придумайте что-нибудь своё". Ну да, ну да, хороший способ...
Напомню, что нормально настроенный kerberos работает в режиме single sign-on: пользователь вводит пароль 1 раз, если это корпоративный компьютер — то при входе в систему.
А вы, предлагая перейти на OAuth2 в безбраузерном варианте, фактически предлагаете либо вводить его в каждом используемом приложении, либо изобретать костыли и велосипеды. Ради чего? Просто потому что OAuth2 современнее?
Kerberos другим словом, кроме как легаси назвать затрудняюсь. Ибо это неповоротливый, сложный во всех аспектах зверь, которому уже 30 лет в обед. Современные подходы проще, дешевле и обладают не меньшей защитой.
Приведите уже ту самую современную технологию, которая позволяет SSO в корпоративной сети, включая рабочие станции и сервера.
Прекрасная статья, все так, а иначе - никак.
Из пожеланий ИБ кровавого интерпрайза еще добавить: не только наличие нормальных журналов аудита, но еще и функция защиты самих этих журналов от модификации. Актуально для учетных финансовых систем, требование по нефальсифицируемости журналов аудита.
Что бы не связываться с IDM. то лучше каталог пользователей приложения и роли безопасности завязывать на корпоративный каталог (AD: пользователи+группы AD замапленные на группы приложения). Тогда весь головняк с правами доступа порешается в самом интерпрайзе самостоятельно.
Как правильно сделать подписание соглашения с пользователем с помощью простой электронной подписи ПЭП? Ведь явно не достаточно сгенерировать случайное число из 4-5 цифр и отправить его пользователю через пуш или смс, а затем сравнить ввод пользователя с загаданным числом? Как потом проверить подпись и как доказать ее наличие и корректность?
код генерируется на основании криптопреобразования данных подписываемого документа, времени, ИД-пользователя и некого уникального ключа пользователя (пусть даже он хранится внутри организации).
Клиент получает код, вводит его как подпись операции\документа, запрос с кодом и реквизитами документа(повторно) уходит на сервер, на сервере осуществляется повторное криптопреобразование над документом и еще раз вычисленный код сравнивается с присланным кодом. Если коды совпали, значит проверка ЭЦП прошла успешно.
Соответственно позже можно провести проверку документа и присланной ЭЦП, если воникает спорная ситуация.
Немного мутная история. С одной стороны, «ваш продукт хочет купить», с другой - сферические «300 требований» в вакууме. Если вы хотите продать свой продукт, то при его разработке наверняка закладывали возможные пожелания потенциальных клиентов по производительности, безопасности и интеграции, интересовались, какие преимущества есть у конкурентов, и лучше клиентов знаете, какие из сотен требований безопасности релевантны для вашего продукта, от чего они защищают и как снижать риски от актуальных угроз… Т.е. либо каждый раз писать под архитектуру заказчика, учитывая его ландшафт, тех.стеки, протоколы и требования безопасности, которые ставятся до начала разработки и именно они и проверяются при приемке в эксплуатацию; либо вы заранее поддерживаете наиболее распространенные требования, и тогда сможете продавать бОльшему числу клиентов…
300 требований ИБ, или почему энтерпрайз [не] купит ваш продукт