Багатоорендна ізоляція в оборонному SaaS: розділення засекречених клієнтів у спільній інфраструктурі

Платформи оборонного SaaS стикаються зі структурним напруженням, якого немає в цивільному багатоорендному програмному забезпеченні. Постачальник комерційного SaaS турбується про логічне розділення даних між клієнтами, щоб запобігти випадковому розкриттю. Постачальник оборонного SaaS має досягти значно сильнішої гарантії: що дані, які належать одному засекреченому орендарю, доказово недосяжні для іншого орендаря, навіть якщо зловмисник скомпрометував код на рівні застосунку чи отримав облікові дані адміністратора. Регуляторне формулювання суворе: несанкціоноване розкриття даних SECRET орендарю без допуску — це не інцидент конфіденційності, це подія витоку з юридичними та оперативними наслідками. Ця стаття розглядає, як багатоорендна ізоляція проєктується, реалізується та демонструється в платформах оборонного SaaS, що обслуговують орендарів різних рівнів секретності, з різними вимогами до резидентності даних та незалежними межами акредитації, на засекреченій хмарній інфраструктурі на основі Kubernetes.

Чому багатоорендність складна, коли орендарі мають різні рівні секретності

Багатоорендна архітектура в комерційному програмному забезпеченні є насамперед економічним рішенням: спільне використання обчислень, бази даних та операційних накладних витрат між клієнтами знижує вартість доставки в розрахунку на клієнта. В оборонному SaaS економіка все ще доречна, але вимоги до ізоляції, накладені секретністю, вводять обмеження, які комерційні багатоорендні патерни не можуть задовольнити з коробки. Коли два орендарі працюють на різних рівнях секретності, скажімо, один на SECRET, а інший на UNCLASSIFIED, вони не можуть спільно використовувати рушій бази даних, пул планування контейнерів чи криптографічний простір імен ключів, оскільки будь-який із цих спільних рівнів може стати каналом несанкціонованої передачі даних — чи то через пряму помилку конфігурації запиту, побічні атаки за часом, чи скомпрометований інструментарій оператора.

Розрив у рівні секретності — не єдиний ускладнюючий чинник. Навіть орендарі того самого рівня секретності можуть мати несумісні вимоги, що потребують сильної ізоляції: різні національні закони про резидентність даних, різні правила щодо зберігання журналів та доступу до аудиту, різні авторизовані групи користувачів та різні схвалені набори шифрів. Орендар Міністерства оборони Великої Британії та орендар Міністерства оборони США можуть обидва працювати на рівні RESTRICTED/SENSITIVE, але за двосторонньою угодою бути позбавленими права обробляти свої дані на тому самому фізичному обладнанні. Модель ізоляції тому має проєктуватися проти матриці атрибутів орендаря — рівня секретності, національної юрисдикції, аудиторського органу та схваленого криптографічного матеріалу — а не простого бінарного поділу високий/низький.

Регуляторні рамки посилюють ставки. Згідно з рамками на кшталт Cloud Computing Security Requirements Guide Міністерства оборони США та настанови Secure by Design Великої Британії, система, яка стверджує, що ізолює засекречених орендарів, має демонструвати ізоляцію через задокументовані засоби контролю, незалежне тестування та безперервний моніторинг, а не просто стверджувати це. Уповноважена посадова особа запитає докази: захоплення мережевого трафіку, що показує відсутність міжорендних потоків, журнали служби керування ключами, що показують відсутність міжорендного використання ключів, та журнали запитів бази даних, що показують відсутність міжорендних наборів результатів. Архітектурні рішення, що ускладнюють отримання цих доказів, не просто технічно незручні; вони є блокувальниками акредитації.

Стратегії ізоляції бази даних: схема-на-орендаря, база-даних-на-орендаря та інстанс-на-орендаря

