Ваша команда знаходить API-ключ у журналі застосунку безпосередньо перед серією виплат. Негайне питання полягає не лише в тому, хто його скопіював, а й у тому, чи може цей обліковий параметр авторизувати виведення з кожного гаманця.
Саме це операційне завдання стоїть за багаторівневим захистом. Криптоплатформі потрібні заходи, які залишаються дієвими, коли інший захід не спрацював, а не просто довший перелік засобів безпеки.
Зміст
- Чому одного сильного засобу контролю ніколи не достатньо
- Шість рівнів, які стримують порушення безпеки
- Як зловмисники поєднують відмови на різних рівнях
- Відповідність модулів BroLabel кожному рівню
- Захист машинних ідентичностей і гаманців AI Agents
- Тестування кожного рівня перед запуском
- Пов'язані посібники BroLabel і наступні кроки
- Відповіді на запитання покупців про багаторівневий захист
Чому одного сильного засобу контролю ніколи не достатньо
Припустімо, витік стосується ключа інтеграції в робочому режимі з широкими дозволами на виведення. Якщо той самий запит може вибрати гаманець, схвалити виплату й запустити підписання, зловмиснику не потрібно долати кожен компонент окремо.
Ворогом є єдина точка відмови: секрет, обліковий запис адміністратора або можливість підписання, компрометація яких надає необмежений доступ. Міжмережевий екран не розв'яже цю проблему, якщо зловмисник надсилає запити через авторизований інтерфейс.
NIST визначає багаторівневий захист як стратегію інформаційної безпеки, що поєднує людей, технології та операційні можливості для створення змінних бар'єрів на різних рівнях організації. Практична мета — не допустити, щоб відмова засобу захисту чи компрометація облікових даних перетворилися на необмежений доступ.
Замок із кількома мурами — корисна початкова аналогія, але сучасна інфраструктура не є замком. Застосунки, оператори, автоматизовані агенти й зовнішні сервіси постійно перетинають межі. Захист має супроводжувати ці взаємодії, а не виходити з припущення, що всьому за периметром можна довіряти.
Стримування має передувати підписанню
У криптоопераціях відправлена в мережу транзакція зазвичай незворотна. Відновлення бази даних застосунку не поверне активи, уже переказані в блокчейні, тому вирішальні засоби контролю мають діяти до підписання й відправлення в мережу.
Розділіть питання, на які має відповісти зловмисник:
- Доступ: чи може цей викликач дістатися сервісу й автентифікуватися?
- Повноваження: чи може цей викликач запросити саме цю виплату?
- Виконання: чи може підписання відбутися без незалежного схвалення?
- Підзвітність: чи можуть операційні команди пояснити рішення та звірити результат?
Практичний урок: рахуйте незалежні шляхи атаки й незалежно застосовувані бар'єри, а не продукти безпеки.
Наведена нижче операційна модель об'єднує ці обов'язки в шість рівнів. Їхня цінність походить із різних меж відмови: викрадений API-ключ не повинен одночасно вимикати політику транзакцій, контролювати підписання й стирати докази.
Шість рівнів, які стримують порушення безпеки
Шість рівнів захисту криптоінфраструктури
| Рівень | На яке питання відповідає | Типовий засіб контролю | Яку відмову стримує |
|---|---|---|---|
| Управління й люди | Хто може змінювати правила й доступ? | Ролі з мінімальними привілеями, політика схвалення, MFA для адміністративного доступу | Дії одного інсайдера або поспішна зміна |
| Ідентичність і доступ до API | Хто звертається і чи є запит справжнім? | API-ключі з обмеженими правами, підписи запитів, списки дозволених IP-адрес, захист від повторного відтворення | Викрадені або повторно використані облікові дані |
| Політика транзакцій | Чи має ця дія взагалі відбутися? | Ліміти для кожного ключа й гаманця, схвалення, перевірки ризиків і санкцій до підписання | Чинні облікові дані, що авторизують несанкціоновану виплату |
| Зберігання ключів і підписання | Чи може одна сторона підписати самостійно? | Порогове підписання окремими частками ключа, Co-Signer під окремим контролем | Вилучення або неправомірне використання одного ключа |
| Сегментація мережі | Чи може скомпрометований сервіс дістатися цілі? | Потоки із забороною за замовчуванням, розділені площини керування й робочого режиму, вузькі ідентичності сервісів | Бокове переміщення від загальнодоступного компонента |
| Операційний журнал, моніторинг і відновлення | Чи можемо ми побачити, що сталося, і відновити систему? | Операційний журнал лише з додаванням, потоки подій у реальному часі, перевірені процедури відновлення | Непомічена втрата, незвірені баланси й стан, який неможливо відновити |
Управління й люди визначають, хто може змінювати самі засоби захисту. Відокремте повсякденну роботу від адміністрування політик, щоб оператор не міг самостійно розширити власні повноваження.
Ідентичність і доступ до API встановлюють викликача й справжність запиту. Сама автентифікація не визначає, чи належать запитуваний гаманець або транзакція до повноважень цього викликача.
Політика транзакцій оцінює бізнес-дію. Навіть правильно автентифікована інтеграція має стикатися з лімітами, правилами адрес призначення та обов'язковими схваленнями.
Зберігання ключів і підписання обмежують виконання. Відокремлення повноважень підписання від застосунку, що надсилає запит, не дає доступу до застосунку автоматично перетворитися на контроль активів.
Відокремлюйте доступність від повноважень
Для сегментації мережі рекомендації CISA щодо посилення захисту радять суворі списки доступу із забороною за замовчуванням, журналювання відхиленого трафіку й багаторівневі межі із застосуванням міжмережевих екранів, DMZ та VLAN. Застосуйте цей принцип, заборонивши прямий доступ із публічного шлюзу до баз даних операційного журналу, брокерів подій, адміністративних консолей і сервісів підписання.
Натомість дозвольте вузько визначені потоки між сервісами. API може передавати намір виведення сервісу політик; лише авторизований шлях політики повинен запитувати підписання. Тримайте адміністративний доступ окремо від трафіку робочого режиму.
Рівень операційного журналу, моніторингу й відновлення зберігає операційну правду. Зіставляйте записи на межах за ідентифікаторами запитів, гаманців або агентів, результатами політик і рішеннями про підписання, а потім перевіряйте відновлення без обходу засобів схвалення.
Верхні рівні зменшують можливості проникнення й зловживання. Межі виконання стримують вторгнення, а операційні записи підтримують виявлення та відновлення.
Для кожного рядка таблиці запишіть засіб контролю, який його забезпечує, та його власника. Позначте порожні рядки й засоби, які один адміністратор може вимкнути разом.
Як зловмисники поєднують відмови на різних рівнях
Зловмисник рідко стикається з одним муром. Витік облікових даних може привести до зміни політики, запиту на підписання та спроби приховати відповідне сповіщення.
Модель вимірювання NIST 2017 року розрізняє глибину — багаторівневі заходи, які має подолати зловмисник, — і ширину — незалежні шляхи до цілі. Бажаний стан є глибоким і вузьким: значні бар'єри на кожному маршруті й менша кількість маршрутів для захисту.
Ця відмінність змінює підхід до архітектурних перевірок. Кілька засобів зі спільним постачальником ідентичностей, обліковим записом адміністратора або каналом журналювання можуть відмовити через одну компрометацію. Вважайте таку спільну залежність загальним шляхом відмови, а не доказом незалежного захисту.
Шляхи атаки й рівні, які їх зупиняють
| Шлях атаки | Що блокує першим | Що обмежує шкоду | Які докази залишаються |
|---|---|---|---|
| Витік API-ключа, який використали з невідомої IP-адреси | Ідентичність і доступ до API, список дозволених IP-адрес і підпис запиту | Політика транзакцій, ліміти для ключа | Журнал відхиленого запиту з IP-адресою й часом |
| Скомпрометований ноутбук адміністратора | Управління й люди, MFA та рольовий доступ | Зберігання ключів, підписання потребує порогового схвалення | Журнал адміністративних дій |
| Маніпульований або некоректно налаштований AI Agent | Політика транзакцій, ліміти для агента | Операційний журнал, запис кожної спроби лише з додаванням | Результат політики з прив'язкою до агента |
| Повторно відтворений запит на виведення | Ідентичність і доступ до API, захист від повторного відтворення | Політика транзакцій, ідемпотентне опрацювання | Дублікат відхилено й записано |
| Скомпрометований вебпроцес намагається дістатися сервісу підписання | Сегментація мережі, потоки із забороною за замовчуванням | Зберігання ключів, сервіс підписання ізольовано від публічних сервісів | Сповіщення про відхилений потік між сегментами |
Операційний журнал зберігає докази; сам по собі він не заважає агенту витрачати кошти. Його цінність для стримування залежить від того, чи діють оператори або автоматизовані засоби на підставі цих записів.
Простежте шлях витоку ключа через весь стек
Припустімо, хтось надсилає запит на виведення за допомогою викраденого ключа з незнайомої мережі. Список дозволених IP-адрес має відхилити запит до того, як він потрапить в опрацювання виведення.
Якщо зловмисник отримає доступ до дозволеного середовища, окремо захищені облікові дані для підпису запиту все одно можуть запобігти підробленню. Якщо й цей захист не спрацює, ліміт транзакцій для ключа обмежить повноваження запиту.
Журнал відхиленого запиту надає докази, а не запобігає дії. Надсилайте його туди, де скомпрометований застосунок не зможе його переписати, і призначте оператора для розслідування.
Запитайте, що залишиться дієвим після відмови першого засобу захисту та чи може зловмисник вимкнути цей залишковий захист за допомогою того самого доступу.
Створіть карту залежностей, що пов'язує кожен засіб контролю з його адміністраторами, обліковими даними, середовищем розміщення й сховищем доказів. Потім перевірте, чи не усуває компрометація спільного компонента одразу кілька бар'єрів.
Відповідність модулів BroLabel кожному рівню
Модулі BroLabel надають інфраструктурні засоби контролю, але не замінюють управління клієнта. Скористайтеся наведеною нижче відповідністю, щоб відрізнити внесок сервісу від того, що має забезпечити ваша організація.
Відповідність модулів BroLabel рівням захисту
| Модуль BroLabel | Охоплений рівень | Який засіб додає | Відповідальність клієнта |
|---|---|---|---|
| Підписання MPC 2-of-3 у BroSettlement | Зберігання ключів і підписання | Жоден власник ключа не може підписати самостійно | Захищати доступ до підписання й матеріалів відновлення під контролем клієнта |
| Co-Signer під контролем клієнта | Зберігання ключів і підписання | Друге схвалення, яким керує клієнт | Контроль доступу до Co-Signer, резервні копії та правила схвалення |
| API-ключі з обмеженими правами, підписи Ed25519, список дозволених IP-адрес | Ідентичність і доступ до API | Запити автентифіковані й обмежені за сферою; захист від повторного відтворення та ключі ідемпотентності підтримують безпечне надсилання | Зберігання, захист і ротація облікових даних; правильне опрацювання повторних спроб |
| Рольовий контроль доступу | Управління й люди | Адміністративний доступ за принципом мінімальних привілеїв із MFA | Призначати ролі й регулярно їх переглядати |
| Операційний журнал лише з додаванням | Операційний журнал, моніторинг і відновлення | Незмінний запис для звірки й аудиту | Виконувати звірку й перевіряти винятки |
| Події WebSocket у реальному часі | Операційний журнал, моніторинг і відновлення | Поточні події депозитів, підтверджень, виведень і політик | Опрацювання сповіщень і реагування на інциденти |
| Гаманці AI Agents | Політика транзакцій | Окремий гаманець кожного агента з власною політикою та аудиторським слідом; ключі ідемпотентності запобігають повторному виконанню | Визначати сфери політик і ліміти агентів |
| BroWallet | Рівень гаманця | Функціональність на рівні гаманця згідно з окремою конфігурацією й умовами сервісу | Підтвердити доступні засоби контролю, доступ і договірні обов'язки |
Підписання MPC 2-of-3 у BroSettlement означає, що жоден власник ключа не може підписати самостійно. Co-Signer під контролем клієнта додає межу схвалення, якою керує ваша організація, але її незалежність залежить від способу захисту й експлуатації.
Для доступу до API автентифікація Ed25519 застосовується до кожного запиту. Обмежуйте облікові дані запланованою операцією й контекстом гаманця та відокремлюйте автентифікацію запиту від авторизації транзакції.
Ключі ідемпотентності усувають іншу відмову: повторний запит на виведення повертає початковий результат замість нового виконання. Ваша інтеграція має повторно використовувати початковий ключ для тієї самої бізнес-дії, а не створювати новий ключ під час кожної повторної спроби.
Визначте межу відповідальності клієнта
Наш адміністративний доступ дотримується принципу мінімальних привілеїв у RBAC і потребує MFA; адміністративні дії журналюються й відстежуються. Операційний журнал лише з додаванням підтримує звірку, а події WebSocket надають дані про депозити, підтвердження, виведення й результати політик для операційного опрацювання.
BroWallet надає рівень гаманця для користувацьких та операційних сценаріїв відповідно до застосовної конфігурації. Це окремий продукт, а не автоматичне право в межах BroSettlement; підтвердьте засоби контролю гаманця й доступність за договором, перш ніж включати їх до архітектури робочого режиму.
Клієнти мають захищати облікові дані та матеріали підписання під контролем клієнта, дотримуватися чинних вимог автентифікації та негайно повідомляти про підозру щодо компрометації або несанкціонованого доступу. Якщо конфігурація містить Co-Signer під керуванням клієнта або матеріали підписання чи відновлення під контролем клієнта, ваша команда відповідає за їхню експлуатацію й захист, зокрема за контроль доступу, резервні копії та правила схвалення.
Модель зберігання активів і відповідальність кожної сторони залежать від конфігурації сервісу й договірних умов. Використовуйте наш посібник з корпоративного криптогаманця, документуючи операційну модель гаманця, а потім позначте кожен засіб контролю вашої команди та назвіть його оператора.
Захист машинних ідентичностей і гаманців AI Agents
MFA працівників не охоплює всю поверхню транзакцій. Сервісні облікові записи, боти, інтеграції та AI Agents можуть ініціювати фінансові дії без людини перед екраном входу.
Огляд галузевого дослідження Conversational Geek, а не державний набір даних, повідомляє, що машинних ідентичностей у 82 рази більше, ніж людських, 94% організацій спостерігали збільшення їхньої кількості за три роки, а 42% цих ідентичностей мають доступ до конфіденційних даних. Ці цифри ілюструють прогалину в охопленні, а не вимірюють ваше середовище.
Автоматизоване навантаження може правильно автентифікуватися, але діяти за межами запланованого бізнес-контексту. Наприклад, маніпульований агент може надіслати справжній запит до дозволеної кінцевої точки, але вибрати неавторизованого бенефіціара.
Закріпіть автономність за політикою, яку можна примусово виконати
- Використовуйте короткострокові облікові дані там, де це підтримується. Обмежте час, протягом якого скопійовані дані залишаються корисними, і забезпечте надійний шлях відкликання даних, які мають зберігатися.
- Обмежуйте дозволи для кожного агента чи сервісу. Навантаження для звітності не повинно успадковувати повноваження на виведення лише тому, що воно розгорнуте в одному застосунку з виконавцем платежів.
- Призначте окремий гаманець і ліміти транзакцій. Пов'язуйте ризик із відповідальним агентом, а не об'єднуйте непов'язану автоматизовану активність за необмеженим доступом.
- Вимагайте незалежного схвалення до підписання. Застосовуйте правила адреси призначення, суми й бізнес-мети поза процесом міркування самого агента.
- Поєднуйте захист від повторного відтворення з ідемпотентним опрацюванням. Відхиляйте повторно використаний матеріал автентифікації, безпечно опрацьовуючи правомірні повторні спроби того самого бізнес-запиту.
- Зберігайте незмінну атрибуцію. Записуйте викликача, гаманець, заплановану дію, рішення політики й посилання на отриману транзакцію. Зберігайте також відхилені спроби.
- Призначте власника сповіщень про аномалії. Виявляйте неочікувані адреси призначення, сплески запитів і повторні відмови політики, а потім визначте, хто може призупинити відповідне навантаження.
Автоматичні сповіщення поведінкового моніторингу застосовуються лише там, де моніторинг під'єднано для сервісу. Потік подій без споживача, правила сповіщення й відповідального за реагування не є операційною можливістю виявлення.
Операційна межа: агент може запропонувати дію. Він не повинен мати змоги переписати політику, яка цю дію авторизує.
Наш перелік перевірок безпеки гаманців AI допомагає перетворити ці обов'язки на перевірки реалізації. Додайте відкликання облікових даних, призупинення агента й процедури відновлення до того самого операційного регламенту.
Мета — автономність у межах політик: автоматизовані дії залишаються атрибутованими, обмеженими, спостережуваними й зворотними там, де це дозволяє архітектура. Інструкції та дозволи в очікуванні можуть бути зворотними; завершений переказ у блокчейні зазвичай — ні.
Тестування кожного рівня перед запуском
Чинний підпис усе одно може авторизувати неправильну виплату. Переказ — це бізнес-подія, а не просто відправлення в блокчейн, тому тестування має встановити, що підписана транзакція відповідає схваленому зобов'язанню.
Цільове оновлення FATF за 2023 рік зазначає, що Рекомендація 15 та пояснювальна записка до неї застосовуються до постачальників послуг віртуальних активів, визначає Travel Rule як ключовий захід і повідомляє про недостатній прогрес юрисдикцій у впровадженні. Компаніям потрібні належне виявлення та зменшення ризиків, а не ставлення до надсилання в мережу як до завершення процесу відповідності вимогам.
Записи робочого режиму мають зберігати застосовну інформацію про ініціатора й бенефіціара, результати перевірок і рішення про схвалення. Зберігайте придатний для аудиту зв'язок між бізнес-запитом, записом операційного журналу, результатом політики й підписаною транзакцією.
Перевірте контроль ризиків і відновлення
Наша архітектура містить можливості AML-перевірки, аудиторські сліди й ролі доступу, створені для підготовки до серйозних аудитів. AML-перевірки застосовуються лише тоді, коли їх налаштовано для конкретного сервісу, як визначено його конфігурацією, договором із клієнтом, застосовними вимогами або постачальником.
Перевірки транзакційних ризиків, шахрайства й санкцій так само застосовуються лише тоді, коли їх налаштовано для сервісу й погоджено з клієнтом. Вони не застосовуються автоматично до кожного сервісу, а сама архітектура не підтверджує відповідність регуляторним вимогам.
П'ять тестів відмови й очікувані результати
| Тест відмови | Очікуваний результат |
|---|---|
| Відкликати один ключ | Ключ не може авторизувати виведення в інших гаманцях |
| Виклик між сегментами з публічного шлюзу | Виклик відхилено й записано як сповіщення про дію між сегментами |
| Повторно відтворити запит на виведення | Дублікат відхилено й записано, другого переказу немає |
| Відновити операційний журнал із резервної копії та виконати звірку | Баланси відповідають запису до інциденту, винятки перелічено |
| Виконати шлях схвалення Co-Signer від початку до кінця | Підписання відбувається лише після запису схвалення клієнта |
Для справжнього повторного відтворення очікуйте відхилення. Для правомірної повторної спроби з початковим ключем ідемпотентності очікуйте початковий результат без іншого переказу; розрізняйте ці випадки у доказах тестування.
Матеріал ThreatExploit AI про те, як знаходити прогалини в засобах контролю безпеки, пропонує корисну відправну точку для перетворення припущень про захист на вправи з перевірки. Для кожного тесту запишіть очікувану відмову, фактичний результат, місце доказу й відповідального за виправлення.
Використовуйте посібник із SDK криптогаманця, щоб пов'язати поведінку застосунку з процесом інтеграції. Тестове й робоче середовища розділені; доступ до пісочниці не підтверджує доступність, ліміти чи продуктивність робочого режиму.
Цього тижня виконайте тест відкликання ключа в пісочниці, а потім перевірте відкликані облікові дані в кожному контексті гаманця, до якого вони раніше мали доступ. Збережіть докази відмови й усуньте неочікуваний доступ до запуску. Bro has your back!
Пов'язані посібники BroLabel і наступні кроки
Використовуйте огляд інфраструктури BroLabel як головну сторінку для зіставлення конфігурації продукту з операційними обов'язками. Спершу виберіть межу контролю, а потім визначте модуль і договір, які її підтримують.
- Зберігання ключів: зіставте підписання BroSettlement зі сторонами, що мають повноваження підписання й матеріали відновлення.
- Друге схвалення: задокументуйте власника схвалення Co-Signer і те, як він залишається незалежним від застосунку, що надсилає запит.
- Рівень гаманця: визначте, які засоби BroWallet доступні згідно з окремою конфігурацією й умовами.
- Ліміти для агентів: визначте дозволені дії та ризик кожного автоматизованого гаманця.
- Процес відповідності вимогам: визначте відповідальних за записи Travel Rule, налаштовані перевірки й аудиторські докази.
Зберігайте цю відповідність разом зі схемою архітектури й регламентом реагування на інциденти. Корисна передача справ визначає власника, точку застосування, джерело доказів і процедуру відновлення для кожної межі, а не лише назву модуля.
Відповіді на запитання покупців про багаторівневий захист
Чи достатньо самого MPC-підписання? Ні. Порогове підписання захищає повноваження підписання, але не визначає, чи є виплата правомірною. Авторизація API, політика транзакцій та операційна перевірка залишаються необхідними.
Чим Co-Signer відрізняється від MPC? MPC розподіляє повноваження підписання; Co-Signer під контролем клієнта додає межу схвалення, якою керує клієнт. Ваша команда відповідає за правила схвалення для компонентів під власним керуванням.
Скільки рівнів нам потрібно? Використовуйте достатньо незалежно застосовуваних засобів, щоб втрата одного захисту не відкрила прямий доступ до критичного активу. Як проєктний мінімум розмістіть додатковий незалежний бар'єр за кожним критичним превентивним засобом і перевірте спільні адміністративні залежності.
Чим це відрізняється від zero trust? Багаторівневий захист описує пошаровий захист. Zero trust спрямовує перевірку й авторизацію запитів у межах такої архітектури; ці підходи доповнюють один одного.
Що покупці мають врахувати в операційній роботі
Ми можемо обмежувати функції, мережі чи активи з міркувань безпеки, дотримання законодавства або цілісності сервісу. Ми завчасно повідомляємо про істотні планові роботи, коли це обґрунтовано можливо, але термінові зміни можуть відбутися без попередження, якщо затримка створює значний ризик.
Доступ може припинитися негайно, якщо подальше надання сервісу буде незаконним, цього вимагає орган влади або серйозний ризик безпеки чи шахрайства неможливо обґрунтовано зменшити вужчими обмеженнями. Дані облікового запису зберігаються під час активних відносин, а після них — лише стільки, скільки обґрунтовано потрібно для сервісу, договірних питань, безпеки, спорів або застосовних правових вимог.
BroLabel пропонує модульну інфраструктуру гаманців, MPC-підписання, схвалення під контролем клієнта, а також можливості операційного журналу й подій для багаторівневих криптооперацій. Відвідайте BroLabel, щоб зіставити процес виплат із цими засобами й визначити обов'язки клієнта до переходу від тестування в пісочниці до робочого режиму. Bro has your back!
