VD30论坛(八)安全控管(下)

VD_publisher 2004-12-22 10:26:15
VD30论坛(八)安全控管(下)
==================================================================================


随着企业的MIS系统进入3-Tier的时代, 甚至可以让员工在家 或是任何有Internet的地方可
以使用企业资讯的系统, 如此将企业的资讯暴露在任何的外点, 恐怕是多数企业担心与不能接受
的一个重要因素, 因此, 3-Tier系统在数据安全的控管上就变成一个非常重要的课题, 在前面论
坛中我们已经对功能性的安全控管提出了解决方案, 在此我们针对更多数据保全的目的做更深入
的介绍.
ROW SECURITY,即代表要控管数据表(Table)的存取权利, 在一般数据库系统其实也有这个功能,
但是也只能针对数据库用户存取那个Table来作为设定依据, 无法控管到每一笔数据的存取权限,
除此之外, 因为VD3是3-Tier的系统, 都是以A/P Server来代理所有Client的Login与存取数据库,
这也是无法使用数据库的安全控管机制的主因. 在VD3中, 我们是以SQuery作为每个Client的读取
权限来控管数据安全, 主要由SecurityStyle与DeptControl来控制安全管理的机制,如下:

SecurityStyle控管模式
------------------------
此模式是比较细腻的一种控管方式, 主要透过SQuery元件中的SecurityStyle,SecFieldName与
SecExcept等属性来控制, 如下说明:
1.安全模式(SecurityStyle): 用来控制数据的安全模式.
(0)ssNone(不启动): 本SQuery不作数据安全控管, 就是任何角色都可以查询所有数据.
(1)ssRoles(依角色): 就是所有归属该使用者相对的角色数据都可以存取, 系统会自动为你加
上 Where 角色栏位 IN (该USER的角色..), 使用IN不使用等于是因为以GETROLE登入的USER
可能有多个对应角色. 须注意在数据表一定有一个栏位记录着数据归属角色为何,此栏位定义
于SecFieldName中.
(2)ssRoleGroup(依角色群): 就是所有归属该使用者相对的角色群数据都可以存取, 系统会自
动为你加上 Where 角色群栏位 IN (该USER角色群..), 使用IN不使用等于是因为GETROLE登
入的USER可能有多个对应角色群. 同样的在数据表一定有一个栏位记录着数据归属角色群为
何, 定义于SecFieldName中.
...全文
49 点赞 收藏 2
写回复
2 条回复
andy_KAO 2004年12月22日
此數據安全機制有申請專利,請勿模仿!!
特別提醒一下!
回复 点赞
VD_publisher 2004年12月22日
(3)ssORG(依组织): 就是组织中的主管可以存取所有其属下的数据,组织是一个TREE的结构,所
以系统在SQuery的Where语法中会自动加上 IN (该主管的所有属下角色..), 也就是以组织
中主管的位置, 去抓取其下的所有角色成员, 自动放在Where的IN里面, 当然数据表中也须
将建档者的角色记录于某一个指定栏位中, 定义于SecFieldName属性.
(4)ssORGShare(依组织分享): 除了与ssORG一样外, 又增加了同一个部门中的数据可以相互分
享,即在TREE的结构上同一个部门下的成员的数据都是共享的, 不同部门不共享, 但上层的
任何直属主管皆可存取其下所有成员的数据, ssORG的缺点是只能各个角色独立, 除了主管
可以看到属下的数据外, 无法共享部门间各角色的数据, 使用了ssORGShare就可让同一部门
的数据可以互相分享. 在SQuery的Where语法IN中会比ssORG多出了同部门的角色.
2.安全栏位名称(SecFieldName): 用来定义本安全控管所需的栏位名称, 如果依角色就是指建档
角色栏位名称, 如果依角色群即指建档角色群栏位名称, 依组织则也是指建档角色栏位名称.
3.例外角色群(SecExcept): 可以定义一个例外的角色群, 属于此角色群的角色都可以不受本安
全控管, 如高级主管/财务部门/MIS部门等角色, 都是可以不受此SecurityStyle属性所管控的.
例外角色群设定时, 可选择多个角色群, 数据都是来自系统档案SYS_ROLEGROUPS这个数据表.

DeptControl控管模式
----------------------
此为简易型的多公司多事业群的安全控管功能, 以往如果要分割多公司或多事业群要将数据库
分开的方式, 再由USER LOGIN时选Database,此方式的优点是数据完全分离,互不影响, 但缺点是
如果要整合统计困难与无法统一管理, 所以, VD30提供了一个系统变数 _DEPT_CODE,其为一个
Client与A/P Server都可以透通的变数,说明如下:
1. 当USER LOGIN时, 系统并不会设定此 _DEPT_CODE的变数, 须自行处理此变数, 可以在USERS
这个Table加入公司别 (最好可以设定多个公司别, 所以栏位宽度可以设定大一点),并在MAIN
的INIT取USERS的相关公司别放入_DEPT_CODE中.
2. 在SQUERY元件中有DeptControl(部门控制)与DeptFieldName(部门栏位名称)两个属性来控管
数据安全, 当DeptControl=True,系统会在SQuery中自动加入Where语法IN (_DEPT_CODE), 其
中 _DEPT_CODE可以多个, Where的栏位来自于DeptFieldName属性的设定, 如果_DEPT_CODE有
多个部门, 则以','分开, 如果_DEPT_CODE为空白时, 则就算DeptControl=True,也不会加入
Where的语法, 经过此DeptControl的控制后, 不管User在Form或Report中如何使用CDS,其数据
内容皆会受到_DEPT_CODE的管控, 所以你只要控制_DEPT_CODE, 即可控制整个系统的公司码与
事业群码.
3. DeptFieldName(部门栏位), 可以自由设定, 建议使用统一的栏位名称, 如SITE_CODE或
DEPT_CODE等).

以上如果有使用DeptControl与SecurityStyle共用时, 两者不相互冲突, 可以并用,因为在
Where中是以AND做为条件, 有了SecurityStyle与DeptControl这两种模式, 我们可以很容易将最
难的数据安全控管交给VD3的A/P Server处理, 你只要了解其架构, 与对USER的部门规划与设定
即可, 各位可能觉得这只是个简单的结果论, 但这个规划确实经过了十馀年的努力且好不容易才
实现的, 希望能为各位带来产品的竞争力与用户的满意度.
回复 点赞
发动态
发帖子
其他数据库
创建于2007-09-28

1924

社区成员

9511

社区内容

其他数据库开发 其他数据库
社区公告
暂无公告