Должен ли я использовать очередь для этого ...?

Question

Я работаю над приложением, которое имеет дело с «чувствительными» данными (например, номерами кредитных карт), и для достижения PCI Compliance нам необходимо убедиться, что наша база данных отделена от наших общедоступных серверов.

Для того, чтобы данные поступали и хранились, должно быть что-то среднее - я не хочу, чтобы данные записывались или читались непосредственно с веб-серверов приложений, поэтому мне было интересно, возможно, подходит архитектура очереди/рабочего.

Основной поток будет:

1. данных от клиента -> Отправить API
2. API сервера помещает данные в 'запрос' объект -> Ставить
3. рабочий (на 'внутренней' сети) поднимает запрос, пишет в БД, делает работу, обновление БД, а затем ставит в очередь на «ответ» объект
4. API-сервер получает этот объект ответа отправляет обратно в ответ на клиент

По существу я надеюсь на что-то, где данные вернутся к одному и тому же запросу, поэтому весь процесс может быть выполнен по одному запросу, но это, похоже, противоречит асинхронному характеру очередей сообщений и может быть больше подходит к «веб-сервиса», действующей в качестве строгого «протокола» сам по себе ...

Edit я должен proabably добавить, что необходимо следующее:

• Долговечность - если очередь или что-то " сбой "он должен иметь возможность восстанавливать« поставленные в очередь »позиции
• Безопасность - конфиденциальные данные должны быть протестами cted - транспорт прекрасен, потому что мы можем что-то использовать на транспортном уровне (TLS, SSL, IPSec), однако хранение номеров карт на стороне отправителя (общедоступной сети) не является идеальным ...
• Скорость - конечно.

Итак, я об этом неправильно?

Answer 1

Пока я не могу сказать, что вы должны , это, конечно, звучит, как вы могли использовать один для хорошего эффекта.

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

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

Скорость является более проблематичной проблемой. В общем, сообщения в системе очередей, коммерческие или с открытым исходным кодом (оставляя в одиночку roll-your-own), занимают всего миллисекунды для передачи с долговечностью и т. П. - добавьте немного дополнительных накладных расходов для шифрования. Предполагая правильную детализацию ваших сообщений (т. Е. Они не «слишком малы», а протокол не «слишком болтливый»), тогда вы должны делать все в порядке.

Существует много коммерческих и открытых систем сообщений и очередей, Google - ваш друг, чтобы их найти.

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

Good Luck

Answer 2

я мог бы быть недопониманием вопроса, а варить его вниз, я думаю, вы могли бы быть overthinking вопроса. Есть способы открыть сервер веб-приложений в Интернете, сохраняя безопасность базы данных за брандмауэром, используя какой-то SOA, может увеличить эту изоляцию и, надеюсь, уменьшить вероятность какой-либо атаки на SQL-инъекцию, но это не автоматический. Представляя очередь, которая может быть настроена на долговечность, дает вам желаемое восстановление, а некоторые могут быть сконфигурированы так, чтобы быть синхронными, чтобы соответствовать «одному шагу» или, по крайней мере, выполнять одноступенчатую операцию. Но дело в том, что эта долговечность добавляет еще одну «уязвимость системы безопасности», поскольку информация в очереди записывается где-то, как правило, либо в базе данных, либо в файловой системе до тех пор, пока транзакция не будет выполнена. Таким образом, в вашей ситуации, где произошел сбой, да, его можно восстановить, но его можно было бы увидеть кем-то внутри предприятия, имеющим доступ к области файловой системы, где эта информация временно сохраняется.