3 Января, 2019

Насколько безопасно хранить ваши данные в облаке

Владимир Безмалый

Мы все чаще и чаще используем облачные хранилища. Что из этого следует? Да то, что безопасность ваших хранимых данных становится все большей проблемой. Уже сегодня все чаще и чаще компании, университеты и школы уже продолжительное время расширяют использование таких облачных сервисов, как Google Drive, и все больше пользователей хранят файлы в Dropbox, Box, Amazon Drive, Microsoft OneDrive и т.п.

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

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

Кроме того, необходимо помнить, что есть ряд относительно простых способов, с помощью которых пользователи могут повысить безопасность своих собственных данных по сравнению со встроенными методами.

Кто выступает в роли хранителя ключа?

Коммерческие облачные системы шифруют данные каждого пользователя с помощью специального ключа шифрования. Но кто владеет этим ключом?

Ключ может храниться как самим сервисом, так и самими пользователями? Большинство сервисов сами хранят ключ, позволяя их системам просматривать и обрабатывать пользовательские данные, например, индексировать данные для будущих поисков. Эти сервисы также получают доступ к ключу, когда пользователь входит в систему с паролем, чтобы разблокировать данные для использования.

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

Ключ хранится у пользователя

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

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

Что делать? Как защитить себя?

Наиболее безопасным будет объединить оба способа хранения ключей. Как? Перед загрузкой данных в облако сначала зашифруйте их, используя собственное программное обеспечение для шифрования. Затем загрузите закодированный файл в облако. Чтобы снова получить доступ к файлу, войдите в сервис, скачайте и расшифруйте его самостоятельно.

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

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

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