Михаил Польгун, Positive Technologies — Разработка и применение систем разграничения доступа

Итак, коллеги, продолжаем развивать утреннюю историю.

Утром вам звонил проектный менеджер, который просил быстро сделать фичу, и тезка нашего текущего оратора Михаил Утром рассказал, как это сделать, как переложить в соответственность команду эксплуатации.

Но сейчас вам звонит тот же самый проектный менеджер и говорит, что на самом-то деле для некоторых лиц, которые пользовались вашим интерфейсом, нужно было сделать чуть-чуть по-другому.

Или где-то их ограничить.

Удивительным образом у нас сегодня подобрались доклады.

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

Но тем не менее Михаил, представитель партнера нашего, будет нам рассказывать, каким образом к силе и свободе добавить ограничения.

Очень тонкие.

Михаил, спасибо вам за слово.

Спасибо.

Привет!

Тема моего доклада «Разработка и применение системы разграничения доступа на базе атрибутов».

Меня зовут Михаил, разработкой на .NET я занимаюсь последние 15 лет, а из них 8 лет я разрабатываю систему информационной безопасности.

Занимался этим в разных ролях, приходил в компанию разработчиком, был тем лидом, сейчас я руковожу бэкэнд-разработкой на метапродуктах в новом направлении компании.

У меня три команды, общей численностью больше 20 человек.

На слайдике мои контакты, если какие-то вопросы будут, не стесняйтесь, пишите, задавайте.

Работаю я в компании Positive Technologies.

Мы обеспечиваем практическую кибербезопасность.

Мы уже больше 20 лет на рынке информационной безопасности.

Тут написано 1800+, реально у нас уже 2000 с хвостиком.

Это специалисты по безопасности, разработчики и другие очень умные ребята.

Компания как проводит аудиты безопасности, так и разрабатывает собственные системы и решения.

Сегодня я расскажу, зачем нам вообще понадобилось разграничение доступа на базе атрибутов.

Его еще называют ABAC.

Расскажу немного теории вообще, как строится разграничение доступа.

И в конце расскажу, что мы сделали у себя.

Началась эта история на рубеже 19-20-х годов.

В то время я работал на проекте MaxPatrol 10.

Основная задача продукта MaxPatrol 10 – это мониторинг и аудит безопасности больших корпоративных сетей.

Работает он по двум направлениям.

Он может провести инвентаризацию, собрать данные с узлов в сети и дальше на них

провести разный анализ, например, на анализ уязвимости.

Второе, он может собирать события информационной безопасности и по ним тоже проводить анализ на поиск угроз.

Все это поставлялось в виде он-прем решения конкретным заказчикам прямо в периметр.

Построено это было на микросервисной архитектуре.

У нас было порядка 40 микросервисов single instance.

И что характерно для продуктов информационной безопасности, у нас было просто уйма экспертного контента.

Базовые уязвимости, правила обработки событий, правила сбора данных с хостов.

И в 2019 году мы выпускались в одной единственной редакции.

Редакция работы с событиями.

CM Information and Event Management.

System Information and Event Management.

Сокращенно CM.

Здесь представлена принципиальная схема, как выглядит продукт.

Тут не все 40 микросервисов, я выделил только такие базовые большие блоки.

Красным представлены инфраструктурные сервисы, сервис идентификации и авторизации, health monitoring, сервис лицензирования, постгрейской для хранения данных.

Шина RabbitMQ для общения сервисов.

Сервисы для работы с событиями информационной безопасности.

У них собственный сторидж и фронтенд для получения работы с этими событиями.

Сервисы для работы с уязвимостями, для анализа уязвимостями.

Дополнительные сервисы для работы с инцидентами и сервисы сбора данных и управления сборами данных, чтобы уметь собирать сервисы с хостов.

Всем этим разнообразием пользователь мог управлять через WebUI.

И в 2020 году перед нами стала новая задача.

Мы захотели выпускать новую редакцию того же самого продукта, а именно редакцию для работы с уязвимостями, vulnerability management.

И перед нами стала задача, как сделать так, чтобы, имея один продукт на одной кодовой базе, на одной бинарной созданной базе,

