Сбой сервера: риски, последствия, контрмеры

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

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

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

Внутренние угрозы:

• Пожар в компьютерном центре

• отключение электроэнергии в компьютерном центре

• Отказ оборудования (сбой жесткого диска, перегрузка, перегрев)

• Ошибка программного обеспечения (сбой базы данных)

• Сетевые проблемы

• Человеческая ошибка

Внешние угрозы:

• проникновение (атака «человек посередине», фишинг, социальная инженерия)

• Саботаж (атаки на системы SCADA)

• Вирусы, трояны и черви

• Распределенная атака типа «отказ в обслуживании» (DDoS)

• Кража оборудования

• Стихийные бедствия (землетрясения, молнии, наводнения)

• Аварии (крушение самолета)

• Атаки

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

Финансовые затраты, связанные с отказом сервера, зависят от нескольких факторов, а также от того, какой именно сервер вышел из строя: сервер электронной почты, веб-сервер, сервер аналитики? Время простоя сервера также играет свою роль. Если это было всего несколько минут, возможно, не стоит подсчитывать убытки, но при более длительном времени, возможно, имеет смысл их подсчитать. Если сервер использовался сотрудниками, необходимо подсчитать, сколько им было заплачено за то, что они технически ничего не делали, что, очевидно, зависит от их зарплаты. Если виновником является сервер электронной коммерции, имеет смысл подсчитать, сколько заказов не удалось разместить за время простоя сервера. Для этого посмотрите на период времени, например, среда 5-7 вечера, и сравните его с тем, сколько заказов вы обычно получаете в это время. Если не работал сервер электронной почты, стоимость зависит от того, насколько ваша компания зависит от трафика электронной почты. Клиенты могут быть раздражены тем, что не получили быстрых ответов на свои запросы, если они привыкли к этому. Этого может быть достаточно, чтобы некоторые клиенты перестали пользоваться вашими услугами или покупать вашу продукцию.

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

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

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

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

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

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

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

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

Компании среднего размера особенно недооценивают влияние, которое оказывают перебои в работе ИТ на бизнес-операции. Причиной этого является высокая надежность стандартных компонентов, которые сегодня используются в корпоративных ИТ. Их доступность обычно оценивается в 99,9%. Эта цифра может показаться высокой, но если система работает 24 часа в сутки в течение года, то максимальное время простоя может составить почти 9 часов. Если это произойдет именно в период пиковых продаж, то относительно короткий отказ сервера может дорого обойтись компании. Высокодоступные ИТ-системы с готовностью 99,99% являются стандартом, когда речь идет о поставке критически важных данных и приложений. В этом случае гарантируется максимальное время простоя в 52 минуты в год. Некоторые ИТ-эксперты даже считают, что доступность 99,999% возможна, что означает не более 5 минут простоя в год.

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

Высокая доступность (сокращенно HA) означает доступность ресурсов компьютерной системы при отказе компонентов системы».

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

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

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

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

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

Системы обнаружения вторжений (IDS) обеспечивают автоматизированный мониторинг серверов и сетей, оповещая пользователей, как только обнаруживаются попытки ручного взлома или автоматические атаки вредоносного программного обеспечения: этот процесс основан на распознавании образов и статистическом анализе. Если используются системы предотвращения вторжений (IPS), то после оповещения принимаются автоматические контрмеры. Обычно они подключаются к брандмауэру, чтобы отбрасывать пакеты данных или прерывать подозрительные соединения.

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

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

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

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

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

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

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

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

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

Методологическая реализация BIA и анализа рисков в рамках BCM является предметом различных стандартов и рамок. В качестве подробного руководства рекомендуется стандарт BSI Standard 100-4.

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

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

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

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

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

Уже разработанные стратегии продолжения работы определены в концепции аварийной безопасности, которая содержит конкретные инструкции для всех соответствующих аварийных сценариев.