开发中的角色问题

很多应用都存在着这样那样的安全隐患，为了尽可能地降低这样的风险，
结合本人的开发经验，对数据库的角色及权限使用做一小结：
1.最小权限：
    过多的权限往往意味着过多的风险。很多情况下，用户甚至只需要连接权限和读权限，创建一个只包含这两个权限的角色已经足够应付一般的业务需求了。
    对于一些更高权限的用户，你可以选择创建不同的、更高权限的角色，针对不同的用户使用不同的角色。或者你可以这样做：
                     选择把那些更高权限的角色做为非默认的角色，通过应用来控制这些高权限角色的开关。
2.及时开关：
    之前我们创建了最小权限的角色，而这个用户现在可以不经过应用来直接访问数据库，当然了，因为他本身有了连接和读的权限。
    为了避免这种情况，我们可以使用set role的方法及时开关不同权限的非默认角色，而且最好是通过应用来控制：
                   当只仅当应用启动时(用户登陆时)才打开这些角色，应用终止（用户退出）即关闭这些角色。
    (AOP就可以实现这样的功能了哦)
3.使用PUP
    通过上文的描述，我们还是可以发现这样的问题：非权限的用户可以在应用之外给自己授权(假设他已经获得了相应角色的密码)。
    为了避免这种情况，SQL*Plus提供了这样一种机制，每个用户(拥有sysdba和sysoper权限的用户除外)登陆SQL*Plus环境时会读取 Product_User_Profile table来获取对登陆用户的限制，从而对相应SQL操作做出限制，比如禁止用户set role等等。这样我们可以通过创建PUP记录来限制这样的用户提升自己的权限。
                  PUP使用存在的限制是必须是登陆local database，对于通过remote database进来(database link)的非权限用户，这种方法就显得捉襟见肘了。
4.给每个角色加密
    在创建角色的时候给每个角色加个密码，这个密码最好能够不那么容易被破解。
    现在我们创建了一个加密的角色，然后在应用中通过set role的方法来开关这个角色以达到权限控制的目的。但是很多情况下，这种做法除了对于一些比较懒的用户起一定成效外，基本上是在自欺其人。不怀好意的用户非常容易得到相应的代码从而获得相应的密码。
    为了避免这种情况，我们可以把这些角色的密码存放在数据库中，通过访问数据库的方式获得相应角色的权限，这样就可以很好地避免了被人反编译拿到写死在应用中的角色密码了。
5.将权限的操作存放在数据库中
    前面我们考虑到了用户在客户端通过反编译的手段来获取角色密码，在应用之外访问数据库来提升自己的权限的情况。现在我们换个思路，为什么要给那些不怀好意 的人在应用之外访问数据库的机会呢？在第4条中，我们把角色的密码存放在数据库的表中，避免了被人从应用代码中直接拿取密码的情况。同样的，我们可以这样 做，把那些权限的操作直接存放在数据库中，在应用中调用这些procedures。这样的话那些不怀好意的用户要首先找到应用的权限操作调用了哪个 procedure,然后找到这个procedure,执行它才可以获得这些角色的密码。这样我再限制了这类用户的execute权限，事情就好办多了。
    好了，这时我们可以这样想：前面我们把权限的相关操作的核心环节放在了数据库，我们为什么不让数据库来替我们把关，把那些没有经过应用而直接访问数据库的用户揪出来呢？要实现这一点，我
们事先要清楚一般的系统三层以上的构架。什么意思，就是现阶段一般的系统并不会让用户直接访问数据库，而是通过了应用层中间代理。事实上， Oracle确实给我们提供了这样的方法：使用
    SYS_CONTEXT ('userenv', 'proxy_userid')或者    SYS_CONTEXT (userenv', 'proxy_user')
来判断用户是不是直接连上了数据库。这样，我们定义一个权限角色，使用一个函数包来判断该角色是否能够生效,大致如下：
        CREATE ROLE test IDENTIFIED USING test.admin;
    查一查 oracle文档，我们很快就可以找到另一种方式：
    SYS_CONTEXT ('userenv', 'ip_address')，通过中间的代理连接数据库，一般来说，中间代理层的IP地址是确定的，这样我们就心理更踏实一点了。
    实际上，IP地址欺骗已经不是什么新奇的事了，所以还是不要以ip_address作为首要的判断条件。我们最好还是把上述的两种方式结合来用。

    现在有人会问了，前面我们创建了一个包来实现对权限角色的开关，那么这个包都底应该实现什么东东呢。
    这个包当然实现了所有对角色的认证了。你比如说：首先你要验证这个要启用当前权限角色的用户是不是存在于数据库中的合法用户，这个用户是不是通过了中间代 理层的才登陆数据库的，这个中间代理的IP是不是我们预料之中的等等，具体还有什么更严格的认证就看你的了。呵呵。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29209660/viewspace-1403882/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29209660/viewspace-1403882/