на одной бинарной собранной базе, наши специалисты могли прийти и поставить его заказчику, но при этом он мог работать только с тем функционалом, который он приобрел, который ему реально нужен.

То есть в зависимости от того, какую редакцию он приобретает, у него часть экспертизы доступна или нет, и часть функционала доступна или нет.

Если ему в будущем что-то понадобится, он мог просто докупить лицензию и все из коробки бы вжух и заработало.

При этом тип редакции влияет и на те действия, которые пользователь может выполнять в системе.

Давайте посмотрим на примере.

Допустим, заказчик покупает себе редакцию для работы с уязвимостями.

В данной редакции у него не должны быть доступные сервисы для работы с событиями информационной безопасности.

Они на слайде серенькие, зачеркнутые.

Они просто не должны быть ему доступны.

Кроме этого, сервис сбора данных должен понимать, что в этой лицензии он не должен собирать события.

Он должен уметь собрать что-то с хостов, но события собирать не должен.

Если же пользователь приобретает себе лицензию, продукт для работы с событиями, то все сервисы у него должны быть доступны.

Мы должны дать ему возможность собрать события, их обработать.

Но работа с уязвимостями у него должна быть ограничена.

И мы подумали, что функция экспертиза зависит от редакции и прав пользователя.

И нам поможет в этом разграничение доступа.

Давайте посмотрим немножко теории, для чего вообще разграничение доступа используется.

Допустим, у нас есть какой-то маленький бизнес, есть Ваня, которого нагрузили тремя функциями.

Финансы, бухгалтерия и IT.

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

В таком режиме они, в принципе, могут работать, ничего там разграничивать им не нужно.

Они могут друг с другом договориться, кто чем занимается, и работать.

При этом...

Есть проблема, что мы не можем никак гарантировать, что кто-то из этих ребят не залезет в чужую область, что-то не поменяет, случайно или специально не внесет какие-то изменения в бухгалтерскую отчетность.

Именно для этого и нужно разграничивать доступ.

Наверное, на текущий момент самым популярным и используемым подходом является ролевая модель – role-based access control.

В данной модели в системе заводятся роли, повторяющие бизнес-функции в компании, и уже в роли привязываются люди.

Так у нас появилось три роли – финансисты, бухгалтера и администраторы.

Мы явно указали, что Таня входит в две роли, и она может заниматься финансовыми операциями и, например, выпускать бухгалтерские отчеты.

Петя у нас только бухгалтер, может только бухгалтерией заниматься.

А Ваня теперь счастливый человек, он занимается только IT, и про финансовую бухгалтерию ему и думать не нужно, и доступа туда нет.

Ролевая модель простая, понятная, но не лишена недостатков.

В больших компаниях со временем растет количество атрибутов, по которым нужно ограничивать доступ.

И это очень сложно решить, кроме как введением новых ролей.

Предположим, что наш бизнес вырос настолько, что теперь у нас три офиса в Москве, в Санкт-Петербурге и в Новосибирске.

И мы хотим ограничивать доступ теперь не только по бизнес-функции, но и по офису.

Для этого нам нужно завести количество ролей как декартового произведения бизнес-функции на города.

Если мы вдруг захотим по какому-то третьему измерению ограничивать доступ, то нам придется сделать декартовое произведение трех атрибутов.

Неудобно.

Кроме этого, ролевая модель позволяет ограничивать доступ только по функциям, которые выполняет пользователь.

Но крайне сложно ограничить доступ к данным, которые пользователь реально работает.

Например, у нас есть простое бизнес-правило.

Бухгалтер может выпускать квартальный отчет по своему офису в рабочее время.

Мы боремся с переработкой бухгалтеров, чтобы они не уставали.

Вот по своему офису мы побороли через композитные группы, а в рабочее время непонятно, сложно как сделать.

Можно, например, какую-нибудь крон-жабу запустить, которая в начале рабочего дня будет добавлять бухгалтера в роль, в конце рабочего дня удалять.

Но выглядит странно.

И для решения таких задач есть другая модель, которая называется Attribute-Based Access Control, ABAC.

В ней разграничение строится не на базе бизнес-функций, а на базе атрибутов объектов, которые участвуют в доступе.

