Условия хранения персональных данных в облаке: сравнение безопасности популярных сервисов

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

Условия хранения персональных данных в облаке сравнивать только по числу гигабайт и цене тарифа бессмысленно. У сервиса может быть двухфакторная аутентификация, AES-256 и удобное мобильное приложение — но данные при этом будут размещены в другой юрисдикции. Или наоборот: облако будет соответствовать требованиям локализации, но не обеспечит модель zero-knowledge, при которой даже оператор не читает содержимое файлов.

Для личного архива и для рабочей базы с ФИО, телефонами, сканами документов действуют разные уровни риска. Смешивать их не стоит.

Локализация: где начинается юридическая граница

Федеральные законы № 152-ФЗ и № 242-ФЗ требуют, чтобы базы данных с персональными данными граждан России при их сборе находились на территории РФ. Норма относится к операторам персональных данных: компаниям, ИП, организациям, которые собирают, систематизируют и хранят сведения о людях.

Практический смысл простой. Интернет-магазин, управляющая компания, фитнес-клуб, клиника, ТСЖ, локальный сервис доставки или городской кружок с онлайн-записью не могут по умолчанию собирать анкеты клиентов сразу в зарубежное облако. Первичная запись должна попасть в базу, размещённую в России.

Под персональными данными в этой логике понимаются не только паспортные сканы. В типовой городской организации этот массив обычно выглядит так:

• ФИО, номера телефонов, адреса электронной почты;
• адреса квартир и сведения о собственниках;
• заявки в диспетчерскую службу, фото неисправностей, записи камер домофона;
• данные сотрудников: договоры, табели, банковские реквизиты;
• анкеты посетителей, участников мероприятий, клиентов салонов и секций;
• документы с сочетанием имени, подписи, номера договора, адреса или иной идентифицирующей информации.

Отдельная проблема — привычка вести рабочие процессы в общей папке Google Drive или OneDrive. Она удобна: доступ выдаётся за минуту, документы редактируются одновременно, интерфейс знаком сотрудникам. Но удобство не отменяет вопроса о физическом местонахождении базы.

Яндекс Диск и Облако Mail.ru заявляют хранение данных в российских дата-центрах. Для оператора персональных данных это снимает базовое противоречие с требованием локализации. Google Drive и Microsoft OneDrive для первичного сбора и хранения ПДн российских граждан такой гарантии не дают: их инфраструктура находится вне российской юрисдикции.

Это не означает, что частному человеку запрещено держать личные фотографии, заметки или собственные документы в Google Drive. Закон регулирует деятельность операторов ПДн, а не бытовой выбор каждого пользователя. Но если частный аккаунт превращён в рабочий архив с клиентскими анкетами, граница между «личным» и «операторским» использованием исчезает быстро.

Локализация — не характеристика интерфейса. Это место, где лежит первая база с данными граждан и где на неё распространяется право.

Санкции показывают, что вопрос перестал быть теоретическим. По статье 13.11 КоАП РФ за нарушение требования о локализации предусмотрены штрафы до 6 млн рублей при первом нарушении и до 18 млн — при повторном. В ноябре 2023 года Google был оштрафован на 15 млн рублей за повторный отказ локализовать данные российских пользователей.

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

Шифрование: AES-256 не равно недоступность файлов провайдеру

В рекламных описаниях облаков слово «шифрование» встречается почти всегда. С технической точки зрения оно может означать две принципиально разные модели.

Первая — шифрование канала и серверного хранилища. Файл передаётся по защищённому соединению TLS, затем хранится на серверах в зашифрованном виде, например с применением AES-256. Это нормальный, распространённый базовый уровень. Он снижает риск перехвата данных в сети и защищает накопители дата-центра от простого физического извлечения информации.

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

Вторая модель — сквозное клиентское шифрование, или zero-knowledge. Файл шифруется ещё на устройстве пользователя. В облако уходит уже зашифрованный массив. Ключ остаётся у владельца аккаунта, а сервис не может прочитать содержимое файла, поскольку не располагает средствами расшифровки.

