我有一个要求（待定），允许用户购买“积分”，然后将这些积分用于真实商品或服务。
这是我第一次在应用程序中执行此操作，我担心它会在我的数据库背面绘制目标。黑客可以（理论上）改变用户拥有的信用额度，然后“花”这些信用额，或将其转换为现金。
我正在用ruby / rails构建解决方案，但我并不局限于这种技术。如果它更实用，我甚至可以使用外部提供商。
有没有人对如何做到这一点有任何建议？你会加密你的数据库吗？那就够了吗？
答案 0 :(得分：1)
要考虑很多不同的事情。在涉及安全问题时，从来没有银弹（任何暗示可能销售蛇油的人）;相反，安全性通常涉及许多不同的步骤来缓解和管理风险以及冗余的保护层，以便当这些层的某些子集由于某种原因而失败时，仍然可以保护它们。
在存储货币交易方面，通常需要遵循一些法律规定，因此我建议除了其他安全措施之外，还要咨询这些规则。在加密数据库方面，有许多不同的方法可以应用加密...可以使用不同的密钥对数据库作为整体或单个数据行进行加密。如果您只是整体加密数据库，如果有人可以访问密钥，它将无法为您提供太多保护（这也会引起谁拥有密钥，存储位置等问题？）。除了数据库本身之外，您可能需要的是一个只写的事务日志，它具有某种校验和，以便您可以确保其真实性，为您提供独立于数据库的审计跟踪（以及如果发生某种违规，可以重建数据库）。此外，您还需要确保只有授权的应用程序（例如您的前端服务器的生产实例）才能与数据库进行通信和解密（并确保只有极少数您信任的人可以部署这些应用程序的新版本，这样任何人都不能随意部署滥用该访问权限的恶意版本。如果可以使用不同的密钥独立加密各个行（例如，使用从用户的登录凭据派生的密钥材料加密每个用户的每一行），那么这是非常可取的（尽管这并不总是可行，例如，如果你即使用户没有主动与您的应用程序交互，也需要能够处理该行）。我确信还有其他一些我没有想过的事情，这就是为什么你还要经常进行渗透测试来检查任何漏洞（并且不仅修复你发现的任何东西，而且还用它来通知您可以采用的项目或流程，以防止将来出现类似的漏洞。
除了安全考虑因素外，货币交易是少数几个“最终一致性”无效的案例之一;你需要确保在编程时要小心，以便使事务处于原子状态。也就是说，你不希望信用数量在与美元的分散相差一个单独的时间步减少，因为这将允许相同的信用被花费两次......你会想要在你的编码中非常小心信用减少和美元增加（反之亦然）同时发生。由于这个原因和其他原因，彻底的测试和良好的代码审查实践是一个好主意。