军队行业数据权限管理

军队行业数据权限管理（3篇）

1.军队行业数据权限管理 篇一

目 录数据库操作规范：............................2

1.1

1.2

1.3

1.4

1.5数据库关键参数配置：.........................2 数据库数据提取流程：.........................2 数据库操作管理制度：.........................2 操作系统帐号管理制度：............................3 数据库帐号管理制度：.........................3 应用程序管理规范............................3

2.1 应用程序发布管理：.............................3数据库备份规范...............................4

3.1

3.2

3.3 备份设备物理规划：.............................4 数据库备份制度：..........................4 备份数据定义：..............................41 数据库操作规范：

1.1 数据库关键参数配置：

· 新项目或系统、数据库填写系统上线更新记录表；

· mysql数据库应用服务端口设定，默认实例服务端口是3306，其它实例需注意服务端口值；

· 数据库内存使用是实际物理内存三分之二，如果是双机系统建议不要超过二分之一；

· 严禁按照Internet上查找的资料中只言片语，对数据库进行调整；

1.2 数据库数据提取流程：

1业务部门相关人员填写“数据申请单”；

2部门负责人签字；

3DBA依情况操作；

4需求申请部门验收。

1.3 数据库操作管理制度：

①业务部门要求的数据库操作需要有书面审批流程，DBA应保留原始文件一份；②业务部门所填写的数据申请表单，一定需要相关负责人签字后方可执行。

③在做数据库更改操作前，必须和业务人员核对业务逻辑，在完全清楚业务逻辑后进行

数据库操作；

④所有数据库更改操作，必须先进行测试，并将操作放在事物中，分步执行；

⑤保留重要操作的脚本、操作前数据、操作过程结果，以便日后查对；

⑥在完成操作后，要给操作需求方最终结果报告，使需求方可以及时核对；

⑦对于一些核心机密数据，需要遵守公司相关的保密协议，不能向外泄露；

⑧注意维护数据库服务器的硬盘空间，及盘阵上磁盘状态；

⑨按流水记录数据操作日志，作为以后查对凭证；

⑩以后有关数据库手工操作之前，一定通知所有应用程序开发人员，以便评估、保存操

作结果；

⑾DBA个人使用的计算机应严格管理，尽可能不要在办公区外上网，更不要浏览和工作无

关的网站，一定要安装防毒套装软件，避免感染病毒和木马，严禁安装与工作无关的应用软件；

⑿当数据库需要调整时，严禁按照网上查找的资料操作数据库，一定是先查看官方完整

文档或权威文档，通过严格测试，书写完整报告，经评估后，填写数据库维护申请表，获审批方可操作；

⒀严禁在其它地方使用工具连接生产数据库，进行操作；

⒁操作流程：填写数据申请单

· 业务部门业务人员提出申请；

· 业务部门负责人审核；

· 运营DBA执行，操作完成后，需在“DBA操作结果”中写明操作语句和影响记

录条数；

· 运营核查；

· 业务部门任务申请人员检验操作结果，并签字确认；

· 单据由运营部门保留。

1.4 操作系统帐号管理制度：

①在数据库服务器、关键应用服务器上，只能有数据库DBA人员的帐号，开发人员需要介

入时，填写开发人员使用数据库申请单；

②在操作系统中需要启动本地安全策略中有关帐户管理的安全策略，策略如下：

·启动密码必须符合复杂性要求；

·密码长度最小值6个字符；

·帐户锁定时间10分钟；

·帐户锁定阀值5次；

③每两个星期检查一次操作系统日志；

1.5 数据库帐号管理制度：

①应用程序帐号权限需要做严格限制，对不同应用需求使用不同权限和操作范围帐号，要有部门负责人确认；

②在不同应用服务器上相同应用程序应使用不同数据库访问帐号；

③帐号密码需要有复杂性要求(字母、数字14位以上)；

⑤所有帐号名称、访问权限、应用程序名称必须记录在案(如：表格形式)；

⑥在防火墙上严格限制数据库端口访问的IP地址，只有正常对外服务的应用服务器IP

可以访问相关数据库；

⑦数据库超级用户权限使用严格限制；应用程序管理规范

2.1 应用程序发布管理：

禁止研发人员在应用服务器上直接操作数据库，需要为业务部门进行统计分析数据时，应使

用特别的查询帐号(只读权限)，应用程序数据库操作帐号必须专人保管；

在关键应用程序更新，涉及重大逻辑调整前后，特别是计费、充值等，必须做数据库静态备

份；数据库备份规范

3.1 备份设备物理规划：

