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

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

В декабре 2010 года размещенная Microsoft служба Business Productivity Online Suite (BPOS) осталась открытой в сети, что позволяет неавторизованным пользователям получать доступ к контактной информации сотрудников в их автономных адресных книгах. В 2012 году Dropbox стал жертвой масштабной утечки данных, в результате которой были скомпрометированы учетные данные более 68 миллионов ее клиентов. Несколько других отраслевых гигантов, в том числе LinkedIn, Apple и некоторые другие, разместили свои данные в облаке. И в большинстве таких инцидентов распространенными причинами таких проблем оказываются некоторые незакрытые уязвимости в системе безопасности, человеческие ошибки или некоторые злоупотребления со стороны инсайдеров, всего этого можно избежать. Чтобы предотвратить атаки такого типа, защитить данные в Интернете и не стать жертвой утечки облачных данных, организации могут следовать следующим рекомендациям:

Шифровать все данные (в состоянии покоя и в движении)

Первый шаг к защите себя в случае утечки облачных данных в облаке по сути такой же, как защита данных вне облака, то есть шифрование. В процессе шифрования читаемые данные кодируются с помощью ключа, поэтому они становятся нечитаемыми для тех, у кого нет ключа разблокировки. Это может применяться к данным, которые находятся «в покое», а также к данным «в движении». Данные в состоянии покоя обычно сохраняются на локальных дисках, в SAN, NAS или другом носителе. Таким образом, шифрование в состоянии покоя обычно может быть реализовано одним из двух способов — шифрование всего диска или шифрование на уровне файлов. Наиболее часто используемые алгоритмы шифрования — Triple DES, RSA, Blowfish, Twofish и AES.

Данные подвергаются большему риску, когда они перемещаются из одного места в другое, т. е. «в движении». Когда данные передаются из одного места в другое, они проходят через десятки потенциальных точек уязвимости на пути передачи данных, где злоумышленник может попытаться их перехватить. Чтобы защитить данные в такой ситуации, поток данных шифруется в источнике, а затем расшифровывается в месте назначения. Шифрование может быть выполнено с использованием туннелей TLS/SSL или IPsec VPN для шифрования. IPsec можно использовать для создания взаимной аутентификации между конечными точками и источником, в то время как безопасность транспортного уровня (TLS) и шифрование уровня защищенных сокетов (SSL) можно использовать для защиты передачи данных. В случае новой реализации или обновления организации могут использовать TLS, который более эффективен и безопасен, чем SSL.

Обеспечение управления и безопасности ключей

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

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

Открытые облачные приложения

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

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

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

Отслеживайте и регистрируйте все сетевые действия

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

Утечки облачных данных: профилактика лучше, чем лечение

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