Защита web-сервера

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

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

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

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

В Web-серверах объектами доступа выступают универсальные локаторы ресурсов (URL - Uniform (Universal) Resource Locator). За этими локаторами могут стоять различные сущности - HTML-файлы, CGI-процедуры и т.п. Как правило, субъекты доступа идентифицируются по IP-адресам и/или именам компьютеров и областей управления. Кроме того, может использоваться парольная аутентификация пользователей или более сложные схемы, основанные на криптографических технологиях.

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

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

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

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

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

Можно выделить три уровня безопасности для сервера:

1. Минимальный уровень безопасности.

o Модернизация имеющегося программного обеспечения и установка "заплаток".

o Использование единых настроек (политик) для всех серверов.

o Удаление лишних приложений.

2. Сопротивление вторжению.

o Установка внешнего межсетевого экрана.

o Удаленное администрирование систем безопасности.

o Ограничения на использование скриптов.

o Защита Web-серверов, используя фильтрацию пакетов.

o Обучение персонала и разграничение прав доступа.

o Использование решений, перечисленных в уровне 1.

3. Обнаружение атак и ослабление их воздействия.

o Разделение привилегий.

o Аппаратные системы защиты.

o Внутренний межсетевой экран.

o Сетевые системы обнаружения вторжений.

o Системы обнаружения вторжений, размещаемые на серверах (хостах).

o Использование решений, перечисленных в уровне 2.

Варианты обеспечения безопасности Web-серверов Можно выделить следующие, наиболее общие способы защиты Web-серверов:

· удаление лишнего программного обеспечения (приложений);

· обнаружение попыток нарушения защиты Web-серверов;

· исправление изъянов в установленном программном обеспечении;

· уменьшение последствий атак на сеть;

· защита остальной части сети, в случае если Web-сервер был скомпрометирован.

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

Еще один недостаток размещения сервера за брандмауэром состоит в том, что пользователи невольно начинают рассматривать сервер Web как обычный внутренний сервер. Такое отношение недопустимо: сервер Web нуждается в особом внимании, так как он открыт для доступа внешних пользователей, даже если эта открытость и ограничивается HTTP. Восприятие сервера Web как неотъемлемого элемента брандмауэра вырабатывает у администраторов именно такое отношение, какое требуется, - подозрительное до помешательства.

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

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

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

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

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

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

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

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

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

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

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

Еще большей защищенности можно добиться, исключив необходимость человеческого вмешательства и автоматизировав администрирование общедоступного сервера Web. Невозможно? Это и так, и не так. Систему следует настроить таким образом, чтобы администраторы Web работали с внутренними серверами Web. Все изменения, сделанные на внутреннем сервере, затем нужно перенести на внешний, общедоступный сервер Web. В принципе, это можно сделать с помощью протокола совместного использования файлов, таких как Microsoft Server Message Block или Unix Network File System. Однако подобные протоколы не гарантируют защиты, и пользоваться ими не следует.

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

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

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

Большинство администраторов Web до сих пор даже не знают, каким собственно образом злоумышленники атакуют их серверы. Сообщество пользователей UNIX уже накопило достаточный опыт для противодействия нападениям и укрепления своих систем. У адептов Microsoft такого опыта пока нет.

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

Принцип форт-хоста предполагает также отказ от сетевых пользовательских бюджетов. Все бюджеты должны быть локальными: они предназначаются для администрирования Web. Решение об открытии сетевых бюджетов для администраторов Web на Web-сервере Intranet зависит исключительно от важности хранимой на нем информации.

На сервере NT в сети Intranet можно использовать фильтрацию пакетов. NT поддерживает простейшую фильтрацию пакетов, настроить которую можно посредством выбора закладки Protocols в апплете Network, в Control Panel.

