Привет, Хабр!

Сразу важное: я не юрист. Я инженер, который пилит свой DNS-резолвер по ночам, и читал законы не от хорошей жизни, а потому что это мой бизнес, и мне надо было понять, что я могу обещать пользователю, а что нет. Всё, что ниже, моя интерпретация после чтения первоисточников, а не legal advice. Если вы строите бизнес или compliance-стратегию на этих выводах, наймите EU privacy lawyer. Они для того и есть.

Юр-формулировки писали юристы для юристов, и читать их примерно то же удовольствие, что разбирать почерк врача. Но в DNS-индустрии слишком много обещаний «мы privacy-first» и слишком мало конкретики о том, что провайдер физически может и физически обязан сделать в определённых сценариях. Разберём CLOUD Act, FISA 702, GDPR и Schrems II, и посмотрим, как эти штуки превращают «privacy» в маркетинговое слово или в реальную защиту.

Я делаю VantageDNS, recursive DNS с фильтрацией, инкорпорация в Финляндии. У меня skin in the game: я и сам должен понимать, что могу и что не могу. Без громких заявлений «у нас единственная безопасная DNS в мире». Мы один из EU-вариантов, и смысл статьи в том, чтобы объяснить, чем EU-варианты отличаются от US-вариантов.

Что такое CLOUD Act

Принят в США в 2018 году. Расшифровка любопытная: Clarifying Lawful Overseas Use of Data Act. Слово «clarifying» здесь эвфемизм, потому что закон не уточнил существующее положение, а расширил его.

Ключевая суть в одной фразе: американский провайдер обязан выдать данные по запросу US authorities, даже если данные физически находятся за пределами США. Юрисдикция тянется не за серверами, а за корпорацией. То есть если NextDNS (US-инкорпорация в Делавэре) хранит query log на сервере в Германии, эти данные всё равно подпадают под CLOUD Act. И «но у нас сервера в EU» здесь не аргумент.

Есть нюанс, который любят упоминать в маркетинге: CLOUD Act позволяет провайдеру оспорить запрос, если он конфликтует с foreign law (например, с GDPR). На бумаге обнадёживающе. На практике процедура редкая, дорогая, и у провайдера должны быть серьёзные юристы и желание судиться с US-government. Большинство комплаятся, потому что это дешевле и безопаснее для бизнеса. Публичных кейсов, где DNS-провайдер успешно оспорил CLOUD Act request на основании EU privacy law, я не видел. Если знаете такой — поделитесь в комментариях.

Что такое FISA Section 702

Если CLOUD Act про targeted requests с какими-то процедурами, то FISA 702 про массовый сбор. Foreign Intelligence Surveillance Court (FISC, «секретный суд» в просторечии) выдаёт авторизации на surveillance под общими параметрами, без публичного процесса. Targeting обязан быть «foreigner outside US», но collection часто incidental включает граждан США и не-targets. Это документировано Snowden disclosures и последующими отчётами PCLOB (Privacy and Civil Liberties Oversight Board); рекомендую почитать их публичные отчёты, они на удивление откровенные для government body.

Про DNS-резолверы FISA 702 явно не говорит, но прецедент применения к ISP, telecoms и cloud providers есть. DNS query log это metadata-золото: показывает, на какие домены человек ходил, когда, откуда. Если провайдер технически способен передать этот поток, и юридически обязан, и у него US-инкорпорация, формально ничто не мешает FISC выдать соответствующий directive.

Здесь обычно возражают: «но это для иностранцев, US-граждан не касается». Для аудитории Хабра большинство как раз и есть «foreigners outside US», прямая цель FISA 702. Если ваш DNS-резолвер сидит в США, всё ваше querystream формально иностранное для США, что бы вы там по гражданству ни были.

Что такое GDPR глазами провайдера

GDPR это огромный документ, и для провайдера данных самые рабочие статьи такие:

• Article 6 (lawful basis). Любая обработка персональных данных должна иметь правовое основание. Для DNS это обычно legitimate interest (мы должны резолвить запрос, чтобы оказать сервис) или contract (юзер подписался на платный план). Маркетинг под legitimate interest не лезет.

• Article 17 (right to erasure). Юзер может потребовать удалить свои данные, и провайдер обязан это сделать в разумный срок, обычно 30 дней. Если у вас retention policy «90 дней query log», и юзер запрашивает удаление на 10-й день, вы обязаны удалить, а не дождаться окончания retention.

• Article 32 (security). Encryption at rest, encryption in transit, контроль доступа, журналирование доступа: всё это требуется. Не «хорошо бы», а требуется.

• Article 33 (breach notification). 72 часа на нотификацию регулятора при breach. Не неделя, не месяц. 72 часа.

Главное для DNS: legitimate interest покрывает базовое функционирование (резолв запроса), но НЕ покрывает retention для marketing, profiling или продажи третьим лицам. И юзер имеет право узнать, что именно про него хранится, а также потребовать удаления.

