Трябва ли да използвам опашка за това?

Работя върху приложение, което се занимава с „чувствителни“ данни (известни още като номера на кредитни карти) и за да постигнем съответствие с PCI, трябва да гарантираме, че нашата база данни е отделна от нашите публични сървъри.

За да влязат данните и да бъдат съхранени, трябва да има нещо по средата - не искам данните да се записват или четат директно от уеб/приложните сървъри - така че се чудех дали опашка/работник архитектурата може да е подходяща.

Основният поток ще бъде:

  1. Данни от клиента -> Изпрати до API
  2. API сървърът поставя данни в обект „заявка“ -> Поставяне на опашка
  3. Работник (във „вътрешна“ мрежа) приема заявка, пише в DB, ​​върши работа, актуализира DB, след което поставя в опашка обект „отговор“
  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

Въпреки че не мога да кажа, че трябва, със сигурност звучи, че можете да използвате такъв за добър ефект.

Опашката ще ви даде ниво на изолация между компонентите. Ако това е необходимо физическо изискване за преминаване на вашето сертифициране, тогава можете да покажете, че двете машини са свързани чрез конкретна мрежа и само определени портове са отворени и т.н.

Устойчивостта е обща характеристика на софтуера за опашки, както и сигурността на ниво транспорт по подобен начин.

Скоростта е по-размита грижа. Като цяло съобщенията в система за опашка, независимо дали са търговски или с отворен код (като оставим само roll-your-own) отнемат само милисекунди за предаване с издръжливост и други подобни - добавете малко допълнителни разходи за криптиране. Ако приемем правилната детайлност на вашите съобщения (т.е. те не са "твърде малки" и протоколът не е "твърде разговорлив"), тогава трябва да се справите добре.

Има много търговски и системи за съобщения и опашки с отворен код, 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