Перенос данных между облаками: критерии оценки рисков

Перенос данных между облачными хранилищами сопровождается расходами и рисками, которые часто не попадают в проектную смету: egress-трафик по тарифу публичного интернета, компрометация API-токенов посредника, рассогласование ACL между source и target, потеря пользовательских metadata и несовместимость lifecycle-политик. При объёмах в десятки терабайт исходящий трафик способен сформировать заметную статью бюджета, но его размер нужно считать по региону, типу маршрута, классу хранилища и условиям конкретного договора, а не по усреднённой цифре из презентации миграционного сервиса.

Риск переноса определяется не только тем, дошёл ли файл до нового bucket. Нужно понять, кто имел доступ к данным по дороге, какие права получил мигратор, где юридически обрабатываются сведения, какие атрибуты объекта пережили переход и можно ли доказать целостность после завершения job. Ниже — аудит процедуры по пяти измерениям, которые архитектурный комитет рассматривает до открытия миграционного окна.

Уязвимости сторонних миграторов и API-интеграций

Сторонние сервисы прямого переноса — CloudFuze, Rclone, Диск-О и аналогичные продукты — получают доступ к API обоих облачных провайдеров. Объём прав зависит от выбранного коннектора и сценария: для одних операций достаточно перечисления объектов и записи, для других потребуются чтение исходных данных, создание multipart upload, перенос тегов или работа с ACL. Проблема начинается там, где мигратор получает универсальную роль с правами чтения, записи, удаления и изменения политик на уровне всего bucket.

В таком случае компрометация посредника превращает его в единую точку входа сразу в два облака. Даже если source и target принадлежат разным провайдерам и защищены разными IAM-моделями, атакующему достаточно украсть один рабочий секрет или захватить агент миграции, чтобы получить доступ к большому объёму данных.

Передача API-токенов мигратору — это делегирование доступа к данным на ограниченный срок. Чем шире роль и дольше живёт секрет, тем меньше разница между временной интеграцией и постоянной учётной записью администратора.

Минимизация поверхности атаки строится не на одном параметре, а на последовательности ограничений.

• Разделить операции по этапам. На первичную загрузку нужны права на перечисление объектов и создание новых объектов в target. delete не следует выдавать заранее: удаление старых объектов выполняется после сверки и отдельного согласования. Если необходимо читать source, это право также ограничивают конкретным bucket, префиксом или набором объектов.
• Использовать короткоживущие credentials. TTL в один час может быть подходящим ориентиром для отдельного job, но не универсальным нормативом. Срок выбирают так, чтобы он покрывал реальную длительность операции с небольшим запасом и позволял автоматически выпускать новый токен. В AWS для этого применяют временные роли через STS, в других средах — соответствующие OAuth2-механизмы или сервисы управления секретами.
• Разнести полномочия. Учётная запись, которая копирует объекты, не должна одновременно менять bucket policy, включать публичный доступ или отключать защиту от удаления. Для подготовки, копирования, сверки и очистки лучше использовать разные роли.
• Отзывать доступ по фактическому завершению. После окончания job секрет отзывают через API или переводят роль в неактивное состояние, а событие сохраняют в audit log. Формулировка «отозвать после завершения» должна означать конкретную автоматизированную операцию, а не задачу в календаре.
• Рассмотреть локальный агент. Rclone, aws s3 sync, gsutil rsync и аналогичные инструменты можно запускать на собственной инфраструктуре. Это не делает процесс автоматически безопасным: ключи всё равно могут попасть на диск, в переменные окружения или логи. Но компания контролирует хост, сетевой маршрут, обновления и журналирование, не добавляя отдельного SaaS-посредника.

Типовая ошибка — использование long-lived service account key в формате JSON вместо временного механизма выдачи полномочий. Долгоживущий ключ может сохраниться в файловой системе агента, артефактах CI/CD-пайплайна, резервных копиях или диагностических логах. Ротация после завершения миграции не устраняет риск, если копии уже разошлись по нескольким системам.

Отдельно проверяют observability-слой. Токен способен попасть в Loki, CloudWatch, SIEM или систему трассировки через URL запроса, сообщение об ошибке, переменную окружения либо отладочный вывод SDK. Маскирование нужно включать на источнике, а не рассчитывать, что секрет будет удалён уже после поступления в централизованный журнал. Логи мигратора должны содержать идентификатор операции, объект, время и результат, но не содержимое credentials и не чувствительные фрагменты пути, если по ним можно восстановить структуру защищаемого набора данных.

