В целом я не встречал сценарии, при котором придётся массово заливать настолько огромное количество устройств в домен (речь скорее идёт про десятки или сотни хостов в одном инвентаре), поэтому судить не могу;
Хорошее замечание, выполняемые команды можно будет взять из разных мест (.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 и т.д.) Особенно была бы интересна часть про подводные камни реализации..)
Information
Rating
Does not participate
Registered
Activity
Specialization
Инженер по безопасности, Специалист по информационной безопасности
Гляну, благодарю!
Благодарю, попробую обкатать такой метод в своей среде!
Интересные вопросы:
В целом я не встречал сценарии, при котором придётся массово заливать настолько огромное количество устройств в домен (речь скорее идёт про десятки или сотни хостов в одном инвентаре), поэтому судить не могу;
Хорошее замечание, выполняемые команды можно будет взять из разных мест (.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 и т.д.)
Особенно была бы интересна часть про подводные камни реализации..)