Построение системы информационной безопасности на основе Solaris 2.x

1. Внешний уровень, определяющий взаимодействие информационной системы организации с глобальными ресурсами и системами других организаций. Функционально этот уровень характеризуется, с одной стороны, информационными (главным образом, сетевыми) сервисами, предоставляемыми данной организацией, с другой стороны, аналогичными сервисами, запрашиваемыми из глобальной сети. На этом уровне должны отсекаться как попытки внешних пользователей несанкционированно получить от организации дополнительный сервис, так и попытки собственных пользователей осуществить подобные операции по отношению к внешним сервисам или несанкционированно переслать информацию в глобальную сеть.
2. Сетевой уровень связан с доступом к информационным ресурсам внутри локальной сети организации. Безопасность информации на этом уровне обеспечивается средствами проверки подлинности пользователей и разграничением доступа к ресурсам локальной сети (аутентификация и авторизация).
3. Системный уровень связан прежде всего с управлением доступом к ресурсам ОС. Именно на этом уровне происходит непосредственное взаимодействие с пользователями, запускаются приложения, и, самое главное, определяются "правила игры" между информационной системой и пользователем (задается либо изменяется конфигурация системы). В этой связи, естественно понимать защиту информации на данном уровне, как четкое разделение, к каким ресурсам ОС какой пользователь и когда может быть допущен. Защите системных ресурсов должно уделяться особое внимание, поскольку несанкционированный доступ к ним может сделать бессмысленными прочие меры безопасности. Важность именно этого уровня можно проиллюстрировать тем фактом, что долгое время вопросы информационной безопасности сводились исключительно к рассмотрению защиты на уровне и средствами ОС.
4. Уровень приложений связан с использованием прикладных ресурсов информационной системы. Поскольку именно приложения на содержательном уровне работают с пользовательскими данными, для них, вообще говоря, нужны собственные механизмы обеспечения информационной безопасности.

Средства защиты, встроенные в ОС, занимают особое место. Их основной задачей является защита информации, определяющей конфигурацию системы, и уже затем — пользовательских данных. Такой подход представляется естественным, поскольку возможность изменять конфигурацию делает механизмы защиты бессмысленными. Так как эти ресурсы находятся на системном уровне, можно было бы ожидать, что на этом уровне и будут собраны основные встроенные средства защиты информации. В случае ОС Solaris 2.x, с самого начала рассматривающей распределенные решения для информационных систем, встроенные средства защиты продвинуты на сетевой уровень, а в общем наборе решений, предоставляемых для корпоративных информационных сетей, присутствуют также инструменты безопасности внешнего уровня. Кроме того, поскольку для информационной безопасности существенным является обеспечение доступности данных, ряд компонент в составе OС Solaris 2.x, не являясь средствами защиты в классическом смысле, тем не менее существенны.

В соответствии с вышеизложенным, в процессе анализа встроенных механизмов защиты ОС Solaris 2.x имеет смысл рассматривать сначала собственно системные средства, включая механизмы аудита и проверки корректности системы, затем средства работы на сетевом уровне и инструменты увеличения надежности доступа к данным, что и будет сделано ниже.

Системные средства аутентификации пользователей

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

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

Процедура проверки соответствия пользователя предъявляемому имени называется аутентификацией. В Solaris 2.x применяется аутентификация при помощи пароля — дополнительной комбинации символов, ассоциируемой с пользовательским именем. Предполагается, что субъект, способный сообщить системе имя и соответствующий ему пароль, является легальным пользователем.

При описанном подходе очень существенной оказывается политика управления пользовательскими паролями, определяющая правила их назначения, хранения, изменения и другие связанные с этим вопросы. Чем большие возможности по проведению подобной политики предоставляет администратору операционная система, тем больше шансов на то, что парольная аутентификация будет действенным инструментом защиты. Для иллюстрации важности разумной политики назначения пользовательских имен и паролей можно привести данные исследований, проведенных в AT&T, показывающие, что из 500 попыток несанкционированного доступа около 300 составляют попытки угадывания паролей или беспарольного входа по пользовательским именам guest, demo и т.д.

Формулируя требования к паролю, необходимо указать, какой набор символов может служить надежным паролем, а какой — нет. Очевидно, что пароли, которые легко угадать либо быстро подобрать, лучше не использовать. В "черный" список включаются имя, отчество и фамилия пользователя, дата рождения, номер телефона, слова, относящиеся к области его интересов, а также общеупотребительные слова, подбираемые по словарю. Лучшим паролем с точки зрения неугадываемости является случайный бессмысленный набор символов. К сожалению, запомнить такой набор достаточно сложно, что заставляет пользователя записывать его на бумаге, с риском потерять запись либо случайно показать ее кому-либо. Разумной альтернативой является пароль, составленный из первых букв каждого слова какой-либо легко запоминающейся фразы. Еще более надежное средство — применение программных генераторов паролей, порождающих случайные и бессмысленные, но благозвучные, а потому запоминающиеся, сочетания.