Proton Drive и MEGA используют именно этот подход для защищённого хранения. Для личного архива с копиями документов, медицинскими выписками, финансовыми файлами или закрытой перепиской это заметное преимущество.

Сравнение выглядит так:

У zero-knowledge есть цена. Потерянный пароль или ключ нельзя просто «сбросить через поддержку» без риска потерять доступ к зашифрованному архиву. Совместная работа, поиск по содержимому, автоматическая обработка файлов могут быть ограничены или реализованы менее удобно. Это не недостаток конкретного бренда, а следствие архитектуры: сервис не может полноценно работать с тем, чего не видит.

Серверное шифрование не следует объявлять ненадёжным. AES-256 и TLS — устойчивые отраслевые стандарты. Вопрос другой: от какого именно риска требуется защита.

• От перехвата трафика в публичной сети защищают TLS и HTTPS.
• От кражи накопителя из дата-центра защищает шифрование данных на сервере.
• От захвата аккаунта защищают пароль, двухфакторная аутентификация и контроль сессий.
• От доступа самого облачного провайдера к содержимому защищает только клиентское шифрование с ключом у пользователя.
• От ошибочной отправки ссылки не спасает ни один алгоритм: файл уже открыт тому, кому выдали права.

Именно поэтому сравнение облачных хранилищ по безопасности нельзя сводить к одной строке «есть шифрование». У всех крупных сервисов есть защита передачи данных. Не у всех одинаковая модель управления ключами.

Зарубежное облако: риск не один, а три

При обсуждении Google Drive и OneDrive обычно смешивают три независимых фактора: локализацию, приватность и операционную устойчивость. Их нужно разделять.

Первый фактор — соответствие российскому законодательству для операторов ПДн. Если компания собирает сведения о гражданах России, первичная база должна быть локализована в РФ. Зарубежный сервис в роли основной базы для этой задачи создаёт правовой риск. Он не исчезает от того, что документы в папке зашифрованы или доступ к ней закрыт паролем.

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

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

Зарубежные сервисы не становятся автоматически «опасными». Они остаются сильными инструментами для международных команд, личных задач, работы с внешними контрагентами и документов, в которых нет регулируемого массива ПДн российских граждан. Ошибка начинается там, где общий инструмент без классификации данных превращают в корпоративное хранилище всего подряд.

Политика конфиденциальности облачных сервисов в такой ситуации должна читаться не как формальность. В ней следует искать четыре конкретные вещи:

1. Регион хранения и обработки. Формулировка «данные могут обрабатываться в разных странах» для оператора ПДн не решает задачу локализации.

2. Порядок передачи третьим лицам. Речь не только о рекламе, но и о подрядчиках, субпроцессорах, технической поддержке.

3. Механизм удаления данных. Удаление файла из интерфейса и фактическое удаление из резервных копий могут происходить не одновременно.

4. Условия восстановления доступа. Чем проще провайдер восстанавливает аккаунт, тем выше значение проверки личности и тем осторожнее нужно относиться к почте и номеру телефона, привязанным к облаку.

Облако безопасно ровно настолько, насколько безопасны права доступа, ключи и резервная копия. Название сервиса в этой формуле занимает не первое место.

Российские платформы: защита есть, но модель доступа нужно настраивать

Яндекс Диск и Облако Mail.ru рационально рассматривать как рабочий слой для российских организаций, которым требуется локальное размещение данных. Они снимают вопрос первичной локализации, дают привычную синхронизацию, общие папки и доступ с мобильных устройств.

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

У Облака Mail.ru в мобильном приложении предусмотрены дополнительные защитные механизмы: PIN-код, вход через Face ID или Touch ID, блокировка приложения при переворачивании смартфона экраном вниз, автоматический выход после трёх неверных попыток ввода PIN-кода. Это полезные меры против бытового сценария — потерянного или оставленного без присмотра телефона.

