SOC 2 та HIPAA для відстеження посилань: відповідь для відділу закупівель

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

Ця публікація відповідає на питання, які відділи закупівель великих компаній насправді ставлять щодо SOC 2 Type II та HIPAA, коли оцінюють постачальника послуг відстеження посилань. Вона написана як для тих, хто заповнює анкету, так і для тих, хто перевіряє відповіді.

Коротко#

Elido має сертифікацію ISO 27001. Отримання SOC 2 Type II зараз у процесі з цільовою датою завершення у другій половині 2026 року — вікно аудиту почалося в лютому 2026 року, збір доказів триватиме до липня, а звіт Type II очікується до кінця четвертого кварталу. HIPAA підтримується на тарифних планах Business та Enterprise з підписанням Business Associate Agreement (BAA); базові засоби контролю такі ж самі, як і для SOC 2.

Статус відповідності GDPR розглядається окремо від SOC 2 та HIPAA і висвітлений у нашому матеріалі GDPR для скорочувачів URL-адрес. Ця стаття фокусується на американських фреймворках атестації, які є визначальними для перевірок при закупівлях у великих корпораціях.

Що насправді говорить SOC 2 про сервіс скорочення посилань#

SOC 2 — це звіт, а не сертифікація. Незалежний аудитор (фірма CPA у US або визнаний аудиторський орган у EU) перевіряє сервісну організацію на відповідність Критеріям довірчих послуг AICPA та надає свій висновок. Type I засвідчує, що засоби контролю розроблені належним чином на певний момент часу; Type II підтверджує, що вони ефективно працювали протягом певного періоду — зазвичай від шести до дванадцяти місяців.

Критерії довірчих послуг поділяються на п'ять категорій. Кожен звіт SOC 2 охоплює Security (Безпеку); інші чотири (Availability, Processing Integrity, Confidentiality, Privacy) включаються за вибором сервісної організації залежно від потреб клієнтської бази.

Security — категорія, що включена завжди#

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

• CC6.1 Logical access: хто може створювати, змінювати або видаляти короткі посилання, а також як цей доступ надається та скасовується. Аудит відстежуватиме конкретних користувачів від запису про найм у HR до IdP (Ory Kratos для Elido) та призначення ролей у робочому просторі, а також перевірить, чи був їхній доступ видалений у встановлений термін після звільнення.
• CC6.6 External access: як зовнішні користувачі (власники кастомних доменів, споживачі API, партнерські інтеграції) проходять автентифікацію та які права доступу вони отримують. Модель токенів API з ключами ідемпотентності та обмеженням прав на рівні робочого простору — це саме те, що захоче побачити аудитор.
• CC7.2 Monitoring: що логується, куди надходять логи та як виявляються аномалії. Для сервісу редиректів релевантними сигналами є незвичний обсяг перенаправлень на робочий простір, спрацьовування обмежень частоти запитів (rate-limit) на edge-вузлах та помилки автентифікації.
• CC8.1 Change management: зміни коду від pull request до розгортання, з розподілом обов'язків між інженером, який вніс зміни, та рев'юером, який їх затвердив. Аудит перевірить вибірку pull requests та проаналізує записи про схвалення та розгортання.

Критерії Security також передбачають наявність задокументованого плану реагування на інциденти. Для сервісу редиректів актуальними інцидентами є несанкціоноване створення посилань, підміна кінцевих адрес редиректів та витік даних через кінцеві точки експорту аналітики. План дій для кожного випадку описано в runbook за адресою /docs/runbooks/.

Availability — друга за поширеністю категорія#

Availability охоплює зобов'язання щодо часу безвідмовної роботи (uptime), планування потужностей та аварійне відновлення. Для скорочувача URL-адрес важливими є такі артефакти:

• Задокументовані цілі рівня обслуговування (SLO). Опублікований SLO Elido становить 99.95% доступності редиректів на квартал, з окремими SLO для панелі управління (99.9%) та API аналітики (99.5%).
• Докази тестування потужності. Сервіс edge-редиректів проходить безперервні навантажувальні тести у staging; аудит шукає докази того, що межі виробничої потужності відомі та моніторяться відповідно до SLO.
• Докази резервного копіювання та відновлення. Postgres використовує Patroni HA з можливістю відновлення на певний момент часу; ClickHouse щодня експортує дані в об'єктне сховище; аудиту потрібен лог навчальних відновлень, який підтверджує, що цільовий час відновлення є досяжним.
• Документація щодо відмовостійкості між регіонами. Три вузли (Frankfurt, Ashburn, Singapore) працюють у режимі active-active для редиректів; аудитор вивчить runbook для відмовостійкості та звіт про останню подію в одному з регіонів.

