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

Мы привыкли считать безопасными наши большие, важные, заметные здания и компьютеры — именно потому, что они большие, важные и заметные. Но все это оказалось мифом. Случись что, в первую очередь пострадают именно такие здания и компьютеры.

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

Можно ли улучшить защиту информационных хранилищ? Существуют ли информационные хранилища, которым исходно присущи безопасность и меньшая уязвимость к катастрофам?

Я уже давно подумывал о написании статьи на эту тему, и в какой-то момент невозможность далее ее откладывать стала ясна. Ниже я расскажу о некоторых важных угрозах, могущих вывести системы из строя на довольно продолжительное время, и возможных мероприятиях по их предотвращению.

Катастрофические аварии

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

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

Приемы кибервойны. Уже давно не новость, что хакеры способны взламывать защиту систем, вызывая в них хаос и нанося значительный ущерб. События 11 сентября заставили нас избавиться от бытующих наивных заблуждений, что такие атаки безопасны или «конструктивны», так как вскрывают недостатки защиты. Среди наших врагов есть квалифицированные пользователи компьютеров, которые сегодня активно пытаются получить доступ к конфиденциальной информации, изменить ее и нарушить работу информационных систем. Вспомните, сколько раз за последние месяцы мы наблюдали атаки типа «отказ в обслуживании» (denial-of-service, DOS) с применением программных «червей», которые захватывали серверы и персональные компьютеры. Я ни за что не поверю, что это работа «деток», балующихся написанием сценариев; подозреваю, что некоторые из них служат разминкой для информационных террористов.

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

Противодействие авариям

Распределенная архитектура. Единственный наиболее эффективный и действенный способ избежать катастрофических последствий аварий информационного хранилища — в высокой степени распределенная его архитектура. Информационное хранилище предприятия должно состоять из множества компьютеров, операционных систем, технологий баз данных, аналитических приложений, коммуникационных каналов, информационных узлов, персонала и онлайновых копий данных. Физические компьютеры должны быть географически разнесены — лучше всего расположить их в разных частях страны или даже по всему миру. Распределение оборудования между многими независимыми узлами существенно снижает уязвимость информационного хранилища к саботажу и сбоям в критических точках. Реализация информационного хранилища одновременно под несколькими операционными системами (например, Linux, UNIX и Windows NT) значительно снижает его уязвимость к «червям», атакам с применением социальной инженерии и нападениям квалифицированных хакеров, использующих слабые места определенных систем.

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

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

Расширенные сети хранения (storage area network, SAN). SAN обычно представляет собой кластер высокопроизводительных дисководов и устройств резервного копирования, объединенных посредством высокоскоростных оптоволоконных каналов. В отличие от файлового сервера SAN-кластер предоставляет интерфейс на уровне блоков, а для клиентов хранилище кажется подключенным непосредственно к компьютеру.

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

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

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

Жестко ограниченный механизм аутентификации и управления доступом с поддержкой ролей. Риск для информационного хранилища намного возрастает при наличии слишком большого числа способов доступа к нему и в отсутствие централизованной защиты. Обратите внимание, я сказал не «локализованной в центре», а «централизованной», т. е. централизованно управляемой системы безопасности. Наиболее подходящее решение заключается в установке LDAP-сервера (Lightweight Directory Access Protocol), управляющего любым доступом к информационному хранилищу извне. Такой сервер обеспечивает всем пользователям единообразную процедуру аутентификации, независимо от того, откуда они подключаются, — из местной сети или из удаленного офиса через Интернет. После успешной процедуры аутентификации сервер каталогов приписывает пользователю поименованную роль. В дальнейшем сервер приложений на каждом шаге просмотра данных принимает решение о том, дает ли указанная для пользователя роль право на доступ к той или иной информации. Преимущества архитектуры жестко ограниченного централизованного управления становятся очевидными по мере роста информационных хранилищ, которые могут насчитывать тысячи пользователей и сотни различных ролей.

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

Я много писал на рассмотренные выше темы. Более подробно о построении распределенных архитектур, шлюзах с фильтрацией пакетов и безопасности на основе ролей я рассказал в книге Warehouse Lifecycle Toolkit (Wiley, 1998). Об использовании сетей SAN в информационных хранилищах вы можете прочитать в моей статье «Adjust Your Thinking for SANs» (8 марта 2001) в Intelligent Enterprise (ее можно найти в архиве на сайте http://www.ralphkimball.com или http://www.IntelligentEnterprise.com).

Ральф Кимбалл (Ralph Kimball) — один из авторов изобретения Star Workstation в компании Xerox и учредитель компании Red Brick Systems. Автор трех бестселлеров о технологиях информационных хранилищ, в том числе The Data Webhouse Toolkit (Wiley, 2000). Преподает конструирование распределенных информационных хранилищ в университете Kimball University. Выполняет оценку проектов крупных информационных хранилищ. С ним можно связаться через Web-сайт http://www.rkimball.com.