Безпека - технічні деталі

Оновлено: 20 вересня 2026 р.

Технічне доповнення до сторінки Як ми захищаємо ваші дані. Описує окремі механізми застосунку; це не сертифікація інфраструктури й не гарантія однакового режиму для всіх категорій даних.

I. Дані особи - Bank iD та ручна перевірка

Особу перевіряємо через Bank iD або ручною перевіркою уповноваженим працівником на онлайн-дзвінку. Результати перевірки й необхідні ідентифікаційні дані зберігаються; окремі чутливі поля шифруються на рівні застосунку.

Bank iD. Застосунок обробляє підтверджені дані авторизаційного процесу та зберігає знімок ідентифікаційних даних для трудового й зарплатного обліку. Дані входу до банку не отримує.

Ручна перевірка. Уповноважений працівник записує дані з документа на онлайн-дзвінку; зображення документа до робочого сховища не завантажується. Результат має джерело MANUAL_ADMIN і той самий аудиторський слід, що й Bank iD.

Аудит і зберігання. Події перевірки особи й підписання мають аудиторські записи. Операційні копії, матеріали перевірки та обов’язкові трудові записи мають різні цілі зберігання; єдиний строк 60 днів до всіх них не застосовується. Видалення облікового запису не видаляє всіх обов’язкових записів.

II. Токени та сесії

Під час входу клієнт отримує два токени: короткостроковий JWT access token і повторно використовуваний refresh token (14 днів ковзним, 365 днів абсолютно).

Refresh token є opaque. 64-символьний рядок з випадкових hex-символів - не JWT. Його не можна "розшифрувати" поза нашим backend. При кожному використанні ротується: старий токен одразу позначається використаним, видається новий.

Ротація та повторні запити. RefreshTokenService використовує family_id для ланцюжка однієї сесії. Оновлення позначає попередній токен використаним. Обмежене вікно відновлення 300 секунд дозволяє повторення, якщо наступник ще не використаний; кеш відновлення тимчасово містить новий токен. Повторення поза дозволеними умовами скасовує цю родину, а не всі незалежні сесії користувача.

Активні пристрої. На /account/security/sessions (веб) і /sessions (мобільний) користувач бачить усі активні сесії, їхню останню активність та пристрій / локацію (з User-Agent та IP-адреси, збереженої з кожним виданим токеном сесії; IP-адреси з попередніх оновлень залишаються в аудиторському ланцюжку токенів до видалення облікового запису, а IP-адреси дій підписання та перевірки - в аудиторських записах). Сесії можна відкликати індивідуально або групою; відкликання анулює родину, а не лише один токен.

III. Файли та документи

Робоче сховище має дві частини: публічні зображення та вкладення чату й підтримки зберігаємо в Amazon S3 (eu-central-1, Франкфурт), а публічні зображення доставляємо через Amazon CloudFront; договори, підписані документи (DPP, декларації), документи BOZP, сертифікації та резюме зберігаємо в Hetzner Object Storage (Фалькенштайн, Німеччина). Середовища розробки можуть використовувати MinIO. Публічні зображення та приватні документи мають різні вимоги до доступу.

Посилання на файли. Для керованих об’єктів застосунок працює з ключем об’єкта й видає URL відповідно до призначення та прав. Підписані посилання мають обмежений строк; власник чинного посилання може завантажити файл. Підписані посилання на непублічні документи зазвичай дійсні 60 секунд, вкладення чату й підтримки - до 72 годин. Це не запобігає копіюванню.

Триступеневий контроль доступу (apps/api/src/modules/storage/storage.controller.ts):

1. Публічні файли (логотипи компаній, профільні фото, фото оголошень) - доступні без авторизації за постійною адресою через CDN із довготривалим кешуванням; вони не підписуються та призначені для оприлюднення.
2. Authenticated assets (договори, документи до замовлень) - перевіряємо JWT і власність перед видачею signed URL.
3. Tenant-scoped assets (внутрішні документи компанії) - додатково перевіряємо X-Active-Company-Id header, тож адміністратор компанії А не має доступу до файлів компанії B.

IV. Шифрування при передачі та окремих даних під час зберігання

Під час передачі. Публічні інтерфейси використовують HTTPS/TLS. Конкретні налаштування TLS і проксі визначає конфігурація відповідного розгортання.

Під час зберігання. Застосунок використовує AES-256-GCM для окремих чутливих ідентифікаційних і зарплатних даних. Це не гарантує шифрування всього диска бази даних, кожного файла чи кожної резервної копії.

Cross-tenant scope safety. Публічні запити до таблиці companies проходять через excludePlatformCompany() (apps/api/src/common/scopes/exclude-platform-company.scope.ts) - внутрішній FIXIT_PLATFORM shell-employer таким чином не може просочитись у публічні переліки, пошук чи Elasticsearch-індексацію.

Вхідні дані користувача. Захист включає валідацію, перевірку прав, безпечне відображення та перевірки URL перед завантаженням сервером. Різні типи контенту обробляються по-різному; не всі вхідні дані проходять однакове очищення.

V. GDPR та контакти

FixIt.app s.r.o. є контролером персональних даних згідно зі статтею 4 GDPR. Наша Політика конфіденційності описує юридичні рамки та ваші права.

• Контакт із захисту даних: legal@fixit.app
• Наглядовий орган: Чеське управління із захисту персональних даних - Pplk. Sochora 27, 170 00 Прага 7

Повідомлення про проблеми безпеки: security@fixit.app. Додайте кроки відтворення та вплив; просимо узгоджувати публікацію з нами.

Запитання про ці механізми: security@fixit.app.