Windows BackupRead / BackupWrite и списки контроля доступа

Думаю, вы правильно понимаете проблемы с резервным копированием и восстановлением данных. Я считаю, что правильное понимание проблемы - это половина ее решения. Я полагаю, что вы, как и большинство пользователей сайта stackoverflow, в основном разработчик программного обеспечения, а не администратор большой сети. Таким образом, вы видите проблему с другой стороны разработчика программного обеспечения, а не со стороны администратора. Администратор знает ограничения резервного копирования и восстановления ACL и уже использует их.

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

В большинстве случаев резервные копии данных содержат идентификаторы безопасности групп домена, идентификаторы безопасности пользователей домена, известные идентификаторы безопасности или псевдонимы SID из домена BUILTIN в дескрипторах безопасности. В этом случае менять SID вообще не нужно. Если администратор внесет некоторые изменения в ACL, он сможет использовать различные существующие утилиты, например SubInACL.exe.

Если вы пишете программу резервного копирования / восстановления, которую хотите использовать для перемещения данных с информацией о безопасности, вы можете включить в резервную копию некоторую дополнительную метаинформацию о локальных SID учетных записей / групп, используемых в сохраненной безопасности. дескрипторы. В программе восстановления вы можете предоставить возможность замены идентификаторов безопасности из сохраненных дескрипторов безопасности. Много лет назад я написал для одного крупного клиента несколько утилит для очистки SID в SD в файловой системе, реестре и службах после миграции домена. Это было не так уж и сложно. Поэтому я предлагаю вам реализовать ту же функцию в своем программном обеспечении для резервного копирования / восстановления.

Я действительно считаю, что API резервного копирования * в первую очередь предназначены для резервного копирования и восстановления на одной и той же машине, что сделает проблему SID несущественной. Однако, предполагая сценарий, в котором вам нужно восстановить резервную копию при новой установке, вот мои мысли о решениях.

Для известных идентификаторов безопасности, таких как «Все», «Владелец-создатель» и т. Д., Проблем нет.

Для идентификаторов безопасности, зависящих от домена, вы можете сохранить их как есть, а после восстановления вы можете исправить часть домена, если это необходимо. Вероятно, вам следует сохранить доменное имя для таких SID.

Для локальных пользователей и групп вы должны как минимум хранить имя пользователя / группы для каждого SID. Исправление при восстановлении может быть частично автоматическим на основе этих имен или вручную (при условии пользовательского интерфейса для приложения), когда вы спрашиваете пользователя, хочет ли он сопоставить этого пользователя с новым локальным пользователем, преобразовать эти SID в хорошо известный SID , или оставить как есть.

Большинство проблем, связанных с такими SID, можно (и, вероятно, обычно) можно решить автоматически. Я определенно был бы признателен за приложение резервного копирования, которое было бы достаточно умным, чтобы выполнить восстановление, о котором я его просил, и выяснить, что «Эрик» на старой машине должен быть «Эрик» на новой машине.

И побочное примечание: если вы все же решите использовать такое решение, помните, как раздражает запуск передачи данных в ночное время, чтобы вернуться к чему-то 5% -ному блокированию во всплывающем окне, которое можно так же легко отложить :)