①数据库本地保留至少一份全备份和之后的日志备份

②在另一台机器保留大部分数据库的备份，至少保留半年以上

③异地存盘保留备份。

3.2 数据库备份制度：

·数据库备份原则上采用数据库完全备份加日志备份策略；

·备份数据存储策略：本机、异机、刻盘、3个级别；

·重要更新时间点前后必须做数据库备份或日志备份，特别是在做数据库表更新、应用

程序更新，如：认证记费程序、充值程序等，都必须先关闭与游戏帐号库有关的所有

应用程序，做数据库静态备份，再进行数据库更新和（或）应用程序更新，在启动应

用程序前，进行第二次数据库静态备份，备份完成后，启动应用程序，将这两次静态

数据库备份永久保留

·每天检查所有数据库备份操作是否正确完成、异地传输是否正常完成，并填写检查表；

·在异地备份数据准确存储后，可以将超过2周 以上的异机备份数据删除，以便腾出存

储空间；

·在异地备份刻盘方式，加密保存。

3.3 备份数据定义：

1数据库常规备份内容：

数据库完整备份、日志备份；

2重要时间点前后备份内容：

数据库表结构变化；

数据迁移；

程序逻辑变化，包括充值逻辑、注册逻辑、计费逻辑

手工操作(尽可能杜绝手工操作数据库，可以将手工操作程序化)；

3数据文件备份，mysqldump逻辑备份

2.军队行业数据权限管理 篇二

一、数据库对象所有者

数据库中的每一个表、视图和存储过程都有一个所有者。数据库的所有者一般是数据库中对象的所有者。一个数据库对象的所有者能改变和删除对象, 也能将对象所有者的权限赋予其他用户, 还能将已赋予其他用户的权限去除。

二、对象的使用权限

为了数据库的数据安全, 我们必须加强对数据库对象的使用权限的管理。为了加强对数据库对象的使用权限的管理, 则必须首先掌握数据库对象所有者具有哪些使用权限。针对表, 对象所有者能执行select、insert、update、delete、references等操作, 并能将这些权限赋予其他用户 (包括用户、用户组、角色) ;针对表的列, 对象所有者能执行select、update、references等操作, 并能将这些权限赋予其他用户;针对视图, 对象所有者能执行select、insert、update、delete等操作, 并能将这些权限赋予其他用户;针对存储过程, 所有者能执行execute等操作, 并能将这些权限赋予其他用户。实际上, 一个对象所有者不但能将对象所有者的权限赋予其他用户, 而且能将已经赋予其他用户的权限去除;不但能够赋予其他用户“权限授权”的权限, 也能够将赋予其他用户的“权限授权”的权限去除。

三、赋予权限

对象所有者能将权限赋予其他用户, 具体的操作语法格式为:

grant{all[privileges]|permission_list}on{table_name[ (column_list) ]|view_name[ (column_list) ]|stored_procdure_name}to{public|name_list|role_name}[with grant option]

其中, all指对象所有者具有的所有权限, privileges是权限, permission_list为权限列表, table_name为表名, column_list为列的列表, view_name为视图名, stored_procdure_name为存储过程, public是特殊用户组, name_list为用户名列表, role_name为角色名列表, with grant option表明赋予指定权限的同时赋予该权限的“权限授权”权限。

四、赋予“权限授权”的权限

对象所有者不但能将某个权限赋予其他用户, 而且能赋予其他用户该权限的“权限授权”。这一同时赋予该权限的“权限授权”操作是在赋予权限操作后加“with grant option”子句实现的。例如, 操作grant select on authors to rstein with grant option将对表authors的select操作权限赋予用户rstein, 同时还将“权限授权”赋予用户rstein。这样, 用户rstein可执行对表authors的select操作, 同时也能将该权限赋予其他用户。

这里必须注意的是, 当我们使用带“with grant option”字句的操作赋予一个用户某种权限时, 该用户也同时将“权限授权”的权限赋予其他用户。因此, 当使用带“with grant option”子句的操作将某个权限赋予一个用户时, 就不能控制有多少用户具有该权限了。

五、去除权限

对象所有者不但能将权限赋予其他用户, 而且还能将已经赋予其他用户的权限去除, 具体的操作语法格式为:

revoke[grant option for]{all[privileges]|permission_list}on{table_name[ (column_list) ]|view_name[ (column_list) ]|stored_procdure_name}from{public|name_list|role_name}[cascade]

其中, grant option for表明去除“权限授权”的权限, permission_list为权限列表, table_name为表名, column_list为列的列表, view_name为视图名, stored_procdure_name为存储过程, name_list为用户名列表, cascade是在去除已经对其他用户授权的“权限授权”时必须带的参数。

