Ferry — Политика за реакция при инциденти със сигурността

В сила от: 3 август 2026 г. Собственик: „Прендит“ ЕООД (Prendit EOOD) · контакт за сигурност: security@ferrycommerce.com

1. Цел и обхват

Тази политика определя как откриваме, реагираме и докладваме инциденти със сигурността, засягащи Ferry — в частност всеки пробив в личните данни (име, адрес, телефон, имейл на клиенти) или в креденшълите на търговци, които обработваме. Покрива всички Cloudflare Workers на Ferry (Shopify приложението и съпътстващите услуги), тяхното D1/R2/KV/Queue/Durable-Object съхранение, куриерските и другите API интеграции и хранилището на изходния код.

2. Какво се счита за инцидент

Всяко действително или подозирано събитие, което компрометира поверителността, целостта или наличността на лични данни или системи, напр.: неоторизиран достъп до D1/R2/KV; изтекли секрети — приложни/платформени API секрети, ключът за шифроване на данни, куриерски креденшъли на търговци, токени на доставчици, административни bearer токени или webhook секрети; експлоатирана уязвимост; компрометирани креденшъли; или уведомление за пробив при подизпълнител.

3. Роли

При малък екип едно лице може да носи и двете роли; важното е един отговорен собственик.

4. Процедура за реакция

1. Откриване и докладване — всеки, забелязал инцидент, докладва незабавно на security@ferrycommerce.com. Източници: Cloudflare observability/аларми, пикове на грешки, уведомления от трети страни.
2. Триаж и класификация — преценка какви данни/системи са засегнати и определяне на тежест:
   • SEV-1 — потвърден пробив в лични данни или креденшъли на търговци (важат задълженията за уведомяване по §5);
   • SEV-2 — подозиран пробив или експлоатируема слабост с достъп до лични данни (третира се като SEV-1 до опровергаване);
   • SEV-3 — събитие по сигурността без експозиция на лични данни (третира се като обикновена поправка, но се записва).
3. Запазване на доказателства — преди отстраняването, където е възможно: съответните логове, записи на заявки и опис на засегнатите данни (какви/чии данни, за какъв период) — това храни и уведомленията по §5, и прегледа след инцидента.
4. Ограничаване — спри изтичането: ротация на изложените секрети, отнемане на токени/креденшъли, изключване на засегнатия път, блокиране на извършителя.
5. Отстраняване и възстановяване — коригирай първопричината, възстанови чисто състояние, провери целостта.
6. Уведомяване (вж. раздел 5).
7. Преглед след инцидента — до 5 работни дни: хронология, първопричина и конкретни последващи действия срещу повторение.

5. Уведомяване

• Търговци (администратори): уведомяваме засегнатите търговци без ненужно забавяне след потвърждаване на пробив в лични данни, съгласно DPA, с естеството на пробива, вероятните последици и предприетите мерки.
• Надзорен орган: когато сме администратор и пробивът вероятно води до риск за физически лица — уведомяваме КЗЛД до 72 часа от узнаването.
• Shopify / подизпълнители: уведомяваме съгласно техните условия.

6. Бърз наръчник при изложен секрет

Ако някой секрет от §2 бъде изложен:

1. Ротация при източника (платформеното табло, порталът на доставчика или — за куриерски креденшъли — повторно въвеждане от търговеца).
2. Обновяване на съхранения секрет в средата за изпълнение.
3. Особеност на ключа за шифроване: ротацията му прави по-рано шифрованите данни нечетими — първо се планира миграция с пре-шифроване, никога сляпа ротация в продукция.
4. Инвалидиране на всичко производно от секрета (сесии/токени) и наблюдение за злоупотреба.

7. Превенция (постоянни контроли)

• Секретите никога не се комитват в кода; продукционните секрети живеят само в хранилището за секрети на платформата.
• Шифроване в покой и при пренос; минимални привилегии; силна автентикация + 2FA за Cloudflare, Shopify Partner и GitHub акаунтите.
• Разделени тестови/продукционни данни; преглед на зависимостите и на достъпите.

8. Преглед

Преглежда се поне веднъж годишно и след всеки значим инцидент.