Де мають жити облікові дані панелі

Кожна хмарна панель керування для автоматизації серверів питає в майстрі налаштування те саме: адресу вашого гіпервізора, токен API, кореневі облікові дані вашої панелі вебхостингу. Далі вона їх зберігає, бо вони потрібні їй на кожному запиті.

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

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

Зашифровано в стані спокою, а розшифровує хто

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

Це не аргумент проти шифрування в стані спокою. Це аргумент, що питання «де ключ» є єдиним питанням, і що площина керування, яка вміє розшифровувати, це площина керування, яку можна змусити розшифрувати.

Структурна альтернатива це третій рядок: не мати секрету взагалі. Що звучить спритно, поки ви не подивитеся, чого коштує це влаштувати.

Тримайте секрет там, де машина

Форма, яка працює: маленький агент працює всередині власної мережі клієнта, тримає облікові дані локально й зʼєднується назовні з платформою. Платформа надсилає вказівки. Агент тримає ключі.

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

Частини, які роблять це справжнім, неефектні.

Сховище і від чого воно чесно захищає

Наш агент зберігає облікові дані в локальному файлі, зашифрованому XChaCha20-Poly1305. Ключем не є файл на диску: його виведено через HKDF із файла ключа, змішаного з власною ідентичністю машини, а додаткові автентифіковані дані привʼязують шифротекст до версії формату й до ідентифікатора агента.

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

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

Облікові дані ніколи не торкаються бази даних платформи

Це та частина, яку легко зробити неправильно, вважаючи, що зробив правильно, бо код має пристойний вигляд і так, і так.

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

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

Видалити секрет це інша задача, ніж зберегти його

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

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

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

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

Що вкрадений сертифікат агента може, а чого не може

Якщо агент автентифікується клієнтським сертифікатом, чесне питання це що станеться, коли хтось його забере. Конкретика тут корисніша за сторінку про безпеку.

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

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

Сам по собі він не дає облікових даних. Сертифікат це ідентичність для розмови з платформою. Ключ сховища окремий, живе на хості й привʼязаний до ідентичності тієї машини. Той, хто має обидва, має root на машині, і в цій точці сертифікат це найменша з бід.

Він перестає працювати, щойно ви скажете, приблизно за хвилину. Відкликання це стан у базі даних, а не CRL і не OCSP. Нове зʼєднання відхиляють негайно. Наявне зʼєднання перевіряють наново з інтервалом в одну хвилину, тож у вже підключеного зловмисника є щонайбільше стільки. Якщо сама перевірка статусу продовжує падати, сесію закривають після трьох послідовних збоїв, а не тримають відкритою нескінченно, що обмежує найгірший випадок приблизно трьома хвилинами.

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

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

Чого це не виправляє

Три речі, сказані прямо, бо модель загроз без залишкового ризику це маркетингова сторінка.

Скомпрометована площина керування все одно може віддавати команди. Вона не може вкрасти ваші токени, але може наказати вашому агентові видалити машину, і агент це зробить. Перенесення секретів переносить радіус ураження; воно його не прибирає. Натомість ви отримуєте те, що шкода обмежена тим, що вміє висловити API, і видима у сліді аудиту, замість зловмисника з вашими обліковими даними, який робить що завгодно просто проти вашого гіпервізора о третій ночі.

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

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

Питання, які варто поставити постачальнику

Хоч би що ви зрештою купили, ці пʼять відділяють продукти, які про це подумали, від тих, що написали абзац:

1. 01Де фізично лежить ключ розшифрування? Якщо відповідь «у нашій платформі», то шифрування в стані спокою захищає від крадіжки диска й більше ні від чого.
2. 02Що у вашому журналі аудиту й у черзі завдань? Секрети витікають туди значно частіше, ніж у таблицю, щодо якої хтось був обережний.
3. 03Що стається з обліковими даними, коли я видаляю інтеграцію, і чи можу я побачити, чи це справді сталося?
4. 04Скільки часу займає відкликання доступу і чи діє воно на сесії, які вже відкриті?
5. 05Чи потрібен хоч чомусь вхідний порт? Правило фаєрвола, що впускає діапазон IP постачальника до інтерфейсу керування вашого гіпервізора, це друга, тихіша версія тієї самої проблеми.

Саме так ми це побудували в Provibr: агент працює на власному залізі клієнта, тримає облікові дані локально й зʼєднується лише назовні.