GDPR не та штука, которую можно «применить частично». Если ты обрабатываешь данные EU-резидентов, ты весь под GDPR. Я их обожаю как обожают старого кота: они ворчливые, но честные, и от них есть конкретная польза.

Schrems II и трансферы EU↔US

В 2020 году CJEU (Court of Justice of the European Union) в деле Schrems II отменил EU-US Privacy Shield, механизм, по которому американские компании могли получать данные EU-граждан на основании self-certification. Аргумент CJEU: США не обеспечивают «equivalent level of protection» из-за FISA 702 и других surveillance-режимов.

С тех пор для трансфера данных из EU в US нужны Standard Contractual Clauses (SCC) плюс Transfer Impact Assessment (TIA), плюс «supplementary measures», обычно encryption, чтобы американский партнёр чисто технически не мог прочитать данные.

Тут начинается интересное. Если у DNS-провайдера US-parent или US-инкорпорация, он по определению обязан получать данные в US (для CLOUD Act compliance), и SCC alone недостаточны, чтобы это легализовать. Поэтому многие US-инкорпорированные «EU-friendly» сервисы технически в юридическом подвешенном состоянии: формально SCC подписаны, но Schrems II не выполнен. Регуляторы это знают, но точечный enforcement пока редкий, и индустрия живёт в этом сером режиме. Реальность, как водится, побила меня палкой по голове, когда я начал в этом разбираться.

В 2023 году появился EU-US Data Privacy Framework, попытка заменить Privacy Shield. Многие юристы (и Max Schrems лично) считают, что DPF не закрывает фундаментальные проблемы и его тоже отменят в третьей итерации.

Юрисдикции конкретных DNS-провайдеров

Это самое неприятное место в статье, потому что я неизбежно буду упрощать. У каждого из этих провайдеров своя сложная корпоративная структура, и одна табличка не передаёт нюансов. Тем не менее:

Несколько комментариев. Quad9 — швейцарский фонд, у них хорошая позиция, и Швейцария имеет EU adequacy decision, что упрощает трансферы. Control D канадский, и Канада в Five Eyes, что означает разведывательное сотрудничество с США (но не такое плотное, как US-инкорпорация). AdGuard — кипрская компания с командами в РФ и Армении, и кипрская часть формально EU, но я бы лично TIA по ним делал тщательнее, чем по Quad9. NextDNS и Cloudflare оба в Делавэре, и я их уважаю как инженерные продукты, но юридически они в той самой Schrems-серой зоне.

Я в этом списке не для саморекламы (точнее, не только для саморекламы), а потому что я выбрал юрисдикцию специально, и вся архитектура от этого пляшет.

Что в реальности значит «CLOUD Act risk» для юзера

Конкретные сценарии, чтобы было предметно.

Subpoena по уголовному делу. US-prosecutor хочет узнать, кто из провайдера X подписан на эндпойнт config_id=ABC123. Provider обязан выдать всё, что есть: email, биллинговый IP, query log за период, времена. Юзер не уведомляется, обычно есть gag order на срок расследования.

National Security Letter (NSL). FBI запрашивает данные плюс gag order, то есть запрет говорить кому-либо, что NSL получен. Provider не может даже warrant canary обновлять без формального нарушения gag, и поэтому warrant canaries юридически в серой зоне (но об этом ниже).

FISA bulk collection. Поток данных собирается для аналитики, без targeting в момент сбора. На таблицу запросов с US-DNS-провайдера это формально могло применяться: см. Snowden disclosures про upstream collection и про cooperation с tier-1 ISPs.

Ни один из этих сценариев не означает, что NextDNS прямо сейчас сливает ваш query log в АНБ. Большинство таких запросов targeted и редкие. Вопрос в том, что провайдер физически и юридически способен это сделать, если запрос придёт. А для privacy-критичных юзеров «не сделает на практике» сильно слабее, чем «не может архитектурно».

Что в реальности значит «EU jurisdiction»

Симметричный набор сценариев для EU-инкорпорированного провайдера. Если финский регулятор Liikenne- ja viestintävirasto (Traficom) или EU body хочет данные:

Уголовный запрос через MLA. Mutual Legal Assistance Treaty процесс медленный, требуется обоснование, требуется судебная санкция, и юзеру по EU-law уведомление обязательно (с задержкой, но не gag-forever, как в США). Для запросов от не-EU стран тот же MLA процесс через Минюст Финляндии, ещё медленнее.

GDPR-related запрос от Data Protection Authority. Обычно для проверки compliance, не для surveillance. Регулятор может потребовать показать, как у тебя организована обработка данных, какой retention, как реализован right to erasure. Это про аудит, не про выдачу пользовательских данных.

Российский или китайский запрос. Финляндия не выдаёт данные без MLA, а MLA с РФ заморожен с 2022 года. Так что для российских юзеров EU-jurisdiction, парадоксально, реальная защита от родного государства. Аналогично для китайских юзеров: с КНР MLA существует, но узкий, и DNS-данные через него не вытащить.

