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

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

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

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

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

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

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

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

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

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

Реклама

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

  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. Выход / Изменить )

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s