Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Прикрывайте Web-тылы!

Лори Маквитти

Чтобы обезопасить доступные из Интернет корпоративные данные, необходимо определить, какая защита требуется каждому вашему информационному ресурсу.

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

Политика безопасности

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

Необходимо исчерпывающе ответить на следующие вопросы:

· Кому и к каким службам, приложениям и данным следует предоставить доступ?

· Где должен находиться источник запроса на получение доступа — снаружи или внутри корпоративной сети?

· Когда этот доступ должен предоставляться — в рабочее или в нерабочее время?

· Какую информацию вы стремитесь защитить?

Полную версию данной статьи смотрите в 12-ом номере журнала за 2002 год.

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

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

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

Спасет ли вас SSL?

Некоторые пользователи ошибочно полагают, что протокол SSL (Secure Sockets Layer) способен защитить их от всех угроз. На самом деле он может предотвратить перехват ваших бизнес-транзакций, но гарантирует безопасность последних лишь во время их передачи, если только вы не используете клиентские сертификаты. Сертификаты обеспечивают более надежную аутентификацию по сравнению с обычными паролями. Требование предъявить клиентский сертификат для доступа затруднит имперсонализацию (имитирование зарегистрированного пользователя посторонним лицом) и обеспечит более высокую степень защиты, поскольку вы можете быть уверены в том, кто именно пытается получить доступ к вашим данным. (Более подробно об SSL см. по адресу http://www.nwc.com/1212/1212f415.html.)

В ряде случаев с точки зрения реализации стратегии безопасности протокол SSL может оказаться помехой. Большинство систем обнаружения вторжений (Intrusion-Detection System — IDS) и сканеров вирусов “не умеют” взаимодействовать с SSL, в результате чего они беспрепятственно пропускают шифрованный трафик. В целях обеспечения инспектирования шифрованного трафика пограничными устройствами до его попадания внутрь корпоративной сети изменим немного сетевую архитектуру. При этом для каждого логического соединения предусмотрим два физических: сначала клиент соединяется с пограничным устройством, затем это устройство — с сервером, выполняющим запрос клиента.

Такую архитектуру иногда называют совмещенной (co-appliance) или траверсной (side-arm) конфигурацией. Средством проведения в жизнь разработанной вами политики безопасности станет устройство управления трафиком, которым обычно служит распределитель нагрузки (рис. 1). В данной конфигурации процесс расшифровки трафика начинается с его перенаправления на SSL-устройство, где он проверяется службами IDS и антивирусами. После проверки трафик вновь направляется на распределитель нагрузки (коммутатор контента) и уже потом — на ваши серверы.

Аналогичной функциональности можно добиться и от устройства управления трафиком (traffic director), если оно способно выполнять роль SSL-терминала. Сконфигурируйте ваш регулятор трафика как реверсный сервер-посредник для SSL-соединений, чтобы он управлял процессом шифровки/расшифровки трафика между клиентом и самим собой. В этом случае у вас исчезнет необходимость во внешнем SSL-устройстве, зато появятся дополнительные трудности. Так, если вы используете клиентские сертификаты, то заниматься аутентификацией придется устройству управления трафиком, а не серверам приложений. Установка трафик-менеджера (traffic manager), помещающего “удостоверения личности” пользователей в HTTP-заголовки, например такого, как Big-IP компании F5 Networks, снимает эту проблему (см. http://www.nwc.com/1223/1223sp1.html).

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

“Как же это работает?” — спросите вы. Все происходит следующим образом.

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

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

· Сервер обслуживает запрос, и его ответ по SSL-соединению отсылается обратно пограничному трафик-менеджеру.

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

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

Теперь давайте отвлечемся на минутку и обсудим вопрос хранения ключей. Никогда не храните секретные ключи (private keys) на диске того самого сервера, который пользуется ими для шифрования данных. Вместо этого для хранения ключей используйте смарт-карты или аппаратные (криптографические) модули защиты (Hardware Security Module — HSM). В этом случае взломщику, чтобы украсть ключи, потребуется физический доступ к устройству считывания карт (card reader); тем самым обеспечивается лучшая защита, так как все управление доступом к ключам осуществляется через смарт-карты. Компании Rainbow Technologies, nCipher и Ingrian предлагают продукты для без-опасного управления ключами. Для этих целей не стоит использовать обычный съемный накопитель — большинство ОС воспринимают их как смонтированные файловые системы, вследствие чего к ним возможен удаленный доступ.

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

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

Контроль за установлением соединений с вашими внутренними серверами необходим для более жесткого управления доступом, что обеспечивает лучшую защиту. Если ваш распределитель нагрузки умеет заменять исходные IP-адреса, то все ваши серверы, расположенные за ним, должны принимать Web-запросы только от этого распределителя — и ни от кого другого. Другими словами: используйте имеющиеся средства управления доступом на базе протокола TCP, либо создайте “сэндвич” из межсетевых экранов, чтобы разрешить прохождение запросов только от конкретных, доверенных клиентов. Прежде всего установите для МЭ правило “отказывать всем” и разрешайте доступ к вашим системам только по мере надобности, когда это нужно для выполнения ими своих задач.

Это особенно важно для серверов БД, ведь именно там находятся ваши главные “сокровища”. Если вы не шифруете хранящиеся конфиденциальные данные (что следовало бы делать), то нужно особо позаботиться о разрешении доступа к ним только тем системам, которым эти данные необходимы.

Хотя описанная выше конфигурация и может повысить производительность ваших приложений, но БД будет уязвима, поскольку Web-серверу необходим прямой маршрут к клиенту. Значит, у этого клиента появится прямой маршрут к серверу БД, что подвергнет последний риску возможного вторжения, если только вы не установите дополнительные правила, увеличив тем самым нагрузку на МЭ. И будьте поосторожнее с применением конфигураций OPR (Out of Path Return) или DSR (Direct Server Return) на Web-серверах и серверах приложений, расположенных за распределителем нагрузки (рис. 2). В этих конфигурациях для соединения клиента с сервером используется распределитель нагрузки, но сервер может отослать ответ клиенту напрямую, минуя его.

Системы APS

Аналогично системам IDS системы APS (Application Protection Systems) выявляют аномальный трафик и реагируют на него (на прикладном уровне). Но между этими системами есть два существенных отличия. Первое — действия APS носят превентивный характер: регистрируя аномалию, система может блокировать запрос, чтобы он не попал на ваши серверы. Второе — APS инспектирует не отдельные пакеты, а потоки данных: исследуя содержимое полезной нагрузки трафика, она определяет легитимность каждого запроса в целом. Система APS должна располагаться перед вашим Web-сервером или распределителем нагрузки (рис. 3).

Такого рода системы, как, например, поставляемые компаниями Kavado, Protegrity, Sanctum и Stratum8, начинают свою работу с формирования наборов правил по результатам наблюдений за “общением” клиентов с серверами. Любой запрос, не укладывающийся в установленные рамки, рассматривается как атака, и система реагирует на него в соответствии с выработанной политикой безопасности.

Такие системы могут обнаруживать и отражать атаки самого разного рода еще до появления “заплаты” для элементов уязвимости (exploits), на которые эти атаки нацелены. Например, распространявшиеся посредством аномальных запросов вирусы Nimda и Code Red успешно отлавливались APS задолго до того, как соответствующие “заплаты” появились.

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

Предположим, что у вас есть простое приложение с тремя доступными пользователю страницами: login.php (регистрация), enterorder.php (ввод заказа) и showorder.php (просмотр заказа). Выбрав метод post для передачи содержимого этих форм, вы сможете указать вашему коммутатору контента URL-ссылки этих трех страниц и разрешить клиентам запрашивать ваши серверы БД, пользуясь только ими. Вам вряд ли понравится метод get, так как с увеличением числа вариаций URL-ссылок сложность набора правил будет повышаться, что часто случается на сайтах электронной коммерции. Разумеется, коммутатор контента сможет определить точки входа и при использовании метода get, но метод post проще и безопаснее, так как вся входная форма, включая идентификатор сеанса (session ID), передается в составе полезной нагрузки, а не в заголовке. Если у вас большое число страниц, набор правил может увеличиться до огромных размеров, но примите во внимание то, к чему может привести кража конфиденциальной информации. Потенциальные потери времени и репутации, штрафы и даже возможные судебные иски в случае обнародования конфиденциальной информации ваших клиентов — все это оправдывает затраты на ее защиту.

Можно также рассмотреть вариант использования МЭ, являющегося посредником для приложений (application proxy firewall). Вместо прямого соединения со службой клиент устанавливает соединение с посредником, а последний в свой черед соединяется с требуемой службой и возвращает запрошенные данные клиенту. Осуществляя контроль за соединением, посредник способен пресечь сетевые атаки и большинство атак на приложения, таких, как переполнение буфера (buffer overflow) или запрещенные протоколом действия (protocol violation). Он также обеспечит вас необходимыми средствами аутентификации и журналами аудита, позволив тем самым усилить контроль за доступом к вашим приложениям (см. http://www.nwc.com/1308/1308sp1.html).





  
12 '2002
СОДЕРЖАНИЕ

бизнес

• Если мерить в "Супердомах"...

• Парад "великих магистров"

• Консалтинговый договор: полезные советы

локальные сети

• Серверы нового поколения

• Сервер Dell побеждает

• Данные на ладони

• Охлаждение оборудования в монтажных шкафах

• Медиаконвертеры расширяют границы сетей

корпоративные сети

• Windows для пользователей Unix

• Держим оборону против спама и спамеров

• Компьютер на службе правосудия

услуги сетей связи

• Новая волна VoIP

• Реорганизация телефонной службы поддержки клиентов

• Тестирование телекоммуникационных протоколов: проблемы и подходы

• Тестирование системы сигнализации: от кабеля до ОКС7

защита данных

• Электропитание: думай о миллисекундах

• Руководство по компьютерной безопасности для начинающих

• Прикрывайте Web-тылы!

новые продукты

• Новые серверы Primepower; Интеллектуальные сети связи Tellin; Novell выпускает четвертую версию ZENworks for Desktops; Серверы ProLiant стали мощнее; ИБП Green-Point с переключаемой фазностью


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх