Легенды и мифы ИТ #3: Как бы дать так, чтобы не дать

clip_image001Еще одна вечная загадка, встречающаяся мне очень часто: как бы так дать все, чтобы дать не все. Это именно тот вопрос, который я часто вижу на разных форумах. Этот тот самый вопрос, который мне частенько задают лично. Задаётся он в разных формах. Наиболее часто он встречается в следующих формах:

1) Как дать пользователю права локального админа так, чтобы он не мог сделать <придумайте сами, что>?

2) Как мне запретить администратору домена доступ к <очень важной информации>?

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

Для начала: предоставляя пользователю права администратора, Вы даете ему права на управление системой: в этом весь смысл. Что этот пользователь не в состоянии сделать прямо сейчас, на то он может выдать себе права. Точка.

В первом случае, единственная вещь, которую можно сделать, это наладить строгий аудит действий администратора. Причем, собираться и обрабатываться эта информация должна на системе, которая недоступна (я молчу про “управляема”) наблюдаемому пользователю, любой другой вариант типа “я выдам одминские права, но запрещу доступ к подсистеме X” обречен на провал.

Второй случай посложнее, поскольку обсуждаемые системы, как правило, распределенные. И все же, в них можно сделать не сильно больше, чем в предыдущем случае. Снова: жесткий аудит без малейших шансов у администратора поиграться с ним. Есть, конечно, варианты, типа построения изолированной от обсуждаемого администратора системы, которая, скажем, шифрует важные данные. Но это сложно и дорого: ведь система должна быть действительно изолированна: вплоть до отдельного рабочего места для людей, который с этими данными работают. А иначе какой-нибудь pass-the-hash или другой сюрприз и все: данные ушли.

Так что, на самом деле, только аудит может вам помочь против врага в лице администратора. Следовательно, просто не давайте этих прав тем, кто их не заслуживает.

Есть еще идеи?

13 комментариев на “Легенды и мифы ИТ #3: Как бы дать так, чтобы не дать

  1. Serg

    От нормального админа защищаться не нужно, но лишнего давать ему тоже не следет.
    От плохого лучше не думать потому что никакой аудит не спасет от «грамотного» специалиста и фокусов можно насмотреться таких…

    Нравится

    1. Alexander Trofimov Автор записи

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

      Нравится

      1. Serg

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

        Немного маразматично, но вполне работоспособно.
        Главное не допустить перекоса при реализации всяких «действий» которые разрушают то что создано.

        Нравится

  2. Alexander Trofimov Автор записи

    Все правильно, но я же не зря выдал в начале блога формулировки, в которых поступают вопросы. Я даже пару раз пытался в качестве ответа описать схему типа той, которую ты изложил, но в ответ получал «не, ну к чему эти сложности, лучше скажи, как ограничить права доменного администратора» ;)
    Про аудит: все зависит от денег и умений, вложенных аудит. Я видел системы, которые указанными тобой финтами не обойти.
    Ну и понятное дело, что панацеи нет, вопрос только в сложности (стоимости) свершения злонамеренных действий и сокрытия следов.

    Нравится

    1. Serg Marinichev

      Ну да. Финты бывают разные и системы тоже. Тут не поспоришь…
      Другой вопрос что надо четко понимать стоимость защиты и целесообразность, но это уже отдельная публикация и отдельная тема для разговора :)
      PS В черновиках валяется, дописать пока что нет времени.

      Нравится

  3. Mikhael Chernogorsky

    В мелких конторах админ царь и бог. и ничего с этим не сделаешь. Ибо дорого
    В крупных. есть такая стуктура, как СБ. в их ИТ подразделение ставится лог сервер.
    И выдаются только нужные права. Да, так как он админ, то он может их повысить (и это реально иногда нужно, но при этом наследит), а дальше старые добрые не ит методы.

    >> Для начала: предоставляя пользователю права администратора, Вы даете ему права на управление системой: в этом весь смысл. Что этот пользователь не в состоянии сделать прямо сейчас, на то он может выдать себе права. Точка.
    Не совсем так. необходимо делать так, чтобы Мог, но наследил. :_)

    Нравится

  4. Виталий

    По поводу второго вопроса: почему нельзя включить шифрование EFS, а Password Key Recovery агентов выдать учеткам, неизвестным админу? Далее всего лишь вести мониторинг активности Password Key Recovery агентов (а чтобы не появлялось новых — исключить его из группы Enterprice Administrators и мониторить изменение членства в ней). Т.о., администратор не сможет прочитать зашифрованные данные, не имея соответствующего ключа.

    Нравится

  5. Alexander Trofimov Автор записи

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

    Нравится

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s