Построение безопасной инфраструктуры в компании обычно подразумевает разделение ресурсов по нескольким зонам безопасности, которые управляются разными администраторами (или, по крайней мере, одними и теми же администраторами, но под разными учётными записями). Например, можно выделить серверы с важными данными, такие как центры сертификации PKI, хостовые машины Hyper-V или машины содержащие персональные данные, и определить их как «Зона 1». Остальные серверы можно обозначить как «Зона 2». Разрешения настраиваются таким образом, чтобы в каждой зонае были свои собственные локальные администраторы, логоны пользователей между зонами — запрещаются (кроме сетевого входа в систему — он обычно не несёт рисков безопасности).
В идеальном мире, для обслуживания каждой зоны безопасности используется своя собственная выделенная инфраструктура, но в реальной жизни не всегда возможно изыскать дополнительные ресурсы для полноценной поддержки инфраструктуры и приходится идти на компромисы. В таком случае, обслуживающие серверы, в т.ч. серверы резервного копирования, логично разместить в более доверенной зоне (зоне 1) — таким образом более защищённые серверы будут получать доступ к менее защищённым, но не наоборот.
Что это означает для SCDPM? DPM не предназначен для резервного копирования между зонами безопасности, но мы можем его заставить.
После того, как вы установили агент SCDPM на сервер в зоне 2, вы должы прикрепить его к серверу SCDPM в зоне 1. На этом шаге, пользователи, под которым вы прикрепляете агента, должен быть локальным администратором одновременно и на сервере, и на клиенте. В зонированной инфраструктуре это невоможно, т.к. одна учётная запись не может быть локальным администратором на машинах в двух разных зонах.
Что же делать? Придётся предоставить необходимые разрешения гранулированно:
Шаг 1
Мы должны предоставить для администратора зоны 1 следующие разрешения на корень WMI на сервере из зоны 2:
- Enable
- MethodExecute
- RemoteAccess
- ReadSecurity
Вы можете назначить эти разрешения через графический интерфейс (wmimgmt.msc) или через PowerShell.
Если вы выберете PowerShell, используйте эту версию сценария Set-WmiNamespaceSecurity.ps1. В этой версии исправлено назначение наследований разрешений — оригинальный сценарий Стива Ли падает с ошибкой «Invoke-WmiMethod : Invalid parameter».
Запустите сценарий на клиенте из зоны 2 с такими параметрами:
Set-WmiNamespaceSecurity.ps1 -namespace 'root' -operation 'add' -account 'EXAMPLE\tier1-admin' -permissions 'Enable','MethodExecute','RemoteAccess','ReadSecurity' -allowInherit $true
При назначении разрешений через графический интерфейс, они должны выглядеть так:
Шаг 2
Второй шаг немного контр-интуитивный: Как известно, сервер SCDPM запрашивает с агента его часовой пояс и сохраняет в своей базе. Почему-то, назначение разрешений из шага 1 не даёт не-администратору возможность удалённо запросить эти данные. В качестве обходного пути, выполните вот такой запрос к WMI на клиенте SCDPM: select * from Win32_TimeZone. После этого, не-администратор в течение некоторого времени сможет запрашивать часовой пояс удалённого компьютера.
Команда PowerShell для этого:
Get-WmiObject -Query 'select * from Win32_TimeZone'
После выполнения этих двух шагов, у вас должно получиться успешно добавить агента из зоны 2 на сервер SCDPM в зоне 1. После этого, вы можете отозвать только что выданные разрешения: Set-WmiNamespaceSecurity.ps1 -namespace root -operation delete -account 'EXAMPLE\tier1-admin'