На базе атрибутов субъекта, который хочет получить доступ.

На базе атрибутов ресурса, действия и окружающей среды.

Город, страна, время.

То же самое правило про бухгалтера мы можем выразить в атрибутной модели тремя условиями.

У субъекта должен быть атрибут «должность», и он равен бухгалтеру.

У ресурса должен быть атрибут «тип».

Это отчет.

У среды должен быть атрибут «время», текущее время.

И он должен входить в диапазон рабочих часов субъекта.

Это тоже атрибут субъекта.

Плюс Абака в том, что он разграничивает доступ именно к данным, позволяет более гранулярно по данным этот доступ разграничивать.

При этом при появлении новых атрибутов не нужно менять уже написанные правила.

То есть все, что уже написано, оно будет работать, даже если завелись новые атрибуты.

На текущий момент ABAC стандартизован стандартом XACML.

Разрабатывается он с 2003 года организацией OASIS.

На текущий момент самая актуальная версия — это третья.

Ей уже 10 лет.

И как можно понять из названия, все, что начинается на X, основано на XML.

Стандарт описывает сущности для проверки доступа и компоненты, обеспечивающие эту проверку.

Если выделить самое основное из описания всех сущностей, а их там довольно много, то...

Доступ описывается правилами.

Несколько правил объединяются в политике.

Несколько политик могут быть объединены в группы политик.

Из чего состоит правило?

Правило состоит из таргета, некого логического выражения, которое может состоять только из атрибутов и констант.

И кондишена, логического выражения, которое уже вычисляется динамически.

В нем можно атрибуты сравнивать друг с другом.

Смысл разделения выражения на два...

На две проверки в том, чтобы как можно быстрее уметь отсечь неподходящие правила и политики на основании того контекста, который есть.

Эффект.

Результат вычисления правила.

Описано четыре эффекта.

Permit – правило разрешающее.

Deny – правило запрещающее.

Они возвращаются явно, и правило вернет permit или deny только в том случае, если и target, и condition истинные.

Если target, target или condition ложные, будет возвращено not applicable.

Правило будет считаться неприменимым.

Если же во время проверки правила произошло какое-то исключение, какая-то ошибка, то должен возвращаться indeterminate.

У правила могут быть облигейшены и адвайсы.

Облигейшены – это те действия, которые необходимо выполнить, если правило прошло.

Например, в случае выпуска квартального отчета облигейшеном может быть запись в security log о том, что отчет выпустился.

Адвайсы – это действия, которые рекомендовано выполнить, но не обязательно.

Таким примером может быть оповестить главбуха в телегу о том, что отчет выпускается.

Как я уже говорил, правила собираются в политике.

У политики есть свои таргеты.

Чтобы быстрее отсеивать, у него могут быть свои obligations, свои advice.

И есть алгоритм комбинации результатов проверки правил.

Смысл в том, что результатом проверки политики должно быть конкретное значение.

И мы должны понять, как несколько результатов от нескольких правил скомпоновать в один ответ.

Есть несколько вариантов.

Давайте на примере посмотрим.

First applicable –

Это первый применимый, первый permit или deny.

Если первое по проверке правила возвращает permit или deny, то будет, соответственно, возвращен permit или deny.

Если ни одно из правил не вернет, будет not applicable.

Deny unless permit.

Запрещено, если не разрешено.

Если хотя бы одно из правил возвращает permit, будет permit.

В противном случае будет deny.

Permit unless deny.

Наоборот, разрешено, если явно не запрещено.

Если хотя бы одно из правил вернет deny, будет deny.

В противном случае permit.

Также стандарт описывает набор компонентов для обеспечения проверки доступа.

Таких компонентов четыре.

Policy administration point.

Его задача — это создавать политики доступа и управлять ими.

Он должен знать формат описания политик, чтобы уметь их правильно интерпретировать.

И также он предоставляет интерфейс для получения этих политик.

Policy information point — это источник значения атрибутов.

К нему можно обратиться, чтобы получить текущее значение атрибутов, которые нам интересны.

Policy Decision Point – это ядро всей нашей проверки.

