«Мы привыкли думать о файлах в «облаке» как о чём-то эфемерном, но каждый гигабайт всегда привязан к конкретной физической стойке в дата-центре. Вопрос не в том, где они лежат, а в том, кто и на каких условиях контролирует доступ к этой стойке, и что происходит, когда политика провайдера меняется.»
Облачное хранилище, это не место, а процесс
Когда вы загружаете файл в Yandex Disk, VK Cloud или S3-совместимое хранилище, вы не отправляете его в абстрактное «небо». Вы передаёте данные на управляемый удалённо сервер, расположенный в физическом здании — дата-центре. Ключевая иллюзия облака в том, что вам не нужно знать номер стойки, модель диска или город. Вы платите за сервис — доступность, резервирование, интерфейс. Но на физическом уровне ваш архив фотографий, это набор магнитных доменов на HDD или состояние ячеек NAND-памяти в SSD, размещённых в конкретном дата-центре, который подчиняется законам страны его расположения.
Физическая география данных и 152-ФЗ
Для российских компаний, особенно работающих с персональными данными, физическое местоположение серверов перестаёт быть технической деталью и становится регуляторным требованием. 152-ФЗ «О персональных данных» обязывает обеспечивать их запись, систематизацию, накопление, хранение на территории России. Если ваш корпоративный файловый архив или CRM-система использует облако, вы должны быть уверены, что данные не мигрируют в дата-центры за рубежом, даже в рамках глобальных политик балансировки нагрузки провайдера.
На практике это означает, что при выборе провайдера нужно проверять не только маркетинговые слоганы о «российских дата-центрах», но и техническую архитектуру. Хранилище должно быть изолировано на уровне региона (region) или зоны доступности (availability zone), которая гарантированно находится в РФ. Административный интерфейс провайдера должен предоставлять чёткие инструменты проверки и контроля локации.
Абстракции поверх железа: от блочного хранилища до object storage
Пользователь видит папки и файлы, но под капотом облачные провайдеры используют разные модели хранения, каждая со своей логикой и «физикой».
- Блочное хранилище (Block Storage): Виртуальный аналог жёсткого диска. Вы получаете том (volume), который операционная система сервера монтирует как обычный диск (например, /dev/vdb). Данные разбиваются на блоки фиксированного размера. Физически эти блоки могут быть разбросаны по разным дискам в кластере для надёжности и скорости. Подходит для баз данных, файловых систем серверов.
- Файловое хранилище (File Storage): Предоставляет доступ по сетевым протоколам, таким как NFS или SMB. Вы монтируете сетевую папку. Здесь уже есть иерархия директорий и файлов, которую поддерживает сервис провайдера. Физически это часто распределённая файловая система (например, на базе CephFS). Удобно для общего доступа между несколькими виртуальными машинами.
- Объектное хранилище (Object Storage): Самый распространённый тип для хранения изображений, видео, бэкапов, статики сайтов. Файл (объект) хранится целиком с присвоенным уникальным идентификатором (ключом) и метаданными. Нет иерархии папок в классическом виде — структура имитируется через префиксы в ключах (например, `photos/2024/summer/beach.jpg`). Физически объект разбивается на части (чанки), которые реплицируются и распределяются по множеству серверов и стоек для отказоустойчивости. Интерфейс доступа — обычно HTTP API (REST).
Репликация, шифрование и контроль доступа
Отказоустойчивость облака строится на избыточности. Один файл в object storage может храниться в трёх экземплярах (репликах), размещённых на разных серверах, в разных стойках и даже в разных дата-центрах одного региона. Это защищает от выхода из строя отдельного диска или сервера. Однако важно понимать: если ваш договор с провайдером предусматривает хранение исключительно в РФ, нужно убедиться, что все реплики тоже не покидают территорию страны.
Шифрование бывает двух типов:
- Шифрование на стороне провайдера (Server-Side Encryption): Данные шифруются после получения и хранятся в зашифрованном виде на дисках провайдера. Ключи шифрования обычно управляются самим провайдером (хотя могут быть варианты с ключами, управляемыми клиентом). Это защищает от физического изъятия дисков, но оставляет данные потенциально доступными для сотрудников провайдера или по решению суда, адресованному провайдеру.
- Шифрование на стороне клиента (Client-Side Encryption): Файлы шифруются на вашем устройстве до отправки в облако. В облаке хранится только шифротекст. Ключи никогда не передаются провайдеру. Это даёт максимальный уровень конфиденциальности, но лишает провайдера возможности предоставлять некоторые сервисы (например, предпросмотр изображений прямо в браузере). Для соответствия требованиям регуляторов иногда необходимо именно клиентское шифрование.
Механизмы контроля доступа (IAM — Identity and Access Management) определяют, кто и к каким файлам может обращаться. Политики доступа могут быть сложными: доступ только с определённых IP-адресов (например, из офисной сети компании), только в определённое время, только для чтения без возможности удаления. Грамотная настройка IAM критически важна для защиты от утечек.
Что происходит при удалении файла?
Нажатие кнопки «Удалить» в веб-интерфейсе редко приводит к мгновенному физическому стиранию данных с дисков. Сначала объект помечается как удалённый, его ссылка убирается из индекса, и он становится недоступным для пользователя. Физическое освобождение места происходит позже, в ходе фоновых процессов сборки мусора. У многих провайдеров есть понятие «корзины» или версионирования, которые позволяют восстановить файл после удаления в течение определённого срока.
Для полного, необратимого удаления данных, соответствующего требованиям регуляторов об «уничтожении персональных данных», часто требуется использование специальных методов: криптографическое стирание (уничтожение ключа шифрования, делающее данные нечитаемыми) или многократная физическая перезапись блока данных, что в облачной среде обычно недоступно клиенту. В таких случаях необходимо запрашивать у провайдера соответствующую процедуру, подтверждённую актом.
Провайдеры и их «физика»
Российский рынок предлагает спектр решений с разной архитектурой.
- Крупные публичные облака (VK Cloud, Yandex Cloud, Selectel): Имеют собственные или арендованные дата-центры уровня Tier III в России. Предлагают полноценные S3-совместимые object storage, блочные и файловые хранилища. Их инфраструктура рассчитана на масштабирование и высокую доступность, но требует внимательной настройки политик локализации данных и доступа.
- Провайдеры с акцентом на sovereign cloud: Позиционируют решения, максимально соответствующие требованиям регуляторов, включая ФСТЭК. Могут предлагать изолированные стенды, проверенное на соответствие ПО и детальную документацию по архитектуре.
- Частные облачные решения: Развёртывание инфраструктуры хранения (например, на базе OpenStack Cinder/Swift или Ceph) на собственном оборудовании в корпоративном дата-центре. Полный контроль над «физикой», но и полная ответственность за отказоустойчивость, обновления и безопасность.
При выборе важно запросить у провайдера схему размещения данных, описание модели репликации, информацию о юрисдикции и практике реагирования на официальные запросы.
Резервное копирование в облако и из облака
Облачное хранилище часто используется как цель для бэкапов. Но здесь возникает тонкий момент: бэкап, хранящийся в том же облаке и у того же провайдера, что и основная система, не является полноценно изолированной копией с точки зрения рисков. Сбой платформы провайдера или его блокировка могут сделать недоступными и основную систему, и её резервные копии.
Стратегия 3-2-1 (три копии данных, на двух разных типах носителей, одна из которых географически удалена) в облачном контексте трансформируется. Например: основная копия на локальных серверах компании, вторая копия в одном публичном облаке (российском), третья копия — в другом публичном облаке или на tape-хранилище у другого провайдера. Критически важные данные могут потребовать также и локального воздушного разрыва (offline backup).
Вместо заключения: файл лежит там, где заканчивается ваша ответственность
Главный вывод не технический, а управленческий. Когда вы используете облачное хранилище, вы делегируете физическое хранение данных провайдеру, но не делегируете ему ответственность за их содержание, законность обработки и, в конечном счёте, за бизнес-последствия их потери или утечки. Вы должны точно знать, в какой юрисдикции находятся серверы, по каким законам живёт провайдер, как построена репликация и кто имеет криптографические ключи.
Файлы в облаке реально лежат на дисках в стойке с определённым адресом. Ваша задача — убедиться, что условия доступа к этой стойке, её географическое положение и правовой режим полностью соответствуют вашим задачам и требованиям регуляторов. Облако, это мощный инструмент, но его сила прямо пропорциональна глубине понимания его устройства.