Даже хорошо сделанные пароли с течением времени становятся известными. Это заставляет периодически проводить их замену. Считается, что в информационных системах с низкими требованиями к обеспечению безопасности пароль должен меняться каждые три месяца, а по мере увеличения значимости вопросов, связанных с несанкционированным доступом, указанный срок уменьшается до шести недель. Не менее важно и минимально допустимое время между двумя последовательными изменениями паролей, поскольку такое изменение — типичное действие в случае получения кем-либо несанкционированного доступа к системе либо ресурсам пользователя. Утилиты Solaris 2.x предоставляют администратору возможность контролировать процесс изменения паролей. Системный администратор может назначать минимальное и максимальное время между изменениями пароля с выдачей предупреждения пользователю о необходимости изменить пароль и блокированием доступа в систему в случае неподчинения.

В любой достаточно большой системе имеются пользователи с временными правами доступа. По окончании легальной работы такого пользователя его системный счет должен быть уничтожен, в противном случае он может использоваться в дальнейшем, но уже несанкционированно. Для предотвращения такой ситуации в Solaris 2.x возможна установка так называемого времени испарения пароля, после которого автоматический доступ пользователя в систему прекращается.

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

При обеспечении режима безопасности важны не только средства предохранения от несанкционированного доступа, но и средства выявления таких событий. Операционная система Solaris 2.x предусматривает ведение записей неудачных попыток входа в систему. Эту информацию нетрудно использовать для оповещения системного администратора в случае, если количество таких попыток превышает заданную величину.

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

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

Особую опасность представляет удаленный вход в систему через телефонную сеть. Поскольку контролировать эту сеть невозможно, то необходимы дополнительные меры безопасности. Такая возможность в Solaris 2.x предусмотрена и заключается в установке дополнительных паролей на последовательные порты. В случае, если при попытке подключения пароль не поступает либо поступает неправильный, дальнейшая работа с системой становится невозможной (Рис. 2).

Существенным моментом является степень защищенности информации о пользователях и их паролях. Пользовательские пароли хранятся в зашифрованным виде в файле /etc/shadow. В отличие от файла /etc/passwd, /etc/shadow доступен на чтение только при наличии у пользователя привилегий системного администратора. Это важно, так как одним из типичных приемов "взлома" системы является копирование злоумышленником на свой компьютер файла паролей и их подбор различными методами, в том числе и методом грубой силы (алгоритм шифрования паролей широко известен).

Разграничение доступа пользователей к ресурсам

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

Избежать этой опасности можно, прежде всего, средствами физической защиты помещения, где установлен компьютер. Кроме того, серверы компании Sun Microsystems снабжаются ключами, а на SPARCcenter 2000 имеется возможность установки электронного ключа, что повышает защищенность.

Для предотвращения несанкционированной загрузки в EEPROM-интерпретаторе предусмотрена переменная security-mode. Установка значения command для этой переменной приводит к запросу пароля при любой перезагрузке ОС. Правда, использование этого способа защиты опасно тем, что в случае утери пароля, машина не может быть загружена без замены микросхемы EEPROM.

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

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

Стандартная команда ls -l выдает список файлов с правами доступа к ним, например

-rwxr-xr-- filename

Здесь символы "rwx" означают наличие прав на чтение, запись и исполнение соответственно, а символ "-" — отсутствие такого права. В данном случае владелец может читать, писать и выполнять файл, члены группы — читать и выполнять, прочие пользователи — только читать.

Для директорий флаг "x" означает право на поиск (извлечение) файлов.

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

500. разрешено чтение и выполнение только владельцу (-r-x------);

444. всем разрешено только чтение (-r--r--r--);

744. все, кроме владельца, могут только читать (-rwxr--r--).

Первоначальные права доступа при создании файлов задаются с помощью команды umask. Ее аргумент, трехзначное восьмеричное число, показывает, какие права будут маскироваться ("вычитаться"). Так, команда umask 027 приведет к тому, что создаваемые файлы будут иметь права доступа rwx для владельца, rx для группы, а прочие пользователи останутся без каких-либо прав по отношению к файлу. Правильная установка значения umask — важный элемент реализации политики безопасности в области разграничения доступа.

Пользователь может изменять права доступа к своим файлам при помощи команды chmod.

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

С целью устранения отмеченного недостатка, начиная с версии Solaris 2.5 стало возможным использовать списки управления доступом (Access Control List, ACL). В таком случае права доступа для отдельных пользователей либо групп могут устанавливаться индивидуально с помощью команды setfacl. Наличие списка обнаруживается при помощи команды ls -l по символу + после стандартных для UNIX прав доступа. Например, для файла file1, принадлежащего пользователю user1 из группы group1, указанные действия будут выглядеть следующим образом:

ls -l file1

-rw-r--r-- + user1 group1 .... file1

Полную информацию по ACL дает команда getfacl. В рассматриваемом случае она выдаст следующую информацию:

getfacl file1

#file: file1

#owner: user1

#group: group1

user::rw-

user:user1:rw-

user:user2:---

group::r--

other:r--

В данном примере отдельно для пользователя user2 запрещен любой доступ к файлу file1.

Механизм ACL работает как в локальных (UFS), так и в сетевых (NFS) файловых системах. Параметры списка доступа сохраняются также всеми встроенными средствами резервного копирования.

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

