Приложение 2 към DPA — Технически и организационни мерки

1. Псевдонимизация и криптиране

1.1. Криптиране в покой

• Чувствителните данни (имена, контакти, бележки, ключове за многофакторна автентикация) се криптират на ниво запис със стандартни за индустрията алгоритми.
• Файловете в обектното хранилище се криптират от хостинг доставчика в ЕС.
• Резервните копия на базата данни се криптират отделно от продукционната среда.
• Ключовете за криптиране се управляват отделно от самите данни; в продукционна среда — чрез управляема услуга за ключове с ограничен достъп.
• Телефонният номер по подразбиране не е технически четим за платформата. При активирани SMS напомняния платформата може да обработва отделно технически четимо копие, ограничено до целите на доставка, повторен опит, обработка на статуса на доставка и техническа диагностика. Това копие се защитава чрез криптиране в покой, контрол на достъпа по роли, логване на достъпа, редуциране на логовете и автоматично премахване/деактивиране при изключване на SMS функцията, отказ на пациента или изтриване на съответните данни за резервацията, освен при кратък технически срок за доставка или мярка при инцидент по сигурността.

1.2. Хеширане на пароли и токени

• Потребителските пароли се съхраняват само хеширани със съвременен алгоритъм, устойчив на атаки с груба сила.
• Резервните кодове за многофакторна автентикация и токените за достъп се съхраняват само в хеширан вид — никога в чист текст.
• За търсене по чувствителни полета се използват отделни ключови хешове, без да се разкрива самата стойност.

1.3. Криптиране при транспорт

• Целият публичен трафик е криптиран по TLS с активиран HSTS.
• Комуникацията между приложението и базата данни остава в рамките на частна мрежа.
• Комуникацията с подобработващите е криптирана по TLS.
• Push известията се предават по стандарта на съответния доставчик.

2. Поверителност, цялостност и достъпност

2.1. Контроли за достъп

• Многофакторна автентикация — задължителна за администраторски достъп и за достъп до клиентски данни в здравните дейности.
• Ротация на токени за сесия с откриване на повторно използване — компрометиран токен прекратява достъпа.
• Кратко живеещи сесии с автоматично подновяване и защитени бисквитки.
• Доверени устройства — до 30 дни без повторна 2FA; не заобикалят паролата.
• Прогресивно блокиране при многократни неуспешни опити за вход.
• Автоматично блокиране на IP при подозрителна активност.
• Пълен, неизменим аудит дневник на действията — създаване, промяна и изтриване на записи, влизания и експорти.

2.2. Сегментиране и изолация на клиентите

• Строга логическа изолация между отделните клиенти на ниво база данни и приложение.
• Задължителни проверки за собственост при всяка заявка и промяна на данни.
• Автоматизирани проверки на ниво код, които спират внедряване при липсваща проверка за изолация.
• Регресионни тестове срещу изтичане на данни между отделните клиенти.

2.3. Пасивна сигурност

• Strict-Transport-Security — 1 година, поддомейни, preload.
• Content Security Policy — активен.
• CORS — ограничен до одобрени origins.
• CAA DNS записи — ограничават кои CA могат да издават сертификати за tochnow.com.
• .well-known/security.txt — публикуван за координирано разкриване на уязвимости.

2.4. Сигурност на инфраструктурата

• Облачна инфраструктура — Hetzner Online (Германия / Финландия).
• Достъп до сървърите — SSH с публични ключове; никакъв парола-базиран достъп.
• Привилегирован достъп — ограничен само до управителя на „СИНТОПИЯ“ ЕООД; всеки достъп се аудитира.
• Отделни служебни акаунти с минимални права за всяка външна услуга.
• Сегментация на мрежата — базата данни и приложният слой не са публично достъпни; на публичния периметър стои само reverse proxy.
• Row-Level Security на ниво база данни за изолация на клиентските данни.
• Patching и обновявания — автоматизирани за Docker base images; Dependabot за приложни зависимости.

3. Възстановяемост на достъпа и наличност

3.1. Резервни копия

3.2. Възстановяване след инцидент

• RTO — < 15 минути за възстановяване до точка във времето; ~14 минути за пълно възстановяване.
• RPO — ≤ 30 минути.

Валидиран на 28 април 2026 г. — реална репетиция за възстановяване с двата сценария. Допълнително валидиран на 29 април 2026 г. с непреднамерена операторска грешка (PITR за 1 минута и 40 секунди от край до край).

3.3. Мониторинг

• Грешки в backend — самостоятелно хоствано наблюдение в ЕС.
• Грешки в браузъра — наблюдение в ЕС с премахване на лични данни преди изпращане.
• Производителност и наличност — вътрешни здравни проверки + външен monitoring.
• Аудит на сигурността — седмични дълбоки одити с автоматизиран agent.

4. Регулярно тестване и оценка

• Автоматизиран daily security linter — ежедневно.
• Автоматизиран weekly deep audit — седмично.
• Автоматизирана проверка на зависимостите за известни уязвимости — на всеки deploy.
• Регресионни тестове за изолация между клиентите — на всеки deploy.
• Pen-test от външен експерт — поне веднъж годишно (последно: 17 април 2026 г. — всички намерени проблеми затворени).
• Тестване на резервни копия — поне веднъж тримесечно.

Преглед и обновяване

• Ротация на криптографски тайни и ключове за достъп — тримесечно.
• Преглед на правилата за достъп — всеки 6 месеца.
• Преглед на DPA и Политики — всеки 6 месеца или при съществена промяна.
• Преглед на списъка с подобработващи — на всеки нов подобработващ + годишно.
• DPIA преразглеждане — годишно или при значителна промяна на обработката.

5. Управление на инциденти

Реакция при инцидент

1. Откриване и валидация (≤ 4 часа).
2. Изолация (незабавно при P0).
3. Уведомяване на засегнатите Администратори (≤ 72 часа от установяване).
4. Уведомяване на КЗЛД, ако е приложимо (≤ 72 часа от установяване, чл. 33 GDPR).
5. Уведомяване на субектите на данни, ако рискът е висок (без необосновано забавяне, чл. 34 GDPR).
6. Корективни мерки и пост-mortem (≤ 14 дни).

Точка за контакт

• Сигурност: security@tochnow.com
• Защита на данните: privacy@tochnow.com
• Отговорно разкриване: security.txt

6. Управление на персонал

• Едиственият служител с достъп до продукционни системи е управителят на „СИНТОПИЯ“ ЕООД.
• При разширяване на екипа: всеки нов служител подписва декларация за поверителност и обучение по GDPR.
• Достъпът се предоставя по принципа „минимални привилегии“.
• Външно обучение по GDPR / сигурност — поне веднъж в две години.
• При прекратяване на трудовите отношения: незабавно отнемане на достъпа.

7. Спазване и одит

Документация: DPA + Приложения, DPIA (вътрешна, налична при искане под NDA), Регистър за обработка на лични данни (чл. 30 GDPR), Runbook за инциденти, Политики за тайни и ротация.

Сертификации

• ISO/IEC 27001 — не сертифицирани (планирани при достигане на мащаб).
• SOC 2 — не сертифицирани.
• ENISA / NIS2 — под наблюдение.
• GDPR Code of Conduct — не присъединени.