Обеспечение безопасности вашего облака
В настоящее время все и их собаки пытаются перенести свою ИТ-инфраструктуру в облако. Преимущества довольно очевидны: меньше оборудования для обслуживания, более предсказуемые затраты, большая гибкость, большая масштабируемость и так далее. Но является ли размещение серверных рабочих нагрузок и приложений в облаке хорошей идеей с точки зрения безопасности? Безопасно ли хранить все свои ИТ-активы и конфиденциальные бизнес-данные в облаке? В конце концов, облако, которое вы используете, представляет собой не что иное, как набор географически разбросанных центров обработки данных, которыми владеет и управляет кто-то другой.
Более того, поставщики облачных услуг обычно изо всех сил стараются сообщить вам, что они определенно могут обеспечить безопасность и защиту ваших конфигураций и данных. «Просто доверься нам» — их мантра. Это напоминает мне то, что Том Круз (Рой) сказал Кэмерон Диас (Джун) в фильме «Рыцарь дня», который, должен признаться, является одним из моих самых любимых фильмов:
Точно так же, когда поставщик облачных услуг говорит мне, что моя ИТ-инфраструктура будет «безопасной» и «надежной» в их облаке и что ее перемещение туда может помочь мне «стабилизировать» мой бизнес, первая мысль, которая часто приходит на мой взгляд, «они собираются убить меня».
Итак, вопрос заключается в следующем: как мне избежать смерти, если я перенесу свою инфраструктуру в облако? Или я просто психически неуравновешенный и параноик?
Думайте локально
Лучше всего начать думать о том, как спроектировать безопасность для вашей облачной инфраструктуры, — представить, что она расположена локально, а не в облаке. Другими словами, многие из тех же принципов, которым вы следуете для обеспечения безопасности традиционной локальной инфраструктуры, так же применимы, если вы размещаете виртуальные машины или контейнерные рабочие нагрузки в Amazon Web Services, Microsoft Azure или общедоступных облачных службах других поставщиков.
Например, в Microsoft Azure, если ваша виртуальная сеть большая, то рекомендуется разделить ее на подсети на основе логических уровней, а затем использовать группы безопасности сети (NSG) для создания правил разрешения/запрета для управления внутренним трафиком в виртуальной сети. Группы безопасности сети действуют как устройства проверки пакетов с отслеживанием состояния и могут помочь вам контролировать, какие пакеты могут маршрутизироваться между вашими подсетями на основе исходного и целевого IP-адреса и порта пакета вместе с протоколом уровня 4 OSI для пакета.
Вы также можете повысить безопасность своей виртуальной сети, развернув устройство безопасности виртуальной сети, такое как брандмауэр веб-приложений Barracuda или брандмауэр Sophos XG в Azure, но имейте в виду, что добавление таких виртуальных устройств обычно требует настройки определяемых пользователем маршрутов (UDR) для вашей виртуальной сети и включив IP-переадресацию на виртуальной машине, на которой размещено устройство.
Точно так же, как если вы хотите подключить локальную сеть к Интернету, создание сети периметра или демилитаризованной зоны также важно для вашей виртуальной сети, чтобы защитить ваши облачные ресурсы при доступе к ним через Интернет. На самом деле, большинство лучших практик, связанных с проектированием DMZ для локальных сетей, переносятся прямо в эфирный мир облачных вычислений.
Включить подключение между локальными объектами
Если вы в настоящее время находитесь в процессе переноса инфраструктуры вашей компании в облако, у вас, вероятно, на данный момент есть какая-то форма гибридной инфраструктуры, которая является частично облачной и частично локальной. Многие компании даже предпочитают оставаться там по причинам, варьирующимся от внутренней политики компании до транснациональных требований соответствия. Независимо от того, собираетесь ли вы оставаться в гибридной зоне или нет, крайне важно, чтобы у вас была безопасная связь между локальной и облачной инфраструктурами.
Опять же, учитывая облачные службы Microsoft Azure, один из способов реализации безопасного подключения между объектами — это использование функции VPN типа «сеть-сеть» в Azure, которая использует режим туннеля IPsec для создания зашифрованного туннеля через Интернет между вашей локальной сетью и облаком. инфраструктуры. Однако пропускная способность этой функции ограничена примерно 200 Мбит/с, поэтому, если вам нужна более высокая пропускная способность для подключения ваших инфраструктур, вы, вероятно, захотите использовать выделенный маршрут канала WAN и использовать Azure ExpressRoute.
Убить RDP
Протокол удаленного рабочего стола (RDP) — это прекрасный способ подключения к удаленным серверам Windows (будь то физические или виртуальные), чтобы вы могли управлять ими, как если бы вы сидели перед ними за консолью. И, конечно же, легко подключить RDP напрямую через Интернет к вашим виртуальным машинам, работающим в Microsoft Azure, чтобы вы могли настраивать, управлять и обслуживать их, чтобы службы и рабочие нагрузки работали на них с первоклассной производительностью.
К сожалению, RDP (а также SSH) можно считать уязвимостью в системе безопасности, когда они включены на виртуальных машинах, размещенных в облаке, поскольку злоумышленник может попытаться атаковать методом грубой силы, чтобы попытаться получить доступ к вашим машинам. Однако, если у вас есть решение для межлокального подключения, такое как VPN типа «сеть-сеть» или Azure ExpressRoute, вам не нужно иметь прямой доступ RDP через Интернет для вашей виртуальной сети Azure. Вместо этого вы можете безопасно использовать RDP для своих виртуальных машин через VPN типа «сеть-сеть» или выделенный канал глобальной сети.
И даже если у вас не реализовано ни одно из этих межучрежденческих решений для подключения, вы все равно можете создать VPN типа «точка-сеть» в Azure, которая использует двухэтапную аутентификацию, чтобы вдвойне защитить ваши виртуальные машины от атак грубой силы на RDP.. В сценарии VPN типа "точка-сеть" первая проверка подлинности выполняется при авторизации VPN-подключения к удаленному компьютеру; затем происходит вторая аутентификация для авторизации создания сеанса RDP. То же самое справедливо и для SSH.
И ответ такой…
Я мог бы рассказать о гораздо большем, что касается обеспечения безопасности вашей облачной инфраструктуры, но вы, вероятно, задаетесь вопросом, почему я до сих пор не ответил на вопрос, который я задал ранее в этой статье, а именно: не параноик ли я, беспокоясь о том, что Меня убьют, если я перенесу инфраструктуру моей компании в облако? Ответ, конечно, «да», я параноик — и вы тоже должны быть! С быстрыми темпами технологических изменений, вызванных облачными вычислениями, новые технологии и функции внедряются задолго до того, как будет адекватно изучено потенциальное влияние этих функций на безопасность. А у более крупных облачных провайдеров многие изменения, которые они вносят в серверную часть, не объявляются публично и не документируются должным образом. Тем больше причин придерживаться хорошо известных передовых методов защиты сетей любой формы, как локальных, так и облачных.