Реализация архитектуры безопасности с нулевым доверием: вторая редакция

[andreyverbin]

Мне всегда интересно, как работает этот самый Policy Engine (PE). Вот сделал я политики — «сидеть вконтакте не более 20 минут в день» или «не заходить на сайт XXX», «пользователь с ролью „Поддержка“ не может выполнять запросы к таблице XYZ». Получается, что PE должен быть интегрирован в каждое приложение, которым пользуются юзеры. Но это же утопия.

[GritsanY]

ZTA придуман для того, чтобы бороться с концепцией "неявного" доверия к компоненту сети. Например, в классической архитектуре сети если вы и другой хост находитесь в одной IP-подсети, то вам, условно, даётся полный доступ к этому хосту (не существует хорошо масштабируемых инструментов в самой сети, чтобы ограничить вам доступ). Или, например, если вы ввели пароль свой учётки для доступа к внутреннему ресурсу и ресурс установил доверие с вами, то это не значит, что можно доверять машине, с которой вы получаете доступ. И помогает в первом случае микросегментация, во втором — мультифакторная аутентификация. Это всё кусочки архитектуры ZTA (далеко не все).
А из того, что вы привели — первый пример не имеет отношения к информационной безопасности,
второй — решается разными сетевыми способами,
третий — сеть принять решение здесь не сможет, вы правы, это уровень приложения и пилить доступ к отдельным таблицам БД должен role-based access control СУБД.

[andreyverbin]

Ага, тут только про сеть, я как-то это упустил. Меня смутили PE, PDP и PA, которые часто используются в других контекстах (всякий OAuth, SAML, SSO, и т.п.).

[vikarti]

Вот сделал я политики — «сидеть вконтакте не более 20 минут в день» или «не заходить на сайт XXX»,

Смотрим по IP (заранее отрезолвив DNS имена интересных сайтов или тупо забив что подсеть A.B.C.D/24 это непонятно что но принадлежит вконтакту) и смотрим статистику. Если больше 20 минут в день — инжектим пользователю редирект на сообщение что время вышло или тупо режем. C https сам сайт тоже прекрасно отслеживается (если там не TLS 1.3 )
Чтобы бороться с tls 1.3 или запрещать например конкретную группу вконтакта — тупо проксируем весь веб-трафик (а пользователю ставим сертификат нашего внутреннего CA, и имеем проблемы с мобилками).
Надо авторизацию получше а не через IP пользователя? Так вообще запретить ходить кроме как через явно указанный через групповые политики прокси, с NTLM авторизаций через ActiveDirectory. Ну или пользователю на компьютер ставить Агент Доверия который его локальную авторизацию и IP — прокинет куда следует а заодно проверить что есть корневые сертификаты которые для взлома https.

С таблицей XYZ — уже на уровне СУБД/Сервера Приложений придется делать.

[andreyverbin]

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

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

[glader]

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

Относится ли это к LDAP как единому центру аутентификации? Каждый ресурс должен иметь свою базу пользователей?

[GritsanY]

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