Как сделать безопасную базу с цифровыми ключами активации в веб?

Question

[DJDiM]

Дайте, пожалуйста, инфу, в каком направление смотреть по описанному ниже вопросу.
Небольшая фирма занимается оптовой продажей ключей активации для видео игр и софта (Windows и т.д.), всё в цифре. Чтобы как-то это упорядочить, как сумел я сделал базу для всех ключей на MS Access. Есть статусы, наименования, названия инвойсов от поставщиков, даты покупки и т.д., но по факту пользоваться ей могу только я, ибо access сложен. Расшарил работникам доступ к базе через Google Drive, они её за пару дней умудрились поломать. То ли проблема с синхронизацией, то ли они что-то натворили не то. Хорошо, что бэкап был.
Сейчас мне приходится тратить выгрузку на выдачу или отправку покупателям ключей вручную. Хотелось бы как-то дать доступ к ключам своим коллегам, чтобы они могли выгружать нужные им ключи, и менять статусы. Очень хотел бы держать базу онлайн в виде Web ресурса, но боюсь за безопасность. В перспективе эту базу хотел бы подключить к собственному магазину. Я не программист, и не знаю, как защитить ключи, на случай взлома сайта или базы. При том, что доступ к сайту я понимаю, что можно ограничить двухфакторкой например. А вот как скрыть ключи в базе, если злоумышленники получать к ней доступ?
В теории, что можно сделать, куда вообще смотреть? Я понимаю, что взломать можно всё, вопрос, как минимизировать риски, и не влететь на ценник разработки решения для банка :)

Answer 1

[Radjah]

> как сумел я сделал базу для всех ключей на MS Access
Если не сильно замутные отношения в базе, то можно перенести её на MySQL/MariaDB. PostgreSQL я не знаю, потому и не говорю за неё. На неё натянуть какой-нибудь движок или скрипт для добавления/удаления/редактирования и дать к нему доступ сотрудникам.

ИМХО за небольшую деньгу программиста для этого дела найти не особо сложно. Только совсем экономить не надо.

Comments

[DJDiM]

А как ключи спятать? Я думал, может какое-то шифрование можно сделать в самой базе, как для паролей? Только не понятно, как потом их расшифровывать, при выгрузке.

[Radjah]

DJDiM, а зачем их прятать? Есть база, есть ПО, которое с ней работает, есть ограниченный круг лиц, который может работать с этим ПО.
По запросу из массива берётся ключ, передаётся покупателю и помечается как проданный.
Вам правильно советуют нанять программиста, который все ваши хотелки реализует.

[Radjah]

John Smith, не надо это делать через Access. Для многопользовательской базы есть клиент-серверное ПО с транзакциями, блокировками и бекапами.

> там была куча программеров, которые это все внедряли.
Чтобы натянуть сову на глобус, нужно приложить много усилий. :)

Answer 2

[rPman]

Судя по всему вы очень узкий специалист,.. если вариант с нанять знающего не катит, копайте сами.
Настоятельно советую выкинуть на помойку ms access и больше не вспоминайте это, когда то эта среда была одним из лидеров, но сейчас безнадежно устарела. В принципе можно использовать само хранилище mdb по назначению, без UI, но сейчас есть более удобный и быстрый инструмент sqlite

Общепринятые практики, которые можно использовать в вашем случае:
* 'разделяйте и властвуйте'
Отделите хранение данных от интерфейса работы с ней, это решит много проблем, уменьшит возможное количество ошибок и облегчит поддержку системы, так как для нее вам не потребуется на столько узкий специалист.

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

* денежные задачи в идеале тоже отделить в отдельную систему
или хотя бы реализовать ее на базе базы данных и ее встроенных процедурах, если они есть. Работа с платежами должна проходить через специально разрботанную прослойку, не подразумевающую что могут идти неправильные операции, а сама система должна заниматься этим контролем (нельзя купить несуществующий товар, нельзя продать один товар дважды и т.п.), хорошей практикой является построение такой системой таким образом чтобы итоговое суммирование 'денег' было нулевым т.е. заводить специальные 'системные' аккаунты, которые должны контролировать пополнения и вывод.

* задайтесь вопросом что есть надежность и безопасность, эти понятия очень много в себя включают

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