Как и в любой гонке вооружений, ответом на появление новых средств нападения является разработка адекватных средств защиты.
В статье "Информационная безопасность в Intranet", опубликованной в предыдущем номере журнала "LAN Magazine/Русское издание", мы рассмотрели концепции, лежащие в основе обеспечения информационной безопасности Intranet. Теперь мы переходим к рассмотрению аппаратно-программных решений, реализующих описанные концепции. Разумеется, к числу абсолютно необходимых принадлежат также меры и методики административного уровня (например методика разработки политики безопасности) и процедурного уровня (в частности инструкции для пользователей и администраторов, регламенты сервисного обслуживания). Тем не менее эти два уровня мы обсуждать не будем, поскольку соответствующие сведения составляют "ноу-хау" каждой компании, занимающейся информационной безопасностью.
FIREWALL-1
FireWall-1 - это программный продукт компании CheckPoint Software Technologies (распространяемый также некоторыми другими компаниями, скажем SunSoft), обеспечивающий комплексное решение технических проблем информационной безопасности в Intranet. FireWall-1 предоставляет следующие возможности:
- межсетевое экранирование;
- поддержку виртуальных частных сетей;
- защиту коммуникаций между сервером и удаленным клиентом.
FireWall-1 - это проверенный продукт, завоевавший около 40% рынка межсетевых экранов, удостоенный многочисленных наград компьютерных изданий и независимых центров тестирования. В основе FireWall-1 лежит новаторская технология многоуровневой фильтрации с формированием и анализом состояния сетевых соединений, предоставляющая надежную защиту для всех без исключения сетевых протоколов в сочетании с высокой эффективностью и полной прозрачностью для легальных пользователей. Эта технология дополнена средствами централизованного администрирования (конфигурации, анализа и аудита) защитных механизмов, а также логически замкнутым набором криптографических средств.
FireWall-1 состоит из двух основных компонентов:
Далее мы рассмотрим (применительно к версии 2.1 программного продукта) функции каждого из модулей.
УПРАВЛЯЮЩИЙ МОДУЛЬ FIREWALL-1
После установки управляющего модуля на управляющей рабочей станции с операционной системой Solaris, HP-UX или Windows NT начинается первый и во многом определяющий этап - формирование базы правил, которые будут использоваться в процессе фильтрации. База правил представляет собой формализованное отражение сетевых аспектов политики безопасности организации.
Компонентами правил являются объекты, пользователи и сервисы. Следовательно, прежде чем приступать собственно к заданию правил, необходимо описать конфигурацию защищаемой сети и ее окружения.
ОПИСАНИЕ СЕТЕВЫХ ОБЪЕКТОВ
Конфигурация FireWall-1 начинается с описания объектов, которые межсетевой экран должен защищать. В число объектов входят хосты (компьютеры с одним сетевым интерфейсом), шлюзы (компьютеры с несколькими сетевыми интерфейсами), маршрутизаторы, сети, области управления. Кроме того, объекты можно объединять в группы.
Каждый объект имеет набор атрибутов, таких как сетевой адрес, маска подсети и т.п. Часть этих атрибутов следует задать вручную, остальные извлекаются автоматически из информационных баз, например NIS/NIS+, SNMP MIB, DNS.
Рисунок 1, на котором приведен внешний вид окна управления сетевыми объектами, иллюстрирует базовые возможности по определению объектов и по редактированию их конфигурации.
Рисунок 1.
Окно управления сетевыми объектами FireWall-1.
Обратим внимание на необходимость полного описания объектов. Так, убедиться в корректности правил фильтрации можно только тогда, когда определены все сетевые интерфейсы шлюзов и маршрутизаторов. Как правило, подобную информацию можно получить автоматически от SNMP-агентов.
Одной из самых распространенных и опасных угроз в сетевой среде является подделка адресов с целью имитации того, что пакет пришел из более привилегированной сети. Для борьбы с подобными подделками FireWall-1 позволяет связывать с сетевым интерфейсом набор допустимых исходных адресов и посылать сигнал тревоги при попытке нарушения наложенных ограничений. Так, на Рисунке 2 определено, что пакеты из "прочих" сетей (то есть из сетей, отличных от зарегистрированных) могут приходить только на внешний сетевой интерфейс (le1).
Рисунок 2.
Окно свойств хоста с ограничениями на сетевые адреса пакетов.
Аналогичные средства для борьбы с подделкой сетевых адресов существуют и для маршрутизаторов. Отметим, что FireWall-1 поддерживает маршрутизаторы компаний Cisco Systems и Bay Networks.
ОПИСАНИЕ ПОЛЬЗОВАТЕЛЕЙ И ГРУПП ПОЛЬЗОВАТЕЛЕЙ
FireWall-1 позволяет разграничивать доступ пользователей, определяя для них допустимые исходные и целевые сетевые адреса, диапазон дат и времени работы, а также схему аутентификации.
Поддерживаются следующие схемы аутентификации:
Кроме перечисленных атрибутов пользователи, разумеется, наделяются входными именами.
При администрировании пользователи объединяются в группы, причем эти группы могут быть компонентами правил.
ОПИСАНИЕ СЕТЕВЫХ СЕРВИСОВ
Используемый сетевой сервис является компонентом правил фильтрации наряду с исходным и целевым адресом. Прежде чем применять сервис при задании правил, необходимо определить его свойства. FireWall-1 содержит предварительно подготовленные определения всех стандартных TCP/IP-сервисов, разбитых на четыре категории - TCP, UDP, RPC, ICMP. Пятая категория, Others, оставлена для нестандартных сервисов. В подавляющем большинстве случаев она остается пустой. Нестандартные (или по-особому трактуемые стандартные) сервисы могут определяться и в пределах первых четырех категорий.
Сервисы UDP традиционно трудны для фильтрации, поскольку фаза установления виртуального соединения отсутствует, равно как и контекст диалога между клиентом и сервером. FireWall-1 сам вычисляет этот контекст, отслеживая все UDP-пакеты, пересекающие межсетевой экран в обоих направлениях, и ассоциируя запросы с ответами на них. В результате получается аналог виртуального соединения для дейтаграммного протокола, а все попытки нелегального установления подобного соединения, равно как и дейтаграммы, следующие вне установленных соединений, обрабатываются в соответствии с выбранной политикой безопасности.
RPC-сервисы сложны для фильтрации из-за переменных номеров используемых портов. FireWall-1 отслеживает RPC-трафик, выявляя запросы к функции portmapper и извлекая из ответов выделенные номера портов.
Описание нового, нестандартного, сервиса - действие чрезвычайно редкое. Оно требует знания тонкостей сетевых протоколов, а также применяемого в FireWall-1 языка определения правил фильтрации Inspect. На Рисунке 3 показано окно определения общих свойств сервиса.
Рисунок 3.
Окно определения общих свойств сервиса.
Мы видим, что FireWall-1 сочетает простоту использования стандартных возможностей со средствами расширения набора фильтруемых протоколов. Это очень важное достоинство, являющееся следствием продуманной архитектуры системы и выбранного подхода к фильтрации.
УПРАВЛЯЮЩИЕ ХАРАКТЕРИСТИКИ
Управляющие характеристики, по сути, являются частью базы правил, поскольку они влияют на фильтрацию сетевых сервисов. Кроме того, управляющие характеристики задают режимы регистрации и возбуждения сигналов тревоги, способ разрешения сетевых имен. Они определяют также взаимодействие FireWall-1 с маршрутизаторами и аутентификацию пользователей и клиентов сервисов.
На Рисунке 4 изображено окно, в котором задаются общие параметры фильтрации. Можно видеть, что в FireWall-1 заранее учтены сложности, вносимые в процесс фильтрации сетевыми протоколами. Например, стандартная реализация протокола FTP использует запрос от сервера к клиенту на установление соединения с нефиксированным номером порта. Отслеживая команду PORT протокола FTP, FireWall-1 выявляет подобные запросы среди прочих попыток установления виртуального соединения и реагирует на них в соответствии с выбранной политикой безопасности.
Рисунок 4.
Окно определения общих параметров фильтрации.
FireWall-1 позволяет проводить аутентификацию клиентов любого сервиса (стандартного или специфичного для конкретной организации) независимо от того, основан ли он на протоколе TCP, UDP или RPC.
АДМИНИСТРИРОВАНИЕ БАЗЫ ПРАВИЛ
На управляющей станции FireWall-1 строится единая база правил, отражающих сетевые аспекты политики безопасности организации. Обычно эта база создается средствами графического интерфейса, однако возможно и непосредственное программирование на языке описания фильтрации Inspect.
На Рисунке 5 изображена верхняя часть окна редактора базы правил. Этот рисунок поможет нам понять, из чего правила состоят и как они применяются.
Рисунок 5.
Окно редактора базы правил.
Первые два поля каждого правила (Source и Destination) задают исходный и целевой адреса фильтруемых сетевых пакетов. В третьем поле (Services) перечисляются рассматриваемые сетевые сервисы. Подразумеваемым значением этих полей является Any, то есть правило применяется ко всем адресам и сервисам.
В четвертом поле (Action) задается действие, совершаемое над сетевым пакетом (пропустить, отвергнуть, аутентифицировать, шифровать). Отвергнуть пакет можно двумя способами - с извещением источника (это подразумеваемое действие) и без такового.
Пятое поле (Track) определяет режимы протоколирования и возбуждения сигналов тревоги. По умолчанию никаких регистрационных действий не предпринимается.
Шестое поле (Install On) задает объекты, к которым данное правило будет применяться. Это может быть хост (и тогда он защищает только себя), маршрутизатор или шлюз. Таким образом, не нарушая централизованности базы правил, разные правила можно применять к разным объектам.
По умолчанию последним располагается правило "отвергнуть все". Тем самым реализуется принцип "все, что не разрешено, запрещено".
После того как база правил сформирована, она проверяется на непротиворечивость. Это очень важный момент, особенно для развитых, многокомпонентных конфигураций со сложной политикой безопасности. Без подобной возможности администрирование межсетевого экрана с неизбежностью ведет к многочисленным ошибкам и созданию слабостей.
Наконец, база правил преобразуется в текст на языке Inspect, а затем выполняется компиляция, результат которой передается на все объекты, вовлеченные в процесс фильтрации.
Приведем несложный пример сетевой части политики безопасности и соответствующей ей базы правил.
Пусть имеется конфигурация, приведенная на Рисунке 6. Локальная сеть (localnet) должна предоставлять вовне только почтовый сервис. В то же время в распоряжении пользователей локальной сети должны быть все сетевые сервисы, внутренние и внешние. В экранирующей подсети (dmz) располагаются общедоступные серверы http и ftp; сами эти серверы не должны выступать в роли инициаторов сетевых сеансов. Авторизованным пользователям, располагающимся во внешней сети, разрешен удаленный доступ в локальную сеть. Наконец, следует позаботиться о том, чтобы экранирующий шлюз был прозрачен для сетевого трафика, т.е. чтобы он не мог выступать в роли отправителя или получателя сетевых пакетов. Результирующий набор правил изображен на Рисунке 7.
(1х1)
Рисунок 6.
Конфигурация с локальной сетью и экранирующей подсетью.
Рисунок 7.
Набор правил для защиты конфигурации, изображенной на Рисунке 6.
РАСПРЕДЕЛЕНИЕ КРИПТОГРАФИЧЕСКИХ КЛЮЧЕЙ
Управляющая станция, отвечающая за централизованное администрирование конфигурации из нескольких межсетевых экранов, выполняет также роль центра распределения криптографических ключей. Более точно, она генерирует для всех экранов пару ключей (открытый/секретный) для применения алгоритма Диффи-Хелмана и служит сертификационным центром, обслуживающим запросы на получение ключей.
На управляющей станции можно генерировать новые ключи. Другие шлюзы, как правило, просто получают ключи из сертификационного центра.
РЕАЛИЗАЦИЯ УПРАВЛЯЮЩЕГО МОДУЛЯ В АРХИТЕКТУРЕ КЛИЕНТ-СЕРВЕР
Управляющий модуль может функционировать в режиме клиент-сервер, когда администрирование выполняется с рабочей станции, работающей под управлением операционной системы Win-dows NT/95. Управляющий сервер выполняет все содержательные действия, а клиентская станция обеспечивает графический интерфейс.
Для защиты коммуникаций между клиентом и сервером и для обеспечения аутентификации удаленных клиентов может использоваться модуль SecuRemote, устанавливаемый на клиентском компьютере. Этот модуль совместим с любым стеком протоколов TCP/IP и с любыми сетевыми адаптерами. Тем самым SecuRemote оказывается универсальным средством криптографического закрытия клиентских коммуникаций.
ЭКРАНИРУЮЩИЙ МОДУЛЬ FIREWALL-1
Экранирующий модуль FireWall-1 устанавливается на всех компонентах корпоративной сети, производящих фильтрацию сетевых потоков данных. Это могут быть серверы с одним сетевым интерфейсом (тогда модуль защищает только данный сервер) или шлюзы с несколькими интерфейсами (тогда модуль экранирует подсеть).
Экранирующий модуль решает три основные задачи:
- фильтрацию сетевого трафика;
- протоколирование информации и возбуждение сигналов тревоги;
- шифрование/дешифрование информации.
Экранирующий модуль встраивается в ядро операционной системы между канальным и сетевым уровнями. Он перехватывает все пакеты, поступающие из/в сетевой карты, и обрабатывает их в соответствии со специфицированной базой правил. Такая обработка производится для каждого сетевого интерфейса на серверах и шлюзах. При фильтрации все правила, заданные для данного интерфейса, просматриваются по очереди. Если подходящее правило найдено, выполняются заданные в нем действия (протоколирование, шифрование и т.д.), после чего пакет пропускается или отвергается. Таким образом, экранирующий модуль FireWall-1 работает до и независимо от сетевых механизмов операционной системы. Работа в пространстве ядра позволяет избежать многочисленных переключений контекстов процессов, что существенно повышает эффективность фильтрации.
Экранирующий модуль FireWall-1 способен выполнять еще одну, очень важную функцию - трансляцию сетевых адресов. Подобная трансляция не только уменьшает потребность в легальных IP-адресах (в пределах защищаемой сети могут использоваться, по существу, произвольные адреса, которые при выходе во внешние сети преобразуются и попадают в диапазон, выделенный данной организации), но и скрывает топологию защищаемой сети, что существенно затрудняет действия злоумышленников.
НОВЫЕ ВОЗМОЖНОСТИ FIREWALL-1 ВЕРСИИ 3
Во второй половине 1996 года компания CheckPoint внесла в свой продукт несколько принципиально важных усовершенствований.
Во-первых, предложила свободно-распространяемое защитное средство SYNDefender, предназначенное для отражения атак.
Во-вторых, в версии 3 FireWall-1 появились следующие новшества:
- возможность антивирусного контроля "на лету";
- возможность фильтрации (верификации байт-кодов) апплетов Java;
- возможность выполнения функций программного обеспечения промежуточного слоя (middleware).
Особенно важным представляется последнее из перечисленных новшеств. ПО промежуточного слоя, как и традиционные межсетевые экраны прикладного уровня, скрывают информацию о предоставляемых сервисах. За счет этого ПО промежуточного слоя может выполнять такие фукнкции, как маршрутизация запросов и балансировка загрузки. Представляется вполне естественным, чтобы эти возможности были реализованы в рамках межсетевого экрана. Это существенно упростит действия по обеспечению высокой доступности экспортируемых сервисов типа переключения на резервные мощности прозрачным для внешних пользователей образом.
SECURE SOCKETS LAYER - ПРОТОКОЛ ЗАЩИТЫ КОММУНИКАЦИЙ
Одним из важнейших фактических стандартов, обеспечивающих информационную безопасность в Intranet и Internet, является протокол Secure Sockets Layer (SSL, см. [6]), разработанный специалистами компании Netscape Communications и поддержанный многими крупнейшими производителями программного обеспечения, такими как Microsoft и IBM.
Этот протокол можно отнести к сеансовому (пятому) уровню эталонной модели ISO/OSI, то есть он располагается выше транспортного, но ниже прикладного уровня. Для приложений, опирающихся на SSL, гарантируется аутентификация пользователей и компьютеров (без передачи имен и паролей в открытом виде), а также целостность и конфиденциальность пересылаемой по сети информации, поддерживается концепция единого входа в информационную систему (когда не надо доказывать свою подлинность каждому серверу в отдельности). Такими приложениями могут быть, например, сервисы HTTP, FTP, SMTP.
В основе протокола SSL лежит использование общепризнанных криптографических решений, наподобие алгоритмов RSA, DES, MD5 и сертификатов, соответствующих спецификациям X.509. В то же время протокол достаточно гибок и допускает применение специфических методов шифрования, в частности ГОСТ 28147-89.
Поддержка SSL и ассоциированных протоколов - SET (Secure Electronic Transactions) и S/MIME (Secure Multipart Internet Mail Encoding) - встроена, по существу, во все продукты компании Netscape Communications. Так, Netscape Navigator обеспечивает проверку подлинности сервера Web, контроль целостности и шифрование сообщений, пересылаемых между клиентами и сервером, причем при установлении соединения алгоритм шифрования может быть выбран по взаимному согласию.
Семейство серверов Netscape SuiteSpot, включающее такие продукты, как Netscape Enterprise Server, Netscape News Server и Netscape Mail Server, позволяет ассоциировать сертификаты клиентов с элементами базы управления доступом. Это упрощает пользовательские действия, поскольку пользователю достаточно войти в свой экземпляр Netscape Navigator, который будет в дальнейшем автоматически вырабатывать и пересылать пользовательские сертификаты. Упрощаются и действия системного администратора, так как вместо того, чтобы поддерживать списки управления доступом на каждом сервере, он может разграничивать доступ в соответствии с тем, какой центр выдал сертификат данного пользователя.
Сертификаты могут использоваться в программах на серверной стороне для более тонкого управления доступом, выполнения действий по доверенности и т.п.
Некоторое время назад в экспортном варианте Netscape Navigator, оперирующем с DES-ключами длиной в 40 бит, были найдены некоторые криптографические слабости. На наш взгляд, данному обстоятельству не следует придавать слишком большое значение, поскольку 40-битные ключи все равно не способны противостоять атакам по методу грубой силы с помощью современных быстродействующих компьютеров. При подобной длине ключей вопрос состоит лишь в том, сколько стоит "взлом". В то же время полноценная реализация Netscape Navigator, насколько нам известно, успешно противостоит криптографическим атакам.
JAVA - БЕЗОПАСНАЯ ПРОГРАММНАЯ СРЕДА
Как указывалось выше, в разделе "Безопасность программной среды", Java-система обеспечивает следующие меры безопасности при создании распределенных приложений:
- надежность языка;
- контроль при получении программ;
- контроль при выполнении программ.
Говоря о надежности языка Java, следует указать следующие особенности.
- Разграничение доступа к компонентам (переменным и методам) объектов. Здесь имеются в виду не только ключевые слова public, protected и private, но и описатель final, обозначающий запрет переопределения (наследования).
- Полный контроль типов. Можно гарантировать, что статический (заданный при компиляции) тип переменной и тип ее значения (определяемый, возможно, при выполнении) совместимы между собой, то есть небезопасные преобразования типов исключены.
- Отсутствие указателей. Это свойство делает невозможным целый класс случайных и преднамеренных ошибок, связанных с адресной арифметикой и с доступом к одному объекту посредством разных ссылок.
- Отсутствие средств явного освобождения памяти. Автоматический сбор мусора гарантирует отсутствие висячих ссылок и дважды занятых блоков памяти. Отметим, что поиск (и даже простое воспроизведение) подобных ошибок всегда был очень трудным и долгим делом.
- Наличие механизма пакетов. Этот механизм позволяет поддерживать деление пространства имен. В частности, пространство имен локальных программ отделено от пространства имен программ, загруженных по сети. Порядок просмотра этих пространств при разрешении внешних ссылок гарантирует то, что загружаемая программа не сможет "заслонить" библиотечные или локальные объекты.
Контроль при получении программ заключается в проверке (верификации) байт-кодов - представления программ, интерпретируемого Java-машиной. Очевидно, что полученная по сети программа может быть изменена злоумышленником и не является результатом работы компилятора Java.
Верификатор байт-кодов кроме общей проверки формата поступившей информации пытается убедиться в отсутствии следующих некорректных действий:
- подделки указателей (например получение указателя в результате выполнения арифметической операции);
- нарушения прав доступа к компонентам классов (скажем присваивание переменной, снабженной описателем final);
- использования объектов в каком-либо другом качестве (допустим применение к объекту метода другого класса);
- вызова методов объектов с недопустимым набором параметров;
- недопустимого преобразования типов;
- вызова операции Java-машины с недопустимым набором параметров;
- некорректной операции с регистрами Java-машины (к примеру запись регистра с неопределенным содержимым);
- переполнения или исчерпания стека.
Выполняются также некоторые другие, более тонкие проверки, связанные, в частности, с корректностью обработки исключительных ситуаций. Реализация верификатора байт-кодов основана на методах анализа потоков данных (аналогичные методы применяются в компиляторах при оптимизации программ).
Чтобы обеспечить безопасное выполнение программ, которые могут осуществлять доступ к локальным файлам и другим ресурсам, в Java-системе используется менеджер безопасности.
Менеджер безопасности представляет собой объект, методы которого проверяют согласованность производимых запросов с принятой политикой безопасности. Стандартная среда Java содержит абстрактный класс SecurityManager, определяющий программный интерфейс с менеджером безопасности. Среди методов этого класса - checkAccess, checkRead, checkWrite, checkExec и т.п. В свою очередь, библиотечные функции содержат вызовы методов класса SecurityManager. Если некоторое действие разрешено, метод завершается обычным образом. В противном случае возбуждается исключительная ситуация SecurityException.
Подразумеваемая реализация методов checkXxx предельно проста:
public void checkXxx (...) {
throw new SecurityException ();
}
Иными словами, создатели языка Java предлагают придерживаться принципа "все, что не разрешено, запрещено". В приложении можно переопределить некоторые методы класса SecurityException, заставив их действовать более избирательно.
Менеджер безопасности - это чрезвычайно гибкое средство. Очевидно, что в процедурном виде можно выразить любую, практически полезную политику безопасности. Дело лишь за корректной реализацией в приложении методов класса SecurityManager.
Следует осознавать границу между концепцией безопасности в языке Java и реализацией среды Java. Если полнота и непротиворечивость концепции в настоящее время являются общепризнанными, то ошибки реализации продолжают обнаруживаться. Впрочем, происходит это не очень часто, ошибки быстро исправляются, а их практическое использование в злонамеренных целях сопряжено со значительными техническими трудностями. Каждая организация должна взвесить все "за" и "против" применения Java в своих системах Intranet. На наш взгляд, достигнутый в Java уровень безопасности можно считать вполне удовлетворительным. Едва ли Java окажется самым слабым звеном.
РАЗГРАНИЧЕНИЕ ДОСТУПА В РАМКАХ HTTPD-СЕРВЕРА
Web-серверы httpd, реализованные Национальным центром суперкомпьютерных приложений (National Center for Supercomputing Applications, NCSA) и совместимые с ними серверы Apache, являются, по-видимому, самыми распространенными в Internet. В этой связи поучительно рассмотреть, как в них реализовано разграничение доступа.
В этих серверах разграничение производится с точностью до каталога документов. В конфигурационный файл, ведающий правами доступа (обычно это access.conf), помещаются директивы Directory, задающие имена каталогов, перечень разрешенных действий и список авторизованных субъектов. Пример:
order deny, allow
deny from all
allow from .jet.msk.su
Данная директива разрешает доступ к каталогу /usr/local/http/docs только пользователям из области управления jet.msk.su. Этим пользователям разрешено получение файлов и выполнение CGI-процедур.
В директиве Directory можно задавать опции, управляющие поведением сервера при обслуживании соответствующих каталогов. Например, директива AllowOverride позволяет в пределах каталога отменять действие централизованного конфигурационного файла и задавать права в локальном файле .htaccess. Такая возможность в полной мере реализует концепцию произвольного доступа, со всеми достоинствами в виде гибкости и недостатками в виде потенциальной потери управляемости и создания слабостей.
Сервер httpd допускает защиту отдельных каталогов с помощью паролей. Это значит, что при попытке доступа пользователь увидит форму, предлагающую ввести входное имя и пароль. Регистрация пользователей и их паролей реализована по образцу ОС Unix, однако следует понимать, что у сервера Web и ОС Unix разные базы пользователей, никакого отношения друг к другу не имеющие.
Приведем пример директивы Directory, которая предусматривает ограничения нескольких видов на доступ к указанному каталогу.
AuthUserFile /etc/http/htpasswd
AuthGroupFile /etc/http/htgroup
AuthName Jet
AuthType Basic
order deny, allow
deny from all
allow from .jet.msk.su
require user juser1 juser2
require group jetgrp1
Директивы AuthUserFile и AuthGroupFile задают местонахождение файлов паролей и групп для данного каталога. AuthName определяет имя так называемой области управления разграничением доступа. Пользователь увидит текст "Jet" и поймет, куда его приглашают войти; в пределах области управления Web-навигатор поддерживает концепцию единого входа - он автоматически передает пользовательские имя и пароль при всех попытках доступа (кроме первой) к документам из этой области.
Директива AuthType задает тип процедуры аутентификации. На момент написания статьи серверы httpd поддерживали только Unix-пароли (тип Basic), что, конечно, нельзя назвать достоинством, особенно с учетом многократной передачи этих паролей.
Директивы require user и require group накладывают дополнительные ограничения на доступ к каталогу secret. Мало быть зарегистрированным в файле htpasswd, необходимо еще иметь имя juser1 или juser2 либо входить в группу jetgrp1. Тем самым идея произвольного управления доступом получает дальнейшее развитие.
Отдельного рассмотрения заслуживает такая мощная возможность сервера httpd, как интерпретация файлов во время пересылки пользовательскому навигатору. Эти интерпретируемые файлы называются включаемыми. Директива Options Includes, помещенная внутри конструкции
В заключение раздела следует еще раз подчеркнуть тот факт, что на сегодняшний день серверы Web являются весьма надежными программами, позволяющими обеспечить должный уровень информационной безопасности, при условии, однако, что организации, использующие технологию Intranet, имеют продуманную политику, активно проводят ее в жизнь, реализуют стройную систему процедурных мер и располагают подготовленными администраторами безопасности.
ЗАКЛЮЧЕНИЕ
Задача обеспечения информационной безопасности в Intranet оказывается более простой, чем в случае произвольных распределенных систем, построенных в архитектуре клиент-сервер. Причина тому - однородность и простота архитектуры Intranet. Если разработчики прикладных систем сумеют в полной мере воспользоваться этим преимуществом, то на программно-техническом уровне им будет достаточно нескольких недорогих и простых в освоении продуктов. Правда, к этому необходимо присовокупить продуманную политику безопасности и целостный набор мер процедурного уровня.
Владимир Антонович Галатенко - консультант АО "Инфосистемы Джет". С ним можно связаться через Internet по адресу: Vladimir.Galatenko@jet.msk.su.