Що таке безпека MCP?
Безпека Model Context Protocol (MCP) – це сукупність заходів і практик, спрямованих на забезпечення цілісності, конфіденційності та коректного функціонування комунікації між великими мовними моделями (LLM) і різними інструментами, плагінами, джерелами даних та API, з якими вони взаємодіють. У міру розширення можливостей LLM за допомогою протоколів, таких як MCP, моделі отримують здатність виконувати дії у реальному середовищі. Вони можуть отримувати доступ до чутливих даних і викликати сторонні розширення. Забезпечення захисту таких взаємодій є критично важливим для запобігання експлуатації, витоку даних і несанкціонованим діям, які можуть бути ініційовані моделлю або спрямовані на неї.
Проблеми безпеки MCP виходять за межі традиційної безпеки застосунків. Моделі обробляють як вхідні підказки від користувачів, так і контекст із API інструментів. Це робить їх вразливими до нових типів атак, таких як ін’єкції промптів (prompt injection) та маніпуляції результатами інструментів. Взаємопов’язаний характер MCP створює кілька меж довіри. Будь-яка слабка ланка може спричинити ланцюжок наслідків для безпеки та конфіденційності. Підхід до безпеки повинен враховувати не лише технічні вразливості. Він також має передбачати динамічну і часто непередбачувану поведінку агентів LLM та екосистеми, до якої вони підключені.
Вас може також зацікавити стаття «Фреймворки та інструкції щодо безпеки ШІ».
Основні проблеми та ризики безпеки MCP
Ін’єкція промпту та отруєння інструментів
Ін’єкція промпту виникає, коли зловмисники створюють спеціальні вхідні дані. Вони можуть бути видимими для користувача або прихованими у зовнішньому контенті. Такі дані маніпулюють моделлю та змушують її виконувати небажані дії. Ці вхідні дані можуть виглядати безпечними. Однак вони розроблені так, щоб викликати певну поведінку після інтерпретації LLM. Наприклад, зловмисник може вставити приховану інструкцію у документ або електронний лист. Після обробки асистентом така інструкція може призвести до витоку даних або виконання системних дій, які не планувалися.
Іншою загрозою є отруєння інструментів (tool poisoning). Воно полягає у зміні метаданих інструментів MCP, зокрема їх описів і параметрів. Це робиться для введення моделі в оману та виконання шкідливих дій. Оскільки інструменти зазвичай вважаються довіреними за замовчуванням, незначні зміни в метаданих можуть залишатися непоміченими. Водночас вони можуть порушувати цілісність системи.
Недовірені сервери
Сервери MCP можуть працювати локально або бути розміщеними у хмарі. В обох випадках виникають ризики, якщо сервер скомпрометований або створений з метою нашкодити. Зловмисник може розгорнути сервер MCP, який виглядає легітимним. Пізніше його інструменти можуть бути оновлені так, щоб виконувати шкідливі дії. Наприклад, це може бути доступ до конфіденційних даних або перенаправлення чутливої інформації.
Це також стосується оновлень серверів. Якщо поведінка інструментів змінюється непомітно після встановлення, агенти або користувачі можуть несвідомо запускати небезпечні операції. Шкідливі сервери також можуть використовувати колізії назв. У цьому випадку вводяться оманливі назви інструментів, які імітують довірені функції.
Розширена поверхня атаки
MCP розширює поверхню атаки, оскільки підключає LLM до багатьох сервісів через API, інструменти та джерела даних. Кожна інтеграція створює нову потенційну точку входу для зловмисників. Якщо будь-який підключений сервіс неправильно налаштований або скомпрометований, він може бути використаний для маніпуляції моделлю, викрадення даних або запуску дій в інших сервісах.
Така взаємопов’язаність означає, що одна вразливість може поширюватися на інші системи. Це може бути вразливість у механізмах обробки промптів, логіці серверів або метаданих інструментів. Ризик збільшується зі зростанням кількості сервісів, інтегрованих у робочу область моделі.
Відсутність належної авторизації
Некоректна реалізація логіки авторизації на серверах MCP створює умови для проблеми «заплутаного посередника» (confused deputy). У такій ситуації сервер MCP може виконувати дії від імені користувача з більшими привілеями, ніж дозволено. Якщо сервер неправильно перевіряє обліковий запис користувача та його права доступу, дії можуть виконуватися з використанням підвищених привілеїв сервера, а не прав користувача, який робить запит.
Хоча MCP використовує OAuth для авторизації, прогалини у специфікації та відмінності у практиках реалізації створюють вразливості. Без жорсткого контролю доступу моделі можуть виконувати дії, які їм не повинні бути дозволені.
Надмірні дозволи доступу
Інструменти MCP часто запитують широкі області доступу для зручності. Наприклад, може надаватися повний доступ до Gmail або Drive навіть тоді, коли потрібні лише права читання. Такі надмірні дозволи збільшують наслідки компрометації. Скомпрометовані інструменти можуть отримувати доступ або змінювати великі обсяги чутливих даних у різних сервісах.
Окрім зовнішніх загроз, це також створює можливості для зловживання привілеями внутрішніми користувачами або некоректною поведінкою агентів. Надлишкові дозволи можуть використовуватися небажаним або несанкціонованим способом.
Ризики ланцюга постачання
Сервери та інструменти MCP складаються з коду і залежностей. Ці залежності також можуть містити вразливості. Зловмисники можуть вставляти шкідливу логіку у залежності або змінювати код серверного компонента. У такому випадку компрометації зазнають усі користувачі цього сервера.
Для зменшення таких ризиків розробники MCP повинні застосовувати безпечні практики розробки програмного забезпечення. До них належать статичний аналіз, аналіз складу програмного забезпечення, перевірка залежностей і підписані збірки. Якщо сервер MCP розгортається у хмарі, він повинен підтримувати криптографічну перевірку. Це дозволяє клієнтам підтверджувати його справжність.
10 ключових елементів захисту в архітектурі MCP
Захист архітектури MCP вимагає контролю кожної межі, де взаємодіють моделі, інструменти, користувачі та зовнішні системи. MCP створює шляхи виконання, які поєднують природну мову, програмний код і привілейовані API. Кожен елемент нижче є точкою контролю. Помилки на цих етапах можуть призвести до несанкціонованих дій, витоку даних або компрометації системи.
1. Контроль автентифікації та авторизації
Клієнти та сервери MCP повинні взаємно автентифікуватися та суворо перевіряти OAuth-токени. Токени повинні бути обмежені аудиторією, мати чіткі області доступу і видаватися спеціально для сервера MCP. Рішення щодо авторизації повинні прийматися на стороні сервера, щоб запобігти проблемі «заплутаного посередника» та ескалації привілеїв.
2. Перевірка вхідних і вихідних даних
Усі вхідні дані для моделі, включно з підказками користувачів і відповідями інструментів, повинні розглядатися як недовірені. Сервери повинні перевіряти та очищувати вхідні дані для виявлення ін’єкцій промпту або некоректних структур. Результати роботи моделі повинні перевірятися перед повторним використанням як вхідні дані інструментів або як контекст для подальших операцій.
3. Цілісність інструментів і метаданих
Визначення інструментів, їх описи та параметри безпосередньо впливають на поведінку моделі. Ці артефакти повинні бути захищені від змін за допомогою підписаних маніфестів або довірених реєстрів. Будь-яка зміна поведінки інструмента або його метаданих повинна запускати процедуру перевірки та повторної авторизації.
4. Логування, моніторинг і аудит
Кожен виклик інструмента повинен створювати структурований запис аудиту. У записі повинні міститися облікові записи, області доступу, параметри та результати. Журнали повинні бути захищені від змін і зберігатися централізовано для підтримки реагування на інциденти. Безперервний моніторинг дозволяє виявляти аномальні або зловмисні шаблони використання.
5. Мережева ізоляція та ізоляція розгортання
Сервери MCP повинні працювати в ізольованих сегментах мережі з мінімальним доступом до внутрішніх сервісів. Компрометація сервера MCP не повинна відкривати можливості для розгалуження атаки. Локальні сервери повинні працювати у пісочниці з обмеженими правами доступу до файлової системи, процесів і мережі.
6. Безпека ланцюга постачання та залежностей
Сервери MCP залежать від сторонніх бібліотек та інструментів, які можуть змінюватися з часом. Залежності повинні перевірятися на наявність вразливостей, фіксуватися за версіями та підтверджуватися підписаними збірками. Конвеєри CI/CD повинні бути захищені від ін’єкції шкідливого коду.
7. Обмеження швидкості запитів і запобігання зловживанням
Кінцеві точки MCP повинні обмежувати кількість запитів для клієнтів, користувачів та інструментів. Такі обмеження зменшують вплив автоматизованих атак, дослідження моделі та спроб відмови в обслуговуванні. Пороги використання повинні контролюватися незалежно від логіки моделі.
8. Безпечна передача даних та шифрування
Усі комунікації MCP повинні використовувати зашифровані канали, наприклад TLS. Чутливі конфігурації, токени та журнали повинні шифруватися під час зберігання. Політики керування ключами та їх ротації зменшують масштаб наслідків у разі компрометації.
9. Безперервне тестування безпеки
Реалізації MCP повинні регулярно перевірятися за допомогою adversarial-промптів, фаззингу та тестування на проникнення. Перевірки повинні охоплювати ін’єкції промпту, неправильне використання інструментів і сценарії обходу авторизації. Тестування безпеки повинно повторюватися після оновлення інструментів або моделей.
10. Контроль керування та відповідності вимогам
Системи MCP часто обробляють регульовані або чутливі дані. Потрібні чіткі політики щодо зберігання даних, журналювання доступу та отримання згоди користувачів. Керування забезпечує відповідність поведінки MCP правовим, конфіденційним та організаційним вимогам.
Найкращі практики безпеки MCP
1. Обмеження областей дозволів MCP до мінімально необхідних дій
Надання широких областей OAuth-доступу з самого початку (наприклад, files:* або admin:*) збільшує наслідки компрометації токена. Це також ускладнює відкликання доступу. Замість цього реалізації MCP повинні використовувати прогресивну модель областей доступу. Початковий набір повинен містити лише низькоризикові області, наприклад mcp:tools-basic. Підвищені дозволи слід запитувати лише за необхідності. Для цього використовуються цільові виклики WWW-Authenticate.
Такий підхід зменшує складність початкового налаштування. Він також знижує ризик ескалації привілеїв і підвищує прозорість аудиту. Сервери повинні підтримувати токени з обмеженими областями доступу та фіксувати всі спроби підвищення привілеїв. У журналах повинні зберігатися деталі областей доступу і кореляційні ідентифікатори. Клієнти також повинні кешувати відхилені області доступу, щоб запобігти повторним циклам запитів на підвищення привілеїв. Не рекомендується штучно розширювати перелік scopes_supported, оскільки це призводить до нормалізації надмірних дозволів і ігнорування запитів на згоду.
2. Забезпечення суворої перевірки серверів для всіх кінцевих точок MCP
Сервери MCP не повинні передавати токени, якщо вони не були видані спеціально для цього сервера. Прийняття довільних токенів доступу (token passthrough) підриває здатність сервера застосовувати обмеження швидкості, перевірку запитів і аудит. Це також створює порушення меж довіри, оскільки підключені API можуть довіряти неправильному обліковому запису або некоректним припущенням щодо поведінки.
Для запобігання цьому сервер MCP повинен:
- перевіряти, що значення aud (audience) та інші твердження токена відповідають його власному обліковому запису;
- відхиляти токени, які не мають областей доступу для сервера MCP;
- не використовувати токени повторно між різними сервісами без перевірки.
3. Перевірка вхідних даних як для промптів користувача, так і для результатів моделі
Неперевірені дані створюють ризики як на вході, так і на виході взаємодій MCP. Ін’єкції промптів можуть виникати через введення користувача або через відповіді інструментів. Шкідливі дані можуть поширюватися між контекстами, якщо результати моделі вважаються довіреними.
Для зменшення ризику сервери MCP повинні:
- перевіряти вхідні промпти користувачів на наявність відомих патернів ін’єкцій або спеціальних токенів;
- аналізувати результати інструментів перед повторним передаванням їх моделі або іншим системам;
- очищувати або відхиляти несподівані відповіді, які можуть спричинити небажану поведінку у наступних компонентах.
4. Логування всіх викликів інструментів із використанням захищеного сховища
Надійне журналювання є критично важливим для забезпечення підзвітності, розслідування інцидентів і цифрової експертизи. Кожен виклик інструмента через сервер MCP повинен фіксуватися разом із пов’язаними метаданими. До таких даних належать:
- обліковий запис клієнта MCP і користувача;
- назва інструмента та параметри;
- запитувані області доступу;
- часова мітка та результат.
Журнали повинні зберігатися у захищених системах, стійких до змін. Це можуть бути журнали з режимом лише додавання або сховища з одноразовим записом. Такі системи повинні підтримувати перевірку цілісності та контроль доступу. Без надійних журналів стає складно відстежувати зловживання або проводити аудит чутливих операцій.
5. Регулярний аудит встановлених інструментів і розширень MCP
Інструменти в середовищі MCP можуть змінюватися після встановлення. Оновлення можуть додавати нову поведінку, дозволи або вразливості. Зловмисники можуть скористатися цим, змінюючи метадані інструментів. Це можуть бути описи або параметри. Також можливе впровадження шкідливої логіки через залежності або динамічну конфігурацію.
Оператори серверів MCP повинні:
- проводити планові аудити всіх встановлених інструментів і розширень;
- повторно перевіряти задекларовані дозволи та описи на відповідність реальній поведінці;
- використовувати статичний аналіз і сканування залежностей для виявлення змін або нових ризиків;
- фіксувати версії для запобігання непомітним оновленням;
- відстежувати зміни в реєстрах інструментів і генерувати сповіщення про неочікувані модифікації.
6. Ізоляція серверів MCP від чутливих внутрішніх мереж
Сервери MCP не повинні розгортатися у середовищах із необмеженим доступом до внутрішніх сервісів. Скомпрометований сервер може стати точкою входу для ширшого проникнення в мережу.
Для зменшення ризику:
- сервери MCP слід розгортати в ізольованих мережевих сегментах із суворим контролем вхідного та вихідного трафіку;
- локальні сервери MCP повинні працювати у пісочниці з мінімальними привілеями, наприклад із обмеженим доступом до файлової системи та мережі;
- необхідно використовувати механізми ізоляції платформи, такі як контейнери, chroot-середовища або ізольовані середовища застосунків;
- для локальних HTTP-каналів слід вимагати автентифікацію або використовувати stdio чи Unix-domain sockets з обмеженим доступом.
Локальні сервери MCP також повинні відображати явні діалоги підтвердження перед виконанням будь-яких команд конфігурації. Діалогове вікно повинно відображати повну команду. Воно має попереджати про потенційний ризик, наприклад виконання rm -rf або curl для ексфільтрації даних. Також повинна бути можливість скасувати дію. Такий механізм захищає від ненавмисного виконання коду або запуску шкідливих сценаріїв під час старту системи.