Рівень бази даних — це місце, де виникає більшість збоїв багатоорендної ізоляції. Існують три патерни, і правильний вибір залежить від вимог секретності та аудиту групи орендарів. Схема-на-орендаря розміщує таблиці кожного орендаря в окремій схемі в межах одного інстансу рушія бази даних. Контроль доступу забезпечується ролями бази даних, прив'язаними до кожної схеми, а політики безпеки на рівні рядків забезпечують вторинний рівень примусу. Цей патерн має найнижчі операційні накладні витрати — один рушій бази даних для оновлення, моніторингу та резервного копіювання — і доречний, коли всі орендарі поділяють той самий рівень секретності, а вимога ізоляції логічна, а не фізична. Слабкість у тому, що неправильно налаштована роль, вразливість підвищення привілеїв у базі даних чи запит, що обходить політику безпеки на рівні рядків, може розкрити міжорендні дані. Для засекречених середовищ, де подія витоку несе серйозні наслідки, покладатися виключно на логічну ізоляцію на рівні схеми — складна позиція для захисту перед уповноваженою посадовою особою.

База-даних-на-орендаря виділяє виділений інстанс бази даних для кожного орендаря, але дозволяє цим інстансам працювати на спільній обчислювальній інфраструктурі. Процес рушія бази даних ізольований на рівні операційної системи, тому неправильно налаштована схема чи скомпрометовані облікові дані застосунку не можуть дістатися до даних іншого орендаря без окремого підвищення привілеїв на рівні ОС. Цей патерн суттєво зменшує поверхню міжорендної атаки й є мінімально життєздатною моделлю ізоляції для оборонного SaaS, що обслуговує орендарів різних рівнів секретності. Операційні витрати пропорційні кількості орендарів: кожен інстанс бази даних потребує власного розкладу резервного копіювання, конфігурації моніторингу, робочого процесу міграції схеми та пулу з'єднань. На десятках орендарів цим можна керувати з добре спроєктованою автоматизацією платформи; на сотнях це вимагає рівня абстракції бази даних як послуги, щоб тримати операційну рутину в межах.

Інстанс-на-орендаря веде розділення далі, виділяючи не лише процес бази даних, а й цілий обчислювальний вузол для робочих навантажень одного орендаря. Це потрібно, коли акредитаційна документація орендаря вимагає фізичного розділення, коли міжорендні побічні канали за часом є правдоподібною моделлю загроз або коли дані орендаря ніколи не повинні проходити мережеву тканину, спільну з іншими орендарями. Витратою є повний рахунок за інфраструктуру на орендаря: виділені вузли, виділене сховище, виділене мережеве обладнання в деяких конфігураціях. Для орендарів найвищого рівня секретності ця витрата не підлягає обговоренню: вимога безпеки керує архітектурою, а не економіка. Платформи, що обслуговують суміш рівнів секретності, часто реалізують багаторівневу модель: схема-на-орендаря для UNCLASSIFIED, база-даних-на-орендаря для SECRET, інстанс-на-орендаря для TS/SCI, з автоматизованими конвеєрами розгортання, що будують правильний рівень з файлу конфігурації онбордингу орендаря.

Ізоляція просторів імен Kubernetes: RBAC, мережеві політики та квоти ресурсів на орендаря

Оркестрація контейнерів вводить власний набір векторів міжорендного розкриття, які ізоляція бази даних сама по собі не вирішує. У кластері Kubernetes под в одному просторі імен може типово надсилати мережевий трафік до подів у будь-якому іншому просторі імен, перелічувати загальнокластерні ресурси, якщо його службовий обліковий запис має надмірні дозволи, та споживати загальнокластерні CPU та пам'ять, поки не виморить сусідні робочі навантаження. Для платформи оборонного SaaS жодне з цих типових налаштувань не прийнятне. Позиція ізоляції має застосовуватися як обов'язкова базова лінія під час розгортання кластера, забезпечуватися контролерами допуску, що відхиляють невідповідні визначення робочих навантажень, та безперервно перевірятися рушієм політик, що сповіщає про дрейф конфігурації.

