Материал Аудит. Использование компьютерных систем во всех сферах современной жизни, стремительное развитие сетевых технологий, помимо преимуществ, повлекли за собой появление большого ряда специфических проблем
Скачать 3.84 Mb.
|
Тема 2. Безопасность серверных операционных систем Цели и задачи изучения темы: Понять основные защитные механизмы и уязвимые места серверных операционных систем. Научиться настраивать ОС семейства UNIX с целью обеспечения безопасной работы. Научиться настраивать ОС семейства Windows NT с целью обеспечения безопасной работы. Научиться конфигурировать сервер аутентификации Kerberos с целью обеспечения безопасного обмена данными. Сформировать концепцию защиты серверных операционных систем, основанную на статистике атак и применяемых методах несанкционированного доступа. Вопросы темы: 1. Выполнение требований к защите информации от НСД. 2. Основные защитные механизмы ОС семейства Unix. 3. Недостатки защитных механизмов ОС семейства Unix. 4. Особенности обеспечения безопасности ОС Windows NT. 5. Сервер аутентификации Kerberos (Цербер). 6. Обзор и статистика методов, лежащих в основе атак на современные ОС. Теоретический материал по теме Вопрос 1. Выполнение требований к защите информации от НСД. В качестве альтернативных реализаций ОС рассмотрим семейства Unix и Windows NT. Сначала остановимся на принципиальном (концептуальном) противоречии между реализованными в ОС механизмами защиты и принятыми формализованными требованиями. Концептуальном в том смысле, что это противоречие характеризует не какой-либо один механизм защиты, а общий подход к построению системы защиты. Противоречие состоит в принципиальном различии подходов (соответственно требований) к построению схемы администрирования механизмов защиты и, как следствие, это коренным образом сказывается на формировании общих принципов задания и реализации политики безопасности в организации, распределения ответственности за защиту информации, а также на определении того, кого относить к потенциальным злоумышленникам (от кого защищать информацию). Для иллюстрации из совокупности формализованных требований к системе защиты конфиденциальной информации рассмотрим следующие два требования: 1) право изменять правила разграничения доступа (ПРД) должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.); 2) должны быть предусмотрены средства управления, ограничивающие распространения прав на доступ. Данные требования жестко регламентируют схему (или модель) администрирования механизмов защиты. Это должна быть централизованная схема, единственным элементом которой выступает выделенный субъект, в частности, администратор (администратор безопасности). При этом конечный пользователь исключен в принципе из схемы администрирования механизмов защиты. При реализации концепции построения системы защиты, регламентируемой рассматриваемыми требованиями, пользователь не наделяется элементом доверия, так как он может считаться потенциальным злоумышленником, что и имеет место на практике. В данной схеме пользователь должен наделяться практически таким же доверием, как и администратор безопасности, и при этом нести наряду с ним ответственность за обеспечение компьютерной безопасности. Данная концепция реализуется и большинством современных приложений, в частности СУБД, где пользователь может распространять свои права на доступ к защищаемым ресурсам. Кроме того, не имея в полном объеме механизмов защиты компьютерной информации от конечного пользователя, в рамках данной концепции невозможно рассматривать пользователя в качестве потенциального злоумышленника. Но именно с несанкционированными действиями пользователя на защищаемом компьютере (причем как сознательными, так и нет) связана большая часть угроз компьютерной безопасности. Централизованная и распределенная схемы администрирования – это две диаметрально противоположные точки зрения на защиту, требующие совершенно различных подходов к построению моделей и механизмов защиты. При этом сколько-нибудь гарантированную защиту информации можно реализовать только при принятии концепции полностью централизованной схемы администрирования, что подтверждается известными угрозами ОС. Возможности моделей, методов и средств защиты будем рассматривать применительно к реализации именно концепции централизованного администрирования. Одним из элементов данной концепции является рассмотрение пользователя в качестве потенциального злоумышленника, способного осуществить НСД к защищаемой информации. Вопрос 2. Основные защитные механизмы ОС семейства Unix. В операционной системе UNIX используется достаточно простая модель доступа, основанная на субъект-субъектной модели. В современных версиях UNIX помимо общей схемы можно использовать списки доступа. При этом реализуется статическая авторизация множественного доступа к объекту. В UNIX роль номинального субъекта безопасности играет пользователь. Каждому пользователю выдается (обычно – одно) входное имя (login). Каждому входному имени соответствует единственное число, идентификатор пользователя (User IDentifier, UID). Это число и есть ярлык субъекта, которым система пользуется для определения прав доступа. Каждый пользователь входит в одну или более групп. Группа – это образование, которое имеет собственный идентификатор группы (Group IDentifier, GID), объединяет нескольких пользователей системы, а стало быть, соответствует понятию множественный субъект. Значит, GID – это ярлык множественного субъекта, каковых у действительного субъекта может быть более одного. Таким образом, одному UID соответствует список GID. Роль действительного (работающего с объектами) субъекта играет процесс. Каждый процесс снабжен единственным UID: это идентификатор запустившего процесс пользователя. Любой процесс, порожденный некоторым процессом, наследует его UID. Таким образом, все процессы, запускаемые по желанию пользователя, будут иметь его идентификатор. UID учитываются, например, когда один процесс посылает другому сигнал. В общем случае разрешается посылать сигналы «своим» процессам (тем, что имеют такой же UID). Роль объекта в UNIX играют многие реальные объекты, в частности представленные в файловой системе: файлы, каталоги, устройства, каналы и т. п.. Каждый файл снабжён UID – идентификатором пользователя-владельца. Вдобавок у файла есть единственный GID, определяющий группу, которой он принадлежит. На уровне файловой системы в UNIX определяется три вида доступа: чтение (read, r), запись (write, w) и использование (execution, x). Право на чтение из файла дает доступ к содержащейся в нем информации, а право записи – возможность ее изменять. При каждом файле имеется список того, что с ним может делать владелец (если совпадает UID процесса и файла), член группы владельцев (если совпадает GID) и кто угодно (если ничего не совпадает). Такой список (рис. 2) для каждого объекта системы занимает всего несколько байт. Рис. 2. Структура прав доступа к файлу в системе Unix Флаг использования трактуется по-разному в зависимости от типа файла. В случает простого файла, он задаёт возможность исполнения файла, т.е. запуска программы, содержащейся в этом файле. Для директории (рис. 3.) – это возможность доступа к файлам в этой директории (точнее говоря, к атрибутам этих файлов – имени, правам доступа и т.п.). Рис. 3. Последовательность проверки прав доступа в UNIX Рассмотрим последовательность проверки прав на примере, «Последовательнось проверки прав доступа в UNIX»). Пусть файл имеет следующие атрибуты file.txt alice:users rw- r-- --- Т.е. файл принадлежит пользователю «alice», группе «users» и имеет права на чтение и запись для владельца и только чтение для группы. Пусть файл пытается прочитать пользователь «bob». Он не является владельцем, однако он является членом группы «users». Значит, он имеет права на чтение этого файла. Права записи в директорию трактуются как возможность создания и удаления файлов, а также изменение атрибутов файлов (например, переименование). При этом субъекту не обязательно иметь права на запись в эти удаляемые файлы. Таким образом, из своего каталога пользователь может удалить любой файл. А если запись в каталог разрешена всем, то любой пользователь сможет удалить в нём любой файл. Для избежания этой проблемы был добавлен ещё один бит в права доступа каталога: бит навязчивости (sticky, t-бит). При его установке пользователь, имеющий доступ на запись в этот каталог, может изменять только собственные файлы. Вопрос 3. Недостатки защитных механизмов ОС семейства Unix. В ОС семейства Unix, вследствие реализуемой ею концепции администрирования (не централизованная), невозможно обеспечить замкнутость (или целостность) программной среды. Это связано с невозможностью установки атрибута «исполнение» на каталог (для каталога данный атрибут ограничивает возможность «обзора» содержимого каталога). Поэтому при разграничении администратором доступа пользователей к каталогам, пользователь, как «владелец» создаваемого им файла, может занести в свой каталог исполняемый файл и, как его «владелец», установить на файл атрибут «исполнение», после чего запустить записанную им программу. Эта проблема непосредственно связана с реализуемой в ОС концепцией защиты информации. Не в полном объеме реализуется дискреционная модель доступа, в частности, не могут разграничиваться права доступа для пользователя «root» (UID = 0), т.е. данный субъект доступа исключается из схемы управления доступом к ресурсам. Соответственно все запускаемые им процессы имеют неограниченный доступ к защищаемым ресурсам. С этим недостатком системы защиты связано множество атак, в частности: несанкционированное получение прав root; запуск с правами root собственного исполняемого файла (локально либо удаленно внедренного), при этом несанкционированная программа получает полный доступ к защищаемым ресурсам и т.д. Кроме того, в ОС семейства Unix невозможно встроенными средствами гарантированно удалять остаточную информацию. Для этого в системе абсолютно отсутствуют соответствующие механизмы. Необходимо также отметить, что большинство ОС данного семейства не обладают возможностью контроля целостности файловой системы, т.е. не содержат соответствующих встроенных средств. В лучшем случае дополнительными утилитами может быть реализован контроль конфигурационных файлов ОС по расписанию в то время, как важнейшей возможностью данного механизма можно считать контроль целостности программ (приложений) перед их запуском, контроль файлов данных пользователя и т.д. Что касается регистрации (аудита), то в ОС семейства Unix не обеспечивается регистрация выдачи документов на «твердую копию», а также некоторые другие требования к регистрации событий. Если же трактовать требования к управлению доступом в общем случае, то при защите компьютера в составе ЛВС необходимо управление доступом к узлам сети. Однако встроенными средствами зашиты некоторых ОС семейства Unix управление доступом к узлам не реализуется. Из приведенного анализа видно, что многие механизмы, необходимые с точки зрения выполнения формализованных требований, большинством ОС семейства Unix не реализуется в принципе, либо реализуется лишь частично. Вопрос 4. Особенности обеспечения безопасности ОС Windows NT. В отличие от семейства ОС Unix, где все задачи разграничительной политики доступа к ресурсам решаются средствами управления доступом к объектам файловой системы, доступ в данных ОС разграничивается собственным механизмом для каждого ресурса. Другими словами, при рассмотрении механизмов защиты ОС Windows встает задача определения и задания требований к полноте разграничений (это определяется тем, что считать объектом доступа). Также, как и для семейства ОС Unix, здесь основными механизмами защиты являются: идентификация и аутентификация пользователя при входе в систему; разграничение прав доступа к ресурсам, в основе которого лежит реализация дискреционной модели доступа (отдельно к объектам файловой системы, к устройствам, к реестру ОС, к принтерам и др.); аудит, т. е. регистрация событий. В лучшую сторону выделяются возможности разграничений прав доступа к файловым объектам (для NTFS) — существенно расширены атрибуты доступа, устанавливаемые на различные иерархические объекты файловой системы (логические диски, каталоги, файлы). В частности, атрибут «исполнение» может устанавливаться и на каталог, тогда он наследуется соответствующими файлами. При этом существенно ограничены возможности управления доступом к другим защищаемым ресурсам, в частности, к устройствам ввода. Например, здесь отсутствует атрибут «исполнение», т. е. невозможно запретить запуск несанкционированной программы с устройств ввода. Операционная система Windows NT всегда обладала хорошими и широко применимыми на практике возможностями защиты. Однократная регистрация в домене Windows NT предоставляет пользователям доступ к ресурсам всей корпоративной сети. Полноценный набор инструментов Windows NT Server облегчает администраторам управление системой защиты и ее поддержку. Например, администратор может контролировать круг пользователей, имеющих права доступа к сетевым ресурсам: файлам, каталогам, серверам, принтерам и приложениям. Учетными записями пользователей и правами для каждого ресурса можно управлять централизованно: С помощью простых графических инструментов администратор задает принадлежность к группам, допустимое время работы, срок действия и другие параметры учетной записи. Администратор получает возможность аудита всех событий, связанных с защитой доступа пользователей к файлам, каталогам, принтерам и иным ресурсам. Система способна блокировать учетную запись пользователя, если число неудачных попыток регистрации превышает заранее определенное. Администраторы вправе устанавливать срок действия паролей, принуждать пользователей к периодической смене паролей и выбору паролей, затрудняющих несанкционированный доступ. С точки зрения пользователя система защиты Windows NT Server полноценна и несложна в обращении. Простая процедура регистрации обеспечивает доступ к соответствующим ресурсам. Для пользователя невидимы такие процессы, как шифрование пароля на системном уровне. Пользователь сам определяет права доступа к тем ресурсам, которыми владеет. Например, чтобы разрешить совместное использование своего документа, он указывает, кто и как может с ним работать. Разумеется, доступ к ресурсам предприятия контролируется только администраторами с соответствующими полномочиями. Более глубокий уровень безопасности — то, как Windows NT Server защищает данные, находящиеся в физической памяти компьютера. Доступ к ним предоставляется только имеющим на это право программам. Если данные больше не содержатся на диске, система предотвращает несанкционированный доступ к той области диска, где они содержались. При такой системе защиты никакая программа не «подсмотрит» в виртуальной памяти машины информацию, с которой оперирует в данный момент другое приложение. Удаленный доступ через открытые сети и связь предприятий через Интернет стимулируют постоянное и быстрое развитие технологий безопасности. В качестве примера можно выделить сертификаты открытых ключей и динамические пароли. Архитектура безопасности Windows NT однозначно оценивается как превосходящая и эти, и многие будущие технологии. Перечислим функции безопасности Windows NT. Информация о доменных правилах безопасности и учетная информация хранятся в каталоге Active Directory (служба каталогов Active Directory обеспечивает тиражирование и доступность учетной информации на многих контроллерах домена, а также позволяет удаленное администрирование). В Active Directory поддерживается иерархичное пространство имен пользователей, групп и учетных записей машин (учетные записи могут быть сгруппированы по организационным единицам). Административные права на создание и управление группами учетных записей пользователей могут быть делегированы на уровень организационных единиц (возможно установление дифференцированных прав доступа к отдельным свойствам пользовательских объектов). Тиражирование Active Directory позволяет изменять учетную информацию на любом контроллере домена, а не только на первичном (копии Active Directory, хранящиеся на других контроллерах домена, обновляются и синхронизируются автоматически). Доменная модель изменена и использует Active Directory для поддержки многоуровневого дерева доменов (управление доверительными отношениями между доменами упрощено в пределах всего дерева доменов). В систему безопасности включены новые механизмы аутентификации, такие как Kerberos v5 и TLS (Transport Layer Security), базирующиеся на стандартах безопасности Интернета. Протоколы защищенных каналов (SSL 3.0/TLS) обеспечивают поддержку надежной аутентификации клиента (осуществляется сопоставление мандатов пользователей в форме сертификатов открытых ключей с существующими учетными записями Windows NT). Дополнительно к регистрации посредством ввода пароля может поддерживаться аутентификация с использованием смарт-карт. В состав Windows NT входит Microsoft Certificate Server, позволяющий выдавать сотрудникам и партнерам сертификаты Х.509 версии. Системные администраторы могут указывать, сертификаты каких уполномоченных являются доверяемыми в системе и, таким образом, контролировать аутентификацию доступа к ресурсам. Внешние пользователи, не имеющие учетных записей Windows NT, могут быть аутентифицированы с помощью сертификатов открытых ключей и соотнесены с существующей учетной записью. Права доступа, назначенные для этой учетной записи, определяют права внешних пользователей на доступ к ресурсам. В распоряжении пользователей находятся средства управления парами закрытых (открытых) ключей и сертификатами, используемые для доступа к ресурсам системы. Технология шифрования встроена в операционную систему позволяет использовать цифровые подписи для идентификации потоков. Делегирование административных полномочий — гибкий инструмент ограничения административной деятельности рамками части домена. Этот метод позволяет предоставить отдельным сотрудникам возможность управления пользователями или группами в заданных пределах, и в то же время, не дает им прав на управление учетными записями, относящимися к другим подразделениям. Существует три способа делегирования административных полномочий: на изменение свойств определенного контейнера, пример, LocalDomainPolicies самого домена; на создание и удаление дочерних объектов определенного типа (пользователи, группы, принтеры и пр.); на обновление определенных свойств некоторых дочерних объектов внутри например, право устанавливать пароль для объектов типа User). Для делегирования полномочий достаточно выбрать лицо, которому будут делегированы полномочия, и указать, какие именно полномочия передаются. Интерфейс программы администрирования Active Directory (рис. 4) позволяет без затруднений просматривать информацию о делегировании, определенную для контейнеров. Рис. 4. Интерфейс программы администрирования Active Directory Наследование прав доступа означает, что информация об управлении доступом, определенная в высших слоях контейнеров в каталоге, распространяется ниже — на положенные контейнеры и объекты-листья. Существуют две модели наследования прав доступа: динамическая и статическая. При динамическом наследовании права определяются путем оценки разрешений на доступ, назначенных непосредственно для объекта, а также для всех родительских объектов в каталоге. Это позволяет эффективно управлять доступом к части дерева каталога, внося изменения в контейнер, влияющий на все вложенные контейнеры и объекты-листья. Обратная сторона такой гибкости — недостаточно высокая производительность из-за времени определения эффективных прав доступа при запросе пользователя. В Windows NT реализована статическая форма наследования прав доступа, иногда также называемая наследованием в момент создания. Информация об управлении доступом к контейнеру распространяется на все вложенные объекты контейнера. При создании нового объекта наследуемые права сливаются с правами доступа, назначаемыми по умолчанию. Любые изменения наследуемых прав доступа, выполняемые в дальнейшем на высших уровнях дерева, должны распространяться на все дочерние объекты. Новые наследуемые права доступа распространяются на объекты Active Directory в соответствии с тем, как эти новые права определены. Статическая модель наследования позволяет увеличить производительность. Вопрос 5. Сервер аутентификации Kerberos (Цербер). Система Kerberos предназначена для решения следующей задачи. Имеется открытая (незащищенная) сеть, в узлах которой сосредоточены субъекты — пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Чтобы субъект C мог доказать свою подлинность субъекту S (без этого S не станет обслуживать C), он должен не только назвать себя, но и продемонстрировать знание своего секретного ключа. C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта (доступна для пассивного и активного прослушивания), а, во-вторых, потому, что S не знает (и не должен) знать секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа. Система Kerberos представляет собой надежную третью сторону (то есть сторону, которой доверяют все), владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности. Чтобы с помощью Kerberos получить доступ к S (обычно это сервер), C (как правило — клиент) посылает Kerberos'у запрос, содержащий сведения о нем (клиенте) и о запрашиваемой услуге. В ответ Kerberos возвращает две порции информации: так называемый билет, зашифрованный секретным ключом сервера, и копию части информации из билета, зашифрованную секретным ключом клиента. Клиент должен расшифровать вторую порцию данных и переслать ее вместе с билетом серверу. Сервер, расшифровав билет, может сравнить его (билета) содержимое с дополнительной информацией, присланной клиентом. Совпадение свидетельствует о том, что клиент смог расшифровать предназначенные ему данные (ведь содержимое билета никому, кроме сервера и Kerberos, недоступно), то есть продемонстрировал знание своего секретного ключа. Значит, клиент — именно тот субъект, за кого себя выдает. Подчеркнем, что секретные ключи в процессе проверки подлинности не передавались по сети (даже в зашифрованном виде) — они только использовались для шифрования. Как организован первоначальный обмен ключами между Kerberos и субъектами и как субъекты хранят свои секретные ключи — вопрос отдельный. Проиллюстрируем описанную процедуру на рисунке 5. Проверка сервером S подлинности клиента C. Здесь: c и s — сведения (например, имя), соответственно, о клиенте и сервере, d1 и d2 — дополнительная (по отношению к билету) информация. Tc.s — билет для клиента C на обслуживание у сервера S, Kc и Ks — секретные ключи клиента и сервера, {info}K — информация info, зашифрованная ключом K. Рис. 5. Проверка сервером S подлинности клиента C Изложенный вариант 1 - крайне упрощенная версия реальной процедуры проверки подлинности. Прежде всего, необходимо уточнить структуру пересылаемых запросов и возвращаемых ответов. И билет, и вторая порция информации, предоставляемая со стороны Kerberos, содержат случайный ключ, пригодный для шифрования сообщений, пересылаемых между клиентом и сервером. Этот ключ называется сеансовым и представляет собой общую секретную информацию, разделяемую C и S. Появление подобной общей информации и возможность организации конфиденциального взаимодействия - важный побочный продукт аутентификации средствами Kerberos. Билет, который выдает Kerberos, имеет ограниченный срок годности. Естественно распространить этот срок и на сеансовый ключ. Когда срок годности истекает, необходимо проведение повторной проверки подлинности. Продолжительность стандартного срока годности зависит от политики безопасности, проводимой организацией. Типичный срок годности — 8 часов. Вполне вероятно, что клиент C захочет убедиться в подлинности обслуживающего его сервера S. Чтобы это было возможным, клиент шифрует дополнительную информацию, передаваемую серверу, с помощью сеансового ключа. Сервер может узнать сеансовый ключ, только расшифровав билет. Если это случится и сервер вернет клиенту свидетельство того, что он сумел прочитать дополнительную информацию, C вправе считать подлинность сервера S установленной. Соответствующая схема представлена на рисунке 6. Взаимная проверка клиентом C и сервером S подлинности друг друга (вариант 2). Здесь: timeexp — срок годности билета, n — одноразовый номер, Kc.s — сеансовый ключ, ts — временной штамп, ck — контрольная сумма. Рис. 6. Взаимная проверка клиентом C и сервером S подлинности друг друга Отдельного пояснения заслуживает обозначение s1 в первом запросе. Вообще говоря, клиенту нужен не конкретный сервер, а определенный сервис, о чем он и просит Kerberos. В ответ клиент получает адрес сервера, способного оказать запрашиваемую услугу. Порции информации в сообщениях 3 и 4, шифруемые сеансовыми ключами, называют аутентификаторами. Они позволяют убедиться в подлинности предъявившего их субъекта. В дальнейшем аутентификатор клиента мы будем обозначать Ac, аутентификатор сервера — As. Далее, необходимо защитить информацию, пересылаемую по сети, от воспроизведения. Если этого не сделать, злоумышленник сможет послать серверу дубликаты билета и дополнительной информации и успешно выдать себя за «второго C». Стандартный способ защиты от воспроизведения — включение в нее временных штампов и/или так называемых одноразовых номеров, позволяющих удостовериться в «свежести» сообщений и в их неповторяемости (и, более того, в целостности последовательности сообщений). Одноразовые номера позволяют также ассоциировать ответы с предыдущими запросами. Вариант 2 гораздо практичнее варианта 1, однако и он нуждается в уточнении. Естественно предположить, что клиенту понадобятся услуги нескольких серверов. Соответственно, чтобы доказать свою подлинность, клиенту придется несколько раз повторять диалог с Kerberos и использовать свой секретный ключ. К сожалению, долго держать наготове секретный ключ опасно — его могут украсть. Чтобы справиться с указанной проблемой, сервер Kerberos «раздваивается» на сервер начальной аутентификации (AS — Authentication Server) и сервер выдачи билетов (TGS — Ticket Granting Server). Клиент запрашивает у AS по схеме, изображенной на рис. 6 , билет к TGS («билет на получение билетов», «билет на билеты» — TGT, Ticket-Granting Ticket). TGT содержит сеансовый ключ для засекречивания общения между клиентом и сервером выдачи билетов. Билеты к другим серверам клиент получает у TGS на основании «билета на билеты». Вопрос 6. Обзор и статистика методов, лежащих в основе атак на современные ОС. Атаки и методы, позволяющие несанкционированно вмешаться в работу системы, можно разделить на следующие группы: позволяющие несанкционированно запустить исполняемый код; позволяющие осуществить несанкционированные операции чтения/записи файловых или других объектов; позволяющие обойти установленные разграничения прав доступа; приводящие к отказу (Denial of Service) в обслуживании (системный сбой); использующие встроенные недокументированные возможности (ошибки и закладки); использующие недостатки системы хранения или выбора (недостаточная длина) данных об аутентификации (пароли) и позволяющие путем реверсирования, подбора или полного перебора всех вариантов получить эти данные; троянские программы; прочие. Вывод: угрозы, описанные в большинстве групп, напрямую используют различные недостатки ОС и системных приложений и позволяют при полностью сконфигурированных и работающих встроенных в ОС механизмах защиты осуществлять НСД, что подтверждает необходимость усиления встроенных механизмов защиты. Анализируя представленную статистику угроз, можно сделать вывод, что большая их часть связана именно с недостатками средств защиты ОС, отмеченными выше, т. е. недостатками, связанными с невыполнением (полным, либо частичным) формализованных требований к защите, среди которых, в первую очередь, могут быть выделены: некорректная реализация механизма управления доступом, прежде всего, при разграничении доступа к защищаемым объектам системных процессов и пользователей, имеющих права администратора; отсутствие обеспечения замкнутости (целостности) программной среды. Большинство атак осуществлялось либо с использованием некоторых прикладных программ, либо с применением встроенных в виртуальные машины средств программирования, т. е. возможность большинства атак напрямую связана с возможностью запуска злоумышленником соответствующей программы. При этом запуск может быть осуществлен как явно, так и скрыто, в рамках возможностей встроенных в приложения интерпретаторов команд. Большая часть угроз обусловлена именно реализуемым в ОС концептуальным подходом, состоящим в реализации схемы распределенного администрирования механизмов защиты. В рамках этой схемы пользователь рассматривается как доверенное лицо, являющееся элементом схемы администрирования и имеющее возможность назначать/изменять ПРД. При этом он не воспринимается как потенциальный злоумышленник, который может сознательно или несознательно осуществить НСД к информации, следовательно назначение механизмов добавочной защиты ОС состоит в реализации централизованной схемы администрирования механизмов защиты, в рамках которой будет осуществляться противодействие НСД пользователя к информации. Вопросы для самопроверки: 1. В чем состоят противоречия между реализованными в ОС механизмами защиты и принятыми формализованными требованиями? 2. В чем, с точки зрения обеспечения информационной безопасности, состоит отличие между централизованной и распределенной схемой администрирования? 3. Как реализуется структура прав доступа к файлу в системе Unix? 4. Какие уровни доступа реализованы на уровне файловой системы в UNIX? 5. Какие основные защитные механизмы реализованы в системе Unix? 6. Каковы основные недостатки защитных механизмов ОС семейства Unix? 7. Какие основные защитные механизмы реализованы в ОС семейства Windows NT? 8. Какие основные функции управления учетными записями пользователей реализованы в ОС семейства Windows NT? 9. Для чего предназначена служба Active Directory и какие она предоставляет возможности администрирования? 10. Каким образом система Kerberos реализует попарную проверку подлинности субъектов. 11. Какие выделяют группы методов, позволяющие несанкционированно вмешаться в работу системы? 12. Какие основные недостатки механизма защиты ОС используют средства несанкционированного доступа? Литература по теме: Основная литература: 1. Безопасность операционных систем : учебное пособие / А. А. Безбогов, А.В. Яковлев, Ю.Ф. Мартемьянов. - М.: Гелиос АРВ, 2008. - 320 с. Дополнительная литература: 1. А. В. Гордеев. Операционные системы Издательство: Питер, 2009 г. 416 с. 2. Ложников П.С. Обеспечение безопасности сетевой инфраструктуры на основе операционных систем Microsoft. Практикум. М.: ИНТУИТ, 2012, - 245 с. 3. Олифер В.Г., Олифер Н.А. Сетевые операционные системы Спб.: Издательский дом Питер, 2001. 4. Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы Спб.: Издательский дом Питер, 2002. 5. Операционная система UNIX. Издательство: БХВ-Петербург, 2007 г. 6. Операционные системы.Учебный курс. CD-ROM, 2006 г. 7. Х. М. Дейтел, П. Дж. Дейтел, Д. Р. Чофнес. Операционные системы. Часть1. Основы и принципы. Издательство: Бином-Пресс, 2009 г. 1024 с. 8. Х. М. Дейтел, П. Дж. Дейтел, Д. Р. Чофнес. Операционные системы. Часть 2. Распределенные системы, сети, безопасность. Издательство: Бином-Пресс, 2009 г. Интернет-ресурсы: 1. Security Audit Policy Reference // http://technet.microsoft.com/ru-ru/library/dd772623(WS.10).aspx. 2. Эволюция операционных систем // http://vv303.narod.ru/files/inst/olifer/chapter1/default.htm#1. 3. НОУ ИНТУИТ | Учебный курс | Администрирование Microsoft Windows Server 2003 // http://www.intuit.ru/department/network/mswinserver2003/. 4. Эволюция операционных систем // http://www.citforum.ru/operating_systems/unix/contents.shtml. Практические задания: Задание 1. В операционной системе семейства Unix - Ubuntu server произвести настройку протокола безопасных соединений – SSH. Задание 2. В операционной системе семейства Windows NT - Windows Server 2008 R2 настроить аудит доменных служб Active Directory. |