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

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

Предварителна версия за юридически преглед

Документът е подготвен спрямо реалните функции на Тефтер и приложимата европейска рамка, но още не е активиран като договорен текст. Бъдещият доставчик е Swift Digital, българско дружество. Преди влизане в сила трябва да бъдат потвърдени точната правна форма, ЕИК, седалището, адресът, представляващият, контактът за поверителност, договорните доставчици и приложимите специални срокове за медицинска документация.

Тефтер обработва здравни и идентификационни данни и прилага многослойни контроли за поверителност, цялостност, наличност и отчетност. Това резюме не е сертификат и не заменя 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.

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

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