Безпека та довіра

1. Резюме на одній сторінці

Наш чесний поточний стан станом на 08.07.2026: Nose for Horse (далі — «Nose») — це продукт на ранній стадії, яким керує один оператор. Сьогодні ми НЕ маємо SOC 2 або ISO 27001, і ми ще не проводили зовнішній тест на проникнення. На цій сторінці описано, що ми робимо, що маємо, а чого ще не маємо. Ми б радше прямо сказали вам, де ми перебуваємо, ніж перебільшували.

• Хто ми. Nose — це програмне забезпечення для роботи школи верхової їзди — планування уроків, відстеження відвідуваності та оплати вершників, керування абонементами та подарунковими сертифікатами, підрахунок прибутків інструкторів і надання клієнтам стайні перегляду їхніх власних бронювань. Ним керує DF Daniel Fojcik, польське одноосібне підприємство (NIP 6472592229 / REGON 387798601, Маркловіце), що веде діяльність під назвою Nose for Horse.
• Наші дві ролі. Ми є контролером даних для нашого власного облікового запису, аналітичних даних і даних безпеки, а також обробником даних, який виконує вказівки кожної стайні щодо даних вершника/клієнта, які вводить стайня. Відносини з обробником регулюються нашою Угодою про обробку даних (DPA). Див. «Система відповідності» нижче.
• Що ми зберігаємо. Електронна адреса облікового запису та необов’язкове ім’я/телефон профілю; електронні адреси запрошень; оперативні записи, які стайня вводить про своїх вершників (імена, контакти, участь в уроках, абонементи/сертифікати, мітки відстеження платежів, довільні текстові примітки); PIN-коди розкладу, хешовані bcrypt; SHA-256-хешовані маркери запрошень. Ми не зберігаємо даних платіжних карток чи банківських даних, а також даних про стан здоров’я. Повний список у розділі «Дані, які ми зберігаємо» нижче.
• Що його захищає. TLS всюди з попереднім завантаженням HSTS; шифрування в стані спокою (AES-256); безпека на рівні рядків, яка забезпечується базою даних, ізолює кожну стайню; перевірка сесії на стороні сервера; посилена повторна автентифікація для деструктивних і адміністративних дій; сувора політика безпеки контенту; обмеження швидкості та захист від ботів; і журнал аудиту лише для додавання. Повний список у розділі «Технічні заходи» нижче.
• Де він працює. У більш ніж одному регіоні даних, і ми додаємо регіони в міру зростання. Дані клієнтів стайень у регіоні США зберігаються у Сполучених Штатах. Сервіс керується, адмініструється та підтримується з Європейського Союзу. Стайні в нашому регіоні ЄС обслуговуються з ЄЕЗ. Кілька послуг є спільними для обох регіонів і працюють у ЄЕЗ — трансакційні електронні листи, моніторинг помилок, аналітика за згодою, — а кілька компонентів працюють глобально. Регіони та механізми передачі окремих постачальників — окремо для кожного регіону даних — вказано в розділі «Інфраструктура — хто керує чим і де» нижче та на сторінці Субпроцесори.
• Чого ми ще не маємо. Немає SOC 2, ISO 27001, зовнішнього тесту на проникнення чи програми винагороди за помилки. Якщо для вашого процесу закупівель сьогодні потрібна SOC 2, ми ще не підходимо.
• Як зв’язатися з нами щодо безпеки. Надішліть електронний лист support@nose.horse, указавши в темі `Security`. Див. нижче «Реагування на інцидент (повідомлення про порушення за 72 години)» і «Відповідальне розголошення».

2. Дані, які ми зберігаємо

Ми збираємо мінімум, необхідний для роботи Сервісу. Категорії нижче - це особисті дані, які стосуються Nose.

Там, де в рядку зазначено регіон вашої стайні, ідеться про регіон ЄС або регіон США — визначений у момент створення стайні та описаний у розділі «Інфраструктура — хто керує чим і де» нижче.

Що ми не тримаємо

