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

Question

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

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

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

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

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

Редактировать Я должен добавить, что мне требуется следующее:

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

Итак, я поступаю неправильно?

Answer 1

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

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

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

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

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

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

Удачи

Answer 2

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