Какая технология является более безопасной? Многие думают, что виртуальные машины во многом преобладают данными качествами. В теории да, но на практике…есть сомнения.
Зачастую мы слышим такие громкие заявления вроде «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, кстати, все они обозначенные как серьезные или критические.
В заключение можно сказать, что, опираясь на практическое использование и теоретические знания о работе системы, виртуальные машины все же обеспечивают лучшую безопасность, чем контейнеры. Но мы должны смотреть на безопасность систем виртуальных машин без розовых очков и всегда быть начеку. Кроме того, контейнеры и виртуальные машины часто комбинируются, поэтому обсуждать эту тему можно еще долго.
Зачастую мы слышим такие громкие заявления вроде «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, кстати, все они обозначенные как серьезные или критические.
В заключение можно сказать, что, опираясь на практическое использование и теоретические знания о работе системы, виртуальные машины все же обеспечивают лучшую безопасность, чем контейнеры. Но мы должны смотреть на безопасность систем виртуальных машин без розовых очков и всегда быть начеку. Кроме того, контейнеры и виртуальные машины часто комбинируются, поэтому обсуждать эту тему можно еще долго.
Комментарии (7)
shockable
06.02.2018 22:42Кроме того, если при обнаружении уязвимости, связанной с эксплуатацией в общей реализации, поддерживающей HTTPS (имеется ввиду OpenSSL и Heartbleed), то этот самый HTTPS может стать хакерским шлюзом, пока вся система не будет исправлена.
Можете пояснить?
imanushin
06.02.2018 23:35Если кратко:
- В случае контейнеров безопасность обеспечивается средствами ОС, а точнее — за счет того, что каждый контейнер работает от отдельного пользователя без прав администратора.
- В случае гипервизора безопасность обеспечивается тем, что разные сервисы работают на разных виртуальных машинах (т.е. каждая запущенная система — виртуализируется).
В случае хакерской атаки, придется проходить разные уровни защиты:
- Для контейнера необходимо воспользоваться уязвимостью вида "повышение прав до уровня администратора"
- Для гипервизора — одной на выбор:
2.1 Или воспользоваться багой, которая позволит вирусу убежать на хост, см. например уязвимость VMWare.
2.2. В некоторых случаях — требуется сначала поднять уровень привилегий до администратора, а потом воспользоваться дырой выше. - В обоих случаях — необходимо еще как-то уметь атаковать сам Http сервис, однако здесь атаки абсолютно одинаковые для обоих технологий: и для контейнеризации, и для виртуализации.
Однако, есть еще небольшой нюанс: в случае контейнеров каждый сервис сидит в отдельном контейнере. В случае честной виртуализаций это потребовало бы на каждый сервис держать в памяти еще одну операционку (с ядром, кешем файловой системы, и применять подобного рода оптимизации), что требует в разы больше ресурсов. Более того — не получится дедуплицировать файлы на уровне файловой системы и т.д. В итоге, виртуализация вырождается в гибрид — на каждой виртуальной машине находится несколько сервисов от одной команды/проекта/компании. То есть для атаки соседних сервисов можно как ломать гипервизор (тогда будет полный контроль), так и ломать контейнер (в этом случае под удар попадут только соседние сервисы).
И самое важное: Http, OpenSsl, Heartbleed тут абсолютно не при чем.
Еще интересный момент — в iOS приложения работают именно по модели контейнеров, т.е. каждое приложение — от отдельного пользователя.
vadimr
08.02.2018 00:11Обычная ОС общего назначения вообще не ставит перед собой задачу изолировать приложения между собой с точки зрения безопасности, она только пытается устранить их влияние на работоспособность друг друга. В общем-то, тут нечего и ломать, средства межпроцессной коммуникации никто не отменял.
VolCh
09.02.2018 13:07Так изоляция приложения между собой с точки зрения безопасности это частный случай устранения их влияния на работоспособность друг друга.
VolCh
Почему везде "гипервизор" в единственном числе? Какой-то конкретный имеется в виду? Hyper-V?
А в целом понятно, что гипервизор даёт ещё один уровень изоляции процессов друг от друга ценой бОльших ограничений. Чтобы достучаться до разделяемых физических ресурсов, нужно "пробить" не только атакуемое приложение и ОС, но ещё и гипервизор.
OlvinKSA
> нужно «пробить» не только атакуемое приложение и ОС, но ещё и гипервизор.
Кстати, подозреваю, что возможны уязвимости, затрагивающие гипервизор без необходимости ломать ОС. Хотя это не умаляет важность дополнительного уровня.
VolCh
Сходу сложно такие представить, но, да, не исключено.