Данные в облаке: шифрование, владельцы ключей и ссылки для общего доступа

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

Шифрование при хранении и при передаче — по умолчанию

Документация Google Cloud описывает то, что по умолчанию делает большинство крупных провайдеров: «все данные, хранимые Google, шифруются на уровне хранилища с использованием алгоритма Advanced Encryption Standard (AES), AES-256», применяемого автоматически, без какой-либо настройки со стороны клиента. Данные при передаче между вашим устройством и провайдером отдельно защищены протоколом TLS, рассмотренным в курсе по криптографии этого университета. Этот базовый уровень действительно полезен — он защищает, например, от физической кражи жёсткого диска из дата-центра, — но отвечает лишь на часть вопроса.

Кто держит ключ — от этого зависит, от чего именно защита

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

Сквозное шифрование: у клиента — единственный ключ

Меньшее число потребительских функций идёт дальше шифрования при хранении, управляемого провайдером, распространяя настоящее сквозное шифрование (гарантию, рассмотренную в курсе по криптографии) на само облачное хранилище. Задокументированный пример — Advanced Data Protection для iCloud от Apple: при включении она распространяет сквозное шифрование на резервные копии iCloud, «Фото», «Заметки», iCloud Drive и другое, и Apple заявляет, что «ваши доверенные устройства сохраняют единоличный доступ к ключам шифрования для большей части ваших данных iCloud» — то есть сама Apple не может их расшифровать, даже по принуждению со стороны закона, и заявляет об этом прямо: «Никто другой не может получить доступ к вашим данным, защищённым сквозным шифрованием, — даже Apple». Компромисс, который Apple документирует вместе с этим, реален: поскольку у Apple нет ключа, она также не может помочь восстановить эти данные, если вы потеряете доступ и заранее не настроите доверенный контакт восстановления или ключ восстановления. Надёжная защита и лёгкое восстановление учётной записи тянут в противоположные стороны, и Advanced Data Protection заставляет вас выбрать.

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

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