Его задача – вычислять политики на основании текущего контекста.

При этом он ничего не знает ни про значение атрибутов, ни про сами политики.

Он просто оперирует теми атрибутами, которые есть.

Все это вычисляет.

Policy Enforcement Point – точка входа.

Его задача – сформировать контекст, вызвать Policy Decision Point и обработать ответ, который ему придет.

Это слайд-шпаргалка.

Все то же самое, что я только что рассказал, нам по ходу повествования понадобится чуть позже, чтобы вспомнить.

Тут можно прям запутаться, они все на одно лицо.

Давайте в динамике посмотрим, как вся эта штука работает.

Изначально администратор описывает какие-то политики, сохраняет их в Policy Administration Point и в какой-нибудь Policy Store.

Не суть важна.

Policy Decision Point получает эти политики.

Дальше клиент инициирует, например, выпуск отчета.

и передает запрос на проверку доступа в Policy Enforcement Point.

Передает туда какие-то атрибуты, например, идентификатор отчета и идентификатор пользователя.

Policy Enforcement Point собирает контекст, добавляет туда необходимые данные.

Если он добавил, например, действия, которые выполняются, и отправляет запрос на авторизацию в Policy Decision Point.

Policy Decision Point на основании переданных атрибутов

по таргетам, ищет подходящие политики, подходящие правила и начинает проверять их.

Достает оттуда атрибуты и понимает, что какие-то атрибуты он не знает, они ему еще нужны.

Формирует запрос Policy Information Point.

Policy Information Point, в свою очередь,

получает значение атрибутов ресурса, субъекта и окружающей среды и отдает их обратно в Policy Decision Point.

Здесь уже можно видеть, что он возвращает позицию нашего субъекта, что это бухгалтер, его рабочее время с 9 до 6 и текущее время 16.30.

Значит, отчет можно выполнить по нашему правилу.

Policy decision point все это проверил и говорит, прекрасно, permit, выпускайте отчет и выполните, пожалуйста, obligation.

Запишите в security log, что отчет выпускается.

И policy enforcement point должен выполнить obligation, отправив запрос в obligation service.

Плюсы.

Это отраслевой стандарт, он уже довольно зрелый, ему 20 лет, как мы видели, при этом есть уже несколько реализаций, как open-source, так и проприетарных.

То есть можно при желании, если очень хочется, взять и пользоваться.

Есть у него недостатки.

Все описывается на XML.

Все политики, все правила описываются на XML.

Я, честно, попытался для примера на слайде написать сам политику, потратил минут 15 на писание, устал и скопировал первую же политику, которая в стандарте была.

В целом, ну, такая история, все это самому руками писать.

Обычно для этого UI-чик делают, чтобы админ мог это натыкивать.

Стандарт определяет, как работать с конкретным ресурсом, как проверить доступ к конкретному ресурсу.

Если же нам нужно обеспечить фильтрацию по группе каких-то ресурсов, то такой возможности стандарт не описывает.

А она иногда нужна.

Сложно обеспечить целостность данных.

Смысл в том, что проверка доступа происходит на полисе decision point, а получение значения атрибутов происходит на каком-то внешнем полисе information point.

И даже если информацию об атрибутах представляет сервис, который является инициатором проверки, то нам сложно обеспечить целостность получения атрибутов и целостность тех объектов, операции над которыми проверяется.

Первую проблему попытались побороть специалисты из компании Axiomatics, выпустив свой язык описания политик Axiomatics Alpha, Abbreviated Language Authorization.

Это уже не XML, это полноценный DSL для описания политик, его уже можно читать и писать, и это я уже сам руками написал.

Здесь можно видеть, что у нас есть политика для отчетов, у нее есть свой таргет, который проверяет, что атрибут ресурс-тайп RyanReport,

Алгоритм комбинации результатов первоприменимый.

Есть одно правило – публикация отчета.

У него тоже свой таргет, что действия публикация, что это бухгалтер.

Правило разрешающее, возвращает пермит.

Есть дополнительный condition, который проверяет, что идентификатор пользователя и owner совпадает.

Уже стало значительно лучше, но не без недостатков.

Неявна параметризация получения атрибутов.