До запуска стоит сделать пробный перенос на отдельный префикс. Он показывает не только скорость, но и фактический набор разрешений: может ли агент читать metadata, создавать multipart upload, работать с объектами, зашифрованными ключом клиента, и корректно завершать незакрытые части загрузки после сбоя. Ошибка в scope, обнаруженная на пилоте, дешевле ошибки в середине миграции, когда приходится временно расширять роль без полноценного согласования.

Модель общей ответственности и правовые барьеры юрисдикций

Shared Responsibility Model фиксирует техническую границу ответственности, но не заменяет договор и правовой анализ. Провайдер обычно отвечает за физическую инфраструктуру, базовую сеть и управляемые компоненты своей платформы. Клиент отвечает за конфигурацию IAM, выбор региона, права доступа, политику хранения, клиентское шифрование и то, какие данные он вообще помещает в сервис.

У миграции есть несколько независимых юрисдикционных слоёв. Значение имеют страна и регион размещения данных, место обработки и поддержки, инкорпорация провайдера, применимое право к заказчику, категории субъектов данных и содержание договора. Поэтому утверждать, что доступ государственных органов определяется только правом страны размещения storage-нод, нельзя. Возможны одновременно требования страны заказчика, режима защиты субъектов данных, законодательства самого провайдера и договорных обязательств перед клиентом.

Шифрование снижает риск раскрытия содержимого, но не отменяет обязанности определить правовое основание передачи. Кроме того, у провайдера или подрядчика могут оставаться метаданные, журналы, сведения об аккаунте, ключи, резервные копии и техническая возможность администрирования. Проверка должна охватывать не только основной bucket, но и цепочку обработки.

Что меняется в разных правовых режимах

152-ФЗ. Для персональных данных граждан РФ первичная запись и систематизация при сборе регулируются требованиями о локализации баз данных. Это не означает, что любое последующее перемещение данных в зарубежный регион автоматически запрещено или что для каждого случая требуется размещать все серверы исключительно в России. Трансграничная передача оценивается отдельно: учитываются категории данных, роль оператора, выбранное иностранное государство, уведомительные и организационные обязанности, а также требования к защите данных.

Перед запуском нужно установить, где находится база, в которую данные собираются первоначально, что именно переносится за границу, на каком основании и какие меры защиты применяются. Для конкретного сценария юридическая служба должна проверить актуальные требования статьи 12 и связанные с ней обязанности, а также внутренние документы оператора. Размер ответственности нельзя надёжно свести к одной универсальной сумме: он зависит от состава нарушения, статуса организации, обстоятельств дела и действующей редакции законодательства. Поэтому цифру из старой презентации или статьи нельзя использовать как самостоятельное основание для расчёта риска.

GDPR. Контролёр обычно заключает соглашение с основным процессором. Отдельный DPA непосредственно с каждым sub-processor контролёр, как правило, не подписывает: основной процессор обязан привлечь субпроцессоров на регулируемых условиях, обеспечить необходимые гарантии и предоставить контролёру информацию для авторизации и контроля. В договоре и документах провайдера проверяют перечень субпроцессоров, процедуру предварительного или общего разрешения, уведомление об изменениях и возможность возражения.

Передача данных за пределы EEA требует подходящего механизма трансфера и оценки условий в конкретной стране и цепочке поставщиков. Standard Contractual Clauses могут быть частью решения, но сами по себе не отменяют необходимость проверить фактические риски доступа и дополнительные меры. После решений Schrems II нельзя механически считать наличие SCC достаточной гарантией без анализа обстоятельств передачи.

HIPAA. Если в наборе есть Protected Health Information, передача провайдеру должна соответствовать требованиям HIPAA и договорной модели Business Associate Agreement, когда провайдер выступает business associate. Шифрование и IAM полезны, но не заменяют BAA, проверку функций сервиса и ограничение доступа сотрудников и подрядчиков. Важны также журналы, процедуры реагирования и порядок возврата или удаления данных.

Согласование фиксируют отдельным тикетом юридической и, при необходимости, службы информационной безопасности. В нём должны быть не общие слова о «соответствии», а конкретные ответы:

• какие категории данных входят в миграционный набор;
• где расположены source, временные буферы, target, резервные копии и журналы;
• кто является контролёром, процессором или оператором на каждом участке;
• действует ли DPA с основным провайдером и покрывает ли он нужные сервисы;
• опубликован ли перечень sub-processors и предусмотрена ли процедура его изменения;
• какой механизм трансграничной передачи выбран и какие дополнительные меры применяются;
• нужно ли обновить реестр операций обработки, уведомления и внутренние политики.

