15 августа 2012 г.

Не по дороге с облаками

В течение последней недели как-то слишком часто попадаются статьи и заметки про облачные вычисления. Все, как на подбор – негативные, зато от людей и компаний, статус которых требует доверия как минимум. То Стив Возняк озаботится, то Гартнер холодненькой водичкой плесканет, а Наташа Храмцовская про это расскажет.

Периодические всплески интереса к любой теме – дело обычное. Но, почитав последние материалы, поймал себя на стойком déjà vu. Все это писалось и год, и два назад. Одними и теми же словами, применительно к одним и тем же ситуациям. С одной стороны, продавцы облачных сервисов убеждают нас, что корпоративные заказчики уже просто-таки рвутся в облака, с другой – за все эти годы нет ни одного внятного, обоснованного и убедительного ответа на крайне простые, очевидные вопросы:

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

2. Какими конкретно механизмами обеспечивается разграничение доступа к информации в облаке между пользователями всех этих SaaS/IaaS/PaaS и вообще XaaS, кто и как подтвердил их надежность?

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

4. Кто и как управляет ключами шифрования при закрытии канала передачи данных в облако? Почему это не АНБ/ЦРУ/Моссад/ФСБ/BND/MI5-MI6 (список продолжите сами)?

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

5. Кто конкретно и как отвечает за неизменность ваших данных в облаке? Чем это подтверждается?

6. Что вы будете делать, когда у вас не окажется доступа к интернету?

7. Что вы будет делать, когда провайдер откажет вам в услуге?

8. Что вы будете делать, когда ваши данные бесследно исчезнут?

9. Что вы будете делать, когда решите «найти себе другого провайдера, честного» и мигрировать к нему? Как вы перенесете свои данные и перенесете ли вообще?

Все эти годы вдвижения новых сервисов в умы и деньги заказчиков вместо ответов мы получаем то, что классик мировой революции называл эклектической похлебкой – общие слова про колоссальный опыт и ответственность разработчиков, огромное количество специфических облачных решений безопасности, описать которые «в данном интервью (статье, выступлении) не представляется возможным из-за ограничений во времени» (при том, что 95% их – маркетинговая лапша на уши), про неизбежность научно-технического прогресса и светлое будущее аутсорсинга всего, не относящегося к основной деятельности – в частности.

Я сам на всех своих курсах, переходя к разделу аутсорсинга безопасности, говорю о том, что история развития человечества – это история развития аутсорсинга, от первобытно-общинной семьи с забитым мамонтом как основным средством существования через коврики под автомобилями 20 века в воскресные погожие дни к «Check engine. Code 235709» сегодня. Все так.

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

Я не нашел не только 33, но и 3 отличия от того, что происходит сегодня. Для информационных технологий и информационной безопасности с точки зрения нейтрализации возникающих угроз год – период огромный. И если за это время на технологические вызовы нет соответствующей реакции, зато заметен рост агрессивности маркетинга, это неспроста. И у меня, как безопасника, появился новый вопрос. Провайдеры облачных услуг, а как и где заказчик может познакомиться с логами событий безопасности, связанными с его конкретно данными? Они вообще-то есть? И как там с таргетированными атаками, всякими новыми Stuxnet’ами, Flame’мами, Gauss’ами? Ведь красть с колхозного поля всегда легче, чем с личной делянки - оно большое, с чужой картошкой и спать хочется в конце концов.

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

7 комментариев:

  1. ну, собственно, не то ответ, не то коммент - в SLA сервисных провайдеров обычно написано, что они гарантируют услугу 365х24х8 с 2, скажем, часами простоя в год. Но... если же сбой таки произойдет - вам вернут деньги, которые вы заплатили для использования этого сервиса в это время.

    ОтветитьУдалить
  2. SLA - это понятно. Но в Вашем примере - это скорее SLA ЦОДа, а не облачного провайдера, поскольку классическая NIST'овская модель облака предполагает оплату только предоставленного сервиса. Я про безопасность. Например, даже в Вашем примере стоимость простоя всегда существенно меньше выручки от работы сервиса, иначе это для клиента не бизнес вообще.

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

    ОтветитьУдалить
  4. С надтехнической - это как? Я этого не предлагал :-). Я просто предлагаю, прежде чем доверить хранение налика соседу с честными глазами, котррый активно это предлагает, про него чего-нибудь узнать и договориться не по понятиям, а по договору.

    ОтветитьУдалить
  5. Это и есть надтехнический вопрос )) Технически как меня не интересует - меня интересует гарантия и что если что ?

    ОтветитьУдалить
  6. Гарантий пока нет. И даже разумных компенсаций. Дадут пару дней бесплатно за сбой или отказ в обслуживании. И все.

    ОтветитьУдалить
  7. Вот пример скандала с KissMetrics, когда компания используя данные аналитики своих клиентов отслеживала цепочку посещений сайтов уже посетителями сайтов своих клиентов и продавала эти данные рекламным компаниям.

    http://www.wired.com/business/2011/07/undeletable-cookie/

    Поскольку продавать SaaS гораздо выгоднее - помесячная оплата + бОльшая зависимость (согласитесь имея под руками базу данных мигрировать проще) + возможность приторговивать агрегированными данными. KissMetrics поступила нехорошо + её поймали за руку.

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

    Большинство крупных компаний по-моему вообще не думает сильно о том, что может случиться если сисадмин SaaS провайдера может решить подзаработать или обидеться на компанию. Да и потом кто знает какова квалификация тех кто делал архитектуру, настраивал резервное копирование, firewall/Selinux.

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

    ОтветитьУдалить