На страже безопасностиСубъекты и участники безопасности

Йеспер М. Йоханссон (Jesper M. Johansson)

Cодержание

Набор субъект/объект/действие
Типы участников безопасности
Службы
Заключение

На самом базовом уровне все в безопасности можно свести к субъектам и объектам. Объекты – это то, что мы защищаем, а субъекты – то, от чего мы защищаем объекты. Эти две конструкции используются в проверке подлинности (удостоверении своей личности), авторизации (предоставлении доступа к чему-либо) и аудите (отслеживании кто получил доступ к чему). В основе своей эти концепции очень просты, как показано на рис. 1.

Рис. 1. Пользователь пытается прочесть файл

Субъекты – это то, что выполняет действие, а объекты – это то, с чем выполняется действие. Кроме того, порой объекты, с которыми что-то делают субъекты, тоже являются субъектами.

Когда речь идет о безопасности, Windows поддерживает ряд чрезвычайно богатых семантик и намного расширила определения субъектов и объектов. Субъектом может быть далеко не только пользователь и его представление гораздо сложнее простого идентификатора пользователя.

В терминах Windows к участникам безопасности относятся не только типичные субъекты (о которых можно думать, как о пользователях), но также группы и компьютеры. Участник безопасности – это все, чему можно выделить идентификатор безопасности и дать разрешение на доступ к чему-нибудь.

В этом выпуске рубрики «На страже безопасности» я даю введение в то, как субъекты представляются и используются в Windows.

Набор субъект/объект/действие

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

Регистр имеет значение

В литературе Windows, когда слова «Администратор» или «Администраторы» употребляются с заглавной «А», они обычно относятся к пользователю или группе соответственно. Когда все слово написано строчными буквами («администратор»), оно относится к какой-нибудь учетной записи пользователя или личности, имеющей административные права. То же самое касается других сущностей, таких как «Гость» и «гость».

Типы участников безопасности

Субъекты (или участники безопасности, как я буду называть их далее) в системе на основе Windows и, соответственно, в сети на основе Windows, могут быть не только пользователями. Однако пользователь остается наиболее базовой концепцией.

Пользователи Пользователь – это некая определенная сущность, входящая в систему на компьютере. В конечном счете, все участники безопасности имеют хоть какое-то отношение к пользователям. В Windows существуют два типа пользователей: локальные и доменные. Локальный пользователь определяется в локальной базе данных диспетчера учетных записей безопасности (SAM) на компьютере. У каждого компьютера на основе Windows имеется локальный SAM, содержащий всех пользователей на данном компьютере.

Часто считается, что у контроллеров доменов (DC) нет локального SAM и, следовательно, локальных пользователей. Это мнение ошибочно. Даже у DC есть локальный SAM, но учетные записи в его SAM могут быть использованы только в режиме восстановления службы каталогов.

Локальный SAM всегда содержит минимум две учетные записи пользователя: «Администратор» и «Гость», причем последняя всегда отключена по умолчанию.

На всех версиях Windows Server 2008 (за исключением Windows Small Business Server 2008), учетная запись администратора по умолчанию включена и ее необходимо использовать при первом входе в систему. На Windows Vista она по умолчанию отключена и может быть использована только в очень ограничивающих обстоятельствах.

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

Все пользователи, кроме локальных, являются доменными Эти пользователи определены в контроллерах (DC) для домена. Различие между локальными и доменными учетными записями заключается, в первую очередь, в их охвате. Доменные учетные записи могут быть использованы на любом компьютере в домене, тогда как локальные учетные записи действительны только на компьютере, на котором определены. Кроме того, с доменными учетными записями может быть связано заметно большее число свойств, по сравнению с локальной учетной записью (см. рис.и 2 и 3 для сравнения).

Рис. 2. Окно свойств для локальной учетной записи

Рис. 3. Окно свойств для доменной учетной записи

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

Компьютеры Компьютер – просто еще один тип пользователя. В Active Directory это особенно верно и подкрепляется моделью наследования. Структура наследования, ведущая к компьютеру, обрисована на рис. 4.

Рис. 4 Иерархия наследования в Active Directory показывает отношения пользователей и компьютеров

На рис. 4 проиллюстрировано несколько очень интересных вещей. Во-первых, как можно увидеть, все классы в Active Directory происходят от корневого класса, именуемого Top («Начало»). На самом деле, даже Top считается подклассом Top. Во-вторых, класс User производится от класса organizationalPerson. В третьих (и это наиболее интересный момент), класс Computer производится от подкласса User. Другими словами, в объектно-ориентированной терминологии компьютер является типом пользователя. Антропоморфизация компьютеров таким способом, однако, вполне имеет смысл, поскольку компьютеры также считаются субъектами и имеют почти все те же атрибуты, что и живой пользователь.