Имеется три легальных способа получения привилегий root: вход в систему под этим именем, использование команды su и выполнение программ, переустанавливающих идентификатор пользователя.

Очевидно, пароль пользователя root должен выбираться и скрываться системными администраторами с особой тщательностью (это важно и для прямого входа в систему, и для команды su). В качестве дополнительной меры безопасности ОС Solaris 2.x позволяет запретить вход под именем root с потенциально ненадежных терминалов. При анализе регистрационной информации системным администраторам следует обращать особое внимание на все попытки входа под именем root и использования команды su.

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

Наличие нескольких путей получения повышенных привилегий является потенциально уязвимым местом в защите операционной системы. Особенно опасно, когда переустановка идентификатора пользователя производится не бинарным файлом, а программой командного интерпретатора (shell script), что объясняется легкостью ее модификации. Указанное обстоятельство заставляет администратора системы контролировать штатные пользовательские командные интерпретаторы, ограничивая возможности пользователя записями в файле /etc/shells.

Поскольку большинство пользователей использует ограниченный набор приложений, в ряде случаев можно зафиксировать круг доступных программ, что особенно актуально при проведении нормативной политики безопасности предприятия. Для этого в Solaris 2.x предусмотрен "restricted shell" (ограничивающий системный интерпретатор). Пользователь ограничивается своей директорией (в другую перейти нельзя) и может использовать программы только из тех директорий, которые записаны в переменной окружения PATH, причем изменение значения этой переменной не допускается. Кроме того, пользователь не может задавать полные имена программных файлов и переназначать поток ввода-вывода. В случае применения этого интерпретатора уменьшается вероятность непреднамеренного нарушения информационной безопасности системы. Существуют, впрочем, более продвинутые программные продукты, выполняющие ту же задачу, которые будут рассмотрены при описании путей усиления безопасности ОС Solaris.

В ряде случаев пользователь вообще не нуждается в непосредственном взаимодействии с операционной системой, работая постоянно с каким-либо приложением (например, клиентом базы данных). В этом случае целесообразно использовать возможности разграничения доступа, предоставляемые СУБД. Чтобы реализовать ситуацию прямого входа в приложение app, необходимо создать следующий файл запуска командного интерпретатора (файл /etc/skeleton/.profile):

#/bin/sh

trap 0 2 3 4 5 6

PATH=/home/bin;export PATH

APHOME=/home; export APHOME

exec /home/bin/app

exit

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

ASET — средство проверки корректности конфигурации системы

Операционная система Solaris имеет большое количество настроек и конфигурационных файлов, что позволяет гибко адаптировать ОС для нужд конкретных пользователей информационной системы. Это, однако, создает опасность появления слабых мест с точки зрения информационной безопасности. Для проверки целостности и корректности текущей конфигурации ОС Solaris предусмотрена специальная утилита — ASET.

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

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

При запуске программа ASET сначала проводит верификацию прав доступа к системным файлам.

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

Список проверяемых программой ASET файлов находится в мастер файле /usr/aset/masters/chklist и содержит более 1000 элементов. Указанный список может быть расширен по желанию системного администратора.

Затем проводится проверка корректности списка пользователей и пользовательских групп. В процессе выполнения этой задачи контролируются дублирование имен и идентификаторов пользователей, формат файлов /etc/passwd и /etc/group, наличие паролей у всех пользователей и т.п., плюс аналогичные параметры в NIS и NIS+.

Далее проверяются записи в конфигурационных файлах директории /etc с выявлением потенциально слабых мест в текущих настройках ОС. К числу таких файлов относятся:

/etc/default/login,

/etc/hosts.equiv,

/etc/inetd.conf,

/etc/aliases,

/etc/hosts,

/etc/vfstab,

/etc/dfs/dfstab,

/etc/ftpusers

и некоторые другие.

На следующем этапе проверяются установки PATH и umask для пользователя root, находящиеся в файлах /.profile, /.login, /.cshrc.

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

Результаты выполнения программы ASET записываются в текстовом виде в файлах директории /usr/aset/reports.

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

Программу ASET рекомендуется запускать раз в сутки. Условия запуска ASET задаются переменной PERIODIC_SCHEDULE конфигурационного файла /usr/aset/asetenv.

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

BSM SunSHIELD — инструмент системного аудита

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

Программные средства, осуществляющие описанный выше контроль, называются средствами аудита. Поскольку в информационной системе предприятия присутствуют несколько функциональных уровней, на каждом из них желательно иметь средства мониторинга событий. В настоящее время наличие механизмов аудита является обязательным требованием к крупным программным продуктам, работающим на любом из уровней. Что касается средств аудита ОС Solaris 2.x, то они принадлежат преимущественно системному уровню, лишь частично покрывая сетевой и тем более внешний функциональные уровни.

Модуль SunSHIELD, входящий в состав Solaris 2.x, осуществляет аудит в соответствии с требованиями к классу безопасности C2 (по классификации Национального Центра Компьютерной Безопасности США) (соответствует пятому классу защищенности средств вычислительной техники по классификации Гостехкомиссии РФ).

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

