数据安全和SOX

数据安全的事情被提到桌面上来，甚至这个项目组成为最落后的一个了。客户所有的项目几乎都或多或少遵循SOX法案，对这个东西，曾经看过一些资料，觉得是个好东西，至少能够在数据质量和数据安全，又多了一些市场。
 
SOX的详细条目估计是贼多贼多地，昨天开会只听到客户精练提出的三个要求：

1、增设数据安全管理员岗位；

2、打开数据库的审计功能；

3、控制对一些关键数据（例如详单）的访问；
 
这就清楚多了，看起来也不是非常麻烦。从客户的嘴里面说出来，似乎还包含着一种不好意思，在语气背后似乎在说，"给你们添麻烦了，我们也不想如此麻烦，莫办法，上市公司的要求"。管理严格了，被管理者就得受点累。但总体来说，觉得这是好事。
 
不过没等我享受到什么好处，就尝到麻烦的滋味。
 
上午去跟客户要点数据，没有放入数据仓库中的数据，这在两个月前曾经拿过一次，那次很顺利的。可这次不行了，发了mail，然后打电话确认。对方说，恐怕没那么简单，你需要填写叉叉单子先。哦，买高的，这个数据并非什么正式数据，只是几个符合特定条件的代码而已，却要填写单子，值得吗？况且，根本没见过那个叉叉单子长的什么样。对方很抱歉地说，不好意思，不能就这么给你，上头会扣分的。
 
没辙，要不填那个单子。要不就转个弯，不知道换个说法是不是可以，原来说的是"提取数据"，如果改成"提取信息"会不会就绕数据安全的问题了呢？
 
一直认为将接口、职责明确是一个目标，但还有些问题要解决的。例如沟通的问题。以往几次，需要增加数据接口，注明需要那些字段，字段的含义，但其实并不清楚数据源那边是否能够提供，或者是否还有更好的接口方式。我期待能有几次交互，将接口确定下来。但这些接口需求几乎都是十分肯定地被接受，"没问题"。如此果断的答复当然令人振奋，但让人担忧的是，双方是否理解一致。
 
这接口的双方，其实都是希望能够多了解对方的一些信息，而不是死板的任务单。特别是在开发期，因为接口的不确定性，更加需要交流。只有双方各自问出，"你需要什么"，"你能提供什么"，才能磨合出比较恰当的接口。原先，数据源和数据仓库厂商的沟通本身就不够，毕竟大家各为其主，总是会留一手。这个sox的应用，不知道会不会更加阻碍这种沟通了。