Дізнайтеся, як налаштувати Zero Trust у своїй інфраструктурі: захистіть веб-адмінку через mTLS та зробіть пристрої довіреними за допомогою TPM і Secure Enclave. Практичний посібник для інженерів.
Концепція захисту інфраструктури, в якій жодна сторона не довіряє іншій за замовчуванням, заслуговує на особливу увагу. Кожна дія перевіряється, кожен запит — під контролем, а доступ — виключно за чітко визначеними правилами. Такий підхід називається Zero Trust — модель, що ставить безпеку вище зручності й виключає «сліпу довіру» навіть всередині системи.
Які основні ідеї лежать у її основі?
Завжди перевіряй явно
Відсутність будь-яких “довірених” зон
Проектування з думкою “нас уже зламали”
Давайте пройдемося по постулатах детальніше і технічніше. По ходу справи вирішуватимемо нагальні проблеми – захист веб-адмінок від крадіжки даних. За підсумками хочемо отримати розуміння, як зробити MVP рішення, збудованого за принципами zerotrust.
Формально, для безпечної взаємодії в інфраструктурі необхідна взаємна автентифікація та авторизація між сторонами. Типова корпоративна мережа включає серверний і користувацький сегменти. Одним із найпоширеніших шляхів витоку даних є наявність зловмисника всередині VPN-середовища, який отримує доступ до облікових записів або обходить двофакторну автентифікацію для внутрішніх адмін-панелей, після чого здійснює крадіжку інформації.
Основна причина таких інцидентів — припущення, що всередині VPN усе вже достатньо захищене, і повторна аутентифікація більше не потрібна. Однак цей підхід вважається застарілим.
Сучасна модель безпеки передбачає обов’язкову та явну перевірку обох сторін комунікації — як з боку сервера, так і з боку клієнта. Найбільш надійним механізмом для цього є використання mTLS (mutual TLS), при якому сторони взаємно перевіряють криптографічні сертифікати одна одної перед встановленням з’єднання.
Ось так виглядає робота mTLS. Клієнт та сервер обмінюються сертифікатами, валідують їх та встановлюють захищене з’єднання. Завдання явної перевірки вирішено.
А що якщо ми не тільки хочемо знати, хто до нас прийшов, але й дізнатися наскільки пристрій захищений? Тобто для повноцінного захисту наших адмінок потрібно робити дві речі:
Аутентифікувати пристрій
Аутентифікувати користувача
Надійно аутентифікувати пристрій можна, згенерувавши сертифікат у сховище, що не виймається. Для цього підходить Secure Enclave у пристроях Apple та TPM для інших пристроїв. Аутентифікувати користувача можна стандартними способами – підійде, наприклад, ldap або OIDC. Докладніше про проблематику перевірки пристроїв та користувача поговоримо в окремому матеріалі.
Проектування сервісу потрібно робити так, ніби у вас усі сервери та клієнти виставлені всіма портами в інтернет. При цьому потрібно врахувати, що кожна компанія має свій рівень зрілості, і свій темп розвитку бізнесу. Потрібні будуть компроміси, наприклад, для виключно міжсерверної взаємодії (похід до СУБД бекендом веб-додатку) термінове впровадження ZT буде надлишковим. Проте проектування нових або перенесення архітектури старих сервісів на нові рейки дасть вагомі плоди з погляду ІБ у довгостроковій перспективі.
Повертаючись до насущної проблеми захисту адмінок – найпростішим та найефективнішим методом буде проксі. Або по кроках:
Реалізуємо проксі, що здійснює перевірку пристрою
Реалізуємо механізм перевірки користувача – наприклад, OIDC
Переносимо існуючу адмінку за нашу захищену проксі
Після реалізації цих пунктів нам буде неважливо в якій зоні довіри матиме нашу адмінку – всередині VPN, всередині окремої захищеної підмережі всередині VPN, або в інтернеті. Прив’язку до довірених зон ми прибрали.
Цей пункт дещо менш технічно прикладний, але він дуже важливий. При побудові інфраструктури необхідно привчити себе до думки, що кожен елемент вже зламаний – клієнтський ноутбук, сервер, або мережева залізця. Так ми зможемо чітко зрозуміти, які ризики виникнуть при зломі, наприклад, клієнтського ноутбука, і які заходи потрібно вжити для мітигації або запобігання атакам.
Так як прикладна проблема, яку ми вирішуємо, це захист веб-адмінок, основним об’єктом захисту для нас стануть клієнтські ноутбуки, так як наша проксі пускає в адмінку тільки відомі нам пристрої.
а) накручуємо на ньому засоби захисту та моніторингу – edr агент, правильно налаштоване логгування.
б) переконуємось, що наш Security Operation Center вміє розпізнавати всі сучасні типи атак на кінцеві пристрої. Для цього ми постійно вивчаємо нові TTP, проводимо навчання та пишемо нові правила в SIEM.
Отже, що ми собі винесли. Для отримання MVP рішення Zetotrust щодо захисту веб-адмінки нам потрібно:
Реалізувати інфраструктуру з доставки та валідації сертифікатів для кінцевих пристроїв
Реалізувати проксі, здатну встановлювати захищене mtls з’єднання, в перспективі перевіряючи рівень захищеності пристрою, що підключається.
Налагодити захист і моніторинг кінцевих пристроїв
Високорівнево виглядає приблизно так:
Схема свідомо спрощена, у кожному новому матеріалі вона оновлюватиметься і ускладнюватиметься. Буде детально розписана схема mTLS і система валідації сертифікатів, включення SOC не тільки в роботу з самим ноутбуком, а й у моніторинг самої адмінки, перевірка захищеності кінцевих пристроїв, тобто кожен новий елемент буде відображено на схемі в міру детального обговорення. Фінальна схема буде доступна пізніше.
Точно сказати, хто придумав ZT і як саме неможливо. Нас більше цікавить практичний бік питання. І ось по ній низка матеріалів є.
Google BeyondCorp. Цикл статей, у тому числі народився спочатку внутрішній, та був і комерційний продукт. У статтях докладно прописана теорія, схема роботи та ряд ключових технічних та управлінських аспектів. Must read.
Project Zero Trust. Книга двох ідеологів ідеї Zerotrust, які десять років їздять різними компаніями та розповідають, як його впроваджувати. Технічного дуже мало, але поради щодо “продажу” ідеї бізнесу зустрічаються тямущі.
Cloudflare ONE. Комерційне рішення від Cloudflare, у документації досить докладно розписані технічні аспекти, з яких можна зрозуміти аспекти організаційні. Є *AAS рішенням, особисто мені зав’язуватися на готові рішення такого масштабу не є розумним. Добре підходить для того, щоби взяти ідеї для власної розробки.
Для того щоб учасники zt перевіряли один одного, нам необхідний якийсь механізм. Раніше ми вибрали для цього старий добрий mTLS. Він дозволяє надійно та безпечно верифікувати обидві сторони взаємодії.
Звернемося до нашого практичного завдання – захист веб адмінок. Перевіряти валідність та довіру сертифікату веб-ресурсу браузери навчилися дуже давно, і механізм добре налагоджений. З перевіркою сервером ендпоїнт не все так просто. Перша проблема, яка спадає на думку – куди покласти сертифікат на машині користувача, щоб його не вкрали? Є кілька варіантів – просто на файлову систему, в захищене парольне сховище (наприклад Keychain на macOS), або ще в більш захищене хардварне сховище TPM або Secure Enclave.
Наш практичний досвід пентестів показує, що все, що лежить на машині користувача, можна витягнути. Просто сертифікат з диска витягується на два рази, пароль з Keychain витягується сфабрикованим поп-апом з проханням ввести від нього пароль. Залишається TPM. Явним його плюсом є те, що згенерований усередині сертифікат не може бути витягнутий – тобто при пробиванні машини і навіть одержанні на ній атаки рута все одно не зможе отримати закритий ключ. Виходить наш вибір очевидний – кладемо сертифікати для mTLS у TPM/SecEnclave.
І тут починається цікаве.
Почнемо з платформи, що найбільш коректно працює – Windows. Вся логіка роботи з TPM зашита в кількох системних DLL різного рівня абстракції, для яких людство розробило велику кількість обгорток.
Якщо не вдаватися до технічних подробиць, генерація та зберігання сертифіката виконується викликом вже написаних добрими людьми функцій з go пакету (ми пишемо на go). Все, що потрібно – запакувати виклик функцій у бінар, додати підтримку cli та silent режиму, після чого протестувати його розливання та виконання за допомогою доменних політик.
Пристрої Apple виступили негаразд гладко. Почнемо по порядку.
Відсутні розвинені Opensource бібліотеки/софт для роботи з Secure Enclave. З більш-менш живих – софт для записування ssh ключів у tpm (не тестували) та POC-софт для повноцінної роботи з SecureEncavle, записування та видалення довільних ключів, їх лістингу тощо. Саме він би взятий за основу і нормально працював. Поки що Apple не викотило оновлення ОС, після чого все працювати перестало. Було ухвалено вольове рішення писати все з нуля.
Через відсутність відкритих бібліотек доводиться користуватися рідним macOS API. Через це ти змушений писати на Objective C. Після героїчного експресу навчання в бойових умовах новій мові, ти приходиш до нового цікавого завдання.
Підписання бінара. Не можна просто так взяти та поширити програму, що працює із захищеним криптопровайдером. Для цього знадобиться а) платний обліковий запис на Apple Developer б) сакральні, ніде не описані знання, які саме entitlements потрібно запросити софту, і які саме галочки проставити в XCode.
Сумісність. Власні процесори та SoC Apple – безумовно, видатні технічні досягнення. Проблема в тому, що з кожною новою версією чіпа змінюється специфікація та необхідні елементи. Для того, щоб бінар коректно заробив відразу на всіх платформах, потрібна була консультація з духом Стіва Джобса.
Після подолання вищеописаного вдалося створити софт. Короткі висновки – Secure Enclave ще сирий і вимагає великої уваги та підтримки, платформоутримувач – Apple – у будь-який момент може змінити правила гри, твоє ПЗ перестане працювати, твої процеси зламаються. Потрібно бути готовим і мати план Б на кожен варіант негативного розвитку подій.
Як тільки ми почнемо розливати на пристрої сертифікати, ми зіткнемося з проблемою – як зрозуміти, що пристрій, який запитує наш сертифікат, корпоративний?
Так як ми використовуємо самописні бінарі для запиту та виконання сертифікату, нам потрібен якийсь механізм, щоб умовний співробітник Вася, не прийшов в офіс з особистим ноутбуком, поставив наш бінар, смикнув ручку та перетворив свій особистий ноутбук на корпоративний.
Перший варіант рішення – використовувати офіційний рекомендований виробниками спосіб атестації. Apple пропонує протокол ACME – офіційний протокол менеджменту сертифікатів у корпоративному середовищі. За ним вердикт короткий – він сирий і не працює. Для Windows є офіційний процес TPM Key Attestation, який на нашому досвіді працює. Тут ми приходимо до того, що половина нашого парку працюватиме нормально (Windows), а половина ні (macOS). Потрібен інший спосіб.
Другий спосіб. Ретроградський. Організуємо секретну кімнату в якій стоїть сервер із Certification Authority з якого стирчить один патч-корд. Всі ноутбуки компанії привозимо в цю кімнату і розливаємо сертифікат по дроту. Спосіб, як не смішно, робітник, але не дуже зручний. Розлити сертифікати на існуючий парк обладнання буде надзвичайно трудомістким. Проте спосіб цілком валідний для сетапу нового обладнання. Поки що залишаємо в такій урізаній формі.
Третій спосіб. Самостійний Enroll із валідацією. Наш софт для спілкування з нашим CA розповсюджується відкрито, він уже йде в комплекті з корпоративною наливкою. При запиті сертифіката від нового пристрою воно потрапляє в лист очікування, в якому інженер у ручному режимі аналізує, чи справді пристрій корпоративний, після чого погодить сертифікат. Спосіб хороший, але лише на невеликих обсягах. Використовуємо її для виняткових випадків. Також використовуємо його для початкового розливання на парк поточних пристроїв, які видано користувачам.
Разом – в ідеальному світі, коли запрацюють вендорські рішення, ми зможемо повністю автоматизувати процес атестації за допомогою MDM. Зараз ми змушені користуватися допоміжними засобами.
Для валідації mTLS нашої проксі потрібен CA, від якого вона може отримати підтвердження, “наш” або “не наш” комп’ютер прийшов.
Також CA нам потрібна для початкової атестації пристроїв:
Як видно зі схеми, нам потрібно невелике middleware для роботи з CA та нашим софтом. На ньому ми можемо надати нові комп’ютери, накручувати при необхідності аутентифікацію, збирати статистику, і, що важливо, збирати логи нашого софту (при падіннях, наприклад).
Так як mTLS досить обкатана технологія, браузери працюють з нею добре і мають достатній набір інструментів з тонким налаштуванням.
Для забезпечення стабільної роботи бажано мати ферму для тестів всіх необхідних браузерів для всіх необхідних операційних систем. На момент написання браузери Chrome, Firefox, Safari на MacOS і Windows працювали коректно.
Після вдалої установки сертифіката в tpm, коли користувач відкриває адмінку за нашою zt проксі, браузер пропонує вибрати сертифікат для аутентифікації (так працює mtls). Для покращення користувальницького досвіду потрібно невелике доналаштування, щоб прозоро цей сертифікат “підкласти” браузеру. Робиться це стандартними задокументованими способами і з досвіду працює коректно. Ця донастройка дозволить забезпечити нульову взаємодію користувача при переході на zt, що забезпечить нам пошану, повагу і позитивні відгуки співробітників.
Для підключення користувацьких машин до процесу zt нам знадобиться:
Розробити механізм (ПЗ) для доставки, управління та атестації сертифікатів на всі підтримувані нами ОС та пристрої.
Зрозуміти та підняти Certification Authority для забезпечення аутентифікації пристроїв
Написати middleware для взаємодії з Certification Authority
Ще кілька зауважень. Для нашого MVP ми беремо на підтримку ноутбуки з Windows та macOS. Дослідження *nix ми провели, працездатності досягли, але офіційно не підтримуємо. Також ми не розглядаємо тут мобільні пристрої, їхня підтримка виходить за рамки MVP.