Регистрационные действия выполняются специализированным аудит-демоном, который проводит запись событий в регистрационный журнал в соответствии с текущей конфигурацией. Аудит-демон стартует в процессе загрузки системы.

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

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

Каждое событие принадлежит какому-либо классу аудита. Такое деление упрощает анализ большого количества событий. Принадлежность событий к классам и набор классов могут быть сконфигурированы системным администратором путем редактирования файла /etc/security/audit_event. Все события пронумерованы от 0 до 65535, причем первые 2048 номеров отведены для событий, связанных с ядром ОС, с 2048 по 32767 — под пользовательские события ОС UNIX, а остальные — под прочие приложения. Таким образом достаточно легко производится настройка на круг событий, для которых требуется аудит.

В общем случае существует около двадцати классов отслеживаемых событий. Каждый класс имеет два имени — полное и сокращенное. Список классов аудита включает в себя:

no_class. исключается из классификации

file_read. события, связанные с чтение

file_write. модификация файлов

file_attr_acc. доступ к атрибутам файла

file_attr_mod. модификация атрибутов файла

file_creation. создание объекта

file_deletion. уничтожение объекта

file_close. системный вызов close

process. операции, связанные с процессами: fork, exec и др.

network. сетевые события: доступ, контакт и т.д.

ipc. операции межпроцессного взаимодействия

non_attrib. события без атрибутов

administrative. действия администрирования

login_logout. вхо

application. события, связанные с приложениями

ioctl. системный вызов ioctl

exec. выполнение программ

other. прочие события

Для любого класса устанавливается один из трех флагов аудита: аудит в случае успешного выполнения действия, аудит неудачных попыток, безусловный аудит. Все указанные описания содержатся в файле /etc/security/audit_control.

Если желательно проводить аудит действий каких-либо пользователей в большем или меньшем объеме, чем всех остальных, администратору достаточно внести соответствующие изменения в файл /etc/security/audit_users.

Аудит-демон выполняется от имени суперпользователя. Соответственно, владельцем всех создаваемых им файлов является пользователь root. Даже если никаких классов для аудита не определено, аудит-демон постоянно работает, причем в каждый момент времени может существовать только один экземпляр демона. В случае, если проведение аудита наталкивается на какие-либо трудности (пример — исчерпание дискового пространства), аудит-демон с помощью программы audit_warn посылает соответствующее сообщение системному администратору.

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

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

• проведение детального аудита среди определенного процента случайно выбранных пользователей;
• полный мониторинг пользователей, в поведении которых проявляется что-либо необычное;
• анализ регистрационной информации в реальном времени с мгновенной реакцией административной программы.

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

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

Встроенные средства аудита позволяют проводить подробный мониторинг событий, связанных с безопасностью ОС Solaris 2.x (системными ресурсами) на системном и частично сетевом уровнях работы информационной системы.

Сетевые средства защиты

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

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

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

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

Защита на сетевом уровне в Solaris 2.x охватывает определенный набор сервисов, достаточно важных и часто используемых, а именно: NIS+ и RPC (NFS). Дополняет указанные меры поддержка в Solaris 2.x клиентской части сервера аутентификации Kerberos, что защищает такие "открытые" сервисы, как telnet и rlogin/rsh.

Защита информации в NIS+

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

Сервис NIS+ работает на основе набора таблиц, содержащих сведения о машинах, параметрах удаленной загрузки, паролях, ключах аутентификации машин локальной сети, пользователях и группах, подсетях, сетевых масках, адресах Ethernet, сервисах, протоколах, параметрах автоматического монтирования удаленных файловых систем и удаленного вызова процедур (RPC). Поскольку указанная информация является весьма важной с точки зрения безопасности информационной системы, ее надежная защита с учетом всех трех критериев (конфиденциальность, целостность, доступность) абсолютно необходима. Такая защита реализуется при задействовании механизмов авторизации и аутентификации NIS+.

Права доступа в NIS+ определяют, какие операции доступны тому или иному NIS-клиенту. Операции в NIS+ подразделяются на четыре класса: чтение (Read), модификация (Мodify), создание (Create), удаление (Destroy). Каждое взаимодействие между клиентом и сервером может сводиться к запросу на проведение действий какого-либо из этих классов, и соответственно авторизовываться.

В NIS+ различаются четыре категории сетевых субъектов: владелец (Owner), группа владельца (Group), все (World), никто (Nobody), причем эти категории не совпадают с упоминавшимися выше категориями пользователей ОС Solaris и администрируются независимо.

В NIS+ имеется три уровня режима безопасности. Уровень 0 используется для тестирования и установки начального набора имен. В этом режиме любому пользователю NIS+ разрешен доступ к любому из объектов. Уровень 1 также применяется на стадии тестирования и отладки. В этом режиме используется тип аутентификации LOCAL, когда параметром служит идентификатор пользователя. В случае, если он не будет найден, клиенту предоставляются права Nobody. При этом все механизмы авторизации работают в полной мере. Наконец, на уровне 2 производится аутентификация клиентов NIS+ с использованием DES-ключей, которая и будет рассмотрена далее.