Группы Как читатели могут вспомнить, субъект – это нечто, пытающееся получить доступ к объекту. Операционная система проверяет эту попытку доступа путем проверки разрешений на объекте. Очень давно разработчики ОС осознали, что выделять разрешения на каждый объект каждому пользователю, которому он нужен, будет неразумно. Чтобы решить эту проблему, разработчики разрешили пользователям быть членами групп. Это позволяет назначать разрешения группам, вместо пользователей.

Группа может и не быть пользователем, но группа остается типом участника безопасности, поскольку она может иметь идентификатор, подобно пользователям и компьютерам. В Windows пользователь может быть членом многих групп, и у объекта могут быть выделены разрешения для многих групп. Вложенные группы также допустимы – с некоторыми ограничениями.

Недоменный контроллер имеет только два типа групп, встроенные группы и локальные группы, которые определил администратор. Но Active Directory можно найти шесть различных видов групп безопасности: встроенные локальные группы домена, встроенные глобальные группы, встроенные универсальные группы, определенные пользователем локальные группы домена, определенные пользователем глобальные группы и определенные пользователем универсальные группы.

Локальным группам домена можно выделять лишь разрешения на ресурсы внутри домена, где они определены. Однако они могут содержать пользователей, универсальные и глобальные группы из любого доверенного домена или леса и локальные группы домена из их собственного домена.

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

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

Хотя по умолчанию на рабочей станции есть только две группы («Администраторы» и «Гости»), в домене имеется относительно большое их число, всех трех типов. На рис. 5 показаны группы по умолчанию в домене. Все они обозначены как группы безопасности, а это значит, что им можно назначать разрешения. (Группы безопасности не стоит путать с группами рассылки, используемыми Microsoft Exchange Server для группировки пользователей в списки электронной рассылки. И те, и другие определяются в Active Directory.) Локальные группы, существующие на всех компьютерах, работающих на Windows, определены в Active Directory на DC.

Рис. 5. Группы по умолчанию определены в контейнере Users («Пользователи») в Active Directory

Как и в случае контроллеров доменов (DC), некоторые компьютеры, не являющиеся ими, также имеют большое число групп. На рис. 6 показаны 16 встроенных групп на тестовом компьютере. Точное число групп на любом конкретном компьютере будет различаться в зависимости от установленных на нем ролей.

Рис 6. Встроенные группы на компьютере, не являющемся контроллером домена (щелкните изображение, чтобы увеличить его)

Если вы попытаетесь назначить разрешения объекту, можно будет найти еще больше групп, чем я пока что показал. В реальности на базовом контроллере домена можно найти не менее 63 групп и встроенных участников безопасности, показанных на рис. 7.

Многие из 63 групп, показанных на рис. 7, являются абстрактными концепциями, порой известными как «специальные учетные данные», представляющими динамическую группу участников безопасности. Порой их также именуют группами входа в систему.

Группы входа в систему Группы входа в систему – это группы, представляющие какой-либо динамический аспект участника безопасности, например то, как пользователь или другой участник вошел в систему. Например, группа INTERACTIVE, показанная на рис. 7 включает в себя всех пользователей, вошедших через консоль компьютера и через службы терминалов. Группа NETWORK, напротив, включает в себя всех пользователей, вошедших через сеть. По умолчанию пользователь может состоять лишь в одной из этих групп за раз и членство в них назначается во время входа в систему. Эти группы можно использовать для выдачи разрешений всем пользователям, входящим определенным способом, но нельзя контролировать, кто станет членом этих групп.

Рис. 7. Базовый контроллер домена имеет не меньше 63 групп и встроенных участников безопасности

Существуют и другие группы такой природы. Отдельно можно отметить группу Everyone («Все») и группу Authenticated Users («Проверенные пользователи»). Группа Everyone включаета себя, как предполагает имя, каждого пользователя, получающего доступ к компьютеру – за исключением, начиная с Windows XP, полностью анонимных, непроверенных пользователей. Другими словами, печально известный пользователь NULL не входит в группу Everyone на любой поддерживаемой операционной системе на основе Windows. Гости входят, однако.

Группа Authenticated Users тоже заполняется динамически, но включает в себя только пользователей, подлинность которых проверена. Таким образом, гости в нее не попадают. Это единственное различие между двумя группами. Но, поскольку единственная гостевая учетная запись, существующая на операционной системе, отключена, между Authenticated Users и Everyone нет практической разницы, если не включить учетную запись Guest («Гость») вручную, в каковом случае, вероятно, гости должны иметь возможность доступа к ресурсам, следовательно, группа Everyone должна остаться целой.