Чем надежнее фильтрация пакетов, тем лучше защита. Например, сервер Web получает запросы через порт 80. Разрешив фильтру TCP пропускать только пакеты, адресованные этому порту, администратор тем самым запрещает использование всех других прикладных протоколов TCP/IP. Кроме того, он может, например, открыть порт 443 для протокола Secure Socket Layer (SSL). Теперь фильтр пакетов будет разрешать установку только соединений через порты 80 и 443. При этом исходящие соединения он никак не будет ограничивать.

Защита web-приложений

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

Несмотря на активное использование приложений в Web, их безопасности уделяется недостаточно внимания. Вся система защиты сводится к рассредоточению: внешний сервер, сервер web-приложений, сервер базы данных, — все они находятся в разных зонах. Компоненты, используемые в разных зонах, имеют укрепленную операционную систему и хорошо сконфигурированы. В этом случае, если злоумышленнику и получается проникнуть на один из компонентов, то ущерб ограничен этим компонентом, т.к. между компонентами открыты исключительно те порты, которые необходимы для выполнения возложенной на них функции (рис. 1). Но, как я и говорил, многоступенчатые фильтры не принесут защиты от содержимого запроса. В случае приложений, работающих по технологии клиент-сервер, клиентская часть устанавливается на пользовательскую машину. При использовании web- приложений часть приложения загружается на машину пользователя, поэтому исследовать исходный код может кто угодно, собственно, сформировать необходимый запрос по результату исследования может тоже кто угодно. Web-приложения состоят из трех частей: представления, логики и данных. Уровень представления, получив запрос, передает его на уровень логики, который начинает обрабатывать запрос (возможно, с привлечением уровня данных), после чего передает результат снова на уровень представления. На каждую из трех частей атака может проводиться независимо. Уровень данных представляет собой хранилище информации и может опрашиваться логическим уровнем (рис. 2). Любой пользователь, в принципе, может запускать скрипт со своими параметрами. Для этого достаточно отправить на сервер специально сформированный запрос. Приведу пример такого запроса, в адресной строке пишется следующее:

httр://www.sa-sec.org/test.php?id=23&format=html.

Файл test.php выполняется на удаленном сервере включая параметры справа от знака вопроса. Если test.php представить в качестве исполняемого файла для Windows (test.exe), то результат оказался бы таким:

C:\ test.exe /id:23/fоrmat: html

