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

Question

Мы строим мультитенантную систему для сотен, а не тысяч отдельных арендаторов, с высокими требованиями к безопасности данных. На данный момент планируется перейти на:

• Изолированные базы данных (по одной на каждого арендатора)
• Веб-сайт и пул приложений (по одному на каждого арендатора), работающие под уникальным идентификатором, который является единственным идентификатором с доступом к соответствующей базе данных.
• Отдельная структура физического каталога для каждого арендатора

Очевидно, что развертывание обновлений должно быть полностью автоматизировано, чтобы быть в курсе этого, возможно, с использованием сценариев MS Deploy + PowerShell и развертывания одного клиента за раз.

Мы создаем кошмар обслуживания по этому маршруту? Существуют ли другие возможные конфигурации, которые мы должны оценивать в этом сценарии, которые могли бы минимизировать наши административные издержки без ущерба для аспекта безопасности?

Спасибо!

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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