NIS+ разделяет клиентов, в зависимости от требуемого сервиса, на две категории: клиент-пользователь и клиент-машина. Клиент выступает как клиент-машина, если запрашиваемый им сервис предполагает получение полномочий привилегированного пользователя (root). Каждому клиенту соответствует удостоверение (credentials), при помощи которого и производится аутентификация. Удостоверение состоит из сетевого имени (unix.UserID@domainname для клиента-пользователя либо unix.HostName@domainname для клиента-машины) и поля верификации, с помощью которого проверяется подлинность и аутентичность удостоверения.

Все удостоверения NIS+ хранятся в одной из таблиц базы данных сетевого информационного сервиса, называемой "Cred table". Для каждого клиента в таблице содержится его имя, тип аутентификации, сетевое имя, открытый (public) и секретный (private) ключи. Удостоверение для каждого из клиентов создается администратором сети (домена сети). Сервер, обслуживающий NIS+, называется мастер-сервером.

Удостоверения клиентов создаются при помощи программы nisaddcred. Эта программа формирует из идентификатора пользователя и имени домена сетевое имя, после чего заносит его в соответствующую таблицу. Для генерации ключей nisaddcred использует сетевой пароль клиента, который может и не совпадать с пользовательским паролем, записанным в файле /etc/shadow. На основании пароля генерируется пара 192-битных ключей в соответствии с алгоритмом Диффи-Хелмана. Ключи также заносятся в NIS+ таблицу.

При посылке запроса на NIS-сервер по умолчанию предполагается, что используется уровень безопасности 2. Если это оказывается не так, последовательно посылаются удостоверения уровней 1 и 0.

Перед генерацией удостоверений уровня 2 (DES-аутентификация) клиент обязан воспользоваться командой keylogin, предоставляющей доступ к его секретному ключу. Команда keylogin берет секретный ключ в таблице NIS+, расшифровывает его с помощью сетевого пароля и помещает в локальную базу данных. Клиент запоминает также открытый ключ сервера, необходимый для посылки последующих запросов.

Рассмотрим процесс аутентификации более подробно. В качестве первого шага клиент по алгоритму Диффи-Хелмана генерирует DES-ключ и порождает временной штамп. Этот штамп кодируется DES-ключом и присоединяется к прочей информации, содержащейся в удостоверении клиента, образуя поле верификации.

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

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

Рассмотрим теперь процедуру авторизации в NIS+. Как уже упоминалось, существуют четыре категории, в соответствии с принадлежностью к которым в NIS+ назначаются права доступа: владелец, группа владельца, все, никто. К первой категории может быть отнесен клиент, создавший данный объект или получивший его в собственность при помощи процедуры nischown. Как правило, для этой категории возможен любой из видов доступа — либо непосредственно, либо путем изменения соответствующих атрибутов, на что владелец также имеет право.

Один или несколько NIS+ клиентов могут составлять NIS+ группу, на которую распространяются права доступа, присущие категории Group, по аналогии с правами доступа в файловой системе. Информация о NIS+ группах хранится в NIS+ таблице "Объекты".

Любой клиент, прошедший аутентификацию NIS+, получает права категории World. Если же аутентификация не была проведена (не поступило удостоверения клиента), клиент может получить права категории Nobody. Если же удостоверение поступило, но было неправильным, права Nobody на этого клиента не распространяются: ему автоматически запрещается получение сервиса (Рис. 3).

Таблицы NIS+ имеют дополнительный уровень защиты, не предоставляемый для других типов NIS+ объектов. Этот уровень построен на раздельном доступе к строкам и столбцам. Таким образом, для таблицы, в зависимости от требуемого клиентом сервиса, могут проверяться права на доступ к самой таблице, к данной строке и данному столбцу.

Защита RPC и NFS

Аналогичная идеология аутентификации применяется при реализации другого важного сервиса — сетевой файловой системы (NFS). NFS — исключительно мощный и удобный сервис, однако его использование сопряжено с угрозами безопасности информационной системы. По умолчанию NFS-сервер проводит аутентификацию клиента-машины, а не клиента-пользователя, что дает возможность несанкционированно получить привилегии суперпользователя (root).

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

Как и в случае NIS+, каждый клиент-пользователь и клиент-машина имеют открытый и секретный ключи. При помощи программы keylogin проводится дополнительная аутентификация пользователя, расшифровывается его секретный ключ и передается программе keyserver, участвующей в процедуре RPC. Программа keyserver с секретным ключом пользователя ожидает запроса на RPC-сервис.

С началом транзакции keyserver генерирует случайный сеансовый ключ. Этим ключом шифруется временной штамп машины-клиента. Затем находится открытый ключ сервера и вырабатывается DES-ключ, с помощью которого шифруется ключ сеанса.

Формируется удостоверение клиента, включающее в себя сетевое имя, зашифрованный сеансовый ключ, допустимая разница времени между клиентом и сервером, и шифрованный временной штамп (Рис. 4).

Когда сервер принимает запрос клиента, программа keyserver, установленная на машине-сервере, ищет открытый ключ клиента в своей базе данных и вырабатывает DES-ключ, используемый для расшифровки ключа сеанса. С помощью последнего расшифровывается временной штамп, полученный от клиента, и сравнивается с текущим временем сервера. Аутентификация считается удачной, если разность времени находится в пределах полученного "окна". Удостоверение клиента запоминается сервером, чтобы противостоять попыткам нелегальной аутентификации путем воспроизведения перехваченной информации.

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

