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

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

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

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

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

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

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

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

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

horsenose — це програма Next.js, розміщена на Vercel, яка підтримується базою даних Supabase Postgres, з невеликим набором спеціалізованих постачальників («субпроцесорів»), кожен з яких обробляє вузький фрагмент. Жоден не має наскрізного доступу до всього. Ми працюємо в кількох регіонах і додаємо регіони в міру зростання, тому ми описуємо стан речей сьогодні, а не обіцяємо єдине постійне розташування: більшість основних процесів — бази даних, електронної пошти, аналітики продуктів і моніторингу помилок — знаходяться в ЄЕЗ, тоді як кілька компонентів уже працюють за його межами (глобальна перевага Cloudflare; необов’язковий вхід Google і частини Stripe у США; Dodo Payments на глобальній основі Merchant-of-Record). Поточний основний регіон для кожного постачальника наведено в таблиці нижче та залишається актуальним у міру його змін; кожен міжрегіональний маршрут охоплюється відповідним механізмом передачі (Рамкова угода про конфіденційність даних ЄС-США, Стандартні договірні положення, Додаток Великобританії або еквівалент, якого вимагає доданий регіон).

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

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

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

Мережа та транспорт- TLS для всього трафіку, який забезпечується Vercel і Supabase. HSTS встановлено як `max-age=63072000; includeSubDomains; попереднє навантаження`.

• Без змішаного вмісту — Політика безпеки вмісту відхиляє ресурси http://`.

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

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

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

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

— Поверхня адміністратора платформи повертає 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. Організаційні заходи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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