Это типичный межсайтовый скриптинг, о котором, помнится, я уже писал на страницах КГ. Защитой от такого рода атак может быть хороший программинг под Web — для этого разработчик должен хорошо проверить имена и значения параметров. Конечно, на практике до этого не доходит. Вдобавок полностью игнорируются многочисленные элементы: идентификационные маркеры (Cookie), заголовок HTTP, информация о сеансе в URL, скрытые поля в исходном тексте и т.д. Поскольку протокол HTTP не содержит никакой информации о статусе пользователя, злоумышленник — в зависимости от приложения — может, к примеру, путем изменения маркера (Cookiе Poisoning, Cookie Stealing) или информации о сеансе в URL получить доступ к открытому сеансу другого пользователя и тем самым к его данным без имени и пароля. Изменение значений скрытых полей в исходном тексте также не представляет труда. Задачу упрощают так называемые "посредники перехвата", работающие на компьютере злоумышленника и заметно упрощающие манипуляции с перечисленными параметрами. Таким образом, для разработки надежного приложения программист должен исходить из того, что злоумышленник в состоянии манипулировать любыми значениями. Дополнительно необходимо проверить поля ввода на наличие специальных символов и сценариев, поскольку они — если достигнут сервера баз данных — могут вызвать запуск специальных функций или обеспечить доступ к оболочке через внешнюю программу. Так, простая кавычка (') в комбинации с командами SQL в поле ввода способна привести к нежелательным действиям с внутренней базой данных. Еще одним возможным сценарием является атака, когда некорректные данные представлены в зашифрованной форме. Если злоумышленник запускает сценарий на стороне клиента (Cross-Site Scripting), специальные символы будут интерпретированы еще позже, когда их выведет, интерпретирует и выполнит браузер ничего не подозревающего пользователя. Для защиты от переполнения буфера должна выполняться проверка длины. Итак, программист должен, с одной стороны, проверять, не манипулировал ли злоумышленник параметрами, заданными приложениями Web, а с другой — не содержат ли поля ввода неразрешенных данных: к примеру, инжекций SQL или команд, сценариев для выполнения на стороне клиента или переполнения буфера.

Компании не должны полагаться на сторонних разработчиков в том, что последние будут использовать надежное программирование. Большинство учитывают некоторые из общих рекомендаций, и то весьма поверхностно. Посему и приложения на выходе не отвечают всем требованиям безопасности. К тому же, надежное программирование достаточно сложно, а, следовательно, дорого. В любом случае приложение должно адекватно обрабатывать "мирные запросы". Это значит, что, допустим, апостроф в имени пользователя S'nams не должен распознаваться как попытка провести инжекцию SQL (рис. 5). Поэтому каждый раз значение поля следует обрабатывать индивидуально. При покупке готовых приложений компании должны проводить обязательный аудит кода для поиска и устранения потенциально опасных мест, иначе это может вылиться в весьма неприятное положение дел со всеми вытекающими последствиями. Альтернативой данному методу является использование брандмауэров для web-приложений (Web Application Firewall — WAF). Такого рода брандмауэр устанавливается перед web-приложением и предоставляет гораздо более расширенные возможности, нежели обычные программные брандмауэры для системы. Отличие от классической технологии заключается в том, что WAF интерпретирует защищаемые приложения Web с их отдельными страницами, полями ввода, значениями параметров и маркерами Cookie. WAF в состоянии контролировать все объекты, которые могут быть доступны пользователям, вводимые URL, а также параметры запросов GET и POST. Допускается возможность только тех URL, которые могут принадлежать тому или другому объекту. Также брандмауэр не позволяет пользователям запускать не относящиеся к ресурсу объекты — например, логи или системные журналы на сервере. Следует контролировать отклики, т.к. в них может содержаться описание ошибки — это описание может содержать достаточно важную информацию. Заголовок сервера, где в стандартной конфигурации сервера Web указан тип сервера (к примеру, сервер: Apache 2.0.54 (UNIX), mod_ssl/2.0.54 OpenSSL/0.9.7a DAV/2 SVN/1.2.0-dev), переписывается в отклике большинства WAF, чтобы злоумышленник не мог получить этих сведений таким простым способом.

Возможны два подхода к решениям обеспечения безопасности — в соответствии с положительной и отрицательной логикой безопасности. В последнем случае определяется лишь то, что запрещено — все остальное разрешено, как, например, в антивирусном сканере. WAF снабжаются заранее составленными черными списками, содержащими схемы распространенных типов атак. Тем самым обеспечивается защита от многих известных атак, базирующихся на этих схемах, поэтому нет необходимости в знании и конфигурировании всех параметров. Чрезвычайно важная функция — исключение отдельных полей ввода перед проверкой для предотвращения неверных положительных распознаваний. В некоторых приложениях Web — к примеру, в техническом дискуссионном форуме — при определенных обстоятельствах может понадобиться разрешение возможности ввода кодов HTML или сценариев. Положительная, известная также как белый список, логика предполагает определение того, что можно — все остальное запрещено. Хотя это и означает значительные издержки на конфигурацию, но в результате обеспечивается существенно более последовательная защита, в том числе от неизвестных типов атак. WAF должен поддерживать комбинацию обоих типов логики. И наиболее эффективен WAF тогда, когда может соответствующим образом интерпретировать приложение Web, т.е. положительная логика преобладает. Основой этого является создание свода правил — так называемой политики. Возможны два подхода: динамический и статический. При динамическом администратор определяет действительные страницы входа и работу WAF в реальном времени.

Для каждой запрошенной пользователем страницы содержащиеся в коде HTML ссылки включая определенные в URI величины добавляются в динамически создаваемое правило. К сожалению, для более сложных приложений, когда на стороне клиента используется JavaScript, эту функцию часто нельзя осмысленно применять, потому что JavaScript позволяет генерировать на клиенте вызываемый URL с передаваемыми параметрами. Как следствие администратор должен определять эти URL как исключение — причем речь идет лишь об одном из нескольких примеров, когда JavaScript на клиенте в случае динамического варианта вызывает проблемы. Поэтому наиболее распространен статический вариант. При статическом подходе администратор создает правило до применения WAF. Этим процессом можно управлять вручную или автоматизировать при помощи определенных инструментов. Например, WAF можно прозрачно включить в поток данных для предварительного протоколирования трафика. На основании полученных данных администратор путем ввода надежных IP-адресов или их диапазонов и определения промежутка времени может описать в политике все варианты разрешенного доступа. Еще одним инструментом является "крот" (crawler). Он должен начиная с некоторой стартовой страницы автоматически отследить все ссылки и за короткое время составить список всех URL включая поля ввода, статичные значения пунктов списка, селективные кнопки и перечни выбора, на основании которых можно будет сформировать политику. Важная функция — анализ "кротом" JavaScript.

Дополнительно должна быть предусмотрена возможность определения пути навигации, по которому может быть вызвана указанная страница. Если, к примеру, задано, что страница z.html должна быть достижимой лишь после того, как пользователь запросил сначала страницу x.html, а потом y.html, то WAF блокирует запрос непосредственно к z.html. В этом случае говорят о "потоках", для которых определяются объекты отправителя и получателя. Ряд производителей предлагают собственный браузер для тонкой настройки, который также оказывается полезен при формировании политики. Поскольку правило не должно генерироваться динамически, статический подход значительно более производителен. Проверка того, было ли статическое значение в запросе HTTP несанкционированно изменено, для большинства WAF не представляет проблемы. Однако при использовании статического подхода WAF должны защищать также от изменений динамических значений, генерируемых на сервере. Это динамическое значение, генерируемое приложением во время выполнения, встречается, к примеру, в URL или в скрытых полях. Злоумышленник может просто изменить его и отправить в следующем запросе HTTP приложению Web. В результате, к примеру, товар будет помещен в корзину покупателя по более низкой цене (рис. 3). Другие приложения для однозначной идентификации пользователя применяют идентификаторы сеанса, которые генерируются на сервере в качестве динамических параметров. Если злоумышленнику удается добраться до идентификатора сеанса другого пользователя, он получает доступ к пользовательскому сеансу и тем самым к его данным без знания имени пользователя и пароля. Для защиты ландшафта ИТ можно настроить WAF таким образом, чтобы он, к примеру, удалял этот динамический параметр из отклика.

Еще одна важная задача WAF — проверка маркеров Cookie. WAF должен предотвращать попадание в приложение Web модифицированных пользователем маркеров (Cookie Poisoning). Если злоумышленнику удастся это сделать, не исключено, что он, как и в предыдущем примере с идентификатором сеанса, попытается получить доступ к сеансу другого пользователя. Одним из вариантов проверки в WAF является помещение зашифрованных и подписанных имен и содержимого всех маркеров пользователя в дополнительном сеансовом маркере, который имеется только в памяти у клиента. Если маркеры передаются браузером приложению, как это происходит в случае каждого запроса HTTP, WAF посредством дополнительного сеансового маркера распознает, изменил ли злоумышленник один или несколько маркеров. К сожалению, некоторые приложения меняют содержимое маркеров и на стороне клиента. Поэтому важно, чтобы маркеры таких приложений могли исключаться перед проверкой. Другой вариант — шифровать все маркеры приложений. При этом, как описано выше, отдельные маркеры могут перед шифрованием исключаться. Когда приложение изменяет на клиенте содержимое отдельного маркера, оно должно быть представлено открытым текстом. Большинство WAF работают в качестве обратного посредника. Они принимают от клиента запрос HTTP вместо сервера Web или балансировщика нагрузки, анализируют его соответствие политике и организуют новое соединение HTTP, наделенное собственным IP-адресом, с сервером Web или балансировщиком нагрузки (рис. 4).

Поэтому для регистрации IP-адресов отправителя на сервере Web необходимо, чтобы WAF мог передавать дальше исходный IP-адрес клиента, к примеру, в заголовке X-Forwarded-For-Header (XFF). Терминирование SSL и аппаратное ускорение шифрования и дешифрования включая согласование ключа должно поддерживаться в любом фильтре приложений, иначе анализу оказываются доступны только незашифрованные данные. Пассивный режим мониторинга, когда запросы злоумышленника не блокируют, а только отмечаются в отчетах, полезен не только при вводе в эксплуатацию, но и в случае высокочувствительных приложений. Тем самым остается по крайней мере возможность получения информации обо всех атаках на приложение Web и сервер Web без прерывания работы приложения.

31 Календарно-плановое руководство защитой информации.

32 Планирование защиты информации.

Основные цели планирования

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

Основными целями планирования мероприятий по защите информации являются:

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

· установление персональной ответственности всех должностных лиц предприятия за решение вопросов защиты информации в ходе производственной и иной деятельности предприятия;

· определение сроков (времени, периода) проведения конкретных мероприятий по защите информации;

· систематизация (объединение) всех проводимых на плановой основе мероприятий по различным направлениям защиты конфиденциальной информации;

· установление системы контроля за обеспечением защиты информации на предприятии, а также системы отчетности о выполнении конкретных мероприятий;

· уточнение (конкретизация) функций и задач, решаемых отдельными должностными лицами и структурными подразделениями предприятия.

Основой для планирования мероприятий по защите информации на предприятии служат:

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

· требования заказчиков проводимых предприятием в рамках соответствующих договоров (контрактов) совместных и других работ;

· положения международных договоров (соглашений) и иных документов, определяющих участие предприятия в тех или иных формах международного сотрудничества;

· положения внутренних организационно-распорядительных документов предприятия (приказов, директив, положений, инструкций), определяющих порядок ведения производственной и иной деятельности, а также конкретизирующих вопросы защиты конфиденциальной информации на предприятии;

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

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

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

· особенности повседневной деятельности предприятия и специфика выполнения на предприятии работ с использованием различных видов конфиденциальной информации.

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

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

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

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

33 Сущность, принципы и методы концептуальной стандартизации в области построения АСОД.

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

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

Разработка стандартов для открытых систем, в том числе и стандартов в области безопасности ИТ, осуществляется рядом специализированных международных организаций и консорциумов таких, как, например, ISO, IЕС, ITU-T, IEEE, IАВ, WOS, ЕСМА, X/Open, OSF, OMG и др.

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

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

Архитектура безопасности Взаимосвязи открытых систем

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

В 1986 г. рядом международных организаций была принята Архитектура безопасности ВОС (АБ ВОС). В архитектуре ВОС выделяют семь уровней иерархии: физический, канальный, сетевой, транспортный, сеансовый, представительный и прикладной. Однако в АБ ВОС предусмотрена реализация механизмов защиты в основном на пяти уровнях. Для защиты информации на физическом и канальном уровне обычно вводится такой механизм защиты, как линейное шифрование. Канальное шифрование обеспечивает закрытие физических каналов связи с помощью специальных шифраторов. Однако применение только канального шифрования не обеспечивает полного закрытия информации при ее передаче по ИВС, так как на узлах коммутации пакетов информация будет находиться в открытом виде. Поэтому НСД нарушителя к аппаратуре одного узла ведет к раскрытию всего потока сообщений, проходящих через этот узел. В том случае, когда устанавливается виртуальное соединение между двумя абонентами сети и коммуникации, в данном случае, проходят по незащищенным элементам ИВС, необходимо сквозное шифрование, когда закрывается информационная часть сообщения, а заголовки сообщений не шифруются. Это позволяет свободно управлять потоками зашифрованных сообщений. Сквозное шифрование организуется на сетевом и/или транспортном уровнях согласно ЭМ ВОС. На прикладном уровне реализуется большинство механизмов защиты, необходимых для полного решения проблем обеспечения безопасности данных в ИВС.

АБ ВОС устанавливает следующие службы безопасности (см. табл.4.2.).

· обеспечения целостности данных (с установлением соединения, без установления соединения и для выборочных полей сообщений);

· обеспечения конфиденциальности данных (с установлением соединения, без установления соединения и для выборочных полей сообщений);

· контроля доступа;

· аутентификации (одноуровневых объектов и источника данных);

· обеспечения конфиденциальности трафика;

· обеспечения невозможности отказа от факта отправки сообщения абонентом - передатчиком и приема сообщения абонентом - приемником.

Состояние международной нормативно-методической базы

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

1. Общие принципы управления информационной безопасностью.

2. Модели безопасности ИТ.

3. Методы и механизмы безопасности ИТ (такие, как, например: методы аутентификации, управления ключами и т.п.).

4. Криптографические алгоритмы.

5. Методы оценки безопасности информационных систем.

6. Безопасность EDI-технологий.

7. Безопасность межсетевых взаимодействий (межсетевые экраны).

8. Сертификация и аттестация объектов стандартизации.

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

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

На роль такого документа претендует, находящийся в стадии утверждения проект международного стандарта ISO/IEC DTR 13335-1,2,3 - "Информационная технология. Руководство по управлению безопасностью информационных технологий". Данный документ содержит:

· определения важнейших понятий, непосредственно связанных с проблемой управления безопасностью ИТ; - определение важных архитектурных решений по созданию систем управления безопасностью ИТ (СУБ ИТ), в том числе, определение состава элементов, задач, механизмов и методов СУБ ИТ;

· описание типового жизненного цикла и принципов функционирования СУБ ИТ;

· описание принципов формирования политики (методики) управления безопасностью ИТ;

· методику анализа исходных данных для построения СУБ ИТ, в частности методику идентификации и анализа состава объектов защиты, уязвимых мест информационной системы, угроз безопасности и рисков и др.;

· методику выбора соответствующих мер защиты и оценки остаточного риска;

· принципы построения организационного обеспечения управления в СУБ ИТ и пр.

Стандартизация моделей безопасности ИТ

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

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

Можно выделить следующие международные стандарты и другие документы, в которых определяются основные модели безопасности ИТ:

· ISO/IEC 7498-2-89 - "Информационные технологии. Взаимосвязь открытых системы. Базовая эталонная модель. Часть 2. Архитектура информационной безопасности";

· ISO/IEC DTR 10181-1 - "Информационные технологии. Взаимосвязь открытых систем. Основы защиты информации для открытых систем. Часть 1. Общее описание основ защиты информации ВОС";

· ISO/IEC DTR 10745 - "Информационные технологии. Взаимосвязь открытых систем. Модель защиты информации верхних уровней";

· ISO/IEC DTR 11586-1 - "Информационные технологии. Взаимосвязь открытых систем. Общие функции защиты верхних уровней. Часть 1. Общее описание, модели и нотация";

· ISO/IEC DTR 13335-1 - "Информационные технологии. Руководство по управлению безопасностью информационных технологий. Часть 1. Концепции и модели безопасности информационных технологий".<

Стандартизация методов и механизмов безопасности ИТ

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

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

· шифрования информации, предназначенные для защиты информации в случае перехвата ее третьими лицами;

· контроля целостности, предназначенные для обеспечения того, чтобы информация не была искажена или подменена;

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

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

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

· ISO/IEC 9798-91 - "Информационные технологии. Защита информации. Аутентификация объекта".

Часть 1. Модель.
Часть 2. Механизмы, использующие симметричные криптографические алгоритмы.
Часть 3. Аутентификация на базе алгоритмов с открытыми ключами.
Часть 4. Механизмы, использующие криптографическую контрольную функцию.
Часть 5. Механизмы, использующие алгоритмы с нулевым разглашением.

· ISO/IEC 09594-8-88 - "Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификации";

· ISO/IEC 11577-94 - "Информационные технологии. Передача данных и обмен информацией между системами. Взаимосвязь открытых систем. Протокол защиты информации на сетевом уровне";

· ISO/IEC DTR 10736 - "Информационные технологии. Передача данных и обмен информацией между системами. Протокол защиты информации на транспортном уровне";

· ISO/IEC CD 13888 - "Механизмы предотвращения отрицания".

Часть 1. Общая модель.
Часть 2. Использование симметричных методов.
Часть 3. Использование асимметричных методов;

· ISO/IEC 8732-88 - "Банковское дело. Управление ключами";

· ISO/IEC 11568-94 - "Банковское дело. Управление ключами".

Часть 1. Введение. Управление ключами.
Часть 2. Методы управления ключами для симметричных шифров.
Часть 3. Жизненный цикл ключа для симметричных шифров;

· ISO/IEC 11166-94 - "Банковское дело. Управление ключами посредством асимметричного алгоритма".

Часть 1. Принципы процедуры и форматы.
Часть 2. Принятые алгоритмы, использующие криптосистему RSA;

· ISO/IEC DIS 13492 - "Банковское дело. Управление ключами, относящимися к элементам данных";

· ISO/IEC CD 11770 - "Информационные технологии. Защита информации. Управление ключами".

Часть 1. Общие положения.
Часть 2. Механизмы, использующие симметричные методы.
Часть 3. Механизмы, использующие асимметричные методы;

· ISO/IEC DTR 10181- "Информационные технологии. Взаимосвязь открытых систем. Основы защиты информации для открытых систем".

Часть 1. Общее описание основ защиты информации в ВОС.
Часть 2. Основы аутентификации.
Часть 3. Управление доступом.
Часть 4. Безотказность получения.
Часть 5. Конфиденциальность.
Часть 6. Целостность.
Часть 7. Основы проверки защиты.

К этому же уровню следует отнести стандарты, описывающие интерфейсы механизмов безопасности ИТ:

· ISO/IEC 10164-7-92. "Информационные технологии. Взаимосвязь открытых систем. Административное управление системы. Часть 7. Функции уведомления о нарушениях информационной безопасности".

· ISO/IEC DTR 11586. "Информационные технологии. Взаимосвязь открытых систем. Общие функции защиты верхних уровней".

Часть 1. Общее описание, модели и нотация.
Часть 2. Определение услуг сервисного элемента обмена информацией защиты.
Часть 3. Спецификация протокола сервисного элемента обмена информацией защиты.
Часть 4. Спецификация синтаксиса защищенной передачи.

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

Стандартизация международных криптографических алгоритмов

ISO стандартизировала ряд криптографических алгоритмов в таких международных стандартах, как, например:

· ISO/IEC 10126-2-91 - "Банковское дело. Процедуры шифрования сообщения. Часть 2. Алгоритм DEA";

· ISO/IEC 8732-87 - "Информационные технологии. Защита информации. Режимы использования 64-битного блочного алгоритма";

· ISO/IEC 10116-91- "Банковское дело. Режимы работы n-бит блочного алгоритма шифрования";

· ISO/IEC 10118-1,2-88 - "Информационные технологии. Шифрование данных. Хэш-функция для цифровой подписи";

· ISO/IEC CD 10118-3,4 - "Информационные технологии. Защита информации. Функции хэширования";

· ISO/IEC 9796-91 - "Информационные технологии. Схема электронной подписи, при которой производится восстановление сообщения";

· ISO/IEC CD 14888 - "Информационные технологии. Защита информации. Цифровая подпись с добавлением". Однако широкое внедрение этих алгоритмов представляется малореальным, поскольку политика крупных государств направлена, как правило, на использование собственных криптоалгоритмов.

Поиск по сайту: