Модель распределения ответственности за безопасность БД в облаке +3


Все меньше времени остается до старта нового потока по курсу «DevOps практики и инструменты». В преддверии старта курса мы подготовили перевод еще одного полезного материала.





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

  • шифрование данных;
  • контроль доступа к базе данных;
  • безопасность сети;
  • безопасность операционной системы (как хоста, так и гостевой);
  • физическая безопасность.

При правильном подходе все это влечет за собой значительный объем работ и, как правило, значительные расходы. В облаках все эти моменты остаются актуальными и необходимыми для обеспечения надлежащей безопасности. Однако в соответствии с моделью общей ответственности часть этой работы переносится с вас на поставщика облачных услуг. Давайте посмотрим на эту модель и на отличия двух распространенных типов развертывания облачных баз данных: IaaS и DBaaS.

Модель общей ответственности


У каждого поставщика облачных услуг могут быть свои специфические термины, но тем не менее, общая концепция у всех остается одинаковой. Безопасность состоит из двух частей: безопасность облака (security of cloud) и безопасность в облаке (security in cloud). Для примера посмотрим на модель ответственности AWS:



Безопасность облака


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

Безопасность в облаке


Так как физической безопасностью облака, управляет поставщик, то зона ответственности клиента становится более целенаправленной. Наиболее важной компонентой остается контроль доступа к данным клиента (customer data).

Даже, если рядом с вашими серверами поставить вооруженную охрану, то вы вряд ли захотите открыть порт 3306 для всего мира и разрешить root-доступ к базе данных. Именно тип развертывания (IaaS или DBaaS) определяет зону ответственности клиента за безопасность “в облаке”.

Самостоятельное развертывание (IaaS)


Часто, при наличии опытной команды по работе с базами данных или сложного окружения, самостоятельное развертывание является более предпочтительным. В этом случае используются облачные компоненты IaaS (виртуальные машины, хранилища и сеть). Хотя в этом подходе нет ничего плохого, но клиент берет на себя больше ответственности за безопасность. Фактически, базовая модель, представленная выше, соответствует самостоятельному развертыванию. Здесь клиент несет ответственность за:

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

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

Управляемое развертывание (DBaaS)


Даже при использовании базы данных как услуги (например, Amazon RDS), часть ответственности все еще остается на клиенте. Хотя ее границы отличаются. Ниже показано как изменяется модель ответственности при DBaaS:



Первое, что бросается в глаза — это то, что ответственность за гостевые ОС и прикладное программное обеспечение переходит к облачному провайдеру. Это может освободить вашу команду, чтобы ей сосредоточиться на уровне базы данных — на самих данных (customer data). Клиент по-прежнему несет ответственность за шифрование на своей стороне, за брандмауэр базы данных и управление доступом к данным. Однако, огромный объем ежедневной операционной работы переходит от клиента к поставщику облачных услуг.

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

Резюме


Как вы видите, облака действительно помогают избавиться от части традиционной работы и накладных расходов, связанных с управлением базами данных. Независимо от того, какой тип развертывания вы используете, у вас все-равно остается (и останется навсегда) ответственность за управление самым важным активом: данными. А также, за вами остается анализ нагрузки, трафика и производительности. Хотя облачные сервисы гарантируют, что отдельные компоненты находятся в пределах SLA, тем не менее, клиент всегда несет ответственность за управление своей нагрузкой, в том числе:

  • оптимизацию запросов;
  • планирование мощностей;
  • оптимальное распределение ресурсов;
  • аварийное восстановление.

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

Взгляните на вторую часть этой серии статей (англ.): Shared Responsibility Model in the Cloud Part 2: DBA Responsibility.

На этом все. До встречи на курсе!




К сожалению, не доступен сервер mySQL