IDC: Опасности "облачных вычислений" несколько преувеличены

image

Теги: облачные вычисления, cloud computing, IDC, безопасность

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

Когда речь заходит об "облачных вычислениях", то ИТ-менеджеры в первую очередь упоминают о возможных проблемах с безопасностью корпоративных данных. Аналитики IDC считают, что эти опасения не всегда обоснованы.

Согласно одному из последних отчетов IDC, эта опасность "облачных вычислений" может оказаться несколько преувеличенной. Дело в том, что безопасность данных - крайне важный аспект корпоративной ИТ-инфраструктуры. Однако аналитики IDC сомневаются, что одна отдельно взятая компания сможет обеспечить такой же уровень безопасности, как, например, такие cloud-провайдеры, как Amazon Web Services или Salesforce.com.

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


или введите имя

CAPTCHA
онаним
20-02-2009 10:25:12
покупайте наших слонов (с) уже незнают как впарить сей продукт...
0 |
этоттам
20-02-2009 10:40:21
а чего им впаривать? Google - продает свои железки и мигрирует на Amazon EC2. Hadoop, Joomla, Oracle - давно уже в виде appliances на EC2. Windows Server? от $0.50 за час. Потребители сами к ним идут.
0 |
20-02-2009 13:26:36
Потребители сами к ним идут.Да что с этих дураков взять...
0 |
этоттам
20-02-2009 17:52:40
да-да, что с тебя взять, если ты не понимаешь, что cloud computing дешевле по капитальным затратам по сравнению с обслуживанием собственного сервера, или не дай бог целого ДЦ. Те цены, которые Amazon и ElasticHosts предлагают на свои cloud VMs - это очень даже конкурентоспособная цена. (от $0.10 до $3.20в зависимости от ограничений и софта). Смысл покупать железку за $3000 и ОС за $15000 когда она будет работать вполсилы например раз в месяц, рассчитывая OLAP-куб из данных 1Ски? Она еще и окупить себя должна ведь, а капитальные затраты ой какие получаются. А в случае с Cloud - просто запустил штук 50 серверов, распараллелил задачу на них - и кури отдыхай.
0 |
20-02-2009 10:42:58
только столман один боится что он уязвим - он как анатолий вассерман видимо все вычисления в голове производит ))
0 |
20-02-2009 13:29:02
Не совсем так. У Вассермана распределенный мозговой кластер, его отдельные элементы находятся не только в голове, но и в других частях тела, а также в жилетке.
0 |
Физек
20-02-2009 10:43:03
а если я хочу расчитать последствия атомного взрыва мне позволят? или мне пс3 покупать вагон?
0 |
svr4
20-02-2009 11:14:05
для рассчёта таких вещей как ядерный взрыв, достаточно ENIAC или 8-битного калькулятора.
0 |
Bortian
20-02-2009 12:14:04
Гыыыыыыыыы. Может, ты даже в уме рассчитаешь? Каптча со мной: 11666
0 |
sgib
20-02-2009 15:35:33
Да опасность всегда существует при передаче на сторону своих данных...
0 |
Bugg
20-02-2009 20:03:11
Однако аналитики IDC сомневаются, что одна отдельно взятая компания сможет обеспечить такой же уровень безопасности, как, например, такие cloud-провайдеры, как Amazon Web Services или Salesforce.com.У "таких cloud-провайдеров" безопасность зиждется на принципе security throug obscurity, пока не доказано обратное. Ибо предлагается слепо доверять, не имея возможности проверить на надежность/безопасность даже бинарный код ПО кластера, как в случае с "традиционным" закрытым ПО. "Аналитики IDC" в данном случае судят о безопасности сферического коня в вакууме, слепо апеллируя к авторитетам. Междустрочный смысл следующий: "Неуловимые джо средней руки зря беспокоятся, ибо никто не позарится на их, никому не нужные, данные и бизнес-процессы. Приобщайтесь, товарищи, и не слушайте технарей - они не полагаются на авось и потому неадекватны."
0 |
этоттам
21-02-2009 08:33:15
Иногда лучше жевать чем говорить. Ты бы не орал, если не знаешь. Во-первых, никакого "бинарного кода кластера" не существует. За исключением blade-ов с Xen или KVM, на которых запускаются образы. И frontend-серверов с web-сервисами, через которые идет управление виртуалками. Во-вторых - ты запускаешь собственный дисковый образ. Залитый на хранилище провайдера в зашифрованном и подписанном виде. А гипервизор его перед запуском проверяет. В-третьих - управление машинами идет через HTTPS, с обязательным предъявлением сертификата сгенеренного, или залитого на аккаунт грида. И HMAC запроса. В-четвертых - тебе никто не мешает внутри образа и подключаемых разделов использовать шифрующие ФС, а для доступа к VM - шифрующие протоколы. А в пятых - доступ к VM открыт только по определенным портам, которые конфигурируются перед запуском в виде группы безопасности файрволла. Учи матчасть, сынок. Никакой obscurity, все прозрачно.
0 |
ykov
21-02-2009 23:52:41
"Во-вторых - ты запускаешь собственный дисковый образ. Залитый на хранилище провайдера в зашифрованном и подписанном виде. А гипервизор его перед запуском проверяет. " при этом надо отдать провайдеру ключи, чтобы гипервизор мог проверить и запустить. а потом вспомнить, что все ВМ умеют делать снапшоты на лету и хорошее API для доступа к данным (фс) в образе или во время исполнения. ну и почитать по поводу автоматического копирования данных и программ на разные узлы (для сохранности) тоже полезно. А в общем правильно - все прозрачно. Даром что на действующих гридах уже давно идет разговор о плохой защите данных - ибо это не позволяет проводить исследования в медицине. приваси пациентов не обеспечивается.
0 |
этоттам
22-02-2009 08:02:50
при этом надо отдать провайдеру ключи, чтобы гипервизор мог проверить и запустить. если речь идет о EC2 - там ключи депонированы. генерятся при регистрации. это уже вопрос скорее регламента, а не технический. снэпшоты делать - никакого смысла. лишнее дисковое пространство тратить. более того - после останова образа он откатывается. Даром что на действующих гридах уже давно идет разговор о плохой защите данных - ибо это не позволяет проводить исследования в медицине. приваси пациентов не обеспечивается. пруфлинк или не было.
0 |
ykov
22-02-2009 22:27:48
например http://gridclub.ru/library/publication.2008-09-23.2364715334/
0 |
этоттам
23-02-2009 19:05:41
там ни слова про Xen. И, да - пользуйтесь внутри виртуалки BitLocker-ом, FreeOTFE, BestCrypt-ом, или шифрующими ФС.
0 |
Bugg
24-02-2009 12:59:21
Иногда лучше жевать чем говорить.Вот именно. Ты бы не орал, если не знаешь.Я спокойно высказал свое мнение. А тебе бы вежливости поучиться. Во-первых, никакого "бинарного кода кластера" не существует. За исключением blade-ов с Xen или KVM, на которых запускаются образы. И frontend-серверов с web-сервисами, через которые идет управление виртуалками.Перефразирую: никакого "бинарного кода кластера" не существует, за исключением кода всего ПО виртуализации и управления. При этом полностью отсутствует возможность этот бинарный код проверить или заменить. Во-вторых - ты запускаешь собственный дисковый образ. Залитый на хранилище провайдера в зашифрованном и подписанном виде. А гипервизор его перед запуском проверяет.Происхождение и целостность образа никакого значения не имеет. Есть 1. виртуальная машина, неподконтрольная клиенту и недоступная для анализа, и 2. провайдер услуги имеет полный доступ к памяти клиентской ОС в ВМ. В такой ситуации всегда существует опасность повышения злоумышленником своих привилегий на кластере (компрометации виртуализатора) или злоупотребление провайдером своими техническими возможностями для хищения данных из памяти ОС клиента внутри ВМ. В-третьих - управление машинами идет через HTTPS, с обязательным предъявлением сертификата сгенеренного, или залитого на аккаунт грида. И HMAC запроса.Ты забыл о недавних уязвимостях в OpenSSL и GnuTLS, позволявших проводить MitM-атаки на сессию. Забыл о недавней компрометации всей PKI интернета из-за безответственного поведения одного из реселлеров Comodo. Брюс Шнайер время от времени пишет о недостатках PKI интернета. Рекомендую почитать. В-четвертых - тебе никто не мешает внутри образа и подключаемых разделов использовать шифрующие ФС, а для доступа к VM - шифрующие протоколы.Ключи храняться в памяти ОС внутри ВМ. Нечестный провайдер может прочесть ключ из памяти, как может его прочесть и злоумышленник, повысивший свои привилегии до уровня гипервизора. Грош - цена такому шифрованию. А в пятых - доступ к VM открыт только по определенным портам, которые конфигурируются перед запуском в виде группы безопасности файрволла.Ерунда, не стоящая даже упоминания. Учи матчасть, сынок.Говори себе эту фразу каждый раз, когда засвербит нагрубить кому-нибудь в комментах. Глядишь, и начнешь "учить матчасть" и понимать, что к чему. Никакой obscurity, все прозрачно.А черное - это белое. там ни слова про Xen.http://xforce.iss.net/xforce/xfdb/42387 И, да - пользуйтесь внутри виртуалки BitLocker-ом, FreeOTFE, BestCrypt-ом, или шифрующими ФС.Чушь.
0 |
этоттам
24-02-2009 18:11:16
Перефразирую: никакого "бинарного кода кластера" не существует, за исключением кода всего ПО виртуализации и управления. При этом полностью отсутствует возможность этот бинарный код проверить или заменить. угу. делай свой cloud. с блэкджеком и шлюхами. а еще полезно немного подумать. единожды скомпрометированный cloud-провайдер потеряет существенную часть клиентов. Это так сказать маркетингово-психологическая гарантия. Ну и вообще-то означенные решения строятся на FOSS-продуктах. Анализатор исходников в зубы и вперед, профессиональный параноик. Есть 1. виртуальная машина, неподконтрольная клиенту и недоступная для анализа,Я же говорю - учи матчасть. Машина мало того, что ИЗГОТОВЛЕННАЯ и ЗАЛИТАЯ клиентом самостоятельно в большинстве случаев. Так еще и откатываемая после останова. и 2. провайдер услуги имеет полный доступ к памяти клиентской ОС в ВМ. И толку? Посчитай оверхед на мониторинг и анализ памяти VM. Это подозрительный признак для любой IPS. В такой ситуации всегда существует опасность повышения злоумышленником своих привилегий на кластере (компрометации виртуализатора)Сложно искать черную кошку в темной комнате. Очень. Очень шаткий путь. или злоупотребление провайдером своими техническими возможностями для хищения данных из памяти ОС клиента внутри ВМ.Да-да. сохранять снэпшот каждого mov src, [memptr] а потом давать миллиону китайцев на разбор. Отсыпь что куришь? Про оверхед вносимый закладкой мониторинга памяти и ввода-вывода, и несовместимость с production-сервисами я уже выше написал. Ты забыл о недавних уязвимостях в OpenSSL и GnuTLS, позволявших проводить MitM-атаки на сессию. Недавняя - это менее месяца. Насколько я помню, последние атаки на OpenSSL/GnuTLS датировались аж серединой 4 квартала прошлого года. Учитывая оперативность багфиксинга FOSS-вендоров можно сказать что это толстый троллинг. Минус один.Забыл о недавней компрометации всей PKI интернета из-за безответственного поведения одного из реселлеров Comodo. А с каких это пор халатность одного реселлера влият на безопасность всей распределенной PKI, имеющей около десятка УЦ только в зоне .com? Брюс Шнайер время от времени пишет о недостатках PKI интернета. Рекомендую почитать. И тем не менее, ничего лучше Twofish-а он не написал. Нормальная у интернета PKI. Главное - децентрализованная. Ерунда, не стоящая даже упоминания.Ойли? С каких это пор существенные компоненты безопасности типа firewall-а стали ерундой? Минус два. ttp://xforce.iss.net/xforce/xfdb/42387 Минус три. Уязвимость датирована маем 2008. Подревнее ничего не нашлось? Тем более, что тот же Amazon использует сильно незалежный Xen, который собирается ручками после тонкого допиливания надфилями.Цитата И, да - пользуйтесь внутри виртуалки BitLocker-ом, FreeOTFE, BestCrypt-ом, или шифрующими ФС. Чушь. Минус четыре. Заперехватывай зашифрованный ioctl. Ищи ключи в памяти с рандомизацией адресного пространства. Короче, четыре грубых ошибки в анализе рисков. Теперь перемножь вероятности факторов необходимых для успешной реализации атаки хотя бы на один узел виртуализирующего грида. Теоретически - может хоть снег в июле пойти, а практически - увы и ах. Комплексные меры обеспечения безопасности все-таки сильно затрудняют жизнь желающим насрать.
0 |
Bugg
25-02-2009 11:58:02
единожды скомпрометированный cloud-провайдер потеряет существенную часть клиентов. Это так сказать маркетингово-психологическая гарантия.Это заблуждения. Провайдеры могут быть скомпрометированы хоть по нескольку раз на дню. Простор для маневра у них колоссальный: 1. Если взломщик не оставил следов взлома, провайдер и/или клиент может никогда не узнать о факте взлома и способе, которым он был произведен. 2. Если взломщик оставил следы взлома, но следы заметны только провайдеру, провайдер может их скрыть. Если клиент обнаружит утечку данных или признаки взлома, провайдер может предположить, что было скомпрометировано ПО клиента внутри ВМ, и со стороны это действительно может выглядеть более правдоподобным. Ну и вообще-то означенные решения строятся на FOSS-продуктах.Ты со свечкой стоял, когда эти "FOSS-продукты" без изменений компилировали в бинарник и внедряли на кластере? Анализатор исходников в зубы и вперед, профессиональный параноик.Нет никакой паранойи в умении анализировать риски и отличать обоснованную уверенность от необоснованной. Я же говорю - учи матчасть. Машина мало того, что ИЗГОТОВЛЕННАЯ и ЗАЛИТАЯ клиентом самостоятельно в большинстве случаев. Так еще и откатываемая после останова.Виртуальная машина - это совокупность интерфейсов для взаимодействия с виртуализатором. То есть, в некоторой мере синоним слову "виртуализатор", а не операционной системе, запущенной внутри ВМ. Соответственно, клиентом "изготавливается и заливается" не виртуальная машина, а ПО, которое будет в ней запущено. Матчасть ты все равно учить не станешь, поэтому не предлагаю. И толку? Посчитай оверхед на мониторинг и анализ памяти VM. Это подозрительный признак для любой IPS.Сделать слепок памяти - дело секунды, а то и долей секунды - зависит от объема. Сложно искать черную кошку в темной комнате. Очень. Очень шаткий путь.Пустая болтовня. Если там действительно Xen или KVM, то злоумышленник может найти в них уязвимость, путем анализа и тестирования кода, и попытаться эксплуатировать ее внутри своей ВМ. Если же нечто проприетарное - это модель security through obscurity, со всеми ее сомнительными достоинствами и явными недостатками. Да-да. сохранять снэпшот каждого mov src, [memptr] а потом давать миллиону китайцев на разбор.Нет, единожды сделать слепок всей памяти. Идентифицировать ОС и прочее ПО по слепку памяти не составит труда. В случае применения TrueCrypt и прочих известных средств шифрования, получить криптоключи тоже не составит труда. Не говоря уже о том, что сама возможность сделать слепок памяти, практически, открывает пути к хищению любых или всех чувствительных данных, от которого шифрование хранилища не защитит никак. Про оверхед вносимый закладкой мониторинга памяти и ввода-вывода, и несовместимость с production-сервисами я уже выше написал.Глупости ты написал. Недавняя - это менее месяца.А почему не вчера? Учитывая оперативность багфиксинга FOSS-вендоров можно сказать что это толстый троллинг. Минус один.SSL/TLS - это сложный механизм, чья функциональность и безопасность зависит от множества факторов. Этот механизм уже не раз подвергался компрометации, у него есть недостатки. При этом существуют гораздо более простые и надежные средства защиты передаваемых данных, вроде SSH, которые в большинстве случаев могут быть безопасно развернуты и использованы в инфраструктуре, подконтрольной одному из участников обмена защищаемой информацией (клиенту), но не в инфраструктуре провайдеров облачных вычислений, даже если какой-нибудь из них и решит применять SSH вместо SSL/TLS. А с каких это пор халатность одного реселлера влият на безопасность всей распределенной PKI, имеющей около десятка УЦ только в зоне .com?С тех, самых ранних пор, когда браузеры начали и продолжили одинаково доверять всем CA в локальном хранилище. А благодаря скрытому лобби VeriSign против DNSSEC, до сих пор нет механизма проверки соответствия сертификата доменному адресу. То есть, PKI в интернете гораздо слабее и уязвимее, чем может быть. Мало того, что SSL/TLS более сложен и потому, как доказала практика, более уязвим (в сравнении с SSH, например), так еще и применяется, как попало. И тем не менее, ничего лучше Twofish-а он не написал.Не вижу связи между Twofish и "тем не менее". Нормальная у интернета PKI. Главное - децентрализованная.Ненадежная у интернета PKI. А нормальная или нет - дело десятое. Ойли? С каких это пор существенные компоненты безопасности типа firewall-а стали ерундой? Минус два.С тех самых пор, когда ты переоценил банальную фильтрацию портов, отказавшись замечать более серьезные изъяны в ИБ облачных вычислений, которые никакой файрвол не покроет. Уязвимость датирована маем 2008.Я привел пример уязвимости Xen'а, который опровергает любые допущения и заявления об абсолютной защите виртуализаторов вообще и Xen'а в частности. Тем более, что тот же Amazon использует сильно незалежный Xen, который собирается ручками после тонкого допиливания надфилями.Security through obscurity. Минус четыре. Заперехватывай зашифрованный ioctl.Это не требуется. Ищи ключи в памяти с рандомизацией адресного пространства.При наличии слепка всей памяти, это не составит труда. Короче, четыре грубых ошибки в анализе рисков.Да не смеши мои тапки. Я тут, фактически, занимаюсь твоим просвещением. Теперь перемножь вероятности факторов необходимых для успешной реализации атаки хотя бы на один узел виртуализирующего грида.Перемножать вероятности нужно там, где они существуют и играют значительную роль. Перечисли факторы, определи "их вероятность", составь внятный сценарий атаки и обоснуй вероятностный характер успеха ее проведения. Обоснуй невозможность проведения атак по другим сценариям. Тогда посмотрим, посчитаем. Пока же говорить совершенно не о чем. Достаточно одной ошибки в виртуализаторе, позволяющей, хотя бы, чтение памяти по случайным адресам, чтобы получить полный или частичный слепок памяти одного или нескольких узлов. Не вижу причин для исключения риска такой компрометации. А разделяемых характер услуг облачных вычислений определяет то, что злоумышленнику достаточно быть клиентом или заполучить реквизиты клиента, чтобы получить доступ непосредственно к ВМ и начать ее эксплуатацию, минуя стадию взлома SSL, файрволы и прочее.
0 |
Bugg
25-02-2009 12:04:24
Кстати, Sun Microsystems предлагает более серьезные (впрочем, и не идеальные) средства программно-аппаратной виртуализации, но за гораздо более серьезные деньги и для более другой целевой аудитории. Сравнивать есть, с чем.
0 |