ISSP \ Домен 02. Управление доступом. Часть 5

В этой части рассмотрены следующие вопросы:

• Авторизация
• Критерии доступа
• Отсутствие доступа «по умолчанию»
• Принцип «необходимо знать»
• Единый вход
• Kerberos
• SESAME
• Домены безопасности
• Службы каталогов
• Тонкие клиенты

3.2. Авторизация

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

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

Критерии доступа

Мы подошли к основам управления доступом. Субъект может иметь очень детализированные права доступа к объекту или ресурсу. Это хорошо для сетевых администраторов и специалистов по безопасности, т.к. они хотят иметь максимальный контроль над ресурсами, а высокая детализация настройки прав доступа позволяет предоставить пользователям в точности те права, которые им необходимы. Однако существуют системы и приложения, в которых отсутствуют детальные настройки прав доступа, что вынуждает администратора предоставлять всем пользователям полные права доступа. Это не обеспечивает какой-либо защиты.

Предоставление прав доступа субъектам должно быть основано на уровне доверия этому субъекту компанией и на принципе «необходимо знать» (need-to-know). Только тот факт, что компания полностью доверяет пользователю, еще не означает, что ему «необходимо знать» содержимое всех ресурсов компании. И, наоборот, если пользователю «необходимо знать» определенные файлы, которые нужны ему для работы, это не означает, что компания доверяет ему доступ ко всем остальным файлам. Эти вопросы должны быть определены и включены в критерии доступа (access criteria). Различные критерии доступа могут определяться ролями, группами, местонахождением, временем и типами транзакций.

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

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

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

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

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

Отсутствие доступа «по умолчанию»

Механизмы управления доступом следует настроить таким образом, чтобы «по умолчанию» доступ ни к каким ресурсам не предоставлялся («no access»). Это позволит избежать многих незаметных «дыр» в безопасности. В операционных системах и приложениях существуют многочисленные варианты прав доступа, которые могут быть предоставлены пользователям и группам, например, «чтение», «запись», «удаление», «полный доступ», «нет доступа». Пока пользователю не предоставлены права индивидуально или пока он не включен в какую-либо специальную группу, у него не должно быть никаких прав доступа к ресурсам, т.е. пользователю должен быть запрещен доступ ко всем ресурсам, кроме тех, к которым он явно разрешен. Другими словами, все управление доступом должно быть основано на концепции старта с нулевым доступом и добавления прав по мере необходимости в соответствии с принципом «необходимо знать».

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

«Расползание прав доступа». Сотрудники работают в компании долгое время и переходят из одного подразделения в другое, получая при этом все больше и больше прав доступа и полномочий. Часто это называют «расползанием прав доступа» (authorization creep). Это может быть большим риском для компании, т.к. в результате слишком многие пользователи имеют слишком привилегированный доступ к активам компании. Администраторам гораздо проще предоставить пользователям излишние права доступа, чем недостаточные, т.к. в этом случае пользователи не возвращаются с претензиями и не просят администратора еще поработать над их профилем. К тому же часто очень трудно определить точный перечень прав доступа, необходимых конкретному человеку. Именно поэтому управление пользователями и инициализация пользователей стали больше превалировать в современных продуктах управления идентификацией, и по этой же причине компании переходят к реализации ролевого управления доступом.
Одной из важных задач является обеспечение минимума привилегий для учетных записей пользователей, чтобы убедиться, что компания не подвергает сама себя излишнему риску. Для этого следует провести полный пересмотр имеющихся прав доступа и привилегий пользователей. Целесообразно совместить это с процессами, вызванными введением новых требований регуляторов. Например, одним из требований SOX является пересмотр руководителями прав доступа их сотрудников на ежегодной основе.

Принцип «необходимо знать»

Принцип «необходимо знать» (need-to-know) похож на принцип наименьших привилегий (least-privilege). Принцип «необходимо знать» говорит о том, что человек должен иметь доступ только к той информации, которая ему совершенно необходима для выполнения своих должностных обязанностей. Предоставление излишних полномочий ведет к излишним проблемам и, вероятно, злоупотреблениям. Руководство должно решить, что пользователь должен знать или какие права доступа ему необходимы, а администратор должен настроить механизмы управления доступом таким образом, чтобы пользователь имел минимальный набор необходимых ему прав доступа, достаточный для выполнения пользователем своих обязанностей, и не более того.

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

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

