Регистрация Войти
Рейтинг:1
fgrieu avatar Server

Преимущества отдельного сервера РСУБД

флаг de
fgrieu

Я хотел бы сравнить преимущества двух архитектур хостинга для небольшого сервера (имеется в виду 2-ядерный процессор и 250 ГБ SSD с 100 ГБ, выделенными для данных, более чем достаточно), состоящего в основном из пользовательского приложения, предоставляющего веб-сервисы, с архитектуру REST и все данные в реляционной базе данных.

  1. Размещается на одном компьютере в облаке (например, экземпляр EC2) с реляционной базой данных (например,mySQL, PostGreSQL), работающие локально, с частыми внешними резервными копиями зашифрованных баз данных (например, в S3/Glacier).
  2. Размещенный на машине в облаке (например, аналогичный экземпляр EC2 с меньшим объемом SSD) с РСУБД в качестве управляемой службы, например. Amazon Relational Database Service, возможно, с менее частым внешним резервным копированием зашифрованных баз данных.

Я вижу преимущества для 1

  • Дешевле (экономия на управляемой СУБД услуге и сети) примерно в 3 раза, я полагаю.
  • Возможно, лучшая задержка доступа к базе данных?

и на 2

  • Если экземпляр EC2 будет уничтожен, мы не потеряем данные.
  • Нет необходимости копировать БД из одного экземпляра EC2 в другой при перестройке сервера с нуля или при серьезном обновлении, таком как изменение ОС; таким образом, меньше времени простоя.
  • Возможно, более простое администрирование БД.

Что мне не хватает? Любые указатели на авторитетную позицию по этому поводу?

44
1 + 3
pmdba avatar
флаг cn
pmdba
С точки зрения безопасности данные _никогда_ не должны размещаться на том же сервере, что и внешний интерфейс приложения, особенно если внешний интерфейс открыт для доступа в Интернет, а также в частных сетях. Базы данных должны быть защищены брандмауэром отдельно от серверов приложений.
1
Ответить
fgrieu avatar
флаг de
fgrieu
@pmdba: Я понимаю вашу точку зрения, и это интересно. Тем не менее, если сервер с внешним интерфейсом приложения скомпрометирован и поскольку у него есть учетные данные для доступа к СУБД, все данные в СУБД в принципе могут быть эксфильтрированы и/или повреждены аналогично сценарию 1/2 (с той разницей, что через файловую систему можно только в 1).Единственное существенное отличие, которое я вижу, заключается в том, что в сценарии 2 эксфильтрация/повреждение видны в журналах СУБД, тогда как они могут быть изменены или уничтожены вместе с остальными в сценарии 1.
0
Ответить
pmdba avatar
флаг cn
pmdba
В безопасном дизайне приложения приложение должно использовать непривилегированную учетную запись БД, получая доступ к данным через внутренний API (построенный с использованием хранимых процедур в БД). Приложение никогда не должно входить непосредственно в привилегированную учетную запись БД, особенно в учетную запись, которой принадлежат данные или объекты.
1
Ответить
Рейтинг:1
avatar Server
флаг de
John Malloc

По первому пункту:

  • Когда ваш веб-сервис скомпрометирован, база данных также будет скомпрометирована. Лучше всего отделить уровень представления от уровня данных.

  • латентность с одной и той же или даже между двумя AZ незначительна и может быть опущена из рассмотрения.

  • Я бы не сказал, что это решение будет намного дешевле, чем RDS, потому что существенным фактором, влияющим на цену, будет хранилище SSD. Цена будет примерно 30% между RDS и EC2.

  • Что касается типа SSD, вам нужно решить, или, возможно, вы уже знаете, какой уровень IOPS и МБ/с при пиковых нагрузках потребуется вашей базе данных в будущем. Это также было бы хорошим кандидатом для повышения конечной цены решения.

По второму пункту:

  • Вы можете предотвратить эту ситуацию. По умолчанию при подключении тома EBS без полномочий root к экземпляру Удалить при завершении атрибут установлен на ЛОЖЬ. Я предполагаю, что база данных будет расположена на некорневом томе EBS. Флаг может быть установлен на ЛОЖЬ на корневой объем, а также.

  • вам не нужно копировать базу данных из EC2 в EC2, вы можете присоединить или отсоединить том EBS с базой данных.

  • как вы указали в решении RDS, административная ответственность лежит на AWS. Однако чем сложнее схема базы данных, тем больше я бы предпочел неуправляемую службу базы данных.

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

0 + 2
fgrieu avatar
флаг de
fgrieu
Я не понимаю, почему с отдельной ДБО ситуация намного лучше с точки зрения безопасности.Я полагаю, что если веб-служба скомпрометирована, поскольку у нее есть доступ R/W к базе данных, злоумышленник может произвести извлечение или изменение. Я признаю одно отличие: вся БД может быть скопирована через файловую систему только тогда, когда RBS работает локально. Зашифрованная БД в некоторой степени смягчает это.
0
Ответить
флаг de
John Malloc
Предположим, я хакер. Я взламываю ваш экземпляр EC2, где работает веб-сервис вместе с базой данных. Давайте также предположим, что вы не заметили инцидент безопасности. Я бы установил программу-сниффер и кейлоггер и ждал бы уведомления. Когда администратор базы данных входит в систему или кто-то по ошибке выполняет команды SQL локально, я перехватываю учетные данные. Я бы снова войти в систему и дамп вашей базы данных. Это сложно сделать, когда ваш уровень представления общается с уровнем базы данных через прокси-сервер HTTPS, а открытый/закрытый ключи не расположены в одном месте.
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

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