Політика RBAC для багатоорендного оборонного Kubernetes починається з принципу, що службові облікові записи кожного орендаря типово мають нульову міжпросторову видимість. Ролі, прив'язані до простору імен, переважають над ролями кластера; прив'язки cluster-admin заборонені поза виділеним керувальним простором імен оператора платформи. Ресурси NetworkPolicy реалізують позицію типового заборонення в кожному просторі імен орендаря: жодного входу та жодного виходу, якщо це явно не дозволено правилом політики. Дозволені потоки вузькі — под застосунку орендаря може спілкуватися зі своїм власним подом бази даних, спільним контролером входу та кінцевою точкою служби керування ключами, і нічим іншим. Принципи архітектури мережі нульової довіри прямо відображаються на цю модель: кожен потік трафіку перевіряється, ніщо не довіряється неявно лише тому, що походить зсередини межі кластера.

Об'єкти ResourceQuota запобігають тому, щоб один орендар спричинив умову відмови в обслуговуванні проти інших орендарів, споживаючи непропорційні ресурси кластера. Кожен простір імен отримує квоти на запит та ліміт CPU, запит та ліміт пам'яті, сховище заявок на постійний том та кількість запущених подів. Об'єкти LimitRange встановлюють типові запити ресурсів на поди, які не оголошують їх явно, запобігаючи обходу системи квот необмеженими робочими навантаженнями. Для засекречених робочих навантажень taint-мітки вузлів та tolerations подів розширюють ізоляцію в фізичний рівень планування: вузли, виділені орендарю рівня SECRET, несуть taint-мітку, що запобігає плануванню подів UNCLASSIFIED на них, а специфікації подів орендаря SECRET несуть відповідний toleration. Поєднання RBAC простору імен, NetworkPolicy, ResourceQuota та taint-міток вузлів дає багаторівневу модель ізоляції, яку можна перевірити: кожен рівень задокументований, тестований та незалежно верифіковний.

Ізоляція ключів шифрування: окремі ієрархії ключів для кожного засекреченого орендаря

Шифрування — це засіб контролю, що змушує ізоляцію даних триматися навіть тоді, коли ізоляція на рівні інфраструктури зазнає невдачі. Якщо дані орендаря SECRET зашифровані ключем, до якого можуть звертатися лише авторизовані процеси цього орендаря, тоді неправильно налаштована мережева політика чи процес контейнера, що вирвався, не зможуть прочитати дані, навіть якщо отримають доступ до сирих байтів сховища. Ця гарантія вимагає, щоб ключі шифрування кожного орендаря керувалися в криптографічному просторі імен, недоступному для інших орендарів — не лише за політикою на рівні застосунку, а й через власний примус контролю доступу служби керування ключами.

Практична реалізація використовує ієрархічну структуру ключів. У корені знаходиться ключ шифрування ключів (KEK), специфічний для орендаря, що зберігається в партиції апаратного модуля безпеки (HSM) або просторі імен служби керування ключами, прив'язаному до службових облікових записів цього орендаря. KEK обгортає набір ключів шифрування даних (DEK), що використовуються застосунком для шифрування конкретних категорій даних: один DEK для оперативних записів, один для журналів аудиту, один для вкладень тощо. DEK зберігаються зашифрованими поруч із даними, які вони захищають; їх можна розгорнути лише процесом, якому надано доступ до KEK орендаря. Якщо зловмисник компрометує DEK ізольовано, він може розшифрувати цю категорію даних. Якщо він компрометує KEK, він потенційно може розшифрувати всі дані орендаря, але не може використати це для доступу до даних іншого орендаря, оскільки KEK іншого орендаря знаходиться в окремій партиції HSM чи просторі імен керування ключами з цілком незалежними політиками доступу. Середовища конфіденційних обчислень розширюють цю модель, захищаючи саму операцію розгортання DEK всередині апаратно верифікованого довіреного середовища виконання.

Політика ротації ключів така ж важлива, як і структура ключів. Орендар, чий KEK не ротувався два роки, має зростаючий радіус ураження: будь-які облікові дані, скомпрометовані в будь-який момент за останні два роки, потенційно все ще надають доступ до всіх даних, зашифрованих під цим KEK. Платформи оборонного SaaS мають забезпечувати автоматизовану ротацію KEK за розкладом, визначеним органом секретності орендаря — зазвичай щорічно для SECRET, частіше для вищих рівнів секретності — та надавати слід аудиту ротації, видимий під час акредитаційних переглядів. Сама подія ротації має реєструватися в потоці аудиту орендаря, мати позначку часу та бути приписана автоматизованій політиці ротації чи конкретному обліковому запису оператора, що її ініціював.

