У меня есть среда STAGING и PROD, веб-приложения, базы данных SQL и т. Д. В Azure. В настоящее время масштаб базы данных SQL для PROD намного выше, чем STAGING - никаких сюрпризов.
Я полагаю, что есть соблазн сэкономить, объединив эти ресурсы SQL вместе с SQL Elastic Pool. Однако я обеспокоен тем, что это создаст связь между STAGING и PROD, что все внутри меня кричит - плохая идея.
Каковы законные недостатки, которые могут повлиять на производительность, надежность, безопасность и т. Д.?
Самый большой отпор для обмена Stage и Prod, который я получаю, исходит от кибер-стороны дома. Если вы должны продемонстрировать четкую границу между Stage и Prod, вам не следует использовать эластичный пул для обоих. Кроме этого, нет никаких реальных технических недостатков, вы всегда можете смешивать и сопоставлять отдельные БД с пулом. В большинстве случаев эластичный пул более рентабелен, но обратите внимание на следующее в соответствии с нашими документация.
Плата за эластичные пулы не взимается за базу данных. Вам выставляется счет за каждый час существования пула с наибольшим eDTU или виртуальным ядром, независимо от использования или от того, был ли пул активен менее часа.
Если у вас есть требования клиента или контракта, которые требуют физического разделения N уровней, вы не можете этого сделать. С точки зрения безопасности, объединение двух сред - очень плохая идея. Отличный способ подлить бензин в огонь состоит в том, что если руководство настаивает на единственном пуле из-за его стоимости, я возражаю, что я шокирован тем, что компания стоит не больше, чем стоимость второго пула. Я видел, как руководители пытались сэкономить 5-10 тысяч долларов на проекте, и я звоню им, конечно, они меня ненавидят, но это факт, а не мнение. Взлом - это сценарий того, когда это произойдет, а не если это произойдет. Вы можете только спроектировать, чтобы он был более безопасным при правильном дизайне. Если эту компанию нельзя продать за 5-10 тысяч долларов, у нас возникнут проблемы. Вы никогда не должны экономить на безопасности или почему бы просто не публиковать все данные публично, так зачем пытаться защитить их, если это их проблема. Если вы еще этого не сделали, посмотрите NIST 800-53 R4, чтобы получить хорошее представление о структуре безопасности. Также CIS-CAT и их хороший сканер могут помочь стать более безопасными.