--- title: "Как да защитите API с чувствителни или регулирани данни" description: "Практически мерки за API с банкови, енергийни или комунални данни: модел на заплахите, оторизация, минимални права, по-малко данни, тайни, одитни дневници." canonical: https://sdk.enterprises/bg/insights/securing-regulated-data-apis language: bg --- # Как да защитите API с чувствителни или регулирани данни Обновено: 2026-09-25 > Защитете API с регулирани данни, като моделирате кой би могъл да злоупотреби с него, проверявате оторизацията за всеки обект и всяко поле, събирате и връщате възможно най-малко данни и държите тайните и одитните дневници под строг контрол. Слабостите, които на практика имат най-голямо значение, са пропуските в оторизацията и отговорите, които разкриват твърде много данни, а не пробитото криптиране. ## Започнете с модел на заплахите за данните, а не за рамката Преди да изберете инструменти, запишете какво разкрива API и кой би могъл да злоупотреби с него. За банка това са данни за сметки и трансакции; за енергийна или комунална компания това могат да са данни от измервания, договори с клиенти и оперативни показания от мрежата. Полезният модел на заплахите е кратък. Той изброява чувствителните данни, всеки извикващ, който може да достигне до тях, действията, които всеки извикващ трябва да може да извършва, и какво става, ако някой от тях бъде компрометиран. Този документ след това определя всяка мярка по-долу и казва на рецензентите какво да тестват. - Кои данни са лични, поверителни или регулирани и къде се съхраняват. - Всеки потребител на API: вътрешни услуги, партньори, мобилни приложения и администратори. - Какво всеки потребител има право да чете, променя или задейства. - Последиците от изтекъл токен, злонамерен служител или компрометирана партньорска система. ## Удостоверявайте всеки извикващ, после оторизирайте всеки обект Използвайте стандартен протокол като OAuth 2.0 с OpenID Connect за потребителите и краткотрайни токени или взаимен TLS (mutual TLS) за извикванията между услуги. Избягвайте дълготрайни споделени API ключове, защото никой не може да каже коя система ги е използвала, нито да ги отмени, без да развали други. Удостоверяването само доказва кой се обажда. Първата позиция в OWASP API Security Top 10 е нарушената оторизация на ниво обект (broken object level authorization): валиден потребител променя идентификатор в заявката и чете чужд запис. Проверявайте собствеността или принадлежността към клиента на сървъра за всеки обект, всяка функция и всяко чувствително поле и никога не се доверявайте на идентификатор или роля, изпратени от клиента. ## Дайте на всеки клиент и всяка услуга минималните права, от които се нуждаят Принципът на минималните права ограничава щетите, когато нещо все пак се обърка. Издавайте отделни идентификационни данни за всеки потребител на API, ограничавайте токените до конкретни операции и дръжте администраторските крайни точки на отделен път с по-строги проверки. Прилагайте същото правило и под API. Служебният акаунт, който чете данни от измервателни уреди, не бива да може да ги изтрива, а задача за отчети трябва да се свързва с роля в базата данни само за четене. Преглеждайте правата по график, защото достъпът, даден за еднократна задача, обикновено остава завинаги. ## Събирайте по-малко, връщайте по-малко и пазете за по-кратко Минимизирането на данните е едновременно принцип на GDPR и силна мярка за сигурност: данни, които никога не сте съхранявали, не могат да изтекат. За всяко поле се запитайте дали услугата наистина се нуждае от него и премахнете или псевдонимизирайте това, което не ѝ трябва. Прилагайте същата дисциплина към отговорите. Определяйте изрични схеми на отговорите, вместо да сериализирате цели обекти от базата данни, маскирайте идентификатори като номера на сметки, когато пълната стойност не е нужна, и задавайте срокове за съхранение, за да се изтриват старите записи. Документирайте правното основание за всяка цел на обработване и подписвайте договори за обработване с всеки доставчик, който борави с данните. Това е инженерна практика, а не правен съвет, затова включете длъжностното лице по защита на данните или юриста си за правната оценка. ## Валидирайте всеки вход и ограничете колко може да изразходва един извикващ Третирайте всяка заявка като враждебна, докато не бъде валидирана. Налагайте схема за всяка крайна точка, отхвърляйте непознатите полета и използвайте параметризирани заявки, за да не става входът никога част от команда към базата данни. Няколко от рисковете за API според OWASP идват от липсващи ограничения, а не от лош код. Ограничавайте честотата на заявките за всеки клиент, задавайте таван на размера на страниците и на съдържанието и защитете чувствителните бизнес процеси, като плащания или промени в договори, от автоматизирана злоупотреба. Ако API изтегля отдалечени URL адреси от името на извикващите, ограничете дестинациите, за да предотвратите фалшифициране на заявки от страна на сървъра (SSRF). ## Дръжте тайните извън кода, образите и дневниците Паролите за бази данни, ключовете за подписване и идентификационните данни на партньорите трябва да са в специализиран мениджър на тайни, да се подават по време на изпълнение и да се сменят по график. Сканирайте хранилищата и контейнерните образи за тайни в pipeline за компилиране и третирайте всяка тайна, попаднала в системата за контрол на версиите, като компрометирана. Разделяйте тайните по среди, за да не отвори никога изтекла тестова парола продукционната среда. Ограничете кой може да чете тайните в продукционна среда и записвайте всеки достъп до тях. ## Водете дневници за одит и проектирайте за по-малко инциденти Регулираните среди трябва да могат да отговорят на прост въпрос след събитието: кой е имал достъп до какви данни, кога и през кой клиент. Записвайте това за всяко чувствително четене и запис, съхранявайте дневниците там, където операторите на приложението не могат да ги променят, и дръжте личните данни извън съобщенията в дневниците. Съчетайте дневниците с известия при необичайни модели, например когато един клиент чете много повече записи от обичайното, и с изпробван план за реакция при инциденти. Чрез Sopra Steria нашите инженери изградиха защитени API за чувствителни данни на комунални услуги при регулаторни ограничения и ръководиха инструмент за оперативен надзор, при който наложените стандарти за сигурност вървяха ръка за ръка с по-малко инциденти в продукционна среда. Днес SDK Enterprises прилага същите практики в клиентските проекти. ## Основното накратко - Кратък писмен модел на заплахите за данните трябва да определя всяка мярка за сигурност на API. - Проверявайте оторизацията на сървъра за всеки обект, функция и чувствително поле, а не само при вход. - Минималните права важат еднакво за токените, служебните акаунти и ролите в базата данни. - Минимизирането на данните намалява както рисковете по GDPR, така и последиците от всяко пробиване. - Одитните дневници трябва да показват кой до какво е имал достъп и кога, без самите те да издават лични данни. ## Въпроси и отговори ### Достатъчен ли е HTTPS, за да защитите API? Не. TLS защитава данните при пренос, но много пробиви в API включват удостоверени извикващи, които достигат до данни, които не бива да виждат. Проверките на оторизацията, валидирането на входа, ограниченията на честотата на заявките и одитните дневници пак са необходими. ### Какво е нарушена оторизация на ниво обект (broken object level authorization)? Това е пропуск, при който API проверява дали извикващият е влязъл, но не и дали поисканият запис му принадлежи. Промяната на идентификатор в URL адреса или в тялото на заявката тогава разкрива данните на други потребители. Решението е проверка на собствеността или на принадлежността към клиента на сървъра за всеки обект. ### Предписва ли GDPR конкретни мерки за сигурност на API? GDPR изисква подходящи технически и организационни мерки спрямо съответния риск, без да налага конкретни инструменти. Мерки като ограничаване на достъпа, минимизиране, псевдонимизация и водене на дневници са често срещани начини за изпълнение на това изискване, а правните Ви съветници трябва да потвърдят какво важи за Вашия случай. ## Свързани услуги - [Сигурност на приложенията](https://sdk.enterprises/bg/services/secure-systems)