Забезпечення резидентності даних: утримання даних орендаря в межах авторизованих юрисдикцій

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

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

Вторинні засоби контролю стосуються шляхів даних, що менш очевидно пов'язані з резидентністю: пересилання журналів, телеметрія моніторингу та інструментарій підтримки. Платформа, що правильно обмежує зберігання даних авторизованим регіоном, але пересилає журнали застосунку до SIEM, що працює в іншій країні, має прогалину в резидентності. Так само сеанси віддаленого адміністрування, що проходять через робочу станцію інженера підтримки в неавторизованій юрисдикції, можуть нести фрагменти даних у стані сеансу. Платформи оборонного SaaS мають відстежувати кожен шлях даних — не лише первинний шлях даних застосунку — та застосовувати засоби контролю резидентності до всіх них. Це зазвичай вимагає окремої інфраструктури моніторингу на кожну зону резидентності та суворих засобів контролю того, які облікові записи операторів можуть ініціювати адміністративні сеанси проти яких середовищ орендарів.

Керування межами акредитації: хто володіє ATO, коли орендарі спільно використовують інфраструктуру

Межі authorization to operate (ATO) стають структурно неоднозначними в багатоорендній платформі оборонного SaaS. Постачальник платформи експлуатує спільну інфраструктуру — площину керування Kubernetes, службу керування ключами, мережеву тканину, постачальника ідентичності — й утримує ATO, що охоплює ці компоненти. Кожен орендар експлуатує робочі навантаження застосунків та дані, що сидять поверх цієї інфраструктури, та може утримувати окреме ATO для власної межі системи. Питання про те, де закінчується ATO платформи й починається ATO орендаря, не є теоретичним занепокоєнням: воно визначає, хто відповідає за кожен засіб контролю безпеки, хто є уповноваженою посадовою особою для змін до цього засобу контролю та хто несе відповідальність, якщо засіб контролю зазнає невдачі.

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

Керування змінами на рівні платформи запускає зобов'язання переакредитації, що каскадно поширюються на орендарів. Коли постачальник платформи модифікує спільний компонент — оновлює версію Kubernetes, змінює механізм примусу мережевої політики, модифікує модель політики доступу служби керування ключами — уповноважена посадова особа кожного орендаря має переглянути зміну та підтвердити, що успадковані засоби контролю орендаря все ще дійсні. Це створює координаційні накладні витрати, що зростають із кількістю орендарів: одне оновлення платформи може вимагати сповіщення та отримання підтвердження від десятків незалежних уповноважених посадових осіб. Платформи оборонного SaaS, що добре цим керують, інвестують у формальний процес комунікації змін, попередньо узгоджені терміни сповіщень та шаблонне формулювання, яке уповноважені посадові особи орендарів можуть використовувати для документування своїх рішень про переакредитацію з мінімальною переробкою.

Журналювання аудиту на орендаря: сегреговані сліди аудиту для міжорендної криміналістики

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

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

Міжорендне криміналістичне розслідування — реконструкція інциденту, що міг залучати кількох орендарів — вимагає, щоб оператор платформи корелював події між кількома ізольованими приймачами журналів. Ця кореляція має виконуватися за допомогою інструментарію з привілеями оператора платформи, що сам генерує записи аудиту, а не шляхом злиття потоків журналів орендарів у спільний рівень сховища. Спільна база даних аудиту, що зберігає події кількох орендарів, відтворила б проблему міжорендного змішування даних, яку архітектура ізольованого приймача журналів була покликана запобігти. Натомість криміналістичний інструментарій запитує приймач журналів кожного орендаря незалежно та збирає міжорендну часову шкалу в пам'яті, у середовищі оператора, ізольованому від усіх середовищ орендарів і самому підлеглому журналюванню аудиту. Цей патерн зберігає ізоляцію журналів орендаря, водночас уможливлюючи криміналістичну спроможність на рівні платформи, якої потребують команди операцій безпеки.