Единый вход

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

В связи с распространением клиент-серверных технологий, сети мигрируют с централизованно управляемой среды в гетерогенную, распределенную среду. Распространение открытых систем и разнообразие приложений, платформ, операционных систем ведет к тому, что пользователю нужно помнить несколько наборов учетных данных для получения доступа и использования различных сетевых ресурсов. Хотя различные идентификаторы и пароли теоретически повышают уровень безопасности, на практике они чаще ведут к нарушениям безопасности (потому что пользователи не могут запомнить много паролей, пишут их на стикерах и приклеивают к монитору) и существенно повышают нагрузку на персонал, занимающийся управлением и поддержкой сети. Сотрудниками служб технической поддержки теряется очень много времени и ресурсов на сброс забытых пользователями паролей. Забытые пароли часто сказываются на продуктивности работы не только самого пользователя, но и на выполнении бизнес-процессов, в реализации которых этот пользователь участвует. Системные администраторы вынуждены управлять множеством учетных записей пользователя на различных платформах, координируя эту деятельность для обеспечения целостности политики безопасности. С возрастанием сложности этих работ, растет число недостатков в управлении правами доступа, а вместе с ними растет и число уязвимостей. Таким образом, дополнительные пароли чаще всего не ведут к дополнительной безопасности.

Повышение стоимости поддержки различных сред, соображения безопасности, пожелания пользователей – все вместе они привели к идее создания возможностей единого входа (SSO – single sign-on). SSO позволяет пользователям вводить свои учетные данные только один раз для получения возможности доступа ко всем ресурсам, что уменьшает время, которое пользователи тратят на процесс аутентификации. Также это позволяет администраторам рационализировать использование учетных записей и лучше управлять распределением прав доступа. SSO повышает безопасность, снижая вероятность того, что пользователь будет хранить свой пароль под клавиатурой – ведь теперь ему нужно запомнить гораздо меньше паролей (в идеале – один). Помимо этого, на повышение безопасности оказывает влияние и тот факт, что администраторы больше времени могут тратить на управление учетными записями и правами доступа пользователей, а не на сброс забытых ими паролей. Используя SSO, администратору проще приостановить или заблокировать учетную запись пользователя, т.к. нет необходимости делать это в каждой системе.

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

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

Kerberos

Kerberos (Цербер) – это имя трехголовой собаки в греческой мифологии, которая охраняла вход в подземный мир. Этим именем названа технология безопасности, которая реализует функции аутентификации и защищает активы компании. Kerberos – это протокол аутентификации, разработанный в середине 1980-х годов, как часть Проекта Афина MIT. Он работает на базе модели клиент-сервер и основан на криптографии с симметричным ключом. Этот протокол годами использовался в системах Unix, а в настоящее время применяется как стандартный метод аутентификации в современных серверных операционных системах Microsoft Windows. Операционные системы Apple Mac OS X, Sun Solaris и Red Hat Enterprise Linux также используют аутентификацию Kerberos. Все чаще появляются коммерческие продукты, поддерживающие Kerberos.

Kerberos – это пример системы SSO для распределенных сред и стандарт «де-факто» для гетерогенных сетей. Kerberos объединяет широкий круг технологий безопасности, предоставляя компаниям больше гибкости и масштабируемости при создании архитектуры безопасности. Он имеет четыре элемента, необходимые для корпоративного управления доступом: масштабируемость, прозрачность, надежность и безопасность. Однако эта открытая архитектура имеет некоторые проблемы совместимости. В основном они связаны с тем, что производители пользуются свободой настройки протокола, и каждый из них настраивает его по-своему, что и вызывает эти проблемы.

Kerberos использует криптографию с симметричным ключом и обеспечивает «сквозную» (end-to-end) безопасность. Хотя Kerberos использует пароли для аутентификации, он спроектирован таким образом, чтобы исключить необходимость передачи паролей по сети. Большинство реализаций Kerberos работает с общими секретными ключами.

