🪟 Windows: OSConfig — GPO умерло, долго живёт drift control

Коллеги, у вас в домене есть сервера, где кто-то "временно" отключил NTLMv1 и забыл вернуть? Или изменил политику аудита "под задачу"? Или коллега поставил TLS 1.0 для совместимости с каким-то древним ПО и не сказал? Я видел такое. Называется configuration drift, и он медленно разрушает безопасный периметр, который ты тщательно выстраивал.

В Windows Server 2025 Microsoft тихо привезла ответ на этот вопрос: OSConfig. Каждые несколько часов OSConfig сканирует отклонения от baseline-конфигурации и автоматически исправляет их — без необходимости ждать GPO-обновления или вмешательства вручную.

Базовая линия безопасности включает более 300 настроек безопасности, соответствующих отраслевым стандартам. После применения параметры автоматически защищены от дрейфа — это одна из ключевых особенностей платформы.

Разворачиваем и настраиваем:

# Устанавливаем модуль из PSGallery (нужен WS2025)
Install-Module -Name Microsoft.OSConfig -Scope AllUsers -Repository PSGallery -Force

# Смотрим доступные сценарии
Get-OSConfigMetadata | Format-Table Name, Description -Wrap
# Сценарии: SecurityBaseline, SecuredCore, AppControl, Defender

# Применяем baseline для Member Server (более 300 настроек разом)
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer

# Для Domain Controller — отдельный сценарий
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/DomainController

# Проверяем что применилось и нет расхождений
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer

# Включаем drift control (автоисправление отклонений)
# По умолчанию проверка каждые 4 часа
Get-OSConfigDriftControl
# Ужесточаем — проверка каждые 45 минут
Set-OSConfigDriftControl 45

# Смотрим конкретный параметр и его текущее состояние
Get-OSConfigDesiredConfiguration `
  -Scenario SecurityBaseline/WS2025/MemberServer `
  -Setting AuditDetailedFileShare

# Кастомизируем под свои нужды (без потери drift control)
# Например, разрешаем RDP drive redirection (отключено по умолчанию)
Set-OSConfigDesiredConfiguration `
  -Scenario SecurityBaseline/WS2025/MemberServer `
  -Name RemoteDesktopServicesDoNotAllowDriveRedirection `
  -Value 0

# Проверяем соответствие требованиям CIS/DISA STIG
# (OSConfig покрывает их автоматически при применении baseline)
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer |
  Where-Object {$_.ComplianceState -ne "Compliant"} |
  Select-Object Name, ExpectedValue, ActualValue

Важный нюанс: OSConfig не заменяет GPO и не конкурирует с ним напрямую. Он отлично подходит для изолированных серверов, workgroup-машин и облачных инстансов, где нет централизованного AD. В AD-среде — дополнительный слой защиты поверх GPO.

Зачем это нужно:
Аудиторы любят вопрос "как вы гарантируете, что конфигурация безопасности не изменилась с момента последней проверки?". Раньше честный ответ был "ну, мы стараемся следить". Теперь ответ: "автоматический drift control каждые 45 минут с логами". CIO это оценит на следующем совещании по ИБ.

Итог: GPO — это политика на бумаге. OSConfig — это политика, которая не даёт себя обойти. Разница принципиальная.

#windows #security #osconfig #drift #windowsserver2025 #sysadmin #admin_future

🧠 Skills: IaC drift — молчаливый убийца стабильности и как его ловить автоматически

Коллеги, у вас есть Ansible или Terraform. Вы гордитесь тем что инфраструктура описана как код. Но когда последний раз вы проверяли — соответствует ли то что работает в продакшне тому что написано в репозитории?

Configuration drift — это когда кто-то "быстро поправил руками" в пятницу вечером, написал "потом зафиксирую в коде" и конечно не зафиксировал. Через месяц инфраструктура живёт своей жизнью, а код — своей.

Два подхода в зависимости от инструмента:

# ---- ANSIBLE: детекция дрейфа через --check --diff ----
# Запускаем playbook в режиме проверки без изменений
ansible-playbook site.yml \
  -i inventories/production/hosts.yml \
  --check \
  --diff

# Вывод покажет ВСЕ расхождения между кодом и реальностью
# Строки с "-" = что есть сейчас, "+" = что должно быть по коду

# Автоматизируем: добавляем в cron или CI/CD pipeline
# crontab -e:
# 0 9 * * 1 ansible-playbook /opt/ansible/site.yml -i production --check --diff \
#   2>&1 | mail -s "Weekly drift report" admin@company.com

# ---- TERRAFORM: детекция дрейфа через plan ----
# Показывает расхождения между state и реальным состоянием ресурсов
terraform plan -detailed-exitcode
# Exit code: 0 = нет изменений, 1 = ошибка, 2 = есть изменения (drift!)

# В CI/CD (GitLab CI пример):
# drift_check:
#   schedule: "0 8 * * *"  # каждый день в 8:00
#   script:
#     - terraform init
#     - terraform plan -detailed-exitcode
#   allow_failure: false

# ---- ПРАВИЛО: что делать при обнаруженном дрейфе ----
# Вариант 1: исправить реальность под код (правильно)
#   ansible-playbook site.yml -i production  # применяем playbook
#   terraform apply                           # применяем план

# Вариант 2: зафиксировать реальность в код (если изменение было намеренным)
#   Обновить playbook/tf-файл, commit, PR, code review
#   terraform import resource_type.name resource_id  # импортируем в state

Зачем это нужно:
Drift detection для Ansible превращает идемпотентность в реальный механизм контроля: если ничего не меняется при запуске — системы соответствуют коду. Terraform использует state file для сравнения желаемого и реального состояния — это его главное преимущество перед Ansible в вопросе дрейфа.

Итог: IaC без регулярной проверки дрейфа — это как бэкап без тестирования восстановления. Выглядит серьёзно, но не работает в нужный момент. Настрой еженедельный отчёт сегодня — это 20 минут работы.

#skills #iac #ansible #terraform #drift #sysadmin #admin_future