Регион в консоли аккаунта — только одна часть доказательства. Его сопоставляют с условиями тарифа, договором, документацией по резервированию и фактическими настройками сервиса. У некоторых управляемых функций данные, журналы или служебные копии могут обрабатываться не там, где находится основной bucket. Если это критично, проверяют именно архитектуру выбранной услуги, а не только название региона.

Технические риски: от сетевых задержек до скрытых egress-платежей

Кросс-облачная миграция отличается от переезда внутри одного провайдера. Канал между разными вендорами может идти через публичный интернет, выделенный канал или прямое сетевое соединение. У каждого варианта свои ограничения, SLA и тарифы. Даже прямой peering не означает автоматически нулевую стоимость: отдельно могут тарифицироваться исходящий трафик, межрегиональная передача, запросы к объектам и работа промежуточного сервиса.

Узкие места нужно измерять как минимум на четырёх участках.

• Latency. Для дальних маршрутов задержка увеличивает время подтверждения и снижает эффективность последовательных запросов. Трансатлантический маршрут между AWS S3 и Google Cloud Storage может давать RTT порядка 80–250 мс, но конкретный показатель зависит от региона, точки выхода, маршрутизации и загрузки канала. Поэтому на больших объёмах важнее не средняя задержка одного запроса, а размер очереди, число параллельных workers и поведение при повторной передаче.
• Bandwidth. Лимит может находиться у source, target, агента, NAT-шлюза или самого миграционного сервиса. Теоретическая оценка для 50 ТБ при канале около 1 Гбит/с даёт несколько суток чистой передачи. Ретраи, контрольные чтения, multipart-операции, паузы и неполная загрузка канала увеличивают календарный срок. Планировать окно нужно по измерению на тестовом наборе, а не по делению объёма на номинальную скорость.
• Egress fee. Исходящий трафик из source обычно считается отдельно от операций чтения и запросов. При ориентировочном тарифе $0.08–0.12 за гигабайт 50 ТБ дают порядок нескольких тысяч долларов — примерно $4–6 тыс. при принятой в расчёте десятичной единице объёма, до поправок на бесплатные лимиты, регион, договор и дополнительные операции. Это может быть значительной суммой, но не «десятками тысяч» только за указанное количество данных и такой диапазон тарифа.
• Schema drift. S3, Azure Blob и Cloud Storage по-разному трактуют object metadata, lifecycle-политики, storage class, версии и object lock. Прямой rclone sync без проверки нужных параметров способен перенести содержимое, но потерять пользовательские теги, изменить даты или не воспроизвести поведение автоматического удаления. S3 Standard не превращается автоматически в Nearline на стороне приёмника: класс хранения и правила lifecycle задаются отдельно.

Ориентировочная таблица полезна только как начало расчёта. Она не заменяет прайс-лист и калькулятор конкретного аккаунта.

Значения зависят от региона, направления, класса хранения, типа аккаунта, contract tier, committed use и текущих коммерческих условий. Для Google Cloud Storage не следует переносить в эту таблицу понятие sustained use discount из Compute Engine: это другая модель скидок и другой продукт. Финальная смета должна строиться в актуальном Pricing Calculator и подтверждаться условиями конкретного договора.

В расчёт включают не только размер исходных объектов:

• повторные передачи после сетевых ошибок;
• временные копии и staging;
• запросы LIST, GET, PUT и операции multipart upload;
• чтение metadata и контрольные чтения после записи;
• стоимость NAT, private endpoint, inter-region transfer и промежуточного bucket;
• хранение source в период read-only;
• лицензирование мигратора и работу выделенных агентов.

Снижать egress можно параллельной передачей из нескольких workers, размещённых ближе к source, сжатие применяют к тем форматам, где оно не ломает дедупликацию и последующее использование. Промежуточный регион выбирают не по одному тарифу за гигабайт: дополнительный маршрут может добавить ещё один платный участок, задержку и новый юридический периметр. Поэтому сценарий «перенести через дешёвый регион» сначала считают целиком, включая оба направления.

Для объёмов свыше 100 ТБ иногда рассматривают Snowball, Data Box или Transfer Appliance при наличии on-prem staging. Но физический носитель не отменяет шифрование, контроль цепочки хранения, сроки доставки и расходы на подготовку. Сравнивают не только egress × объём, но и логистику, аренду устройства, загрузку, возврат, страхование, время простоя и стоимость локального хранилища.