Основные компоненты Kerberos

Центр распространения ключей (KDC – Key Distribution Center) – это самый важный компонент в среде Kerberos. Он хранит секретные ключи всех пользователей и служб. KDC реализует службу аутентификации и функции распространения ключей. Клиенты и службы доверяют целостности KDC, это доверие является основой безопасности Kerberos.

KDC предоставляет сервисы безопасности системным объектам (principal), которые могут быть пользователями, приложениями или сетевыми службами. KDC должен иметь учетную запись для каждого системного объекта и общий секретный ключ с каждым системным объектом. Для пользователей пароли преобразуются в значение секретного ключа. Секретный ключ используется для передачи критичной информации между системным объектом и KDC, а также для аутентификации пользователя.

Служба предоставления билетов (TGS – Ticket Granting Service) на KDC генерирует и передает системному объекту (например, пользователю) билет (ticket), когда ему нужно аутентифицироваться на другом системном объекте (например, сервере печати). Предположим, что Эмили нужно воспользоваться сервером печати. Для этого она должна доказать серверу печати, что она та, за кого себя выдает, и что она уполномочена использовать службу печати. Эмили запрашивает билет в TGS. TGS выдает Эмили билет, который она отправляет серверу печати. Если сервер печати принимает этот билет, Эмили разрешается использовать сервер печати.

KDC предоставляет сервисы безопасности набору системных объектов. Этот набор называется областью (realm) в Kerberos. KDC – это доверенный сервер аутентификации для всех пользователей, приложений и служб в рамках области. Один KDC может отвечать за одну или несколько областей. Области позволяют администратору логически группировать ресурсы и пользователей.

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

Процесс аутентификации Kerberos

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

Выполняются следующие шаги:

1. Эмили приходит на работу в 8 часов и вводит свое имя и пароль на своей рабочей станции.
2. Программное обеспечение Kerberos на рабочей станции Эмили отправляет ее имя службе аутентификации (AS – Authentication Service) на KDC, которая в свою очередь отправляет ей билет для получения билета (TGT – Ticket Granting Tiket) зашифрованный на пароле Эмили (секретном ключе, хранящемся в KDC).
3. Если Эмили ввела правильный пароль, она сможет расшифровать TGT и получить доступ к рабочему столу своей локальной рабочей станции.
4. Когда Эмили потребуется отправить задание на сервер печати, ее система отправит TGT службе предоставления билетов (TGS), запущенной на KDC. Это позволит Эмили доказать, что она была аутентифицирована и позволит ей запросить доступ к серверу печати.
5. TGS создает и отправляет второй билет Эмили, который она будет использовать для аутентификации на сервере печати. Этот второй билет содержит два экземпляра одного и того же сеансового ключа, один из которых зашифрован на секретном ключе Эмили, а второй – на секретном ключе сервера печати. Также, в этот второй билет входит аутентификатор, содержащий идентификационную информацию Эмили, IP-адрес ее системы, порядковый номер и штамп времени.
6. Система Эмили получает второй билет, расшифровывает его и извлекает сеансовый ключ, добавляет в него второй аутентификатор, содержащий идентификационную информацию, и отправляет билет серверу печати.
7. Сервер печати получает билет, расшифровывает его, извлекает сеансовый ключ, а затем расшифровывает и извлекает два аутентификатора. Если сервер печати может расшифровать и извлечь сеансовый ключ, он может быть уверен, что билет создал именно KDC, т.к. только KDC имеет секретный ключ этого сервера печати. Если информация из аутентификаторов (один из которых помещен в билет KDC, а другой – пользователем) совпадает, сервер печати может быть уверен, что билет получен от корректного системного объекта (пользователя).
8. После завершения этого процесса, Эмили считается успешно аутентифицированной на сервере печати, и сервер печатает ее документ.

Это очень простой пример, но он дает основную идею организации работы Kerberos при взаимодействии с сетевыми ресурсами. Посмотрите на рисунок 2-6, на котором схематически изображен этот процесс.