Вот атрибут Owner, который был указан, непонятно, откуда его получать.

То есть чтобы Policy Information Point знал, откуда получать значение Owner, как части нашего отчета, он должен, по сути, взять контекст, оттуда каким-то образом достать конкретный отчет, который нас интересует, понять, кто его владелец, достать эти атрибуты,

Это очень сильно сужает возможность переиспользования policy information points.

Второе.

Тип ресурса, к которому применима политика, описывается в таргете.

Как я уже говорил, таргет описывается просто набором атрибутов.

Это...

дает дополнительную сложность в том, чтобы разграничить политики по типам атрибутов.

У нас могут быть одни и те же атрибуты в разных объектах применяться.

Кроме этого, это усложняет индексацию правил и политик по типу ресурса.

Изучив всю эту теорию, мы решили взять ее за основу и по пути внесли доработки от всей задачи, которые нам нужны.

Напомню, перед нами стояла задача, имея такой продукт, научиться поставлять его заказчику в ограниченном режиме работы, чтобы в зависимости от того, какая лицензия у него есть, ему был бы доступен ограниченный функционал и ограниченный контент.

При этом все это уметь делать без переустановки, без раскатки продукта.

И мы подумали, что ABAC нам поможет в этом.

Мы сможем выделять редакции через политики доступа.

То есть мы опишем политики, которые точно опишут, какие сервисы должны быть доступны пользователю и какой экспертный контент он может использовать для своих задач.

И это дает нам возможность в будущем формировать новые редакции с минимальными изменениями кода.

По сути, нам что нужно сделать?

Как только мы захотим выпустить новую редакцию,

то мы просто напишем новые политики и новые сервисы, которые еще не умеют работать с этим, просто научим обращаться в сервис авторизации.

Что мы сделали?

Мы разработали свой сервис авторизации, назвали его ABAC Authorization, как богатая фантазия на нейминг.

Мы ввели явную схему атрибутов ресурса.

Она описывается в виде ямлика.

Здесь можно видеть, что у нас есть ресурс-отчет, у него...

К нему применимо два действия чтения и публикации.

У него есть два атрибута.

ID типа UID и Owner типа String.

Дальше мы сделали свой диалект языка Alpha.

Назвали его Positive Alpha или P-Alpha.

Сверху представлена та же самая знакомая политика на Axiomatics Alpha.

Снизу та же самая политика, переписанная на P-Alpha.

В чем отличие?

Первое, мы явно ввели фильтрацию политики по типу ресурса.

Это нам позволяет как раз-таки убрать неоднозначность в определении, к какому ресурсу применять какую политику.

Во-вторых, это дает нам возможность индексировать эти политики.

Второе, мы явно указали, как получить значение атрибута owner, как части нашего отчета.

Префикс report квадратной скобочки называется группой атрибута.

И значение его результатом можно представить как некий объект, который содержит два поля id и owner.

Соответственно, когда мы обращаемся и указываем фильтрацию, то он, по сути, возвращает этот объект.

К нему подставляются те атрибуты, которые мы указали.

Собачка ID – это зарезервированный атрибут, который в себе содержит идентификатор текущего ресурса, к которому мы проверяем доступ.

Если мы указываем несколько атрибутов, как во втором примере, то они проверяются по И. То есть здесь одна и та же проверка.

Мы проверяем, что владелец текущего отчета совпадает с идентификатором пользователя.

В первом случае мы получили отчет по идентификатору и проверили его атрибут на равенство.

Во втором случае мы просто взяли все отчеты, у которых такой идентификатор и такой владелец, и функцией они проверили, что есть хотя бы один.

Кроме этого, мы внесли доработки в схему взаимодействия к SACMU.

Наши микросервисы могут зарегистрировать в Policy Enforcement Point локальные Policy Information Points.

И мы добавили новый результат проверки, Deferred, отложенная проверка.

Давайте коротко вспомним, какие компоненты у нас были.

Policy administration point создает и администрирует политики.

Интерфейс получения политик.

Information point дает значение атрибутов.

Decision point – это ядро нашей проверки, вычисляет политики.

Enforcement point – точка входа, вызывает decision point и обрабатывает ответ.

