Аналіз безпеки сервісно-­орієнтованого програмування

DOI: 10.31673/2412-9070.2021.052933

Анотація

За останні кілька років стрімко зросло використання технологій віртуалізації. Тому потреба в ефективних і безпечних вирішеннях для віртуалізації стає дедалі очевиднішою. Віртуалізація на основі контейнерів та віртуалізація на основі гіпервізора — це два головних типи технологій віртуалізації, що з'явилися на ринку. З цих двох класів віртуалізація на основі контейнерів може забезпечити більш легке та ефективне віртуальне середовище, але не без проблеми безпеки. У статті проаналізовано рівень безпеки сервісно-орієнтованого програмування, яке базується на контейнеризації застосунків. Розглянуто дві сфери: внутрішню безпеку сервісно-орієнтованого програмування та його взаємодію з функціями безпеки ядра Linux, зокрема SELinux та AppArmor, для посилення захисту хост-системи. Аналіз показав, що сервісно-орієнтоване програмування забезпечує високий рівень ізоляції та обмеження ресурсів для своїх контейнерів за допомогою простору імен, контрольних груп та файлової системи копіювання під час запису, навіть якщо конфігурація за замовчуванням. Воно також підтримує кілька функцій безпеки ядра, які уможливлюють посилення безпеки хоста. Єдина проблема, яку виявлено в сервіс-орієнтованому програмуванні, була пов’язана з його мережною моделлю за замовчуванням. Віртуальний ethernet-міст, який сервісно-орієнтоване програмування використовує як свою мережну модель за замовчуванням, уразливий до ARP-спуфінгу та атак заповнення MAC, оскільки він не забезпечує жодного фільтра мережного трафіку, що проходить через міст. Однак цю проблему можна вирішити, якщо адміністратор вручну додасть до мосту фільтрацію, наприклад ebtables, або змінить мережне підімкнення на більш безпечне, скажімо віртуальну мережу. Також варто зауважити, що якщо оператор запускає контейнер як «привілейований», СОП надає повний доступ до контейнера, який майже такий самий, як і для процесів, запущених на хості. Тому безпечніше експлуатувати контейнери як «непривілейовані». Крім того, незважаючи на те, що контейнери можуть забезпечити більшу щільність віртуальних середовищ і кращу продуктивність, вони мають більшу поверхню атаки, ніж віртуальні машини, оскільки контейнери можуть безпосередньо спілкуватися з ядром хоста. Проте можна зменшити поверхню атаки, зберігаючи ці переваги. Наприклад, цього можна досягти, розмістивши контейнери всередині віртуальних машин.

Ключові слова: сервісно-орієнтоване програмування; контейнеризація; віртуалізовані застосунки; віртуальна машина; сервер; контейнер; простір імен; контрольні групи.

Список використаної літератури
1. Burniske C. Containers: The next generation of virtualization? [Електронний ресурс]. URL: http://ark-invest.com/webx0/ containers-nextgeneration-virtualization. [Accessed 22 November 2014].
2. Security of OS-level virtualization technologies / E. Reshetova, J. Karhunen, T. Nyman and N. Asokan // Proceedings of the 2014 NordSec Conference. Norway, 2014. Р. 77–93.
3. Милл И., Хобсон Сейерс Э. Docker на практике / пер. с англ. Д. А. Беликов. Москва: ДМК Пресс, 2020. 516 с.
4. Regola N., Ducom J.-C. Recommendations for virtualization technologies in high performance computing // IEEE Second International Conference on Cloud Computing Technology and Science (Cloud-Com). Nov. 2010. Р. 409–416.
5. Моуэт Э. М89 Использование Docker / пер. с англ. А. В. Снастина; науч. ред. А. А. Маркелов. Москва: ДМК Пресс, 2017. 354 с.