При использовании механизмов аутентификации, встроенных в Solaris 2.x, необходимо учитывать следующее:

• Если произошло нарушение безопасности сервера при работе в режиме защищенного RPC, все ключи сервера и клиентов, содержащиеся в базе keyserver, должны быть изменены.
• Должна быть обеспечена физическая защищенность сервера.
• В момент загрузки бездисковых станций режим защищенного RPC не работает, следовательно, возникает угроза безопасности.
• Нельзя применять программу keylogin при удаленном доступе на ненадежные машины, поскольку в этом случае туда посылается секретный ключ пользователя.

Kerberos-клиент

Современные информационные системы, как правило, разнородны как с точки зрения аппаратных средств, так и с точки зрения применяемых операционных систем. Достаточно популярной является комбинация UNIX-серверов с рабочими местами на базе ПК с ОС Windows NT или MS-DOS с соответствующим сетевым расширением. Количество сервисов, требующихся для каждого пользователя, может быть велико, причем некоторые сервисы могут требоваться неявно. Это делает актуальной задачу выделения аутентификации в сетевой конфигурации в особый сервис, с назначением сервера аутентификации.

Стандартом де-факто такого сервера является Kerberos, разработанный в Массачусетском технологическом институте. В настоящее время практически все коммерческие системы аутентификации, как сетевого уровня (CygnusKerberos, OpenVSecure), так и уровня приложений (Tuxedo), реализуют именно этот стандарт.

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

Работа в качестве Kerberos-клиента поддерживается в ОС Solaris. В частности, пользователь Solaris может генерировать удостоверение, передаваемое серверу аутентификации, используя команду kinit, и заканчивать сеанс при помощи команды kdestroy. Особенностью системы Solaris 2.x является возможность применить протокол Kerberos для файловых систем NFS. Это позволяет реализовать единый механизм аутентификации для всех видов сетевых сервисов.

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

Безопасность X-приложений

Одной из характерных черт современной операционной системы является возможность использования многооконного интерфейса для работы пользователей. Как и большинство UNIX-систем, ОС Solaris использует стандарт X11R5 Массачусетского технологического института. Этот стандарт построен на основе технологии "клиент-сервер", и, соответственно, предполагает предоставление сервиса каждым сервером для любого из клиентов.

Поскольку X-сервер управляет такими ресурсами, как экран, клавиатура, "мышь", необходимо проводить разграничение доступа к этим ресурсам. При этом, с одной стороны, пользователь должен иметь возможность вызывать как локальные, так и удаленные X-приложения, в том числе выступая под различными пользовательскими именами, с другой стороны, несанкционированный доступ к этим ресурсам должен быть невозможен.

Для решения сформулированной задачи применяются различные варианты авторизации, поддерживаемые X-сервером. Наиболее простой вариант предполагает авторизацию по имени машины, запрашивающей сервис. Сопоставляя это имя со списком доступа, содержащимся в файле /etc/Xn.hosts и модифицируемым командой host, сервер разрешает или запрещает выполнение запроса клиента.

Поскольку такой механизм авторизации заведомо недостаточен (разрешая работать своим удаленным приложениям, Вы неявно разрешаете работу приложений всех других пользователей этой машины), в X11 применяется механизм авторизации пользователей, называемый MIT-MAGIC-COOKIE. В этом случае, когда происходит инициализация сервера, генерируется последовательность байт, которая записывается в файл .Xauthority пользователя, открывающего сеанс на данном дисплее. После этого любой клиент получит разрешение на работу в данном сеансе только после предоставления этого кода серверу. Права доступа к файлу .Xauthority установлены в виде -rw----, что разрешает его чтение только владельцу.

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

Начиная с версии Solaris 2.5, предоставляется возможность проведения авторизации/ аутентификации X-клиента с использованием сервера аутентификации Kerberos.

Обеспечение доступности данных с помощью Online DiskSuite/Networker

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

Как правило, данные и программы хранятся на дисках — либо в рамках файловых систем, либо в виде неструктурированных разделов (raw partitions). Требование, состоящее в том, чтобы к этим информационным ресурсам можно было обращаться в любой момент, и чтобы такая операция занимала минимальное время, выглядит бесспорным. Однако существует вероятность сбоя в работе дисков в результате неправильных действий пользователя, аппаратной ошибки или иных причин. Это заставляет использовать дополнительные средства для увеличения надежности системы и, соответственно, доступности данных.

Одним из средств, позволяющих увеличивать надежность работы с дисковыми накопителями, является входящий в стандартный комплект ОС Solaris продукт Online DiskSuite.

Апробированным средством повышения производительности и надежности дисковых систем является использование избыточных массивов недорогих дисков (RAID). RAID-технология подразделяется на несколько уровней. Уровень RAID-0 предполагает рассеивание информации по дискам (striping), когда логически последовательные блоки попадают на разные устройства. Он применяется для увеличения производительности системы, то есть минимизации времени доступа к ее ресурсам за счет распараллеливания обменов с дисками.