Рисунок 2-6.Для использования запрашиваемого ресурса, пользователь должен сначала получить билет от KDC

Служба аутентификации является частью KDC, аутентифицирующей системные объекты. TGS также является частью KDC, она создает билеты и отправляет их системным объектам. TGT позволяет пользователю не вводить свой пароль каждый раз, когда ему нужно взаимодействовать с другим системным объектом. После того, как пользователь ввел пароль, TGT временно сохраняется на его системе и пользователь может в любое время взаимодействовать с любым системным объектом, повторно используя этот TGT.

Необходимо понимать различия между сеансовым и секретным ключами. Секретный ключ является статическим, а сеансовый ключ генерируется при создании сеанса и уничтожается после его окончания. Секретный ключ совместно используется KDC и системным объектом, а сеансовый ключ – двумя системными объектами.

Если реализация Kerberos настроена на использование аутентификатора, пользователь отправляет серверу печати свою идентификационную информацию, штамп времени (timestamp) и порядковый номер (sequence number), шифруя всю эту информацию на общем сеансовом ключе. Сервер печати расшифровывает полученную информацию и сравнивает ее с идентификационными данными запрашивающего пользователя, полученными от KDC. Если данные совпадают, сервер печати принимает задание от пользователя. При этом штамп времени помогает противодействовать атаке повтора (replay attack). Сервер печати сравнивает штамп времени в полученном пакете со своим собственным внутренним временем, если время существенно различается, это может означать, что сетевой пакет был перехвачен атакующим, а затем отправлен повторно с целью получения несанкционированного доступа от имени легитимного пользователя. Также сервер печати проверяет порядковый номер, чтобы убедиться, что этот пакет не был получен ранее. Это другая защитная мера, позволяющая противостоять атаке повтора.

Основная причина использования Kerberos заключается в том, что системные объекты недостаточно доверяют друг другу для прямого взаимодействия. В нашем примере, сервер печати не намерен печатать чьи угодно задания, без проведения предварительной аутентификации пользователя. Однако нет системных объектов, которые доверяют друг другу напрямую, они доверяют только KDC. KDC создает билеты, ручаясь таким образом за определенный системный объект, которому нужно взаимодействовать.

Такой же тип модели доверия используется в среде PKI (более подробная информация о PKI представлена в Домене 6). В среде PKI пользователи также не доверяют друг другу напрямую, но они доверяют удостоверяющему центру, который ручается за личность пользователей с помощью цифровых сертификатов.

Kerberos является примером технологии SSO – пользователь вводит свой идентификатор и пароль только один раз. Билеты имеют ограниченное время жизни, которое настраивается администратором. Чаще всего время жизни TGT составляет от 8 до 10 часов, чтобы, когда пользователь придет на работу на следующий день, он представил свои учетные данные снова.

Недостатки Kerberos

Ниже представлено несколько потенциальных недостатков Kerberos:

• KDC может являться единой точкой отказа (single point of failure). Если KDC недоступен, никто не сможет получить доступ к ресурсам. Поэтому KDC требует избыточности.
• KDC должен быть способен одновременно обрабатывать большое количество запросов. Поэтому он должен быть масштабируемым.
• Секретный ключ временно хранится на рабочей станции пользователя, что может привести к его компрометации.
• Сеансовый ключ хранится на рабочей станции пользователя в открытом виде в кэше или таблице ключей, что может привести к его компрометации.
• Kerberos уязвим к подбору паролей, он не сможет узнать, что атакующим производится подбор пароля по словарю.
• Kerberos не защищает сетевой трафик, если не включено шифрование.
• Если ключ очень короткий, он может быть уязвим к атаке «грубой силы» (brute force attack).
• Kerberos требует, чтобы системные часы на всех клиентах и серверах были синхронизированы.

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

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

Ссылки по теме:

• Kerberos FAQ
  
• MIT Kerberos Papers and Documentation web page
  

SESAME

Проект SESAME (Secure European System for Applications in a Multi-vendor Environment) – это технология SSO, расширяющая функционал Kerberos и устраняющая его недостатки. В отличии от Kerberos, SESAME использует симметричные и асимметричные технологии криптографии для аутентификации субъектов на сетевых ресурсах.

