Разговоры о безопасности данных, как правило, делятся на три основные темы:
Данные SaaS не похожи на локальные или облачные данные, потому что у вас нет права собственности на операционную среду и гораздо меньше права собственности на сами данные. Из-за этих ограничений создание автоматических резервных копий, их хранение в безопасных средах и владение процессом восстановления является гораздо более сложной инженерной задачей.
Такая негибкость вынуждает организации разрабатывать обходные пути и ручные процессы резервного копирования данных SaaS, оставляя их в гораздо менее безопасных средах — досадно, потому что ваши резервные копии почти так же ценны для злоумышленников, как и ваши производственные данные. Организации, которые относятся к данным SaaS с меньшей осторожностью, даже в свете двузначного роста использования приложений SaaS, передают ключи от своего королевства более очевидными способами, чем они могли бы ожидать. В условиях надвигающейся угрозы потери данных, во что обойдется вашему бизнесу, если вы не предпримете быстрых мер по созданию плана восстановления данных SaaS?
Теперь давайте изменим эту иллюстрацию, добавив менее распространенное дополнение: у вас есть резервные копии для всех ваших данных на GitHub, которые включают не только код в каждом из этих репозиториев, но и метаданные, такие как проверки запросов на извлечение, проблемы, управление проектами и многое другое.
В этом случае ваши резервные копии на GitHub не будут содержать паролей или личной информации (PII) о ваших сотрудниках, помимо той, которую они уже опубликовали в своем профиле на GitHub. Это также не позволит злоумышленнику перемещаться вбок к вашим производственным серверам или службам, поскольку они еще не определили вектор атаки или точку вторжения. Однако вы все еще не в безопасности — резервные копии всех видов содержат информацию, на основе которой злоумышленники могут извлечь уроки, делая выводы о том, как работает ваша производственная среда.
Каждая небезопасная резервная копия и клонирование вашего личного кода чрезвычайно ценны, если целью злоумышленника является только кража интеллектуальной собственности (IP) или утечка конфиденциальной информации о предстоящих функциях, партнерских отношениях или слияниях и поглощениях конкурентам или финансовое мошенничество.
Файлы конфигурации Infrastructure as Code (IaC) и CI / CD также представляют особый интерес, поскольку они определяют топологию вашей инфраструктуры, раскрывают вашу инфраструктуру тестирования и этапы развертывания, а также раскрывают всех облачных провайдеров или службы сторонних производителей, от которых зависят ваши производственные сервисы. Эти файлы конфигурации основаны на секретах, таких как пароли или токены аутентификации. Даже если вы используете инструмент управления секретами, чтобы скрыть фактическое содержимое указанных секретов от контроля версий на GitHub, злоумышленник сможет быстро определить, где искать дальше, будь то хранилище Hashicorp, AWS Secrets Manager, Cloud KMS или одна из множества альтернатив.
Поскольку вы также создаете резервные копии своих метаданных, показанных на этом рисунке, небезопасная реализация оставляет ваши запросы на извлечение и комментарии к выпуску, которые вы в противном случае спрятали в своих частных репозиториях GitHub, доступными для изучения злоумышленником. Они быстро узнают, у кого есть права утверждать и объединять код в каждом репозитории, и изучат контрольные списки для развертывания или исправления, чтобы выявить слабые места.
Располагая этой информацией, они могут организовать гораздо более целенаправленную атаку либо непосредственно на вашу инфраструктуру, либо с использованием методов социальной инженерии, таких как предлог, на сотрудников, которые, как они теперь понимают, обладают правами администратора.
Данные SaaS однозначно уязвимы, поскольку, в отличие от локальных данных, в них есть две заинтересованные стороны: ваш провайдер и вы. У вашего провайдера может произойти потеря данных, например, когда GitLab потеряла 300 ГБ пользовательских данных всего за несколько секунд, когда инженер переписал их производственную базу данных. Вы можете совершить серьезную ошибку, например, случайно удалить свой экземпляр или загрузить CSV-файл, который мгновенно повредит все аспекты ваших данных.
Осведомленность вызывает серьезную озабоченность. В отчете AppOmni за 2023 год 85% опрошенных ими экспертов в области ИТ и кибербезопасности заявили, что в SaaS нет проблем с безопасностью. Тем не менее, 79% тех же людей признали, что их организация выявила по крайней мере одну угрозу кибербезопасности на основе SaaS за последние 12 месяцев. Наиболее распространенными инцидентами были уязвимости в разрешениях пользователей, раскрытие данных, конкретная кибератака и человеческая ошибка.
В то же время, отчет Oracle и аналитической фирмы ESG показал, что только 7% руководителей служб информационной безопасности (CISO) заявили, что они полностью понимают модель совместной ответственности, которая возлагает ответственность за безопасность данных на пользователя, а не на поставщика SaaS. 49% респондентов также заявили, что путаница вокруг этой модели привела к потере данных, несанкционированному доступу к данным и даже к компрометации систем.
Ответ на любые опасения по поводу безопасности резервных копий данных заключается не в том, чтобы полностью игнорировать резервные копии.
Когда вы предоставляете ИИ доступ на запись к вашим платформам SaaS, он может невинно повредить все ваши критически важные данные на скорости, ускоренной графическим процессором. Когда сообщения о подобных ситуациях начнут появляться массово, вы будете рады, что спрятали свои данные SaaS так, чтобы никто — ни злоумышленник, ни потерянный искусственный интеллект — не мог их прочитать. Вы будете вдвойне рады, что они также в целости и сохранности, когда вам это больше всего нужно.
- Как мы можем защитить данные, которые мы храним в нашей локальной или облачной инфраструктуре?
- Какие стратегии, инструменты или платформы позволяют надежно создавать резервные копии и восстанавливать данные?
- Во что нам обойдется потеря всех этих данных и как быстро мы сможем их вернуть?
Данные SaaS не похожи на локальные или облачные данные, потому что у вас нет права собственности на операционную среду и гораздо меньше права собственности на сами данные. Из-за этих ограничений создание автоматических резервных копий, их хранение в безопасных средах и владение процессом восстановления является гораздо более сложной инженерной задачей.
Такая негибкость вынуждает организации разрабатывать обходные пути и ручные процессы резервного копирования данных SaaS, оставляя их в гораздо менее безопасных средах — досадно, потому что ваши резервные копии почти так же ценны для злоумышленников, как и ваши производственные данные. Организации, которые относятся к данным SaaS с меньшей осторожностью, даже в свете двузначного роста использования приложений SaaS, передают ключи от своего королевства более очевидными способами, чем они могли бы ожидать. В условиях надвигающейся угрозы потери данных, во что обойдется вашему бизнесу, если вы не предпримете быстрых мер по созданию плана восстановления данных SaaS?
Ценные секреты, скрывающиеся на виду
Давайте проиллюстрируем распространенный сценарий: у вашей команды есть единая организация на GitHub, где вся ваша команда инженеров совместно работает над проектами разработки и развертывания в нескольких частных репозиториях.Теперь давайте изменим эту иллюстрацию, добавив менее распространенное дополнение: у вас есть резервные копии для всех ваших данных на GitHub, которые включают не только код в каждом из этих репозиториев, но и метаданные, такие как проверки запросов на извлечение, проблемы, управление проектами и многое другое.
В этом случае ваши резервные копии на GitHub не будут содержать паролей или личной информации (PII) о ваших сотрудниках, помимо той, которую они уже опубликовали в своем профиле на GitHub. Это также не позволит злоумышленнику перемещаться вбок к вашим производственным серверам или службам, поскольку они еще не определили вектор атаки или точку вторжения. Однако вы все еще не в безопасности — резервные копии всех видов содержат информацию, на основе которой злоумышленники могут извлечь уроки, делая выводы о том, как работает ваша производственная среда.
Каждая небезопасная резервная копия и клонирование вашего личного кода чрезвычайно ценны, если целью злоумышленника является только кража интеллектуальной собственности (IP) или утечка конфиденциальной информации о предстоящих функциях, партнерских отношениях или слияниях и поглощениях конкурентам или финансовое мошенничество.
Файлы конфигурации Infrastructure as Code (IaC) и CI / CD также представляют особый интерес, поскольку они определяют топологию вашей инфраструктуры, раскрывают вашу инфраструктуру тестирования и этапы развертывания, а также раскрывают всех облачных провайдеров или службы сторонних производителей, от которых зависят ваши производственные сервисы. Эти файлы конфигурации основаны на секретах, таких как пароли или токены аутентификации. Даже если вы используете инструмент управления секретами, чтобы скрыть фактическое содержимое указанных секретов от контроля версий на GitHub, злоумышленник сможет быстро определить, где искать дальше, будь то хранилище Hashicorp, AWS Secrets Manager, Cloud KMS или одна из множества альтернатив.
Поскольку вы также создаете резервные копии своих метаданных, показанных на этом рисунке, небезопасная реализация оставляет ваши запросы на извлечение и комментарии к выпуску, которые вы в противном случае спрятали в своих частных репозиториях GitHub, доступными для изучения злоумышленником. Они быстро узнают, у кого есть права утверждать и объединять код в каждом репозитории, и изучат контрольные списки для развертывания или исправления, чтобы выявить слабые места.
Располагая этой информацией, они могут организовать гораздо более целенаправленную атаку либо непосредственно на вашу инфраструктуру, либо с использованием методов социальной инженерии, таких как предлог, на сотрудников, которые, как они теперь понимают, обладают правами администратора.
Почему безопасные резервные копии — особенно данных SaaS — более важны, чем когда-либо?
Короче говоря, данные SaaS еще никогда не были так важны для почасовой работы вашей организации. Используете ли вы платформу для совместной работы с кодом, такую как GitHub, инструменты для повышения производительности, такие как Jira, или даже используете Confluence в качестве основного поставщика (и зависимого) всего бренда, вы привязаны к среде, которой не владеете, с методами управления данными, которые вы не можете полностью контролировать, просто чтобы не отключать свет.Данные SaaS однозначно уязвимы, поскольку, в отличие от локальных данных, в них есть две заинтересованные стороны: ваш провайдер и вы. У вашего провайдера может произойти потеря данных, например, когда GitLab потеряла 300 ГБ пользовательских данных всего за несколько секунд, когда инженер переписал их производственную базу данных. Вы можете совершить серьезную ошибку, например, случайно удалить свой экземпляр или загрузить CSV-файл, который мгновенно повредит все аспекты ваших данных.
Осведомленность вызывает серьезную озабоченность. В отчете AppOmni за 2023 год 85% опрошенных ими экспертов в области ИТ и кибербезопасности заявили, что в SaaS нет проблем с безопасностью. Тем не менее, 79% тех же людей признали, что их организация выявила по крайней мере одну угрозу кибербезопасности на основе SaaS за последние 12 месяцев. Наиболее распространенными инцидентами были уязвимости в разрешениях пользователей, раскрытие данных, конкретная кибератака и человеческая ошибка.
В то же время, отчет Oracle и аналитической фирмы ESG показал, что только 7% руководителей служб информационной безопасности (CISO) заявили, что они полностью понимают модель совместной ответственности, которая возлагает ответственность за безопасность данных на пользователя, а не на поставщика SaaS. 49% респондентов также заявили, что путаница вокруг этой модели привела к потере данных, несанкционированному доступу к данным и даже к компрометации систем.
Ответ на любые опасения по поводу безопасности резервных копий данных заключается не в том, чтобы полностью игнорировать резервные копии.
На что обратить внимание в безопасном поставщике резервного копирования данных SaaS
По мере изучения рынка платформ, позволяющих создавать резервные копии и восстанавливать данные из этих критически важных приложений SaaS, вам следует тщательно проверять эти обязательные компоненты:- Автоматизация: Ни одно надежное резервное копирование не требует ручных процессов — процесс резервного копирования должен автоматически создавать ежедневные инкрементные резервные копии с использованием дельта- или дифференцирующего алгоритма. Любой ручной процесс, такой как использование сценария резервного копирования с открытым исходным кодом, который не обновлялся годами, или даже простая задача, такая как написание задания cron для запуска сценария резервного копирования каждый вторник в 23: 59 вечера, создает потенциальные точки отказа.
- Полнота: Пример GitHub однозначно хорошо иллюстрирует разницу между данными (вашим кодом) и метаданными (разговорами, которые ваши инженеры ведут вокруг вашего кода), но многие SaaS-приложения имеют схожую иерархию данных. Если решение для резервного копирования не может защитить все ваши данные, то в случае аварийной потери данных у вас будет лишь половинчатый план восстановления и много ручной работы для восстановления скорости.
- Шифрование: Настаивайте на использовании 256-битного шифрования AES, как в режиме ожидания, так и при передаче, для всех ваших резервных копий данных SaaS. Провайдер также должен поддерживать единый вход, чтобы вы могли управлять пользователями и их привилегиями с помощью централизованного поставщика удостоверений личности.
- Соответствие требованиям к данным: такие сведения, как отчеты SOC 2 типа 2, в которых подробно описываются средства контроля безопасности платформы резервного копирования, могут дать вам уверенность в том, насколько серьезно они относятся к защите конфиденциальных данных в ваших резервных копиях. Хотя в настоящее время они вам не нужны, такие функции, как data residency, демонстрируют, что они разработали сложную инфраструктуру с правильными политиками для нескольких регионов.
- Наблюдаемость: вы не можете полностью контролировать, что происходит с данными вашей организации. Следующая лучшая вещь - это точное знание того, кто, когда и что было доступно или изменено в ваших резервных данных, как только это произойдет. Журнал аудита в режиме реального времени поможет вам быстро выявлять вторжения и принимать правильные меры по исправлению до того, как атака успеет нарушить ваши данные.
Когда вы предоставляете ИИ доступ на запись к вашим платформам SaaS, он может невинно повредить все ваши критически важные данные на скорости, ускоренной графическим процессором. Когда сообщения о подобных ситуациях начнут появляться массово, вы будете рады, что спрятали свои данные SaaS так, чтобы никто — ни злоумышленник, ни потерянный искусственный интеллект — не мог их прочитать. Вы будете вдвойне рады, что они также в целости и сохранности, когда вам это больше всего нужно.
