如何利用MySQL加密函数保护Web网站敏感数据

如果您正在运行使用MySQL的Web应用程序，那么它把密码或者其他敏感信息保存在应用程序里的机会就很大。保护这些数据免受黑客或者窥探者的获取是一个令人关注的重要问题，因为您既不能让未经授权的人员使用或者破坏应用程序，同时还要保证您的竞争优势。幸运的是，MySQL带有很多设计用来提供这种类型安全的加密函数。本文概述了其中的一些函数，并说明了如何使用它们，以及它们能够提供的不同级别的安全。
双向加密
就让我们从最简单的加密开始：双向加密。在这里，一段数据通过一个密钥被加密，只能够由知道这个密钥的人来解密。MySQL有两个函数来支持这种类型的加密，分别叫做ENCODE()和DECODE()。下面是一个简单的实例：
mysql> INSERT INTO users (username, password) VALUES ('joe', ENCODE('guessme', 'abracadabra'));
Query OK, 1 row affected (0.14 sec)
其中，Joe的密码是guessme，它通过密钥abracadabra被加密。要注意的是，加密完的结果是一个二进制字符串，如下所示：
mysql> SELECT * FROM users WHERE username='joe';
+----------+----------+
| username | password |
+----------+----------+
| joe      | ¡?i??!?  |
+----------+----------+
1 row in set (0.02 sec)
abracadabra这个密钥对于恢复到原始的字符串至关重要。这个密钥必须被传递给DECODE()函数，以获得原始的、未加密的密码。下面就是它的使用方法：
mysql> SELECT DECODE(password, 'abracadabra') FROM users WHERE username='joe';
+---------------------------------+
| DECODE(password, 'abracadabra') |
+---------------------------------+
| guessme               |
+---------------------------------+
1 row in set (0.00 sec)
应该很容易就看到它在Web应用程序里是如何运行的——在验证用户登录的时候，DECODE()会用网站专用的密钥解开保存在数据库里的密码，并和用户输入的内容进行对比。假设您把PHP用作自己的脚本语言，那么可以像下面这样进行查询：
<?php
$query = "SELECT COUNT(*) FROM users WHERE username='$inputUser' AND DECODE(password, 'abracadabra') = '$inputPass'";?>
　　揭露 PHP 应用程序中出现的五个常见数据库问题 —— 包括数据库模式设计、数据库访问和使用数据库的业务逻辑代码 —— 以及它们的解决方案。
　　如果只有一种 方式使用数据库是正确的……
　　您可以用很多的方式创建数据库设计、数据库访问和基于数据库的 PHP 业务逻辑代码，但最终一般以错误告终。本文说明了数据库设计和访问数据库的 PHP 代码中出现的五个常见问题，以及在遇到这些问题时如何修复它们。
　　问题 1：直接使用 MySQL
　　一个常见问题是较老的 PHP 代码直接使用 mysql_ 函数来访问数据库。清单 1 展示了如何直接访问数据库。
　　
      交易日志（Transaction logs）是数据库结构中非常重要但又经常被忽略的部分。由于它并不像数据库中的schema那样活跃，因此很少有人关注交易日志。
　
      交易日志是针对数据库改变所做的记录，它可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中。对于任何每一个交易过程，交易日志都有非常全面的记录，根据这些记录可以将数据文件恢复成交易前的状态。从交易动作开始，交易日志就处于记录状态，交易过程中对数据库的任何操作都在记录范围，直到用户点击提交或后退后才结束记录。每个数据库都拥有至少一个交易日志以及一个数据文件。
　
      出于性能上的考虑，SQL Server将用户的改动存入缓存中，这些改变会立即写入交易日志，但不会立即写入数据文件。交易日志会通过一个标记点来确定某个交易是否已将缓存中的数据写入数据文件。当SQL Server重启后，它会查看日志中最新的标记点，并将这个标记点后面的交易记录抹去，因为这些交易记录并没有真正的将缓存中的数据写入数据文件。这可以防止那些中断的交易修改数据文件。
　