Kerberos использует билеты для аутентификации субъектов и объектов, а SESAME использует для этого сертификаты атрибутов привилегий (PAC – Privileged Attribute Certificate), которые содержат идентификационные данные субъекта, его возможности доступа к объекту, период времени доступа и время жизни PAC. PAC подписывается ЭЦП, которую объект может проверить с помощью доверенного сервера аутентификации, называемого сервером атрибутов привилегий (PAS – Privileged Attribute Server). PAS выполняет роль, похожую на роль KDC в Kerberos. После успешной аутентификации пользователя в службе аутентификации (AS), он предоставляет токен, полученный от PAS. Затем PAS создает PAC для пользователя, который пользователь будет предоставлять ресурсам, доступ к которым ему потребуется. На рисунке 2-7 показана схема работы основных элементов SESAME.

Рисунок 2-7.SESAME очень похож на Kerberos

Ссылки по теме:

• SESAME in a Nutshell
  
• SESAME links
  

Домены безопасности

Термин домен (domain) часто связывают с Microsoft, когда люди слышат этот термин, они представляют себе группу компьютеров и устройств в сетевом сегменте, управляемых сервером, на котором запущено программное обеспечение Microsoft, называемом контроллером домена. В действительности, домен – это просто набор ресурсов, доступных субъекту. Помните, что субъект может быть пользователем, процессом или приложением. В рамках операционной системы, процесс имеет домен, который является набором системных ресурсов, доступных процессу для выполнения им своих задач. Этими ресурсами могут быть сегменты памяти, пространство на жестком диске, службы операционной системы и другие процессы. В сетевой среде, домен является набором доступных физических и логических ресурсов, которыми могут быть маршрутизаторы, файловые серверы, службы FTP, веб-серверы и т.д.

Термин домен безопасности (security domain) основывается на определении домена, добавляя к нему факт, что ресурсы в рамках этой логической структуры (домена) работают c одной и той же политикой безопасности и управляются одной группой. Таким образом, администратор может поместить компьютеры, учетные записи и сетевые ресурсы сотрудников бухгалтерии в Домен 1, а компьютеры, учетные записи и сетевые ресурсы руководства в Домен 2. Все эти элементы попадут в эти два контейнера, поскольку они (элементы) не только выполняют однотипные задачи, но также, что более важно, имеют один и тот же уровень доверия. Общий уровень доверия позволяет управлять этими элементами одной (отдельной) политикой безопасности.

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

Домены могут быть спроектированы в виде иерархической структуры, определяющей взаимоотношения между различными доменами и способы взаимодействия субъектов, находящихся в различных доменах. На рисунке 2-8 показан пример иерархии сетевых доменов. Их коммуникационные каналы управляются агентами безопасности (списками контроля доступа межсетевых экранов и маршрутизаторов, службами каталогов) и отдельными доменами, изолированными с помощью различных масок подсетей.

Рисунок 2-8.Сетевые домены используются для разделения различных сетевых сегментов

Помните, что домены не обязательно связаны с сетевыми устройствами и сегментацией, они могут также применяться к пользователям и процессам. На рисунке 2-9 показано, как с пользователями и процессами могут быть связаны более детальные домены на основе уровней доверия. Группа 1 имеет высокий уровень доверия и может использовать доступ как к домену своего уровня доверия (Домен 1), так и к домену более низкого уровня доверия (Домен 2). Пользователь 1, который имеет низкий уровень доверия, может использовать только домен своего уровня доверия и не выше. Система реализует эти домены с помощью привилегий доступа и прав на уровне файловой системы и ядра операционной системы.

Рисунок 2-9.Субъекты могут использовать доступ к доменам на основе уровней доверия

Почему домены включены в раздел «Единый вход»? Потому что различные виды существующих в настоящее время технологий, использующихся для определения и реализации этих доменов и связанных с ними политик безопасности, направлены на предоставление пользователям (субъектам) возможности проходить аутентификацию только один раз и получать при этом возможность доступа к различным доменам без необходимости повторного ввода учетных данных. Примерами таких технологий являются: контроллеры домена в среде Windows, продукты ERM, Microsoft Passport и различные продукты, предоставляющие функциональность SSO.

