Через службу каталогов работает часть функционала инвентаризации активов;
Я применяю объекты групповой политики к серверам через 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 и т.д.) Особенно была бы интересна часть про подводные камни реализации..)
Информация
В рейтинге
796-й
Зарегистрирован
Активность
Специализация
Инженер по безопасности, Специалист по информационной безопасности
В моём случае это необходимо потому, что:
Через службу каталогов работает часть функционала инвентаризации активов;
Я применяю объекты групповой политики к серверам через 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 и т.д.)
Особенно была бы интересна часть про подводные камни реализации..)