• Без даних платіжних карток чи банківських реквізитів. Nose ніколи не є стороною платежу та не обробляє дані картки. Офлайн-методи («готівка», «абонемент», «сертифікат», «переказ») є позначками обліку, а не транзакціями. Для підписки стайні (Stripe для польських стайнь, Dodo Payments як Merchant of Record для непольських стайнь) і для онлайн-платежів вершників, якщо стайня їх увімкнула (через Stripe на власний обліковий запис стайні), дані картки обробляються винятково на платіжній сторінці провайдера і ніколи не надходять до нас. Тому ми залишаємося поза сферою PCI DSS (див. «Система відповідності» нижче).
• Немає документів, що посвідчують особу, або адрес. Ми не збираємо домашні адреси, номери ідентифікаційних документів або державні ідентифікатори.
• Немає даних особливих категорій (зокрема даних про здоров’я). Ми не маємо наміру збирати дані за статтею 9 GDPR, і продукт не призначений для їх зберігання. Стайням наказано в DPA не вводити дані особливих категорій у поля довільного тексту. Примітки про коня стосуються тварини, а не людини, і не підпадають під GDPR.
• Жодних рекламних профілів, ідентифікаторів перенацілювання чи міжсайтового відстеження. Жодних пікселів Meta/LinkedIn/X/TikTok; відсутність відбитків пальців браузера.
• Ми не продаємо, не здаємо в оренду й не позичаємо дані третім особам.
• Ми не навчаємо моделі AI/ML на ваших даних. Ми не навчаємо, не налаштовуємо й не оцінюємо моделі ШІ або машинного навчання на персональних даних, отриманих через Nose. Розширення `pgvector` увімкнене в Postgres для можливих майбутніх сценаріїв внутрішнього пошуку, але зараз не містить ембедингів персональних даних.

3. Інфраструктура — хто керує чим і де

Nose — це програма Next.js, розміщена на Vercel, яка підтримується базою даних Supabase Postgres, з невеликим набором спеціалізованих постачальників («субпроцесорів»), кожен з яких обробляє вузький фрагмент. Жоден не має наскрізного доступу до всього. Nose працює у двох регіонах даних: регіоні ЄС і регіоні США. Дані клієнтів стайень у регіоні США зберігаються у Сполучених Штатах. Сервіс керується, адмініструється та підтримується з Європейського Союзу. Операційні дані стайні зберігаються лише в базі даних її власного регіону — між регіонами немає реплікації і немає шляху в програмі, який читав би дані між ними. Три послуги є спільними для обох регіонів і залишаються в ЄЕЗ — трансакційні електронні листи, моніторинг помилок і аналітика продукту за згодою. Таблиця нижче називає регіон кожного постачальника окремо для кожного регіону даних; канонічним списком — з категоріями даних і механізмами передачі — є сторінка Субпроцесори.

Канонічна, завжди актуальна версія цієї таблиці — з категоріями персональних даних для кожного постачальника та механізмами передачі — підтримується на сторінці Субпроцесори; Політика конфіденційності та DPA посилаються на одне джерело, а не зберігають різні копії.

4. Технічні заходи

Це елементи керування, які фактично діють сьогодні. Це також суть DPA → «Конфіденційність, безпека та субпроцесори», яка вказує тут на наші технічні та організаційні заходи.

Мережа та транспорт

• TLS для всього трафіку, який забезпечується Vercel і Supabase. HSTS встановлено як `max-age=63072000; includeSubDomains; preload`.
• Без змішаного вмісту — Політика безпеки вмісту відхиляє ресурси `http://`.

Ізоляція та авторизація орендарів

• Безпека на рівні рядків (RLS) для кожної стайні в кожній робочій таблиці, примусово у самій базі даних — дані однієї стайні не можуть бути прочитані іншою, навіть якщо код програми містить помилку. Це основний захист між орендарями.
• Рольові ворота на прикладному рівні (автентифіковані / у межах стайні / інструктор-або-адміністратор / суперадміністратор) як поглиблений захист поверх RLS, ніколи як єдина лінія.
• Перевірки на рівні маршрутів вимагають активного сеансу для захищених шляхів і статусу суперадміністратора для поверхні адміністратора.

