Руководство по безопасности в Lotus Notes

Требования к защищенной инфраструктуре

Разбить на страницы
Показывать лекцию целиком

Под термином "инфраструктура" будем понимать:

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

    3.1 Потребность в защищенных инфраструктурах

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

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

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

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

    3.2 Требования к обеспечению безопасности инфраструктуры

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

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

    Требования к обеспечению безопасности бизнеса, как правило, включают:

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

    3.2.1 Обеспечение конфиденциальности данных

    В этом разделе опишем следующие методы обеспечения конфиденциальности данных:

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

    Во-первых, мы предполагаем, что вы имеете общее представление о криптографии и моделях шифрования с использованием симметричных и несимметричных ключей (общие секретные ключи и открытые/секретные ключи). Далее мы поведем разговор на высоком уровне, упомянув лишь о том, что зашифрованные данные не могут быть расшифрованы человеком или системой, которые не владеют корректным ключом для расшифровки. Обзор криптографии представлен в разделе 1.4, "Криптографические техники", а подробное рассмотрение криптографии с использованием асимметричного ключа можно найти в лекции 6, "Инфраструктуры открытых ключей".

    Во-вторых, позвольте нам обратить внимание на то, что мы не говорим о необходимости шифрования всех данных повсеместно. Ранее в этом курсе мы обсуждали процесс классификации данных. Дополнительным аспектом классификации данных является определение требуемого уровня защиты в зависимости от того, где находятся данные в любой заданный промежуток времени. К примеру, ваша политика безопасности может требовать, чтобы почтовый файл Notes хранился в зашифрованном виде на внутреннем сервере Domino. Вспомним, что, когда вы шифруете базу данных Domino на сервере Domino, она шифруется с использованием открытого ключа сервера. Но если реплика почтового файла сохранена на лэптопе, который потенциально может быть вынесен из учреждения, ваша политика безопасности может требовать и шифрования локальной реплики. Шифрование локальной реплики клиента Notes шифрует почтовую базу данных с использованием открытого ключа пользователя. Но помните о том, что процесс репликации Notes Domino включает передачу данных с применением опр еделенного вида связи по сети. Репликация в Notes (инициируемая сервером Domino или клиентом Notes) представит данные на сетевой порт в незашифрованном виде, так как шифрование базы данных, по существу, становится прозрачным для задачи репликации сервера или клиента. Помним и о том, что задача репликации запускается под определенным идентификатором (ID), что шифрует базу данных. По умолчанию шифрование порта на сервере Domino не разрешено, и, таким образом, вы остановитесь на сценарии, описанном на рис. 3.1.

    (рис 3.1) Незашифрованная репликация

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

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

    Совет! Защита, предоставляемая шифрованием баз данных на сервере Domino, зависит от того, насколько безопасным является доступ как к зашифрованному файлу базы данных, так и к ID-файлу сервера на уровне ОС сервера. Так как пароли в ID серверов Domino используются редко (для разрешения автоматических рестартов), скомпрометированный ID-файл сервера может быть использован для открытия копии зашифрованной базы данных, скопированной с сервера. Поэтому убедитесь, что разрешение на доступ к ID-файлу сервера дано только для учетной записи администратора на Windows-серверах или только для учетных записей Notes и root для ОС Unix.

    Физическое и логическое разделение серверов и сетей

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

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

    К одним из наиболее важных разделений серверов, или, если быть более точным, служб, относятся службы доменных имен DNS (Domain Name Services). DNS используется для установления соответствия между IP-адресами и именами хостов и обратного поиска IP-адресов по именам хостов. Большинство организаций имеют как внешние IP-адреса, так и используемые внутри организаций частные IP-адреса. Примите во внимание, что существуют серверы, которые вам необходимо сделать доступными и "видимыми" для внешних пользователей. Этим внешним пользователям необходимо разрешить доступ к вашим открытым именам хостов и записям почтового обмена (MX) на ваших свободно доступных серверах. Также помните, что у вас есть совокупность внутренних пользователей, имеющих два требования: способность разрешать внешним серверам IP-адреса и способность разрешать всем внутренним серверам их IP-адреса. Мы описали концепцию "раздельной DNS" в лекции 4, "Компоненты и уровни безопасности".

    Разделение систем применяется для ограничения доступа только в тех областях, в которых пользователь нуждается в своих бизнес-функциях или транзакциях. Это относится как к конечным пользователям, так и к администраторам. Как было упомянуто в этом курсе ранее, одна из наибольших угроз исходит от вашего внутреннего персонала; она больше, чем угроза от злонамеренных, умышленных или случайных действий. Нашей основной целью является не допустить действий отдельного индивидуума по внесению единой точки отказа. У многих ИT-профессионалов есть ужасные истории о происшествиях, причиной которых стал действующий из самых лучших побуждений администратор, имеющий возможно слишком много полномочий от единой точки входа. Таким образом, в некоторых случаях нам необходимо разрабатывать среду для защиты нас от самих себя! Если посмотреть на это с другой стороны, то накладные расходы по уменьшению воздействия административных ошибок являются нашими собственными проблемами.

    Повышение защищенности от сетевого сниффинга

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

    Подверженность этому явлению можно значительно снизить путем использования двух принципов:

  • Уменьшение видимости пакетов путем ограничения физических путей прохождения TCP/IP-трафика. К примеру, Ethernet-коммутатор не производит широковещательной рассылки всех пакетов на все порты, как это делает простой концентратор. Установка адресов хостов и фильтров портов на маршрутизаторах может ограничить возможность прослушивания сети за пределами локального сегмента ЛВС. Пакеты TCP/IP должны быть ограничены минимальным количеством сетевых сегментов, требуемых для доставки из точки А в точку Б. Еще одной технологией, становящейся широкодоступной в сетевых коммутаторах для обеспечения гранулированной сегментации сети с использованием меньшего количества оборудования, является применение возможностей виртуальной ЛВС (VLAN).
  • Шифрование пакетов в сетях, в которых допускается наличие неразрешенных устройств или сниффинговой активности. Вместе или по отдельности могут использоваться шифрование на уровне приложений или шифрование на уровне сессии. Как правило, шифрование на уровне сессии, такое, как SSL, должно использоваться для защиты чувствительных данных в тех случаях, когда приложение не гарантирует, что на момент покидания сервера приложений данные зашифрованы (сервер отображает данные в незашифрованном виде, даже несмотря на то что физически он хранит данные в шифрованном виде). Шифрование на уровне сессии является также подходящим для защиты ID и паролей пользователей, передаваемых во время диалога аутентификации.
  • С распространением беспроводных Ethernet-сетей стандарта 802.11 сетевой сниффинг больше не требует наличия физического сетевого порта. В настоящее время устройства, которые можно повесить на цепочку с ключами, способны определять "хотспоты", доступно множество чувствительных антенн и специального программного обеспечения. Визит на сайт netstumbler.com познакомит со ссылками, описывающими притязания на "Wi-Fi-серфинг из проезжающего мимо автомобиля", новыми инструментами сканирования, здесь представлено и множество другой информации, заставляющей отвечающего за безопасность человека дважды подумать о реализации беспроводной сети. В то время как сильно ожидавшийся стандарт беспроводной безопасности IEEE 802.11i в результате опубликован в 2004 г., в настоящее время безопасность в беспроводных ЛВС в большинстве случаев отсутствует. Как было показано, шифрование WEP (Wired Equivalent Privacy) довольно легко взламываемо, а его преемник, шифрование WPA (Wi-Fi Protected Access), является неадекватным в ряде случаев выполнения (обычно из-за плохо сконфигурированных систем). Что еще более удивительно, так это то, что даже беспроводные изделия, которые используют WEP, с его слабым и устаревшим шифрованием, иногда запрещаются (или никогда не разрешаются) администраторами, которым надоели их пользователи с вопросами о совместимости карт беспроводного доступа. Как и со множеством других проблем в сети, при обеспечении безопасности часто идут на компромисс для создания удобства в использовании.

    Идентификация абонентов и разрешение доступа

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

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

  • Каким образом можно подтверждать личность людей?
  • Если вы собираете и храните эту информацию о людях, как сохранить ее приватность?
  • Если вы собираете информацию о людях, как эта информация используется?
  • Механизмы целостности и конфиденциальности информации, или и того и другого вместе, должны применяться для защиты передаваемых посредством Интернета важных данных, включая информацию, которая идентифицирует людей, информацию об их кредитных картах, информацию о заказах и договорах и т. д. Поэтому мы рекомендуем трактовать всю информацию о личностях и удостоверении личностей пользователей как конфиденциальную информацию. Эта информация включает в себя как ваших внутренних пользователей, так и внешних. Законы о защите персональной информации различны в разных странах и зачастую диктуют особые требования для обеспечения хранения и защиты информации о служащих, подрядчиках, бизнес-партнерах, заказчиках и поставщиках. Вы обязаны обеспечить соответствие всем применяемым законам о защите персональной информации (правовые консультации выходят за рамки этого курса).

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

  • Отслеживаемость. Возможность отслеживания в системе всей активности человека, инициировавшего действие. Это имеет профилактическое значение, гарантирующее, что пользователи знают о невозможности анонимной активности (значительно уменьшает соблазн просмотреть или злоупотребить системой), и позволяющее восстановить все действия вплоть до инцидента с безопасностью.
  • Минимальные привилегии. Имеют целью обеспечить пользователя только тем набором привилегий, которые необходимы для выполнения каждым из пользователей санкционированных обязанностей. Это помогает сократить нередко встречающуюся цепочку: любопытство, просмотр, обнаружение, притягательность, соблазн и в конце концов неправомерное действие. Основной подход уменьшения привилегий – "необходимо знать".
  • Разделение обязанностей. Целью является обеспечение того, чтобы исполнял, одобрял и рассчитывал какое-либо критическое для безопасности действие не единственный человек. Основной целью является не позволить единственному индивидууму выполнить действия по внесению единой точки отказа.
  • Использование прокси-систем

    Использование прокси-систем может обеспечить защиту серверных приложений и Web-серверов. Считайте, что прокси является разновидностью брандмауэра, которая работает за пределами уровня протокола TCP/IP. На них иногда ссылаются как на "шлюзы приложений", хотя этот термин в последнее время используется менее часто. Протоколы приложений обычно поддерживают HTTP, FTP и telnet, но виртуально могут включать любой протокол TCP/IP. Прокси-системы для конечного пользователя обычно прозрачны. Мы исследуем характеристики брандмауэров и прокси, а также выполняемые прокси специфичные функции в последующих лекциях. На этой стадии в качестве ключевого момента вы должны понимать, что прокси являются неотъемлемым компонентом передового опыта обеспечения безопасности.

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

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

    Реализация обнаружения вторжения

    Вторжение подразумевает ситуации, когда некая сторона (или стороны) получает доступ, пытается получить доступ или пытается разрушить компьютерный ресурс, который ей не разрешено использовать. Вовлеченной стороной может выступать человек, программа либо их комбинация. Компьютерным ресурсом, выбранным в качестве цели, может быть сервер, приложение, база данных, сетевая ссылка и т. д. Системы обнаружения вторжения (IDS) являются важной мерой обеспечения безопасности, потому что они могут предупредить вас об атаке еще в процессе ее выполнения (успешная или нет). Раннее обнаружение является важным моментом в обеспечении безопасности, поскольку попытки взломов или атак, как правило, начинаются с "исследования" цели для нахождения возможных уязвимостей или перспектив доступа. Это исследование обычно выполняется посредством сканирования TCP/IP портов для последующей их эксплуатации с целью определения возможности атаки. В идеальном случае ваши методы обнаружения вторжений позволят обнаружить подозрительную активность на ранних фазах попыток атаки.

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

    Существует вопрос, который мы слышим от некоторых клиентов: "Подразумевает ли обнаружение сетевого вторжения перехват сообщений?" Это поднимает интересные этические вопросы, однако правовые понятия относительно определения перехвата сообщений широко расходятся в разных странах. В большинстве стран разрешено производить мониторинг активности на вашем собственном оборудовании, хотя могут быть установлены ограничения на то, какой контент может, а какой не может подвергаться мониторингу. Возможны также различия в зависимости от того, проводится ли мониторинг для внутренних пользователей (служащих) либо для внешних клиентов. В США действует легальное преимущество, позволяющее нанимателю отслеживать использование собственного оборудования компании ее служащими. Однако мы рекомендуем, чтобы весь внутренний мониторинг активности служащих был четко разъяснен либо в трудовой политике, либо в политике безопасности (либо в обеих).

    Существует четыре основные категории систем обнаружения вторжения (IDS): сетевые (NIDS), системы проверки целостности хоста, системы мониторинга активности и сканеры контента. Последние не всегда рассматриваются как IDS, но большинство людей согласится, что e-mail-вирус является разновидностью атаки, поэтому и сканер-вирусов может рассматриваться как специализированный тип IDS. Мы рассмотрим все эти различные типы IDS в разделе 4.1.5, "Системы обнаружения вторжения".

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

    Обеспечение целостности данных

    В этом разделе мы опишем следующие методы обеспечения целостности данных:

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

    "Целостность данных" в простейшем смысле означает, что данные не были изменены. В сетевом контексте существует две содержащиеся в пакете части: заголовок и полезная нагрузка данных. Предотвращению или обнаружению изменений в информации заголовка способствует управление доступом и аутентификацией с точки зрения сетевого (IP) адреса. Аутентификация (в этом контексте) означает, что мы можем идентифицировать адреса источника и получателя. С сетевой точки зрения можно применить управление сетевым доступом, основанное на IP-адресах и транспортных протоколах. Но сетевые адреса источника и получателя в пакете обычно представляются в незашифрованном виде; таким образом, мы нуждаемся в средствах предотвращения или обнаружения несанкционированного изменения данных либо их фальсификации.

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

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

    Управление доступом для безопасного администрирования

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

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

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

  • определение стандартных систем управления доступом;
  • определение административных полномочий безопасности, связанных с этими системами управления доступом;
  • обязательные стандарты управления и реализации по умолчанию для этих систем управления доступом.
  • Обеспечение доступности

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

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

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

    Управление административной деятельностью по сопровождению

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

  • Четко ли определены допустимые пределы полномочий и приемлемость их использования?
  • Очевидны ли процессы управления назначением полномочий и своевременным удалением полномочий при окончании индивидуальной необходимости ведения бизнеса?
  • Имеет ли персонал, в обязанности которого входит эксплуатация и поддержка операционной системы, заданные их индивидуальным пользовательским ID системные полномочия? Если нет, может ли вся их деятельность отслеживаться точно индивидуально с абсолютной достоверностью?
  • Имеет ли персонал, в обязанности которого входит администрирование безопасности, заданные их индивидуальным пользовательским ID полномочия администрирования безопасности?
  • Может ли запуск служебных механизмов и агентов (служб, "демонов", заданий по расписанию), являющихся частью операционной системы, задаваться в отделе эксплуатации и поддержки системы способом, отличным от индивидуального?
  • Имеет ли каждый, кто способен начать работу или модифицировать служебные механизмы или агенты, действительную необходимость в этом для ведения бизнеса?
  • Могут ли члены групп с административными полномочиями быть индивидуально идентифицируемы и управляемы?
  • Как часто будет пересматриваться членство в группе для обеспечения гарантии того, что полномочия доступа удалены своевременно по окончании индивидуальной необходимости ведения бизнеса?
  • Деятельность, выполняемая в процессе использования системных полномочий или полномочий администрирования безопасности, должна быть особым образом санкционирована менеджментом путем внесения изменений в процесс управления либо должна быть совместимой с индивидуальным видом занятости персонала. Менеджмент организации должен убедиться, что имеющие полномочия люди осведомлены об этом требовании. Одной из наиболее важных процедур, которые вы должны определить в политике безопасности, является удаление административного доступа для тех людей, обязанности которых по работе закончились или изменились.

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

    Технические факторы

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

  • предотвращение попыток внешнего сетевого доступа к серверу/устройству посредством telnet;
  • уверенность в том, что диалог регистрации, в котором передаются имя и пароль, не проходит открытым текстом по любому из звеньев сети.
  • Безопасная программная оболочка [SSH (Secure Shell)] являет собой более безопасную альтернативу telnet. SSH использует шифрование для регистрационных имени и пароля в процессе аутентификации. Большинство платформ маршрутизаторов Cisco поддерживают SSH первой версии, и мы настоятельно рекомендуем использовать для административного доступа к маршрутизаторам SSH вместо telnet.

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

    Применение обновлений, связанных с уязвимостями в безопасности

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

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

    Уязвимости в программном обеспечении, как правило, разделяются на три категории:

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

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

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

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

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

    http://www.cert.org

    Ресурсы, требуемые для выполнения исправлений (патчей) на серверах, будут широко различаться в зависимости от размеров вашей организации, количества различных операционных систем, количества приложений. Ресурсы, требуемые для выполнения патчей на рабочих станциях, также будут сильно различаться в зависимости от того, применяется или нет центральный механизм распространения программного обеспечения, и ряда других факторов. Обновления, патчи и другие "заплатки" могут загружаться на рабочие станции с использованием традиционных инструментов распространения ПО либо с использованием специализированных продуктов патч-менеджмента, таких, как Patchlink Update (www.patchlink.com), BigFix Patch Manager (www.bigfix.com), Security Update Manager (www.configuresoft.com), LANguard Network (www.gfi.com) и др.

    Запись действий для аудита и отчетности

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

    Далее перечислены функции, которые должны быть предоставлены.

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

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

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

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

    3.3 Краткие выводы

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

    Обеспечение гарантированной конфиденциальности данных

  • Шифруйте конфиденциальную и чувствительную информацию, где это требуется.
  • Способствуйте как физическому, так и логическому разделению сервера и сети при любой возможности.
  • Уменьшайте подверженность сетевому сниффингу.
  • Идентифицируйте соответствующие стороны, наделенные полномочиями доступа и обновления контента.
  • Обеспечьте защиту внутренних приложений и Web-серверов путем использования уровней сетевых прокси.
  • Защитите ресурсы организации с помощью мониторинга, использующего системы обнаружения вторжений (IDS).
  • Обеспечение гарантированной целостности данных

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

    Страницы:

    Под термином "инфраструктура" будем понимать:

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

    3.1 Потребность в защищенных инфраструктурах

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

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

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

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

    3.2 Требования к обеспечению безопасности инфраструктуры

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

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

    Требования к обеспечению безопасности бизнеса, как правило, включают:

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

    3.2.1 Обеспечение конфиденциальности данных

    В этом разделе опишем следующие методы обеспечения конфиденциальности данных:

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

    Во-первых, мы предполагаем, что вы имеете общее представление о криптографии и моделях шифрования с использованием симметричных и несимметричных ключей (общие секретные ключи и открытые/секретные ключи). Далее мы поведем разговор на высоком уровне, упомянув лишь о том, что зашифрованные данные не могут быть расшифрованы человеком или системой, которые не владеют корректным ключом для расшифровки. Обзор криптографии представлен в разделе 1.4, "Криптографические техники", а подробное рассмотрение криптографии с использованием асимметричного ключа можно найти в лекции 6, "Инфраструктуры открытых ключей".

    Во-вторых, позвольте нам обратить внимание на то, что мы не говорим о необходимости шифрования всех данных повсеместно. Ранее в этом курсе мы обсуждали процесс классификации данных. Дополнительным аспектом классификации данных является определение требуемого уровня защиты в зависимости от того, где находятся данные в любой заданный промежуток времени. К примеру, ваша политика безопасности может требовать, чтобы почтовый файл Notes хранился в зашифрованном виде на внутреннем сервере Domino. Вспомним, что, когда вы шифруете базу данных Domino на сервере Domino, она шифруется с использованием открытого ключа сервера. Но если реплика почтового файла сохранена на лэптопе, который потенциально может быть вынесен из учреждения, ваша политика безопасности может требовать и шифрования локальной реплики. Шифрование локальной реплики клиента Notes шифрует почтовую базу данных с использованием открытого ключа пользователя. Но помните о том, что процесс репликации Notes Domino включает передачу данных с применением опр еделенного вида связи по сети. Репликация в Notes (инициируемая сервером Domino или клиентом Notes) представит данные на сетевой порт в незашифрованном виде, так как шифрование базы данных, по существу, становится прозрачным для задачи репликации сервера или клиента. Помним и о том, что задача репликации запускается под определенным идентификатором (ID), что шифрует базу данных. По умолчанию шифрование порта на сервере Domino не разрешено, и, таким образом, вы остановитесь на сценарии, описанном на рис. 3.1.

    (рис 3.1) Незашифрованная репликация

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

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

    Совет! Защита, предоставляемая шифрованием баз данных на сервере Domino, зависит от того, насколько безопасным является доступ как к зашифрованному файлу базы данных, так и к ID-файлу сервера на уровне ОС сервера. Так как пароли в ID серверов Domino используются редко (для разрешения автоматических рестартов), скомпрометированный ID-файл сервера может быть использован для открытия копии зашифрованной базы данных, скопированной с сервера. Поэтому убедитесь, что разрешение на доступ к ID-файлу сервера дано только для учетной записи администратора на Windows-серверах или только для учетных записей Notes и root для ОС Unix.

    Физическое и логическое разделение серверов и сетей

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

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

    К одним из наиболее важных разделений серверов, или, если быть более точным, служб, относятся службы доменных имен DNS (Domain Name Services). DNS используется для установления соответствия между IP-адресами и именами хостов и обратного поиска IP-адресов по именам хостов. Большинство организаций имеют как внешние IP-адреса, так и используемые внутри организаций частные IP-адреса. Примите во внимание, что существуют серверы, которые вам необходимо сделать доступными и "видимыми" для внешних пользователей. Этим внешним пользователям необходимо разрешить доступ к вашим открытым именам хостов и записям почтового обмена (MX) на ваших свободно доступных серверах. Также помните, что у вас есть совокупность внутренних пользователей, имеющих два требования: способность разрешать внешним серверам IP-адреса и способность разрешать всем внутренним серверам их IP-адреса. Мы описали концепцию "раздельной DNS" в лекции 4, "Компоненты и уровни безопасности".

    Разделение систем применяется для ограничения доступа только в тех областях, в которых пользователь нуждается в своих бизнес-функциях или транзакциях. Это относится как к конечным пользователям, так и к администраторам. Как было упомянуто в этом курсе ранее, одна из наибольших угроз исходит от вашего внутреннего персонала; она больше, чем угроза от злонамеренных, умышленных или случайных действий. Нашей основной целью является не допустить действий отдельного индивидуума по внесению единой точки отказа. У многих ИT-профессионалов есть ужасные истории о происшествиях, причиной которых стал действующий из самых лучших побуждений администратор, имеющий возможно слишком много полномочий от единой точки входа. Таким образом, в некоторых случаях нам необходимо разрабатывать среду для защиты нас от самих себя! Если посмотреть на это с другой стороны, то накладные расходы по уменьшению воздействия административных ошибок являются нашими собственными проблемами.

    Повышение защищенности от сетевого сниффинга

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

    Подверженность этому явлению можно значительно снизить путем использования двух принципов:

  • Уменьшение видимости пакетов путем ограничения физических путей прохождения TCP/IP-трафика. К примеру, Ethernet-коммутатор не производит широковещательной рассылки всех пакетов на все порты, как это делает простой концентратор. Установка адресов хостов и фильтров портов на маршрутизаторах может ограничить возможность прослушивания сети за пределами локального сегмента ЛВС. Пакеты TCP/IP должны быть ограничены минимальным количеством сетевых сегментов, требуемых для доставки из точки А в точку Б. Еще одной технологией, становящейся широкодоступной в сетевых коммутаторах для обеспечения гранулированной сегментации сети с использованием меньшего количества оборудования, является применение возможностей виртуальной ЛВС (VLAN).
  • Шифрование пакетов в сетях, в которых допускается наличие неразрешенных устройств или сниффинговой активности. Вместе или по отдельности могут использоваться шифрование на уровне приложений или шифрование на уровне сессии. Как правило, шифрование на уровне сессии, такое, как SSL, должно использоваться для защиты чувствительных данных в тех случаях, когда приложение не гарантирует, что на момент покидания сервера приложений данные зашифрованы (сервер отображает данные в незашифрованном виде, даже несмотря на то что физически он хранит данные в шифрованном виде). Шифрование на уровне сессии является также подходящим для защиты ID и паролей пользователей, передаваемых во время диалога аутентификации.
  • С распространением беспроводных Ethernet-сетей стандарта 802.11 сетевой сниффинг больше не требует наличия физического сетевого порта. В настоящее время устройства, которые можно повесить на цепочку с ключами, способны определять "хотспоты", доступно множество чувствительных антенн и специального программного обеспечения. Визит на сайт netstumbler.com познакомит со ссылками, описывающими притязания на "Wi-Fi-серфинг из проезжающего мимо автомобиля", новыми инструментами сканирования, здесь представлено и множество другой информации, заставляющей отвечающего за безопасность человека дважды подумать о реализации беспроводной сети. В то время как сильно ожидавшийся стандарт беспроводной безопасности IEEE 802.11i в результате опубликован в 2004 г., в настоящее время безопасность в беспроводных ЛВС в большинстве случаев отсутствует. Как было показано, шифрование WEP (Wired Equivalent Privacy) довольно легко взламываемо, а его преемник, шифрование WPA (Wi-Fi Protected Access), является неадекватным в ряде случаев выполнения (обычно из-за плохо сконфигурированных систем). Что еще более удивительно, так это то, что даже беспроводные изделия, которые используют WEP, с его слабым и устаревшим шифрованием, иногда запрещаются (или никогда не разрешаются) администраторами, которым надоели их пользователи с вопросами о совместимости карт беспроводного доступа. Как и со множеством других проблем в сети, при обеспечении безопасности часто идут на компромисс для создания удобства в использовании.

    Идентификация абонентов и разрешение доступа

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

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

  • Каким образом можно подтверждать личность людей?
  • Если вы собираете и храните эту информацию о людях, как сохранить ее приватность?
  • Если вы собираете информацию о людях, как эта информация используется?
  • Механизмы целостности и конфиденциальности информации, или и того и другого вместе, должны применяться для защиты передаваемых посредством Интернета важных данных, включая информацию, которая идентифицирует людей, информацию об их кредитных картах, информацию о заказах и договорах и т. д. Поэтому мы рекомендуем трактовать всю информацию о личностях и удостоверении личностей пользователей как конфиденциальную информацию. Эта информация включает в себя как ваших внутренних пользователей, так и внешних. Законы о защите персональной информации различны в разных странах и зачастую диктуют особые требования для обеспечения хранения и защиты информации о служащих, подрядчиках, бизнес-партнерах, заказчиках и поставщиках. Вы обязаны обеспечить соответствие всем применяемым законам о защите персональной информации (правовые консультации выходят за рамки этого курса).

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

  • Отслеживаемость. Возможность отслеживания в системе всей активности человека, инициировавшего действие. Это имеет профилактическое значение, гарантирующее, что пользователи знают о невозможности анонимной активности (значительно уменьшает соблазн просмотреть или злоупотребить системой), и позволяющее восстановить все действия вплоть до инцидента с безопасностью.
  • Минимальные привилегии. Имеют целью обеспечить пользователя только тем набором привилегий, которые необходимы для выполнения каждым из пользователей санкционированных обязанностей. Это помогает сократить нередко встречающуюся цепочку: любопытство, просмотр, обнаружение, притягательность, соблазн и в конце концов неправомерное действие. Основной подход уменьшения привилегий – "необходимо знать".
  • Разделение обязанностей. Целью является обеспечение того, чтобы исполнял, одобрял и рассчитывал какое-либо критическое для безопасности действие не единственный человек. Основной целью является не позволить единственному индивидууму выполнить действия по внесению единой точки отказа.
  • Использование прокси-систем

    Использование прокси-систем может обеспечить защиту серверных приложений и Web-серверов. Считайте, что прокси является разновидностью брандмауэра, которая работает за пределами уровня протокола TCP/IP. На них иногда ссылаются как на "шлюзы приложений", хотя этот термин в последнее время используется менее часто. Протоколы приложений обычно поддерживают HTTP, FTP и telnet, но виртуально могут включать любой протокол TCP/IP. Прокси-системы для конечного пользователя обычно прозрачны. Мы исследуем характеристики брандмауэров и прокси, а также выполняемые прокси специфичные функции в последующих лекциях. На этой стадии в качестве ключевого момента вы должны понимать, что прокси являются неотъемлемым компонентом передового опыта обеспечения безопасности.

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

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

    Реализация обнаружения вторжения

    Вторжение подразумевает ситуации, когда некая сторона (или стороны) получает доступ, пытается получить доступ или пытается разрушить компьютерный ресурс, который ей не разрешено использовать. Вовлеченной стороной может выступать человек, программа либо их комбинация. Компьютерным ресурсом, выбранным в качестве цели, может быть сервер, приложение, база данных, сетевая ссылка и т. д. Системы обнаружения вторжения (IDS) являются важной мерой обеспечения безопасности, потому что они могут предупредить вас об атаке еще в процессе ее выполнения (успешная или нет). Раннее обнаружение является важным моментом в обеспечении безопасности, поскольку попытки взломов или атак, как правило, начинаются с "исследования" цели для нахождения возможных уязвимостей или перспектив доступа. Это исследование обычно выполняется посредством сканирования TCP/IP портов для последующей их эксплуатации с целью определения возможности атаки. В идеальном случае ваши методы обнаружения вторжений позволят обнаружить подозрительную активность на ранних фазах попыток атаки.

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

    Существует вопрос, который мы слышим от некоторых клиентов: "Подразумевает ли обнаружение сетевого вторжения перехват сообщений?" Это поднимает интересные этические вопросы, однако правовые понятия относительно определения перехвата сообщений широко расходятся в разных странах. В большинстве стран разрешено производить мониторинг активности на вашем собственном оборудовании, хотя могут быть установлены ограничения на то, какой контент может, а какой не может подвергаться мониторингу. Возможны также различия в зависимости от того, проводится ли мониторинг для внутренних пользователей (служащих) либо для внешних клиентов. В США действует легальное преимущество, позволяющее нанимателю отслеживать использование собственного оборудования компании ее служащими. Однако мы рекомендуем, чтобы весь внутренний мониторинг активности служащих был четко разъяснен либо в трудовой политике, либо в политике безопасности (либо в обеих).

    Существует четыре основные категории систем обнаружения вторжения (IDS): сетевые (NIDS), системы проверки целостности хоста, системы мониторинга активности и сканеры контента. Последние не всегда рассматриваются как IDS, но большинство людей согласится, что e-mail-вирус является разновидностью атаки, поэтому и сканер-вирусов может рассматриваться как специализированный тип IDS. Мы рассмотрим все эти различные типы IDS в разделе 4.1.5, "Системы обнаружения вторжения".

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

    Обеспечение целостности данных

    В этом разделе мы опишем следующие методы обеспечения целостности данных:

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

    "Целостность данных" в простейшем смысле означает, что данные не были изменены. В сетевом контексте существует две содержащиеся в пакете части: заголовок и полезная нагрузка данных. Предотвращению или обнаружению изменений в информации заголовка способствует управление доступом и аутентификацией с точки зрения сетевого (IP) адреса. Аутентификация (в этом контексте) означает, что мы можем идентифицировать адреса источника и получателя. С сетевой точки зрения можно применить управление сетевым доступом, основанное на IP-адресах и транспортных протоколах. Но сетевые адреса источника и получателя в пакете обычно представляются в незашифрованном виде; таким образом, мы нуждаемся в средствах предотвращения или обнаружения несанкционированного изменения данных либо их фальсификации.

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

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

    Управление доступом для безопасного администрирования

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

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

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

  • определение стандартных систем управления доступом;
  • определение административных полномочий безопасности, связанных с этими системами управления доступом;
  • обязательные стандарты управления и реализации по умолчанию для этих систем управления доступом.
  • Обеспечение доступности

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

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

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

    Управление административной деятельностью по сопровождению

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

  • Четко ли определены допустимые пределы полномочий и приемлемость их использования?
  • Очевидны ли процессы управления назначением полномочий и своевременным удалением полномочий при окончании индивидуальной необходимости ведения бизнеса?
  • Имеет ли персонал, в обязанности которого входит эксплуатация и поддержка операционной системы, заданные их индивидуальным пользовательским ID системные полномочия? Если нет, может ли вся их деятельность отслеживаться точно индивидуально с абсолютной достоверностью?
  • Имеет ли персонал, в обязанности которого входит администрирование безопасности, заданные их индивидуальным пользовательским ID полномочия администрирования безопасности?
  • Может ли запуск служебных механизмов и агентов (служб, "демонов", заданий по расписанию), являющихся частью операционной системы, задаваться в отделе эксплуатации и поддержки системы способом, отличным от индивидуального?
  • Имеет ли каждый, кто способен начать работу или модифицировать служебные механизмы или агенты, действительную необходимость в этом для ведения бизнеса?
  • Могут ли члены групп с административными полномочиями быть индивидуально идентифицируемы и управляемы?
  • Как часто будет пересматриваться членство в группе для обеспечения гарантии того, что полномочия доступа удалены своевременно по окончании индивидуальной необходимости ведения бизнеса?
  • Деятельность, выполняемая в процессе использования системных полномочий или полномочий администрирования безопасности, должна быть особым образом санкционирована менеджментом путем внесения изменений в процесс управления либо должна быть совместимой с индивидуальным видом занятости персонала. Менеджмент организации должен убедиться, что имеющие полномочия люди осведомлены об этом требовании. Одной из наиболее важных процедур, которые вы должны определить в политике безопасности, является удаление административного доступа для тех людей, обязанности которых по работе закончились или изменились.

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

    Технические факторы

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

  • предотвращение попыток внешнего сетевого доступа к серверу/устройству посредством telnet;
  • уверенность в том, что диалог регистрации, в котором передаются имя и пароль, не проходит открытым текстом по любому из звеньев сети.
  • Безопасная программная оболочка [SSH (Secure Shell)] являет собой более безопасную альтернативу telnet. SSH использует шифрование для регистрационных имени и пароля в процессе аутентификации. Большинство платформ маршрутизаторов Cisco поддерживают SSH первой версии, и мы настоятельно рекомендуем использовать для административного доступа к маршрутизаторам SSH вместо telnet.

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

    Применение обновлений, связанных с уязвимостями в безопасности

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

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

    Уязвимости в программном обеспечении, как правило, разделяются на три категории:

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

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

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

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

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

    http://www.cert.org

    Ресурсы, требуемые для выполнения исправлений (патчей) на серверах, будут широко различаться в зависимости от размеров вашей организации, количества различных операционных систем, количества приложений. Ресурсы, требуемые для выполнения патчей на рабочих станциях, также будут сильно различаться в зависимости от того, применяется или нет центральный механизм распространения программного обеспечения, и ряда других факторов. Обновления, патчи и другие "заплатки" могут загружаться на рабочие станции с использованием традиционных инструментов распространения ПО либо с использованием специализированных продуктов патч-менеджмента, таких, как Patchlink Update (www.patchlink.com), BigFix Patch Manager (www.bigfix.com), Security Update Manager (www.configuresoft.com), LANguard Network (www.gfi.com) и др.

    Запись действий для аудита и отчетности

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

    Далее перечислены функции, которые должны быть предоставлены.

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

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

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

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

    3.3 Краткие выводы

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

    Обеспечение гарантированной конфиденциальности данных

  • Шифруйте конфиденциальную и чувствительную информацию, где это требуется.
  • Способствуйте как физическому, так и логическому разделению сервера и сети при любой возможности.
  • Уменьшайте подверженность сетевому сниффингу.
  • Идентифицируйте соответствующие стороны, наделенные полномочиями доступа и обновления контента.
  • Обеспечьте защиту внутренних приложений и Web-серверов путем использования уровней сетевых прокси.
  • Защитите ресурсы организации с помощью мониторинга, использующего системы обнаружения вторжений (IDS).
  • Обеспечение гарантированной целостности данных

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

    Вернуться к учебному плану