Безопасность технологий: виртуальные машины против контейнеров
Какая технология является более безопасной? Многие думают, что виртуальные машины во многом преобладают данными качествами. В теории да, но на практике…есть сомнения.
Зачастую мы слышим такие громкие заявления вроде «HTTPS хорошо защищенный», или «HTTP не защищенный». Но что на самом деле мы подразумеваем под этими фразами? «HTTPS сложно отследить и произвести атаки «человек посередине» или «у моей бабушки нет никаких проблем отследить HTTP».
В данном вопросе нельзя кидаться такими фразами, ведь и HTTPS можно взломать (и бывали случаи), и HTTP в некоторых случаях достаточно безопасен. Кроме того, если при обнаружении уязвимости, связанной с эксплуатацией в общей реализации, поддерживающей HTTPS (имеется ввиду OpenSSL и Heartbleed), то этот самый HTTPS может стать хакерским шлюзом, пока вся система не будет исправлена.
HTTP и HTTPS — это протоколы, определенные Инженерным советом Интернета (IETF) в документах RFC под номерами 7230–7237 и 2828. Изначально появился HTTP, а уже в 2000 году был разработан HTTPS как более защищенный аналог HTTP. Однако, нельзя заявлять, что HTTPS является безопасным, а HTTP нет, т.к. существуют и исключения.
Почему виртуальные машины безопаснее контейнеров
Разделяй и властвуй — выигрышный принцип не только для военной стратегии, но и для программного обеспечения. Когда архитектура разделяет одну большую, сложную, труднорешаемую проблему безопасности на более легкие задачи, результатом решения каждой составляющей из этой проблемы в большинстве случаев станет более безопасный вариант, нежели при ситуации, когда существует одно решение, которое будет адресованное на все проблемы.
Контейнеры как раз являются ярким примером этого принципа. Из-за того, что каждое приложение обособлено в собственной «ячейке», недостатки в одном приложении не ослабляют приложения в других контейнерах. Виртуальные машины также существуют по этому принципу, но в данном случае и каждое действие у них происходит изолированно.
При работе с контейнерами существует следующий риск: Слабое место или неисправность одного приложения, заключенного в «ячейку» не может влиять на другие приложения напрямую, но это неисправное приложение может причинить урон единой операционной системе (ОС), которой также пользуются и другие контейнеры. Тем самым негативное воздействие будет оказываться уже на все контейнеры. В виду всего этого можно сделать вывод, что при использовании общей ОС вся структура подвергается риску, если возникнет неисправность хоть в одной ее составляющей. Т.е. если хоть какой-то сегмент подвергнется негативному влиянию, то это ставит под угрозу физическую машину.
Многоуровневая архитектура, такая как виртуализация, отделяет стек работы каждого приложения вплоть до аппаратного обеспечения, исключая возможность взаимодействия приложений друг с другом через общую ОС. Кроме того, между каждым стеком приложений и оборудованием имеются четные границы для предотвращения возникновения дальнейших ошибок и неправильного использования. Все это обеспечивает дополнительную надежность и защиту, не давая приложениям негативно влиять друг на друга. Виртуальные машины отделяют ОС, которая контролирует действия пользователя, от гипервизора, который контролирует взаимодействие между гостевой ОС и оборудованием. Гостевая ОС виртуальной машины управляет действиями пользователей, но не взаимодействием с железом. Ошибки в приложении или гостевой ОС вряд ли повлияет на физическое оборудование или другие виртуальные машины.
Если взять 2 идентичные ОС (гостевая ОС виртуальной машины и ОС контейнера), то при любом негативном воздействии под угрозу попадут все контейнера, работающие на ОС, и никакой угрозы не будет обнаружено для виртуальных машин. Причина в том, что виртуальные машины для обеспечения безопасности используют способ, когда приложения обособляются по горизонтали, а ОС обособляется от железа по вертикали.
Уязвимость гипервизора
Но все же вернемся к заголовку статьи, так ли идеальны виртуальные машины? И все же даже в такой архитектуре, предусматривающей обособление всех слоев, может возникнуть угроза. И слабое место в такой архитектуре — гипервизор. Нарушение в работе гипервизора это единая точка отказа, которая может вывести из строя всю систему, или вызвать недоступность данных, особенно это касается публичных облаков. Таким образом вполне может возникнуть такая ситуация, когда один хакер запустит вредоносный код на виртуальной машине, управляемой другими приложениями, которые принадлежат пользователям публичного облака, и тем самым с помощью одной атаки он завладеет всеми данными публичного облака.
Архитектура с прочной структурой все же может иметь ошибки реализации, которые существенно ослабляют систему. Нарушениям в работе гипервизора часто не уделяют должного внимания, потому что есть устойчивое мнение, что с ними никогда ничего не произойдет. Ведь считается, что гипервизоры настолько просты, настолько хорошо написаны, настолько тщательно проверены, что они просто никогда не выйдут из строя. Но последствия ошибок в работе гипервизора могут быть столь же разрушительным, как печально знакомые всем последствия вируса WannaCry. Кстати, к слову вспомним и о печально известном всем Heartbleed, ошибке в криптографическом программном обеспечении OpenSSL. А ведь OpenSSL имеет гораздо меньше строк кода, чем гипервизор. Но пока все же не беспокойтесь об этом.
На сегодняшний день мы не имеем сведений о каких-либо резонансных и серьезных нарушений гипервизора, которые поставили бы под риск всю систему. Но быстрый экспресс-анализ базы данных общеизвестных уязвимостей информационной безопасности (CVE) показывает, что исследователи все же обнаруживают в эксплуатации гипервизора недостатки, влияющие на уязвимость технологии. Но стоит отдать должное разработчикам гипервизором, по мере возникновения и обнаружения любых уязвимостей системы, они быстро находят пути их устранения. В марте 2017 года Microsoft выпустила бюллетень по безопасности под номером MS17–008, в котором задокументировано семь исправленных уязвимостей в гипервизоре Hyper-V, кстати, все они обозначенные как серьезные или критические.
В заключение можно сказать, что, опираясь на практическое использование и теоретические знания о работе системы, виртуальные машины все же обеспечивают лучшую безопасность, чем контейнеры. Но мы должны смотреть на безопасность систем виртуальных машин без розовых очков и всегда быть начеку. Кроме того, контейнеры и виртуальные машины часто комбинируются, поэтому обсуждать эту тему можно еще долго.
