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

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

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

• Хто ми. Nose — це програмне забезпечення для роботи школи верхової їзди — планування уроків, відстеження відвідуваності та оплати вершників, керування абонементами та подарунковими сертифікатами, підрахунок прибутків інструкторів і надання клієнтам стайні перегляду їхніх власних бронювань. Ним керує DF Daniel Fojcik, польське одноосібне підприємство (NIP 6472592229 / REGON 387798601, Маркловіце), що веде діяльність під назвою Nose for Horse.
• Наші дві ролі. Ми є контролером даних для нашого власного облікового запису, аналітичних даних і даних безпеки, а також обробником даних, який виконує вказівки кожної стайні щодо даних вершника/клієнта, які вводить стайня. Відносини з обробником регулюються нашою Угодою про обробку даних (DPA). Див. «Система відповідності» нижче.
• Що ми зберігаємо. Електронна адреса облікового запису та необов’язкове ім’я/телефон профілю; електронні адреси запрошень; оперативні записи, які стайня вводить про своїх вершників (імена, контакти, участь в уроках, абонементи/сертифікати, мітки відстеження платежів, довільні текстові примітки); PIN-коди розкладу та маркери запрошень, що зберігаються лише як односторонні хеші. Ми не зберігаємо даних платіжних карток чи банківських даних, а також даних про стан здоров’я. Повний список у розділі «Дані, які ми зберігаємо» нижче.
• Що його захищає. Шифрування під час передавання та в стані спокою; ізоляція орендарів, що забезпечується в самій базі даних; перевірка сесії на стороні сервера; посилена повторна автентифікація для деструктивних і адміністративних дій; сувора політика безпеки контенту; обмеження швидкості та захист від ботів; і журнал аудиту лише для додавання. Див. розділ «Технічні заходи» нижче.
• Де він працює. У більш ніж одному регіоні даних, і ми додаємо регіони в міру зростання. Дані клієнтів стайень у регіоні США зберігаються у Сполучених Штатах. Сервіс керується, адмініструється та підтримується з Європейського Союзу. Стайні в нашому регіоні ЄС обслуговуються з ЄЕЗ. Кілька послуг є спільними для обох регіонів і працюють у ЄЕЗ — трансакційні електронні листи, моніторинг помилок, аналітика продукту, — а кілька компонентів працюють глобально. Регіони та механізми передачі окремих постачальників вказано на сторінці Субпроцесори.
• Чого ми ще не маємо. Немає SOC 2, ISO 27001 чи зовнішнього тесту на проникнення. Якщо для вашого процесу закупівель сьогодні потрібен якийсь із них, ми ще не підходимо.
• Як зв’язатися з нами щодо безпеки. Надішліть електронний лист 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.

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

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

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

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

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

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

• TLS для всього трафіку, з попереднім завантаженням HSTS.
• Без змішаного вмісту — Політика безпеки вмісту відхиляє незахищені ресурси.

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

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

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

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

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

• PIN-коди розкладу та токени запрошень зберігаються лише як односторонні хеші; токени запрошень є одноразовими й обмеженими за часом, а необроблені токени ніколи не зберігаються.
• Привілейовані облікові дані служб працюють лише на сервері — вони ніколи не потрапляють у браузер; це забезпечує перевірка на етапі збирання.

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

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

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

• Обмеження частоти та захист від ботів застосовуються до автентифікації та інших конфіденційних кінцевих точок.

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

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

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

• Автоматичне щоденне резервне копіювання бази даних із рухомим вікном зберігання. Попередні розгортання зберігаються, щоб можна було швидко відкотити невдалий випуск.

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

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

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

Моніторинг. Помилки та події, пов’язані з безпекою, відстежуються, а журнал аудиту лише для додавання забезпечує надійний запис для розслідування.

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

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

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

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

7. Чого ми ще не маємо

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

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

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 допомагає як процесор; виняток — дані для входу вершника, контролером яких є Nose, тож права щодо них реалізуються безпосередньо щодо Nose.

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

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

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

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

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

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

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

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

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

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