Ссылки по теме:

• Underlining Technical Models for Information Technology Security, Recommendations of the National Institute of Standards and Technology, by Gary Stoneburner, NIST Special Publication 800-33 (Dec. 2001)
  
• “New Thinking About Information Technology Security,” by Marshall Abrams, PhD and Michael Joyce (first published in Computers & Security, Vol. 14, No. 1, pp. 57–68)
  

Службы каталогов

Служба каталога – это механизм, который идентифицирует ресурсы (принтеры, файловые серверы, контроллеры доменов и периферийные устройства) в сети. Сетевая служба каталога (network directory service) содержит информацию об этих ресурсах и субъектах, которым нужен доступ к ним, и выполняет действия по управлению доступом. Если служба каталога работает на основе базы данных, построенной в соответствии со стандартом X.500, она работает в иерархической схеме, которая описывает атрибуты ресурсов, такие как имя, логическое и физическое размещение, субъектов, которые могут использовать эти ресурсы, и операции, которые субъекты могут выполнять с ними.

В базах данных, построенных в соответствии со стандартом X.500, запросы на доступ выполняются пользователями и другими системами посредством протокола LDAP. База данных такого типа обеспечивает иерархическую структуру для организации объектов (субъектов и ресурсов). Служба каталога присваивает уникальные имена каждому объекту и, при необходимости, добавляет соответствующие ему атрибуты. Служба каталога реализует политику безопасности (настроенную администратором) для управления взаимодействием субъектов и объектов.

Сетевые службы каталогов предоставляют пользователям доступ к сетевым ресурсам прозрачно, т.е. пользователям не нужно знать конкретное местоположение ресурсов или шаги, которые необходимо выполнить для доступа к ним. Сетевые службы каталогов выполняют эти задачи для пользователей в фоновом режиме. Примерами служб каталогов являются LDAP (Lightweight Directory Access Protocol), Microsoft AD (Active Directory), Novell NDS (NetWare Directory Service).

ПРИМЕЧАНИЕ. Службы каталогов также рассматривались в разделе «Управление идентификацией» ранее в этом Домене.

Тонкие клиенты

Бездисковые компьютеры (diskless computer) и тонкие клиенты (thin clients) не могут хранить много информации, т.к. они не имеют встроенных устройств хранения информации и необходимых ресурсов. Этот вид клиент-серверной технологии позволяет пользователям регистрироваться на центральном сервере для использования компьютера и доступа к сетевым ресурсам. Когда пользователь включает компьютер, он выполняет короткий список команд и затем обращается на сервер, чтобы загрузить операционную систему или работать в терминальном режиме с прикладным программным обеспечением, работающем на сервере. Это позволяет реализовать строгий контроль доступа, т.к. компьютер пользователя не может сделать ничего самостоятельно, пока не аутентифицируется на центральном сервере и не получит с сервера операционную систему, профиль и функционал. Технология тонких клиентов предоставляет собой другой тип технологии SSO для пользователей, позволяя им аутентифицироваться только на центральном сервере или мейнфрейме, который затем предоставляет им доступ ко всем необходимым и разрешенным им ресурсам.

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

ПРИМЕЧАНИЕ. Эта технология пришла от централизованной модели, использовавшейся мейнфреймами и простыми терминалами (dumb terminal). Она реализуется с помощью службы терминалов Windows, программного обеспечения Citrix, сервис-ориентированной архитектуры (SOA – Service Oriented Architecture) и т.д.

Примеры технологий SSO:

• Kerberos. Протокол аутентификации, использующий KDC и билеты, который основан на криптографии с симметричным ключом.
• SESAME. Протокол аутентификации, использующий PAS и PAC, который основан на симметричной и асимметричной криптографии.
• Домены безопасности. Работа ресурсов в рамках одной политики безопасности и управляемых одной группой.
• Тонкие клиенты. Терминалы, которые используют центральный сервер для управления доступом, обработки и хранения данных.

<<< Предыдущий раздел • Содержание • Следующий раздел >>>