Замена суперпользователя многими мелкозернистыми пользователями (безопасность)
Я нахожусь в ситуации, когда у меня есть учетная запись суперпользователя, которая в основном может делать все в домене и настроена для запуска запланированных задач, служб Windows и веб-сайтов.
Я унаследовал эту ситуацию (я понимаю, что это очень плохая практика) и должен удалить эту учетную запись суперпользователя и заменить ее учетной записью для каждого приложения.
Поэтому моя задача - сначала карта
- где используется эта учетная запись (например, для запуска Service X на сервере Y)
- к каким папкам / файлам он пытается получить доступ
После того, как я это сопоставлю, я создам много аккаунтов, которые имеют доступ только к необходимым папкам / файлам.
Например,
Super account runs windows service X on server Y and writes to folder Z
windows service A on server B and write to folder C
Заменяется
New Account 1 runs windows server X and has write access to folder Z
New Account 2 runs windows server A and has write access to folder C
В домене есть много серверов (более 20), которые необходимо проверить, поэтому мой конкретный вопрос заключается в том, как это автоматизировать.
Я разработчик, поэтому немного зелен, когда дело касается задач сисадмина. Я хотел получить хорошую награду за этот вопрос, но не могу передать свою репутацию stackoverflow. Надеюсь, вы все равно можете мне помочь.
1 ответ
Ну, к сожалению для вас, вы не можете автоматизировать это. Там нет ~all the places this account is used функции или атрибута, поэтому для получения этой информации требуется много усилий.
Журналы событий могут быть полезны, как правило, с помощью ведения журнала на уровне аудита, который может быть установлен для отдельных файлов и папок, а также для событий входа в учетную запись, и оба могут быть установлены с помощью групповой политики (так что вам не нужно делать изменения в каждой системе, которую вы хотите отслеживать). В этом отношении почти все может быть настроено на ведение журналов на уровне аудита, но активность входа в систему и доступ к файлам / папкам, как правило, наиболее полезны из отслеживания того, где используется вся данная учетная запись.
Если вы действительно хотите упростить свою жизнь, после настройки политик ведения журналов настройте пересылку событий, чтобы все интересующие вас события пересылались в одно место (чтобы вам больше не приходилось искать их на каждом сервере отдельно).).
Пакет SysInternals также очень полезен (в частности, ProcMon и ProcExplorer), если вы пытаетесь отслеживать текущие запущенные процессы, а не просто собираете журналы и ожидаете запуска процесса, а многие другие инструменты будут полезны при установке вниз к тому, к чему имеет доступ весь рассматриваемый аккаунт... который обычно является хорошим началом в попытке определить, что все это делает на самом деле.
Да, и проверьте запланированные задания на всех ваших серверах. Возможно, вам повезет и вы обнаружите, что все, что делает эта "вся учетная запись службы / администратора", - это выполнение запланированных задач на ваших серверах. (Маловероятно, но вам все равно нужно проверить.)
Кроме того, вы действительно вынуждены делать что-то вроде "теста на крик". Найдите службы, процессы и сценарии, которые вы можете, перенесите их на работу с соответствующей учетной записью службы, а затем отключите "все службы / учетной записи администратора". Посмотрите, что ломается. Опять же, ваши журналы должны быть полезны, так как все, что все еще пытается использовать учетную запись, будет где-то всплывать с проверками ошибок в журнале безопасности. Включите учетную запись снова, пока вы исправите все, что сломалось. Повторите по мере необходимости. И помните, что есть вероятность того, что некоторые варианты использования будут происходить через длительные промежутки времени (например, некоторые задачи обслуживания выполняются раз в месяц), поэтому пройдет некоторое время, прежде чем вы сможете объявить об успехе и оставить все это позади.
Если это звучит как трудоемкая боль в заднице, это потому, что это так. На вашем месте я бы использовал его, чтобы убедить начальника нанять / нанять младшего администратора для выполнения этой работы за меня, а также в качестве аргумента того, почему необходимы надлежащие стандарты и действительные администраторы. В действительности очень мало смысла в том, чтобы старший ресурс или ресурс разработки (с их высокой эффективной почасовой оплатой труда) выполняли такие виды чтения журналов и базовые административные вещи, которые в принципе любой может сделать за 10 долларов в час.