
Комментарии 7
К сожалению это действительно так. Сейчас очень распространена атака на цепочку поставок, а так как сервис дески в основном опенсорсное решение и редко когда разработчики занимаются харденингом кода, а если к этому еще добавить огромное количество форков, в которых может быть овердофига закладок и т.п., то пускать в ружу такую систему может быть себе дороже. Обычно сервис дески работают с AD по LDAP, и если с ружи получится скомпрометировать УЗ и повысить привилегии, то game over. Понятно что в зрелых организациях есть FW на границе, возможно даже EDR на конечных точках (хотя бы серверах) и сисадмины даже могут замутить DMZ спецом для такого кейса, но все это упирается во время и нехватку персонала, поэтому либо проект остаётся на бумаге либо чаще просто НЕТ.
Спасибо. Тут дело не в сервис десках (кстати опен сорс решений у энтерпрайз сегмента не видел), думаю с такой проблемой сталкиваются любые классы систем, которые хотят на ружу). Да сервис деск зачастую работает с AD по LDAP, но SSO SAML никто не отменял + всегда есть двухфакторная аутентификация, если подытожить то упираемся в бюджеты и время.
Я такой себе ИБ пофигист, поэтому пускаю клода в свою небольшую рабочую сетку небольшой организации на 30 чел. Настраивает AD вдоль и поперёк. Вычистил кучу техдолга в интранете. В общем имхо вопрос бюджеты-время упирается лишь в уровень доверия ИИ инструментарию.
ИИ инструментарий это относительно новая технология. А вот всякие CRM или ITSM системы используются уже десятки лет, а до сих пор запрещают в некоторых организациях интеграцию с внешними системами. Что касается ИИ тут в первую очередь с людьми нужно работать, что бы не сливали в ИИ конфиденциальную информацию.
Я для тестов свою AD тоже настраивал чрез ИИ, заводя тута десятки тестовых пользователей, групп и т.д.
Недавно клодом 1) поднял новую виртуалку на ESXi c Win2025 2) На нём новый DC 3) старый задемоутил Всё это с ворохом всякого обвеса в sysvol и кастом скриптах, вылечиванием старых проблем в DNS и DHCP из-за собственной криворукости и прочее. За 2 дня. Ни разу не заходив ни на один из серверов. Не призываю так делать, но будущее рядом.
Не запретительный, а разрешительный :)
Две стратегии:
(Либеральный) Всё разрешено, пока явно не запрещено
Всё запрещено, пока явно не разрешено
Оставим гибридную за рамками…
Первая требует постоянного мониторинга изобретательности людей и выдачи точечных запретов (запретительный орган). В итоге нужно управлять и поддерживать большой список непонятных запретов.
Вторая требует мониторинга, но не совсем такого широкого. В итоге нужно управлять и поддерживать небольшой список понятных разрешений. (разрешительный орган)
А как там устроено на местах - это отдельный вопрос. Где-то ИБ может работать только как супервизор: не предлагает решений, а анализирует предложенные на предмет их допустимости. "Нет" значит “в этом виде не годится, приходите с другим решением”.
Существуют две политики, массовая - палочная, и маргинальная - превентивная.
Первая стала массовой именно потому что вы заметили, это же хоть и информационная но БЕЗОПАСНОСТЬ. А потому как правило на руководящие позиции туда прут пенсы из силовиков, в основном "мусора". Какие вы от них навыки и скилы хотите? Только наказать и палки зарабатывать. Они и в прошлом своём занятии тем же занимались. А вот стратегия (которой стараюсь придерживаться и я в своей работе) превентивная - руководством не поддерживается.
Стратегия, имхо, должна предусматривать всего то несколько принципов:
защита компании от нарушителей
соответствие регуляторики в отрасли
защита сотрудников компании от ошибок
Стиль простой, ИБ должна работать так, чтобы никто и не знал о её работе, а все действия пользователей, отрегулированные политикой в рамках трудовой деятельности, никак не могли создать проблем как системам так и самим пользователям, им не нужно думать о правилах соблюдения ИБ, у них своя работа есть, подчас гораздо сложнее.
Это непростая задача, но решаемая. Главное чётко представлять цели, а способ найдётся.
ИБ как запретительный орган: традиция или необходимость?