Совет №28
Предотвращение катастрофических сбоев в хранилищах данных

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Ральф Кимбалл (все статьи)
Перевод на русский язык: Юрий Кузьменков
Оригинальный документ располагается здесь.

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

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

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

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

Катастрофические события

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

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

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

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

Противостояние катастрофическим последствиям

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

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

Расширение сетей хранения данных (СХД) – СХД это обычно комбинация высокопроизводительных дисковых накопителей и устройств резервного копирования, соединенных посредствам технологии высокоскоростных оптоволоконных каналов. Выгодно отличаясь от файл-сервера, кластерные дисковые накопители представляют модульный интерфейс для компьютеров, подключенных к СХД, что делает накопители доступными для подключения к системной плате каждого компьютера. СХД предоставляет как минимум три огромные возможности для больших хранилищ данных. Одна физическая СХД может быть протянута на 10 километров. Это значит что дисковые накопители, архивные системы и устройства резервирования могут быть расположены в разных зданиях на достаточно большом расстоянии. Во-вторых, резервирование и копирование может быть выполнено на скоростях диск-диск на всей СХД. И в третьих, когда все диски СХД будут объединенным ресурсом, различные приложения могут быть сконфигурированы для параллельного доступа к данным. Что наиболее существенно для «read-only» сред.

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

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