Как мы это сделали у себя?

Как я уже говорил, у нас появился сервис авторизации, который в себе инкапсулирует три компоненты.

Он в себе инкапсулирует administration point, в нем в виде файликов подкладываются политики, в виде альфа-файлов и схемы ресурсов.

Они подкладываются в продукт во время сборки.

В последних версиях появилась возможность задавать это все через API.

Он реализует в себе частично information point, он может сходить в сервис лицензии, запросить данные по атрибутам, связанным с лицензией, чтобы проверить, какая лицензия есть.

Сам сервис лицензии ничего про это не знает, он только отдает данные лицензии.

Ну и policy decision point – это прям корневая задача нашего сервиса авторизации – проверка политик.

Микросервис, в свою очередь, может у себя зарегистрировать Policy Enforcement Point, подключив Nuget пакет, и при необходимости добавить в него регистрацию локального Policy Information Point.

Он может получать данные об атрибутах откуда угодно, например, может в качестве источника использовать локальную базу микросервисов.

Как это все работает?

Допустим, у нас инициируется тот же самый выпуск отчета, он приходит в микросервис на выпуск.

Перед тем, как выпустить отчет, формируется запрос в Policy Enforcement Point, он прямо внутри микросервиса.

Policy Enforcement Point собирает контекст и отправляет запрос в сервис авторизации.

Здесь уже собран тот контекст, который у него есть.

Тип ресурса, действия, идентификаторы пользователей, все прочее.

Сервис авторизации бегает по своим политикам и на основании типа ресурса находит, какие политики применимы к нему.

Берет эти политики, из них достает правила, начинает проверять их кондишены.

Если понимает, что каких-то атрибутов ему недостаточно, он может сформировать запрос сервис-лицензии, если нужны атрибуты для проверки лицензии, и получить их обратно.

Дальше он проводит дальнейшую проверку.

Например, смотрит, что части атрибутов у него нет.

Но то, что он проверил, оно разрешает выполнение политики.

В данном случае он возвращает...

Результат deferred, отложенную проверку.

То есть он говорит, я у себя все проверил, вроде ок, но да проверь то, что я не смог.

И часть фильтра, которую необходимо проверить на локальном information point.

Сервис получил этот ответ, берет эту часть фильтра, из нее формирует запрос в базу данных.

преобразует этот, например, в SQL-запрос какой-нибудь Postgres, достает значение атрибутов, допроверяет то, что он не проверил, и выдает свой вердикт из разряда «доступ разрешен, выпускай отчет».

Если доступ запрещен, он выбросит исключение о том, что доступ запрещен.

Эта схема как раз позволяет нам решить проблему с проверкой целостности данных.

То есть мы можем, например, организовать транзакцию в момент, когда мы запрашиваем значение атрибутов и изменяем какие-то объекты, по которым у нас доступ разрешен.

Итоги.

Нам получилось сделать расширяемый механизм управления редакциями.

продукт MaxPatrol Vulnerability Management, а в этом году у нас вышел третий продукт в линейке продуктов MaxPatrol 10, называется Host Compliance Control, и в нем тоже активно используется этот функционал.

К факту там реально просто были дописаны новые политики, которые позволили разграничивать продукт.

И этот механизм учитывает разрешение пользователей.

Как вся эта история работает?

В уже знакомой схеме появился сервис авторизации.

Теперь сервисы, когда поднимаются при запуске, они могут пойти в сервис авторизации, проверить, разрешено им работать или не разрешено.

Если по какой-то причине, например, не та лицензия, они работать не должны, они могут просто остановиться или погасить свои endpoint, сделать вид, что мы не работаем.

Другие же сервисы, которые должны работать ограниченно, они при выполнении определенной функции идут в сервис авторизации, как я уже рассказал, и получают разрешение на выполнение конкретной операции.

Или же могут организовать фильтрацию данных на основании тех политик, которые у них есть.

Так, в данном случае сервисы работы с событиями, они посмотрели и поняли, что в этой лицензии они работать не могут.

В другой лицензии сервис работает с уязвимостями.

Понял, что он должен работать ограниченно.

На этом у меня по докладу все.

