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

Доступ из Web к сети и инфраструктуре

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

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

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

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

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

Другая проблема заключается в выполнении программ, сценариев или иных вспомогательных процедур на Web-сервере. Некоторые организации не испытывают таких проблем и разрешают запускать сценарии, которые работают как часть общего шлюзового интерфейса сервера (CGI — Common Gateway Interface). В других организациях испытывают беспокойство при разрешении запуска всего, что отличается от тестовых страничек сервера. Необходимо быть очень осторожным при утверждении таких правил, поскольку они будут сильно влиять на архитектуру вспомогательных систем Internet вашей организации. Чрезмерная жесткость правил будет неприемлема для организаций, которые пользуются услугами внешних вспомогательных систем.

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

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

Защита и обслуживание CGI и других сервисных программ

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

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

При разработке правил для этих вспомогательных программ необходимо рассмотреть два аспекта.

• Ревизию всего установленного программного обеспечения на предмет возникновения любых потенциальных проблем.
• Безопасную эксплуатацию этих средств.

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

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

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

Правила в этих областях довольно сложно трактовать. Если ваша организация использует внешние WеЬ-серверы, то определить их потенциальные проблемы довольно сложно. Можно попробовать заключить соглашение при подписании контракта, которое согласовывалось бы с вашими правилами, но все равно это будет намного сложнее, чем если бы ваша организация имела собственные Web-серверы. Ваши администраторы не могут просто проводить новые патчи или менять конфигурацию, так как не могут быть уверены в том, что эти обновления не приведут к неправильной работе или к выходу из строя сервера или программного обеспечения.

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

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

Корректировщики содержимого

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

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

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

Управление содержимым

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

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

Правило конфиденциальности

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

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

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

Доступ пользователей к Web

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

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

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

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

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

Позже автор начал исследовать сеть организации извне. Во-первых, используя некоторые стандартные средства, удалось обнаружить все серверы, обслуживающие WеЬ-системы. В результате тестирования были обнаружены серверы на нестандартных портах. На основе этой информации были преобразованы адреса поиска, чтобы установить, какому имени какой адрес соответствует. Обнаружилось, что один из адресов имеет резервное имя, зарегистрированное в InterNIC (Internet Network Information Center— информационный центр сети Internet). Используя новое имя и броузер, автор получил доступ к сайту. То, что удалось обнаружить на этом сайте, шокировало людей, с которыми он сотрудничал. Информация совершенно не соответствовала целям организации и могла считаться запрещенной.

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

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

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