Data/Locales/checks/ru/TierZeroChecks.json
|
{ "_family": "TierZeroChecks.json", "ADTIER-001": { "name": { "value": "Аудит учётной записи синхронизации Azure AD Connect (MSOL_)", "status": "machine-draft" }, "description": { "value": "При установке Azure AD Connect в режиме Express создаётся доменная учётная запись с именем MSOL_<random-hex> и ей предоставляются права Replicating Directory Changes и Replicating Directory Changes All на контексте именования домена, то есть права DCSync. Фактически эта учётная запись относится к Tier-0, но по умолчанию находится в стандартном контейнере Users, имеет срок действия пароля 10 лет и редко попадает в инструменты перечисления привилегированных групп, поскольку получает свои полномочия через прямой ACL, а не через членство в группе. Компрометация этой учётной записи функционально равнозначна захвату домена", "status": "machine-draft" }, "recommendedValue": { "value": "Все учётные записи MSOL_ инвентаризированы, их пароль сменён в течение последних 180 дней, они размещены в подразделении Tier-0 с ограниченными правами входа, а сам сервер AAD Connect защищён как система Tier-0", "status": "machine-draft" }, "remediationSteps": { "value": "Найдите учётную запись MSOL_: Get-ADUser -Filter {sAMAccountName -like 'MSOL_*'}. Убедитесь, что у неё есть права DCSync: dsacls 'DC=domain,DC=com' | findstr MSOL_. Переместите её в подразделение администрирования Tier-0. Смените пароль средствами AAD Connect (НЕ сбрасывайте через стандартные инструменты, используйте Add-ADSyncADDSConnectorAccount в модуле PowerShell ADSync на сервере AAD Connect). Примените GPO ограничения входа, чтобы учётная запись могла входить локально только на сам сервер AAD Connect. Рассматривайте узел AAD Connect как Tier-0: ограничьте круг тех, кто может подключаться к нему по RDP или администрировать его", "status": "machine-draft" } }, "ADTIER-002": { "name": { "value": "Учётные записи служб ПО резервного копирования в привилегированных группах", "status": "machine-draft" }, "description": { "value": "ПО резервного копирования (Veeam, Commvault, Rubrik, Cohesity, NAKIVO, Backup Exec, Vembu, Acronis) обычно запрашивает учётную запись службы с очень высокими правами. В документации для простоты настройки нередко предлагается Domain Admin, и многие администраторы соглашаются. Как только злоумышленник компрометирует сервер резервного копирования (частый вектор первоначального доступа при атаках программ-вымогателей), он наследует Domain Admin через учётную запись службы. Это путь повышения привилегий номер один при атаках программ-вымогателей по данным реагирования на инциденты за 2023-2025 годы", "status": "machine-draft" }, "recommendedValue": { "value": "Ни одна учётная запись службы ПО резервного копирования не является членом Domain Admins, Enterprise Admins, Schema Admins или Backup Operators. Используйте документированные вендором учётные записи с минимальными привилегиями и изолированные учётные данные резервного копирования", "status": "machine-draft" }, "remediationSteps": { "value": "Определите используемый продукт резервного копирования и следуйте его руководству по минимальным привилегиям (Veeam: только локальный администратор сервера резервного копирования плюс учётная запись AD с чтением объектов; Rubrik: выделенный субъект-служба в облачной роли и т. д.). Удалите учётную запись резервного копирования из Domain Admins. Перейдите на gMSA там, где это поддерживается. Разместите сервер резервного копирования в подразделении Tier-1 с ограниченными правами входа. Если полный DA действительно требуется для конкретной рабочей нагрузки, задокументируйте это и изолируйте эту часть резервного копирования на отдельной учётной записи, отличной от основной", "status": "machine-draft" } }, "ADTIER-003": { "name": { "value": "Учётные записи служб гипервизора и виртуализации в привилегированных группах", "status": "machine-draft" }, "description": { "value": "Интеграции vCenter, Hyper-V, SCVMM, Citrix, Nutanix с AD часто используют учётную запись службы, настроенную при развёртывании. Если эта учётная запись является Domain Admin, то компрометация плоскости управления гипервизором (или базы данных SSO узла) распространяется на AD. Гипервизор концептуально уже относится к Tier-0; его идентификатор в AD должен этому соответствовать", "status": "machine-draft" }, "recommendedValue": { "value": "Учётные записи служб гипервизора имеют только права, документированные вендором (обычно чтение для инвентаризации плюс запись в конкретные подразделения, если используется интеграция VM с AD). Не входят в Domain Admins", "status": "machine-draft" }, "remediationSteps": { "value": "Проверьте учётную запись службы AD для каждого продукта гипервизора. Примените рекомендации вендора по минимальным привилегиям. Для vCenter: используйте документированный шаблон источника идентификации SSO вместо сопоставления с Domain Admin. Для Hyper-V/SCVMM: ограничьте права учётной записи службы подразделениями, где размещаются учётные записи компьютеров виртуальных машин. Рассматривайте узел управления гипервизором как Tier-0 в вашей административной модели", "status": "machine-draft" } }, "ADTIER-004": { "name": { "value": "Учётные записи служб управления конфигурацией в привилегированных группах", "status": "machine-draft" }, "description": { "value": "Платформы управления конфигурацией (SCCM/MECM, Intune Connector, Jamf, KACE, Lansweeper, ManageEngine, Ivanti, BigFix) по определению распространяют ПО на каждую конечную точку: они уже являются привилегированной платформой для горизонтального перемещения. У SCCM, в частности, есть хорошо известные примитивы злоупотребления (раскрытие Network Access Account, принуждение NTLM к серверу сайта, client push). Учётная запись службы управления конфигурацией в Domain Admins даёт злоумышленнику, попавшему на любую управляемую конечную точку, ключи от домена", "status": "machine-draft" }, "recommendedValue": { "value": "Учётные записи служб управления конфигурацией ограничены документированными минимальными правами и никогда не входят в Domain Admins или Enterprise Admins. Network Access Account в SCCM представляет собой непривилегированный выделенный идентификатор", "status": "machine-draft" }, "remediationSteps": { "value": "Определите продукт управления конфигурацией и проверьте права учётной записи службы. Для SCCM: убедитесь, что Network Access Account непривилегирована (НЕ Domain Admin); убедитесь, что учётная запись компьютера сервера сайта не является Domain Admin; проверьте учётные записи служб иерархии на предмет минимальных привилегий. Переместите серверы сайтов и точки управления в подразделение Tier-0 с ограниченными входами", "status": "machine-draft" } }, "ADTIER-005": { "name": { "value": "Учётные записи служб SQL и баз данных в привилегированных группах", "status": "machine-draft" }, "description": { "value": "Учётные записи служб SQL Server, MySQL, PostgreSQL в Domain Admins распространены в средах, где команда администраторов баз данных установила SQL по стандартной рекомендации «использовать существующую учётную запись AD» и выбрала учётную запись администратора из соображений удобства. Как только сервер баз данных становится доступен по сети, компрометация учётных данных SQL или уязвимость SQL Server даёт злоумышленнику Domain Admin напрямую", "status": "machine-draft" }, "recommendedValue": { "value": "Учётные записи служб баз данных работают как gMSA или выделенные идентификаторы служб без членства в привилегированных группах", "status": "machine-draft" }, "remediationSteps": { "value": "Переведите учётные записи служб SQL на gMSA там, где это поддерживается. Для учётных записей, которые должны оставаться пользовательскими, удалите членство в привилегированных группах и предоставьте только локальные права, необходимые движку базы данных (Log on as a service, Bypass traverse checking, Adjust memory quotas for a process, см. конкретные права в документации Microsoft)", "status": "machine-draft" } }, "ADTIER-006": { "name": { "value": "Административные учётные записи Tier-0 вне выделенного подразделения Tier-0", "status": "machine-draft" }, "description": { "value": "Если ваши Domain Admins находятся в том же подразделении, что и обычные пользователи, каждый GPO, нацеленный на пользователей (сценарии входа, политика браузера, подключённые диски и т. д.), также применяется к вашим Domain Admins, а значит любой, кто может редактировать эти GPO, способен выполнить код от имени Domain Admin при следующем входе. Многоуровневая модель Microsoft рекомендует выделенное подразделение администрирования Tier-0 с ограниченным авторством GPO и ограниченными правами входа", "status": "machine-draft" }, "recommendedValue": { "value": "Все члены Domain Admins, Enterprise Admins и Schema Admins находятся в выделенном подразделении Tier-0 (обычно OU=Tier-0,OU=Admin) с ограниченным авторством GPO", "status": "machine-draft" }, "remediationSteps": { "value": "Создайте OU=Tier-0,OU=Admin, если оно ещё не существует. Переместите в него всех членов Domain/Enterprise/Schema Admins. Ограничьте авторство GPO на этом подразделении (только самими администраторами Tier-0). Примените выделенный GPO ограничения входа, чтобы учётные записи Tier-0 могли входить только на узлы Tier-0. Заблокируйте наследование на этом подразделении", "status": "machine-draft" } }, "ADTIER-007": { "name": { "value": "Учётные записи служб с правами интерактивного входа через привилегированную группу", "status": "machine-draft" }, "description": { "value": "Учётные записи служб, являющиеся членами Domain Admins (или любой группы, которой предоставлено право «Allow log on locally» через стандартное членство в привилегированной группе), могут использоваться интерактивно. Злоумышленники это любят: перехватить пароль учётной записи службы (Kerberoasting, реестр, сценарии в SYSVOL), использовать его интерактивно на рабочей станции, извлечь LSASS и переместиться дальше. Учётные записи служб не должны иметь возможности интерактивно входить ни на что, кроме обслуживаемого ими узла", "status": "machine-draft" }, "recommendedValue": { "value": "Учётным записям служб (эвристика: sAMAccountName начинается с svc/sa/service или имеет SPN и не входила интерактивно в последнее время) явно запрещены «Allow log on locally» и «Allow log on through Remote Desktop Services» через Default Domain Controllers Policy и выделенный GPO ограничения входа Tier-1/Tier-2", "status": "machine-draft" }, "remediationSteps": { "value": "Определите учётные записи служб (наличие SPN, соглашение об именовании или бизнес-инвентаризация). Примените GPO Default Domain Policy: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > 'Deny log on locally' = <service-accounts-group>. Добавьте те же учётные записи в 'Deny log on through Remote Desktop Services'. Добавьте их в Protected Users там, где это поддерживается (Server 2012 R2 и новее)", "status": "machine-draft" } } } |