我怎样才能在这台机器上提供良好的安全性以防止有人窃取数据库（通过本地访问 - 这台机器没有连接互联网）？

您可以做很多事情，但其中大部分不是直接的数据库编程。因为其中大部分都不是编程，所以它可能超出了您的范围。我不知道你被雇来做什么或你的背景是什么。如果这超出了范围，或者您对实施它感到不舒服，请让您的客户知道您的安全问题并建议他们聘请专家。

• 散列信用卡号码。

这取决于存储的信用卡号的用途。如果该号码仅用于唯一识别客户或购买，那么您实际上并不需要信用卡号码，只需一个与信用卡号码不匹配的值即可。如果是这种情况，则将信用卡号替换为信用卡号的哈希值。一些哈希算法：SHA1、MD5、RIPEMD-128/256。

• 删除信用卡号。

如果在某个时候不再需要信用卡号，但行中的其余数据是，请清除信用卡字段。如果您需要保留卡的某些指示，但不用于充电，则保留最后四位数字。

• 将数据库分成几部分。

如果您不需要同时访问整个事物，请将数据库分成您需要同时访问的部分。如果条目是独立的，则将其分成大小相等的部分。如果一件物品丢失或被盗，这将限制损坏。尝试一次加载尽可能少的部分。如果您的应用程序一次只能访问几个部分，这将减慢未经授权的用户的速度。

• 将钥匙存放在机器外。

有几种方法可以做到这一点。一种方法是使用加密令牌。有 USB 设备、智能卡设备和软件令牌。软件令牌可以存储在任何可移动媒体（CD-ROM、DVD、USB 闪存驱动器等）上。如果您确实将数据库分解为多个部分，您可能会考虑为某些部分使用不同的键，特别是如果某些部分的使用频率低于其他部分。

• “加盐”你的钥匙

salt是一个随机数，通常与散列密码条目一起使用，使访问密码数据库的攻击者难以快速找到数据库中的所有密码。PBKDF2 是一种使用盐和密码生成密钥的加密算法。为每一行生成一个盐（随机数）并将盐以明文形式存储在该行中。使用 PBKDF2 或其他合适的密钥生成算法为然后行生成密钥，并使用生成的密钥加密信用卡数据。目的是让攻击者读取数据库并生成一个新的密钥来解密每个信用卡号。

• 限制对系统的网络访问。

你说这台机器没有连接互联网，但我怀疑它仍然在内部网络上。使用系统上的防火墙来限制对两个或三个其他系统的网络访问。如果系统需要连接到两个或三个以上的其他系统，那么您可能需要考虑将数据库移动到不同的系统或为数据库创建一个专用系统。

• 限制用户访问系统。

配置安全策略，只允许少数关键用户登录机器。如果超过 8 人需要访问机器，这又应该是一个信号，表明数据库应该转移到另一个系统或它自己的专用系统。我对八个用户的快速了解：系统管理员、系统管理员候补、安全管理员、安全管理员候补、数据库管理员、数据库管理员候补、应用程序开发人员、应用程序开发人员候补。

• 限制对系统的物理访问。

这只是老式的上锁门。如果它需要在与其他系统共享的区域中，请尝试使其系统允许访问相同的用户。如果所有可用的只是壁橱或橱柜，请确保它具有唯一的钥匙。许多办公室锁和家具共享共同的钥匙。

• 限制哪些用户可以物理访问系统。

仅仅因为他们需要访问机器并不意味着他们需要物理访问系统。选择您将钥匙交给谁，并指示他们不要复制或将其借给其他任何人。

老实说，如果您将系统作为访问数据库运行，大概与前端在同一个系统上，那么您可以做的保护数据的工作是有限的，就像一个坚定的攻击者会做的那样能够访问加密密钥（例如，在使用时从内存中读取）。

也就是说，您也许可以做一些事情来提高标准。据我所见，在本地 Windows 机器上存储机密的一种选择是将它们放在注册表中，并且 ACL 保护注册表项。这可能会提供一些保护，以防有人访问系统的时间足够长以获取 .mdb 文件，但不足以在机器上彻底搜索密钥。

在这种情况下，另一个有价值的保护可能是在系统本身上实施全盘加密。这将有助于在整个设备被盗的情况下提供保护（假设它是一台在被盗时可能会关闭电源的台式机）。

以下是您可以考虑的一些步骤，这些步骤可能有助于减轻一些风险：

• 将数据库放在单独的机器上。那台单独的机器应该被锁定，以便它只运行支持数据库所需的服务。您可以建立防火墙，因此它只接受来自前端 Web 服务器的入站连接。

  另一种选择是在一个虚拟机中运行前端网络服务器，并在单独的虚拟机中运行数据库。

• 配置数据库以锁定它并减少某些安全风险（例如，配置它以便存储过程和 SQL 查询不能产生 shell 命令）。我不知道这在多大程度上适用于 Access 或 Access 推荐了哪些配置，但对于某些商业数据库来说，这是一个很好的强化步骤。

• 根据您的 Web 应用程序的设计和需求，它可能只需要将信用卡号写入数据库，而不需要读取它们。如果是这样，您可以配置数据库以强制执行此限制，或者使用细粒度访问控制，或者通过使用粗粒度访问控制和存储过程（使用表或用户粒度访问控制来阻止 Web 应用程序从直接访问信用卡号，然后创建一个存储过程，该存储过程能够写入一个新的信用卡号，授予 Web 应用程序调用存储过程的权限，并转换 Web 应用程序以使每一个涉及信用卡的 SQL 语句转换为使用此存储过程）。但是，这不太可能对 Web 应用程序进行微不足道的更改；

• 检查客户的代码以确保它使用准备好的语句（或等效语句）而不是字符串连接来构建 SQL 查询。如果它使用字符串连接，请考虑将其转换为使用准备好的语句。字符串连接带来了 SQL 注入漏洞的重大风险，并代表了一种次优的编码实践。

• 正如@Rory 建议的那样，您可以考虑对托管数据库的服务器使用全盘加密。但是，这可能只有适度的价值，因为您又回到了“我在哪里存储秘密密码？”的难题。您可以在启动时让服务器操作员在 FDE 密码中键入，但如果出现断电或服务器以其他方式重新启动，那么您的站点将关闭，直到服务器操作员亲自出现并输入 FDE 密码.

• 您可以将 PCI-DSS 合规性视为一种风险缓解措施。但是，这可能比客户准备的要贵。

在您的限制范围内，您可能无法完全解决整个信用卡数据库被盗的风险。充其量您可以部分减轻一些最高可能性的风险。

不要那样做。

选择一个支付提供商，例如 Stripe.com 或 Pay-pal，他们将为您处理订阅的重新计费。

亲：您不必费心保护数据库或花钱请别人来做这些细节。

缺点：如果您已经有商家帐户/网关，您最终可能会支付稍多的费用。但是，无论您付出多少额外费用，很有可能远低于数据泄露的责任，或者安全顾问的费用，甚至是 DW 建议的额外服务器的运营成本

您的公司/客户坚持为此使用 MS Access 的事实强烈表明他们没有资格做出 IT 安全决策。说真的，只是不要这样做。