Вопросы безопасности для модели облачных вычислений «инфраструктура как услуга»

Введение

Облако облако облако! Правильно, это еще одна статья об облачных вычислениях. Учитывая, что Microsoft «все включено», Google делает ставку на Chromebook, зависящий от Интернета, а Apple готовится к запуску облачных сервисов, кажется, что сопротивление бесполезно. Если вы посетили конференцию TechEd этого года в Атланте на прошлой неделе, вы знаете, что все ее внимание было посвящено облаку.

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

Что еще хуже, у нас есть разные виды облачных вычислений. Во-первых, общедоступное облако против частного облака, а иногда они даже объединяются и создают гибридное облако. Кроме того, существуют различные типы облачных сервисов: программное обеспечение как услуга (SaaS), инфраструктура как услуга (IaaS) и платформа как услуга (PaaS). Неудивительно, что даже техническим специалистам трудно ориентироваться в облаках.

Определение терминов

Многие из вас, возможно, уже начали свой путь к облачным вычислениям, но если нет, давайте начнем с нескольких определений. Облачные вычисления, согласно определению Национального института науки и технологий США (NIST), включают следующие функции:

• Самообслуживание по требованию. Пользователь может получить возможности вычислений, сети и хранения без необходимости обращаться к посреднику; это можно сделать через портал самообслуживания и приемный центр того или иного типа.
• Широкий доступ к сети. Хранилище информации в облачной инфраструктуре должно быть доступно из любого места и с широкого спектра сетевых устройств, таких как настольные компьютеры, ноутбуки, КПК, смартфоны и другие устройства, которые существуют в настоящее время, а также те, которые будут существовать в будущем..
• Объединение ресурсов. Вычислительные, сетевые ресурсы и ресурсы хранения предоставляются из более крупного пула ресурсов, и несколько арендаторов (разные группы или организации) используют преимущества этого пула. Также может быть независимость от местоположения, поскольку каждый арендатор может знать или не знать о местонахождении конкретных ресурсов в любой момент времени.
• Быстрая эластичность. Пользователи могут быстро и легко выделять и удалять ресурсы. Кроме того, это предоставление и удаление может выполняться автоматически на основе политики, так что ресурсы назначаются по мере необходимости и освобождаются, когда они больше не нужны.
• Измеренное обслуживание. Пользователи получают вычислительные, сетевые ресурсы и ресурсы хранения, которые им нужны, и платят только за те услуги, которые они используют.

Модели облачных вычислений

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

Существует три модели услуг для облачных вычислений:

• Программное обеспечение как услуга (SaaS). С помощью SaaS (также называемого «готовыми услугами») пользователи могут арендовать готовые к использованию приложения. Накладные расходы на приобретение обычно очень низки, а обязательства могут быть краткосрочными или долгосрочными.
• Платформа как услуга (PaaS). PaaS, в отличие от SaaS, не предоставляет клиентам готовые услуги. Вместо этого PaaS предоставляет платформу разработки со встроенной облачной аналитикой, поэтому разработчикам не нужно беспокоиться о базовой вычислительной, сетевой инфраструктуре и инфраструктуре хранения. Все, что нужно сделать разработчикам, — это разработать приложения с помощью инструментов, которые они уже умеют использовать, а затем развернуть их у поставщика PaaS. Затем облачный механизм поставщика PaaS обеспечивает основные облачные компетенции, необходимые для облачного приложения, как указано в первом маркированном списке выше.
• Инфраструктура как услуга (IaaS). IaaS, в отличие от SaaS и PaaS, не предоставляет ни готовой услуги, ни платформы для разработки. Вместо этого IaaS предоставляет базовую вычислительную, сетевую инфраструктуру и инфраструктуру хранения, на основе которых вы можете создавать свои собственные среды PaaS или SaaS. По сути, IaaS предоставляет простой способ развертывания виртуализированных серверов в облаке, используя преимущества виртуализации и автоматизации серверов.

Вам также необходимо знать о моделях развертывания облака. В то время как NIST определяет четыре модели развертывания в своем недавно выпущенном синопсисе DRAFT Cloud Computing, большая часть отрасли признает только три:

• Частное облако. Частная облачная инфраструктура — это инфраструктура, в которой вы контролируете все активы, которые участвуют в облачном решении. Инфраструктура частного облака может располагаться в вашем собственном центре обработки данных или в размещенном центре обработки данных. Однако, даже находясь в размещенном центре обработки данных, частное облако находится под вашим полным контролем — вы контролируете входящий и исходящий доступ, вы контролируете сеть, вы контролируете аппаратное обеспечение и все программное обеспечение (операционные системы и системные службы).
• Публичное облако. В общедоступном облаке вы арендуете услуги у облачного провайдера. Вы можете арендовать услуги SaaS, PaaS или IaaS, но вы не контролируете все уровни стека. Кроме того, общедоступные облачные среды являются общими, многофункциональными средами, что означает, что ваши услуги и данные могут быть размещены совместно с другими, в том числе с конкурентами.
• Гибридное облако. Гибридное облако — это модель развертывания, при которой организация использует преимущества как общедоступного, так и частного облака. Например, фирма может захотеть разместить большое количество веб-серверов в общедоступном облаке, чтобы они были клиентским интерфейсом для покупок и приема заказов, но затем частное облако используется для хранения клиентских и финансовых данных, которые управляют транзакциями.

Модели развертывания обычно определяются тем, кто контролирует облачные ресурсы. Документ NIST добавляет «облако сообщества», в котором несколько организаций объединяются для создания «полуприватного» облака. NIST дополнительно разбивает модели частного и общественного облака на две подмодели: локальную и аутсорсинговую. 84-страничный документ NIST обеспечивает хорошую основу для понимания основ облачных вычислений. Вы можете скачать его в формате PDF здесь.

Безопасность инфраструктуры как услуги

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

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

• Защита от утечки данных и мониторинг использования
• Аутентификация и авторизация
• Реагирование на инциденты и возможности судебной экспертизы
• Укрепление инфраструктуры
• Сквозное шифрование

Защита от утечки данных и мониторинг использования

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

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

Аутентификация и авторизация

Конечно, для эффективного решения по предотвращению потери данных (DLP) необходимо иметь надежные методы аутентификации и авторизации. Мы все можем согласиться с тем, что имя пользователя и пароль — не самый безопасный механизм аутентификации. Рассмотрите возможность двухфакторной или многофакторной аутентификации для всей информации, которая должна быть ограничена. Кроме того, рассмотрите возможность разделения политик доступа на уровни на основе уровня доверия к каждому поставщику удостоверений для ваших облачных решений IaaS. Уровень авторизации, который вы включаете от поставщика удостоверений, такого как Google Mail, будет намного ниже, чем если бы поставщиком удостоверений была ваша корпоративная среда Active Directory. Интегрируйте этот уровень авторизации в свое решение DLP.

Сквозное ведение журнала и отчетность

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

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

Укрепление инфраструктуры

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

Сквозное шифрование

IaaS как услуга, как в общедоступных, так и в частных облаках, должна использовать сквозное шифрование. Убедитесь, что вы используете шифрование всего диска, что гарантирует, что все данные на диске, а не только файлы пользовательских данных, будут зашифрованы. Это также предотвращает офлайн-атаки. В дополнение к шифрованию всего диска убедитесь, что все соединения с хост-операционными системами и виртуальными машинами в инфраструктуре IaaS зашифрованы. Это можно сделать через SSL/TLS или IPsec. Сюда входит не только обмен данными со станциями управления, но и обмен данными между самими виртуальными машинами (при условии, что вы разрешили обмен данными между виртуальными машинами). Кроме того, если они доступны, разверните такие механизмы, как гомоморфное шифрование, чтобы обеспечить безопасность и безопасность связи конечных пользователей. Это форма шифрования, которая позволяет выполнять сложные вычисления с данными, даже если они зашифрованы. Чтобы узнать больше об этом, см. статью Майкла Касснера «Гомоморфное шифрование: может ли оно спасти облачные вычисления?» на веб-сайте TechRepublic.

Резюме

Облачные вычисления — это больше, чем просто виртуализация серверов. Документ NIST определил несколько требований к решению для облачных вычислений. Существует три модели услуг для облачных вычислений: SaaS, PaaS и IaaS, а также (как минимум) три модели развертывания: общедоступное облако, частное облако и гибридное облако. При развертывании решения IaaS возникает ряд вопросов безопасности, которые необходимо учитывать как для частного облака IaaS, так и для общедоступного облака IaaS, которые мы выделили в этой статье. В следующих статьях мы углубимся в другие аспекты облачной безопасности.