数据库加密越来越常见，但与此同时还是有一些因缺乏加密而造成重要数据泄漏的情况。姑且认为你已经部署了所有的安全措施，并且开发进程中的每一步都经过深思熟虑;开发出的web应用程序也有足够的能力对抗跨站脚本攻击、SQL注入和其他常见的web漏洞;并且熟知所有的安全计划(OWASP)条款，也知道对所有的传输数据、敏感数据库、数据库中的敏感字段加密。但接下来你会将加密密钥放在哪里呢?有没有使用硬件安全模块(HSM)?大多数企业都没有使用HSM，其实为了安全他们应该都要使用的。存储明文密码就相当于将钥匙放在门垫上，完全没有安全意识。
Web应用程序框架
让我们先来恶补一下常见的Web应用程序框架。在一个典型的数据库加密Web应用程序中，应用程序会直接将密钥存储在服务器的某个角落。这样就被置于了逆向工程攻击之列，并且还会造成一些操作性的安全问题。这就是不使用HSM的后果，所以各位程序猿们赶紧使用HSM吧。
科普：什么是HSM?
一个HSM本质上就是一个协同处理器。就计算机架构而言，HSM可能含有冯诺依曼机的所有组件——包括储存、内存以及处理能力。计算机采用二进制算法和内存贮器后，指令和数据便可以一起存放在存贮器中，并可作同样处理，这样，不仅可以使计算机的结构大大简化，而且为实现运算控制自动化和提高运算速度提供了良好的条件。
HSM为主机本身提供专用离线加密服务。
HSM致力于处理加密和保护加密进程，服务器内存不能访问重要数据，用户也无法看到明文密钥，因此可以保证应用程序和加密数据中间存在一个可信任的路径。这个时候你可能会想到还有可能被物理入侵呢，其实不用担心，HSM拥有一个防干扰的密封圈，可阻止攻击者的电子窃听和无线电监测。
HSM可以用来防范什么?
HSM可以防止攻击者从一个敏感数据库中盗取信息。如果攻击者获得了应用服务器(储存了明文密钥)的访问特权，密码可以重新找回。无论密码有多复杂，哪怕是被编译、被打包或者被更改，它也能给逆向工程了。从安全工程的角度来看，这不是一种最佳的方式。
从操作安全的角度看，让别人看到敏感、加密数据都是不明智的。其中包括终端用户，还有开发团队、系统管理员以及数据库管理员。从系统角度看，你同样不希望看到敏感数据从产品服务器传播到工作服务器或开发服务器上。如果你的数据库含有敏感数据，最好不要让任何人访问它。
HSM是如何实施的?
因为HSM是由一个应用程序开发团队部署，它是属于程序安全领域，而不是基础设施安全。硬件安全模块能够被应用程序用于建立一个安全、可靠的通路。应用程序必须使用HSM供应商提供的应用程序编程接口(API)建立专门执行加密的操作。这些API包括常见的加密功能，如对称算法、非对称算法和解密操作，散列消息身份验证代码，密码信息身份验证代码，RSA，数字签名算法，Diffie-Hellman密钥交换，随机数生成，素数生成以及格式保存生成。HSM程序编程接口可以由特定的供应商提供，比如IBM发布的常见加密体系结构，或遵循公共标准，如PKCS 11。显然，有人会需要做一些谨慎的购物来确保适当的功能可用。
遵从FIPS-140-2标准
然而HSM不受PCI合规的托管，它们为大多数支付方案使用。当前HSM的管理标准为来自美国国家标准和技术委员会，称为美国联邦信息处理标准(缩写：FIPS-140-2)。事实上，若你需要储存信用卡数据，你非常应该使用HSM。2009年PCI安全需求查看请点这里，2012年更新内容可以在这里查看。
当遵守FIPS-140-2标准的HSM被广泛运用于支付行业中，所有行业数据库的安全系数都得到了大幅提高。而需要牢记的是你的医疗记录对网络犯罪而言比你的信用卡更具有价值，所以请保持警惕。
怎么开始使用加密?
幸运的是，HSM认证产品拥有一个“票据交换所”，同时还有很多关于硬件安全模型的讨论，包括专为基于网络模块储存系统及其他定制的设计。然而，本文的目的是为HSM做一个高级的介绍，同时鼓励用户去SANS研究所和Stack Exchange(一系列问答网站，每一个网站包含不同领域的问题)做一些深入的阅读。
