Як досягти безпечної роботи онлайн-сервісів

Я — Володимир Мельник, технічний директор Tucha. Хочу поділитися сучасним підходом до створення безпечної роботи онлайн-сервісів, а саме — їх захисту від зовнішніх загроз. Маю на увазі не лише захист від внесення сторонніми особами змін до коду веб-додатків, але й інші аспекти, пов'язані з безпекою. Тож наразі розглянемо способи протидії спробам експлуатації вразливостей самого додатка, які можуть вживатися зловмисником з метою отримання неправомірного доступу до тих або інших даних, їх крадіжці, підміні або знищення.

Та спочатку я увімкну режим Капітана Очевидність і акцентую увагу на деяких загальновідомих постулатах:

Помилки в коді веб-додатка нерідко дозволяють зловмиснику експлуатувати їх таким чином, щоб змусити додаток виконувати дії, вигідні зловмисникові та невигідні провайдеру або іншим користувачам онлайн-сервісу, роботу якого цей додаток забезпечує.

Наразі не існує скільки-небудь надійного способу, який міг би гарантувати відсутність помилок в коді програмного забезпечення, як не існує і гарантованого способу забезпечити неможливість їх знаходження та експлуатації.

Мережа Інтернет за визначенням не може вважатися безпечним середовищем. Автоматизовані сканери вразливостей постійно прочісують усі доступні адреси з метою виявлення слабких місць у захисті служб, що відгукуються за цими адресами (і якби ця практика не була достатньо ефективною, вона б не застосовувалася). Популярні онлайн-сервіси, до того ж, привертають масу уваги з боку ентузіастів, що приділяють цю саму увагу пошуку вразливостей, експлуатація яких може привести до цікавих для них результатів.

Проте кількість онлайн-сервісів у мережі продовжує зростати, збільшуються і темпи цього зростання. Одним із дійсно важливих питань є те, як захистити від зазіхань дані, що зберігаються на серверах, постійно підключених до мережі Інтернет.

Практик, націлених на зниження ризиків злому, існує досить багато, але, щоб не намагатися обійняти неосяжне, сфокусуємо загальну увагу на двох-трьох аспектах.

1. Виявлення вразливостей публікації додатка шляхом автоматичного тестування (зокрема і після кожного внесення змін до коду).
2.  Захист від експлуатації вразливостей за допомогою брандмауера веб-додатків, що виявляє потенційно небезпечні патерни в поведінці користувача і блокує потенційно небезпечні запити.
3. Не зайвим було б також згадати і про переваги мікросервісної архітектури, яка дозволяє мінімізувати ризики ескалації доступу при зломі мікросервісу, який сам по собі такого доступу не має.

Чи ефективні вони? Так.

Чи використовуються вони повсюдно? Ні.

Що може заважати застосовувати ці практики? Відповідь — лінь та оптимізм.

«Наші веб-додатки і так досить добре захищені» — це, мабуть, найшкідливіше допущення, яке можна зробити. Ще небезпечніше та абсурдніше за нього може бути тільки таке: «Ми пишемо код без помилок».

Зрозуміло, як я вже зазначав на самому початку, не існує засобів, що дозволяють повністю уникати помилок при розробці, як не існує і стовідсотково надійних способів захисту від їх експлуатації. Але, чим більше уваги приділяється цим аспектам, тим нижча ймовірність того, що веб-додаток буде зламано.

І я припускаю, що тут могла б допомогти платформа, в якій цей функціонал був би закладений спочатку. Уявімо собі, якою вона могла б бути.

Така платформа дозволяє автоматизувати процеси, пов'язані з життєвим циклом додатків, забезпечує роботу цих додатків, а також зберігання їх даних в обчислювальній хмарі. Щоб бути достатньо надійною, вона забезпечує розподілені обчислення та розподілене зберігання даних.

Під використанням платформи мається на увазі використання контейнерів — повністю ізольованих оточень, в яких з додатком доступні лише найнеобхідніші для його роботи компоненти. Коли платформі необхідно запустити додаток, вона створює нові контейнери (і не один, а кілька однакових), розгортаючи їх з образу, котрий їй доступний в репозиторії. Що б не сталося всередині контейнера, ці зміни вже не потраплять назад до репозиторія, контейнери постійно створюються та знищуються. Такий додаток не вдасться зламати і додати до коду які-небудь закладки. Чому? По-перше, всі файли програми намертво захищені від запису, а, по-друге, навіть якби зміни якимось чином вдалося б внести, усі ці файли є лише копією додатка: вони знаходяться в тимчасовому ефемерному контейнері, який рано чи пізно все одно буде знищено.

Цього року ми запустили платформу TuchaKube, що забезпечує цілий ряд функцій. Зазвичай, самостійне впровадження таких функцій вимагає тривалої і копіткої роботи, осмислення безлічі принципово нових понять, а також болісних пошуків відповіді на питання: «А для чого мені це все потрібно?». І ці функції стосуються не тільки безпеки. Платформа забезпечує такі речі, як:

• моніторинг величезної кількості метрик;
• автоматичне горизонтальне масштабування (шляхом створення на різних обчислювальних вузлах потрібної кількості однакових контейнерів з урахуванням поточного навантаження);
• автоматичний випуск сертифікатів для TLS-з'єднань;
• автоматизацію функцій DevOps.

Ще з минулого року, завдяки побажанням деяких партнерів нашої компанії, ми зіштовхнулися з необхідністю вирішити задачі із забезпечення автоматизації CI/CD-процесів. Це привело нас до щільного використання Docker-контейнерів, а потім — і до використання системи оркестрації Kubernetes. Накопичивши достатню кількість практичного досвіду, ми вирішили цей досвід систематизувати та витягти з нього додаткову користь для всіх: саме так і з'явилася революційна платформа TuchaKube.