Apple PCC

Я тут розгриз блог-пост про епловський Private Cloud Compute, і, чесно кажучи, підхід до проблеми вражає. Якщо ви не в темі — Епл робить сервіс для Епл хоче мати сервіс, де вони залізно можуть сказати “це — дуже приватно”. Але ж якщо просто зробити сек’юрний та приватний сервіс, як це довести? Є кілька проблем з доведенням цього факту:

• Конфігурацію сервера складно верифікувати зовні

• Визначити, який софт відповідає в якості сервісу, складно

• Що робити з адмінами, які можуть все споганити?

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

1. Сильно звужений ланцюжок постачальників, щоби влізти в нього було дорожче і це було легше поміти.

2. Кожен сервер перед закриванням фоткається з високою роздільністю.

3. Коли сервер прибуває в датацентр, “we perform extensive revalidation” перед встановленням.

4. Для завантаження використовується Secure Boot, який завантажує тільки підписаний софт.

5. Інсталяція софта залишає записи десь? Це я так зрозумів фразу “approved for that specific PCC node”.

6. Що цікавіше, використовується Secure Enclave — так само як в айфонах. Забезпечує сек’юрність і незмінність розділу, де зберігається ОС та моделі. Стежить, щоби завантажений код неможливо було змінити чи підмінити під час виконання. Забороняє JIT, щоб новий код не виникав сам по собі.

7. Операційна система — це власне обрізана iOS/macOS, зі значно зменшеною поверхнею для атаки: наприклад, там немає ні ssh, ні будь-яких інших засобів віддаленого керування.

8. Увесь (новий) код написан на Swift’і, щоби не було питань із безпекою доступу до пам’яті.

9. Під час кожного завантаження Secure Enclave генерує новий випадковий ключ для шифрування диску (на який попадають користувацькі дані) і не зберігає цей ключ нікуди. Таким чином можна бути певним, що після перезавантаження дані на диску прочитати буде неможливо.

10. Окрім цього, кожен процес виконується у sandbox’і, з увімкненим Pointer Authentication Codes — це система, яка заважає підмінювати адреси функцій і адреси повернення (тобто крек для фотошопу в такому середовищі не спрацює 😁).

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

12. Очевидно, e2e шифрування зробити неможливо — бо сервісу потрібно мати доступ до власне даних. Але кожен запис шифрується публічними (верифікованими під час виконання айфоном) ключами ноди PCC — таким чином жодна прокся/балансувальник їх прочитати не можуть. [Це вони https описали чи шо? Трохи не вистачає порівнянь із загально прийнятими практиками]

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

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

15. Нагадаю, немає ssh чи ще чогось типу RDP — підписування коду і Secure Enclave теж завадили би запуску зайвого коду, але інтерактивний шел давав би значно більшу поверхню для атак на систему.

16. Інструментарій для спостереження за системою теж дуже обмежений. Скажімо, логи, які покидають машину, задаються заздалегідь, і проходять кілька рівнів незалежного рев’ю для апруву — де стежать, щоби в них не попадали користувацькі дані.

17. Кожен реліз софта для PCC публічний! Бінарна збірка мається на увазі, не джерельний код.

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

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