EU-jurisdiction не делает провайдера непробиваемым. Если финская полиция расследует CSAM или серьёзный терроризм с подходящей санкцией, данные вытащат. Но процедура медленная, прозрачная (post-factum) и узко-целевая, в отличие от bulk-collection.

Что не защищает EU jurisdiction

Прозрачность важнее манипуляций. Про границы:

• US-parent или US-investor с board control. CLOUD Act может применяться через corporate veil, если US-entity имеет «possession, custody, or control». Я single owner, в Финляндии, без US-investors. Это специально, и это написано в моих учредительных документах.

• US-cloud провайдер для storage. Если EU-инкорпорированный сервис хранит данные на AWS, GCP или Azure, это формально US-сервис в роли processor, и данные подпадают под CLOUD Act. Я на Hetzner (DE+FI) и на dedicated серверах в EU.

• Backups на US-S3 или US-CDN. То же самое. У меня backups на Hetzner Storage Box в EU, и логи стрятся в ClickHouse в Хельсинки, без US-CDN ни на каком слое.

• CDN перед сайтом. Тут компромисс частичный: статический лендинг через EU PoPs, но если завтра я подключу Cloudflare для DDoS-защиты, это надо будет честно задокументировать.

Privacy-архитектура это система с дырами, и важно не делать вид, что дыр нет. Полезнее их перечислить.

Warrant canary

Раз в неделю я подписываю PGP-ключом файл, в котором написано «за период такой-то NSL и аналогичных gag-секретных запросов не получал». Файл публикуется на vantagedns.com/canary. Если подпись перестаёт обновляться вовремя, юзер делает выводы.

Юридически warrant canary это серая зона. Суд может запретить мне обновлять подпись, но не может заставить меня подписать ложный канарик задним числом, это уже obstruction of justice. Так что отсутствие обновления это сигнал, не сильнее чем «что-то не так», но и не слабее. Mullvad, IVPN, Riseup делают так. Я тоже делаю. Не потому, что это серебряная пуля, а потому что это один из немногих доступных провайдеру способов сигнализировать о проблеме без прямого нарушения gag.

Важно: warrant canary имеет смысл только в юрисдикциях, где gag-orders бывают. В Финляндии gag-order на национальной basis это редкий и ограниченный по времени механизм, поэтому канарик у нас больше про защиту от потенциальных запросов из других стран, проходящих через MLA.

Чек-лист: что спрашивать у DNS-провайдера

Это, наверное, самая практичная часть статьи. Вне зависимости от того, выберете вы меня, NextDNS или ничего, вот вопросы, ответы на которые стоит получить до того, как доверять провайдеру свой query log:

1. В какой стране юр.лицо?

2. Кто бенефициарные владельцы и есть ли среди инвесторов US-entities?

3. Где физически находятся серверы, обрабатывающие query?

4. Где физически хранятся логи и backups?

5. Используется ли US-cloud (AWS/GCP/Azure) на любом слое?

6. Используется ли US-CDN перед публичными ресурсами провайдера?

7. Есть ли warrant canary, как часто обновляется, какой формат подписи?

8. Опубликован ли transparency report (сколько запросов от LE, в какой период)?

9. Open-source ли edge-софт провайдера?

10. Какой retention для query log, как enforce, можно ли в настройках поставить меньше?

11. Опубликована ли law enforcement response policy?

12. Какой процесс при right to erasure запросе, как быстро удаляют?

Если ответы на 1-6 это «США» или «не скажем», это не значит «провайдер плохой», это значит «у вас Schrems II риск, оцените сами, важен ли он вам». Для большинства домашних юзеров, которые блокируют рекламу, может быть, и не важен. Для журналиста, активиста, security-исследователя или просто параноика важен.

Если совсем коротко

Если упростить до одной формулы: privacy в DNS это произведение трёх множителей.

Privacy = jurisdiction × architecture × transparency.

Jurisdiction это где ты юридически. Architecture это где данные физически и через какие системы они идут. Transparency это что ты публично документируешь, и можно ли проверить твои утверждения.

Если хотя бы один из трёх близок к нулю, privacy фейковая, какие бы хорошие были остальные два. US-инкорпорация с EU-серверами и красивым лендингом про privacy это сильная архитектура и transparency при дырявой jurisdiction. EU-инкорпорация с US-cloud-бэкендом наоборот. EU-инкорпорация на dedicated серверах без публичных policies это третья версия той же проблемы.

Я стараюсь, чтобы у меня все три были выше нуля. Получается ли, судите сами по публичной документации, не по моему слову.

Ссылки

• vantagedns.com — продукт

• vantagedns.com/try — попробовать

• vantagedns.com/canary — warrant canary

• vantagedns.com/security — transparency policies, LE response policy

• vantagedns.com/press-kit — press kit

Если в комментариях есть юристы, которые увидят неточности, буду благодарен за поправки. Я инженер, который читает законы, а не наоборот, и ошибки в интерпретации тут нормальны. Главное их исправлять.