← Правна информация
ПРАВЕН ДОКУМЕНТ · ВЕРСИЯ 2026-09-01

Сигурност и технически мерки

Публично резюме на защитите, ограниченията и начина за докладване на инцидент.

Статус
Публично резюме; evidence при договорен преглед
В сила
Не е в сила
Планирана дата
1 септември 2026 г.
Обновен
1 септември 2026 г.
За кого
Практики, IT, DPO и security екипи
Към документа

1. Подход, основан на риска

Тефтер обработва здравни и идентификационни данни и прилага многослойни контроли за поверителност, цялостност, наличност и отчетност. Това резюме не е сертификат и не заменя due diligence, DPA или production evidence.

2. Основни контроли

ОбластТекущ подход
ИдентичностИндивидуални акаунти, bcrypt, email 2FA, WebAuthn/passkeys, memory-only access token, HttpOnly refresh cookie, CSRF, rotation/reuse detection и server-side revocation
ДостъпRBAC, server-side authorization, tenant context и отделна PostgreSQL схема за практика
КриптиранеTLS при пренос; AES-256-GCM за ЕГН/ЛНЧ на ниво поле; presigned S3 access
ОтчетностAudit trail за чувствителни действия, export, преглед и файлови операции
МинимизацияRedacted отговори за роли без клиничен достъп и ограничаване на PII в application logs
Жизнен цикълRetention jobs за избрани категории, controlled erasure и offboarding runbooks
ИнцидентиContainment, оценка на риска, уведомяване и postmortem процедура

3. Наличност и възстановяване

Съществуват backup и restore runbooks, проверки на checksum и възможност за off-site копия. Публично не се обещават конкретни RPO/RTO или успешен периодичен restore, докато те не са измерени, документирани и договорно одобрени.

4. Сигурна разработка

  • Минимални и целеви промени с code review и automated tests за критични потоци.
  • Regression тестове за ownership, роли, tenant isolation, финанси и външни интеграции.
  • Версионирани database migrations и rollback/backup процедури.
  • Dependency и configuration review преди release.
  • Отделяне на demo/mock от production интеграции и ясни preflight предупреждения.

5. Споделена отговорност

  • Практиката управлява екипа, ролите, устройствата и своевременното отнемане на достъп.
  • Потребителите проверяват получателя и документа преди print, download, share или email.
  • Не се използват общи пароли и не се въвеждат реални пациентски данни в demo кабинет.
  • Локално изтеглен файл и отпечатан документ вече са под контрола на практиката.

6. Публично декларирани ограничения

  • Новият auth модел използва memory-only access token и rotating HttpOnly Secure SameSite=Strict refresh cookies с CSRF и reuse detection; effective production cookie/CORS/TTL конфигурацията трябва да бъде доказана след rollout.
  • Legacy plain SHA-256 стойностите за търсене по ЕГН/ЛНЧ трябва да бъдат заменени чрез контролирания all-tenant HMAC rehash job и доказан zero-mismatch резултат.
  • Не всички клинични свободни текстове са криптирани field-level; защитата разчита и на database, OS, access и network контроли.
  • Binary S3 файловете все още могат да изискват отделно защитено предаване при пълен DSAR export.
  • Behavioral anomaly detection за масов export е ограничен и изисква допълнително развитие.
  • Production vendor evidence, restore drills и пълният tenant offboarding се проследяват като отделни readiness задачи.

7. Докладване на проблем

Не изпращайте пациентски данни в първоначалния сигнал. Опишете засегнатия домейн, стъпките, времето и потенциалния ефект на support@mytefter.bg с тема „Сигурност“. При активен критичен риск не тествайте допълнително върху production.

Официални източници

Източниците подпомагат прегледа; приложимостта за конкретната практика се оценява отделно.