Rambler's Top100
Статьи ИКС № 7-8 2008
Владимир ИВАНОВ  28 июля 2008

Как хранить ценности

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

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

 

Центр требует централизации

 

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

 

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

 

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

 

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

 

Защитная инфраструктура сети

 

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

 

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

 

Эшелонированная сетевая оборона

 

Методически принято различать ЦОДы, обслуживающие внутренних пользователей (через корпоративную сеть) и внешних (через публичные сети), но с точки зрения защиты их проблемы и решения весьма сходны. При этом во «внутреннем» ЦОДе вероятность атаки на внутренние приложения ниже, чем во «внешнем», а возможный ущерб больше.

 

В корпоративных вебприложениях, построенных по принципу трехзвенной архитектуры (рис. 2), с пользователями, по идее, должны работать только серверы первого уровня – web frontend. На практике, однако, потребитель передает данные приложению, установленному на сервере второго уровня, и при недостаточно качественной фильтрации эти данные напрямую попадают в СУБД.

 

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

 

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

 

В современных ИС серверный и пользовательский трафик может фильтроваться не только на межсетевых экранах, но и средствами коммутаторов, обеспечивающих поддержку списков доступа на портах или VLAN. В идеале фильтр нужно устанавливать максимально близко к источнику трафика, чтобы те пакеты, которые все равно будут отброшены на пути к получателю, не занимали полосу пропускания и ресурсы сетевого оборудования. Это означает: трафик, транспортируемый к отвечающим пользователям серверам, следует фильтровать на границе дата-центра, а трафик между серверами ЦОДа – на порту, к которому подключен серверисточник. Фильтрация серверного трафика должна быть более жесткой, что вместе с ограниченностью числа протоколов внутри серверной фермы позволит сохранять строгий контроль над ним и наиболее полно использовать системы обнаружения и предотвращения вторжений (IDS/IPS). Разумеется, производительность этих систем необходимо подбирать с учетом предварительных оценок объемов трафика между приложениями.

 

Наконец, если сложность протокола не позволяет контролировать легитимность информационного обмена между клиентом и сервером, для обеспечения безопасности можно применять фильтрующие проксисерверы прикладного уровня. Примером сложных, многоуровневых протоколов служит SOAP (Simple Object Access Protocol – простой протокол доступа к объектам). Согласно SOAP общение между сервером (или вебсервисом) и клиентом происходит с помощью сообщений на основе XML (расширяемого языка разметки). В качестве транспорта для XMLсообщений обычно используется протокол HTTP или HTTPS.

 

Таким образом, для оценки корректности SOAPвзаимодействия контролирующая система должна:

 

- проанализировать IPпакеты и TCPсегменты, а если в качестве транспорта применяется протокол HTTPS, то выполнить терминирование SSL;

 

- собрать в памяти полный HTTPзапрос или ответ и проанализировать его на соответствие спецификации HTTP;

 

- проанализировать XMLдокумент на соответствие XMLсхеме;

 

- проанализировать SOAPсообщение на соответствие спецификации WSDL (языка описания вебсервисов).

 

Такой алгоритм оценки делает потоковый (попакетный) анализ, при котором используются некоторые сетевые IDS/IPSсистемы, затрудненным или нерациональным. Но контроль можно реализовать и на прикладном уровне, например с помощью промежуточного вебсервера, который проверяет полностью принятый запрос и, при положительных результатах проверки, передает его «настоящему» вебприложению. Выделенное устройство контроля над XMLсообщениями не занимается терминированием SSLсоединений или предотвращением вторжений на сетевом уровне, и такое разграничение ролей позволяет добиться высокой производительности.

 

Идеологически близкая задача – защита вебприложений, напрямую «общающихся» с клиентом. По данным OWASP (Open Web Application Security Project), наиболее распространенные атаки на вебприложения – это межсайтовый скриптинг, внедрение кода (например, SQLинъекция) и неконтролируемое выполнение файлов. Для защиты от них можно использовать комплексы WAF (web application firewall), которые контролируют параметры, передаваемые пользователем с помощью запросов HTTP GET и POST. Параметры запросов, HTTP cookies и URL проверяются на предмет легитимности, отсутствия признаков атак (например, наличия в передаваемом параметре фрагмента SQLзапроса или сценария JavaScript), после чего запрос отправляется «настоящему» вебсерверу.

 

Средства индивидуальной защиты

 

Добиться полной защищенности приложений только сетевыми средствами сложно. Необходимо принимать дополнительные меры на уровне серверной операционной системы и установленных на сервере приложений.

 

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

 

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

 

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

 

Повысить уровень защищенности от неизвестных уязвимостей таким способом нельзя, но это можно сделать с помощью программной системы класса HIPS (host intrusion prevention system). Она контролирует системные вызовы, выполняемые приложением, и оценивает информационные потоки между приложениями. В системе HIPS всегда присутствует набор правил, описывающих нормальное поведение корпоративного приложения. Отклонения от этих правил считаются нарушением защиты. Даже если зловредный код, который привел к изменению работы приложения, неизвестен традиционному антивирусу, система его «вычислит». Набор правилполитик, описывающих нормальное функционирование приложений, поставляется производителем такой системы и может быть дополнен специалистами службы ИБ.

 

Когда сервер управления HIPS получает определенное число сходных уведомлений о подозрительной активности, он расценивает это как атаку неизвестного зловредного кода. Тогда сервер создает сигнатуру, позволяющую IPS предотвратить атаку на уровне периметра сети или ее сегмента.

 

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

 

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

 

Наиболее остро стоит проблема шифрования резервных копий, которые в рамках стратегии восстановления системы после катастроф должны быть вынесены с территории организации. Если ленточная библиотека подключена к сети хранения, то шифруется содержимое SCSI-команд в Fibre Channelтрафике, предназначенном для записи на ленту. Но разбор FCфреймов и шифрование данных внутри команды требуют значительных вычислительных ресурсов. Эта задача обычно выполняется специализированным устройством – кроме тех случаев, когда резервная копия имеет относительно небольшой размер или время, выделенное на резервное копирование, позволяет выполнить шифрование программным способом.

 

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


 . . . 

Защитить дата-центр только сетевым экраном не удастся. Современные угрозы намного сложнее тех, которые подвластны МСЭ. Снизить риски позволяют построение глубоко эшелонированной защиты, правильная организация процессов оперативного управления работой ЦОДа и обеспечение тесного взаимодействия сотрудников.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!
Поделиться: