Суверенността е свойство на контролната равнина
Представете си workload във Франкфурт, чиито данни остават там. Самото местоположение не показва кой може да даде административен достъп, да получи ключа за декриптиране на диска, да замени софтуера, който управлява облака, да промени одитната му следа или да го възстанови след отказ.
Това са въпроси за контролната равнина. Един облак е суверенен само когато неговият оператор разполага с правомощията, ключовете, софтуера и знанията да го поддържа без разрешение от външна страна. Операторът трябва също да може да премести или изведе платформата от експлоатация, без да загуби достъп до данните, конфигурацията или състоянието на контролната равнина.
Преместването на един компонент в центъра за данни на оператора не премества непременно и контрола върху него. Компонентът може да продължи да зависи от доставчик на идентичност, услуга за управление на ключове, регистър за контейнери, удостоверяващ орган или процедура за възстановяване, контролирана от някой друг. Самостоятелното хостване на един компонент често разкрива следващата зависимост.
За мен пет конкретни проверки са по-полезни от спор дали един облак заслужава да бъде наречен суверенен. Заедно те обхващат правомощията, контрола върху ключовете, доказателствата, работата без външни услуги и преместването към друга платформа. Те не са схема за сертифициране. Всяка проверка започва с конкретна зависимост или отказ. Без това твърдението за независимост е твърде неясно, за да бъде проверено.
Проследете пътя на контрола
Твърдението за независимост трябва да казва какво операторът трябва да може да прави сам и какво трябва да продължи да работи, когато външна услуга не е достъпна. Може ли операторът да обнови и рестартира платформата без помощ от доставчика? Може ли да попречи на инфраструктурния доставчик да декриптира диск? Може ли да премести workload-ите и състоянието на контролната равнина другаде? Това са различни твърдения и за тях са нужни различни доказателства.
Вземете една обикновена заявка за създаване на машина. Потребителят се удостоверява пред услуга за идентичност. API прилага политика за достъп. Контролер извиква инфраструктурния доставчик. Услуга за ключове може да предостави ключа за диска. Услуга за одит записва случилото се. Софтуерът зад тези услуги е минал през build и release система. Целият път зависи и от DNS, сертификати и точно време.
Проследявам заявката през всяка система, която може да я разреши, изпълни или запише какво се е случило. За всяка система по този път искам да знам кой я управлява, кой държи административните данни за достъп, кои ключове може да използва и какво става, когато системата не е достъпна. Искам да знам и дали операторът може да я замени, без да загуби достъп до съществуващи workload-и или данни.
Външната зависимост не е непременно проблем. Една организация може съзнателно да използва федеративен доставчик на идентичност или да разчита на доставчика на софтуера за обновявания. Това е напълно приемливо, но ограничава какво може да твърди операторът. Той не е независим от услуга, без която все още не може да администрира или възстанови облака, да декриптира данните му или да провери доказателствата от одита.
1. Външна страна не може сама да си даде административни права
Идентичността е на първо място, защото всеки друг контрол зависи от това кой има право да действа. Фактът, че услугата за идентичност работи локално, не доказва, че операторът контролира административния достъп. Може да съществуват акаунт за поддръжка на доставчика, отдалечена услуга за възстановяване или друг издател на токени, които платформата приема за административен достъп.
Обхватът е също толкова важен, колкото и удостоверяването. Ако един API приема идентификатор на тенант или проект от извикващата страна и го третира като факт, валидни данни за достъп могат да са достатъчни за навлизане в чужд обхват. Платформата трябва да извлече този обхват от достоверна информация за идентичността и състоянието на ресурсите и едва тогава да приложи политиката.
Изключенията заслужават повече внимание от нормалния път. Аварийна администраторска идентичност може да е необходима, но кой може да я активира? Ограничено ли е използването ѝ във времето и записва ли се? Може ли операторът да я деактивира без помощ от външната страна, която я контролира? Постоянни данни за достъп на доставчика, скрити зад думите “достъп за поддръжка”, остават външен източник на административни права.
Започнете с данни за достъп за идентичност без никакви права и докажете, че заявената операция е отказана. Дайте на тази идентичност право за едно тясно определено действие и докажете, че то работи. Отменете данните за достъп и докажете, че те спират да работят. След това опитайте да преминете в друг тенант или проект, като промените данните в заявката. Накрая опишете всеки път, който може да създаде администратор, да възстанови административен акаунт или да се представи за такъв.
Това не изисква всяка организация да изгради собствен доставчик на идентичност. Федерацията може да бъде съзнателно избрана и разумна зависимост. Операторът обаче трябва да контролира кои издатели са доверени, да може да отнеме това доверие и да разполага с път за възстановяване, който външният издател не може да заобиколи.
2. Операторът може да разреши или откаже декриптиране, без да предава контрола върху ключовете
Криптирането на съхранените данни означава, че те се пазят като шифротекст. То не казва кой може да ги превърне обратно в четим вид.
Много облачни дискове използват envelope encryption. Един ключ криптира данните на диска, а втори ключ криптира първия. Клиентът или операторът може да пази втория ключ в собствена услуга за управление на ключове. Този ключ не обработва всеки блок от диска, но без него платформата не може да получи ключа за данните.
Това оставя два въпроса. Кой държи обвиващия ключ и кой има право да го използва? Съхраняването му в контролиран от оператора HSM не е достатъчно, ако една платформена идентичност с твърде широки права може да използва ключа за всеки диск. Политиката трябва да свързва всяка заявка с workload-а и ресурса, за които се отнася. HSM, или хардуерен модул за сигурност, защитава ключовия материал. Сам по себе си той не решава кой workload има право да използва даден ключ.
Проверете това, като направите контролираната от оператора услуга за ключове недостъпна, докато останалата част от платформата продължава да работи. Нов опит за отваряне на диска или стартиране на машина, която го използва, трябва да се провали, защото платформата не може да получи ключа за данните, а не защото цялата контролна равнина е спряна. Възстановете достъпа до обвиващия ключ и прочетете същите данни от същия диск.
Същата проверка показва и къде свършва този контрол. Отнемането на достъпа не позволява на платформата да получи отново ключа за диска. То не може да отнеме обратно четимите данни или ключовия материал, които вече се намират в работещ хост. Изтриването на обвиващия ключ също не е по-силна проверка на контрола. То може да докаже единствено, че операторът може да направи собствените си данни невъзстановими.
3. Операторът може да запази и независимо да провери доказателствата от одита
Страница с одитни записи е полезна при нормална работа. Тя е слабо доказателство, когато една и съща контролна равнина съхранява събитията, отговаря на заявката и решава дали собственият ѝ отговор е валиден.
Операторът трябва да може да изнесе доказателствата извън системата, която ги създава. Обикновено това означава експортирани събития, подписани потвърждения, запазени ключове и самостоятелен инструмент за проверка. Подписите позволяват да бъде открита промяна в събитията. Свързването на всяко потвърждение с предходното разкрива празнини в последователността. За да бъдат открити събития, премахнати от края, е нужна и запазена доверена контролна точка.
Неуспешните действия също трябва да присъстват в доказателствата. Одитна следа, която записва успешните административни действия, но пропуска отказаните заявки, опитите с отменени данни за достъп или неудостоверените заявки, оставя празнина при разследване на атака или неправилно внедрена политика. Ако една неудостоверена заявка твърди, че идва от Алиса, одитният запис не трябва да посочва Алиса като удостоверен потребител.
Експортирайте кратка поредица от събития заедно с всичко необходимо за нейната проверка. Направете три копия. В първото променете поле, във второто променете връзката към предходното събитие, а от третото премахнете последното събитие. Независимият инструмент трябва да отхвърли всяко копие, без да се свързва с първоначалната услуга. След това сменете ключа за подписване и покажете, че по-старите доказателства остават проверими.
Използвам “промените могат да бъдат открити”, а не “данните са неизменяеми”. Подписът не пречи на някого да изтрие файл. Верига от хешове може да разкрие липсващо събитие само ако проверяващият разполага с по-късна връзка или с доверена контролна точка за сравнение. Архитектурата трябва също да казва кой пази тази точка, кои събития са включени и колко дълго се съхраняват доказателствата.
4. Операторът може да продължи да работи без външни услуги
Инсталирането на софтуер в центъра за данни на оператора не прави платформата автоматично независима. Тя може да работи без проблеми с месеци и да не успее да се рестартира без публичен container registry. Подновяването на сертификати може да зависи от външен CA. Хостовете може да зависят от публични NTP сървъри или DNS resolver-и. При обновяване платформата може да изтегли Helm chart, пакет или база с уязвимости, които никога не са били включени в доставката.
Тези зависимости лесно се пропускат, защото са извън основния път на заявките. Те се появяват при инсталиране, рестартиране, мащабиране, подновяване на сертификати, обновяване и диагностика. Всяка от тези операции се нуждае от собствена проверка без външна свързаност. “Работи без достъп до интернет” е твърде общо твърдение, ако не казва кои операции са били изпълнени и за колко време.
Операторът трябва вече да разполага с deployment конфигурацията, артефактите, корените на доверие и инструкциите за възстановяване на платформата. Подписите на версиите трябва да могат да бъдат проверени без връзка с доставчика. Списъкът на артефактите трябва да идва от генерираните deployment манифести, а не от ръчно поддържан списък. Helm chart-овете често добавят container images, които не се виждат в основния списък с компоненти.
Отказът на инфраструктурния доставчик е друга полезна проверка. Прекъснете достъпа до инфраструктурния API и наблюдавайте какво става с четенето, записването, reconciliation процесите и health checks. Контролната равнина може да продължи да връща локално записаното състояние и да отказва нови промени. Това може да е правилното поведение. Може и да се отчита като изправна, докато фоновите процеси натрупват заявки, които никога не могат да завършат. И двете поведения са невидими в архитектурна диаграма.
Писането на оперативни процедури е част от тази проверка. Rollback процедура, която казва само “възстановете при нужда”, пропуска трудната част. Опишете командите, входните данни, реда на изпълнение и очакваното състояние. Всяка стъпка, която трябва да бъде измислена по време на писането, е нерешена инженерна задача.
5. Операторът може да възстанови, премести и изведе платформата от експлоатация по проверени процедури
Преносимостта често свършва на границата на един API. Бизнес логиката е отделена от адаптера към доставчика, интерфейсът изглежда чист и проектът е обявен за преносим. Това е полезно доказателство на ниво дизайн. То не е същото като преместването на работеща система.
Преместването от една платформа включва повече от дисковете на workload-ите. Операторът може да се нуждае от състоянието на идентичностите и политиките, метаданните за ключовете и материалите за възстановяване, доказателствата от одита, DNS, сертификатите, конфигурацията за внедряване и корените на доверие, използвани за приемане на дадена версия. Целевата платформа трябва да предоставя еквиваленти на инфраструктурните възможности, от които зависи workload-ът. Втори доставчик с различен модел за съхранение или мрежа може да предостави същия API само ако тези разлики са изразени някъде явно.
Възстановяването разкрива сходен проблем. Представете си, че базата на контролната равнина е възстановена до вчерашното ѝ състояние. Машини и дискове, създадени след резервното копие, може все още да съществуват при инфраструктурния доставчик, но възстановената контролна равнина вече не знае, че ги притежава. Успешното възстановяване на базата може следователно да остави ресурси без собственик. Ако платформата не може да ги открие отново и да съгласува състоянието им, резервното копие е само част от плана за възстановяване.
Сериозната проверка за преместване започва с чиста контролна равнина. Операторът импортира необходимото състояние и го съгласува с това, което действително съществува. Ако се твърди поддръжка на няколко инфраструктурни доставчика, проверката трябва да използва реален втори адаптер, вместо да приема самия интерфейс за доказателство. Накрая операторът премахва идентичностите за поддръжка, свързани със старата платформа, изважда ключовете за подписване на предишния доставчик от хранилището на доверени ключове и отнема достъпа му до услугите за ключове. Докато тези стъпки не бъдат изпълнени, преместването е само проект, а не проверена оперативна възможност.
Десет въпроса за технически преглед на суверенността
Бих започнал техническия преглед със следните въпроси:
- Кой може да даде административен достъп, да възстанови администраторски акаунт или да се представи за него? Може ли операторът да отмени всеки път за външен достъп?
- Обхватът на тенанта, проекта и ресурса извлича ли се от доверено състояние, или се приема от извикващата страна?
- Кой може да поиска достъп до ключа за криптиране на данни и коя система решава дали да го даде?
- Може ли операторът да отнеме и възстанови достъпа до ключа, без да унищожи ключа или да спре цялата платформа?
- Могат ли доказателствата от одита да бъдат експортирани и проверени, без да се пита системата, която ги е създала?
- Може ли независима проверка да открие променени или пропуснати събития и включват ли доказателствата неуспешните и отказаните заявки?
- Кои критични операции спират, когато услугите на доставчика станат недостъпни или връзката с публичния интернет прекъсне?
- Може ли операторът да изгради платформата отново от артефакти, корени на доверие и инструкции, с които вече разполага?
- Може ли операторът да възстанови състоянието на контролната равнина и да съгласува ресурсите, които възстановената база вече не вижда?
- Доказала ли е практическата проверка, че операторът може да премести данните, ключовете, идентичностите и доказателствата си на друга платформа? Може ли да установи там същите права за оператора, да изведе старата платформа от експлоатация и да отмени всеки останал път за достъп?
Местоположението на данните продължава да има значение, защото казва на операторите и потребителите къде се пазят данните. То не казва кой контролира системите, които могат да имат достъп до тях, да ги преместват или възстановяват.
Отворената инфраструктура помага, защото може да бъде проверявана, управлявана и заменяна. Това дава на оператора повече начини да остане независим, но само по себе си не осигурява нужните умения, артефакти или процедури за възстановяване.
Не бих приел нито едно от тези твърдения само по архитектурна диаграма. Отменете данните за достъп на администратор. Отнемете достъпа до ключ и после го възстановете. Покажете, че променен одитен запис не преминава проверката. Прекъснете връзката с външните зависимости. Изпълнете процедурата за преместване. Докато тези проверки не бъдат изпълнени, суверенността остава намерение в архитектурата, а не качество на работещата система.