Мультитенантный сайт с высокими требованиями к безопасности - возможные конфигурации?

То, что вы описываете, действительно было бы очень безопасным способом делать что-то, но похоже, что это повлечет за собой много накладных расходов. Одна вещь, которую следует учитывать, - это то, как поступать с логинами. Обязательно ли каждый пользователь указывать TenantId, UserName и Password? Или вы, возможно, собирались назначить каждому арендатору уникальный субдомен?

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

Исключением из этого правила, конечно же, являются такие сайты, как Google и Facebook, у которых слишком много пользователей и слишком много данных для традиционных реляционных баз данных. Но я считаю, что для 95% + сайтов эта модель может работать.

Что касается безопасности, вы можете добавить TenantId в каждую таблицу в своей базе данных и фильтровать по нему каждый запрос. Да, это нетривиально, но и процедуры обслуживания, которые вы описываете, также не описываются.

То, что вы описываете, действительно является способом создания нескольких клиентов, но, как уже упоминалось выше, это не то же самое, что и несколько клиентов. См. Статью http://www.ibm.com/developerworks/cloud/library/cl-multitenantsaas/index.html?ca=drs-, чтобы узнать о факторах, которые следует учитывать.

1. Пожалуйста, подумайте, сколько у вас будет клиентов и сколько пользователей в среднем будет у каждого арендатора.
2. Если у вас будет большое количество арендаторов, ваша модель может стать слишком дорогой в обслуживании. Десять тысяч арендаторов, каждый со своей собственной базой данных, структурами файловой системы и т. Д., Удачи.
3. Настоящая многопользовательская среда, такая как «Факторы успеха», SalesForce.com, NetSuite и т. Д., Успешна в первую очередь потому, что они многопользовательская, одна кодовая база, одна модель базы данных и т.д. Все арендаторы получают доступ к одной крупномасштабной системе и видят изолированные данные.
4. Альтернативой True Multi-Tenancy является виртуализация, а с виртуализацией, такой как VMWare, вы можете съесть свой пирог и съесть его. В каждом образе VMware есть все, что вам нужно, и его можно создать по запросу. Вы можете сделать одно обновление кода и развернуть его при создании экземпляра образа. Это будет намного более рентабельно, чем разрозненные хранилища, которые вы себе представляете сейчас, но в меньшей степени, чем True Multi-Tenancy.

Есть несколько способов уберечь клиента A от данных клиента B.

1. Siloing, как вы описали - машины, обслуживающие клиента B, отклоняют все сетевые подключения от машин, выделенных другим клиентам и иметь отдельные физические диски, журналы и т. д. Здесь вас беспокоят нулевые дни, связанные с сетевыми сообщениями и троянами, которые пытаются заразить обновления вашего кода, и любое устройство, которое может подслушивать сетевые сообщения между машинами. в бункере.
2. Шифрование всех хранимых данных - вместо отдельных машин вы шифруете все данные. Обычно для этого по-прежнему требуются изолированные базы данных, но не файловые системы или журналы. Нулевые дни, о которых вы беспокоитесь, - это дни 1 плюс все, что связано с границами процессов, кешами памяти, блокировкой файловой системы и всем, что влияет на взаимодействие с хранилищем ключей клиента. У меня нет большого опыта в этом, но я скептически отношусь к тому, что это административная победа.
3. Анализ информационных потоков - убедитесь, что каждая часть данных помечена. Все запросы от программы, которая обслуживает запрос для клиента A, помечены как A, и все программы, которые обслуживают запросы для клиента A, принимают только сообщения, отмеченные A, а не B. Это можно использовать для глубокой защиты поверх других. схемы, поскольку он сам по себе не защищает системы хранения.