Я работаю в команде из 10 разработчиков. У нас есть настроенные серверы, которые выполняют резервное копирование, автоматическую сборку программного обеспечения, автоматическое развертывание и многое другое. Некоторые из этих серверов содержат полезный материал, например данные для входа в производственные системы (которые необходимы для автоматического развертывания).
Мы хотим ограничить круг лиц, имеющих доступ к этим машинам, чтобы снизить риск случайной утечки паролей. Для этого мы создали группу в Active Directory, состоящую из 4 человек, которым разрешен доступ к серверам, содержащим конфиденциальные материалы, и убедились, что только эти 4 пользователя могут войти в систему.
Некоторые из этих серверов запускают запланированные задачи и службы Windows для выполнения резервного копирования / развертывания. Эти задачи / службы запускаются под определенной «общей» учетной записью пользователя, назовем ее «buildacc». Причина в том, что для выполнения задач требуется доступ к общим ресурсам в сети для выполнения сборки / развертывания. Таким образом, мы также предоставили этому пользователю доступ к серверам.
Чтобы иметь возможность изменять запланированные задачи в Windows, все 4 разработчика должны иметь доступ к этой учетной записи buildacc, что означает, что все они должны знать общий пароль и сообщать друг другу, когда он изменился, что нам не нравится. оф.
Мы рассмотрели возможность использования личных учетных записей для выполнения запланированных задач, таких как сценарий построения. Обратной стороной является то, что любой член команды может изменить сценарий сборки и заставить его делать что-то новое под учетной записью пользователя, который настроил фактическую запланированную задачу.
Есть ли какие-нибудь передовые методы решения этой ситуации?
В целом то, что вы сделали заранее, нормально. Выделенная учетная запись в стиле «службы», которая настроена с необходимыми разрешениями и используется для выполнения запланированных задач.
На этом этапе все, что вам действительно нужно сделать, это:
buildaccНа данный момент это действительно вопрос внутренней политики. Вы должны настроить запланированные задачи так, чтобы они не менялись. Это означает, что если он запускает "test.exe", разработчики должны изменить этот exe-файл, но не саму запланированную задачу. Если всем четверым разработчикам действительно нужен доступ для изменения запланированных задач, тогда вы просто застряли там, где находитесь ...
РЕДАКТИРОВАТЬ: Я бы также предупредил вас, чтобы вы слишком либерально относились к своим buildacc учетная запись через службы и серверы Лучше сохранить его строго для «сборок» и иметь резервные копии и другие службы, работающие под их собственными выделенными учетными записями.
Предполагая, что вы используете систему Windows 2008R2 и AD 2008R2, вы можете использовать для этого управляемую учетную запись службы.
Эта запись в блоге technet содержит довольно хорошее описание того, как использовать управляемые учетные записи служб, но вот основные принципы:
Учетная запись управляемой службы - это учетная запись AD, которая прочно привязана к компьютеру и имеет автоматически управляемый пароль. Вы не создаете пароль, и никто не должен о нем знать, но, поскольку это учетная запись AD, вы можете использовать ее для сетевых списков контроля доступа, что делает его идеальным для вашего сценария.
Однако использование MSA для запланированной задачи потребует от вас использования командной строки для создания задач (см. этот и этот нить для более подробной информации).
Я вижу несколько ответов, в которых MSA упоминается как решение для учетной записи, используемой для запуска запланированной задачи, но, как упоминал автор этого сообщения, они используют Windows Server 2008 R2 и, согласно моим исследованиям, MSA в этой ОС не может использоваться для выполнения запланированных задач.
Однако в Windows Server 2012 gMSA (групповая управляемая учетная запись службы) может использоваться для запуска запланированных задач, как описано в этом статья.