Confidentiality та Privacy — включаються вибірково#

Категорії Confidentiality та Privacy частково перетинаються з вимогами GDPR. Більшість корпоративних клієнтів у EU віддають перевагу вирішенню питань приватності через документацію GDPR (договори про обробку даних згідно зі Статтею 28, оцінка впливу передачі даних, публічна DPA), а не через SOC 2 Privacy. Поточний обсяг аудиту SOC 2 в Elido включає Security, Availability та Confidentiality. Питання Privacy розглядаються окремо через пакет документів GDPR на сторінці /trust.

Причина такого поділу: SOC 2 Privacy базується на Generally Accepted Privacy Principles AICPA, які були розроблені для фреймворків приватності US. GDPR — це окрема законодавча база з власними контролями. Поєднання обох в одній атестації зазвичай послаблює кожну з них.

Що насправді говорить HIPAA про сервіс скорочення посилань#

HIPAA — Health Insurance Portability and Accountability Act, оновлений актом HITECH та правилом Omnibus 2013 року — регулює те, як Protected Health Information (PHI) обробляється охопленими суб'єктами (медичними закладами, страховими компаніями) та їхніми діловими партнерами (Business Associates).

Сервіс скорочення посилань стає Business Associate, коли коротке посилання або дані, що стоять за ним, містять PHI. Цікаве питання полягає в тому, чи стається це взагалі, і відповідь тут складніша, ніж зазвичай вважають під час перевірок.

Коли PHI проходить через редирект#

Саме по собі коротке посилання — наприклад, s.elido.me/abc123 — не є PHI. URL-адреса призначення, метадані робочого простору та теги кампаній також зазвичай не є PHI.

Питання PHI виникає у трьох конкретних випадках:

• URL-адреси призначення, що містять ідентифікатори: коротке посилання, що веде на https://provider.example/patient/12345/results, містить ідентифікатор пацієнта в шляху URL. Ця адреса зберігається скорочувачем і, отже, є PHI у строгому розумінні — навіть якщо ніхто в сервісі скорочення не інтерпретує цей ідентифікатор.
• Кастомні параметри, що додаються під час кліку: якщо редирект додає ідентифікатор сесії або користувача як параметр URL, і цей ідентифікатор згодом можна поєднати з PHI, подія кліку стає частиною ланцюжка PHI.
• Події кліку з даними реферера: подія кліку включає URL реферера. Якщо реферер містить ідентифікатор пацієнта (наприклад, сторінка порталу пацієнта, яка перенаправила користувача на скорочене посилання), поле реферера є PHI.

Більшість маркетингових кейсів у сфері охорони здоров'я не створюють PHI через ці канали. Відділ маркетингу медичної системи, що проводить кампанії щодо щеплень від грипу або загальних порад для здоров'я, створює редиректи без PHI в адресах призначення та реферерах. Для таких завдань BAA є лише запобіжним заходом, а не архітектурною необхідністю.

Для завдань, де маршрути ведуть до PHI — портали пацієнтів, посилання для підтвердження запису на прийом, URL-адреси для отримання результатів аналізів — BAA є обов'язковим, і в сервісі скорочення мають бути впроваджені архітектурні контролі, описані нижче.

Відповідність HIPAA Security Rule сервісу редиректів#

HIPAA Security Rule (45 CFR Part 164, Subpart C) приписує адміністративні, фізичні та технічні заходи захисту. Для сервісу редиректів, що працює з PHI в адресах призначення:

• Access controls (164.312(a)): унікальна ідентифікація користувачів, автоматичне завершення сеансу, шифрування ePHI під час передачі та зберігання. Elido забезпечує унікальні ідентифікатори користувачів через IdP, можливість налаштування таймауту сесії для кожного робочого простору, TLS 1.3 на всіх зовнішніх кінцевих точках та конвертне шифрування AES-256 для відповідних сховищ даних.
• Audit controls (164.312(b)): запис та аналіз активності в системах, що містять або використовують ePHI. Elido генерує аудит-логи для створення та зміни посилань, зміни адрес призначення та експорту аналітики у захищене сховище, що дозволяє лише додавання записів. Термін зберігання аудит-логів становить 24 місяці для планів Business+.
• Integrity controls (164.312(c)): захист ePHI від несанкціонованої зміни. URL-адреси призначення зберігаються з історією на рівні рядків; будь-яка зміна логується з ідентифікатором виконавця та міткою часу, а попереднє значення залишається в таблиці історії.
• Transmission security (164.312(e)): захист ePHI під час передачі через відкриті мережі. Використання TLS 1.3 на всіх точках редиректу; HSTS preload; можливість піннінгу сертифікатів для кастомних доменів.