Автентифікація

• Вхід без пароля — магічне посилання електронної пошти (оброблюється Supabase Auth) або додатковий вхід Google (OAuth). Паролі не зберігаються.
• Перевірка сеансу на стороні сервера для кожного захищеного запиту — файл cookie для входу ніколи не вважається надійним.
• Повторна автентифікація з підвищенням прав (step-up) для деструктивних і адміністративних дій — для таких операцій, як видалення облікового запису, зміни ролі останнього адміністратора, масова деактивація, архівування стайні та всі записи суперадміністратора, потрібен короткочасний окремо підписаний файл cookie підвищення прав; якщо його немає або строк його дії минув, доступ блокується (fail-closed).
• Поверхня адміністратора платформи повертає 404, якщо суперадміністратора не налаштовано, тому його існування не витікає.

Секрети та обробка облікових даних

• PIN-коди розкладу зберігаються як хеші bcrypt; маркери запрошень зберігаються як хеші SHA-256 — одноразові, обмежені за часом (строк дії — 7 днів) і прив’язані до електронної пошти; необроблені токени ніколи не зберігаються.
• ключ ролі сервісу бази даних призначений лише для сервера — він ніколи не додається до JavaScript клієнта; валідатор часу збирання не виконує збірку, якщо чутлива змінна має неправильний префікс.

Обробка введення та виведення

• Перевірка схеми на кожній межі входу сервера — перевірка на стороні клієнта розглядається лише як UX; сервер є межею довіри.
• Строга політика безпеки вмісту з nonce для кожного запиту, а також блокований набір заголовків безпеки (`X-Content-Type-Options`, `X-Frame-Options` / `frame-ancestors`, `Referrer-Policy`, заголовки ізоляції між джерелами та обмежувальна `Permissions-Policy`).
• Автоматичне екранування виводу; вміст, створений користувачем, на цьому етапі є простим текстом.

Захист від зловживань і ботів

• Обмеження частоти для входу, реєстрації, магічного посилання, прийняття запрошення, експорту/видалення та інших конфіденційних кінцевих точок (для електронної пошти, для IP-адреси, для користувача чи для стайні залежно від дії; кожна політика є відкритою або закритою при помилках).
• Захист від ботів Cloudflare Turnstile у формі входу, формі реєстрації, запиті магічного посилання, сторінці прийняття запрошення та введенні PIN-коду загальнодоступного розкладу.

Дані в стані спокою та контрольний слід

• Шифрування в стані спокою через Supabase (AES-256).
• Журнал аудиту лише для додавання записує події, пов’язані з безпекою (автентифікація, зміни ролі та членства, фінансові події, експорт, видалення). Запис ведеться завжди, і він відрізняється від оперативної телеметрії.
• Моніторинг помилок із очищенням особистих даних — перед тим, як будь-яка помилка буде надіслана до Sentry, спеціальний скрабер видаляє адреси електронної пошти, номери телефонів, текст повідомлення, примітки та будь-які поля, які виглядають як маркери. Залишається технічний контекст плюс псевдонім UUID користувача, ідентифікатор стайні, локаль і назва невдалої операції.

Резервне копіювання та відновлення

• Supabase забезпечує автоматичне щоденне резервне копіювання (зберігання протягом 7 днів на поточному рівні; довше збереження планується в міру розвитку служби). Vercel зберігає попередні розгортання для майже миттєвого відкоту поганого випуску.

5. Організаційні заходи

