Назад | Перейти на главную страницу

Замена суперпользователя множеством более тонких пользователей (безопасность)

Я оказался в ситуации, когда у меня есть учетная запись суперпользователя, которая может в основном делать все в домене и настроена на запуск запланированных задач, служб Windows и веб-сайтов.

Я унаследовал эту ситуацию (я понимаю, что это очень плохая практика) и мне нужно удалить эту учетную запись суперпользователя и заменить ее учетной записью для каждого приложения.

Итак, моя задача - сначала отобразить

  1. где эта учетная запись используется (например, для запуска службы X на сервере Y)
  2. к каким папкам / файлам он пытается получить доступ

Как только я это нанесу, я создам много учетных записей, у которых будет доступ только к необходимым папкам / файлам.

Например,

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. Надеюсь, ты все же сможешь мне помочь.

Что ж, к сожалению для вас, вы не можете автоматизировать это. Нет ~all the places this account is used функция или атрибут, поэтому получение этой информации требует значительных усилий вручную.

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

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

Пакет SysInternals также очень полезен (в частности, ProcMon и ProcExplorer), если вы пытаетесь отслеживать запущенные в данный момент процессы, а не просто собирать журналы и ждать запуска процесса, и многие другие инструменты будут полезны для устранения того, что все рассматриваемая учетная запись имеет доступ к ... что обычно является хорошим началом в попытке определить, что все это на самом деле делает.

Да, и проверьте запланированные задачи на всех ваших серверах. Возможно, вам повезет и вы обнаружите, что все, что делает эта «учетная запись службы / администратора», осуществляется через запланированные задачи на ваших серверах. (Вряд ли, но вам все равно нужно там проверить.)

Однако, помимо этого, вы действительно вынуждены делать что-то вроде «крик-теста». Найдите сервисы, процессы и сценарии, которые вы можете, переместите их на использование соответствующей учетной записи службы, а затем отключите «учетную запись службы / администратора всего». Смотрите, что ломается. Опять же, ваши журналы должны быть полезны, поскольку все, что все еще пытается использовать учетную запись, будет появляться с проверками отказов в журнале безопасности где-то. Включите учетную запись снова, пока исправляете то, что сломалось. При необходимости повторите. И помните, что некоторые виды использования могут происходить через длительные промежутки времени (например, некоторые задачи обслуживания, которые выполняются раз в месяц), поэтому пройдет некоторое время, прежде чем вы сможете объявить об успехе и оставить все это позади.

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