лучший дизайн взаимодействия родительского процесса с базой данных

Question

Предположим, у нас есть родительский процесс, A. A получает входные данные username и password и ищет их в базе данных AllUsers, чтобы убедиться в правильности комбинации username/password. A затем запускает новый дочерний процесс B и передает его username/password. B требуется дополнительная информация из базы данных, например, age и nickname.

пользователя.

Если A разрешен только доступ к базе данных:

• A получает всю информацию от базы данных и передает все это B через строки командной строки при создании новый B. Даже если A не заботиться о age и nickname. B будет анализировать строки, чтобы захватить поля.
• A только проходит username/password до B, а A имеет WCF услуги, которые позволяют B вызвать услуги, что делает A доступ к базы данных и вернуть информацию в B.

Если A и B оба имеют доступ к базе данных:

• A только руки B username/password и позволяет B получить доступ к базе данных, чтобы он мог получить age/nickname сама.

Если у нас есть несколько баз данных:

• A имеет доступ только к AllUsers база данных. Но у нас также есть база данных для каждого пользователя. Итак, 10000 пользователей = 10000 баз данных. B доступ только одна пользовательская база данных для одного пользователь заботится о нем.

Имейте в виду, что будет только один A, но могут быть сотни или тысячи B процессов. Я хочу, чтобы нагрузка была как можно более равномерной, т. Е. Я не хочу, чтобы A являлось узким местом, если тысячи B должны с ним разговаривать. Но я также обеспокоен тем, что два процесса могут обращаться к одной и той же базе данных одновременно, кажется, что это может вызвать медленный доступ или повреждение данных.

Это мои идеи о том, как это сделать. Какой из них лучше? Или есть лучший подход?

Answer 1

По моему мнению, имя пользователя и пароль не должны передаваться никакими средствами, если это возможно, и кажется, что это довольно легко избежать в вашем сценарии. Прежде всего, ни у одного процесса не должно быть полного доступа к базе данных AllUsers, поскольку она хранит конфиденциальные данные. Хорошим подходом будет использование хранимой процедуры, к которой имеет доступ только A, для передачи имени пользователя и пароля (хеша) в качестве параметров. Таким образом, если процесс A скомпрометирован, злоумышленник не может просто получить список имен пользователей и паролей. Он / она может попытаться использовать грубую силу, но с достаточно надежными паролями (и надлежащим мониторингом) у вас должно быть более чем достаточно времени, чтобы обнаружить событие. Если они верны, хранимая процедура должна вернуть криптографически безопасный токен случайного сеанса. Это должна быть единственная информация, которую нужно передать, и то, как вы это делаете (WCF, аргумент командной строки и т. Д.), Не важно, выбирайте то, что вам нравится. Процесс B должен иметь возможность запрашивать любую необходимую ему информацию через хранимые процедуры, которые принимают токен в качестве параметра и возвращают отфильтрованные результаты в зависимости от ваших потребностей. Например, процесс B должен иметь возможность читать только собственную строку пользователя, но без пароля. Добавьте некоторые завершающие штрихи, например, работу, чтобы очистить старые сессии, и у вас будет дизайн, который будет безопасным и простым в обслуживании.

Answer 2

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

Я бы избегал иметь базу данных для каждого пользователя, так как вы, вероятно, собираетесь запускать много, если не все экземпляры на одном компьютере.

Я бы предложил почитать о возможностях базы данных и ее масштабировании.

Надеюсь, это поможет.