• Соло оператор. Nose керує одна людина (Даніель Фойчик). Наразі немає працівників із доступом до робочого (продакшн) середовища. Якщо це зміниться (наприклад, буде залучено підрядника з доступом до продакшн-середовища), цю сторінку буде оновлено, а активні стайні повідомлено.
• Дані робочого середовища залишаються в керованій інфраструктурі. Дампи продакшн-баз даних не зберігаються на локальних машинах; локальна розробка використовує окрему базу даних із синтетичними даними.
• Найменший привілей для облікових записів служби. Ключ ролі служби бази даних призначений лише для використання на стороні сервера; доступ до бази даних із браузера використовує обмежений ключ, що працює за захистом на рівні рядків.
• Керування секретами. Секрети зберігаються в конфігурації середовища хостинг-провайдера та локальному файлі, який ігнорується, — ніколи не передається в репозиторій. Секрети робочого середовища не копіюються на локальні машини.
• Реєстрація доступу на стороні постачальника. Адміністративні дії щодо наших постачальників реєструються цими постачальниками; ми переглядаємо їх за потреби (ad hoc).
• Конфіденційність. Персонал (наразі власник) зобов’язаний дотримуватися конфіденційності персональних даних, які обробляються через Сервіс, як зазначено в DPA.
• Дисципліна змін. Зміни коду проходять сувору перевірку типів, лінтинг і автоматичні тести перед розгортанням, а міграції бази даних застосовуються до проміжного середовища перед робочим.

6. Реагування на інцидент (повідомлення про порушення за 72 години)

Моніторинг. Помилки надходять до Sentry (з очищенням персональних даних, описаним у розділі «Технічні заходи» вище); діагностика на рівні запиту доступна в журналах хостингу; Монітор безвідмовної роботи та сповіщення про частоту помилок є частиною базової лінії зміцнення. Журнал аудиту лише для додавання забезпечує надійний запис подій, пов’язаних із безпекою, для розслідування.

Наше зобов’язання сповіщати про порушення. Якщо станеться порушення безпеки персональних даних, яке може призвести до ризику для прав і свобод постраждалих осіб, ми:

• повідомимо компетентний наглядовий орган — Президента UODO в Польщі — без невиправданої затримки та, якщо це можливо, протягом 72 годин після того, як нам стало відомо про порушення (Стаття 33 GDPR);
• *якщо порушення може призвести до високого* ризику для постраждалих осіб, повідомимо їх без невиправданої затримки, описавши характер порушення, категорії задіяних даних, ймовірні наслідки та вжиті заходи (Стаття 34 GDPR**);
• якщо ми виступаємо як процесор для стайні, сповістимо цю стайню (контролера) без зайвої затримки, щоб вона могла виконати свої власні зобов’язання за статтями 33/34 перед своїми вершниками.

Це відображає Політику конфіденційності та DPA. У ньому зазначено, як ми маємо намір виконувати зобов’язання, які вже накладає GDPR — це не додаткова договірна обіцянка поза GDPR. Формально задокументований регламент реагування на інциденти міститься в дорожній карті; до того часу команда з однієї особи реагує в ручному режимі (ad hoc) у межах зазначених вище строків.

Контакт. Нетерміново: support@nose.horse. Безпека (терміново): надішліть електронний лист support@nose.horse із `Security` в темі.

7. Система відповідності

GDPR (Регламент 2016/679). Nose має подвійну роль: контролера для даних, мету та засоби обробки яких він визначає (відвідувачі маркетингового сайту, облікові записи й контакти адміністраторів стайні та інструкторів, аналітика продукту за згодою, дані безпеки й запобігання зловживанням), і процесора для операційних даних вершників/клієнтів. Тут стайня є контролером, а Nose обробляє дані за її документованими інструкціями відповідно до DPA (стаття 28 GDPR). Субпроцесори діють за договорами відповідно до статті 28 (DPA + SCC/DPF, Доповнення для Великої Британії або еквівалентний механізм для міжнародного передавання) — див. сторінку «Субпроцесори».

Дані дітей. Школи верхової їзди регулярно навчають дітей, тому Nose свідомо обробляє дані неповнолітніх від імені стайні (наприклад, дитина введена як учасник уроку, часто батьком, який є клієнтом стайні). Стайня несе відповідальність за законну основу та будь-яку необхідну згоду або повноваження батьків відповідно до законодавства, яке до неї застосовується (стаття 8 GDPR в ЄС і Великій Британії; COPPA та законодавство штатів у Сполучених Штатах); Nose мінімізує те, що зберігається про дитину, не орієнтується на дітей і не спрямовує на них маркетинг безпосередньо. Див. Політику конфіденційності → «Конфіденційність дітей».