На уровне RAID-1 производится зеркалирование (mirroring) дисков. Очевидно, что в случае каких-либо сбоев на одной части "зеркальной" дисковой системы, данные могут быть легко восстановлены с другой части. Недостатком этого подхода является увеличение времени доступа и необходимость удвоения объема дисковой памяти.

Как правило, реализуется комбинация обоих уровней (striping + mirroring), называемая RAID0+1.

Для реализации упомянутых подходов Online DiskSuite создает псевдодрайвер диска и помещает его между пользовательскими приложениями и драйверами дисковых подсистем. Псевдодрайвер принимает пользовательские запросы на ввод/вывод и прозрачным для приложений образом переадресовывает их реальным устройствам. С точки зрения пользователя, происходит увеличение скорости и надежности работы дисков без каких-либо аппаратных модификаций (Рис. 5).

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

Важным достоинством дисковых подсистем на основе Online DiskSuite является возможность динамического изменения размеров файловой системы без остановки ее работы.

Начиная с версии 4.0, Online DiskSuite обладает продвинутым графическим пользовательским интерфейсом, делающим действия по формированию и администрированию файловых систем простыми и наглядными.

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

Для проведения резервного копирования ресурсов распределенной информационной системы, целесообразно проводить этот процесс централизованно на какой-либо одной машине (выделенном backup-сервере). Такая политика имеет следующие достоинства:

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

В состав ОС Solaris входит программа NetWorker, позволяющая реализовать все преимущества централизованного создания резервных копий в рамках разнородной сети предприятия. Основными достоинствами этой программы являются:

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

Средства дополнительной защиты систем с ОС Solaris 2.x

Анализируя средства дополнительной защиты систем с ОС Solaris, прежде всего необходимо выяснить, с какой целью такая защита устанавливается. В самом деле, как следует из приведенного выше материала, Solaris является достаточно надежной системой, соответствующей пятому классу защищенности средств вычислительной техники по классификации Гостехкомиссии РФ (классу C2 по критериям Национального Центра Компьютерной безопасности США). Существует, однако, некоторая разница между защищенностью самой ОС и безопасностью информационной системы, работающей под ее управлением. В этом смысле верна аналогия с физическим прибором, который всегда измеряет исключительно свои собственные параметры (термометр знает только о собственной температуре, амперметр измеряет только ток, который течет непосредственно через него и т.д.).

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

Средств, позволяющих расширить в том или ином направлении возможности защиты информационных ресурсов систем, находящихся под управлением ОС Solaris, существует немало, и их полное описание не является целью данной статьи. Приводимые примеры лишь показывают разные варианты применения дополнительных средств защиты на основных функциональных уровнях.

Говоря об уровне системной защиты, где сосредоточены основные встроенные средства ОС Solaris, целесообразно кратко рассмотреть одно из наиболее сильных средств защиты от несанкционированного доступа — CA-Unicenter.

Реализация политики безопасности средствами CA-Unicenter

CA-Unicenter является программным продуктом, обеспечивающим поддержку администрирования больших распределенных систем.

В CA-Unicenter вся информация, относящаяся к обеспечению защиты, хранится в особой базе данных (под управлением СУБД Ingres). Эта реляционная база обеспечивает гибкость в описании политики безопасности путем определения защищаемых ресурсов или активов (assets). Системе безопасности доступна вся информация, касающаяся каждой пары ресурс/пользователь, и на ее основе вырабатывается решение о доступе либо запрете доступа пользователя к запрашиваемым ресурсам. Наличие такой базы данных позволяет легко вводить дополнительные ограничения, такие как временной контроль, или новые группы — пользователей или ресурсов. Кроме того, вновь создаваемые файлы защищаются сразу и без вмешательства пользователя в соответствии с критериями политики безопасности. Подобный подход открывает возможность администрирования системы с большим количеством пользователей без дополнительных усилий.

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

По каждому запросу на доступ к ресурсам принимаются два основных решения. Во-первых, проверяется, имеются ли соответствующие права доступа к данному ресурсу для пользователя, делающего запрос, и если нет, то выдается диагностика "нарушение". Затем определяется поведение системы при наличии нарушения.

Для любого ресурса или группы ресурсов могут быть установлены следующие режимы доступа:

• доступ разрешен;
• доступ отличен от разрешенного;
• факт доступа протоколируется.

Утилиты calendars и criteria profiles позволяют устанавливать дополнительные ограничения на доступ к тем или иным группам ресурсов.

Реакция на нарушение прав доступа определяется в CA-Unicenter значением параметра enforcement mode. Возможны следующие значения:

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

warn. доступ к неразрешенным ресурсам открыт, но CA-Unicenter выдает пользователю предупреждение и протоколирует его действия.

monitor. реакция аналогична предыдущей, но пользователь не предупреждается.

quiet. система разграничения доступа не действует.

Необходимо также заметить, что CA-Unicenter предваряет действия операционной системы по защите ресурсов, то есть механизм контроля доступа ОС UNIX начинает действовать в случае успешного прохождения запроса на использование ресурсов через "фильтр" CA-Unicenter.

