Введение
Эйфорией по имени Intranet уместно наслаждаться лишь пользовате- лям. Тем же, на кого возложена ответственность за развитие корпоративной интрасети, предстоит продумать множество вопросов. Как построить Intranet, чтобы она давала максимальную отдачу для отдельных лиц, подразделений и предприятия в целом? Как впишется имеющаяся инженерная инфраструктура в эту новую сеть? С какими техническими проблемами связаны развитие и развертывание сети Intranet? Как обеспечить информационную безопасность итрасети? Эти и ряд других подобных вопросов рассматриваются в данной главе.
§ 3.4.1. Трудности создания Intranet
Повальное увлечение Internet постепенно сменяется всеобщим стрем- лением создавать собственные корпоративные интрасети. Однако многие ор- ганизации берутся за процесс разработки интрасетей, не понимая того, что для их создания необходимы значительные инвестиции.
Для внедрения интрасети требуется наличие шести основных элемен-
тов:
* высокоскоростного маршрутизатора или коммутируемых магист-
ральных каналов, обеспечивающих адекватную пропускную способность;
* надежных устройств удаленного доступа, позволяющих подключать к сети удаленных пользователей;
* надежной сетевой защиты, обеспечивающей сохранность конфиден-
циальной информации;
* сложных систем управления сетью, с помощью которых осуществля-
ется контроль за работой сети;
* квалифицированного персонала, способного заниматься планирова-
нием, разработкой, внедрением и управлением сетью;
* документированных процедур для руководства обслуживающим пер-
соналом.
Хотя необходимость всех этих элементов вполне очевидна, удивитель- но, как много организаций забывает о них при реализации интрасети. После первого опыта работы с интрасетью, который обычно оказывается неудач- ным, этим компаниям приходится делать шаг назад и заниматься укреплени- ем инфраструктуры своих сетей. При этом неудачи на начальном этапе под- рывают доверие конечных пользователей к концепции интрасети.
По оценкам исследовательской компании Gartner Group, реализация интрасети примерно в три раза увеличивает сетевой трафик внутри организа- ции. Так почему же большая часть компаний не уделяет должного внимания обеспечению надежной сетевой инфраструктуры до ввода в действие интра- сети? Наиболее очевидное объяснение состоит в чрезмерной спешке. Под воздействием шумихи, поднятой вокруг интрасетей компьютерной и деловой прессой, должностные лица и рядовые пользователи начинают требовать, чтобы их корпоративные сети соответствовали современным концепциям. Многие считают интрасети панацеей, которая позволит их организациям ос- тавить в прошлом проблемы внутренних коммуникаций.
Мало кто осознает, что внедрение технологий интрасетей может только обострить проблемы, связанные с корпоративными сетями. Отсутствие адек- ватной сетевой инфраструктуры, способной справиться с нарастающим тра- фиком, приведет к снижению производительности сети, увеличению числа сбоев и росту негативных отзывов пользователей. Поэтому важное место в процессе разработки интрасети должно быть уделено тщательной оценке имеющейся сетевой инфраструктуры.
Прежде всего, необходимо исследовать уровни сетевого трафика и оп- ределить, обладает ли сеть достаточной пропускной способностью, чтобы принять на себя дополнительную нагрузку, связанную с внедрением корпо- ративной интрасети. Затем, используя специальные средства тестирования, следует оценить величину дополнительного трафика и определить требова-
ния к увеличению пропускной способности. После внедрения интрасети не-
обходимо выполнить анализ ее производительности.
Для успешной работы интрасети не следует пренебрегать и организа- ционными моментами. Надлежащий уровень обслуживания расширенной се- тевой инфраструктуры можно обеспечить только при увеличении, а не уменьшении численности персонала и повышении его квалификации. Кроме того, будьте готовы к реорганизации вашей внутренней группы технической поддержки, которая должна будет выполнять разнообразные требования пользователей, стремящихся использовать преимущества интрасетей.
Многие специалисты предполагали, что интрасети повлияют на эконо- мические аспекты использования корпоративных вычислительных ресурсов, и они оказались правы. Многие организации поняли, что создание интрасети обходится значительно дороже, чем они рассчитывали, и это их в немалой степени разочаровало. Однако те организации, которые сумели преодолеть барьер начальных затрат и организационные трудности, начинают получать отдачу от своих новых корпоративных сетей. Трезвое понимание необходи- мости серьезных инвестиций для создания интрасети является первым шагом к повышению эффективности работы предприятия и получению им матери- альных выгод от использования интрасетей.
§ 3.4.2. Оценка исходного состояния организации
Прежде чем решить, в каком направлении двигаться, надо понять, где находишься. А для этого необходимо оценить производственную и техноло- гическую среду организации. И хотя найдутся компании, агитирующие за простые решения для Intranet (установите сервер Web, дайте пользователям браузеры и авторский инструментарий для подготовки информационного на- полнения Web и получите Intranet), однако такого рода решения не учитыва- ют конкретные потребности конкретной организации, особенно когда речь идет о долгосрочных перспективах, поэтому в итоге они могут обернуться
простоями, низкой отдачей, а с ростом организации или Intranet - и низким качеством обслуживания пользователей.
Чтобы найти оптимальное решение для Intranet, необходимо рассмот- реть внутреннюю сеть с точки зрения применения ее в деятельности органи- зации, т. е. сравнить текущие и потенциальные функции и услуги Intranet с задачами и планами организации в целом. Главная цель - выявить те направ- ления деятельности, которые выиграют от применения технологии Intranet (поставка изделий, обслуживание клиентуры, связь между сотрудниками и т.
д.).
Определив производственные выгоды, следует подумать, как приме-
нить технологию в каждой конкретной области деятельности, чтобы эти вы- годы стали реальными. Вот где важна оценка технологии Intranet. Учет и анализ аппаратных и программных средств, применяемых в инфраструктуре системы, поможет определить, насколько они подходят для приложений Intranet. Оценка технологии должна проводиться с позиций требований к Intranet в отношении, например, масштабируемости, производительности, на- значения, безопасности и управления; результаты такого анализа могли бы быть использованы при планировании архитектуры и технологии, реализация которых позволила бы получить намеченные выгоды.
Возможно, первое, что следует проанализировать, так это такую со- ставляющую инфраструктуры организации, как сеть. Нужно определить то- пологию существующей сети организации, а именно: какие технологии при- меняются на магистрали, в локальных и территориальных сетях, установить применяемые в этих сетях протоколы и приходящуюся на каждый из них до- лю активности сети. Следует замерить загрузку сети на нормальном и пико- вом уровнях, с тем, чтобы установить распределение нагрузки и узкие места сети, а также другие проблемы со связью, которые могут возникнуть из-за дополнительного трафика вследствие активности пользователей Intranet.
Занимаясь оценкой технологии, важно также учитывать, планируется ли подключение Intranet к Internet. Для того чтобы сетевой узел мог работать
в Internet, он должен иметь уникальный IP-адрес. Такие адреса выдаются Центром сетевой информации Internet (InterNIC). Если компания уже исполь- зует протокол TCP/IP в своей внутренней сети, но не подключена к Internet, то может оказаться, что ее узлам были присвоены IP-адреса, на которые не получено разрешение InterNIC. Тогда в случае подключения организации к Internet такие IP-адреса могут вступить в конфликт с теми, что уже были вы- даны центром InterNIC другим компаниям. В такой ситуации вы должны ли- бо присвоить узлам зарегистрированные адреса, либо скрыть их с помощью брандмауэра и виртуальной частной сети.
Если компания до сих пор этого не сделала, нужно запросить (даже не имея намерений подключиться в ближайшем будущем к Internet) у InterNIC (точнее у потенциального провайдера услуг Internet) подходящий блок адре- сов, а также имя собственного домена. Имена доменов - товар дефицитный; компании быстро расхватывают желанные имена и адреса. И, готовясь к расширению в будущем, организация должна придерживаться принятых пра- вил адресации и наименования.
В ходе оценки технологии надлежит определить, насколько надежна защита сети и как ее можно укрепить в связи с введением Intranet. Обычно сеть Intranet подсоединяется к Internet через брандмауэр, защищающий Intranet от нападений со стороны Internet. Брандмауэр представляет собой ин- тегрированную систему сетевой безопасности, благодаря которой одну сеть можно легко подключить ко многим, причем первая останется закрытой и недоступной извне.
Если у организации еще нет определенной политики относительно брандмауэра, то необходимо ее разработать. Однако следует учесть, что ус- тановка брандмауэра предполагает компромисс между защитой и управляе- мостью. Кроме того, маршрутизаторы должны иметь списки прав доступа для защиты сети, а агенты по мониторингу и аудиту - выдавать предупреж- дения в случае возникновения каких-либо проблем. Результатом такой оцен-
ки сети будет схема, в которой имеющаяся сетевая среда встроена в новую структуру Intranet.
Далее, следует обратить внимание на эксплуатируемые организацией системы. Необходимо сделать анализ вычислительных технологий настоль- ных систем, рабочих станций и серверов, обращая особое внимание на их способность работать с IP-трафиком. После анализа их операционных сис- тем, типов аппаратного обеспечения и функций сервера (например, элек- тронная почта, печать, файлы, приложения и т. д.) можно будет составить более четкое представление относительно того, насколько они впишутся в IP- среду сети Intranet.
Затем потребуется также принять решение относительно систем и про- цедур управления модернизацией, распространением и лицензиями на ПО. Поскольку TCP/IP - жизненно важный компонент новой сетевой стратегии, системы должны поддерживать эти протоколы в их новейшей версии для Intranet. Совместимость систем электронной почты - одна из главных забот в разнородных системах. Следует продумать вопрос об использовании интег- рированной системы, если таковая еще не реализована.
Наконец, нужно определить, какими Web-активами организация распо- лагает (включая наличные серверы и браузеры Web) на предмет емкости и возможности связи со всеми корпоративными узлами, IP-возможностей и производительности при каждодневной эксплуатации. При необходимости, если того требуют новый трафик и подключение сетей, не использующих протокол IP, надлежит выработать рекомендации касательно модернизации систем.
Результаты анализа инфраструктуры должны содержать полную опись серверных систем, рабочих станций и настольных компьютеров; необходи- мые интерфейсы, которые должны иметь эти машины, и план интеграции их в новую сеть Intranet.
§ 3.4.3. Информационная безопасность в Intranet-сетях
Архитектура Intranet подразумевает подключение к внешним открытым сетям, использование внешних сервисов и предоставление собственных сер- висов вовне, что предъявляет повышенные требования к защите информации.
В Intranet-системах используется подход клиент-сервер, а главная роль на сегодняшний день отводится Web-сервису. Web-серверы должны поддер- живать традиционные защитные средства, такие как аутентификация и раз- граничение доступа; кроме того, необходимо обеспечение новых свойств, в особенности безопасности программной среды и на серверной, и на клиент- ской сторонах.
Таковы, если говорить совсем кратко, задачи в области информацион- ной безопасности, возникающие в связи с переходом на технологию Intranet. Далее рассмотрим возможные подходы к их решению.
Позволим себе небольшое отступление, расскажем одну быль. Однаж- ды некий банкир, прочитав в каком-то дорогом журнале статью об информа- ционной безопасности, сделал для себя вывод, что защищаться бесполезно - слишком велик арсенал потенциального злоумышленника. Он перестал рас- сматривать предложения по защите компьютерной системы банка, считая их заведомо бесполезными. К фаталистам его отнести было нельзя, от подтяжек он не отказался, однако масса технических деталей, приведенных в журналь- ной статье, совершенно запутала и подавила его. Сжав голову руками, он хо- дил из угла в угол, бормоча: “Пароли перехватываются, соединения крадутся, получить привилегии root - раз плюнуть” и т.д. и т.п. Все попытки указать ему на то, что в статье допущен ряд чисто технических ошибок, что не ого- ворены условия, при которых возможна та или иная атака, что, наконец, от- сутствует комплексный подход к проблеме безопасности, успеха не имели.
Так совпало, что вскоре дела банка, где работал этот банкир, стали ид- ти все хуже и хуже. Более удачливые конкуренты, казалось, все время преду- гадывали его ходы, постоянно оказываясь на полшага впереди. Будем наде- яться, что у читателей данного учебника, напротив, все пойдет как нельзя
лучше и у них окажется больше здравого смысла, больше умения видеть про-
блему в целом.
Формирование режима информационной безопасности - проблема ком-
плексная. Меры по ее решению можно разделить на четыре уровня:
* законодательный (законы, нормативные акты, стандарты и т.п.);
* административный (действия общего характера, предпринимаемые руководством организации);
* процедурный (конкретные меры безопасности, имеющие дело с людьми);
* программно-технический (конкретные технические меры).
§ 3.4.4. Сетевые аспекты политики безопасности
Политика безопасности определяется как совокупность документиро- ванных управленческих решений, направленных на защиту информации и ассоциированных с ней ресурсов.
При разработке и проведении ее в жизнь целесообразно руководство-
ваться следующими принципами:
* невозможность миновать защитные средства;
* усиление самого слабого звена;
* невозможность перехода в небезопасное состояние;
* минимизация привилегий;
* разделение обязанностей;
* эшелонированность обороны;
* разнообразие защитных средств;
* простота и управляемость информационной системы;
* обеспечение всеобщей поддержки мер безопасности.
Поясним смысл перечисленных принципов.
Если у злоумышленника или недовольного пользователя появится воз- можность миновать защитные средства, он, разумеется, так и сделает. При- менительно к межсетевым экранам данный принцип означает, что все ин-
формационные потоки в защищаемую сеть и из нее должны проходить через экран. Не должно быть “тайных” модемных входов или тестовых линий, иду- щих в обход экрана.
Надежность любой обороны определяется самым слабым звеном. Зло- умышленник не будет бороться против силы, он предпочтет легкую победу над слабостью. Часто самым слабым звеном оказывается не компьютер или программа, а человек, и тогда проблема обеспечения информационной безо- пасности приобретает нетехнический характер.
Принцип невозможности перехода в небезопасное состояние означает, что при любых обстоятельствах, в том числе нештатных, защитное средство либо полностью выполняет свои функции, либо полностью блокирует дос- туп. Образно говоря, если в крепости механизм подъемного моста ломается, мост должен оставаться в поднятом состоянии, препятствуя проходу непри- ятеля.
Принцип минимизации привилегий предписывает выделять пользова- телям и администраторам только те права доступа, которые необходимы им для выполнения служебных обязанностей.
Принцип разделения обязанностей предполагает такое распределение ролей и ответственности, при котором один человек не может нарушить кри- тически важный для организации процесс. Это особенно важно, чтобы пре- дотвратить злонамеренные или неквалифицированные действия системного администратора.
Принцип эшелонированности обороны предписывает не полагаться на один защитный рубеж, каким бы надежным он ни казался. За средствами фи- зической защиты должны следовать программно-технические средства, за идентификацией и аутентификацией - управление доступом и, как последний рубеж, - протоколирование и аудит. Эшелонированная оборона способна по крайней мере задержать злоумышленника, а наличие такого рубежа, как про- токолирование и аудит, существенно затрудняет незаметное выполнение зло- умышленных действий.
Принцип разнообразия защитных средств рекомендует организовывать различные по своему характеру оборонительные рубежи, чтобы от потенци- ального злоумышленника требовалось овладение разнообразными и, по воз- можности, несовместимыми между собой навыками (например, умением преодолевать высокую ограду и знанием слабостей нескольких операцион- ных систем).
Очень важен принцип простоты и управляемости информационной системы в целом и защитных средств в особенности. Только для простого защитного средства можно формально или неформально доказать его кор- ректность. Только в простой и управляемой системе можно проверить согла- сованность конфигурации разных компонентов и осуществить централизо- ванное администрирование. В этой связи важно отметить интегрирующую роль Web-сервиса, скрывающего разнообразие обслуживаемых объектов и предоставляющего единый, наглядный интерфейс. Соответственно, если объекты некоторого вида (скажем таблицы базы данных) доступны через Web, необходимо заблокировать прямой доступ к ним, поскольку в против- ном случае система будет сложной и трудно управляемой.
Последний принцип - всеобщая поддержка мер безопасности - носит нетехнический характер. Если пользователи и/или системные администрато- ры считают информационную безопасность чем-то излишним или даже вра- ждебным, режим безопасности сформировать заведомо не удастся. Следует с самого начала предусмотреть комплекс мер, направленный на обеспечение лояльности персонала, на постоянное обучение, теоретическое и, главное, практическое.
Анализ рисков - важнейший этап выработки политики безопасности. При оценке рисков, которым подвержены Intranet-системы, нужно учитывать следующие обстоятельства:
* новые угрозы по отношению к старым сервисам, вытекающие из воз- можности пассивного или активного прослушивания сети. Пассивное про- слушивание означает чтение сетевого трафика, а активное - его изменение
(кражу, дублирование или модификацию передаваемых данных). Например, аутентификация удаленного клиента с помощью пароля многократного ис- пользования не может считаться надежной в сетевой среде, независимо от длины пароля;
* новые (сетевые) сервисы и ассоциированные с ними угрозы.
Как правило, в Intranet-системах следует придерживаться принципа “все, что не разрешено, запрещено”, поскольку “лишний”сетевой сервис мо- жет предоставить канал проникновения в корпоративную систему. В прин- ципе, ту же мысль выражает положение “все непонятное опасно”.
§ 3.4.4. Управление доступом путем фильтрации информации
Перейдем к рассмотрению мер программно-технического уровня, на- правленных на обеспечение информационной безопасности систем, постро- енных в технологии Intranet. На первое место среди таких мер поставим меж- сетевые экраны - средство разграничения доступа, служащее для защиты от внешних угроз и от угроз со стороны пользователей других сегментов корпо-
ративных сетей, рис. 35.
Рис. 35. Межсетевое экранирование
Отметим, что бороться с угрозами, присущими сетевой среде, средст- вами универсальных операционных систем не представляется возможным. Универсальная ОС - это огромная программа, наверняка содержащая, поми- мо явных ошибок, некоторые особенности, которые могут быть использова-
ны для получения нелегальных привилегий. Современная технология про- граммирования не позволяет сделать столь большие программы безопасны- ми. Кроме того, администратор, имеющий дело со сложной системой, далеко не всегда в состоянии учесть все последствия производимых изменений (как и врач, не ведающий всех побочных воздействий рекомендуемых лекарств). Наконец, в универсальной многопользовательской системе бреши в безопас- ности постоянно создаются самими пользователями (слабые и/или редко из- меняемые пароли, неудачно установленные права доступа, оставленный без присмотра терминал и т.п.).
Как указывалось выше, единственный перспективный путь связан с разработкой специализированных защитных средств, которые в силу своей простоты допускают формальную или неформальную верификацию. Межсе- тевой экран как раз и является таким средством, допускающим дальнейшую декомпозицию, связанную с обслуживанием различных сетевых протоколов.
Межсетевой экран (Firewall) - это полупроницаемая мембрана, которая располагается между защищаемой (внутренней) сетью и внешней средой (внешними сетями или другими сегментами корпоративной сети) и контро- лирует все информационные потоки во внутреннюю сеть и из нее. Контроль информационных потоков состоит в их фильтрации, то есть в выборочном пропускании через экран, возможно, с выполнением некоторых преобразова- ний и извещением отправителя о том, что его данным в пропуске отказано. Фильтрация осуществляется на основе набора правил, предварительно за- груженных в экран и являющихся выражением сетевых аспектов политики безопасности организации.
Целесообразно разделить случаи, когда экран устанавливается на гра- нице с внешней (обычно общедоступной) сетью или на границе между сег- ментами одной корпоративной сети. Соответственно, будем говорить о внешнем и внутреннем межсетевых экранах.
Как правило, при общении с внешними сетями используется исключи-
тельно семейство протоколов TCP/IP. Поэтому внешний межсетевой экран
должен учитывать специфику этих протоколов. Для внутренних экранов си- туация сложнее, здесь следует принимать во внимание помимо TCP/IP по крайней мере протоколы SPX/IPX, применяемые в сетях Novell NetWare. Иными словами, от внутренних экранов нередко требуется многопротоколь- ность.
Ситуация, когда корпоративная сеть содержит лишь один внешний ка- нал, является, скорее, исключением, чем правилом. Напротив, типична си- туация, при которой корпоративная сеть состоит из нескольких территори- ально разнесенных сегментов, каждый из которых подключен к сети общего пользования. В этом случае каждое подключение должно защищаться своим экраном. Точнее говоря, можно считать, что корпоративный внешний межсе- тевой экран является составным, и требуется решать задачу согласованного администрирования (управления и аудита) всех компонентов.
При рассмотрении любого вопроса, касающегося сетевых технологий, основой служит семиуровневая эталонная модель ISO/OSI. Она состоит из следующих уровней:
7-ой уровень – прикладной – обеспечивает поддержку прикладных процессов конечных пользователей.
6-ой уровень – представительный – определяет синтаксис данных в мо-
дели, т.е. представление данных.
5-ый уровень – сеансовый - реализует установление и поддержку сеан-
са связи между двумя абонентами через коммуникационную сеть.
4-ый уровень – транспортный – обеспечивает интерфейс между про-
цессами и сетью.
3-ий уровень – сетевой – определяет интерфейс оконечного оборудова-
ния данных пользователя с сетью коммутации пакетов.
2-ой уровень – канальный- реализует процесс передачи информации по информационному каналу.
1-ый уровень – физический – выполняет все необходимые процедуры в канале связи.
Межсетевые экраны также целесообразно классифицировать по тому, на каком уровне производится фильтрация - канальном, сетевом, транспорт- ном или прикладном. Соответственно, можно говорить об экранирующих концентраторах (уровень 2), маршрутизаторах (уровень 3), о транспортном экранировании (уровень 4) и о прикладных экранах (уровень 7). Существуют также комплексные экраны, анализирующие информацию на нескольких уровнях.
Мы не рассматриваем экранирующие концентраторы, поскольку кон-
цептуально они мало отличаются от экранирующих маршрутизаторов.
При принятии решения “пропустить/не пропустить”, межсетевые экра- ны могут использовать не только информацию, содержащуюся в фильтруе- мых потоках, но и данные, полученные из окружения, например текущее время.
Таким образом, возможности межсетевого экрана непосредственно оп- ределяются тем, какая информация может использоваться в правилах фильт- рации и какова может быть мощность наборов правил. Вообще говоря, чем выше уровень в модели ISO/OSI, на котором функционирует экран, тем более содержательная информация ему доступна и, следовательно, тем тоньше и надежнее экран может быть сконфигурирован. В то же время фильтрация на каждом из перечисленных выше уровней обладает своими достоинствами, такими как дешевизна, высокая эффективность или прозрачность для пользо- вателей. В силу этой, а также некоторых других причин, в большинстве слу- чаев используются смешанные конфигурации, в которых объединены разно- типные экраны. Наиболее типичным является сочетание экранирующих маршрутизаторов и прикладного экрана.
Такая конфигурация называется экранирующей подсетью. Как правило, сервисы, которые организация предоставляет для внешнего применения (на- пример “представительский” Web-сервер), целесообразно выносить как раз в экранирующую подсеть.
Помимо выразительных возможностей и допустимого количества пра- вил качество межсетевого экрана определяется еще двумя очень важными характеристиками - простотой применения и собственной защищенностью. В плане простоты использования первостепенное значение имеют наглядный интерфейс при задании правил фильтрации и возможность централизованно- го администрирования составных конфигураций. В свою очередь, в послед- нем аспекте хотелось бы выделить средства централизованной загрузки пра- вил фильтрации и проверки набора правил на непротиворечивость. Важен и централизованный сбор и анализ регистрационной информации, а также по- лучение сигналов о попытках выполнения действий, запрещенных политикой безопасности.
Собственная защищенность межсетевого экрана обеспечивается теми же средствами, что и защищенность универсальных систем. При выполнении централизованного администрирования следует еще позаботиться о защите информации от пассивного и активного прослушивания сети, то есть обеспе- чить ее (информации) целостность и конфиденциальность.
Хотелось бы подчеркнуть, что природа экранирования (фильтрации), как механизма безопасности, очень глубока. Помимо блокирования потоков данных, нарушающих политику безопасности, межсетевой экран может скрывать информацию о защищаемой сети, тем самым, затрудняя действия потенциальных злоумышленников. Так, прикладной экран может осуществ- лять действия от имени субъектов внутренней сети, в результате чего из внешней сети кажется, что имеет место взаимодействие исключительно с межсетевым экраном, рис. 31. При таком подходе топология внутренней сети скрыта от внешних пользователей, поэтому задача злоумышленника сущест- венно усложняется.
Рис. 36. Информационные потоки.
Более общим методом сокрытия информации о топологии защищаемой сети является трансляция “внутренних” сетевых адресов, которая попутно решает проблему расширения адресного пространства, выделенного органи- зации.
Ограничивающий интерфейс также можно рассматривать как разно- видность экранирования. На невидимый объект трудно нападать, особенно с помощью фиксированного набора средств. В этом смысле Web-интерфейс обладает естественной защитой, особенно в том случае, когда гипертексто- вые документы формируются динамически. Каждый видит лишь то, что ему положено.
Экранирующая роль Web-сервиса наглядно проявляется и тогда, когда этот сервис осуществляет посреднические (точнее, интегрирующие) функции при доступе к другим ресурсам, в частности таблицам базы данных. Здесь не только контролируются потоки запросов, но и скрывается реальная органи- зация баз данных.
§ 3.4.5. Безопасность программной среды
Идея сетей с так называемыми активными агентами, когда между ком- пьютерами передаются не только пассивные, но и активные исполняемые данные (то есть программы), разумеется, не нова. Первоначально цель со- стояла в том, чтобы уменьшить сетевой трафик, выполняя основную часть обработки там, где располагаются данные (приближение программ к дан- ным). На практике это означало перемещение программ на серверы. Класси-
ческий пример реализации подобного подхода - это хранимые процедуры в реляционных СУБД.
Для Web-серверов аналогом хранимых процедур являются программы, обслуживающие CGI (Common Gateway Interface - общий шлюзовый интер- фейс). CGI-процедуры располагаются на серверах и обычно используются для динамического порождения HTML-документов. Политика безопасности организации и процедурные меры должны определять, кто имеет право по- мещать на сервер CGI-процедуры. Жесткий контроль здесь необходим, по- скольку выполнение сервером некорректной программы может привести к сколь угодно тяжелым последствиям. Разумная мера технического характера состоит в минимизации привилегий пользователя, от имени которого выпол- няется Web-сервер.
В технологии Intranet, если заботиться о качестве и выразительной силе пользовательского интерфейса, возникает нужда в перемещении программ с Web-серверов на клиентские компьютеры - для создания анимации, выпол- нения семантического контроля при вводе данных и т.д. Вообще, активные агенты - неотъемлемая часть технологии Intranet.
В каком бы направлении ни перемещались программы по сети, эти действия представляют повышенную опасность, т.к. программа, полученная из ненадежного источника, может содержать непреднамеренно внесенные ошибки или целенаправленно созданный зловредный код. Такая программа потенциально угрожает всем основным аспектам информационной безопас- ности:
* доступности (программа может поглотить все наличные ресурсы);
* целостности (программа может удалить или повредить данные);
* конфиденциальности (программа может прочитать данные и передать их по сети).
Проблему ненадежных программ осознавали давно, но, пожалуй, толь- ко в рамках системы программирования Java впервые предложена целостная концепция ее решения.
Java предлагает три оборонительных рубежа:
* надежность языка;
* контроль при получении программ;
* контроль при выполнении программ.
Впрочем, существует еще одно, очень важное средство обеспечения информационной безопасности - беспрецедентная открытость Java-системы. Исходные тексты Java-компилятора и интерпретатора доступны для провер- ки, поэтому велика вероятность, что ошибки и недочеты первыми будут об- наруживать честные специалисты, а не злоумышленники.
В концептуальном плане наибольшие трудности представляет контро- лируемое выполнение программ, загруженных по сети. Прежде всего, необ- ходимо определить, какие действия считаются для таких программ допусти- мыми. Если исходить из того, что Java - это язык для написания клиентских частей приложений, одним из основных требований к которым является мо- бильность, загруженная программа может обслуживать только пользователь- ский интерфейс и осуществлять сетевое взаимодействие с сервером. Про- грамма не может работать с файлами хотя бы потому, что на Java-терминале их, возможно, не будет. Более содержательные действия должны произво- диться на серверной стороне или осуществляться программами, локальными для клиентской системы.
Интересный подход предлагают специалисты компании Sun Microsystems для обеспечения безопасного выполнения командных файлов. Речь идет о среде Safe-Tcl (Tool Comman Language - инструментальный ко- мандный язык). Sun предложила так называемую ячеечную модель интерпре- тации командных файлов. Существует главный интерпретатор, которому доступны все возможности языка. Если в процессе работы приложения необ- ходимо выполнить сомнительный командный файл, порождается подчинен- ный командный интерпретатор, обладающий ограниченной функционально- стью (например, из него могут быть удалены средства работы с файлами и сетевые возможности). В результате потенциально опасные программы ока-
зываются заключенными в ячейки, защищающие пользовательские системы от враждебных действий. Для выполнения действий, которые считаются при- вилегированными, подчиненный интерпретатор может обращаться с запро- сами к главному. Здесь, очевидно, просматривается аналогия с разделением адресных пространств операционной системы и пользовательских процессов и использованием последними системных вызовов. Подобная модель уже около 30 лет является стандартной для многопользовательских ОС.
§ 3.4.6. Защита Web-серверов
Наряду с обеспечением безопасности программной среды, важнейшим будет вопрос о разграничении доступа к объектам Web-сервиса. Для решения этого вопроса необходимо уяснить, что является объектом, как идентифици- руются субъекты и какая модель управления доступом - принудительная или произвольная - применяется.
В Web-серверах объектами доступа выступают URL (Uniform (Universal) Resource Locator - универсальные локаторы ресурсов). За этими локаторами могут стоять различные сущности - HTML-файлы, CGI- процедуры и т.п.
Как правило, субъекты доступа идентифицируются по IP-адресам и/или именам компьютеров и областей управления. Кроме того, может использо- ваться парольная аутентификация пользователей или более сложные схемы, основанные на криптографических технологиях.
В большинстве Web-серверов права разграничиваются с точностью до каталогов (директорий) с применением произвольного управления доступом. Могут предоставляться права на чтение HTML-файлов, выполнение CGI- процедур и т.д.
Для раннего выявления попыток нелегального проникновения в Web-
сервер важен регулярный анализ регистрационной информации.
Разумеется, защита системы, на которой функционирует Web-сервер,
должна следовать универсальным рекомендациям, главной из которых явля-
ется максимальное упрощение. Все ненужные сервисы, файлы, устройства должны быть удалены. Число пользователей, имеющих прямой доступ к сер- веру, должно быть сведено к минимуму, а их привилегии - упорядочены в соответствии со служебными обязанностями.
Еще один общий принцип состоит в том, чтобы минимизировать объем информации о сервере, которую могут получить пользователи. Многие сер- веры в случае обращения по имени каталога и отсутствия файла index.HTML в нем, выдают HTML-вариант оглавления каталога. В этом оглавлении могут встретиться имена файлов с исходными текстами CGI-процедур или с иной конфиденциальной информацией. Такого рода “дополнительные возможно- сти” целесообразно отключать, поскольку лишнее знание (злоумышленника) умножает печали (владельца сервера).
§ 3.4.7. Аутентификация в открытых сетях
Методы, применяемые в открытых сетях для подтверждения и провер- ки подлинности субъектов, должны быть устойчивы к пасс