Облачные вычисления: Первое путешествие в облако

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

Дэн Гриффин и Том Джонс

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

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

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

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

С чего начать

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

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

1. Проверка подлинности пользователей при доступе как к общедоступному облаку, так и к корпоративной среде (в пределах предприятия).
2. Угрозы безопасности и минимизация последствий рисков при использовании общедоступного облака.
3. Соблюдение законодательства и возможности упрощения решения этой задачи за счет реализации «правильной» архитектуры.

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

1. Государственные нормативы, запрещающие перенос через государственную границу информации, составляющей личную или государственную тайну.
2. Медико-санитарная информация, защищаемая HIPAA или аналогичными актами.
3. Хищение персональных данных, в частности, получение доступа к финансовым счетам.
4. Публичное раскрытие личной информации пользователя (PII).
5. Внутрикорпоративные требования к обработке коммерческих секретов.

Вопросы проверки подлинности

Некоторые пользователи облачных сервисов не являются членами корпоративного домена, такого как Microsoft Active Directory. В этом случае облачной службе необходимо агрегировать пользователей разных провайдеров идентичности. А это означает, что правила доступа к облачным ресурсам будут отличаться.

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

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

Служба Windows Azure Access Control (AC) Service является удобным облачным сервисом, который может интегрировать запросы от корпоративного сервера служб федерации Active Directory (ADFS) и внешних провайдеров идентификации, предоставляемых Windows Live, Facebook или другими социальными сетями. Использование облачных сервисов для агрегации данных идентификации предоставляет возможность использовать большое количество языков программирования и многих существующих провайдеров идентификационной информации.

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

Рис. 1 Служба Windows Azure Access Control может стать посредником между локальными и облачными ресурсами

Угрозы безопасности в общедоступном облаке

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

Тем не менее, открытое подключение к Интернету будет создавать новые угрозы. Эти типы угроз появляются за счет демонтажа сети периметра, так что так или иначе, но придется принять соответствующие меры защиты. В любом случае, каждое новое общедоступное облако надо обязательно анализировать на предмет безопасности. Необходимо принять во внимание следующие соображения.

В рамках домена предприятия допускается наличие только состоящих в домене компьютеров. Можно использовать такие механизмы, как Network Access Protection (NAP) и IPsec, чтобы гарантировать, что все компьютеры хорошо известны и надлежащим образом защищены от угроз. Впрочем, эти механизмы можно распространить на облачные ресурсы.

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

Вот некоторые конкретные уязвимые места, которые учитывать в процессе анализа безопасности:

• раскрытие информации или атаки типа «отказ в обслуживании» в общедоступном информационном обмене;
• подмены с посредником (man-in-the-middle) на облачном или на локальном серверах;
• перехват существующих подключений в общедоступном Интернете;
• повторное использование учетных данных облака.

Эти виды атак встречались в предыдущих поколениях корпоративных сервисов. Для анализа угроз, возникающих из-за использования общедоступных облачных сервисов совместно с локальными сервисами (рис. 2), можно использовать потоки данных. Вот три основных типа подключений, которые придется проанализировать:

1. Ни одно из конечных подключений не находится в надежном месте Не существует способа оценить подключение, так что в этом случае для обеспечения целостности сообщения все заявки от провайдера услуг идентификации должны регистрироваться в службе.
2. Одно из конечных подключений расположено в облаке Другое находится на стороне пользователя и управляется корпоративными службами. В этом случае можно защитить подключение с помощью протокола SSL (TLS или HTTPS), по которому можно переправлять идентификационные данные на одно (или оба) конечное подключение — это обеспечит хоть какой-то уровень проверки подлинности, а также защиты данных при переносе через облако. Без возможности проверки идентификационных данных и обоих концах подключения возможны атаки с посредником.
3. Оба конечных подключения находятся в надежном месте Поскольку облако не контролируется предприятием, требуется строгая идентификация на обоих концах соединения. В этом случае потребности в защите обеспечит протокол SSL или IPsec (VPN).

Рис. 2. Анализ угроз для потока данных до принятия решения

Построение архитектуры с соблюдением установленных норм

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

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

1. Обеспечьте качественное разделение контроля. Это предполагает, что любой процесс, который может получить доступ к конфиденциальным данным, не должен контактировать с Интернетом. Если каким-то интернет-процессам нужны данные, попробуйте размещать конфиденциальные данные отдельно от несекретных данных, даже если доступ к ним обеспечивается тем же ключом.
2. Убедитесь, что протоколы передачи данных между приложениями, обрабатывающими конфиденциальные данные и общедоступные приложения, устроены так, что не могут содержать конфиденциальные данные.
3. Используйте шифрование для защиты конфиденциальных данных. Ключи шифрования не должны быть доступны для приложений с доступом к Интернету. Можно развернуть секретные ключи и приложения в облаке или на корпоративном ресурсе, но они никогда не должны иметь такие же права доступа, что и общедоступные приложения.

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

1. Можно объединять проверку подлинности пользователей со службой сопоставления заявок, такой как Windows Azure AC Service. Она собирает заявки пользователей с корпоративного сервера служб федерации Active Directory и облачных провайдеров служб идентификации, таких как Windows Live или Facebook.
2. Отделяйте компоненты бизнес-приложения, которые работают с защищенными данными, от тех, что не работают с такой информацией. Таким образом, усилия аудита можно сосредоточить на приложениях первого типа.

Рис. 3. Любые проверки выполнения нормативов должны выполняться независимо от бизнес-приложений

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

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

Дэн Гриффин (Dan Griffin) является основателем JW Secure Inc, консультационной фирмы по обеспечению безопасности программного обеспечения, размещенной в Сиэтле. С Дэном можно связаться в twitter.com/JWSdan.

Том Джонс (Tom Jones) архитектор программ и автор, специализирующийся в области безопасности, надежности и удобства использования сетевых решений на основе облаков для финансовых и других важных организаций. Его решения в области безопасности охватывают огромную область, простирающуюся от принудительного обеспечения целостности до шифрующих модемов. С Томом можно связаться по электронной почте tom@jwsecure.com.