В числе других возможностей CA-Unicenter по обеспечению безопасности упомянем средства контроля за назначением и использованием паролей. Эти средства позволяют для каждого пользователя проводить назначение и изменение пароля, устанавливать временные ограничения на его действие, генерировать случайный пароль, отслеживать историю изменения пароля, а также попыток некорректного входа и нарушений установок службы безопасности.

CA-Unicenter снабжен дружественным пользовательским интерфейсом, позволяющим быстро и эффективно устанавливать перечисленные компоненты и режимы службы безопасности.

CA-Unicenter предоставляет мощные и, в то же время, гибкие механизмы разграничения доступа. Имеется легко настраиваемый инструментарий для установки прав доступа к ресурсам в системе с практически неограниченным числом пользователей. Указанная возможность, несомненно, дает администратору CA-Unicenter значительные преимущества по сравнению с обычной ОС (например, Solaris).

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

В то же время, CA-Unicenter не является панацеей от всех бед. В частности, серьезным недостатком оказывается отсутствие средств защиты от перехвата пакетов в сети при работе процедур telnet, rlogin. В этом случае как имеющиеся в ОС Solaris собственные средства обеспечения безопасности при работе в сети с распределенными ресурсами (такие как NIS+, SecureRPC), так и независимые разработки (семейство программных продуктов класса Kerberos) эффективно дополняют службу безопасности, построенную на основе CA-Unicenter.

Повышение безопасности локальных сетей средствами SSH

Рассмотрим теперь расширения средств ОС Solaris на уровне локальной сети. Как указывалось выше, далеко не все сетевые сервисы являются безопасными; скорее верно противоположное утверждение. Варианты применения сложных схем с сервером аутентификации типа Kerberos, во-первых, не всегда оправданы (поскольку усложняют управление и администрирование системы), а, во-вторых, не закрывают всего диапазона требуемых сервисов. Промежуточным средством в этом случае является, например, разработанная в Технологическом Университете Хельсинки программа Secure SHell (SSH).

SSH представляет собой программу, позволяющую получать удаленный доступ в распределенной информационной системе, а также удаленно выполнять команды и пересылать файлы. При этом осуществляется аутентификация по схеме RSA, а данные пересылаются по открытым каналам в зашифрованном виде, причем кодирование/декодирование проводится незаметно для пользователя ("прозрачный" режим). Кроме того, обеспечивается безопасность работы по X-протоколу, а также отсутствие недостатков в защите, связанных с DNS.

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

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

После проведения аутентификации, клиент генерирует некоторое количество запросов, требуемых для этого сервиса. К типичным запросам относятся выделение псевдотерминала, запуск X11, старт агента аутентификации либо запуск команды/командного интерпретатора.

В протокол заложены возможности будущего расширения, для чего в идентификационное сообщение включается номер версии. Кроме того, там же содержится поле флагов протокола, приводящее в соответствие установки клиента и сервера.

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

Применение SSH совместно с встроенными средствами ОС Solaris повышает безопасность использования большинства сервисов на уровне локальной сети.

Внешняя защита: Firewall-1

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

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

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

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

Sun Microsystems предлагает в качестве решения для уровня внешней защиты продукт Solstice Firewall-1, представляющий собой набор функциональных модулей, позволяющих реализовать управление информационными потоками на всех уровнях семиуровневой модели ISO/OSI, начиная со второго. Firewall-1 устанавливается на физически защищенный компьютер, через который проходит весь трафик, передаваемый между внутренней и внешней сетями. Различают следующие виды функциональных модулей.

Модули фильтрации пакетов (Packet Filter Module, PFM) анализируют все входящие и исходящие пакеты в соответствии с правилами, устанавливаемыми сетевым администратором и записанными в соответствующей базе данных. PFM реализует нормативную политику безопасности — все данные, по поводу которых нет явного разрешения, отбрасываются. Разумеется, ведется регистрационный журнал.

Кроме обычного PFM, может использоваться модуль с проведением аутентификации, схема которой аналогична схеме аутентификации клиента в NIS+.

Для управления работой PFM используется модуль управления фильтрами (Filter Manage-ment Module, FMM). Один FMM может контролировать несколько модулей PFM, что дает дополнительные удобства централизованного администрирования в случае предприятий с несколькими межсетевыми экранами. Важное достоинство модуля управления в Firewall-1 — дружественный графический интерфейс.

Для формирования списков управления доступом и проведения мониторинга/аудита отдельных серверов и маршрутизаторов используются модули расширений (Router & Server security extension).

В целом Firewall-1 представляет собой мощное и легко настраиваемое средство внешнего уровня защиты.

Заключение

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

С точки зрения защиты ресурсов самой операционной системы, Solaris предоставляет полный набор инструментов, решающих данную задачу. Достоинством ОС Solaris является наличие встроенных средств контроля системных ресурсов (ASET) и средств системного аудита. Более того, ряд сетевых ресурсов, с которыми работает компьютер под управлением ОС Solaris, наряду с функционально полезными сервисами также имеют встроенные средства защиты.

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

На наш взгляд, описанный в данной статье набор механизмов безопасности надежно защищает корпоративные информационные системы, построенные на фундаменте ОС Solaris 2.x.