Прикладная метеорология. Как обеспечить безопасность вашего охранного "облака"?

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

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

Впрочем, давайте сначала определимся с понятиями и категориями.

Не только кучевые и перистые

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

Институт NIST дает следующее определения первым двум слоям этой диаграммы.

Модель охвата (возможно, вы встретите перевод "модель размещения") характеризует базу пользователей, которым предоставляются ресурсы.

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

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

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

Модель обслуживания соотносится с уровнем или типом сервисов, предоставляемых облачной системой.

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

В прошлом году альянс производителей полупроводниковой техники GSA присудил награду GSA Award двенадцати разным компаниям, предоставляющим IaaS-услуги правительственным агентствам США в рамках соглашения о пакетных госзакупках (BPA). Можно сказать, что инфраструктура как услуга подразумевает передачу на аутсорсинг физической и сетевой составляющей вычислительных систем.

Платформа как услуга обычно описывается как предоставление одного или более архитектурных слоев вместе с нижележащей инфраструктурой. Эти слои -- программная среда, чаще всего в виде API. В ней содержится каркас из многих функций, но высокоуровневое программирование бизнес-логики приложения по-прежнему остается заботой конечного пользователя. Примеры таких сервисов -- Force.com или движок Google App. При подписке вы не получаете работающее приложение; вы должны сами написать свою игру, социальную сеть или систему для физической безопасности.

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

С этим облаком вам по дороге

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

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

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

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

Выбор модели охвата остается открытым вопросом и решается для каждой компанией для себя самостоятельно. Выбор модели охвата сводится к дилемме: использовать ли серверы охранного провайдера или размещать веб-решение на собственной инфраструктуре?

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

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

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

Обеспечиваем безопасность охранного облака

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

Такие процедуры обязательны для государственных учреждений США. Аудит безопасности регламентирован Федеральным законом о защите информации (FISMA) и, что важнее, программой FedRAMP (Федеральной программой по управлению рисками и санкционированию доступа). С момента введения ее прямое назначение -- повышение безопасности облачных сервисов.

Кроме того, отраслевыми экспертами сформулировано множество рекомендаций по обеспечению безопасности облачных решений. Провайдерам охранных облачных сервисов стоит встроить эти формулировки в свои коммерческие предложения. Это не только повысит общий уровень отраслевого профессионализма, но и даст очки в конкурентной борьбе. Достойный источник информации по этой теме -- ресурс Cloud Security Alliance (существует российское отделение этого альянса -- RISSPA, и после регистрации вы сможете ознакомиться с большим объемом материала по защите систем виртуализации).

Итак, что делать? При выборе поставщика облачного сервиса постарайтесь узнать ответы на следующие вопросы:

1. Существует ли в компании последовательная политика безопасности, и если да, то насколько она строга?
2. Где находятся вычислительные мощности? Кому принадлежит аппаратное обеспечение? Какие в дата-центре внедрены системы физической безопасности? Ведутся ли журналы не только логического, но и физического доступа?
3. Проходят ли сотрудники компании проверку благонадежности?
4. Что входит в процедуру регулярного аудита безопасности сервиса? Как часто он проводится?
5. Какие у компании есть сертификаты по информационной безопасности?
6. Существует ли соглашение о качестве обслуживания (SLA)? Установлено ли в нем максимальное время неработоспособности сервиса (в часах в год)? Указаны ли предельные сроки решения разных типов проблем технической поддержкой?
7. Как часто производится резервное копирование базы данных?

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

cloudsecurityservice.secnews.ru 92.255.73.2

Это значит, что при попытке зайти браузером на интерфейс вашего охранного сервиса cloudsecurityservice.secnews.ru запрос будет перенаправлен на сервер с IP-адресом 92.255.73.2. Если вы внесете эту запись в ваш файл hosts, то при обращении к указанному доменному имени у вас откроется сайт журнала Security Focus. Но там могла быть подложная страница, внешне копирующая интерфейс вашей охранной системы. В привычном поле вы бы ввели пароль, и... можно не продолжать. Кстати, даже если вы ничего не ввели, то на подложный сервер были бы отосланы привязанные к доменному имени cookies. Страницы в социальных сетях "взламывают" именно так, хотя слово "взлом", тут, думается, не вполне применимо. Если агент конкурента нашел бумажку с паролем в мусорной корзине, вы же не назовете его "хакером"?

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

По материалам журнала Security Distribution & Marketing, США