安全审计打造固若金汤的数据堡垒.docx

安全审计打造固若金汤的数据堡垒.docx

《安全审计打造固若金汤的数据堡垒.docx》由会员分享，可在线阅读，更多相关《安全审计打造固若金汤的数据堡垒.docx（11页珍藏版）》请在冰豆网上搜索。

安全审计打造固若金汤的数据堡垒

安全审计打造固若金汤的数据堡垒

来源：

IT168网

     众所周知，数据库系统功能强大而丰富，因而，对于一个数据库环境而言，我们可以生成很多类型的审计记录。

当然，这并不意味着本文所涉及到的所有审计类型都适合读者你，但是，知道有哪些审计类型以及如何实施这些审计有助于你满足合规需求。

　　要实施完善的数据库审计，必须理解的一个关键问题是需求，从而知道可以使用哪些审计类型来满足自己的需求。

本文可作为你实施数据库审计的一个参考。

　　审计数据库的登入和登出

　　在你要进入一家公司会晤某人的时候，一般需要在前台进行登记。

这样做可确保公司完整的记录进入公司的任何人，在出现问题时，或在追踪和调查“这事儿是谁干的?

”时，这种登录很有用处。

这种日志通常会记录来客是谁、何时进入、何时离开。

同样的过程也适用于数据库，多数环境中所需要的首要审计就是完整的记录哪些人曾登入过数据库。

　　对于这类审计，你需要记录两类事件：

登入事件和登出事件。

对于每一个事件，你都需要保存登录名和时间，但你还应该考虑记录附加信息。

这包括发起连接的客户端的IP地址，以及用于初始化连接的程序。

例如，在Oracle环境中，你可能想知道该连接是否由SQLPlus等初始化。

　　除了这两类事件，你还应当记录所有失败的登录企图。

事实上，从安全的观点来看，失败的登录事件甚至可能比成功的登录更重要。

记录失败的登录企图不仅是为了审计和合规目的，而且可作为警告和停用某个账户的基础。

　　虽然你可将这三类事件放在同样的文件或表格中，但你可能会以不同的方式进行报告。

成功的登录和登出报告不是多数人愿意关注的问题，除非要进行某种调查，因为这些日志反映了正常的操作。

除此之外，还有一种例外情况，即比较不同时期的文件，看其是不是发生了改变。

然而，过多的失败登录肯定是一个令人感兴趣的安全报告，而且许多人会根据如下这几个方面定期地查看这些失败的登录企图：

　　用户名

　　连接失败的客户端IP地址

　　源程序

　　时间和日期

　　例如，图一展示了两个视图，这两个视图根据两个方面进行了分类总结，一是根据登录名（上图的左侧），二是根据显示失败登录的详细视图的报告（包括登录名、源IP地址、连接到哪个数据库服务器、通信类型）。

　　可使用数据库的特性或使用外部的数据库安全方案来审计登入和登出活动。

所有的数据库厂商都支持这种基本的审计功能，而且因为这些事件的数量是很小的（至少在与审计实际的SQL调用时所得到的事件数量相比时是这样的），所以数据库在执行这种审计时所遭受的性能损失很少。

　　正如在插入或更新时，Oracle触发器会启动一样，系统级触发器会针对特定的系统事件（如登入、登出和DDL执行）而执行。

下面如何实施这种审计：

　　首先，创建一个你用来保存这种信息的表：

　　下一步，创建一个在发生新登入时可执行的触发器：

　　多数数据在用户登入时被记载，但在用户登出时，需要用触发器来记载其登出日期和时间，代码如下：

　　在Oracle环境中这样做就可以了。

如果你运行的是Sybase环境，问题就更简单了，因为你可以用下面的命令审计对所有数据库的所有访问：

众所周知，数据库系统功能强大而丰富，因而，对于一个数据库环境而言，我们可以生成很多类型的审计记录。

当然，这并不意味着本文所涉及到的所有审计类型都适合读者你，但是，知道有哪些审计类型以及如何实施这些审计有助于你满足合规需求。

　　要实施完善的数据库审计，必须理解的一个关键问题是需求，从而知道可以使用哪些审计类型来满足自己的需求。

本文可作为你实施数据库审计的一个参考。

　　审计数据库的登入和登出

　　在你要进入一家公司会晤某人的时候，一般需要在前台进行登记。

这样做可确保公司完整的记录进入公司的任何人，在出现问题时，或在追踪和调查“这事儿是谁干的?

”时，这种登录很有用处。

这种日志通常会记录来客是谁、何时进入、何时离开。

同样的过程也适用于数据库，多数环境中所需要的首要审计就是完整的记录哪些人曾登入过数据库。

　　对于这类审计，你需要记录两类事件：

登入事件和登出事件。

对于每一个事件，你都需要保存登录名和时间，但你还应该考虑记录附加信息。

这包括发起连接的客户端的IP地址，以及用于初始化连接的程序。

例如，在Oracle环境中，你可能想知道该连接是否由SQLPlus等初始化。

　　除了这两类事件，你还应当记录所有失败的登录企图。

事实上，从安全的观点来看，失败的登录事件甚至可能比成功的登录更重要。

记录失败的登录企图不仅是为了审计和合规目的，而且可作为警告和停用某个账户的基础。

　　虽然你可将这三类事件放在同样的文件或表格中，但你可能会以不同的方式进行报告。

成功的登录和登出报告不是多数人愿意关注的问题，除非要进行某种调查，因为这些日志反映了正常的操作。

除此之外，还有一种例外情况，即比较不同时期的文件，看其是不是发生了改变。

然而，过多的失败登录肯定是一个令人感兴趣的安全报告，而且许多人会根据如下这几个方面定期地查看这些失败的登录企图：

　　用户名

　　连接失败的客户端IP地址

　　源程序

　　时间和日期

　　例如，图一展示了两个视图，这两个视图根据两个方面进行了分类总结，一是根据登录名（上图的左侧），二是根据显示失败登录的详细视图的报告（包括登录名、源IP地址、连接到哪个数据库服务器、通信类型）。

　　可使用数据库的特性或使用外部的数据库安全方案来审计登入和登出活动。

所有的数据库厂商都支持这种基本的审计功能，而且因为这些事件的数量是很小的（至少在与审计实际的SQL调用时所得到的事件数量相比时是这样的），所以数据库在执行这种审计时所遭受的性能损失很少。

　　正如在插入或更新时，Oracle触发器会启动一样，系统级触发器会针对特定的系统事件（如登入、登出和DDL执行）而执行。

下面如何实施这种审计：

　　首先，创建一个你用来保存这种信息的表：

　　下一步，创建一个在发生新登入时可执行的触发器：

　　多数数据在用户登入时被记载，但在用户登出时，需要用触发器来记载其登出日期和时间，代码如下：

　　在Oracle环境中这样做就可以了。

如果你运行的是Sybase环境，问题就更简单了，因为你可以用下面的命令审计对所有数据库的所有访问：

　　根据失败的登录来实施警告或账户锁定这种功能，需要得到数据库厂商或数据库安全解决方案的支持。

如果使用数据库来生成登录和登出的审计，并且你的数据库厂商可以实施账户锁定功能，那么，你可以在数据库环境中实现这一点。

例如，你可能知道如何建立Oracle的口令策略。

在另外一种环境中（如SQLserver2000），你就无法使用本地数据库特性来完成此功能，而需要编写代码来检查Windows的事件日志，查找失败的登录，或者使用一个外部的安全系统来实现。

　　在使用外部安全系统时，你可以使用SQL防火墙来阻止经过一定数量的失败登入企图后，某个登录名的任何连接。

在这种情形中，数据库并不会收到连接企图，因为这种连接企图会在防火墙水平上被拒绝。

另外一个选择（该选择并不要求你将安全系统置于数据库之前）是使用数据库过程，如图二所示。

在这种情形中，失败的登录次数超过某个上限后，审计系统就会生成一次审计。

该审计被发送给一个负责连接到数据库的系统，并且调用一个过程来锁定账户。

该系统一般还会通知数据库管理员，告知已经采取了该行动，以便于进行调查，并且在必要时可以释放被锁定的账户。

