TechLead. Допомагаю рости будь-яким командам.
Користуйтеся ключами RSA, у кожного користувача своя пара ключів. Один (публічний) передається на сервер, інший (приватний) залишається у користувача. Коли робиться транзакція, наприклад покупка, то на сервер повинна надходити інформація:- ідентифікатор покупця
- номер рахунку покупця
- ідентифікатор продавця
- номер рахунку продавця
- ідентифікатор покупки
- валюта
- точна сума покупки
- точний час транзаціі в Таймзона UTC
До кожної транзакції повинен додаватися відбиток від всіх цих значень, підписаний з використанням приватного ключа покупця. На сервері цей відбиток повинен перевірятися з використанням публічного ключа того ж користувача. Публічний ключ можна зберігати в базі же. Він тільки для звірки.
Щоб виконати транзакцію (покупку), потрібно перевірити, чи вистачає коштів на балансі користувача-покупця. Для цього потрібно вилучити з бази всі транзакції користувача-покупця, по кожній транзакції провести перевірку відбитка і підсумувати ті, у яких відбиток коректний.
Перевіряйте час транзакцій. У кожного покупця все транзакції повинні бути строго хронологічними. Не повинно бути щоб покупка N + 1 була ДО покупки N.
Це обчислюється довго. Щоб прискорити обчислення залишку, можна ввести спеціальний тип транзакції "стан на початок місяця". Його повинні виконувати сторонній довірений сервер, який має свою спеціальну пару ключів. Тоді поточний баланс = останній залишок на початок місяця + всі надходження - все оплати. Обчислюється значно швидше.
Якщо зловмисник зламає базу даних, то внесені записів буде чрезивичайно скрутним, тому що підробити відбиток транзакції буде неможливо. Слабка ланка - можна просто вивантажити базу або таблицю в файл і потім дропнуть таблицю або базу і шантажувати вас втраченими даними. Щоб виключити таке, забороніть користувачам (не покупцям, які а тим, які підключаються до бази) робити DROP TABLE / DATABASE. Ще робіть резервні копії. Ще тримайте дзеркало бази даних.
Все що я описав, буде марно, якщо зловмисник замінить вихідний код платіжного сервера, так як він зможе просто вирубати всі перевірки на відбитки. Тому платіжний сервер не повинен бути скриптовою. Тобто не PHP, node, Python, Ruby. Це повинен бути компільований код. З цифровим підписом. Сервер не повинен виконувати додатки з відсутньою або неправильної цифровим підписом.
Але це не заважає підмінити список довірених центрів сертифікації на сервері, щоб запустити підроблене додаток замість платіжного сервера. Тому на стороні СУБД потрібно реалізувати механізм, який не дає підключитися до бази будь-якого додатка. Ця програма має мати спеціальний механізм доступу. Обмеження по IP, спеціальні заголовки, особлива сесія. Значить це не MySQL і, швидше за все, не PostgreSQL.
Ще про якомусь головняка розповісти або вже досить?
Фахівці з WebMoney, PayPal, Yandex.Деньги і онлайн-банків зараз не приховуючи усмішки дивляться на мій алгоритм. Привіт вам всім, друзі!
Щодо реалізації на PHP. Два сервера з запитами через AJAX не зроблять сервер надійніше, тому що все можна підробити в браузері.
Потрібно запобігти доступ користувача до сервера. В Інтернет величезна кількість статей на цю тему. Я боюся, що повний список засобів запобігання доступу я просто не згадаю. У будь-якому випадку, способів злому більше, ніж методів захисту в PHP.
І ось списочок способів зниження ймовірності проникнення і нанесення непоправної шкоди:
стан серверів- Тримай сервера в актуальному стані, стеж за знайденими уразливими, оновлюй серверні додатки
- Роби бакапи файлів і баз даних, тримай дзеркальну базу даних; в разі біди - використовуй копію
- Використовуй віртуальні машини, роби періодично знімки, а в разі злому Відновлюй машини зі знімків
- Більше не пригадаю. Тримай адміна під рукою.
- Якщо все додаток на одному сервісі, то всі внутрішні служби (mysql, memcached, raddis, rabbit) повинні слухати тільки інтерфейс 127.0.0.1. (Habrahabr.ru/post/212265)
- Якщо програма включає кілька серверів (окремо база, окремо PHP), тобто являє собою кластер, то служби повинні слухати тільки ті IP, які відносяться до кластеру.
- Зміни стандартні порти всіх сервісів
- Користувачеві UNIX від якого працює PHP-FPM / NGINX / APACHE, повинні бути відкриті для запису тільки кілька директорій (upload, логи, тимчасові файли), а для виконання - взагалі нічого не можна.
- Користувачеві бази даних не повинні бути доступні деструктивні і небезпечні операції (DROP / ALTER / CREATE PROCEDURE), може бути навіть для INSERT / UPDATE / DELETE в даних з фінансів використовувати інший аккант в базі даних
nezzard. якщо ти маєш на увазі, що він отримає доступ до бази (логін, пароль), то який-небудь хеш можна звичайно придумати, по будь-яким декількох полях. Але простіше закрити доступ до бази "ззовні" (обмежити доступ користувача тільки з локалхоста) і ніяких проблем. Ну, а якщо він отримає доступ з твого сервера, значить у нього всього скоріше буде доступ до файлів.
Vitaliy Orlov. Спасибі, а якщо такий варіант. Ведеться облік в двох базах на різних серверах. Висновок проводитися на іншому сервері, тобто при натисканні кнопки "Вивести" йде аякс запит на інший сервер, де йде перевірка двох таблиць на різних серверах, якщо все ок, виводить. Що на рахунок цього скажете.
