Пять главных угроз облачной безопасности
Практически каждый бизнес использует какую-либо облачную сеть, а это означает, что облачная безопасность имеет жизненно важное значение. Вот наш список тем, которые вы должны контролировать, чтобы оставаться в безопасности.
Высокая доступность — включая субъектов угроз
Одним из основных преимуществ облака является высокая доступность размещенных ресурсов. Они доступны из любого места. И это здорово. Но это также означает, что ваша облачная инфраструктура неизбежно выходит в Интернет. Это позволяет любому злоумышленнику легко попытаться подключиться к вашим серверам и службам, выполнить сканирование портов, атаки по словарю и разведывательные действия.
Некоторые проблемы безопасности, которые необходимо решить для облачной инфраструктуры, такие же, как и для традиционной локальной инфраструктуры. Некоторые из них отличаются или включают дополнительные задачи. Первый шаг — определить риски, связанные с вашей облачной инфраструктурой. Вам необходимо принять контрмеры и другие ответные меры и действия, которые уменьшат или смягчат эти риски. Убедитесь, что вы действительно задокументировали их и отрепетировали их со всеми заинтересованными сторонами, присутствующими и вовлеченными. Это сформирует вашу всеобъемлющую стратегию безопасности в облаке.
Отсутствие стратегии облачной безопасности равносильно игнорированию кибербезопасности наземных сетей. На самом деле, это, вероятно, хуже из-за того, что облако ориентировано на Интернет.
Конкретные риски, с которыми вы сталкиваетесь, немного различаются в зависимости от того, как вы используете облако и какое сочетание облачных предложений вы используете: инфраструктура как услуга, платформа как услуга, программное обеспечение как услуга, Контейнеры как услуга и так далее. И есть разные способы классификации рисков. Мы собрали их вместе в согласованные, но общие группы риска. Могут быть некоторые, которые не относятся к вашим конкретным вариантам использования, но убедитесь, что это действительно так, прежде чем отбрасывать их.
Неправильная конфигурация и человеческий фактор
Ошибки из-за недосмотра, переутомления или просто неумения по-прежнему изобилуют в организациях всех размеров. Каждую неделю забытые элементы и пропущенные настройки приводят к компрометации системы. Массовое взлом Equifax в 2017 году, в результате которого были украдены личные данные более 160 миллионов человек, использовало устаревший SSL-сертификат. Если бы существовал процесс, регулирующий возобновляемые элементы, и четкие указания о том, кто несет ответственность за этот процесс, вероятно, сертификат был бы продлен, и нарушения никогда бы не произошло.
Исследователи безопасности обнаруживают незащищенные контейнеры почти каждую неделю с помощью таких инструментов, как Shodan, поисковая система, которая ищет устройства, порты и службы. Некоторые из этих взломов и разоблачений возникают из-за того, что люди ожидают, что все будет защищено по умолчанию, а это не так. После того, как вы развернули свой удаленный сервер, вам необходимо предпринять те же шаги по укреплению безопасности и улучшению безопасности, что и любой другой сервер. Патч тоже жизненно важен. Для поддержания целостности защиты сервера необходимо своевременно применять исправления безопасности и обслуживания.
Приложения, особенно хранилища данных и базы данных, такие как Elastic Search, также должны быть защищены после установки. Для учетных записей по умолчанию необходимо изменить свои учетные данные, а API-интерфейсы должны быть защищены с помощью самого высокого уровня безопасности, который предлагается.
Следует использовать двухфакторную или многофакторную аутентификацию, если она доступна. Избегайте двухфакторной аутентификации на основе SMS, ее легко скомпрометировать. Неиспользуемые API должны быть отключены, если они не нужны, или заблокированы невыпущенными — и закрытыми — ключами API, чтобы предотвратить их использование. Брандмауэры веб-приложений обеспечивают защиту от таких угроз, как атаки с внедрением кода SQL и межсайтовые сценарии.
Отсутствие контроля над изменениями
С ошибками конфигурации связаны уязвимости, возникающие при изменении или обновлении работающей системы. должны осуществляться контролируемым и предсказуемым образом. Это означает планирование и согласование изменений, проверку кода, применение изменений в изолированной системе, их тестирование и внедрение в работающую систему. Это то, что идеально подходит для автоматизации — до тех пор, пока конвейер от разработки до развертывания достаточно надежен и действительно проверяет то, что, по вашему мнению, он делает, настолько тщательно, насколько вам это нужно.
Другие изменения, о которых вам следует знать, касаются ландшафта угроз. Вы не можете контролировать обнаружение новых уязвимостей и добавление их в список эксплойтов, которые могут использовать злоумышленники. Что вы можете сделать, так это убедиться, что вы просканировали свою облачную инфраструктуру, чтобы устранить все известные на данный момент уязвимости.
Необходимо проводить частые и тщательные проверки на проникновение в вашу облачную инфраструктуру. Поиск и устранение уязвимостей — ключевой элемент обеспечения безопасности ваших инвестиций в облако. Сканирование на проникновение может искать забытые открытые порты, слабые или незащищенные API, устаревшие стеки протоколов, распространенные неправильные конфигурации, все уязвимости в базе данных Common Vulnerabilities and Exposures и многое другое. Их можно автоматизировать и настроить на оповещение при обнаружении требующего действия элемента.
Взлом аккаунта
Взлом учетной записи — это название компрометации системы путем доступа к учетной записи электронной почты уполномоченного лица, учетным данным для входа или любой другой информации, необходимой для аутентификации в компьютерной системе или службе. Затем субъект угрозы может изменить пароль для учетной записи и осуществлять злонамеренные и незаконные действия. Если они скомпрометировали учетную запись администратора, они могут создать новую учетную запись для себя, а затем войти в нее, оставив учетную запись администратора, по-видимому, нетронутой.
Фишинговые атаки или атаки по словарю являются распространенными способами получения учетных данных. В дополнение к словарным словам и перестановкам с использованием обычных замен чисел и букв, атаки по словарю используют базы данных паролей из других утечек данных. Если кто-либо из владельцев учетных записей был уличен в предыдущих взломах в других системах и повторно использовал скомпрометированный пароль в ваших системах, они создали уязвимость в вашей системе. Пароли никогда не должны повторно использоваться в других системах.
Здесь поможет двухфакторная и многофакторная аутентификация, а также автоматическое сканирование журналов на наличие неудачных попыток доступа. Но не забудьте проверить политику и процедуры вашего хостинг-провайдера. Вы предполагаете, что они будут следовать передовым отраслевым практикам, но в 2019 году выяснилось, что Google хранит пароли G Suite в виде обычного текста в течение 14 лет.
Снижение видимости
Езда в тумане — занятие неблагодарное. И администрирование системы без низкоуровневой детализированной информации, которую специалисты по безопасности используют для мониторинга и проверки безопасности сети, представляет собой аналогичную перспективу. Вы не сделаете работу так хорошо, как если бы вы могли видеть то, что вам нужно.
Большинство облачных серверов обычно поддерживают несколько методов подключения, таких как протокол удаленного рабочего стола, Secure Shell и встроенные веб-порталы, и это лишь некоторые из них. Все это можно атаковать. Если происходят нападения, вам нужно знать. Некоторые хостинг-провайдеры могут предоставить вам лучшее ведение журнала или более прозрачный доступ к журналам, но вы должны запросить это. Они не делают этого по умолчанию.
Доступ к журналам — это только первый шаг. Вам нужно анализировать их и искать подозрительное поведение или необычные события. Объединение журналов из нескольких разных систем и просмотр их на единой временной шкале может быть более информативным, чем просмотр каждого журнала по отдельности. Единственный реальный способ добиться этого — использовать автоматизированные инструменты, которые будут искать необъяснимые или подозрительные события. Более совершенные инструменты также будут сопоставлять и находить закономерности событий, которые могут быть результатом атак и которые, безусловно, требуют дальнейшего изучения.
Несоблюдение правил защиты данных
Несоблюдение — это защита данных и конфиденциальность данных, эквивалентная неправильной настройке системы. Несоблюдение требуемых законом политик и процедур для обеспечения законного сбора, обработки и передачи персональных данных представляет собой другой тип уязвимости, но, тем не менее, это уязвимость.
В эту ловушку тоже легко попасть. Защита данных, безусловно, хорошая вещь, и законодательство, которое требует, чтобы организации функционировали таким образом, чтобы охранять и защищать данные людей, также является хорошей вещью. Но следить за самим законодательством очень сложно без помощи специалиста или внутренних ресурсов с достаточными навыками и опытом.
Постоянно принимаются новые законы и вносятся поправки в действующее законодательство. Когда Великобритания вышла из Европейского экономического союза (ЕАЭС) 31 января 2020 года, британские компании оказались в любопытном положении. Они должны соблюдать версию Общего регламента по защите данных для Великобритании, содержащуюся во второй главе Закона Великобритании о защите данных от 2018 года, в отношении любых данных, которые они хранят о гражданах Великобритании. Если какие-либо личные данные, которые они хранят, принадлежат людям, проживающим в других странах Европы, вступает в силу Общий регламент ЕС по защите данных.
И GDPR распространяется на все организации, независимо от того, где они базируются. Если вы собираете, обрабатываете или храните личные данные, принадлежащие гражданам Великобритании или Европы, к вам будет применяться один из этих GDPR — этим должны заниматься не только организации Великобритании и ЕС. Та же модель применяется к Закону штата Калифорния о конфиденциальности потребителей (CCPA). Он защищает жителей Калифорнии независимо от того, где происходит обработка данных. Так что это не то, с чем должны справиться только калифорнийские организации. Важно не ваше местоположение. Важно местонахождение человека, чьи данные вы обрабатываете.
Калифорния не одинока в решении проблемы конфиденциальности данных посредством законодательства. Невада и Мэн также имеют действующее законодательство, а Нью-Йорк, Мэриленд, Массачусетс, Гавайи и Северная Дакота применяют свои собственные законы о конфиденциальности данных.
Это дополняет федеральное законодательство с вертикальной направленностью, такое как Закон о переносимости и подотчетности медицинского страхования (HIPAA), Правило о защите конфиденциальности детей в Интернете (COPPA) и Закон Грэмма-Лича-Блайли (GLBA) в случае возникновения любого из они относятся к вашей деятельности.
Если вы собираете информацию через портал или веб-сайт в своей облачной инфраструктуре или обрабатываете данные на размещенном сервере, некоторые из этих законов будут применяться к вам. Несоблюдение может повлечь за собой значительные финансовые санкции в случае утечки данных, а также ущерб для репутации и возможность подачи коллективных исков.
Все сделано правильно, это работа на полный рабочий день
Безопасность — это бесконечная проблема, и облачные вычисления привносят свой собственный набор уникальных проблем. Важным фактором является тщательный выбор хостинга или поставщика услуг. Убедитесь, что вы проводите тщательную комплексную проверку, прежде чем официально взаимодействовать с ними.
- Серьезно ли они сами относятся к безопасности? Каков их послужной список?
- Предлагают ли они рекомендации и поддержку или продают вам свои услуги, оставляя вас с ними?
- Какие инструменты и меры безопасности они предоставляют в рамках своих услуг?
- Какие журналы вам доступны?
Когда речь заходит об облачных вычислениях, кто-то обычно произносит хорошо известную фразу: «Облако — это просто чей-то компьютер». Как и все звуковые фрагменты, это грубое упрощение. Но доля правды в нем все же есть. И это трезвая мысль.