Основная причина, по которой компании не решаются переходить на облачные решения, – это вопросы безопасности. Опасения относительно сохранности конфиденциальных данных, относящихся как к коммерческой тайне, так и к персональным данным клиентов, до сих пор остаются главным препятствием широкого внедрения облачных технологий. Между тем сами провайдеры уже давно уделяют первостепенное внимание безопасности, читая необходимым не только неформальное соответствие современным требованиям, но и получение формальных сертификатов соответствия, например, стандарту ISO/IEC 27001.
В чём же сегодня состоят основные угрозы безопасности облачных решений? Как нетрудно догадаться, часть из них типична для любых дата-центров, но есть и специфические риски, связанные непосредственно с облачными технологиями.
Прежде всего речь идёт об организации инфраструктуры и о возможности как физического, так и виртуального несанкционированного проникновения в систему. Поэтому чрезвычайно важно обеспечить многоуровневую защиту, в частности несколько периметров безопасности, самый слабый из которых, к примеру, доступен любому штатному персоналу объекта, а самый сильный может быть ограничен даже не просто машинным залом, а конкретным набором оборудования с защитой, преодолеть которую уполномочены только отдельные представители заказчика.
Виртуальная угроза связана с возможностью удалённого проникновения в «чужую» часть облака с использованием неправильно организованной инфраструктуры провайдера. Имеется в виду, например, эксплуатация известных уязвимостей в несвоевременно обновляемом системном ПО, использование backdoor («чёрных ходов») в приложениях, распределённых по разным серверам облака, проникновение с одних виртуальных машин на другие в инфраструктуре того же провайдера.
С этой проблемой непосредственно связаны и риски, связанные с пресловутым «человеческим фактором», то есть инсайдерские угрозы как от сотрудников оператора, так и от представителей самого заказчика, что тоже не редкость. И если в последнем случае проблема в кадровой политике заказчика, то в первом причина кроется в отсутствии должной организации работы персонала провайдера, который в силу служебных обязанностей способен получать расширенный доступ к информации клиентов.
Не стоит сбрасывать со счётов и случайные ошибки персонала, в результате которых снижается уровень безопасности системы и злоумышленники могут получить доступ к «облаку» и хранящимся в нём данным.
Наконец, угрозы, непосредственно относящиеся к облачным технологиям, связаны с их сетевой основой: поскольку облака по определению расположены в публичной части интернета, которая при наличии средств аутентификации должна быть доступна клиентам, они уязвимы и для сетевых атак. За последние годы одними из самых распространённых подобных атак стали DDoS, при которых страдает не только сама жертва, но и вся инфраструктура: мусорным трафиком забиваются сетевые каналы, а производительность оборудования максимально снижается из-за обработки мусорных запросов.
Поскольку в дата-центрах вместо независимых хостов широко используются виртуализованные, так как они обеспечивают высокую производительность работы с большими массивами данных, то с этим также связан целых ряд возможных уязвимостей. Дело в том, что приложения с разной степенью активности, расположенные на одном виртуальном хосте, способны чрезвычайно жёстко соперничать за вычислительные ресурсы, что заметно снижает производительность. Для предотвращения таких ситуаций создаются дополнительные экземпляры виртуальных машин, а увеличение числа компонентов само по себе снижает безопасность, поскольку появляется целый ряд новых объектов атак – от гипервизоров до виртуальных коммутаторов.
Результат – создание целого ряда специфических типов атак, направленных именно на виртуальную среду. В частности, злоумышленники могут перехватывать контроль над гипервизорами, что позволяет управлять виртуальными хостами, похищать сами виртуальные машины и монтировать их образы на других системах. Вирусы, запущенные в виртуальной машине, способны «перепрыгивать» из одной виртуальной машины в другую (VM Hopping) или даже «сбегать» за её пределы (VM Escape), внедряя и исполняя вредоносный код непосредственно на гипервизоре.
Экспертное мнение
Вячеслав Вовкогон, специалист по информационной безопасности DataLine
Каковы, по вашему мнению, самые главные риски для облачных систем? Связаны ли они с уязвимостями архитектуры, инсайдерскими угрозами и утечками или с проникновением извне и DDoS-атаками на облака?
Можно выделить как угрозы, присущие большинству облачных информационных систем, так и специфичные. Так, проблема уязвимости облачной архитектуры характерна для высокоуровневых моделей (PaaS, SaaS). Она особенно актуальна для организаций госсектора. Например, используемое ПО должно обязательно иметь сертификаты ФСТЭК по отсутствию НДВ (недокументированные возможности).
Для интернет-магазинов с внешней системой приёма платежей угрозы утечек и инсайда не столь опасны, но в то же время DDoS-атаки сайта длительностью в три дня могут привести к финансовым потерям, грозящим магазину банкротством. При тех же условиях банк, хранящий резервные копии своих информационных систем в облаке, легко переживёт недельную DDoS-атаку, но угроза утечки или инсайда будет для банка весьма критична.
Постоянно модифицирующиеся многоуровневые угрозы заставляют отвергать стандартные способы защиты, выстраивая из знакомых элементов сложные системы противодействия злоумышленникам. К таким традиционным элементам прежде всего относятся брандмауэры, антивирусное программное обеспечение, системы предотвращения утечек информации (DLP) и защищённые хранилища. При этом для каждого инструмента существуют свои нюансы применительно именно к облачным системам.
Так, межсетевые экраны должны включать в себя средства предотвращения вторжений во внутренние сети извне, и такие инструменты включаются во все системы нового поколения. Антивирусы должны работать только вне виртуальных машин, размещаясь отдельно в качестве шлюзов или независимых систем сканирования данных – в целях предотвращения перехвата управления и блокировки.
Системы защиты от утечек, как и программы мониторинга потоков передаваемой информации, типичны для корпоративных сетей, когда они устанавливаются на клиентских ПК и на шлюзе для выхода во внешние сети. Применительно же к облачным технологиям такие системы могут быть реализованы на независимой виртуальной машине, которая может располагаться в том числе и у другого оператора с целью повышения взломоустойчивости систем.
Поскольку любой ЦОД сам по себе является защищённым хранилищем данных, повышенная защита может означать, к примеру, полное шифрование данных, абсолютную изоляцию от других данных и виртуальных машин, возможно, и размещение в каком-то удалённом месте или у другого провайдера услуг. Разумеется, при этом должно обеспечиваться полноценное функционирование всей инфраструктуры, безотносительно к физическому расположению оборудования.
Наконец, сами облака могут предоставлять услуги безопасности даже для вычислительных ресурсов, размещённых на территории заказчика: возможно, что с ростом доверия к облакам Security as a Service станет намного более востребованным сервисом. Облачные антивирусы, системы определения вторжений IDS и защиты от DDoS, а также различные межсетевые экраны могут значительно облегчить задачу обеспечения безопасности даже для крупных компаний.
А ведь уже существуют и гораздо более интересные решения – например, гибридные облака, при которых определённые части инфраструктуры остаются у заказчика, а другие – арендуются в облаке. Здесь в любом случае необходимы услуги облачной безопасности, иначе будет невозможно организовать эффективное взаимодействие между отдельными сегментами облака.
Другой вариант – распределённые облака, когда отдельные элементы инфраструктуры размещаются у разных облачных провайдеров, а вся система объединяется при помощи защищённых межсетевых экранов. Теоретически такая схема может быть намного отказоустойчивей, чем если бы всё облако арендовалось у одного оператора, хотя могут возникнуть сложности с его администрированием и правовым регулированием.
В любом случае облака уже сегодня готовы предложить потенциальным клиентам самые разнообразные способы защиты информации, в зависимости от их потребностей. Более того, недоверчивый клиент может самостоятельно установить свои собственные инструменты обеспечения безопасности в арендованной облачной инфраструктуре, при этом они будут подконтрольны исключительно авторизованному персоналу заказчика.
Экспертное мнение
Эдуард Бавижев, руководитель группы виртуализации DataLine
Для надёжной защиты облачной инфраструктуры необходимо использовать специализированные программные продукты и решения. В практике DataLine для обеспечения безопасного доступа к облаку используется решение Cisco Easy VPN, в рамках которого применяются устойчивые алгоритмы шифрования. Помимо этого, есть возможность разграничения доступа к порталу заказчика с использованием различных методов фильтрации.
Для защиты периметра виртуального дата-центра можно применять как аппаратные решения, так и специализированные программные. В компании DataLine для этих целей служат vShield EDGE и Cisco ASA. Оба варианта поддерживают функции VPN (с возможностью шифрования трафика), преобразования сетевых адресов (NAT), также дают возможность настраивать FireWall по определённым протоколам и портам. Для обеспечения антивирусной защиты виртуальных машин можно прибегнуть к продуктовой линейке vShield – в частности vShield Endpoint, а также к продукту Trend Micro Deep Security. Что касается защиты от DDoS-атак, то DataLine предоставляет соответствующий сервис совместно с компанией Highloadlab.
Облачные технологии и соответствующие решения помогают добиться как значительной экономии, так и повышения гибкости. Однако при внедрении этих технологий на предприятиях не следует оставлять без внимания традиционные процессы - их необходимо оптимизировать в расчете на новые условия. Из-за отсутствия физического доступа к серверам в публичных облачных средах вопросы безопасности становятся еще более важными, ведь в чрезвычайной ситуации не будет возможности нажать кнопку экстренного отключения.
В публичных облаках для создания новых клиентских учетных записей и облачных серверов потребуется лишь несколько минут времени и действующая кредитная карточка. Опыт показывает, что предприятиям не удается предотвращать ситуации, когда их сотрудники, к примеру, приобретают ресурсы для целей моделирования, включая их стоимость в командировочные расходы или оплачивая с помощью корпоративных кредитных карт. К сожалению, в результате реальное число облачных серверов, на которых хранятся конфиденциальные корпоративные данные, может значительно превосходить то количество, которое находится под контролем ответственных специалистов.
Поэтому гораздо безопаснее обеспечить сотрудникам предприятия контролируемый доступ к этим ресурсам - разумеется, только в действительно необходимых пределах. Это позволит не только упорядочить доступ, но и управлять им. Многие брокеры внешних и внутренних облаков предлагают широкие возможности администрирования доступа для отдельных лиц в соответствии с пользовательской, ролевой или мандантной моделью в рамках общего доступа. С одной стороны, в этом случае предоставляются только те права, которые действительно необходимы пользователям, а с другой - повышается безопасность на предприятии, поскольку права распределяются централизованно и дифференцированно.
Такие функции предоставляют все наиболее популярные облачные брокеры, такие как vCloud Director, Amazon/ IAM, OpenStack и CloudStack. Во многих случаях возможна даже комбинация локальных и внешних ресурсов. Отказ от этих функций равносилен наличию одного общего пароля для всех сотрудников компании, работающих за общим компьютером, - очевидно, не самый благоприятный сценарий. Поэтому создание и использование ролей, индивидуальных учетных записей или мандантов следует считать обязательным.
Независимо от того, под управлением какой операционной системы функционирует облачный сервер, доступ к нему необходимо защитить. Конечно, можно положиться на предоставленные брокером облачных сервисов случайные пароли, но обычно пользователи эти пароли либо где-нибудь записывают, либо заменяют их простыми стандартными комбинациями. Оба варианта не самые удачные.
Один из подходов заключается в разделении внутреннего и внешнего подтверждения прав доступа (Credentials). Это можно реализовать на базе собственных серверов доступа/SSH/ RDP Proxy или с помощью специализированных коммерческих решений. При этом сотрудники указывают свой внутренний пароль для регистрации на сервере доступа, а после проверки предоставленных им прав получают доступ к облачному серверу. Таким образом, при обращении к внешним ресурсам они смогут использовать свои собственные (доменные) пароли без угрозы для безопасности.
Этот вариант привлекателен особенно в средах Windows, поскольку, с точки зрения пользователей, доменные пароли пригодны для авторизации на облачных серверах, причем внешние облачные серверы не получают доступа к элементам Active Directory и их не нужно включать в домен. Периодическая смена паролей тоже значительно облегчается (а в некоторых случаях становится наконец-то возможной), поскольку внутренние и внешние процессы авторизации разделены.
Как и любая другая система, облачные серверы тоже создают журнальные записи (Log Data). Однако специалисты часто забывают о том, что журнальные записи могут служить важным источником информации при проведении инженерно-технических экспертиз (особенно для динамически запускаемых и останавливаемых облачных серверов). При необходимости такой экспертизы, к примеру, в случае хакерской атаки, эти данные (при их наличии) зачастую оказываются единственной зацепкой, ведь соответствующие облачные серверы уже могут быть выведены из эксплуатации.
Поэтому сохранение важных журнальных записей (вход/выход пользователей, целостность системы, обновления) за весь срок службы облачного сервера является важной и необходимой мерой. Только сбор данных, их объединение и вывод на внешние инструменты, к примеру на сервер Syslog, платформу безопасности с функцией проверки журналов или на систему управления событиями информационной безопасности (Security Information and Event Management, SIEM), позволят осуществить их последующий анализ. Атака на группу облачных серверов может остаться незамеченной, если атаки злоумышленника станут направляться каждый раз на новый сервер, но после вывода журнальных записей за пределы облачных серверов и выполнения их систематизации такое поведение можно будет быстро обнаружить (см. Рисунок 1).
С точки зрения обеспечения безопасности облака представляют собой лишь одну из разновидностей инфраструктурных платформ, пусть даже с высокой степенью автоматизации. Разумеется, и в облаке не обойтись без процессов, которые хорошо зарекомендовали себя в традиционных физических системах. Такие основополагающие функции, как межсетевой экран, IDS/IPS, виртуальное закрытие уязвимостей (Virtual Patching) и антивирусы, являются обязательными элементами любой концепции безопасности, будь то физические, виртуальные или облачные системы. А вот задачи, возникающие при управлении этими функциями, в различных инфраструктурах отличаются.
Необходимо, чтобы все серверы из локальных, внутренних или внешних облаков были идентифицированы и интегрированы в концепцию управления безопасностью. При использовании облачных сервисов этого можно добиться посредством прямой интеграции с брокером облачных сервисов, который в любой момент может предоставить информацию о наличии различных облачных серверов. Сопоставлять вручную параметры эксплуатируемых серверов с требованиями систем безопасности в динамических средах невозможно, а при попытках такого сравнения возникают многочисленные ошибки.
К сожалению, в этом случае действует принцип самого слабого звена: если какой-либо облачный сервер не интегрирован в систему управления безопасностью, то есть не защищен в достаточной мере, то для злоумышленников именно он является наиболее привлекательной мишенью. А когда информация о всех облачных серверах предоставляется автоматически, независимо от их расположения, с помощью профилей безопасности можно оперативно вносить изменения для любого количества облачных серверов.
Вместе с тем, это позволяет централизованно контролировать изменения, производимые на облачных серверах (к примеру, в файлах или реестре). Чтобы снизить трудоемкость отслеживания таких событий, необходимо обеспечить автоматическую фильтрацию этих данных посредством специализированного ПО - сортировать вручную все события, к примеру при обновлении стандартной системы Linux или Windows, не получится. Благодаря автоматической фильтрации «положительных» событий появляется возможность подробнее изучить оставшиеся, обнаружить вероятные несанкционированные действия и отследить их.
.png)
Независимо от того, связан ваш бизнес с Интернетом или нет, в вашей компании все равно есть информационная cеть.
Компьютерные сети упрощают логистику и финансовые операции, способствуют продуктивной работе сотрудников, где бы они ни находились, и обеспечивают сохранение данных. Возрастающие темпы интеграции физического и цифрового мира привели к появлению среды, полной новых возможностей для обучения, ведения совместной деятельности и повышения ее эффективности. В ближайшем будущем почти все устройства, как и люди, будут связаны друг с другом электронными коммуникациями.
Все это ведет к растущей популярности облачных вычислений, виртуализации и мобильности, распространению интеллектуальных датчиков и интересу к использованию персональных устройств для решения бизнес-задач (BYOD).
Однако не все потенциальные цифровые возможности заведомо приводят к успеху. Киберпреступники, хакеры и враждебно настроенные по отношению к другим странам государства стремятся воспользоваться нестабильностью и пробелами в безопасности, возникающими при развитии этих новых тенденций. С ростом взаимозависимости между физическим и электронным мирами крайне важное значение приобретают сбалансированные меры кибербезопасности, которые позволили бы получить максимальный эффект, использовать преимущества новых цифровых моделей и при этом держать под контролем их негативные стороны.
Цифровизация бизнеса - залог успеха, но, увы, у большинства организаций отсутствует какая-либо киберстратегия. Не понимая сопутствующих опасностей, которым они себя подвергают, многие организации не обладают стратегическим пониманием того, как можно свести к минимуму угрозы безопасности и воспользоваться открывающимися возможностями.
Чтобы полностью воспользоваться достоинствами сбалансированной киберстратегии, необходимо разработать два интегрированных плана - реализации цифровых преимуществ и обеспечения безопасности. Для их успешного претворения в жизнь компаниям нужно использовать преимущества стратегического руководства, продемонстрировать стремление к цели и обеспечить постоянный контроль при четком понимании задач и стимулов. Стратегия должна исходить из того факта, что киберфункции приобретают ключевую роль в достижении бизнес-успеха.
Первым шагом к разработке сбалансированной киберстратегии является создание плана реализации преимуществ цифрового мира, для чего необходимо исследовать, какие возможности и выгоды открывают перед организацией новые технологии. Для этого потребуется изучение и углубленный анализ как уже существующих цифровых решений, так и тех, которые будут разработаны в ближайшем будущем.
В первую очередь следует изучить следующее: технологии, обеспечивающие более простой обмен информацией, а также дающие выигрыш в эффективности за счет масштаба, виртуализации и миграции в облако; инновации в области коммуникаций и совместной работы; возможность максимального использования социальных технологий с помощью краудсорсинга и вовлечения заказчиков в процесс исследований и разработок, развития продуктов и маркетинга.
Кроме того, чтобы свести к минимуму риски, создаваемые инновационными решениями, нужно разработать план обеспечения безопасности. И прежде всего следует позаботиться об обеспечении устойчивости за счет осведомленности о ситуации, эффективного и действенного управления безопасностью и операциями, а также о создании и поддержке динамичной системы безопасности и противодействия.
Эпоха изолированных решений, нацеленных на защиту отдельных информационных систем, закончилась. Новые подходы должны предусматривать упреждающие стратегии, в рамках которых выявляются и отрабатываются первые признаки опасности, проводится активное тестирование, анализируются поведенческие тенденции, а инструменты и методы противодействия атакам постоянно обновляются в соответствии с изменениями мышления хакеров и применяемых ими методов. Чтобы обеспечить централизованное управление, стандартизацию и быстрое принятие решений безопасности в масштабе всей организации, необходимо целостное (360 градусов, 24/7) представление о всей сетевой инфраструктуре организации, ее ИТ-ресурсах, процессах и событиях.
Последним краеугольным камнем в данной стратегии является способность к гибкости. С развитием цифровых возможностей должна эволюционировать и система информационной безопасности. Выстраивание жестких барьеров и использование статических аппаратно-зависимых технологий позволят лишь идти в ногу с изменениями и инновациями, в то время как хакеры действуют быстрее, опережая способность бизнеса организовать защиту.
Для успешной защиты уровень организации систем безопасности должен быть выше среднего, а условия для проникновения в информационные системы настолько сложными, чтобы затраты времени и усилий, направляемые на взлом, оказывались для хакеров невыгодными. Для компании «лучшая практика» заключается в том, чтобы сравнивать себя с конкурентами и непрерывно развивать не только свою способность к обороне, но и готовность к нападению.
Интернет всегда был и будет великолепным источником и катализатором инноваций. Для успешной конкуренции компаниям следует находить подходящие для себя кибервозможности.
В то же время овладение ими может подвергнуть компанию дополнительному риску, ведь непрерывность бизнес-процессов начинает в большей степени зависеть от надежности сети, партнеры получают доступ к корпоративным данным, а электронное взаимодействие и сотрудничество превращаются в важнейшие элементы взаимодействия с заказчиками. Даже если организация не пользуется Интернетом, игнорировать эти риски нельзя.
Очень важно найти баланс между риском и выигрышем. Составляющие такого баланса специфичны для каждой организации и зависят от степени опасности, которую она считает приемлемой для достижения конкретных показателей возврата инвестиций. Однако руководители предприятий должны быть осмотрительны, знать о возможных угрозах и не упускать их из виду, увлекаясь технологическими инновациями, что потенциально может внести негативные коррективы в уже утвержденные стратегии развития, а в конечном счете - повредить способности бизнеса планировать и реализовывать поставленные задачи.
Дмитрий Ушаков - руководитель отдела по подготовке и внедрению технических решений Stonesoft Russia.
Предоставление надежно защищенного облачного сервера для обработки данных - это лишь первый шаг при использовании облачных сервисов. На втором и третьем этапах требуется переместить данные на защищенный облачный сервер и позаботиться о том, чтобы они и в облаке (то есть за пределами сферы физического доступа клиента) оставались в безопасности. Последнее можно обеспечить с помощью полного шифрования виртуальных жестких дисков: в случае необходимости получения доступа данные расшифровываются при считывании, а затем снова зашифровываются при записи на диск. Благодаря этому можно избежать ситуаций, когда незашифрованная информация попадает в системы длительного хранения провайдеров услуг или сохраняется в виде резервных копий.
При шифровании данных всегда возникает вопрос о ключах. Их хранение на облачном сервере нецелесообразно, поскольку каждый, кто имеет доступ к облачным серверам или шаблонам, мог бы получить доступ к ключу - а значит, и к расшифрованным данным. Набор пароля при запуске системы, как это принято в локальных решениях для шифрования данных, затруднен в связи с отсутствием настоящей консоли, однако идея неплоха. Физический ввод ключа заменяется запросом, который облачный сервер отправляет внешнему источнику - серверу управления ключами (Key Management Server, KMS).
ШИФРОВАНИЕ ДАННЫХ Сервер KMS проверяет идентификационные данные (к примеру, по облачному серверу, IP-адресам, шаблонам, ЦОД или местонахождению) и целостность (брандмауэр, установленные заплаты, наличие активного антивирусного сканера) облачного сервера, направившего запрос, - точно так же, как это делает человек при традиционном шифровании жестких дисков. В случае успеха ключ предоставляется либо автоматически, либо после подтверждения вручную уполномоченным лицом. После этого облачный сервер получает доступ к данным - до тех пор, пока не окажется нарушена его целостность или идентичность.
Решающим фактором для обеспечения безопасности такого решения является раздельная эксплуатация облачного сервера и сервера управления ключами (см. Рисунок 2): если оба размещены у (одного и того же) провайдера облачных сервисов, то вся информация снова оказывается собранной в одном месте. Хорошей альтернативой является установка сервера KMS в локальном ЦОД или в качестве внешней услуги у другого сервис-провайдера.
Помимо вышеупомянутого варианта шифрования жестких дисков с раздельным управлением ключами при предоставлении инфраструктуры в качестве сервиса (Infrastructure as a Service, IaaS), эта концепция встречается и при реализации модели предоставления платформы как услуги (Platform as a Service, PaaS). Информация зашифровывается таким образом, что в базы данных, предоставляемые провайдером облачных сервисов, в виде открытого текста она не попадает. В этом случае необходимые для работы с зашифрованными данными ключи тоже контролируются пользователем.
Оба указанных метода не следует путать с шифрованием данных на стороне провайдера, когда данные шифруются провайдером перед их перемещением на системы хранения или при резервном копировании (такой подход применяется, к примеру, в сервисе Amazon S3 Server-Side Encryption). Эта технология позволяет защитить информацию от злоумышленников, даже если те получат физический доступ к жестким дискам (украденные данные будут непригодны для использования), но не убережет от злоупотребления должностными полномочиями со стороны сотрудников провайдера облачных сервисов.
.png)
Рынок облачных сервисов растет быстрыми темпами, поэтому и вопросы безопасности их использования стоят очень остро. На территории Российской Федерации работа с такими сервисами имеет свою специфику в силу законодательных требований обязательной защиты информации, например персональных данных, врачебной тайны и т. д. В первую очередь необходимо определиться с подходами к решению вопросов ИБ при различных реализациях облачных сервисов.
Модель «ПО как сервис» (Software as a Service, SaaS) подразумевает обработку и хранение всех данных на стороне провайдера. В данном случае приходится полностью доверять принятым им мерам и технологиям защиты информации. Использование SaaS для обработки, скажем, персональных данных - причем как в техническом плане, так и в организационно-правовом - возможно только в доверенных инфраструктурах. Поэтому единственным применением этой модели представляется реализация частных облаков, когда доверенный провайдер является подразделением или подведомственной организацией вышестоящего органа.
При этом особое внимание следует уделить вопросам доступа к сервису SaaS. Для его защиты необходимы строгая двухфакторная аутентификация пользователей с помощью отчуждаемых носителей (USB-токенов или смарт-карт), например eToken, и передача данных в зашифрованном виде. Для этой цели подходят HTTPS или VPN с поддержкой сертифицированной «российской» криптографии, шифрование выборочных данных на прикладном уровне посредством подключаемого модуля браузера или же описанное автором статьи решение с применением собственных proxy-серверов, которые защищают коммуникацию с провайдером.
Модель «платформа как сервис» (Platform as a Service, PaaS), как и SaaS, при обработке персональных данных применима только при работе с доверенным провайдером. И на нее тоже распространяются все вышеперечисленные подходы (с некоторым расширением).
Кардинальную противоположность SaaS представляет модель «инфраструктура как сервис» (Infrastructure as a Service, IaaS). В данном случае потребителю предоставляется готовая инфраструктура. Это может быть как виртуальная машина, так и целая сеть. При обращении к услугам недоверенного провайдера следует контролировать доступ на уровне гипервизора, иначе все попытки построить эффективную защиту будут сродни построению крепких ворот без забора. При этом задача обеспечения информационной безопасности сводится к комплексной защите удаленного подразделения с применением зарекомендовавших себя традиционных методов, применяемых в физических системах.
В случае недоверенного провайдера при использовании любой модели актуально хранение данных в облаке в зашифрованном виде. Особую остроту этому вопросу придает популярность общедоступных сервисов Data as a Service и Database as a Service, которые не предусматривают защищенного взаимодействия между провайдером и потребителем, нарушая требования регуляторов в области ИБ. Когда HTTPS или VPN с сертифицированной «российской» криптографией не используется, единственно возможным решением представляется передача данных по открытым каналам связи в зашифрованном виде. И такие предложения имеются на рынке - например, «Крипто БД» в режиме работы с шифрующим посредником (proxy). Отличительная особенность этих решений заключается в том, что управление ключами осуществляется администратором ИБ в рамках локальной инфраструктуры, а не в инфраструктуре провайдера.
Максим Чирков - руководитель направления развития сервисов ЭП компании «Аладдин Р.Д.».
Но что даст зашифрованное хранение данных даже в сочетании с надежным контейнером, если передача данных осуществляется в незащищенном виде и без проверки целостности? Для безопасной обработки данных обязательным условием является их шифруемая передача. Интересный вариант представляет собой комбинация из зашифрованных данных и технологий защищенной передачи.
Большинство протоколов SSL и VPN в качестве опции поддерживают использование цифровых сертификатов для аутентификации, посредством которых проверяется идентификационная информация другой стороны, причем еще до начала передачи данных. Такие цифровые сертификаты могут храниться на виртуальных жестких дисках в зашифрованном виде, и используются они только после того, как сервер управления ключами проверит идентификационную информацию и целостность системы. Следовательно, такая цепочка взаимозависимостей позволит передавать данные только тем облачным серверам, которые прошли предварительную проверку.
Тема безопасности в облаке очень обширна. Особое внимание следует обратить на контекст, в котором работают облачные серверы: ведь во внешних облаках ближайший сосед может оказаться основным конкурентом, поэтому следует изначально исходить из того, что вы находитесь на «вражеской территории», и обеспечить соответствующие меры безопасности. К сожалению, к обещаниям, которые дают провайдеры облачных сервисов, следует относиться с осторожностью, ведь правовая ответственность за сохранность данных и их утрату возлагается на самих клиентов.
Помимо общих правовых условий, существуют меры технического характера, соблюдение которых позволит повысить защищенность облачных ЦОД. Прежде всего все действия, направленные на улучшение их защиты и управление ими, не должны становиться помехой для работы пользователей. Это потребует, с одной стороны, применения уже проверенных инструментов и методов - частично в более расширенном формате (как в случае шифрования данных и раздельного управления ключами). С другой стороны, обязательным условием для повышения уровня автоматизации является более тесная интеграция различных функций безопасности с брокером облачных сервисов. Учет этих двух аспектов позволит в полной мере воспользоваться преимуществами облаков и не допускать компромиссов в сфере безопасности.
Удо Шнайдер - системный архитектор по региону ЕМЕА в компании Trend Micro.
Компании, которые задумываются о переходе к облачным вычислениям (cloud computing), больше всего волнует вопрос безопасности. Но далеко не все знают, что при профессиональном подходе к выбору провайдера облачных услуг существует возможность повысить уровень защиты своих данных. Как выясняется на практике, зачастую провайдер предоставляет более высокий уровень безопасности, чем тот, который компании могут обеспечить внутри собственной инфраструктуры. Дело в том, что решение связанных с безопасностью задач провайдеры берут на себя и посвящают этой работе гигантские усилия. Часто именно на гарантиях безопасности строится вся маркетинговая активность провайдера. Обслуживая предприятия с оборотом в миллиарды долларов, облачные провайдеры делают все от них зависящее для обеспечения максимально безопасной среды. Тем не менее, облачные вычисления несут в себе множество новых рисков для потенциальных пользователей.
Перед тем как довериться определенному провайдеру, компании стоит удостовериться в том, что он действительно обладает средствами для обеспечения уровня надежности, необходимого для безопасной работы с приложениями и хранения данных в облаке. К счастью, возрастающая конкуренция на рынке облачных сервисов заставляет игроков предлагать бòльшие возможности и во многих случаях более гибкий контроль, чем готовы предоставить организациям их собственные ИТ-инфраструктуры. Расчетливые покупатели облачных сервисов, действительно знающие, что им нужно, могут курсировать от одного провайдера к другому в поиске более подходящих для себя решений.
Но прежде чем погрузиться в cloud computing, клиенту необходимо определить полный список требований к вычислительной платформе, включая и уровень безопасности. В этом случае можно обратиться к поставщику с прямым вопросом, способна ли его платформа удовлетворить этим требованиям. Для того, чтобы не ошибиться в выборе, крайне важно знать, какие именно вопросы задавать и что именно искать в ответах провайдера.
Кто на вашей стороне ?
На сегодняшний день лучшим экспертом в сфере облачной безопасности является Cloud Security Alliance (CSA). Эта организация выпустила и недавно обновила руководство, включающее описание сотни нюансов и рекомендаций, которые необходимо принимать во внимание при оценке рисков в облачных вычислениях. Руководство включает 76 страниц, и чтобы вам не пришлось читать столь длинный документ, мы отобрали наиболее важные рекомендации и составили серию вопросов, которые стоит задать потенциальному провайдеру облачных услуг в первую очередь. А также привели ответы, которые вы должны получить. Хотя данная статья и описывает множество ключевых моментов, мы рекомендуем вам в любом случае ознакомиться с оригиналом руководства .
Еще одной организацией, деятельность которой затрагивает аспекты безопасности в облаке, выступает Trusted Computing Group (TCG). Она является автором нескольких стандартов в этой и других сферах, в том числе широко используемых сегодня Trusted Storage, Trusted Network Connect (TNC) и Trusted Platform Module (TPM). Более подробную информацию об этих стандартах можно получить на веб-сайте TCG .
Облачные вычисления: вопросы и ответы
Приведенные ниже пункты являются ключевыми вопросами, которые стоит задать провайдеру, облачными услугами которого вы планируете пользоваться. Каждый вопрос касается одной из шести специфических областей, как показано на рис.1.
Рис. 1:
Области безопасности, требующие изучения при выборе
поставщика облачных услуг
Прежде чем обратиться к вопросам, вы должны понять преимущества использования решений основанных на стандартах. И это касается всех областей безопасности. Проприетарные системы несут меньший уровень надежности по сравнению с системами на базе стандартов, и с этим согласны как игроки рынка, так и государственные учреждения, и органы стандартизации. Именно поэтому повсеместное распространение получили такие стандарты, как Advanced Encryption Standard (AES) и Transport Layer Security (TLS). Они претерпели годы анализа и улучшений. Более того, используя основанные на общепринятых стандартах системы безопасности, клиент получает дополнительное преимущество – в случае необходимости он сможет поменять провайдера услуг, так как большая часть провайдеров поддерживают стандартизованные решения.
Еще один момент, который стоит прояснить: как удостовериться в том, что провайдер выполняет данные им обещания? В этом вам поможет заключение соглашения об уровне услуг (Service Level Agreement, SLA), или контракта, или другого письменного документа, где будут четко прописаны обязательства провайдера. Итак, серия вопросов от общего к частному, которые стоит задать потенциальному провайдеру облачных услуг.
1. Сохранность хранимых данных . Как сервис-провайдер обеспечивает сохранность хранимых данных?
Лучшая мера по защите расположенных в хранилище данных – использование технологий шифрования. Провайдер всегда должен шифровать хранящуюся на своих серверах информацию клиента для предотвращения случаев неправомерного доступа. Провайдер также должен безвозвратно удалять данные тогда, когда они больше не нужны и не потребуются в будущем.
2. Защита данных при передаче . Как провадйер обеспечивает сохранность данных при их передаче (внутри облака и на пути от/к облаку)?
Передаваемые данные всегда должны быть зашифрованы и доступны пользователю долько после аутентификации. Такой подход гарантирует, что эти данные не сможет изменить или прочитать ни одно лицо, даже если оно получит к ним доступ посредством ненадежных узлов в сети. Упомянутые технологии разрабатывались в течение "тысяч человеко-лет" и привели к созданию надежных протоколов и алгоритмов (например TLS, IPsec и AES). Провайдеры, должны использовать эти протоколы, а не изобретать свои собственные.
3. Аутентификация . Как провайдер узнает подлинность клиента?
Наиболее распространенным способом аутентификации является защита паролем. Однако провайдеры, стремящиеся предложить своим клиентам более высокую надежность, прибегают к помощи более мощных средств, таких как сертификаты и токены. Наряду с использованием более надежных к взлому средств аутентификации провайдеры должны иметь возможность работы с такими стандартами как LDAP и SAML. Это необходимо для обеспечения взаимодействия провайдера с системой идентификации пользователей клиента при авторизации и определении выдаваемых пользователю полномочий. Благодаря этому провайдер всегда будет располагать актуальной информацией об авторизованных пользователях. Худший вариант – когда клиент предоставляет провайдеру конкретный список авторизованных пользователей. Как правило, в этом случае при увольнении сотрудника или его перемещении на другую должность могут возникнуть сложности.
4. Изоляция пользователей . Каким образом данные и приложения одного клиента отделены от данных и приложений других клиентов?
Лучший вариант: когда каждый из клиентов использует индивидуальную виртуальную машину (Virtual Machine – VM) и виртуальную сеть. Разделение между VM и, следовательно, между пользователями, обеспечивает гипервизор. Виртуальные сети, в свою очередь, развертываются с применением стандартных технологий, таких как VLAN (Virtual Local Area Network), VPLS (Virtual Private LAN Service) и VPN (Virtual Private Network).
Некоторые провайдеры помещают данные всех клиентов в единую программную среду и за счет изменений в ее коде пытаются изолировать данные заказчиков друг от друга. Такой подход опрометчив и ненадежен. Во-первых, злоумышленник может найти брешь в нестандартном коде, который позволит ему получить доступ к данным, которые он не должен видеть. Во-вторых, ошибка в коде может привести к тому, что один клиент случайно "увидит" данные другого. За последнее время встречались и те, и другие случаи. Поэтому для разграничения пользовательских данных применение разных виртуальных машин и виртуальных сетей является более разумным шагом.
5. Нормативно-правовые вопросы . Насколько провайдер следует законам и правилам, применимым к сфере облачных вычислений?
В зависимости от юрисдикции, законы, правила и какие-то особые положения могут различаться. Например, они могут запрещать экспорт данных, требовать использования строго определенных мер защиты, наличия совместимости с определенными стандартами и наличия возможности аудита. В конечном счете, они могут требовать, чтобы в случае необходимости доступ к информации смогли иметь государственные ведомства и судебные инстанции. Небрежное отношение провайдера к этим моментам может привести его клиентов к существенным расходам, обусловленными правовыми последствиями.
Провайдер обязан следовать жестким правилам и придерживаться единой стратегии в правовой и регулятивной сферах. Это касается безопасности пользовательских данных, их экспорта, соответствия стандартам, аудита, сохранности и удаления данных, а также раскрытия информации (последнее особенно актуально, когда на одном физическом сервере может храниться информация нескольких клиентов). Чтобы это выяснить, клиентам настоятельно рекомендуется обратиться за помощью к специалистам, которые изучат данный вопрос досконально.
6. Реакция на происшествия . Как провайдер реагирует на происшествия, и насколько могут быть вовлечены его клиенты в инцидент?
Иногда не все идет по плану. Поэтому провайдер услуг обязан придерживаться конкретных правил поведения в случае возникновения непредвиденных обстоятельств. Эти правила должны быть задокументированы. Провайдеры обязательно должны заниматься выявлением инцидентов и минимизировать их последствия, информируя пользователей о текущей ситуации. В идеале им следует регулярно снабжать клиентов информацией с максимальной детализацией по проблеме. Кроме того, клиенты сами должны оценивать вероятность возникновения проблем, связанных с безопасностью, и предпринимать необходимые меры.
Будущее облачной безопасности
Несмотря на то, что сегодня мы имеем значительно более широкий набор инструментов для обеспечения безопасности, чем прежде, работа далеко не окончена. В некоторых случаях для вывода на рынок той или иной технологии, помогающей решить новую задачу, проходит некоторое время, даже несмотря на то, что она уже разработана. Вот некоторые из таких новейших технологий: данные со встроенной защитой (самозащищенные данные) и доверенные мониторы.
Самозащищенные данные (self-protected data) – это зашифрованные данные, в которые интегрирован механизм обеспечения безопасности. Такой механизм включает в себя набор правил, которым может или не может удовлетворять среда, в которой находятся самозащищенные данные. При попытке доступа к этим данным, механизм проверяет среду на безопасность и раскрывает их, только если среда является безопасной.
Доверенный монитор (trusted monitor) – это программное обеспечение, устанавливаемое на сервер провайдера облачных вычислений. Оно позволяет наблюдать за действиями провайдера и передавать результаты пользователю, который может убедиться в том, что компания действует в соответствии с принятым регламентом.
Когда все исследовательские работы и разработка новых технологий будут завершены, следующим шагом станет их внедрение провайдером услуг. Когда это произойдет, клиенты будут с большим доверием относится к концепции облачных вычислений.
Огромные вычислительные мощности облачных инфраструктур открывают перед пентестерами и блекхатами множество новых возможностей. Сегодня мы посмотрим на cloud computing с новой стороны и рассмотрим конкретные кейсы использования облачных мощностей для взлома и пентестинга.
Облачные вычисления представлены для пользователя следующими услугами:
В первую очередь нас интересует сервис IaaS, так как он предоставляет в данный момент наиболее востребованную и «реалистичную» среду для пентестера. Сервис IaaS предоставляет пользователю возможность создания виртуального сервера на основе оборудования провайдера облачных вычислений. Самое очевидное преимущество данного сервиса - практически неограниченные возможности по масштабированию вычислительных мощностей.
Что же такое сервис IaaS для пентестера? Это уникальная возможность использовать десятки идентичных по возможностям серверов с целью эффективной реализации классических задач в области пентеста:
Само собой, использование инновационных технологий облачных вычислений может быть направлено как в полезное русло, так и в не очень полезное. Как плохие парни могут использовать сервис в своих целях? Этот вопрос мы постараемся рассмотреть в данной главе на примере наиболее частых злоупотреблений.
Вопрос анонимности при использовании сервисов облачных вычислений стоит крайне остро. Дело в том, что вся информация, которая необходима для получения доступа к такого рода сервисам, ограничивается лишь номерами кредитной карты и сотового телефона. Большинство провайдеров верят пользователю «на слово» и не задумываются в настоящий момент о вопросах, возникающих после того, как их сервис стал одной из ключевых цепочек в истории взлома какого-либо ресурса. Чтобы выгодно продать свои услуги, провайдеры охотно предлагают пользователям промо-программы, предоставляющие возможность бесплатного использования сервисов в течение определенного промежутка времени. Вся информация о пользователе, получившем доступ к сервису, в таком случае сводится к адресу электронной почты и IP-адресу, который был использован пользователем для управления услугами. Совершенно понятно, что в этих условиях существует много способов абсолютно анонимного использования облачных мощностей.
Термин «сетевая разведка» подразумевает под собой мероприятия, направленные на автоматизированный сбор информации для дальнейшего анализа. Облачные вычисления позволяют создать отличную площадку для проведения такого рода мероприятий, потому что обеспечивают несколько важных факторов, которые необходимы для автоматизации сбора данных. А именно: разные IP-адреса, с которых производится сбор данных, скорость канала связи и вычислительные ресурсы, позволяющие быстро обрабатывать полученную в результате сбора данных информацию.
Использование возможностей сервиса IaaS позволяет злоумышленнику преодолевать такие защитные средства, как IPS/IDS. Идея возможности скрытого от IPS/IDS сканирования портов на удаленной системе заключается в том, что сканирование проходит с более чем десятка различных IP-адресов с временными интервалами, по частям. В результате - даже хорошо настроенная IPS/IDS не сможет идентифицировать событие сканирования портов, а если идентифицирует его, то заблокирует только один IP-адрес из множества адресов, сканирующих серверов. Естественно, для реализации такой задачи необходимо разработать программное обеспечение, позволяющее удаленно управлять процессами на серверах, запущенных на площадке провайдера облачных вычислений.
IaaS-площадки идеально подходят и для атак на удаленные сервисы. Например, для перебора паролей, а также различных видов client-side-атак. Во-первых, на площадке достаточно легко и просто «развернуть» любой боевой арсенал, например, metasploit или canvas. Во-вторых, перебор паролей может быть осуществлен распределенно, как и в случае со сканированием портов удаленного хоста, во избежание блокировки IP-адреса атакующего. В третьих, площадка IaaS может послужить отличным посредником между атакующим и целью с точки зрения того, что история всех действий, совершенных с площадки IaaS, будет уничтожена после выключения сервера.
Возможность использовать условно «неограниченные» ресурсы облачных вычислений позволяет продуктивно проводить мероприятия по брутфорсу хешей и генерации радужных таблиц с последующим восстановлением по ним зашифрованных строк. Явным плюсом генерации радужных таблиц на базе облачных сервисов является возможность использования огромного устройства хранения данных. На практике генерация радужных таблиц для алгоритма ntlm (mixalpha-numeric-all-space, 8 символов) сводится только к вопросу времени и финансовым затратам. Для генерации такой таблицы на топовом домашнем компьютере потребуется порядка 1290 лет. В случае же облачных вычислений, прямо здесь и сейчас можно купить «машину времени», которая будет создаваться примерно 1,5 года и ее стоимость составит порядка $320k. Я хочу сказать, что такую таблицу, используя облачные вычисления, на практике можно создать всего за 1,5 года. В таблице 1 показана детальная статистика по финансовым затратам для такой разработки. В данном случае использовалось 20 серверов со следующими техническими характеристиками: 2xIntel Xeon X5570 quad-core «Nehalem» architecture, 2 ядра NVidia Tesla M2050, 23 Гб ОЗУ.
Цифры говорят о том, что пора менять парольную политику - расшифровать NTLM-хеш пароля из 8 символов вполне реально и доступно для плохих парней. Но это только теория. На практике же политика безопасности паролей более лояльна и ограничивает пользователя лишь длиной пароля - 8 символов в лучшем случае. Статистика используемых паролей в крупных компаниях, составленная Дмитрием Евтеевым и приведенная в его докладе «Анализ проблем парольной защиты в российских компаниях «, говорит о том, что большинство пользователей всеми возможными способами пытаются обойти ограничения парольной политики и использовать простой пароль.
В таблице 2 представлены необходимые для генерации различных радужных таблиц ресурсы.
Как видно, генерация «универсальной» радужной таблицы для паролей, состоящих из символов английского алфавита (lowcase) и цифр (от 1 до 12 символов) занимает целый миллениум и порядка 80 млн долларов. Для частного лица это на грани фантастики, но для государств и даже крупного бизнеса - вполне подъемно. Если же задаться целью, то используя всего 20 000 серверов вместо 20, можно создать такую таблицу всего за год.
В первую очередь необходимо разобраться со схемой проведения эффективной ДДоС-атаки на сервер/сервис. Гаранты эффективности ДДоС-атаки:
IaaS в скопе со специализированным DDoS-софтом - этой убойная конструкция, позволяющая осуществлять очень эффективные ДДоС-атаки. Сервис IaaS удовлетворяет пункт о необходимом множестве атакующих машин. Специализированный софт должен отвечать за «умную» нагрузку атакуемых систем с целью «отказа в обслуживании».
Специалистами нашей компании было разработано техническое задание для подобного рода софта. Требования к распределенной системе нагрузочного тестирования:
Необходимые на первых парах модули:
Параллельно с разработкой распределенной системы нагрузочного тестирования, мы провели испытания уже существующего софта для нагрузочного тестирования. Большая часть публичного ПО не удовлетворяла пункту централизованного управления, в связи с чем пришлось самостоятельно писать управляющие скрипты для централизации управления атакующими приложениями.
Из публичных утилит мы использовали два продукта:
Разработка системы распределенного нагрузочного тестирования была проведена в соответствии с от провайдера Amazon . Выбор пал на данного провайдера не случайно. Во-первых, Amazon - достаточно быстро развивающийся крупный проект, позволяющий своим пользователям одними из первых получать доступ к новым «фичам» функционала облачных вычислений. Во-вторых, после проведения сравнения бюджета на реализацию атак на отказ в обслуживании, который приведен ниже в таблице 3, оказалось, что сервис от Amazon наиболее демократичен и гибок.
Технические характеристики запускаемого Instance, выступающего в роли атакующего звена, представляют собой следующее:
Технические характеристики Instance были выбраны минимальными в силу того, что для реализации атаки на «отказ в обслуживании» приоритет отдается количеству атакующих машин, а не их вычислительным характеристикам. Каждый Instance снабжен каналом с пропускной способностью 100 Mb/s, поэтому проблем в скорости передачи данных до атакуемого сервера теоретически быть не должно.
В первую очередь было очень интересно увидеть реальную мощность предполагаемого «ботнета» на облачных технологиях. Для теста был выбран сценарий упомянутого Брайена Андерсона, представляющий из себя реализацию атаки на «отказ в обслуживании» для HTTP-сервера.
Как было выяснено, связка 1 «Instance» + скрипт SlowPost.pl позволяет эмулировать более чем 900 клиентов веб-сервера. Таким образом, этой связки достаточно, чтобы вывести из строя любой веб-сервер, поддерживающий максимальное число подключений менее чем 900. Бюджет, необходимый для реализации такой атаки сводится к минимуму за счет потребления лишь компьютерного времени, а не ресурсов и трафика. Себестоимость атаки для таких веб-серверов - меньше 7 рублей в час! (см. таблицу 4)
При тестировании в реальных условиях мишенью выступал веб-сайт, обслуживаемый сервером IIS. Балансировка нагрузки была разделена на два IP-адреса. Таким образом, чтобы положить этот сервер, потребовалось создать более чем 20 000 подключений к каждому из IP-адресов. Настройки атакуемого веб-сервера были установлены по умолчанию. В итоге, для обеспечения всех условий для удачной атаки «отказ в обслуживании» было запущено 46 «Instance», каждый из которых эмулировал одновременную работу 900 пользователей. Кстати, обычным пользователям Amazon позволяется работать одновременно только с 20 «Instance». Чтобы полностью пройти путь плохого парня, задумавшего DDoS-атаку, мы просто зарегистрировали три различных аккаунта. Кроме этого, для регистрации нам понадобилось три сим-карты. Естественно, были куплены анонимные карты с балансами 300 рублей - причем абсолютно легально. К каждой сим-карте была приобретена карта оплаты (Prepaid Card For Internet Shopping) с балансами $5 - карта необходима при регистрации на площадке Amazon и верификации. В итоге, бюджет для атаки «отказ в обслуживании» на веб-сайт достаточно крупной компании составил всего 1150 рублей. Детальная стоимость представлена в таблице 5.
Атака проводилась в отношении веб-сервера на протяжении двух часов, чего вполне достаточно для ощутимых потерь в сфере интернет-бизнеса.
Удобство облачных сервисов заключается также в гибкости выбора ОС и ее компонентов через приятный веб-интерфейс. Пользователь может использовать как стандартные решения, предоставленные провайдером, так и образы ОС, созданные пользователями провайдера. Например, сервис от Амазон очень активно использует данную систему. Именно в ней и кроится опасность - провайдер не гарантирует того, что образы систем, предоставленные пользователями для общего использования, не выполняют никаких скрытых действий: например, не ведут логи, не копируют личную информацию, не становятся частью ботнета, не распространяют вредоносное ПО. Проведенные тесты показали, что многие пользователи действительно не следят за такими вещами.
Для проведения теста потребовалось:
Кроме этого мелким шрифтом в описании программы было написано, что при старте этого образа ОС в автоматическом режиме происходит HTTP-GET-отстук на сервер, собирающий статистику. Хотя об этом можно было и не говорить в описании образа, мелкий текст не испортил картины. Как результат - более 1000 отстуков за месяц! Представь, какой хороший и бесплатный ботнет можно собрать. Размещаешь протрояненный образ с красивым описанием - пользователи устанавливают его, а ты анонимно пользуешься их серверами за их же деньги.
Теоретически, оперативное реагирование на жалобы должно быть правилом для любого провайдера. В реальности же все обстоит несколько иначе. Проведя небольшое исследование, было выявлено, что даже серьезные провайдеры облачных сервисов (например, Amazon), не спешат реагировать на abuse и расследовать инциденты. Фактически, дело не заходит дальше учета сообщений об инцидентах. Во-первых, чтобы инцидент был рассмотрен провайдером, необходимо предоставить, помимо IP-адреса атакующего, точную дату и время атаки. После предоставления необходимой информации о злоумышленнике, переписка с провайдером будет продолжаться. Но это будет односторонняя переписка: провайдер с радостью выслушает ответы на интересующие его вопросы, но вот на твои - не ответит, за редким исключением, любезно игнорируя.
При первом обращении к провайдеру, служба безопасности просит предоставить следующую информацию:
Крайне важны точное время атаки и временная зона атакуемой машины. Это связано с тем, что IP-адрес атакующего может менять владельца более одного раза за сутки, что усложняет идентификацию злоумышленника. Кроме этого следует точно идентифицировать вид атаки и создать слепок лог-файлов атакуемого сервиса для предоставления службе безопасности провайдера.
Облачные технологии, предоставив пользователям доступ к огромным вычислительным возможностям, также дали возможность плохим парням использовать свои мощности в корыстных целях. Панацеи от этого не существует. Но, зная возможные векторы атаки с использованием облачных вычислений, можно защитить свои информационные ресурсы от возможных инцидентов.
Шишкин В.М.
Аннотация
В статье анализируется ситуация, которая складывается в настоящее время в связи с интенсивным распространением так называемых «облачных» услуг. Отмечается недостаточная исследованность и противоречивый характер понимания безопасности в «облаке», указывается на обеспечение доверия как основного условия успешного использования данной технологии. Рассматриваются возможности применения авторской методики и программных средств, ориентированных на риск-анализ сложных, не достаточно определённых объектов для исследования безопасности облачных вычислений.
The situation developing now in connection with intensive expansion of so-called cloud services is analyzed in the paper. Insufficient study and discrepancy of understanding of security in «cloud» is marked and it is underlined trust maintenance as basic condition for successful use of these technologies. The paper considers the possibilities of the author’s technique and software oriented to risk analysis of complex objects which are not certain enough for the cloud computing security research.
Введение
Под облачными вычислениями (cloud computing) понимаются технологии обработки данных, в которых ресурсы (память, процессор, дисковое пространство и пр.) предоставляются пользователю как интернет-сервисы. Пользователь получает доступ к своим данным, при этом вся забота об обслуживании инфраструктуры полностью ложится на поставщика услуг. Термин «облако» выступает в качестве метафоры, которая основывается на изображении интернета на диаграммах компьютерных сетей. В 2008 году IEEE опубликовал документ, в котором определил облачную обработку данных как «парадигму, в рамках которой информация постоянно хранится на внешних серверах и временно кэшируется на клиентской стороне» .
«Облачные» услуги сравнительно новый, активно развивающийся сектор ИТ-услуг, но не следует считать применяемые в них технологии революционными, это лишь новая методика доставки услуг. Они представляют очередной и не последний этап давно обозначившейся объективно обусловленной тенденции на распределённое хранение и обработку, виртуализацию ресурсов и отчуждение конечного пользователя от непосредственного управления ими. Существенная их новизна проявляется,
пожалуй, в организационном отношении. В отличие от предшествующих технологий, «облачные» услуги зародились прежде всего как коммерческий проект. Соответственно, предоставляются они преимущественно на коммерческой основе, что создаёт дополнительные сложности для анализа их применения, во всяком случае, получить систематические объективные данные по их безопасности из литературных источников пока затруднительно.
Исходя из собственного опыта, присоединимся к мнению автора : «Сегодня говорить о безопасности облачных вычислений довольно сложно». Разумеется, существуют некоторые руководства по безопасности, выработанные, например, усилиями Cloud Security Alliance (CSA), тем не менее следует признать, что технический стандарт облачных вычислений находится все еще в начальных стадиях разработки .
При этом облачные вычисления как одна из технологий распределения и виртуализации ресурсов, в которой ресурсы и мощности предоставляются пользователю как интернет-сервис, с точки зрения безопасности на первый взгляд имеют преимущества перед традиционными технологиями взаимодействия в сетевых компьютерных структурах. Правда, технологии виртуализации доступа к сетевым ресурсам уже достаточно давно декларировались, в частности в Sun Microsystems, как едва ли не универсальное средство защиты их от несанкционированного использования, но, признавая безусловную эффективность и полезность данного подхода к повышению защищённости информационных ресурсов, панацеей их безопасности он стать, конечно же, не мог. Виртуализация доступа, тем более в отношении публичных сервисов, сама по себе не способна обеспечить информационную безопасность в широком смысле этого слова. Согласно данным CSA , несмотря на наличие встроенных в технологию облачных вычислений механизмов безопасности, при оценке рисков использования «облачных» услуг необходимо принимать во внимание большое количество обстоятельств. Добавим, что они не всегда достаточно определены и могут иметь субъективный характер, что существенно осложняет анализ любой ситуации.
1. Обзор технологических решений
Рассмотрим некоторые из применяемых в настоящее время технологических решений для облачных вычислений для того, чтобы дать представление о них в самом общем виде, без ссылок на источники. Обычно выделяются следующие основные уровни в архитектуре облачных вычислений:
инфраструктура как сервис (IaaS); платформа как сервис (PaaS);.
программное обеспечение как сервис (SaaS); хранение данных (рабочее место) как сервис (DaaS); оборудование как сервис (HHaaS);
ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ
PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»
VOL.II, IZHEVSK, NOVEMBER 8–12, 2011
коммуникации как сервис (CaaS).
На рисунке 1 представлена указанная схема архитектуры.
Рис. 1. Архитектура облачных вычислений
Список не ограничивается приведенными пунктами и может расширяться, так как могут появиться новые технологические тенденции, разнообразные гибридные решения. Общим в таких тенденциях является уверенность, что Интернет способен удовлетворить все потребности пользователя по обработке данных («Всё как сервис»).
Sun Cloud Computing Resource Kit (SCCRK) опирается на принципы открытого ПО: предоставление механизмов взаимодействия для больших компьютерных ресурсов и распределенных приложений через компоненты для облачных вычислений. Предлагается ПО для полного построения облака: гипервизор (Sun xVM Server, базируется на Xen), виртуализация ОС (Solaris Containers), виртуализация сети (Crossbow), виртуализация накопителей
(COMSTAR, ZFS) и сервера приложений (GlassFish, Java CAPS).
Amazon EC2 является центральным компонентом системы для облачных вычислений Amazon Web Service (AWS), позволяющих создавать и загружать в
Amazon S3 (Simple Storage Component) образы виртуальных машин (Amazon Machine Image, AMI), настраивать через веб-сервис безопасность и сетевой доступ. Amazon S3 – виртуальный накопитель, доступ к которому осуществяется через веб-сервис. Как и SCCRK, Amazon предоставляет ПО для всех уровней построения облака. Новая разработка Amazon – CCI(Cluster Compute Instances) – предназначена для перенесения присущих облачному подходу масштабируемости и гибкости в область высокопроизводительных приложений. Компания представила классический Grid продукт, основанный на облачных технологиях – он представляет собой переход от Cloud к Grid –
ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ
PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»
VOL.II, IZHEVSK, NOVEMBER 8–12, 2011
явление, обратное обычной эволюции от Grid к Cloud. По сути, в аренду сдаются мощности большого числа стандартных стоечных серверов. При этом сохраняется возможность в любой момент подключить дополнительные узлы и гарантируется высокая скорость обмена данными (до 10 Гбит/с) между всеми узлами. Пока в семейство Cluster Compute Instances входит только одно решение – Cluster Compute Quadruple Extra Large. Его характеристики таковы: 23 Гб оперативной памяти, 33 стандартных узла EC2 с двумя четырёхъядерными процессорами Intel Xeon X5570 на базе микроархитектуры Nehalem и 1690 Гб дискового пространства. В качестве ОС по умолчанию используется CentOS Linux.
Terremark предлагает облачные решения на базе партнерской программы
VMware"s vCloud Express. В основе сервисов компании GoGrid лежат технологические решения на базе гипервизора Xen для запуска веб-
приложений. Joyent предлагает решения на базе Twitter.com. Microsoft Windows
Azure – сервис IaaS. Основной целью и задачей, поставленной перед сервисом, является тотальная интеграция ОС Windows и всего, что с ней связано, в облачную среду. Облачное решение Google App Engine на базе массивной и отказоустойчивой инфраструктуры и OpenSource стандартов и технологий предоставляет платформу для разработки и запуска приложений в их информационной среде.
NewServers предлагает целиком реальные серверы как сервис для тех пользователей, которые сомневаются в качестве обслуживания и производительности виртуальных сред, но которым необходимы все преимущества облачных технологий. Savvis заявляет высокий уровень обеспечения безопасности в их облачных сервисах как привлекательный фактор для корпоративных заказчиков, которые планируют использовать облачные решения.
Приведённые сведения далеко не исчерпывают рынок внешне разнообразных решений. Общей уязвимостью всех предложений является уже упомянутое утверждение, что Интернет способен удовлетворить все потребности пользователя, так как Интернет сам по себе уязвим во многих отношениях. При этом пользователи обычно даже не думают о том, что по экономическим соображениям используемые провайдерами серверы физически нередко находятся на территориях других государств. То есть немаловажным фактором, имеющим значение для безопасности, о чём также было сказано, является коммерческий характер предоставления облачных услуг, что, вопервых, не способствует вскрытию проблем, которые могут возникнуть у потребителей, особенно неквалифицированных, и, во-вторых, затрудняет доступ к объективной информации, в частности по статистике инцидентов.
(http://www.gazeta.ru/interview/nm/s3680945.shtml) директора по стратегическому развитию «СКБ Контур»: «Слово «облако» мы стараемся не употреблять, потому что пользователь его боится».
ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ
PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»
VOL.II, IZHEVSK, NOVEMBER 8–12, 2011
1. Проблемы безопасности облачных вычислений
Таким образом, первый аспект проблемы безопасности в облачных вычислениях состоит в недостаточной исследованности, определённости и разнородности факторов риска (уязвимостей, угроз и т.д.), сложности структуры их взаимодействия.
Кроме того, проблему обеспечения безопасности в технологиях облачных вычислений приходится рассматривать с двух точек зрения: провайдера услуг и пользователей «облачных» сервисов. Может показаться, что они должны совпадать, т.к. обе стороны заинтересованы в одном и том же результате – безопасности сервисов. Однако на самом деле мотивы, цели и понимание процессов у сторон разные, даже противоположные в некотором смысле, и, следовательно, различаются их модели рисков.
Точка зрения пользователя, его понимание безопасности определяется отчуждением от контроля не только технологических, но и собственных информационных ресурсов, что совершенно естественно порождает в той или иной мере недоверие относительно безопасности предоставляемых услуг. Основные вопросы, которые должны возникать у пользователя (но не обязательно возникают) таковы: как и в какой мере обеспечена сохранность хранимых данных и защита данных при передаче; каковы процедуры аутентификации пользователей и насколько они надёжны; как обеспечена изоляция пользователей в «облаке»; как обрабатываются и какова реакция на инциденты; наконец, каким образом обеспечена и соблюдается нормативноправовая чистота оперирования с данными, в частности с юридически значимыми. Прозрачные ответы на эти вопросы провайдер дать не может.
Последнее обстоятельство порождает специфические препятствия к внедрению «облачных» услуг в правительственные организации – в частности, это проблема безопасности обработки персональных данных граждан в «облаке». Более того, правовые нормы не позволяют перенести в «облака» ряд приложений eGovernment. Поэтому главной задачей провайдера для снижения коммерческого риска является доказательство доверия к «облачным» услугам, поскольку сервисы безопасности в технологиях облачных вычислений декларируются, но практически не проверяемы со стороны пользователя.
Таким образом, ещё один необходимый аспект рассмотрения проблемы безопасности в облачных вычислениях определяется наличием двух взаимозависимых, но не равноправных и не равно ответственных субъектов отношений с несовпадающими целями безопасности.
Проблему безопасности, доверия в облачных вычислениях следует также рассматривать не только относительно настоящего времени, но, что важнее, в контексте тенденции неизбежного распределения и виртуализации ресурсов, этапом развития которой данная технология является. Следовательно, проблему необходимо исследовать с учетом перспективы, когда она еще более усложнится, то есть выявлять, прежде всего, фундаментальные факторы риска.
ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ
PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»
VOL.II, IZHEVSK, NOVEMBER 8–12, 2011
Можно предположить, что нынешняя беззащитность рядового пользователя Интернета лишь слабое подобие возможных проблем при массовой стихийной миграции в коммерческие «облака».
Итак, облачные вычисления, являясь новой методикой доставки ИТ-услуг, имеют ряд особенностей, которые одновременно и упрощают обеспечение безопасности, и предполагают дополнительную оценку рисков как традиционных (в смысле целостности, конфиденциальности и доступности), так и связанных с физическим отчуждением активов от владельца, в том числе юридически значимых. Соответственно, проблема безопасности «облачных» услуг не может считаться только технической и должна рассматриваться и решаться комплексно с учётом разнородных и противоречивых факторов. В итоге она сводится к проблеме доверия и отсутствия практических средств, способствующих повышению его уровня.
Кроме того, проблему безопасности, доверия в облачных вычислениях следует рассматривать в контексте тенденции распределения и виртуализации ресурсов, как отмечалось выше, этапом развития которой данная технология является. Собственный опыт по анализу рисков GRID-технологий, которые в силу своей функциональности и не публичного применения менее чувствительны с точки зрения безопасности, и риски в них имеют преимущественно технический характер, показал, что даже эта задача не проста. Тем более возникнут новые проблемы и усложнится задача анализа рисков в недалёкой перспективе по мере развития технологий и распространения «облачных» и других подобных услуг. Они становятся все более популярными, особенно в последнее время, когда ограниченность финансовых ресурсов вынуждает компании оптимизировать затраты.
По оценкам аналитиков, рынок облачных услуг в 2009 г. составил около 17 млрд долл., а к 2013 г. достигнет 44,2 млрд. Согласно по данным Ассоциации аудита и контроля информационных систем (ISACA), опросившей свыше полутора тысяч организаций более чем в 50 странах Европы, Ближнего Востока и Африки, 33% ИТ-менеджеров уже успешно применяют «облачные» технологии. Однако одна пятая респондентов по-прежнему считает, что риски от внедрения «облаков» перевешивают их преимущества. Более 18% ИТпрофессионалов надеются воспользоваться облачными вычислениями в будущих проектах, а другие 18% пока не определились с какими-либо планами. Оставшиеся 63% не намерены адаптировать «облачные» подходы в своих компаниях. Всего 9,4% ИТ-специалистов в настоящий момент планируют прибегнуть к «облачным» службам для обеспечения работы критических приложений, хотя около двух третей (63%) организаций согласны взять на себя связанные с ИТ бизнес-риски, а 12,1% компаний готовы крупно рисковать, надеясь на максимальную отдачу. На вершине приоритетов у 58% респондентов – защита конфиденциальных данных в «облаках».
Принимая во внимание, что значительная часть «облачных» сервисов востребована в Европе (971 млн евро в 2008 г., до 6,005 млрд – в 2013 г.),
ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ
PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»
VOL.II, IZHEVSK, NOVEMBER 8–12, 2011
Европейское агентство по сетевой и информационной безопасности (European Network and Information Security Agency, ENISA) исследовало риски, связанные с такого рода сервисами. Оценка безопасности облачных вычислений проводилась с учетом трех основных тенденций и сценариев: 1) миграции среднего бизнеса на «облачные» сервисы, 2) влияния облачных вычислений на устойчивость обслуживания, 3) использования облачных вычислений в системах eGovernment, eHealth и прочих социально значимых масштабных проектах. Многие аналитики, в том числе специалисты Gartner, отмечают, что важнейшими аргументами за миграцию на «облачные» сервисы являются снижение стоимости и высокая масштабируемость, а наибольшее беспокойство вызывают вопросы конфиденциальности информации и ответственности за инциденты с используемой инфраструктурой.
Одним из очевидных рисков безопасности облачных вычислений эксперты считают потерю управляемости, ведь клиент передает отдельные рычаги управления ИТ-системой провайдеру, а соглашения об уровне обслуживания зачастую не содержат обязательств, связанных с безопасностью. Более того, действия провайдера, не всегда прозрачные, могут вызвать дополнительные сложности в части соответствия стандартам. К тому же пока предлагается не так много инструментов, процедур, стандартных форматов интерфейсов, которые гарантируют переносимость данных, приложений и служб. Это усложняет (даже в теории) миграцию от одного провайдера к другому либо на собственные ИТ-ресурсы и провоцирует возникновение зависимости.
Впрочем, если риски, связанные с деятельностью провайдеров, в какой-то мере можно отследить еще на этапе выбора поставщика услуг, то технологически обусловленные недостатки систем облачных вычислений обойти вряд ли удастся. Прежде всего, любая крупная система представляет собой желанную цель для разного рода злоумышленников, и, хотя вероятность пробить усиленную защиту меньше, чем в случае малых систем, ущерб от них может оказаться гораздо серьезнее. Поскольку ключевым моментом облачных вычислений является совместное использование ресурсов, возникают риски отказа механизмов изоляции хранилищ, памяти, маршрутизации разных арендаторов.
Остро стоит и вопрос защиты данных – во-первых, доступ к интерфейсам управления и данным осуществляется через Интернет, а системы удаленного доступа, как и браузеры, имеют собственные уязвимости. Во-вторых, пользователю сложно проверить практику работы с данными у провайдера, особенно если деятельность связана с интенсивным обменом информацией. И в-третьих, запрос на удаление данных, как правило, не подразумевает их полного физического уничтожения; периодическая очистка хранимых копий также не всегда возможна, что означает бóльшие риски для клиента, чем при работе с собственным оборудованием. Ну и, разумеется, нельзя сбрасывать со счетов человеческий фактор – в случае облачных вычислений
ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ
PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»
VOL.II, IZHEVSK, NOVEMBER 8–12, 2011
несанкционированная деятельность инсайдеров может привести к особо тяжелым последствиям, а надежной защиты от этого не предвидится.
Универсальных средств пока нет и от других угроз, тем не менее европейские эксперты разработали ряд рекомендаций по минимизации рисков, связанных с миграцией на облачные вычисления, предполагающих четкое разделение сфер ответственности клиента и провайдера в вопросах безопасности. Квалификация разработчиков политик безопасности, технические механизмы и процесс управления рисками, уровень тестирования сервиса, возможности вендора по выявлению непредвиденных уязвимостей и мониторингу аномальной активности, соответствие регуляторным требованиям, возможности провайдера по хранению и обработке данных в рамках определенной юрисдикции, изоляция данных, средства обеспечения непрерывности бизнеса – вот основные факторы, на которые необходимо обращать внимание при миграции в «облака». Государственным структурам необходимо убедиться еще и в том, может ли провайдер предоставить исчерпывающую информацию и контроль за текущим физическим размещением данных, поддерживает ли он принятую схему их классификации, гарантирует ли полную изоляцию ресурсов клиента (т.е. без совместного использования физических компьютеров), поддерживается ли двухфакторная аутентификация и выполняет ли провайдер требования спецификаций ISO
На рисунке 2, приведённом в , иллюстрируются некоторые аргументы «за» и «против» применения технологий облачных вычислений.
Рис. 2. Облачные вычисления: «за» и «против»
Как полагают эксперты, облачные вычисления, предлагающие существенные изменения в подходах к реализации бизнеса, нуждаются в адекватных инструментах оценки рисков, позволяющих выявить и установить уровни потенциальных опасностей по отношению к технологическим
ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ
PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»
VOL.II, IZHEVSK, NOVEMBER 8–12, 2011
преимуществам. Таким образом, чтобы полностью задействовать технологический потенциал облачных вычислений, требуется обеспечить надлежащий уровень информационной безопасности и доверия, но для этого надо уметь, прежде всего, идентифицировать и оценивать риски.
2. Постановка и подход к решению задачи риск-анализа облачных вычислений
В соответствии с представленным выше состоянием проблемы задача рисканализа облачных вычислений в общем виде ставится пока следующим образом. Требуется адекватная сложности и неопределённости проблемы методика анализа рисков и способные к адаптивному развитию инструментальные средства, позволяющие в соответствии с целями комплексной безопасности потребителя выявлять, определять и структурировать разнородные факторы риска облачных вычислений, получать количественные оценки их значимости, а также эффективности мер и средств противодействия для поддержки принятия обоснованных целенаправленных решений, способствующих повышению уровня безопасности и доверия облачных сервисов. В качестве задачи-минимум рассматривается разработка риск-модели облачных вычислений, соответствующей указанным выше требованиям и возможностям, на базе функционально достаточного программного инструментария, без возможности тиражирования, но обеспечивающей повторяемость и верифицируемость результатов.
При этом понятно, что в силу отсутствия систематизированных источников информации и потенциальной сложности поставленной задачи, нельзя сразу рассчитывать на полноту представления модели, тем более что наш подход ориентирован на развитие технологии моделирования и накопление информации. Однако даже в минимальном варианте планируется получить безусловно новую информация, так как подобных исследований в отношении облачных вычислений ещё не проводилось. Ранее нами делались аналогичные оценочные расчеты по анализу рисков в рамках программы фундаментальных исследований Президиума РАН: «Проблемы создания национальной научной распределенной информационно-вычислительной среды на основе развития GRID-технологий и современных телекоммуникационных сетей». Однако поставленная задача, если не ограничивать её, например, только технической прагматикой или, наоборот, вполне уместным экономизмом, а рассматривать в комплексе всех аспектов, выглядит более нетривиальной.
Используемый нами подход к решению задачи можно рассматривать в классе экспертных систем анализа информационных рисков, но он имеет некоторые преимущества перед ними, особенно если речь идёт о сложных, недостаточно определённых информационных объектах . Поэтому данный подход использовался и в других предметных областях.
ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ
PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»
VOL.II, IZHEVSK, NOVEMBER 8–12, 2011
В качестве структурной основы модели анализа рисков и алгоритмизации методики идентификации профиля рисков в нашем подходе используется метамодель , допускающая различные содержательные и алгоритмические интерпретации.
Она построена на дихотомической оппозиции: «защищаемый объект» – потенциально враждебная «среда» в широком смысле этих слов. Подчеркивается необходимость фиксации «границы объекта», или, функционально, – «границы ответственности», и «внешней границы среды», ограничивающей зону досягаемости для противодействия факторам риска.
Элементы модели определяются в терминах трех категорий: субъектов, объектов и воздействий первых на вторые. Столь общая квалификация элементов позволяет использовать модель в более широком спектре исследований. Соответственно категориям выделяются три непересекающихся
«угрозы» нарушения безопасности – множество M e (threat events), в котором
выделяется подмножество так называемых «событий риска» – угроз, непосредственно наносящих ущерб объекту;
«компоненты» объекта – множество M c (components).
На множестве M 0 определяется хотя бы один тип отношений: бинарное
отношение причинности R со свойством транзитивности, к которому можно свести многие связи, имеющие импликативный характер.R упорядочиваетM 0
и задает на нем структуру, фиксирующую каналы распространения потоков угроз от источников до объекта, и порождает квадратную матрицу отношений
W 0.
Цель реализует «система защиты информации» – СЗИ, или, в общем случае, сиcтема защиты противодействия факторам риска, которая представима в виде множества элементов S , каждый из которых осуществляет воздействие на элементы изM 0 . Между элементами множествS иM 0 устанавливается
отношение, формально подобное R , порождающее прямоугольную матрицу отношенийR 0 .
На рисунке 3 показана простая иллюстрация такого представления метамодели.
ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ
PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»
VOL.II, IZHEVSK, NOVEMBER 8–12, 2011
Рис. 3. Структурная схема метамодели
Источники угроз из M s считаются генераторами потока событий (угроз), распространяющегося по каналам, заданным отношениемR наM 0 . Элементы
представляющих события риска, формируется поток угроз, непосредственно воздействующий на объект в составе M c . Тогда средства защиты изS можно
интерпретировать как фильтры.
Роль условного элемента z , соответствующего состоянию объекта в целом, как преобразователя, ограничивается функцией сумматора-интегратора. Тогда на выходеz можно фиксировать результирующий потокf T , интеграл от
которого по некоторому интервалу времени является, по сути, мерой риска для объекта, измеряемого ущербом, наносимым ему за это время.
Простейшая количественная интерпретация метамодели, предполагающая линейный характер отношений в W 0 , отображает ее в арифметическую
матрицу W (w ij ) , элементы которой можно рассматривать как весовые
коэффициенты, имеющие смысл меры влияния i -го элемента наj -й. Она
содержит все исходные данные для расчетов на модели, полученные и представленные тем или иным способом.
с учетом транзитивности R . В результате определяется матрицаV , структурно эквивалентнаяW . При отсутствии рефлексии элементов, еслиW считать взвешенной матрицей смежности некоторого графа, они легко рассчитываются на графе в соответствующих терминах как суммы по всем путям изi -й вj -ю
ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ
PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»
VOL.II, IZHEVSK, NOVEMBER 8–12, 2011
вершину произведений оценок дуг каждого пути, что равносильно матричному преобразованию V (I W )1 I .
Однако в общем случае такой расчет не возможен, и тогда V рассчитывается с использованием аппарата марковских цепей следующим образом. ИзW исключается левый блок нулевых столбцов, соответствующих множествуM s , выделяются верхний горизонтальный блок в виде матрицыW s
V e det(D e )(D e 1 ).
Последний, всегда не содержащий нулей, z -й столбецv z матрицыV содержит искомые показатели {v iz } влияния любогоi -го фактора риска на
безопасность объекта. Эти показатели должны целенаправленно ориентировать создание системы защиты на противодействие наиболее значимым факторам риска.
Для получения количественной оценки результативности системы защиты матрица R 0 также арифметизируется, а соответствующая матрицаR (r kj )
содержит оценки воздействия k -го элемента СЗИ наj -й фактор риска. Далее
она преобразуется в вектор r , гдеr j 1 (1r kj ) , или дополняющий
его u ,u j 1r j ,r j 1,u j 0 , представляющие совместное действие элементов системы защиты. Тогда общий показатель её результативностиr z
рассчитывается | следующим | Во-первых, | определяется | ||||||||||||||||
W (I- diag (u | )W )1 | Где u | – части вектора | u с компонентами, |
|||||||||||||||
относящимися | соответственно | к элементам | множества | M s и | остальным |
||||||||||||||
элементам из М e , далее, используя композицию | ν {e s ;ν s }, гдеe s – вектор, |
||||||||||||||||||
состоящий | единиц порядка, | количеству | элементов | в M s , |
|||||||||||||||
определяется | r z(v r ) v z, | обозначает | операцию |
||||||||||||||||
поэлементного умножения векторов. | |||||||||||||||||||
отображает | взаимодействие | элементов |
|||||||||||||||||
моделируемой системы, учитывая трудно предсказуемые мультипликативные эффекты удаленных косвенных влияний и циклических связей, являясь одновременно относительной оценкой изменения интегральной характеристики результирующего потока угроз.
Факторы риска можно также связать с физическими объектами, задав множество P , представляющее оборудование, физические среды, персонал и
защиты получить оценки значимости оборудования в отношении безопасности системы.
В нынешнем состоянии методика существенно усовершенствована с точки зрения представления исходных данных . Они не обязательно числовые, допускается нечёткость, в том числе отношений, и неполнота, а результирующие оценки получаются в стохастическом виде, что способствует большему доверию к ним.
Первым и наиболее сложным этапом в данном подходе при построении риск-модели облачных вычислений является не формализуемый содержательный анализ документации и литературных источников в качестве экспертных знаний для выявления множества актуальных факторов риска. Как уже отмечалось, эта работа не тривиальна, но в любом выполненном объёме имеет позитивный результат с точки зрения накопления информации, на данном этапе мы сейчас находимся. Последующие операции по структурированию множества (таксономическому и логическому), оценочные и расчётные, ведутся уже в автоматизированном режиме, они вариативны и направлены на получение прикладных результатов.
Заключение
Технологии облачных вычислений являются очередным и не последним этапом развития тенденции на распределённость и виртуализацию информационных и технологических ресурсов, которая стала заметной по крайней мере с 70–80-х годов прошлого столетия. Достаточно вспомнить в связи с этим вычислительные сети коллективного пользования тех лет на базе территориально удалённых мэйнфрэймов. Проблемы безопасности таких технологий стояли всегда, хотя и не всегда формулировались явным образом в терминах безопасности, так как это были проблемы профессионалов и для профессионалов, число которых было относительно невелико. Они были вполне конкретны, лишены субъективизма, лежали в организационнотехнической плоскости и решались соответствующими средствами.
Развитие и массовая доступность компьютерных сетей общего доступа породило и продолжает порождать всё новые проблемы сетевой безопасности, касающиеся уже практически всего активного населения, и большинство из них давно вышло за пределы узкотехнических аспектов, стали гуманитарными или социо-техническими. Проведём аналогию: безопасность GRID-технологий как предшествующего этапа развития рассматриваемого направления также была, скорее, технической проблемой, касающейся ограниченного количества специалистов участников GRID-проектов. Теперь же «облака» с учетом перспективы развития данного направления ИТ-услуг переводят проблемы безопасности технологий распределения и виртуализации ресурсов в
публичную плоскость, и, соответственно, решаться они должны уже в комплексе, исходя из разных, в том числе противоречивых, интересов.
Разработанная нами методика, алгоритмы и инструменты, ориентированные на анализ рисков для сложных, недостаточно определённых объектов различной природы, позволяющая проводить анализ рисков в условиях, свойственных для новых систуаций неполноты и гетерогенности исходных данных с получением стохастического профиля рисков, является адекватным средством по решению поставленной задачи. В рамках создания предметно-ориентированных риск-моделей проведены предварительные расчеты с использованием технологии удаленных параллельных вычислений, что может найти применение и в сервисах облачных вычислений.
Список литературы
1. Hewitt C. ORGs for Scalable, Robust, Privacy-Friendly Client Cloud Computing // IEEE Internet Computing, 2008, vol. 12, no. 5, p. 96–99.
2. Черняк Л. Безопасность: облако или болото? // Открытые системы. СУБД, 2010, № 1, c. 16–19.
3. Security Guidance for Critical Areas of Focus in Cloud Computing V2.1.
Copyright © 2009 Cloud Security Alliance, 76 p. URL: https://cloudsecurityalliance.org/csaguide.pdf (дата обращения 29.08.2011).
4. Youssef L. et al. Toward a Unified Ontology of Cloud Computing.
5. Дериева Е. «Облака»: преимущества и риски безопасности // Компьютерное
6. Стрельченко Ю. ИТ-специалисты прибегают к «облачным» вычислениям, несмотря на риски [Электронный ресурс] 24.03.2010. URL: http://net.compulenta.ru/517328 (дата обращения 29.08.2011).
7. Шишкин В.М. Сравнительный анализ методик комплексного оценивания рисков в информационных системах // Региональная информатика (РИ2010) / XII Санкт-Петербургская Международная конференция. СанктПетербург: СПОИСУ, 2010, c. 150.
8. Шишкин В.М. Метамодель анализа, оценки и управления безопасностью информационных систем // Проблемы управления информационной безопасностью: Сборник трудов ИСА РАН / Под ред. Д.С.Черешкина. Москва: Едиториал УРСС, 2002, c. 92–105.
9. Shishkin V.M., Savkov S.V. The Method of Interval Estimation in Risk-Analysis System // Proceedings of the Second International Conference on Security of Information and Networks. Famagusta, North Cyprus: New York: ACM, 2009, p. 3–7.
10. Шишкин В.М., Савков С.В. Методика арифметизации неполной
системах: Труды Международной научной школы МА БР – 2010. СанктПетербург: ГУАП, 2010, с. 295–300.
ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ
PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»
VOL.II, IZHEVSK, NOVEMBER 8–12, 2011