　　除了可用于创建审计线索，登录信息可用于创建一种可以帮助管理员确认异常的基准。

用户登录活动的基准是“正常”登录行为的反映。

这种基准是通过着眼于在某段时间（例如，一个月）的所有登录活动而构建的。

通过将所有的可能性进行组合，对其分类而建立基准。

例如，你可以根据网络位置、用户名、源程序、时间和日期来对登录进行分类，此时的基准可能会类似于下面这个样子：

　　这个基准表明，根据相对记录期中所观察到的所有登录活动，user1总是从192.168.1.168（例如这是一台应用程序服务器），并且是24小时持续地连接。

User2用于从Excel连接到数据库，它用于192.168子网中的多个网络节点中，不能用于正常上班时间之外。

最后，在从isql发起访问时，就会用到user3，它可以在周末从10.10.10子网的任何节点上工作。

　　有了这种基准，管理员就可以对背离正常操作的行为做出报告或发出警告。

例如，如果你看到有人使用user1成功登录，但其IP地址却不同于192.168.1.168，而且所使用的工具却是SQLNavigator之类的工具，可以断定，要么你的环境发生了变化，要么是某人成功地获得了应用程序服务器的用户名和口令，并用这些信息从数据库析取信息。

再举一个例子，使用user2在午夜2点的一次登录就非常可疑。

当然，这可能表明某个人工作得很晚，但根据具体环境、敏感性等，你可能需要深入地调查此事。

　　根据失败的登录来实施警告或账户锁定这种功能，需要得到数据库厂商或数据库安全解决方案的支持。

如果使用数据库来生成登录和登出的审计，并且你的数据库厂商可以实施账户锁定功能，那么，你可以在数据库环境中实现这一点。

例如，你可能知道如何建立Oracle的口令策略。

在另外一种环境中（如SQLserver2000），你就无法使用本地数据库特性来完成此功能，而需要编写代码来检查Windows的事件日志，查找失败的登录，或者使用一个外部的安全系统来实现。

　　在使用外部安全系统时，你可以使用SQL防火墙来阻止经过一定数量的失败登入企图后，某个登录名的任何连接。

在这种情形中，数据库并不会收到连接企图，因为这种连接企图会在防火墙水平上被拒绝。

另外一个选择（该选择并不要求你将安全系统置于数据库之前）是使用数据库过程，如图二所示。

在这种情形中，失败的登录次数超过某个上限后，审计系统就会生成一次审计。

该审计被发送给一个负责连接到数据库的系统，并且调用一个过程来锁定账户。

该系统一般还会通知数据库管理员，告知已经采取了该行动，以便于进行调查，并且在必要时可以释放被锁定的账户。

　　除了可用于创建审计线索，登录信息可用于创建一种可以帮助管理员确认异常的基准。

用户登录活动的基准是“正常”登录行为的反映。

这种基准是通过着眼于在某段时间（例如，一个月）的所有登录活动而构建的。

通过将所有的可能性进行组合，对其分类而建立基准。

例如，你可以根据网络位置、用户名、源程序、时间和日期来对登录进行分类，此时的基准可能会类似于下面这个样子：

　　这个基准表明，根据相对记录期中所观察到的所有登录活动，user1总是从192.168.1.168（例如这是一台应用程序服务器），并且是24小时持续地连接。

User2用于从Excel连接到数据库，它用于192.168子网中的多个网络节点中，不能用于正常上班时间之外。

最后，在从isql发起访问时，就会用到user3，它可以在周末从10.10.10子网的任何节点上工作。

　　有了这种基准，管理员就可以对背离正常操作的行为做出报告或发出警告。

例如，如果你看到有人使用user1成功登录，但其IP地址却不同于192.168.1.168，而且所使用的工具却是SQLNavigator之类的工具，可以断定，要么你的环境发生了变化，要么是某人成功地获得了应用程序服务器的用户名和口令，并用这些信息从数据库析取信息。

再举一个例子，使用user2在午夜2点的一次登录就非常可疑。

当然，这可能表明某个人工作得很晚，但根据具体环境、敏感性等，你可能需要深入地调查此事。