Защита данных в облаке: с чего начать

Безопасность
Защита данных в облакеКогда мы говорим о защите данных в облаке, то мы подразумеваем… Простого ответа на этот вопрос нет, так как он в значительной степени возникает из тех инструментов и технологий, которые используются. С точки зрения ИТ-специалистов, обилие потенциальных векторов атаки делает защиту облачных систем куда как более сложной, чем защиту традиционных систем. Но это совсем не значит, что нужно планировать защиту от всех этих факторов — при первоначальной формулировке модели угроз значительная их часть отсеивается.

Логика такова:

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

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

Процессы защиты данных


Резервное копирование и восстановление, обеспечение непрерывности бизнеса, восстановление после ЧП — все это темы, которые наверняка всплывут в обсуждении, которое касается защиты данных. Есть и другие термины — комбинация двух или более техник. Стоит согласовать определения с партнерами и вендорами — если вы подразумеваете под ними разные понятия, то вы можете получить не совсем то что хотите.

Резервное копирование — пожалуй, самый простой в организации процесс. Это защита данных дупликацией, созданием копии данных, которые находятся в работе. Копия хранится в отдельном хранилище, отделенном от основного логически и физически (желательно расстоянием). В случае сбоя, работа сервиса/приложения восстанавливается загрузкой резервной копии с последующим ее восстановлением.

Восстановление в аварийных ситуациях — это процесс восстановления работоспособности всей ИТ-инфраструктуры (которая обеспечивала функционирование приложения/сервиса) после того как инфраструктура стала недоступна на недопустимый промежуток времени. Восстанавливаются не только данные, но и серверы, приложения работающие на серверах, схема сетевых взаимодействий между серверами и так далее.

Определение непрерывности бизнеса включает в себя как оперативное восстановление, так и восстановление в аварийных ситуациях. Оперативное восстановление подразумевает восстановление работы какой-либо из систем ИТ-структуры. Это может быть технический отказ — выход из строя жесткого диска или поломка системы кондиционирования или неполадка, связанная с ПО — сбой сетевого протокола или повреждение базы данных. Главное отличие от восстановления в аварийных ситуациях в том, что усилия по восстановлению проходят в штатном режиме и как правило не подразумевают нарушений в работе сервиса — пока идут работы, нагрузка переносится на другие серверы/площадки, в то время как при ЧП возможно прекращение работы сервисов до устранения ЧП.

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

Определение «облака» и защита данных


Национальный институт стандартов и технологии определяет публичный «облачный» сервис как «инфраструктуру, которая содержится и поддерживается облачным провайдером и предоставляется для свободного использования всем желающим». Частное «облако», согласно определению того же NIST, это «облачная» компьютерная инфраструктура, предоставляемая облачным провайдером для эксклюзивного использования единственной организацией, включающей в себя многочисленных пользователей (например бизнес-подразделения организации). Оно («облако») находится в собственности и управляется организации, которая пользуется его услугами, третьим лицом, либо тем и другим в разной степени и может располагаться на или вне мощностей заказчика.

Защита данных может выполняться как своими силами организации или передаваться третьим лицам — провайдерам сервисов резервного копирования (backup-as-a-service), восстановления данных (recovery-as-a-service) или восстановления в аварийных ситуациях (disaster recovery-as-a-service). Хотя не существует ни одной компании, которая бы предоставляла услуги именно под такими названиями, эти модели существуют, просто, как правило, они включены в состав более общих IaaS, PaaS и так далее. В любом случае участие третьей стороны в создании и выполнении схемы защиты подразумевает определенное (и немалое) доверие к провайдеру, который должен быть включен в состав облачной инфраструктуры организации, причем желательно с самого начала.

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

Первые шаги


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

Простой способ классификации задач предложил Редьярд Киплинг. В поэме он сформулировал основные принципы журналистики в виде «шестерки слуг»-вопросов (кто?, что?, когда?, где?, почему?, как?), эти же вопросы-критерии можно использовать и для работы с информацией в целом. Попробуйте категоризировать имеющиеся задачи по этим принципам. Четкое понимание своих потребностей — то что вам необходимо, когда вы будете проводить переговоры с вендорами, иначе можно потеряться и получить не то что нужно.

Комментарии (0)


Добавление комментариев доступно только зарегистрированным пользователям. Используйте свою существующую учетную запись для авторизации. Если у Вас еще нет учетной записи на сайте ее можно создать пройдя несложную процедуру регистрации. Кстати, для входа на сайт, наравне с учетной записью на cloudzone.ru, можно использовать аккаунт из следующих популярных сервисов: Яндекс, Facebook, Google и LinkedIn