Временный пароль для администратора домена

Question

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

Computer Associates предлагает систему, которая генерирует ограниченные по времени учетные записи администраторов домена по запросу, с хорошим журналом и всем остальным. Проблема в том, что это очень дорого и определенно не по бюджету.

Я предложил помочь некоммерческой компании, но я не уверен, как сделать это достаточно простым для локального опытного пользователя способом. Итак, что будет простой способ создания одноразовых учетных записей администраторов домена? Я не профессионал, но я могу иметь дело с VBScript, PowerShell или VB.NET.

Большое спасибо за любые указатели.

Answer 1

Администратор домена - администратор домена

Любой, кому вы предоставляете полные права администратора, может делать все, что пожелает, в том числе устанавливать секретный секретный доступ, подделывать журналы аудита, а также получать и копировать данные по своему усмотрению. Лучшее, что вы можете сделать, выпустив временные учетные записи администратора домена, - это создать ложное чувство безопасности для фирмы.

Администратор домена - это самая высокая учетная запись, которая может быть выдана в домене. Он никому не отвечает и не может быть ограничен меньшими или равными аккаунтами. Если вы хотите ограничить его, вам нужно будет использовать более высокий уровень привилегий, чего нет в Active Directory.

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

Answer 2

Я рекомендую создать второго пользователя и предоставить ему только те права, которые ему нужны. Вы можете установить срок действия для этой учетной записи, поэтому вы знаете, что они могут использовать его только до истечения срока действия учетной записи. Если вы боитесь, что они редактируют свою учетную запись, вы можете предотвратить это с помощью групповой политики или вообще не раздавать административный доступ или другими способами ограничить доступ к Active Directory.

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

Кроме того, убедитесь, что кто-то смотрит на плечи ИТ-персонала, если вы действительно боитесь.

Answer 3

powershell [Reflection.Assembly]::LoadWithPartialName('System.Web')^|Out-Null;1..12^|%{[Web.Security.Membership]::GeneratePassword(16,3)}

Если вы предоставляете сервису внутреннюю ИТ-инфраструктуру, у вас нет безопасности. Это вопрос порядочности сторонней сервисной компании.

Проблема в архитектуре операционной системы, которая не обслуживается отдельной системой на уровне ядра и приложениями отдельно, маршрутами и ссылками.

Нет примера такой роли, как "аудитор", пример - Novell Netware, функция "аудитор" выполняет только действия по проверке, но не может вносить какие-либо изменения.

Если вам нужна безопасность, административными учетными записями должны быть только вы.

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

То, что вы хотите, это не безопасность, а игра в безопасности. Потому что командная строка по сути - мгновенное администрирование. Приложение - еще быстрее. Сколько миллисекунд вы хотите предоставить административным привилегиям другой стороне? )))

Answer 4

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

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

Конечно, он не должен знать, где находится сценарий, или в этом отношении, что сценарий вообще существует.