六、从多个用户获得权限

一个用户能从不同的用户获得同一权限, 这一权限的授权过程按如下顺序进行:dbo用户执行带“with grant option”的赋予操作将某一权限赋予用户user1;用户user1执行带“with grant option”的赋予操作将这一权限赋予用户user2和user3;用户user2和user3分别将这一权限赋予用户user4。这样, 用户user4从不同的用户同时获得这一权限。如果用户user1去除对用户user2的该权限的赋予, 则用户user4也将失去从用户user2获得的该权限, 但用户user4仍具有从用户user3获得的该权限。在这种情况下, 难于判定用户user4是否具有从用户user2获得的权限。可见, 在实际应用维护中, 在赋予授权操作时要非常谨慎。否则, 如果随意赋予授权, 将很难判定一个用户是否具有某种权限。

七、权限优先级问题

角色、用户和用户组都可以决定用户的权限, 那用户通过哪个途径获得的权限优先级较高呢?也就是说, 当一个用户从一个途径获得一个权限, 又从另一个途径获得与这个权限相反的权限时, 哪一个权限会生效呢?以下我们将简要介绍权限的优先级。确定权限优先级的基本原则是:从角色获得的权限比从用户或用户组获得的权限优先级高, 从用户或者用户组获得的权限优先级取决于执行的顺序 (最近执行的具有较高的优先级) 。根据确定用户优先级的基本原则, 可以判定用户具有哪个权限。例如, 如果把一个权限赋予一个角色, 同时又把该权限从具有该角色的某个用户中去除, 那么该用户仍具有这个权限 (从角色获得的权限优先级较高) ;如果把一个权限赋予一个用户组, 接着把该权限从用户组中的某个用户去除, 那么该用户不具有这个权限 (从用户或者用户组获得的权限优先级取决于执行的顺序, 最近执行的具有较高的优先级) 。

八、结束语

3.军队行业数据权限管理 篇三

前言：

权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真，针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的方案。

目标：

直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是因为它足够直观。

简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。

扩展，采用可继承在扩展上的困难。的Group概念在支持权限以组方式定义的同时有效避免了重定义时

现状：

对于在企业环境中的访问控制方法，一般有三种：

1.自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。

2.强制型访问控制方法。用于多层次安全级别的军事应用。

3.基于角色的访问控制方法(RBAC)。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

名词：

粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特

定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。

细粒度：表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细

粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。

原则：

权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。

需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整，

回到权限的问题公式，通用的设计仅解决了Who+What+How 的问题，其他的权限问题留给业务逻辑解决。

概念：

Who：权限的拥用者或主体(Principal、User、Group、Role、Actor等等)

What：权限针对的对象或资源(Resource、Class)。

How：具体的权限(Privilege, 正向授权与负向授权)。

Role：是角色，拥有一定数量的权限。

Operator：操作。表明对What的How 操作。

说明：

User：与 Role 相关，用户仅仅是纯粹的用户，权限是被分离出去了的。User是不能与 Privilege 直接相关的，User 要拥有对某种资源的权限，必须通过Role去关联。解决 Who 的问题。

Resource：就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。资源可以反向包含自身，即树状结构，每一个资源节点可以与若干指定权限类别相关可定义是否将其权限应用于子节点。

Privilege：是Resource Related的权限。就是指，这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限，叫做“部门新闻发布权限”。这就表明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。权限，包括系统定义权限和用户自定义权限用户自定义权限之间可以指定排斥和包含关系(如：读取，修改，管理三个权限，管理 权限 包含 前两种权限)。Privilege 如“删除” 是一个抽象的名词，当它不与任何具体的 Object 或 Resource 绑定在一起时是没有任何意义的。拿新闻发布来说，发布是一种权限，但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时，才会产生真正的 Privilege。这就是 Privilege Instance。权限系统根据需求的不同可以延伸生很多不同的版本。

Role：是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。

Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的Parent是什么Group。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上，在业务逻辑的判断中，User仅应关注其直接属于的Group，用来判断是否“同组” 。Group是可继承的，对于一个分级的权限实现，某个Group通过“继承”就已经直接获得了其父Group所拥有的所有“权限集合”，对这个Group而言，需要与权限建立直接关联的，仅是它比起其父Group需要“扩展”的那部分权限。子组继承父组的所有权限，规则来得更简单，同时意味着管理更容易。为了更进一步实现权限的继承，最直接的就是在Group上引入“父子关系”。