Некоторые аспекты разработки платежных систем. Часть I. Трехзвенка без трехзвенки

Мир тебе, %username%!

В этой серии постов я хочу рассказать о некоторых аспектах реализации платежной системы(а если повезет и двух), реально имевшей честь работать с середины 2000х в одном из городов нашей необъятной родины.
Что вообще такое ПС, и по каким принципам она должна работать? Я, как и заказчик, имел об этом представление лишь как пользователь WebMoney и платежных терминалов. Тем не менее, желание+деньги сделали своё дело и разработка началась.

Для начала, что вообще понималось под платежной системой и с чего началась разработка.
UPD:
Вторая часть!

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

Веб сервер представлял из себя FreeBSD с Apache, БД сервер на Windows с MySQL.
К сожалению Postgre в то время был (да и остается) для меня дремучим лесом, а к MS SQL Server мы напрямую из под FreeBSD подключаться не умели. К тому же планировалось написание внешнего модуля для СУБД, отвечающего за часть с криптографией, что поставило точку в выборе ОС для неё.

Ключевыми вопросами для меня при разработке были вопросы безопасности, т.к. работала система с какими никакими, а все таки деньгами.
Почти сразу родилась следующая простая схема работы WEB server<->DB server:

• Web сервер имеет доступ лишь к разрешенным хранимым процедурам в одной отдельно взятой базе. Никаких SELECT\INSERT\DELETE. Лишь вызов нескольких хранимок и всё.
• Все доступные web серверу хранимки, кроме Auth(login, pass), принимают в качестве первого параметра ID сессии (и первым делом проверяют её живучесть), которая возвращается в Auth как hash(random()) и живет лишь несколько минут после неактивности.

Таким образом

• Мы на 100% защитились от SQL inject
• На 99% защитились от злоумышленника в случае полной компрометации web сервера (1% оставим на дыры в MySQL и фаерволе). Можно делать для аккаунта веб сервера логин\пароль на БД web/qwerty и спать спокойно. Хакер неудачник будет видеть лишь пустые результаты выполнения хранимок
• Вся логика системы реализована в хранимках, по сути web сервер лишь вызывает их и показывает оформленный результат пользователю.

Со стороны юзера трафик защищался SSLем с купленным у VeriSign сертификатом.

В первом приближении получилась безопасная «трехзвенка» без «трехзвенки», которой было довольно удобно рулить и которая отвечала неплохим, на мой взгляд, критериям безопасности. Проблемы были лишь когда добавлялась новая хранимка и я по запарке забывал выставить для неё права аккаунту веб сервера )

Предстояло продумать структуру бд(неинтересно) и систему защиты виртуальных кошельков.

Если хабрасообществу будет интересно, в следующих частях я расскажу о:

• Защите клиента, в частности о системе ЭЦП с использованием эллиптических кривых и прикручиванием всего этого чуда к MySQL.
• Прообразе «фермы платежных модулей».
• Разработке с нуля платежной системы для терминалов самообслуживания.