Резидентность данных (Data Residency)

Резидентность данных относится к тому, где физически хранятся и обрабатываются данные клиента SaaS — дата-центры какой именно страны или региона фактически содержат эти байты, — и всё чаще это жёсткое договорное или регуляторное требование, а не приятное дополнение, обусловленное такими законами, как GDPR (который ограничивает передачу персональных данных ЕС за пределы ЕС/ЕЭЗ без определённых гарантий), а также правилами закупок в государственном секторе, здравоохранении и финансовом секторе, требующими, чтобы определённые данные вообще никогда не покидали конкретную юрисдикцию. Резидентность данных отличается, хотя и связана, от суверенитета данных (более широкого принципа, согласно которому данные подчиняются законам страны, в которой они хранятся, независимо от национальности владельца данных) и от локализации данных (более строгого, абсолютного правового мандата в некоторых странах — прежде всего в России и Китае, — требующего хранения определённых категорий данных исключительно в пределах национальных границ без исключений). Для SaaS-разработчиков, обслуживающих международных, регулируемых или государственных клиентов, резидентность данных — это не просто юридическая галочка, а инфраструктурное решение с реальной инженерной стоимостью: поддержка опции резидентства в ЕС обычно означает развёртывание полностью отдельного приложения и базы данных в облачном регионе ЕС (а не просто edge-кэш CDN), маршрутизацию регистраций клиентов из ЕС именно в этот регион и обеспечение того, чтобы резервные копии, логи и даже вложения в тикетах поддержки, содержащие данные клиентов, также оставались в закреплённом регионе — гораздо более серьёзная задача, чем кажется на первый взгляд, которую легко упустить, пока проверка безопасности при заключении корпоративного контракта специально не спросит: «а данные тикетов поддержки тоже остаются в регионе?» Облачные провайдеры (AWS, GCP, Azure) технически делают мультирегиональное развёртывание возможным, но SaaS-поставщику всё равно приходится проектировать архитектуру для подлинной изоляции данных по регионам, а не для единой глобальной базы данных с региональными репликами для чтения, поскольку в последнем случае основная копия данных обычно всё равно находится в одном регионе независимо от того, откуда обслуживаются чтения. Конкретный пример: SaaS-компания, продающая государственным клиентам в ЕС, разворачивает полностью изолированную инфраструктуру в регионе Франкфурт (eu-central-1) AWS — отдельный экземпляр Postgres, отдельные бакеты S3 для загрузки файлов, отдельный конвейер логирования — и направляет любого клиента, выбравшего «резидентность данных в ЕС» при регистрации, исключительно в этот стек, с внутренней защитой (ограничение базы данных плюс проверка CI), которая активно предотвращает запись данных любого клиента с резидентностью в ЕС в базу данных компании по умолчанию в регионе США, даже случайно. Команды продаж и ценообразования также должны быть вовлечены в планирование резидентности данных на раннем этапе, поскольку региональные развёртывания несут реальные постоянные инфраструктурные расходы (второй полноценный производственный стек, дублированная наблюдаемость, региональное дежурство) — многие SaaS-поставщики оценивают резидентность данных в ЕС/регионе как отдельный премиальный уровень именно для того, чтобы компенсировать эти расходы, а не предполагать, что каждого клиента можно обслуживать одинаково независимо от того, в каком регионе его данные должны находиться по закону.