Безпека

1. Вступ та сфера застосування

Ця Заява про безпеку підсумовує технічні та організаційні заходи (далі — ТОМ), які Goup Space Sp. z o. o. застосовує для захисту персональних даних та інших даних, що обробляються через Платформу.

Оператор застосовує загальний принцип ст. 32 GDPR: «розумні технічні та організаційні заходи, пропорційні ризикам», з урахуванням рівня розвитку техніки, витрат на впровадження, а також характеру, обсягу, контексту та цілей обробки.

Оператор: Goup Space Sp. z o. o., контакт info@pages.otack.eu. Дотичні документи: Політика конфіденційності, Договір про обробку даних.

2. Шифрування під час передачі

Увесь трафік між браузером Користувача та Платформою шифрується по HTTPS / TLS (TLS 1.2 або вище).

Сесійний cookie WGSESS_{port} у середовищі продакшну встановлюється з прапором Secure (лише через HTTPS) та HttpOnly (недоступний з JavaScript), з атрибутом SameSite=Lax для пом'якшення CSRF.

3. Ключі AI — точна позиція (НЕ zero-knowledge)

Цей розділ описує наше поводження з API-ключами Користувача до сторонніх AI-провайдерів. Зміст по суті ідентичний Політиці конфіденційності §9.

API-ключ Користувача до AI-провайдера шифрується у браузері за допомогою PBKDF2 + AES-256-GCM (Web Crypto API). Пароль шифрування ніколи не передається Оператору.

Зашифрований blob зберігається у users.ai_keys_blob (режим Account) або у браузерному localStorage (режим File). Оператор не може розшифрувати жодне з цих сховищ.

Коли Користувач робить AI-запит, ключ розшифровується у браузері й надсилається Оператору через TLS у HTTP-заголовку X-AI-API-Key. Ключ тримається у пам'яті PHP лише на час одного AI-запиту, після чого видаляється.

Ключ ніколи не зберігається у читабельній формі в інфраструктурі Оператора та ніколи не логується (прапор захоплення корисного навантаження у generation_log зберігає лише запит та відповідь, але ніколи — ключ).

Для асинхронних завдань генерації, що поміщаються до внутрішньої черги Redis, ключ повторно шифрується через AES-256-GCM (JobEncryptor) перед потраплянням до черги і стирається з черги після того, як воркер обробив завдання.

Оператор не реалізує справжню «zero-knowledge» архітектуру: ключ проходить через сервер Оператора у відкритому вигляді протягом одного запиту. Проте Оператор ніколи не зберігає ключ у читабельній формі та не логується його.

4. Паролі

Паролі Користувачів ніколи не зберігаються у відкритому вигляді. Паролі хешуються за допомогою bcrypt (PASSWORD_BCRYPT через функцію PHP password_hash()) з індивідуальною сіллю; Оператор не зберігає оригінальний пароль.

Токени відновлення паролю та підтвердження e-mail є випадковими, одноразовими та мають короткий термін дії.

5. Контроль доступу та розділення адміністративної й користувацької автентифікації

Платформа розділяє користувацьку автентифікацію (таблиця users) та адміністративну автентифікацію (таблиця admins). Ключі сесій користувачів та адміністраторів є різними.

Дії адміністраторів записуються до незмінного журналу аудиту (таблиця admin_audit_log) із зазначенням адміністратора, дії, сутності та змін стану.

На рівні застосунку запроваджено обмеження частоти запитів (rate limiting) на ендпоінтах автентифікації для зменшення ризику атак перебором.

6. Захист від CSRF та цілісність запитів

Усі HTTP-запити, що змінюють стан (POST та подібні), захищені анти-CSRF middleware, який перевіряє 32-байтовий випадковий токен, прив'язаний до сесії Користувача.

7. Шифрування корисного навантаження черги

Внутрішня черга завдань (на базі Redis) переносить чутливі дані — API-ключі AI, SFTP-облікові дані для розгортання тощо.

Усі чутливі поля у завданнях черги шифруються за допомогою AES-256-GCM (JobEncryptor) з випадковим IV для кожного навантаження та AEAD-тегом перед потраплянням до черги.

Чутливі поля видаляються з будь-якого завдання, що переноситься до черги «мертвих» повідомлень (dead-letter).

8. Платіжні дані — поза нашою сферою

Дані картки (PAN, термін дії, CVV) збираються та обробляються виключно Stripe Payments Europe Ltd. (1 Grand Canal Street Lower, Grand Canal Dock, Dublin 2, Ireland).

Оператор ніколи не отримує, не зберігає та не обробляє дані картки. Оператор зберігає лише метадані, необхідні для звірення (посилання на замовлення, сума, валюта, статус, ID замовлення у провайдера, e-mail покупця).

9. Резервні копії, моніторинг та реагування на інциденти

Оператор виконує регулярні резервні копії бази даних, щоб уможливити відновлення у разі втрати або пошкодження даних. (Конкретні цілі RTO/RPO у цій Заяві не публікуються.)

Оператор моніторить логи застосунку та інфраструктури на предмет подій безпеки.

У разі порушення безпеки персональних даних Оператор діє згідно зі ст. 33 GDPR (повідомлення наглядового органу — Prezes UODO — упродовж 72 годин, якщо порушення може створити ризик для прав і свобод фізичних осіб) та ст. 34 GDPR (повідомлення суб'єктів даних без невиправданої затримки, якщо порушення може створити високий ризик).

10. Обов'язки Користувача та контакти

Користувач відповідає за:

збереження конфіденційності паролю свого облікового запису та використання унікального стійкого паролю;
збереження паролю шифрування AI-ключів (Оператор не може його відновити);
конфігурування своїх опублікованих Згенерованих сайтів відповідно до вимог безпеки (повідомлення про конфіденційність, банер cookie, HTTPS).

Повідомлення про проблему безпеки: зверніться на info@pages.otack.eu з відповідними деталями. Оператор розглядає такі звернення та відповідає згідно зі своєю процедурою розгляду скарг (див. Умови оплати та повернення коштів §10).

Дата набрання чинності: 2026-05-20. Англійська версія є основною; у разі розбіжностей пріоритет має англійська версія.