Частина 5: Genesis of Ledger Recover - Операційна безпека | Леджер

Частина 5: Genesis of Ledger Recover – Operational Security | Леджер

Поки що ми показали в частинах 1 і 2, як відновити Ledger розділяє ваше насіння на частки та безпечно надсилає ці акції до друзі надійні постачальники резервних копій. У частині 3 ми показали, як це зробити безпечно зберігає (і відновлює) частки вашого насіння, захищений апаратним шифруванням, прив’язаний до вашої особи та різноманітний. У частині 4 ми дослідили, як Ledger Recover вдається надати доступ до резервної копії лише вам.

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

  • Зміцнення інфраструктури, що лежить в основі Ledger Recover,
  • Застосовуючи розподіл обов’язків для різних операторів Ledger Recover,
  • Моніторинг критичних компонентів і операцій,
  • Впровадження спеціального реагування на інцидент Recover.

Давайте детально розберемо значення кожного з цих елементів.

Зміцнення інфраструктури

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

Частина 5: Genesis of Ledger Recover - Операційна безпека | Ledger PlatoBlockchain Data Intelligence. Вертикальний пошук. Ai.
Частина 5: Genesis of Ledger Recover - Операційна безпека | Леджер

Ось короткий перелік наших ключових заходів щодо зміцнення інфраструктури Ledger Recover:

Доступність послуги

Інфраструктура створена так, що є відсутність єдиної точки відмови (NSPOF), що означає, що система є стійкою до відмови будь-якого компонента. Візьмемо такий приклад: наші центри обробки даних обслуговуються двома незалежними постачальниками послуг Інтернету (ISP) у двох протилежних кінцях будівлі. Якщо оптоволокно пошкоджено через поточні будівельні роботи в одній частині будівлі, дані просто будуть направлені через іншого провайдера. Технічне обслуговування без збоїв є ще однією перевагою, яка підвищує доступність. Враховуючи, що існує принаймні два екземпляри всіх програмних компонентів Ledger Recover, ми можемо переналаштувати систему, щоб використовувати лише екземпляр A під час заміни/оновлення/виправлення екземпляра B.

Обмежений доступ адміністратора до програм Ledger Recover

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

Захищені фізичні центри обробки даних

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

Ізоляція ресурсів Ledger Recover

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

Безпека на рівні коду забезпечується кількома стовпами
  • Ми використовуємо сканери коду щоб допомогти нам визначити та усунути вразливості на ранній стадії, не даючи їм потрапити у виробництво.
  • код is відгуки і затверджено by незалежна команда одного, що розробляє Ledger Recover. Це поділ є ще одним заходом для покращення загальної якості коду шляхом виявлення логічних недоліків, які можуть призвести до проблем безпеки.
  • Код критичні модулі Ledger Recover є підписано за допомогою криптографічного підпису. Підпис частково генерується на основі вмісту коду, що запобігає розгортанню підробленого коду шляхом порівняння підпису з його очікуваним значенням. Ця перевірка безпеки виконується перед виконанням коду.
Контроль мережевого трафіку

Мережевий трафік жорстко контролюється за допомогою політик, які визначають правила для потоків трафіку для всіх 3 постачальників резервних копій. за визначення правил дозволеного та забороненого трафіку, ми обмежуємо поверхню атаки та знижуємо ризик несанкціонованого доступу. Крім того, обмеження зв’язку між окремими службами гарантує, що бічний рух зловмисника обмежений, навіть якщо один компонент скомпрометований. Крім того, ми застосовуємо взаємну автентифікацію TLS (mTLS), щоб запобігти атакам Man-in-the-Middle (MiM). Перевіряючи особу обох сторін за допомогою сертифікатів, взаємний TLS гарантує це лише надійні організації можуть встановити безпечне з’єднання.

Обертання ключів

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

Безпека вихідного трафіку

Вихідний трафік обмежується лише відомими доменами та IP-адресами (постачальники резервних копій, постачальники послуг). Обмеження та моніторинг вихідного трафіку є способом стежити за можливим витоком даних. Якщо обсяг вихідних потоків даних перевищує очікуваний, зловмисник може витягувати конфіденційні дані з системи Ledger Recover у значному масштабі. 

Безпека вхідного трафіку

