Написать этот текст меня побудило периодическое появление на Хабре статей администраторов Windows, авторы которых, на мой взгляд, не очень хорошо понимают, что делают. Последний из таких постов — о защите служебных учетных записей.
Прежде всего хочется сказать следующее — уважаемые коллеги, защита учетных записей — хотя и типовая, но ни в коем случае НЕ простая задача, особенно для среднего системного администратора, не являющегося специалистом по информационной безопасности. Если вам повезло и вы попали в организацию, где все регламенты и процессы разработаны до вас — вам, конечно, будет довольно просто воспользоваться плодами чужого труда. Но если всё, что у вас есть на руках — свежеподнятый (или, что ещё хуже, поднятый не пойми кем и как) домен AD и гугл, не стоит подходить к задаче в стиле «прочитаю Best practices, сделаю как там пишут, и всё будет пучком».
В качестве примера, почему любые общие рекомендации надо применять с крайней осторожностью, рассмотрим классический вариант с блокировкой учетных записей по числу неудачных попыток входа, упомянутый в статье выше. Многие необоснованно считают, что Best practice тут — включать блокировку. Это действительно может быть полезной мерой, если вы по каким-то причинам уверены, что злоумышленник сможет узнать имена лишь небольшого количества учеток.
К сожалению, у этого способа есть один недостаток — если злоумышленник получил доступ к списку учетных записей, он сможет заблокировать их все. Здесь, в частности, следует помнить об одной вещи — любая учетная запись в домене AD может отправлять запросы к службе каталогов и по умолчанию имеет права на чтение практически всех её разделов. На практике это значит, что, если злоумышленник узнает логин-пароль хотя бы одного пользователя, он с помощью простого LDAP-запроса сможет получить список ВСЕХ (да, совсем всех) учетных записей в домене. И, если у вас включена политика блокировки учеток, он сможет все их заблокировать. Представьте себе последствия и попробуйте придумать, что вы будете делать, если вас постигнет подобная участь.
К слову, предлагаемый автором вариант решения с автоматической разблокировкой учетки и отправкой сообщения администратору на самом деле не является решением — если на запись действительно ведут атаку перебора паролей автоматизированными средствами, она с высокой вероятностью попросту будет тут же заблокирована снова.
Как можно не выстрелить себе в ногу? Например, задуматься над вопросом, а нужна ли вам вообще блокировка записей, и не лучше ли будет отслеживать неудачные попытки входа сами по себе, благо даже штатными средствами Windows можно повесить алерты на попавшие в Event Log события и обрабатывать эти события так, как вам нужно (а не просто путем «три неудачные попытки — выстрел»). При этом, однако, стоить помнить, что учетка может авторизоваться на любом контроллере домена в сети, и каждый КД надо мониторить отдельно. Можно вспомнить, что в более-менее современных версиях Windows политик безопасности может быть несколько. Следовательно, можно более аккуратно подойти к вопросу, какие учетки блокировать, а какие — нет. В-третьих, можно даже заняться вопросом, которым обычный администратор Windows никогда не занимается, а именно ограничением данных пользователю по умолчанию прав в AD (замечу, что это может иметь смысл и вне контекста защиты именно учеток).
Таким образом, даже одна из наиболее частых и типовых задач для успешного решения (а не видимости решения) требует достаточно внимательного подхода и может потребовать углубления в вопросы, о которых подавляющее большинство администраторов Windows просто не задумывается.
Далее, когда мы переходим к защите служебных (а не пользовательских) учетных записей, автор полагает, что эти записи «не защищены от перебора и с годами не меняемым паролем». Оставим в стороне вопрос с Managed Service accounts — по моему личному опыту мест, где можно их применить, куда меньше, чем мест, где нельзя. Однако необходимо помнить о двух вещах — во-первых, пароли служебных учеток не обязаны соответствовать требованию удобства для человека, и, следовательно, могут быть куда более сильными, во-вторых, в Windows, как ни удивительно, есть средства автоматизации, позволяющие пароли менять — простой пример. Понятно, что автоматизация тут не всегда возможна (и вообще смена пароля в ряде случаев может представлять квест, который совершенно не хочется проходить без крайней необходимости), но, тем не менее, помнить об этом надо.
Автор также упоминает об ограничениях на локальный вход для служебных учеток общей доменной политикой. В некоторых случаях это может быть полезно, однако надо понимать, что запрет на локальный вход может не значить вообще ничего, особенно в весьма часто встречающемся случае, когда служебная учетка обладает расширенными правами в домене или на отдельных компьютерах. Ограничение списка машин, на которые учетка вообще может заходить — вещь более сильная, но применять её надо с крайней осторожностью.
И, разумеется, это далеко не все вопросы, о которых можно поговорить как применительно к критикуемой статье, так и к теме вообще.
Подводя некоторые итоги:
1. Не следует относиться даже к базовым моментам ИБ как к «простому» вопросу. Думайте, и думайте хорошо, особенно если вы — новичок.
2. Иллюзия защищенности, которую может создать следование не слишком хорошо продуманным советам — хуже, чем понимание, что у тебя есть проблема и недостаточно знаний для решения.
3. Если вы хотите писать статью на тему, а не просто делитесь личным опытом в стиле «я сделал так, что вы об этом думаете?» — пожалуйста, как следует изучите тему, по которой пишете. Некомпетентности в мире и так более чем достаточно, не стоит её приумножать, попутно рискуя создать большие проблемы тем, кому вы, по идее, хотите помочь.
Автор: ildarz