Спасибо большое, что послушали.

Коллеги, предлагаю забыть, что у нас ко всему этому ротовый доступ, представить, что нас это тоже касается и позадавать докладчику вопросы.

Лес рук.

Здравствуйте.

Вот такой вот вопрос все-таки возник.

Я, насколько понимаю, вы в данном случае это вот все разворачиваете на один конкретный продукт?

Да.

То есть если к вам пришли и сказали, мы делаем новый продукт, вы его создали и снова вот это все накатили на него?

На момент времени, про который я рассказывал, именно так надо было делать.

Сейчас мы меняем подходы и в целом продукты смогут зарегистрировать себя в сервере авторизации, принеся свои политики.

схемы и уже смогут работать.

Вот вопрос как раз про это.

Это и было интересно с условием того, что вы подходили.

То есть, наверное, уже какие-то новые инструменты именно для групповой политики, они существуют или нет?

Ну,

Как я уже пытался объяснить, у нас довольно ограниченный контекст, то есть нас не сколько интересовало ограничить доступ пользователя, сколько совместить ограничение доступа с теми функциями, которые он может выполнять с точки зрения контента.

Поэтому таких решений на рынке у нас не было, нам пришлось делать самим.

Понятно, то есть была задача, вы под нее как бы подстроились.

Когда будет больше, тогда будем искать новое решение.

Да, и в целом нас оно очень удовлетворяет.

Я понял, спасибо.

Спасибо.

Здравствуйте, спасибо за доклад.

А вот вы интегрировались только работой с базой, например, про автодентификацию, или, допустим, с какими-то более системными штуками, типа домена, еще что-то?

То есть вы пользователя берете откуда, собственно?

Пользователь у нас берется из... Давайте сейчас пролистну.

То есть у нас... А, тут уже не видно.

Видно.

Левый нижний угол есть Identity and Access Management Service.

По факту это наше ССО.

В нем есть данные о пользователе и весь контекст о пользователе хранится там.

Он может брать данные из LDAP, откуда угодно.

Сервис авторизации напрямую, про который я рассказывал, а бак авторизации, он напрямую с ним не работает.

Он из него получает, все данные к нему берутся из ААМа, уже конкретным сервисом-инициатором, и подставляются в виде значения атрибутов в контекст.

То есть они развязаны между собой.

А это не создает распределение задач авторизационного менеджера между…

ABAC authorization и, собственно, клиентам, которые должны сам лезть.

Они немного разные задачи решают.

Задача IAM это идентифицировать пользователя и ограничивать его доступ именно по входу.

А задача ABAC это ограничить исходя из того функционала, который он выполняет.

То есть, наверное, дает, но так как мы его используем, нас это не сильно заботит.

Спасибо.

Спасибо.

Спасибо за доклад, я, может, прослушал, а было что-нибудь сказано про raw level security, то есть, ну, типа, каждый менеджер может посматривать только своих клиентов, ну, то есть, фильтруем по значениям created by, там, менеджер ID, там, то есть, именно связь прав и данных.

Ну, если я правильно понял вопрос, то, кажется, Абак, он, в принципе, про это и есть, то есть, он, давайте сейчас пролистнем.

Ставлю, ставлю, ставлю.

Какой-нибудь пример.

А, ну вот, например, наше бизнес-правило.

И здесь же можно как раз и выписать и права, и любой атрибут, который нас интересен.

Рабочие часы и роль у нас заранее известны.

А вот пока мы не получили данные, не совместили с текущей ролью,

Это можно сделать за счет information point.

То есть это он должен знать, что откуда взять и как совместить.

Все, что мы не знаем, мы можем запросить в information point и получить данные.

То есть каким-то образом вы умеете встраиваться в запросы, в репортинг, чтобы подставить?

Вы имеете в виду подставить в отчет эти данные?

Нет, мы сейчас этого не умеем.

Мы умеем только организовать фильтрацию данных, которые потом пойдут в отчет.

Ладно, спасибо.

Кажется, речь шла как раз о запросе, где вы показывали ID и Honor.

Вот именно об этом речь шла.

У меня похожий вопрос, может быть, слайд, который Москва, Питер, Новосибирск, когда у нас в одних табличках хранятся данные по разным подразделениям, и сотрудники Москвы могут смотреть на новосибирские данные.

Как это решается АБАКом?

Что-то я вот тоже не уловил.

То есть это как раз именно построчный доступ к данным, да?

Я правильно понял.

То есть SQL сервер, например, Microsoft, он умеет low-level security, ты кидаешь функцию, которую проверяет, удовлетворяет строчку условий, а вот тут непонятно, можно ли это разграничить.

С точки зрения стандарта, как раз я и говорил, что он на множественные данные не распространяется.

Он говорит про конкретный ресурс.

Функциональный чисто, да?

Да.

Собственно, вот как раз здесь вы видите, что User ID проверяется, проверяется поле Owner, и вместо него вы можете проверить любое другое поле.

Да, это понятно, но оно про функционал.

То есть я могу пользоваться, я могу выгружать отчет, но не могу ограничить внутри этого отчета данные, которые я выгружаю.

То есть если я выгружаю данные по бухгалтерии, чисто по конкретному отделу, я не могу?

С точки зрения стандарта, да, так сделать нельзя.

С точки зрения нашей реализации мы предусмотрели, возможно, фильтрации данных.

То есть вот эти фильтры, которые возвращаются, мы их можем превратить в запрос и по ним фильтровать данные.

Вот вон молодой человек рука.

Я запомнил вас.

Здравствуйте, спасибо за доклад.

Интересно, как вы реализовали как раз эти фильтры?

То есть это JavaScript интерпретатор или DSL какой-то?

Это, собственно, DSL, который я показывал на базе Axiomatics Alpha.

Он под капотом, у нас написанная грамматика на TLR.

Он преобразуется в зависимости от того... Давайте я покажу, у меня есть дополнительный... В TLR я уже понял.

То есть, по факту, фильтр может преобразоваться в SQL-запрос и дальше просто выполнить его.

Понятно.

И второй вопрос.

Как насчет производительности?

Вот это решение масштабируется ли для больших нагрузок или здесь вот в этом плане нету?

Знаете, откровенно скажу, у нас не стояла задача масштабирования по горизонтальному, по большим нагрузкам, но ни разу я не слышал, чтобы он был у нас бутылочным горлышком в работе нашего системы.

Окей, спасибо.

Спасибо.

Спасибо за доклад.

У меня короткий вопрос.

Вы упомянули, что ранее все политики поставлялись клиенту вместе с приложением.

Соответственно, он примес, они устанавливали его на своих серверах, и политики хранились там же в виде файлов.

Были ли какие-то проблемы с безопасностью?

То есть клиент мог бы чисто теоретически поправить политику и воспользоваться более расширенной лицензией?

Нет.

Реальных прецедентов такого не было.

Во-первых, надо знать, куда лезть и как править.

Не все из клиентов знают.

С другой стороны, если мы, допустим, защищаемся не от клиента, а от злоумышленника, то если злоумышленник уже получил доступ к серверу с продуктом или к группе серверов с продуктом, то изменение политик – это самая маленькая проблема, которая у нас есть.

Да, он ставился на сервера самого клиента.

Да, у него был доступ, он мог, но мы не знали ничего про это.

Еще вопросы?

Хорошо, я позволю себе задать вопрос, который прилетел в чат.

В чем различие и преимущество над Coinbase?

Различие как раз-таки в том, что claim-based, по-моему, он же как раз как и ролевая модель работает, он описывает клеймы к конкретным, к чему-то, к чему мы описали, но не позволяет делать более гранулярную историю по атрибутам конкретных ресурсов.

Но вы, наверное, говорите о том, что для того, чтобы сделать более гранулярную проверку, придется просто написать гораздо больше кода, потому что сделать мы ее можем.

И сложнее будет поддерживать клеймы.

Спасибо.

Коллеги, уважаемые, стенд компании Postive Technologies находится там.

Вы можете принять участие в их активностях, даже какие-то призы, возможно, выиграть.

Ну и, конечно же, задать дополнительные вопросы Михаилу, которые не успели задать здесь.

Спасибо, Михаил, за доклад.

Спасибо.