Несмотря на это, многие переводчики потратили немало нервов благодаря тому, что «все на свете имеют разрешения на моем сервере», и приняли весьма радикальные шаги для изменения разрешений с целью исправления этой ситуации. Обычно эти изменения влекли за собой совершенно катастрофические результаты. Совершенно нет причин заменять разрешения для Everyone на Authenticated Users. Либо гостям следует иметь разрешения на доступ к компьютеру, и тогда гостевая учетная запись включается, либо нет, – и тогда она отключается. Если нужно, чтобы гости имели разрешения, нужны разрешения для Everyone. Если нет, группа Everyone не будет отличаться от Authenticated Users.

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

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

Также следует указать на различие между встроенной группой Users и Authenticated Users. Различие состоит в достаточно очевидном факте того, что группа Authenticated Users включает в себя каждого пользователя, удостоверившего свою подлинность на компьютере, включая пользователей в различных доменах, пользователей, являющихся членами иных локальных групп, чем Users и пользователей, вовсе не входящих в группы (да, такие бывают). Это значит, что группа Users намного, намного более ограничивающая, чем Authenticated Users.

Несмотря на это, я видел, как организации разрушали свои сети, пытаясь заместить разрешения для Users разрешениями для Authenticated Users, в попытке «укрепить свои системы». Я вел бесконечные споры с невежественными аудиторами PCI/DSS, утверждающими, что отрасль платежных карт требует замены всех разрешений для Users на Authenticated Users. Это просто неверно.

Мне также приходилось защищать организации по всему миру от консультантов, похоже, считающих полную замену списка управления доступом отличным способом накрутки оплачиваемых часов. Нечего и говорить, что любые попытки полной замены Users или Everyone на Authenticated Users не должны принести особых успехов как в плане безопасности, так и стабильности.

Службы

Windows Vista и Windows Server 2008 поддерживают один новый тип участника безопасности: службу. Чтобы осознать, насколько ценны эти сущности, вспомните идущие споры по использованию брандмауэров на узлах. Многие люди, которых с энтузиазмом поддерживают поставщики, продающими продукты, утверждают, что брандмауэры на узлах должны фильтровать исходящий трафик, чтобы иметь значение, поскольку это защищает остальную сеть от зараженного компьютера. Более объективные умы указывают, что, если компьютер заражен, то уже находящаяся на нем вредоносная программа имеет возможность обойти или полностью отключить брандмауэр на узле.

Чтобы понять, почему это так, рассмотрим две службы, работающие как один и тот же участник безопасности. Службе А позволено сообщение через брандмауэр, службе Б нет. Если безопасность службы Б нарушена, взломщик может обойти это ограничение, взяв под контроль другой процесс, работающий как этот участник безопасности, например службу А, и передавать все, что нужно, через этот процесс.

Чтобы решить эту проблему, корпорации Майкрософт был нужен способ применять разрешения к процессу, а конкретнее к службе. С этой целью службы стали собственными участниками безопасности. Как следствие, у каждой службы теперь есть идентификатор, который можно использовать для применения к нему разрешений. Из командой строки можно выполнить команду "sc showsid", чтобы увидеть SID службы в любой момент.

С помощью идентификаторов безопасности служб можно ограничить доступ к ресурсам для конкретного процесса, а не только для конкретных пользователей. Это делает фильтрацию исходящих с помощью брандмауэра на узле осмысленной, в некоторых ситуациях. Объяснение, что именно это за ситуации выходит за рамки данной статьи, но тем, кто заинтересован в том, чтобы прочесть об этом больше, я рекомендую мою статью о брандмауэре Windows Vista написанную для номера журнала TechNet Magazine за июнь 2008 года (см. «Управление брандмауэром Windows Vista»).

Заключение

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

Эта статья основана на материале моей книги Windows Server 2008 Security Resource Kit (изд-во Microsoft Press).

Йеспер М. Йоханссон является старшим архитектором безопасности для хорошо известной компании Fortune 200, работающим над концепцией безопасности на основе рисков и стратегией безопасности. Он также является пишущим редактором журнала TechNet Magazine. Его работа заключается в обеспечении безопасности одной из наиболее крупных и распределенных систем в мире. Он имеет докторскую степень по информационным системам управления, обладает более чем 20-летним опытом в области безопасности и званием наиболее ценного специалиста (MVP) Майкрософт по безопасности предприятий. Его последняя книга – Windows Server 2008 Security Resource Kit.