Адміністративні та фізичні заходи захисту (навчання персоналу, політики санкцій, контроль доступу до приміщень) значною мірою перетинаються з контролями SOC 2 Security. Ті самі докази підтверджують обидва аудити, тому ми проводимо їх за спільним графіком збору доказів.

Що покриває і що не покриває BAA#

Business Associate Agreement — це договір згідно з HIPAA 164.504(e). Він зобов'язує ділового партнера дотримуватися конкретних заходів захисту, термінів сповіщення про витоки даних та зобов'язань щодо субпідрядників. Він не змінює базову архітектуру; він зобов'язує вендора використовувати цю архітектуру відповідно до вимог HIPAA.

Стандартний BAA від Elido, доступний на планах Business та Enterprise, охоплює:

• Чотири категорії заходів захисту HIPAA Security Rule, що застосовуються до всіх даних, які клієнт спрямовує через сервіс редиректів.
• Сповіщення про витік даних протягом 60 днів після виявлення, з детальними термінами реагування на інциденти, зазначеними в BAA та відповідному runbook /docs/runbooks/incident-response.
• Передачу зобов'язань субпідрядникам (Hetzner, OVH, Postmark, Cloudflare, monobank Plata) згідно з їхніми власними BAA, де це застосовно. Поточний список субпроцесорів доступний за адресою /legal/subprocessors і збігається зі списком для документації GDPR.
• Повернення або знищення PHI після розірвання контракту з 30-денним вікном для експорту даних клієнтом перед їх видаленням.

Чого BAA не робить: він не робить план, який не відповідає вимогам HIPAA, придатним для використання. Плани Free та Pro не передбачають підписання BAA. Інфраструктура однакова на всіх платних тарифах, але юридичні зобов'язання — ні.

Анкета закупівлі — відповіді, які можна скопіювати#

Більшість анкет безпеки містять однаковий набір запитань. Нижче наведено відповіді, які ми надаємо зазвичай, з посиланнями на артефакти.

Чи маєте ви актуальний звіт SOC 2 Type II? Ми маємо сертифікат ISO 27001; аудит SOC 2 Type II триває, звіт Type II очікується в четвертому кварталі 2026 року. Bridge letters та актуальний сертифікат ISO 27001 доступні за умов NDA на сторінці /trust. Звіт SOC 2 Type I був завершений у листопаді 2025 року і також доступний під NDA.

Чи підпишете ви наш BAA? Ми підписуємо наш стандартний BAA на планах Business та Enterprise. BAA на бланку клієнта розглядаються для планів Enterprise; ми приймаємо типові зміни (розширені вікна сповіщення про витоки, додаткові підтвердження заходів захисту, контроль субпідрядників за вибором клієнта). Зверніться до [email protected] для отримання стандартного тексту або початку розгляду вашого документа.

Де зберігаються дані? Клієнти з EU за замовчуванням використовують Frankfurt (Hetzner FRA1, регіон EU). Клієнти з US можуть обрати Ashburn (Hetzner ASH). Singapore (OVH SGP) доступний для клієнтів з APAC. Реплікація між регіонами підключається окремо для кожного робочого простору; без неї всі дані клієнта залишаються в обраному регіоні. Детальніше про це у статті про зберігання даних.

Яке шифрування використовується? TLS 1.3 для даних у дорозі на всіх зовнішніх точках (редирект, API, панель управління, аналітика). Конвертне шифрування AES-256 для основної бази Postgres, кластера ClickHouse та об'єктного сховища. Підтримка KMS клієнта доступна на планах Enterprise через інтеграцію BYO KMS.

Як надається та скасовується доступ? Single sign-on через SAML або OIDC за допомогою WorkOS; SCIM для управління життєвим циклом користувачів. Контроль доступу на основі ролей на рівні робочого простору з можливістю створення кастомних ролей на рівні Enterprise. Докладніше про це у статті про SCIM та SSO.

