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

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

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

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

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

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

Изменить Вероятно, я должен добавить, что мне нужно следующее:

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

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


architecture message-queue
person Matthew Savage    schedule 07.12.2010    source источник
comment
Чисто из интереса: спецификация PCI, с которой вы работаете, дает ли она какие-либо рекомендации, которые предлагают предпочтительные подходы (или те, которых следует избегать)?   -  person Adrian K    schedule 07.12.2010

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

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

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

Удачи

person sdg    schedule 07.12.2010
comment
Спасибо за мнение и ссылку на DayTrader — похоже, я могу покопаться в этом, чтобы получить представление о том, как что-то можно сделать. - person Matthew Savage; 18.01.2011

arrow_upward
0
arrow_downward

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

person mezmo    schedule 07.12.2010