Стратегии защиты данных: шифрование и контроль доступа

Клиентское шифрование уменьшает последствия компрометации мигратора и доступа к дискам провайдера, но не решает все задачи сразу. Оно защищает содержимое только при условии, что ключи не ушли вместе с данными и что приложение умеет работать с зашифрованным форматом. Имена объектов, размеры, временные метки, структура каталогов и журналы могут оставаться видимыми. Кроме того, юридические требования к трансферу не исчезают из-за применения AES.

Для переносимых архивов применяют несколько подходов.

• Cryptomator — файловый vault, который позволяет зашифровать данные до загрузки в облачное хранилище. Мигратор видит набор зашифрованных объектов и не обязан понимать внутренний формат. Параметры шифрования, формат vault и механизм вывода ключевого материала зависят от версии формата и реализации; их нельзя описывать одной универсальной формулой вроде «ключ выводится из пароля по Argon2». Перед эксплуатацией фиксируют версию Cryptomator, формат vault и процедуру восстановления, а не только название алгоритма.
• VeraCrypt — контейнер или зашифрованный том, который монтируется на агенте до запуска копирования. Подход удобен для архивов с единым набором политик, но требует контролировать доступ к смонтированному тому, свободное место под служебные операции и корректное завершение работы после сбоя.
• rclone crypt — обёртка над удалённым хранилищем, шифрующая файлы и имена на лету. Это удобно для поточного переноса, однако формат тесно связан с конфигурацией rclone. До удаления source нужно сохранить совместимый конфиг, пароль и процедуру расшифровки; иначе данные физически будут находиться в target, но операционно окажутся недоступны.

При выборе схемы отдельно решают, требуется ли шифровать имена файлов, сохранять возможность серверного поиска и поддерживать случайный доступ. Предварительное шифрование делает объект непрозрачным для штатных средств классификации, антивирусной проверки, DLP и дедупликации провайдера. Для части систем это приемлемая цена, для других — функциональный запрет.

Конфигурация защиты на миграционном окне включает несколько независимых уровней:

• чувствительные каталоги шифруются до upload либо передаются через потоковую криптографическую обёртку;
• TLS используется на всех участках, а сертификаты и параметры клиента проверяются по журналам и настройкам агента;
• ключи и пароли хранятся в HSM, внешнем KMS или другом контролируемом хранилище, а не в том же аккаунте, куда загружаются объекты;
• резервная копия конфигурации ключей хранится отдельно и проходит тест восстановления;
• доступ к plaintext на агенте ограничен операционной ролью и временем работы job.

SSE-S3 и SSE-KMS не нужно автоматически отключать для предзашифрованных объектов. Серверное шифрование может оставаться дополнительным слоем защиты от компрометации самого storage и ошибок конфигурации. Его отключение оправдано только после оценки стоимости операций, требований к управлению ключами и модели угроз. Двойное шифрование не даёт универсального выигрыша, но и не является по определению бесполезным: решение принимают для конкретного набора данных и способа доступа.

На стороне target применяют deny-by-default. Сервисная роль получает доступ к конкретным bucket и префиксам, а не ко всему аккаунту. Для cross-account-сценариев используют assume role с external ID или эквивалентный механизм, исключают wildcard в чувствительных действиях и блокируют public access на уровне bucket и аккаунта. Приёмник должен однозначно определять владельца загружаемых объектов; в S3 для этого используют режим Bucket owner enforced, если он совместим с выбранным способом загрузки.

Object Lock и retention могут защитить от преждевременного удаления, но требуют проверки совместимости с перезаписью, версиями и процедурой очистки. Нельзя включать их формально, не понимая, кто и когда сможет удалить объект после окончания удержания. На период миграции полезно запретить cleanup-скриптам работу с target и вынести финальное удаление в отдельный change request.

Протоколы сверки целостности после завершения миграции

Завершение job в консоли мигратора — только технический сигнал. Оно показывает, что заданный процесс дошёл до состояния «завершён», но не доказывает совпадение набора данных, metadata, прав и прикладной доступности. Исходные объекты нельзя удалять до отдельного reconcile-этапа.

Проверка проходит в несколько слоёв.

1. Количество и объём. На source и target получают полный список объектов через paginated API и сравнивают количество, суммарный размер, префиксы и версии, если versioning используется. Расхождение не всегда означает потерю: причиной может быть фильтр, незавершённый multipart upload, исключённый временный файл или разная модель представления каталогов. Но до объяснения дельты процесс остановлен.