维护交易日志
      因为很多人经常遗忘交易日志，因此它也会给系统带来一些问题。随着系统的不断运行，日志记录的内容会越来越多，日志文件的体积也会越来越大，最终导致可用磁盘空间不足。除非日常工作中经常对日志进行清理，否则日志文件最终会侵占分区内的全部可用空间。日志的默认配置为不限容量，如果以这种配置工作，它就会不断膨胀，最终也会占据全部可用空间。这两种情况都会导致数据库停止工作。
　
      对交易日志的日常备份工作可以有效的防止日志文件过分消耗磁盘空间。备份过程会将日志中不再需要的部分截除。截除的方法是首先把旧记录标记为非活动状态，然后将新日志覆盖到旧日志的位置上，这样就可以防止交易日志的体积不断膨胀。如果无法对日志进行经常性的备份工作，最好将数据库设置为"简单恢复模式"。在这种模式下，系统会强制交易日志在每次记录标记点时，自动进行截除操作，以新日志覆盖旧日志。
　
      截除过程发生在备份或将旧标记点标为非活动状态时，它使得旧的交易记录可以被覆盖，但这并不会减少交易日志实际占用的磁盘空间。就算不再使用日志，它依然会占据一定的空间。因此在维护时，还需要对交易日志进行压缩。压缩交易日志的方法是删除非活动记录，从而减少日志文件所占用的物理硬盘空间。
blog 和 wiki 技术概述
从 20 世纪 90 年代末起（那时 Web 的繁荣正达到某个饱和点），一些用户开始编辑他们最喜欢的网站清单，这些网站符合一定的兴趣或主题。许多包含在用户清单上的条目都被加了评论，并标注了日期。这样的清单很快被称为 weblog 或 blog（博客），维护这样的 blog 的人被称为 blogger。后来，blog 开始变成文章的集合，通常以时间倒序的形式呈现，并与一个特定的主题相关。Wikipedia 对 blog 的定义如下：
早期的 weblog 仅仅是普通网站的手动更新组件。然而用于简化网络文章（以所谓时序性风格发表）生成及维护的工具的发展使得发表的过程在规模上更为庞大、技术含量更低并更加流行。最终导致了这种在线发布的类型，由此产生了今天的 blog。例如，使用一些基于浏览器的软件是当今 “blog” 的一种典型表现。可以通过专门的 blog 主机服务来托管 blog，blog 也能通过使用 blog 软件在一般的网络主机服务上运行。像其他媒体一样，blog 通常关注某一特定的主题，诸如食品、政治或本地新闻。一些 blog 以在线日记的形式存在。
在 blog 开始出现的同一段时间里，Ward Cunningham 发明了一项技术，这项技术允许任何人通过简单的编辑为 Web 页面做贡献。他将这项技术命名为 Wiki Wiki Web（来源于夏威夷语单词 wiki ，意为迅速 或快），后来这个名字被缩略到只有 wiki 。使用 wiki 的一项显著优势是用户可以当场向 Web 页面贡献内容。另外，因为编辑起来很简单，因而贡献内容时不需要任何特殊的软件。可以在 Wikipedia Web 的百科全书上找到更多关于 wiki 技术的信息，该网站本身就是使用 wiki 技术实现的。（参见 参考资料 上的链接）。
协作性应用程序
这就是 Web 2.0 的全部，尽管该术语出现才几乎一年的时间，但现在好像只有烹饪杂志还没有加入到讨论 Web 2.0 未来出路的行列中。自从出现了里程碑式的文章 “What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software”（此文由 Tim O'Reilly 在 2005 年 9 月所写，参见 参考资料 中的链接），对 Web 2.0 这一由该文创造的术语的赞同或反对之声一直没有间断。尽管如此，大多数人都认同了 Web 业已改变并进入了一个新的发展阶段，这是带其步入下一个逻辑高度的阶段。在 O'Reilly 的文章中，他阐释了任何 Web 2.0 公司必须具备的核心元素：
     一般情况下，SQL数据库的收缩并不能很大程度上减小数据库大小，其主要作用是收缩日志大小，应当定期进行此操作以免数据库日志过大。
      1、设置数据库模式为简单模式：打开SQL企业管理器，在控制台根目录中依次点开Microsoft SQL Server-->SQL Server组-->双击打开你的服务器-->双击打开数据库目录-->选择你的数据库名称（如论坛数据库Forum）-->然后点击右键选择属性-->选择选项-->在故障还原的模式中选择“简单”，然后按确定保存
      2、在当前数据库上点右键，看所有任务中的收缩数据库，一般里面的默认设置不用调整，直接点确定。
      3、收缩数据库完成后，建议将您的数据库属性重新设置为标准模式，操作方法同第一点，因为日志在一些异常情况下往往是恢复数据库的重要依据 。

      原文地址：http://www.111cn.net/?13542/action_viewspace_itemid_2928.html