До начала нового потока по курсу остается все меньше времени «Практики и инструменты DevOps» .
В преддверии старта курса мы подготовили перевод еще одного полезного материала.
Когда мы думаем об облаке, мы часто говорим о его преимуществах: масштабируемости, эластичности, гибкости и гибком ценообразовании.
Это все хорошо, но безопасность по-прежнему остается критически важным вопросом для бизнеса.
В вашей локальной среде вы несете ответственность за все аспекты безопасности, которые на базовом уровне включают (но не ограничиваются):
шифрование данных; контроль доступа к базе данных; сетевая безопасность; безопасность операционной системы (как хостовой, так и гостевой); физическая охрана.При правильном подходе все это влечет за собой значительный объем работы и, как правило, значительные затраты.
В облаках все эти моменты остаются актуальными и необходимыми для обеспечения должной безопасности.
Однако в рамках модели общей ответственности часть этой работы перекладывается от вас к поставщику облачных услуг.
Давайте рассмотрим эту модель и различия между двумя распространенными типами развертывания облачных баз данных: IaaS и DBaaS.
Модель общей ответственности
У каждого поставщика облачных услуг могут быть свои специфические условия, но тем не менее общая концепция остается для всех одинаковой.Безопасность состоит из двух частей: безопасность облака и безопасность в облаке.
Например, давайте посмотрим на модель ответственности AWS: 
Облачная безопасность
Та часть модели общей ответственности, за которую несет ответственность поставщик облачных услуг.Он включает в себя аппаратное обеспечение, операционную систему хоста и физическую безопасность инфраструктуры.
При переходе в облако многие из этих задач сразу же снимаются с клиента.
Облачная безопасность
Поскольку физической безопасностью облака управляет поставщик, зона ответственности клиента становится более целенаправленной.Важнейшим компонентом остается контроль доступа к данным клиентов.
Даже если вы поставите рядом с вашими серверами вооруженную охрану, вы вряд ли захотите открыть порт 3306 всему миру и разрешить root-доступ к базе данных.
Именно тип развертывания (IaaS или DBaaS) определяет зону ответственности клиента за безопасность «в облаке».
Самостоятельное развертывание (IaaS)
Часто, когда у вас есть опытная команда баз данных или сложная среда, самостоятельное развертывание предпочтительнее.В этом случае используются облачные компоненты IaaS (виртуальные машины, хранилище и сеть).
Хотя в этом подходе нет ничего плохого, он возлагает на клиента большую ответственность за безопасность.
Фактически представленная выше базовая модель соответствует самостоятельному развертыванию.
Здесь клиент несет ответственность за: управление гостевой операционной системой (обновления, исправления безопасности и т. д.); управление и настройка всех сетевых компонентов; управление брандмауэром; управление базами данных (безопасность, исправления, резервное копирование и т. д.); контроль доступа; данные клиента.
Опять же, это вполне жизнеспособный подход, а иногда и необходимый, в зависимости от ваших обстоятельств.
Однако давайте посмотрим, как меняется эта модель при использовании DBaaS.
Управляемое развертывание (DBaaS)
Даже при использовании базы данных в качестве услуги (например, Amazon RDS) часть ответственности по-прежнему остается на клиенте.Хотя границы у него разные.
Ниже показано, как меняется модель ответственности с DBaaS: 
Первое, что бросается в глаза, — ответственность за гостевую ОС и прикладное ПО переходит к облачному провайдеру.
Это позволит вашей команде сосредоточиться на уровне базы данных — самих данных о клиентах.
Клиент по-прежнему несет ответственность за шифрование на своей стороне, брандмауэр базы данных и контроль доступа к данным.
Однако огромный объем ежедневной оперативной работы передается от клиента поставщику облачных услуг.
Имейте в виду, что модель DBaaS не устраняет необходимость в администраторе базы данных.
Хотя большая часть оперативной поддержки прекращена, стандартные задачи администратора базы данных остались.
В будущем мы подробнее обсудим оставшиеся проблемы и причины, по которым вам необходимо продолжать уделять внимание своей базе данных.
Краткое содержание
Как видите, облако действительно помогает устранить часть традиционной работы и накладных расходов, связанных с управлением базами данных.Независимо от того, какой тип развертывания вы используете, вы по-прежнему несете (и всегда будете) ответственность за управление своим самым важным активом: данными.
А также вам остается анализ нагрузки, трафика и производительности.
Хотя облачные сервисы гарантируют, что отдельные компоненты находятся в рамках соглашения об уровне обслуживания, клиент всегда несет ответственность за управление своей рабочей нагрузкой, включая: оптимизация запросов; планирование мощностей; оптимальное распределение ресурсов; аварийное восстановление.
Это основные аспекты уровня базы данных, и переход в облако позволяет вам сосредоточить свои усилия на создании наилучшего приложения, оставляя детали инфраструктуры кому-то другому.
Поэтому, если вы рассматриваете возможность миграция в облако Percona может помочь вам проанализировать варианты и разработать систему, которая лучше всего подойдет вашей организации.
Взгляните на вторую часть этой серии статей: S Общая модель ответственности в облаке.
Часть 2: Ответственность администратора базы данных .
Вот и все.
Увидимся в курс ! Теги: #облачные сервисы #DevOps #облако #MySQL
-
Как Обновить Internet Explorer В Windows 7?
19 Oct, 24 -
Common Sense — Новейшее Антивирусное Решение
19 Oct, 24 -
Как Я Стал Инвестором
19 Oct, 24 -
Что Общего Между Коронавирусом И Шахматами?
19 Oct, 24 -
Управление Голосом Или Правильным Сообщением
19 Oct, 24 -
Алгоритм Диффи-Хеллмана
19 Oct, 24 -
Выпуск Gcc-4.7
19 Oct, 24
