Благодарю за вопрос, на самом деле тут стоит уточнить для доступа к каким ресурсам может потребоваться запрос логина и пароля при истечении срока жизни билета Kerberos.
Если говорить про RDP-сессию - то не придётся заново вводить логин и пароль при истечении срока жизни билета, здесь всё решается параметрами таймаута и блокировки RDP-сеансов, если же говорить про сетевые ресурсы - например DFS или простые сетевые папки - может быть заново затребован логин и пароль.
На практике с какими-либо сложностями при такой конфигурации не сталкивался (применял её в собственной инфраструктуре)
Вероятно, роль пункта про отложенное восстановление бэкапов ещё состоит в том, чтобы не восстанавливать систему, которая заведомо может содержать в себе те же закладки (бэкдоры) и уязвимости, которые были на момент компрометации инфраструктуры, и их восстановление без качественного расследования инцидента - будет вождением вилами по воде (злоумышленники смогут провести те же векторы атак и закрепления).
Спасибо за комментарий, внесу корректировки в стиль повествования!
Немного философствуя на тему места СРК и её администраторов в такой модели - по всем признакам оно именно в нулевом тире, но требует особого внимания из-за её роли для бизнеса (вряд ли первым лицам Компании станет хорошо, когда до них дойдёт информация об отсутствии резервных копий, или о том что они были зашифрованы очередной ransomwar'ью вместе со всей остальной инфраструктурой). Стоит начать хотя бы с "лучших практик" самого вендора СРК (вот например для Veeam, их B&R до сих пор достаточно часто встречается в ру-сегменте), с последующим эшелонированием и наслоением мер (привет мониторинг событий ИБ, изолированные инсталляции СРК для реализации 3-2-1-1-0 и т.д.).
Касательно RODC: они и до сих пор применяются по прямому назначению, например в крупном энтерпрайзе с множеством филиалов - не только для оптимизации потоков аутентификации и сетевой нагрузки, но и для защиты доменных служб в трудно-контролируемых локациях (на ум приходят и другие сценарии, но они, вероятно, менее целесообразны, из-за наличия всех прочих защитных механизмов)
Практически дословное цитирование документации ЛК:
https://support.kaspersky.ru/ksc/15.1/3674 (тихий режим утилиты klbackup): ... -migrate mysql – создание резервной копии данных Сервера администрирования, хранящихся в базе данных SQL Server, совместимой с MySQL (включая MariaDB). Данные из этой резервной копии можно восстановить в MySQL. ...
https://support.kaspersky.ru/ksc/15.1/13288 (интерактивный режим утилиты klbackup): ... параметр Перенос данных в формате MySQL/MariaDB - Включите этот параметр, если в настоящее время вы используете SQL Server в качестве СУБД для Сервера администрирования и хотите перенести данные с SQL Server на MySQL или MariaDB. Kaspersky Security Center создаст резервную копию данных, совместимую с MySQL и MariaDB. После этого вы можете восстановить данные из резервной копии в MySQL или MariaDB. ...
Если вы не видите данный параметр - возможно, у вас стоит EOL-версия KSC (<14)
В целом я не встречал сценарии, при котором придётся массово заливать настолько огромное количество устройств в домен (речь скорее идёт про десятки или сотни хостов в одном инвентаре), поэтому судить не могу;
Хорошее замечание, выполняемые команды можно будет взять из разных мест (.bash_history, или же напрямую из памяти при наличии активной сессии), был бы рад услышать про реализацию метода с вводом в домен через тикет Kerberos с использованием ansible;
В целом AWX интересный продукт, но сильной потребности в моей среде в нём нет, и имеется достаточный опыт работы с голым Ansible, плюс в скором времени первый ждут определённые реворки в силу монолитности проекта, поэтому может быть в будущем получится раскрыть эту тему и с ним.
Через службу каталогов работает часть функционала инвентаризации активов;
Я применяю объекты групповой политики к серверам через ADSys для запуска startup-скриптов (но на самом деле применения у модуля масса, в том числе контроль доступа и управление привилегиями sudo);
Некоторые сервисы, в которых реализована поддержка Kerberos-аутентификации - требуют наличия у учётной записи компьютера SPN-записи, что невозможно без его ввода в домен;
Можно настроить autoenrollment сертификатов через AD CS;
Можно получать доступ к другим ресурсам в домене (например, сетевым папкам) без дополнительного ввода пароля, при наличии действующего билета Kerberos.
Если в вашем случае необходима только доменная аутентификация на серверах - можно не вводить их домен, и ограничиться только настройкой sssd и сопуствующих служб и модулей ОС.
В целом можно использовать для этой задачи и ntp и chrony, вопрос скорее привычки и потребности в расширенном функционале chrony (в моей среде он не требуется)
У коллег тоже были интересные моменты, связанные с традиционным VPN в UserGate, насколько помню были расхождения в конфигурациях серверных и клиентских профилей, хотя везде они были настроены корректно. Решило проблему только мажорное обновление с 6.х на 7.х версию UGOS
Дополню статью касательно менеджеров паролей, по крайней мере для админов.
Хранить общую базу kdbx на файловой шаре, причём в чистом виде - не безопасно само по себе, в виду наличия у него множества уязвимостей (https://www.cve.org/CVERecord/SearchResults?query=keepass).
Всё же для совместного доступа рекомендовал бы приглянуться в т.ч. к open-source решениям для командной работы с паролями, например passbolt (https://www.passbolt.com/) или vaultwarden (https://github.com/dani-garcia/vaultwarden).
Конечно, не забыв о проработке модели защиты и для них :)
Рекламная статья сгенерированная ИИ, где не написаны никакие фактические доводы в пользу данного продукта, и уверяю - безопасности и удобства там сильно меньше чем в забугорном дискорде. Советую почитать комментарии выше, где более полно раскрыли то, почему много негатива в сторону продукта.
Правильно подметили, что забыл упомянуть в статье довольно важные темы по поводу точек распространения и как следствие шлюзов соединения (но нюансов в их работе тоже не мало, в целом хватило бы на отдельную статью), они тоже играют роль в нивелировании сетевой нагрузки.
К сожалению в официальной документации не нашёл прямого подтверждения уменьшения нагрузки на сеть при использовании шлюзов соединения именно в описанном в статье сценарии, видимо уточню этот вопрос уже на обучающем курсе.
Очень удобный инструмент, позволяющий и проанализировать действующие security-бэйзлайны microsoft для доменных узлов и объектов в виде отчётов html, а так же их импортировать в действующий домен организации.
Всем советую, но используйте с умом, и предварительным анализом того, что вы включаете)
Вспоминается поговорка: "Плохому танцору и яйца мешают"
Если у ответственного ИТ/ИБ специалиста организации имеется достаточная квалификация и опыт - он сможет, не прибегая к дорогим для организации решениям, по типу физической изоляции сегментов сети - построить киберустойчивую сетевую инфраструктуру (даже не берём в расчеты отдельные случаи, когда организация имеет инфраструктуру уровня матёрого дата-центра, на всех стыках которой такого рода защиту выстроить практически невозможно без серьёзной потери управляемости, масштабируемости и гибкости управления, что тоже весьма важно).
Ровно как и не самый лучший специалист, даже прибегая к "лучшим" архитектурным решениям, может запороть киберустойчивость сетевой инфраструктуры её незнанием, или кривой реализацией.
Про субъекты КИИ - понятное дело, что защита такого уровня должна присутствовать "по умолчанию", в добавок к различным наложенным средствам защиты информации.
Зачем когда есть менеджеры паролей, причем некоторые из них с аатозаполнением и гибким генератором паролей? (Бесплатный - KeePassXC, Платный - Roboform, про корп.сегмент даже говорить нет смысла, поскольку имеется несколько десятков продуктов со схожим и даже большим функционалом, на любой вкус, цвет и потребности);
Использовать на двух и более сайтов один и тот же пароль, хеш или иные производные - априори не безопасная идея;
Коллеги, благодарю за познавательную статью! Подскажите, а был ли в рамках данного проекта, или иного другого, кейсы интеграции SIEM с DR (Detection and Response) решениями? (с KATA, TDR, MXDR и т.д.) Особенно была бы интересна часть про подводные камни реализации..)
Информация
В рейтинге
1 535-й
Зарегистрирован
Активность
Специализация
Инженер по безопасности, Специалист по информационной безопасности
Благодарю за вопрос, на самом деле тут стоит уточнить для доступа к каким ресурсам может потребоваться запрос логина и пароля при истечении срока жизни билета Kerberos.
Если говорить про RDP-сессию - то не придётся заново вводить логин и пароль при истечении срока жизни билета, здесь всё решается параметрами таймаута и блокировки RDP-сеансов, если же говорить про сетевые ресурсы - например DFS или простые сетевые папки - может быть заново затребован логин и пароль.
На практике с какими-либо сложностями при такой конфигурации не сталкивался (применял её в собственной инфраструктуре)
Вероятно, роль пункта про отложенное восстановление бэкапов ещё состоит в том, чтобы не восстанавливать систему, которая заведомо может содержать в себе те же закладки (бэкдоры) и уязвимости, которые были на момент компрометации инфраструктуры, и их восстановление без качественного расследования инцидента - будет вождением вилами по воде (злоумышленники смогут провести те же векторы атак и закрепления).
Спасибо за статью!
Спасибо за комментарий, внесу корректировки в стиль повествования!
Немного философствуя на тему места СРК и её администраторов в такой модели - по всем признакам оно именно в нулевом тире, но требует особого внимания из-за её роли для бизнеса (вряд ли первым лицам Компании станет хорошо, когда до них дойдёт информация об отсутствии резервных копий, или о том что они были зашифрованы очередной ransomwar'ью вместе со всей остальной инфраструктурой).
Стоит начать хотя бы с "лучших практик" самого вендора СРК (вот например для Veeam, их B&R до сих пор достаточно часто встречается в ру-сегменте), с последующим эшелонированием и наслоением мер (привет мониторинг событий ИБ, изолированные инсталляции СРК для реализации 3-2-1-1-0 и т.д.).
Касательно RODC: они и до сих пор применяются по прямому назначению, например в крупном энтерпрайзе с множеством филиалов - не только для оптимизации потоков аутентификации и сетевой нагрузки, но и для защиты доменных служб в трудно-контролируемых локациях (на ум приходят и другие сценарии, но они, вероятно, менее целесообразны, из-за наличия всех прочих защитных механизмов)
Практически дословное цитирование документации ЛК:
https://support.kaspersky.ru/ksc/15.1/3674 (тихий режим утилиты klbackup):
... -migrate mysql – создание резервной копии данных Сервера администрирования, хранящихся в базе данных SQL Server, совместимой с MySQL (включая MariaDB). Данные из этой резервной копии можно восстановить в MySQL. ...
https://support.kaspersky.ru/ksc/15.1/13288 (интерактивный режим утилиты klbackup):
... параметр Перенос данных в формате MySQL/MariaDB - Включите этот параметр, если в настоящее время вы используете SQL Server в качестве СУБД для Сервера администрирования и хотите перенести данные с SQL Server на MySQL или MariaDB. Kaspersky Security Center создаст резервную копию данных, совместимую с MySQL и MariaDB. После этого вы можете восстановить данные из резервной копии в MySQL или MariaDB. ...
Если вы не видите данный параметр - возможно, у вас стоит EOL-версия KSC (<14)
Гляну, благодарю!
Благодарю, попробую обкатать такой метод в своей среде!
Интересные вопросы:
В целом я не встречал сценарии, при котором придётся массово заливать настолько огромное количество устройств в домен (речь скорее идёт про десятки или сотни хостов в одном инвентаре), поэтому судить не могу;
Хорошее замечание, выполняемые команды можно будет взять из разных мест (.bash_history, или же напрямую из памяти при наличии активной сессии), был бы рад услышать про реализацию метода с вводом в домен через тикет Kerberos с использованием ansible;
В целом AWX интересный продукт, но сильной потребности в моей среде в нём нет, и имеется достаточный опыт работы с голым Ansible, плюс в скором времени первый ждут определённые реворки в силу монолитности проекта, поэтому может быть в будущем получится раскрыть эту тему и с ним.
Для предотвращения конфликтов доступа к сетевому порту 123/udp и системным часам при ручной синхронизации времени через ntpdate
В моём случае это необходимо потому, что:
Через службу каталогов работает часть функционала инвентаризации активов;
Я применяю объекты групповой политики к серверам через ADSys для запуска startup-скриптов (но на самом деле применения у модуля масса, в том числе контроль доступа и управление привилегиями sudo);
Некоторые сервисы, в которых реализована поддержка Kerberos-аутентификации - требуют наличия у учётной записи компьютера SPN-записи, что невозможно без его ввода в домен;
Можно настроить autoenrollment сертификатов через AD CS;
Можно получать доступ к другим ресурсам в домене (например, сетевым папкам) без дополнительного ввода пароля, при наличии действующего билета Kerberos.
Если в вашем случае необходима только доменная аутентификация на серверах - можно не вводить их домен, и ограничиться только настройкой sssd и сопуствующих служб и модулей ОС.
В целом можно использовать для этой задачи и ntp и chrony, вопрос скорее привычки и потребности в расширенном функционале chrony (в моей среде он не требуется)
У коллег тоже были интересные моменты, связанные с традиционным VPN в UserGate, насколько помню были расхождения в конфигурациях серверных и клиентских профилей, хотя везде они были настроены корректно. Решило проблему только мажорное обновление с 6.х на 7.х версию UGOS
Дополню статью касательно менеджеров паролей, по крайней мере для админов.
Хранить общую базу kdbx на файловой шаре, причём в чистом виде - не безопасно само по себе, в виду наличия у него множества уязвимостей (https://www.cve.org/CVERecord/SearchResults?query=keepass).
Всё же для совместного доступа рекомендовал бы приглянуться в т.ч. к open-source решениям для командной работы с паролями, например passbolt (https://www.passbolt.com/) или vaultwarden (https://github.com/dani-garcia/vaultwarden).
Конечно, не забыв о проработке модели защиты и для них :)
Было бы интересно услышать в статье так же про альтеинативный метод установки через папку Knox (для смартфонов samsung)
Рекламная статья сгенерированная ИИ, где не написаны никакие фактические доводы в пользу данного продукта, и уверяю - безопасности и удобства там сильно меньше чем в забугорном дискорде. Советую почитать комментарии выше, где более полно раскрыли то, почему много негатива в сторону продукта.
Добрый день!
Правильно подметили, что забыл упомянуть в статье довольно важные темы по поводу точек распространения и как следствие шлюзов соединения (но нюансов в их работе тоже не мало, в целом хватило бы на отдельную статью), они тоже играют роль в нивелировании сетевой нагрузки.
К сожалению в официальной документации не нашёл прямого подтверждения уменьшения нагрузки на сеть при использовании шлюзов соединения именно в описанном в статье сценарии, видимо уточню этот вопрос уже на обучающем курсе.
Как раз в процессе выбора УЦ и согласования обучения, благодарю за совет)
Жалко не упомянули про Microsoft Security Compliance ToolKit:
https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/windows-security-configuration-framework/security-compliance-toolkit-10
Очень удобный инструмент, позволяющий и проанализировать действующие security-бэйзлайны microsoft для доменных узлов и объектов в виде отчётов html, а так же их импортировать в действующий домен организации.
Всем советую, но используйте с умом, и предварительным анализом того, что вы включаете)
Вспоминается поговорка: "Плохому танцору и яйца мешают"
Если у ответственного ИТ/ИБ специалиста организации имеется достаточная квалификация и опыт - он сможет, не прибегая к дорогим для организации решениям, по типу физической изоляции сегментов сети - построить киберустойчивую сетевую инфраструктуру (даже не берём в расчеты отдельные случаи, когда организация имеет инфраструктуру уровня матёрого дата-центра, на всех стыках которой такого рода защиту выстроить практически невозможно без серьёзной потери управляемости, масштабируемости и гибкости управления, что тоже весьма важно).
Ровно как и не самый лучший специалист, даже прибегая к "лучшим" архитектурным решениям, может запороть киберустойчивость сетевой инфраструктуры её незнанием, или кривой реализацией.
Про субъекты КИИ - понятное дело, что защита такого уровня должна присутствовать "по умолчанию", в добавок к различным наложенным средствам защиты информации.
Интересное решение, но:
Зачем когда есть менеджеры паролей, причем некоторые из них с аатозаполнением и гибким генератором паролей? (Бесплатный - KeePassXC, Платный - Roboform, про корп.сегмент даже говорить нет смысла, поскольку имеется несколько десятков продуктов со схожим и даже большим функционалом, на любой вкус, цвет и потребности);
Использовать на двух и более сайтов один и тот же пароль, хеш или иные производные - априори не безопасная идея;
Коллеги, благодарю за познавательную статью!
Подскажите, а был ли в рамках данного проекта, или иного другого, кейсы интеграции SIEM с DR (Detection and Response) решениями? (с KATA, TDR, MXDR и т.д.)
Особенно была бы интересна часть про подводные камни реализации..)