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

Выполнение методов WMI через прокси - как защитить учетные данные от доступа пользователей?

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

Другой вариант, который я рассматриваю, - это создание настраиваемого поставщика метода WMI, который будет выполнять соответствующие вызовы WMI для выполнения нужной мне задачи в рамках набора ограничений, которые я хотел бы наложить на технических специалистов с помощью инструмента, который хочет руководство. Затем я просто зарегистрирую этого провайдера на сервере ConfigManager и дам полевым техникам права «Выполнить методы».

Прежде чем я по колено взломаю сервер SCCM моей организации с помощью сумасшедшего нестандартного мусора WMI, который, вероятно, будет сложно изменить или воссоздать моим преемникам, есть ли что-то очевидное, что мне не хватает, что делает это глупым или невозможным? В противном случае, существуют ли какие-либо другие распространенные практики, о которых я не замечаю, которые позволили бы нашим техническим специалистам выполнять задачу по доверенности для выполнения задачи, на выполнение которой у них нет конкретных разрешений?

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

Я постоянно наблюдаю это у компаний; они хотят дать специалистам службы поддержки низкого уровня возможность сбрасывать пароли AD, но не хотят предоставлять им доступ к инструменту RSAT для пользователей и компьютеров Active Directory. В итоге они создают веб-страницу или какое-то приложение для сброса пароля, которое использует учетную запись службы для выполнения работы. Вы можете утверждать, что это снижает поверхность атаки для вредоносных программ (поскольку вам нужно защитить только 1 учетную запись вместо 20 или более), но на самом деле все, что вы делаете, это скрываете информацию, которую гнусный пользователь мог бы получить другими способами. во всяком случае, если они действительно этого хотели.

Суть в том, что вы можете установить консоль SCCM на рабочую станцию ​​технического специалиста, не предоставляя им доступа к самому серверу, и эта консоль полностью защищена. Вы полностью контролируете, кто и что может видеть. Это немного работы, чтобы сделать это правильно, но, конечно, намного меньше работы, чем неподдерживаемый сценарий WMI в стиле Руба Голдберга, о котором вы говорите.

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

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