Вхідний трафік захищено комбінацією методів захисту від DDoS, фільтрації веб-додатків (WAF) і фільтрації IP-адрес. Розподілені атаки типу «відмова в обслуговуванні» (DDoS) завдають шкоди, переповнюючи цільову систему запитами. Обмеження кількості вхідних запитів є загальновідомим заходом проти таких атак. Тепер не всі атаки стосуються кількості, деякі з них стосуються якості. Ось де вступає в гру WAF. WAF переглядає вхідні запити та перевіряє їх заплановану поведінку: якщо запит спрямований на отримання несанкціонованого доступу або маніпулювання даними, фільтр блокує запит. Нарешті, IP-фільтрація використовує подвійну техніку: a) білий список, тобто дозволяючи трафік лише з певних IP-адрес або діапазони, і b) чорні списки, тобто блокування трафік з відомих IP-адрес зловмисника.       

Управління вразливістю

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

Розмежування обов'язків

Розподіл обов'язків є основою стратегії безпеки Ledger Recover. 

Розподіл обов'язків між різними Постачальники резервних копій (частина 3) і Постачальник IDVs (частина 4) описано в попередніх постах. Ви можете пригадати, що існують:

  • 3 частки секретної фрази відновлення, керовані 3 незалежними постачальниками резервних копій (з диверсифікацією бази даних для запобігання змові)
  • 2 незалежні валідатори ідентифікації (постачальники IDV)

На рівні інфраструктури, розподіл обов'язків застосовується між різними ролями, залученими до розробки та експлуатації Ledger Recover.

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

Тому, коли «найменший привілей» поєднується з «розподілом обов’язків», різні ролі адміністратора призначені різним людям щоб жодна особа не могла пошкодити/порушити конфіденційність або цілісність будь-якого компонента системи. Наприклад, розробники коду Ledger Recover не мають доступу до системи, у якій працює код, який вони написали.

Частина 5: Genesis of Ledger Recover - Операційна безпека | Ledger PlatoBlockchain Data Intelligence. Вертикальний пошук. Ai.
Частина 5: Genesis of Ledger Recover - Операційна безпека | Леджер
Управління: Кворуми

Подібно до консенсусних механізмів Blockchains, які гарантують цілісність і безпеку завдяки тому, що кілька учасників перевіряють блоки, ми прийняли кворум у системі Ledger Recover для підвищення нашої операційної безпеки.

Незважаючи на ретельну перевірку наших працівників, факт залишається фактом: люди можуть бути слабкою ланкою в будь-якій системі, і криптосфера не є винятком. Високі інциденти безпеки, такі як Злом Mt.Gox 2014 року, продемонструвати, як люди можуть бути використані або призвести до провалів безпеки. На людей можна вплинути або примусити їх через різні мотивації – гроші, ідеологію, примус, его (також також MICE(S)), що робить навіть найсуворіші перевірки не зовсім надійними.

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

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

Ось деякі види діяльності, у яких ми використовуємо кворум:

1. Створення приватних ключів для HSM Ledger Recover: Ця важлива операція захищена незалежними кворумами в кожній організації – Coincover, EscrowTech і Ledger. Кожен член цих окремих кворумів має бути присутнім для генерації закритих ключів у своїх відповідних HSM. Кожен член кворуму має доступ до резервного ключа, який є вирішальним для відновлення та регенерації їхніх секретів HSM, якщо це необхідно. Ця структура не лише захищає від ризику неправомірного впливу будь-якої особи на один із трьох HSM постачальників резервних копій, але й покращує загальну цілісність системи, оскільки кожен кворум працює незалежно та не знає про специфіку один одного.

Частина 5: Genesis of Ledger Recover - Операційна безпека | Ledger PlatoBlockchain Data Intelligence. Вертикальний пошук. Ai.
Частина 5: Genesis of Ledger Recover - Операційна безпека | Леджер
Майте на увазі, що навіть повністю скомпрометований кворум не може поставити під загрозу активи користувачів. Пам'ятайте з пост у блозі 2: Кожен постачальник резервного копіювання обробляє лише один спільний ресурс. Без усіх необхідних спільних ресурсів реконструкція початкового коду користувача неможлива. 

Крім того, видобуток закритого ключа HSM, який необхідний для розшифровки існуючих спільних ресурсів, неможливо виконати за допомогою резервних ключів кворуму. Члени кворуму постачальника резервних копій зможуть лише відновити та повторно створити новий HSM.

2. Прийняття рішення про позачергове вивільнення частки клієнта: певні, хоча й рідкісні, ситуації можуть вимагати виняткового звільнення частки клієнта. Це може статися через помилки підтвердження особи (зміна імені, фізичне спотворення тощо) або якщо наші нерозголошені заходи безпеки неправильно блокують пристрій у чорному списку. Коли виникає така ситуація, збирається кворум, що складається з кількох осіб із резервних постачальників. Ця процедура, яка потребує широкого консенсусу, гарантує, що рішення не приймаються поспішно чи в односторонньому порядку, тим самим підвищуючи безпеку клієнтів. Кожен член кворуму використовує свій пристрій Ledger Nano (з власним PIN-кодом), щоб схвалити випуск, додаючи ще один рівень безпеки від можливої ​​змови чи індивідуальних помилок.