Но биометрия в приложении не защищает сам аккаунт, если доступ к основной почте уже скомпрометирован. Цепочка всегда длиннее одного экрана:

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

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

У этого подхода есть ограничения. Онлайн-просмотр, полнотекстовый поиск и совместное редактирование внутри зашифрованного контейнера становятся неудобными или невозможными. Поэтому разделение данных обычно эффективнее тотального шифрования всего массива.

Рабочая схема может быть трёхуровневой:

• в локализованном облаке — документы, с которыми команда должна работать ежедневно;
• в отдельном зашифрованном архиве — сканы паспортов, финансовые документы, резервные выгрузки и иные чувствительные массивы;
• на независимом носителе или втором хранилище — резервная копия критичных файлов.

Это не избыточность. Это минимальная защита от одновременной ошибки сотрудника, сбоя учётной записи и случайного удаления.

Удобство против приватности: где проходит рабочий компромисс

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

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

Практический выбор можно свести к нескольким сценариям.

Личный пользователь хранит документы и фотографии

Если в облаке лежат фотографии, бытовые файлы, копии квитанций и отдельные документы, первым уровнем остаётся защита аккаунта: уникальный пароль, 2FA, проверка активных сессий. Российское или зарубежное облако выбирается по удобству, доступности и уровню доверия к юрисдикции.

Для паспортных сканов, медицинских данных, налоговых документов и архивов с финансовой информацией разумнее использовать отдельную зашифрованную папку или сервис с zero-knowledge. Не нужно превращать весь цифровой быт в криптографический проект. Достаточно отделить небольшой массив действительно чувствительных данных.

Малый бизнес собирает контакты клиентов

Здесь выбор уже не бытовой. CRM-выгрузки, анкеты, заявки, договоры и таблицы с телефонами должны первоначально храниться в инфраструктуре на территории России. Российское облако может быть частью такой схемы, но само по себе не заменяет настройку доступа и внутренний порядок работы с ПДн.

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

Команда работает с международными контрагентами

Здесь может понадобиться зарубежное облако из-за офисной экосистемы, совместного редактирования или требований партнёра. Но в него не следует автоматически переносить всю российскую клиентскую базу. Рабочий контур лучше разделять: документы без ПДн — в международный сервис, массивы с данными граждан РФ — в локализованную систему.

Такое разделение кажется неудобным первые две недели. Потом оно экономит часы при аудите, смене подрядчика, инциденте с доступом или запросе на удаление данных.

Организация хранит архив «на всякий случай»

Это самый дорогой сценарий. Старые сканы, выгрузки, анкеты и договоры годами лежат в папке «Архив», доступной нескольким людям. Чем дольше хранится неиспользуемый массив, тем выше площадь утечки и стоимость инвентаризации.

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

Цена ошибки — не только штраф

Штраф до 6 млн рублей — видимая часть риска. В реальности утечка или неправильное размещение данных создают ещё несколько затрат, которые редко попадают в первоначальную смету.

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

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

Третий — зависимость от одного человека. Если документы принадлежат личному аккаунту администратора, бухгалтера или менеджера, увольнение становится технической проблемой. Доступ может быть утрачен, а права на файлы — не переданы.

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

Пятый — неверная классификация. Скан договора с подписью, таблица «Имя — телефон — адрес», выгрузка заявок с геометками — это уже не нейтральные файлы. Их нельзя размещать по логике «в эту папку быстрее загрузить».

Выбор облака: сначала данные, потом сервис

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

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

Proton Drive и MEGA сильнее там, где критична конфиденциальность содержимого и пользователь готов взять на себя ответственность за ключи и восстановление доступа. Для российского оператора ПДн они не заменяют локализованную базу.

Google Drive и OneDrive остаются удобными международными инструментами, но для первичного сбора и хранения персональных данных граждан России это плохая юридическая опора. Использовать их как универсальный архив организации — решение с отложенной ценой.

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