Права суб’єкта даних підтримуються, включаючи самообслуговування доступ/перенесення через експорт JSON за адресою /account/export і видалення через /account/delete (застосовується 30-денний оборотний пільговий період і повторна автентифікація з підвищенням прав; під час видалення ми вилучаємо прямі ідентифікатори, а не видаляємо запис остаточно — псевдонімізація відповідно до ст. 4(5) GDPR, а не повна анонімізація відповідно до пункту 26; див. таблицю зберігання в Політиці конфіденційності → «Як довго ми зберігаємо дані» для деталей на рівні поля). Для даних вершника контролером є стайня, тому вершник реалізує свої права щодо своєї стайні, а Nose допомагає як процесор.

PCI DSS — не застосовується до Nose. Ми не обробляємо, не зберігаємо та не передаємо дані карток. Для виставлення рахунків за підпискою стайні шлях до даних картки повністю передається платіжним постачальником на його розміщеній касі — Stripe (процесор платежів) для польських стайень, з Nose як торговцем і Dodo Payments як Merchant of Record для непольських стайень. Для онлайн-оплати вершника, якщо стайня це дозволяє, дані картки, гаманця або (у Польщі) BLIK повністю передаються Stripe (через Stripe Connect) і осідають у власному обліковому записі Stripe стайні — стайня є продавцем, а Stripe — це PCI-сумісний процесор, тоді як Nose лише передає інструкції та ніколи не отримує дані картки. У будь-якому випадку Nose ніколи не отримує дані картки і залишається поза межами PCI.

Акт ЄС щодо штучного інтелекту — не застосовується. Nose — це робочий інструмент для шкіл верхової їзди; він не навчає, не розробляє та не розгортає моделі ШІ, і жоден компонент не використовує машинне навчання чи генеративний ШІ для обробки персональних даних. Розширення `pgvector` Postgres увімкнуто для можливих майбутніх випадків використання внутрішнього пошуку, але сьогодні не містить векторних представлень (embeddings), похідних від персональних даних; якщо це зміниться, ми опублікуємо позицію щодо Закону про штучний інтелект ЄС і зобов’язання «не навчати моделі на персональних даних» перед запуском цієї функції.

ePrivacy / файли cookie. Додаткова аналітика (PostHog) завантажується лише за згодою; строго необхідні файли cookie звільняються відповідно до статті 5(3) Директиви про електронну конфіденційність. Перегляньте Політику щодо файлів cookie.

8. Відповідальне розголошення

Якщо ви вважаєте, що знайшли вразливість системи безпеки у Nose:

• Надішліть електронний лист [support@nose.horse](mailto:support@nose.horse) із `Security` у темі. (Планується виділена `security@` адреса та ключ PGP.)
• Додайте достатньо деталей, щоб відтворити проблему.
• Дайте нам розумний період для розслідування та виправлення перед будь-яким оприлюдненням.

Чого ви можете очікувати від нас:

• Підтвердження та початкова оцінка, як тільки це буде практично можливо. Nose — це індивідуальна служба, яка не може гарантувати відповідь у той же день; ми не залишимо достовірне повідомлення без уваги.
• Статус оновлюється через розумні проміжки часу, поки проблема перевіряється або вирішується.
• Згадка про вас у будь-якому розкритті інформації після виправлення, якщо ви цього бажаєте (необов’язково).

Чого ми поки що не можемо запропонувати: на даному етапі ми не виплачуємо винагороди за помилки. Ми чітко скажемо про це, якщо і коли програма баунті стане доступною.

Обсяг і безпечна гавань. Добросовісне дослідження безпеки, яке відповідає цій політиці, залишається у ваших власних облікових записах, уникає погіршення якості Сервісу для інших і не має доступу до даних, крім ваших власних, не вважатиметься порушенням нашої Політики прийнятного використання чи Умов використання. Не намагайтеся отримати доступ до даних іншої стайні чи іншого вершника, а також не запускайте автоматизований скрейпінг чи тестування на відмову в обслуговуванні Сервісу.

9. Журнал змін