3. Підписання оновлення коду мікропрограми HSM: перед розгортанням нового оновлення мікропрограми для HSM наша команда безпеки продуктів, Ledger Donjon, проводить комплексний процес перевірки. Будучи частиною кворуму прошивки, Ledger Donjon гарантує, що жодні бекдори чи зловмисний код не були впроваджені зловмисним інсайдером або скомпрометованим конвеєром розробки через атаку на ланцюг поставок. Таким чином вони зберігають цілісність і безпеку оновлення мікропрограми.

4. Оновлення мікропрограми пристроїв Ledger (Nano та Stax): Подібно до мікропрограми для HSM, оновлення мікропрограми нашого пристрою Ledger проходять суворий процес перевірки та вимагають схвалення кворуму, перш ніж вони будуть запропоновані нашим користувачам через Ledger Live.

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

Моніторинг критичних компонентів і операцій

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

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

Давайте розглянемо кілька прикладів нашого багаторівневого підходу:

Моніторинг діяльності адміністратора: Ми встановлюємо суворий контроль доступу для наших адміністраторів. Ми не лише вимагаємо 2FA (двофакторну автентифікацію) для всіх адміністративних з’єднань з нашою інфраструктурою, але також обов’язково перевіряємо кілька осіб для доступу адміністратора до інфраструктури критичних частин системи. Крім того, наші системи ретельно реєструють і відстежують кожну адміністративну діяльність. Ці журнали автоматично порівнюються з нашими внутрішніми системами квитків, щоб виявити будь-які незаплановані дії. Ця обережна кореляція дає нам змогу негайно сповіщати наші служби безпеки про будь-яку незвичайну чи підозрілу поведінку, посилюючи нашу оперативну безпеку.

Перехресний контроль між постачальниками резервних копій: Прозорість і підзвітність є основою відносин між постачальниками резервних копій, Ledger, EscrowTech і Coincover. Ми налагодили обмін журналами в режимі реального часу, які використовуються для моніторингу та безпеки системи. Це дає можливість перехресної перевірки діяльності. Якщо виявляється будь-яка невідповідність, служба негайно блокується, щоб захистити активи користувачів.

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

Використання інформації про безпеку та управління подіями (SIEM): Рішення SIEM є важливою частиною стратегії моніторингу Ledger Recover. Цей спеціальний SIEM покращує здатність виявляти потенційні проблеми безпеки та реагувати на них у режимі реального часу. Завдяки спеціальним правилам виявлення, спеціально розробленим для служби Ledger Recover, він точно налаштований для ідентифікації різноманітних індикаторів компрометації (IoC) на основі кластерів і журналів програми Ledger Recover. У разі виявлення спеціального IoC реакція відбувається автоматично та негайно – увесь кластер блокується, доки не буде проведено ретельний аналіз. У службі Ledger Recover конфіденційність має пріоритет над доступністю послуги, щоб забезпечити максимальний захист активів користувачів.

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

Реагування на інцидент Ledger Recover

За допомогою послуги Ledger Recover було створено стратегію реагування на інциденти, розроблену спільно з трьома постачальниками резервних копій. Центральною частиною цієї стратегії є автоматичні засоби захисту, які негайно блокують всю систему після виявлення підозрілої активності в будь-якій частині інфраструктури. 

По суті, протокол «завжди безпечний, ніколи не шкодує» був розроблений у службі Ledger Recover. Безпека є пріоритетом номер один, і це зобов’язання, яке ніколи не порушиться. 

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

Висновок

Ось ми й підійшли до кінця частини цієї серії, присвяченої операційній безпеці. У цій частині ми спробували відповісти на будь-які ваші занепокоєння щодо того, як забезпечується неприступність заходів безпеки системи Ledger Recover. Ми говорили про інфраструктуру, розподіл обов’язків, управління та моніторинг і, нарешті, стратегію реагування на інциденти. 

Ще раз дякую, що дочитали до цього моменту! Тепер ви повинні мати повне розуміння операційної безпеки Ledger Recover. Заключна частина цієї серії дописів у блозі буде про останні проблеми з безпекою, які ми мали, а точніше: як ми керували внутрішніми та зовнішніми перевірками безпеки, щоб гарантувати максимальний рівень безпеки для наших користувачів? Залишайтеся на зв'язку! 

Часова мітка:

Більше від Гросбух