2. Контрольные суммы. Для каждого объекта сравнивают доступный hash, checksum или ETag с учётом особенностей multipart upload. ETag не всегда является обычным MD5 и не должен восприниматься как универсальное доказательство целостности. Для крупных составных объектов надёжнее использовать явно выбранный алгоритм контрольной суммы и сохранять его результат в отчёте. Rclone check, aws s3api head-object и gsutil hash помогают собрать данные, но итоговая методика должна учитывать формат и способ загрузки.

3. Metadata и теги. Отдельно сверяют custom metadata, пользовательские теги, content type, cache-control, ACL, версии, retention и object lock. Флаг --metadata в миграторе не гарантирует семантическое совпадение между разными облаками: одинаковое имя поля может означать разные свойства, а часть атрибутов вообще не имеет прямого аналога.

4. Доступ приложения. Выборку объектов читают не только через мигратор, но и через приложение-потребитель. Это проверяет IAM, сетевые разрешения, формат имён, работу ключей и фактическую доступность данных. Доля выборки определяется объёмом и критичностью набора; диапазон 0,5–1% можно использовать как рабочий ориентир для крупного массива, но для небольших или особо чувствительных наборов разумнее проверить все объекты либо заранее выделенный критичный перечень.

5. Повторяемость отчёта. Результат сверки сохраняют с идентификатором запуска, временем, версиями инструмента, параметрами фильтра и списком исключений. Отчёт без исходных параметров трудно использовать при разборе инцидента: через месяц будет непонятно, сравнивались ли версии, незавершённые загрузки и служебные префиксы.

Миграция без сверки — это резервная копия с неизвестной консистентностью. Пока source доступен только для чтения, аномалию ещё можно исправить; после удаления исходного набора ошибка становится отдельным инцидентом восстановления.

После успешного reconcile source переводят в read-only на срок, установленный политикой компании и критичностью данных. Период в 7–14 дней может быть разумным для части систем, но не является универсальным правилом: его сопоставляют с циклом обнаружения ошибок, требованиями бизнеса и стоимостью хранения. В этот период отслеживают обращения пользователей, расхождения в приложениях и фоновые процессы, которые могли продолжать писать в старое хранилище.

Окончательное удаление выполняют по отдельному change request. В нём фиксируют подтверждение владельца данных, результат сверки, наличие резервной копии, срок хранения журналов и процедуру восстановления. Для версионируемых bucket проверяют не только текущие объекты, но и старые версии и delete markers: удаление видимого файла не обязательно означает освобождение всего объёма и прекращение доступа к прежней версии.

Финальный аудит

Оценка рисков переноса между облаками складывается из пяти измерений: периметр посредника и API-токенов, применимое право и договоры обработки, сетевая экономика egress, клиентское шифрование и контроль доступа, а также доказуемая целостность после миграции. Они связаны между собой, но не заменяют друг друга. Хорошо настроенный IAM не исправляет ошибку локализации, а корректный DPA не доказывает, что в target попали все версии объектов.

Перед закрытием миграционного окна должны быть зафиксированы следующие решения:

• scope ролей мигратора ограничен нужными операциями и префиксами, срок действия credentials обоснован, отзыв подтверждён в audit log;
• описаны source, target, временные буферы, резервные копии и служебные логи, включая их регионы и возможных sub-processors;
• юридическая служба подтвердила применимость требований к локализации, трансграничной передаче, DPA и уведомлениям;
• egress-калькуляция учитывает тариф источника, регион, тип маршрута, запросы, повторы, промежуточное хранение и срок read-only;
• выбранная схема шифрования документирована вместе с версией инструмента, форматом vault или конфигурацией rclone crypt и процедурой восстановления ключей;
• target закрыт от публичного доступа, сервисные роли ограничены, владельцы объектов и правила retention проверены;
• reconcile содержит сравнение количества, размера, контрольных сумм, metadata и прикладного чтения;
• source переведён в read-only, а окончательное удаление отделено от успешного завершения job и оформлено отдельным изменением.

Перенос данных между облачными хранилищами становится управляемым не тогда, когда выбран самый быстрый инструмент, а когда у каждой операции есть ограниченный доступ, у каждой суммы — проверяемый расчёт, у каждого юридического вывода — конкретное основание, а у результата — воспроизводимый протокол сверки. Мигратор сокращает объём ручной работы, но не принимает за компанию решения о юрисдикции, ключах и допустимой потере metadata. Именно эти решения определяют, станет ли перенос штатной операцией или инцидентом с отложенным обнаружением.