Який ваш процес реагування на інциденти? Задокументований runbook з SLA на першу відповідь 60 хвилин, SLA на технічне оновлення 24 години та чергуванням відповідальних за інциденти. Сповіщення про витоки відповідають термінам у нашому BAA та DPA. Повний список інструкцій знаходиться за адресою /docs/runbooks/.

Хто ваші субпроцесори? П'ять основних субпроцесорів: Hetzner (інфраструктура, EU), OVH (інфраструктура, APAC), Postmark (транзакційні листи), Cloudflare (захист від DDoS на публічних маркетингових ресурсах; не використовується в обробці даних редиректів), monobank Plata (білінг для клієнтів з EU). Повний список із контактними даними — на /legal/subprocessors.

Як довго ви зберігаєте дані клієнтів? Дані про кліки зберігаються протягом терміну дії контракту плюс 30 днів для експорту після розірвання, після чого видаляються. Конфігурація посилань зберігається протягом дії контракту плюс вікно для експорту. Агреговані метрики (кількість посилань на робочий простір, кількість кліків на день, без PII) зберігаються після закінчення контракту для білінгу та внутрішнього планування потужностей.

Файл з доказами, який хоче бачити аудитор#

Якщо ви є корпоративним клієнтом, що проходить власний аудит SOC 2, і Elido є вашим вендором, ваш аудитор, ймовірно, попросить докази згідно з контролями CC9.2 (управління вендорами) та CC1.4 (зобов'язання). Файл вендора має містити:

• Наш актуальний сертифікат ISO 27001 (оновлюється щорічно).
• Наш звіт SOC 2 Type I та bridge letter для SOC 2 Type II (доступні під NDA).
• Наші підписані DPA та BAA (якщо застосовно).
• Список субпроцесорів та дати останніх змін у ньому.
• Знімок нашої публічної сторінки безпеки /trust та актуальну версію політики приватності.
• Історію сповіщень про витоки (публічна історія порожня — внутрішній журнал надається для ознайомлення під час закупівлі за умов NDA).

Такий файл з доказами формується один раз для кожного клієнта і оновлюється щороку. Список вище є стандартним; додаткові запити аудиторів розглядаються індивідуально.

Що є справді складним#

Є дві речі, які дійсно складно реалізувати в рамках SOC 2 та HIPAA для сервісу редиректів, і ми згадуємо про них, бо вони часто виникають під час обговорення закупівлі.

Безперервний моніторинг для edge-вузлів (POP) — це непросте завдання. Система обробляє величезні обсяги трафіку в трьох регіонах, і аудитор хоче бачити докази того, що моніторинг працює постійно, а не лише вибірково. Наш поточний підхід використовує синтетичні редиректи в кожному регіоні щохвилини, а стан сповіщень фіксується в лозі, захищеному від змін. Вартість такого моніторингу значна, а його дизайн пройшов три ітерації, щоб досягти правильного співвідношення сигналу та шуму. Налаштування описано в посібнику з обсервабіліті, а технічне обґрунтування (ADR) — у /docs/adr/0024-sla-monitoring.md.

Терміни сповіщення про витоки HIPAA жорсткіші за GDPR. HIPAA вимагає сповіщення постраждалих осіб протягом 60 днів після виявлення; якщо витік стосується 500+ осіб, необхідні додаткові сповіщення до HHS та ЗМІ. GDPR дає 72 години на сповіщення наглядового органу, але термін сповіщення осіб — "без невиправданої затримки". У випадку витоку, що стосується кількох юрисдикцій, терміни HIPAA часто є домінуючими. Ми за замовчуванням дотримуємося термінів HIPAA для будь-яких інцидентів, що стосуються даних клієнтів, які проходять через вузли в US, і наш runbook реагування на інциденти відображає це.

Що ще почитати#

• GDPR для скорочувачів URL-адрес: що насправді хоче бачити ваш DPO — ключовий матеріал з теми комплаєнсу.
• Зберігання даних в EU для маркетингової аналітики — архітектура зберігання та варіанти піннінгу даних.
• Schrems II та ваші пікселі відстеження — контекст оцінки впливу передачі даних.
• SCIM та SSO для маркетингових інструментів — засоби контролю доступу, що відповідають CC6.1.
• Атрибуція кліків після Safari ITP — стаття про обмеження приватності на стороні браузера.
• Операційна частина: посібник із доказів SOC 2 у документації — як збір доказів відбувається на практиці.
• Продуктові сторінки: /solutions/compliance та /solutions/enterprise для порівняння тарифів та функцій.