数据安全稽核（共5篇）
篇1：数据安全稽核
宁波万华聚氨酯有限公司(以下简称宁波万华)成立于2006年2月27日，是烟台万华聚氨酯股份有限公司的控股子公司，主要从事异氰酸酯及其衍生物的生产。宁波万华以风险管理和控制作为开展安全隐患排查治理工作的基础，最重要的手段是持续开展全员稽核和安全检查。与传统意义上对照安全检查表逐项看是否达到标准的检查方式不同，安全稽核是一个双向沟通的过程，在效果上具有一定的优势，见表1。
安全稽核与传统安全检查的区别
宁波万华建立了《安全稽核程序》，开展全员安全稽核，领导层、部门经理、主管、班长、员工全部参与安全稽核。《安全稽核程序》的基本要求是：宁波万华实行区域全员安全稽核制度，公司内的所有人员均要参与安全稽核。各部门根据公司和月度稽核计划要求，制定与本部门、本区域相适应的安全稽核计划，并提交HSE部备案。各部门、区域根据本部门的稽核计划进行稽核活动，稽核活动的频次应达到一定的要求（见表2）。
安全稽核的频次
现场安全稽核的主要步骤
现场安全稽核的步骤共分为6步：
第一步：观察作业人员的反应及作业过程，要以安全的方式制止其不安全行 为。第二步：肯定或表扬作业人员的安全行为或好的方面，肯定或表扬的内容要具 体、明确。
第三步：讨论不安全行为或不安全状态，说出稽核中发现的问题，和作业人员谈论不安全的方面以及可能导致的后果。第四步：取得承诺，通过有效地沟通，取得作业人员对不安全行为的具体承诺和发自内心的认可。
第五步：讨论其他安全问题。第六步：对作业人员表示感谢。安全稽核的内容
安全稽核的内容主要包括以下5个方面(见表3)。ＨＳＥ稽核内容
1.人员的反应：当作业人员有不安全行为的时候，发现稽核人员会做出不自然的反应，立刻改变当前的作业状态。
2.人员的位置：作业人员所处的位置是否可能对自身造成伤害。
3.个体防护装备：所使用的个体防护装备，根据当时的作业情况判断能否完全保护作业人员。
4.工具与设备：工具与设备的完好性，工具与设备是否适合当时作业类型，工具与设备是否被正确地使用。
5.程序与5S(工作场所的安全标语）：作业人员是否按照规程或操作程序作业，工作场所5S是否符合要求。稽核结果分析及跟踪
宁波万华的HSE安全专业人员会在每周一，将上周的稽核报告汇总，对有效稽核报告中的数据进行统计分析，编制每周安全周报，绘制安全气象图(见图1)。
图1纵坐标表示通过对稽核问题分析得到的安全气象指数。按照稽核发现的隐患或事故可能导致伤害程度的不同，分为死亡、重伤、轻伤3种结果，指数分别为0.5、0.3、0.1，所有问题对照的指数累加后的和即为某段时期的安全气象指数。图1的横坐标指稽核问题汇总统计的时间段，一般以周为单位。
将连续几周的安全气象指数连接后，就会形成一条以指数为纵坐标，周次为横坐标的曲线图。安全气象图中的指数大小能直接反映某个区域在一定时间段内的不安全因素有多少。可见，绘制安全气象图可以有效地监控某个区域在一定时间段内的安全状况，指数越高，说明存在的问题越多。平稳的气象曲线说明当前安全状况比较平稳，一旦曲线连续几周变化较大，就需要提醒相关部门及时查找原因，消除各类安全隐患。制定稽核计划
每年，宁波万华都会提前制订稽核计划，以便有效地落实稽核工作。2008年的安全稽核计划见表4。
宁波万华的各部门依据此模版制定全年的稽核工作计划，并结合各自的具体情况，确定每月的稽核要点及具体内容，在上表中所对应项打“√”。各部门根据本部门特点可增加稽核内容，在相应的“其他”项中说明。月度稽核计划根据计划进行分解。
开发稽核管理系统软件
为方便大量稽核数据的管理和统计工作，宁波万华的HSE部和信息管理人员合作开发了安全稽核管理系统。此软件可以对稽核数据进行输入，方便查询，软件的统计功能可以对所有输入的数据按时间进行分类统计，自动计算出安全气象指数并生成安全气象图，大大节省了HSE管理人员的统计分析时间。宁波万华在稽核管理系统中，将公司所有区域进行了划分，每个区域都有责任人负责对稽核出的问题进行整改。每项稽核问题输入管理系统后，系统会自动将任务转到责任人的待办事项中，及时提醒责任人进行处理。
稽核系统还可以按时间段对每个区域负责人的稽核问题整改完成情况进行统计。稽核系统的应用大大提高了对稽核数据的统计分析效率，避免了人工统计带来的误差，同时能将每项问题都及时通知责任人，保证了稽核问题的按时整改。
通过稽核程序的执行，宁波万华的员工在使用劳动防护用品和遵守安全作业规程方面，由原来被动接受公司安全管理部门的监督变为主动执行，营造了良好的安全氛围。在现场安全隐患整改方面，宁波万华主要对生产现场设备设施的安全隐患进行了稽核，如对现场的坑洞进行了整改，不能消除的进行了硬性防护，对有棱角的设备都进行了钝化或防护，对旋转设备的防护罩全部进行了确认，对容易碰撞和绊脚的设施都进行了颜色警示，为员工创造了一个安全的工作环境。编辑 王 璇
篇2：数据安全稽核
为及时发现并解决各类安全隐患，落实安全生产责任制，预防各类安全事故发生，从而提高制造厂安全生产管理水平，特制定本制度。2 适用范围：
本制度适用北京厂、上海厂、惠阳厂 3 相关职责：
3.1 运营支持处：依据本制度组织厂级日常的安全稽核，跟进不符合项的整改情况，统计、通报稽核结果。3.2 各业务处：梳理、确认本处安全稽核标准，主动接受并配合安全部门组织的厂级检查稽核，落实对不符合项或相关问题的整改和反馈；组织本业务处内的日常稽核和整改。4 名词定义
安全稽核：依据《安全稽核标准》组织专人对工厂相关业务进行的例行或专项安全检查。5 安全稽核：
5.1 稽核时间：
5.1.1 工厂每半月应组织至少一次的例行检查稽核，每月应保证所稽核对象覆盖到本工厂所有部门。5.1.2 除例行的检查稽核外，各工厂应针对安全事故、重要时期、重点业务等实际情况组织专项或日常随机稽核。5.1.3 工厂各部门应根据本制度制定处内的安全检查稽核要求，每月不少于一次对处内各项安全情况进行检查并做好详细记录。5.2 稽核内容：
5.2.1 思想、意识：检查员工包括管理者安全意识与培训教育情况；
5.2.2 管理、制度执行：检查法律法规、各项安全管理制度、程序文件、安全操作规程的落实和执行情况。5.2.3 事故：检查事故调查、报告、处理、纠正与预防措施制定及过程的跟踪、措施整改情况。5.2.4 隐患：检查重点岗位、设备、环境、人员，尤其是强检设备设施、环境、仪器、防护用品等潜的隐患和危险。5.2.5 整改：检查所有隐患整改及效果。5.3 稽核标准：
5.3.1 工厂各部门负责制订处级安全稽核项目和条款、工厂安全管理部门负责制订厂级安全稽核项目和条款，并形成书面的《安全稽核标准》（见附件），《安全稽核标准》须经工厂相关业务和安全管理部门确认。5.3.2 工厂各部门应定期对本部门条款及标准进行评审，如因程序文件、业务或现场发生变化导致《安全稽核标准》不符的，应及时修订并发送至工厂安全管理部门。5.4 稽核准备：
5.4.1 工厂安全管理部门在安全稽核前1个工作日，应确定稽核小组成员、稽核内容、时间计划。5.4.2 依据《安全稽核标准》随机抽取相关项目及条款编制《安全稽核计划、通知单》（见附件）。5.4.3 以邮件方式将稽核检查通知发送稽核小组成员及被稽核部门相关人员。5.5 组织稽核：
5.5.1 稽核小组根据稽核时间计划，依照《安全稽核计划、通知单》对被稽核部门开始稽核，稽核组通过查阅、访谈、观察、检测等方式，核对稽核条款的符合性并将结果详细记录于该表上。5.5.2 稽核组应对所有稽核内容进行分析、判断并确定不符合项或问题，最后与被稽核部门相关人员进行确认，同时明确整改要求。5.5.3 被稽核部门如对相关条款或稽核组提出的不符合项和整改有意见时，最终应以稽核小组意见为准。5.5.4 在稽核过程中如发现稽核计划之外的问题，或该问题责任不在被稽核部门的，同样需进行记录。5.6 稽核结果：
5.6.1 稽核小组对所有稽核发现的不符合项均应详细记录，同时向被稽核部门相关人员明确整改要求和期限。5.6.2 稽核小组在每次稽核结束后1个工作日内应将《安全稽核计划整改通知》发送被稽核部门并抄关相关人员。5.6.3 被稽核部门须严格按照《安全稽核计划整改通知》认真落实整改并反馈整改结果。5.6.4 各厂安全管理部门应每月就安全稽核结果及考核情况发送被稽核部门经理及相关人员。5.6.5 安全稽核结果将作为各部门安全工作负责人以及本部门安全工作业绩的评价依据。
制造联合平台管理（JAT）二零零九年九月四日
篇3：高效分布式数据稽核系统实现方案
关键词：分布式计算框架,STORM,分布式缓存,分布式列式数据库,HBASE,ROWKEY
0 引言
大数据时代,海量数据在系统之间川流不息,分布式架构设计要求系统间的耦合度越来越低,庞大的系统被拆分为多个独立功能模块,模块之间采用异步消息通信或者数据同步的方式进行信息交互,全系统数据一致性的问题被越来越多的暴露出来。在这种情况下,需要有一套通用的数据稽核系统对系统间的数据,进行双方或者多方的比对,以发现数据不一致的问题。
1 数据建模方案
数据稽核模型包括:稽核任务配置、稽核处理、稽核结果数据生成三大部分。每一组需要比对的数据源都会对应一个稽核任务,稽核任务上配置了该任务的稽核规则和这种任务的属性信息,这组比对数据源的来源是固定的,并且按照一定的时间频度进行比对。
稽核任务基础信息包括:任务名称、任务类型、任务是否可持续反复进行、稽核任务数据的归属本地网,稽核差异数据记录阀值,稽核规则等信息;稽核任务通知扫描的时间间隔,每种任务的稽核的数据生成需要的时间长度和时间间隔不同,因此任务就绪通知产生的实际时间也不同,需要配置不同的任务通知扫描时间,确保任务就绪通知被及时发现。
稽核任务规则:稽核任务需要处理的数据源信息,例如表名、关键字段、索引字段、主键字段;稽核数据范围提取方式配置,例如:直接给定时间范围或者按照当前时间的偏移量自动计算等。
每个稽核任务都对应一个规则,规则包括:需要配置稽核数据源表和稽核数据目标表,既以哪个表为基准进行比对,被配置为“稽核数据源表”的表数据是作为稽核比对的基准,我们需要配置出需要稽核的表对象名,以及表里需要稽核的字段名,使稽核程序能够从识别到真正的需要稽核的对象,然后进行按字段逐一比对。
稽核任务节点配置用于配置每种类型的数据源节点,以及每种类型的节点有几个数据生成节点实例,用于稽核数据任务就绪判断。
稽核任务涉及数据范围配置:稽核任务涉及数据范围配置每种稽核任务需要稽核的数据表。比对数据表的基本表信息和字段信息配置在对应的“比对数据表定义”和“比对数据表字段定义”。比对两端的数据表有可能表名和表字段名一致,也有可能不一致,“比对任务涉及业务数据表字段对应关系”就是进行两端表字段的对应关系配置,以确定稽核双方的表字段映射关系。
“数据字段值匹配规则”定义了两端数据稽核差异的匹配规则,例如最常见的就是全匹配(稽核的两端数据需要完全相同,才能认为无差异),部分匹配(稽核两端的数据只要有包含,即可认为无差异),转换匹配(需要进行规则转换后再进行匹配)等。
在每次具体的稽核比对任务执行时生成对应的稽核任务实例,处理程序会按照稽核任务配置环节中的配置内容进行加载,作用于每次的稽核任务实例,并记录本次稽核任务实例处理中的一些信息。每个稽核任务实例对应一次具体的数据稽核处理任务,其处理数据来源就是稽核数据源。
每次稽核任务实例对数据源处理后的稽核结果记录在稽核结果差异日志表。差异信息中记录了差异数据的来源、差异字段、差异值、差异原因等信息。
2 系统架构方案
稽核数据源取自各个外部系统,数据量庞大,因此这部分数据都将存放在分布式HBASE列式数据库中,便于扩展。HBASE中ROWKEY的设计是一个关键点,合理的ROWKEY设计是确保稽核处理准确高效的前提。对于每种稽核数据源需要约定统一的HBASE的ROWKEY定义规则,ROWKEY里需要包括被稽核两端数据源表的公共字段信息,用这些公共字段信息拼接合成后的ROWKEY能够把两边被稽核数据一一对应起来。ROWKEY至少需要要包括:主键标识字段、时间范围字段等。由于HBASE的分布式特点,所有的记录将按照一定的算法规则被分散在不同的HBASE数据节点,这个算法规则也是针对ROWKEY的。接下来我们就可以利用HBASE的ROWKEY高效定位特性进行数据记录源和目标的匹配,找到匹配的记录后,再进行后续的每条记录的具体字段值的稽核匹配处理。
稽核主程序部署在分布式计算框架storm集群上,每条被稽核的数据记录都是各自独立无关的,因此可以利用分布式处理框架的特点对数据进行并发稽核处理,HBASE中的稽核数据源中的每一条记录都将快速进入STORM集群中。系统的主要稽核逻辑基于Storm建立,事件源的消息将通过分布于各个节点Spout读入,然后分发到多个节点的Bolt中进行分析处理,因此每时每刻稽核数据源流入均能确保快速高效的并行处理分析,最终的稽核记过也将由末端的Bolt产生并把差异记过落到分布式数据库MYSQL上。
分布式缓存上存放基础的配置信息,稽核主程序在启动时读取这些配置信息并进行初始化,处理过程中的过程日志也将临时记录在分布式缓存中,利用分布式缓存的访问的高效性提高处理信息的生成和读取效率。
为了便于后期的统计分析,稽核差异结果记录在分布式数据库MYSQL中。差异的信息包括数据来源、数据表信息、数据差异类型、数据差异字段、数据差异值等。
以下是系统架构图:
3 结语
篇4：加强稽核力度 确保基金安全
西峰区自11月城乡居民基本养老保险工作启动以来，城乡居民基本养老保险参保人员已达16.66万人，其中年满60岁以上享受养老金人员36529人。在制度实施过程中，由于涉及人员较多、涉及面广、信息量大、信息不准确，冒领、重复领取养老金、重复参保的情况时有发生，给养老保险基金带来带来了极大安全隐患，损害了参保人的切身利益。
此次清查核对的信息主要是参保人员的姓名、身份证号码、居住地详细地址、缴费金额、是否参加其他养老保险、异地参保等信息进行全面核查。将核查人员花名分发到乡镇(街办)、职责落实到个人，进村入户进行调查核实，确保乡镇(街办)不漏村居(社区)、村居(社区)不漏户、户不漏人、人不漏表、表不漏项，保证了全区参保人员信息真实、全面、准确。对冒领、违规领取养老金的人员，坚决予以清理追回，维护了保险基金安全运行和参保居民的切身利益，保证了城乡居民基本养老保险工作的顺利开展。
(通讯员：张伟宁 西峰区城乡居民社会养老保险局)
篇5：数据安全稽核
随着中国移动产品、服务的不断增加, 业务受理渠道日益多样化, 网络业务平台越来越复杂。同时由于业务流程和管理制度不够完善, 数据不一致等现象大量存在, 所引发的一系列业务、计费及服务等相关问题日趋严重, 所造成的客户投诉增加、客户满意度降低, 业务收入流失的情况更是不容忽视。因此尽快采取措施解决数据一致性问题, 已经成为业务系统支撑工作的重中之重。
笔者认为, 实现数据一致性管理, 首先要界定数据一致性管理的网元或业务基础平台、业务和数据范围, 规范与支撑系统相连各网元或业务基础平台的数据交互流程, 明确相关网元或业务基础平台的接口功能和性能指标, 并提出数据一致性管理的相关要求, 为建立相应的一致性管理打下基础。
事实上, 数据不一致的现象存在于核心网、业务网以及其他的业务平台与网元或业务基础平台之间。这其中, 营帐系统与核心网的HLRAUC签约数据、营帐系统与业务网的用户信息和业务局数据之间进行数据一致性管理影响最大, 也是首先要解决的重点工作。
由此, 笔者主要围绕数据一致性的管理目标, 从业务推广方案要求、指令准确性要求、统一服务开通要求、管理办法要求四个方面出发, 对造成数据不一致的原因进行分析描述, 提出相应改进要求, 并针对存在的不一致问题, 从数据比对内容、数据比对方式、同步规则确定、数据同步等方面提出数据比对、同步要求, 进而从根本上解决数据不一致的问题, 实现数据的一致性管理。
业务推广中的用户数据不一致
在业务推广期间, 运营商有时候需要通过网元或业务基础平台直接向用户免费开通某项业务, 推广期结束后再根据用户实际需求由营帐系统对用户数据进行补录, 但存在部分用户的现有套餐不支持该项业务的情况, 导致营帐系统与网元或业务基础平台间用户数据不一致;另外, 运营商在制定用户套餐、产品迁移方案时可能会出现诸如互斥关系设置错误、数据提取错误等纰漏, 这也会导致营帐系统与网元或业务基础平台间用户数据不一致。
针对因业务规划、设计考虑等原因导致在业务推广和产品迁移时的用户数据不一致情况, 我们一般通过以下手段解决。
首先, 在业务规划、设计时明确业务推广对象, 并充分考虑套餐对产品的支持, 对业务互斥和包含逻辑进行有效梳理;其次, 在制定、实施用户套餐、产品改造方案时, 制定周密的用户数据迁移方案并严格遵照落实, 避免出现数据提取错误或字段不一致造成的数据不一致现象。
订购业务和实际使用中不一致
配置错误以及指令兼容性问题造成的不一致问题, 首先会表现为服务开通指令无法准确开通相应业务;服务开通指令无法兼容旧指令, 用旧指令开通的业务无法用新指令更改或关闭;另外一种常见的现象是由于指令的颗粒度不够细或者业务配置逻辑的失误造成在开通某项业务时会同时改变用户的其他功能和状态等问题。
针对业务发布上线时, 由于指令及业务规则匹配产生的数据不一致问题, 需要从以下几个方面予以解决。
首先, 对符合业务开通要求的服务查询、开通指令进行二次比对梳理, 确保服务查询、开通指令的准确性。制定统一模板, 服务查询、开通指令应包括指令格式, 各指令参数, 指令执行返回结果的说明。
其次, 对于因网元或业务基础平台设备版本升级等引起的服务开通指令变更, 应严格测试新指令的准确性和后向兼容性, 在验证准确无误的情况下, 提供新的指令集并对服务开通指令进行相应调整。
最后, 明确公司内部的各部门分工, 支撑部门应根据业务规则正确匹配业务指令和开通服务指令, 确保业务开通的有效性, 在使用新的开通服务指令进行业务受理前, 应严格测试业务指令与服务开通指令对应关系的准确性。
业务受理流程中的数据不一致
在现有的业务受理流程中, 存在以下四种情况导致服务开通时数据不一致现象。第一, 客户办理业务时存在多种受理渠道, 各渠道服务开通没有统一入口到营帐系统, 而是通过核心网或业务网网元或业务基础平台直接给用户开通了相关服务, 如果各渠道没有把相关业务受理的信息及时同步给营帐系统, 或同步时发生了差错, 或多网元或业务基础平台数据同步时没有确立基准都可能会造成数据的不一致。
第二, 业务受理面向客户, 实时性要求较高, 服务开通面向网元或业务基础平台操作, 网元或业务基础平台处理时可能会有工单积压的情况, 因此业务受理与服务开通之间多为异步操作。如果网元或业务基础平台没有或未及时把指令处理结果信息反馈给营帐系统, 或者营帐系统没有对失败工单及时准确地予以重处理, 会导致在营帐系统与网元或业务基础平台间数据的不一致。
第三, 由于业务本身的复杂性, 某项业务的订购依赖于多个网元或业务基础平台的服务开通, 如果某个网元或业务基础平台处理失败而其他网元或业务基础平台处理成功, 而营帐系统没有准确完整的判断处理机制, 势必也会造成营帐系统与网元或业务基础平台间数据的不一致;
第四, 业务推广时需要给用户免费体验, 而支撑网尚未完成系统改造, 需要在核心网网元或业务基础平台、业务网元或业务基础平台直接给用户开通服务, 而营帐系统无相关记录, 势必会造成用户数据和业务局数据的不一致。
避免业务处理“多入口、多出口”
总之, 对于客户来说, 多种业务受理渠道的存在极大地方便了业务办理, 运营商针对现存的多种业务受理渠道情况, 应避免“多入口、多出口”的业务处理方式, 在营帐系统设置接口服务器, 各渠道的受理指令统一汇总到接口服务器, 最后由营帐系统的服务开通接口统一发送服务开通指令至各网元或业务基础平台;在统一受理入口的基础上, 还应避免网元或业务基础平台间的数据双向或多向交互, 逐步实现以营帐系统为发起端进行单向交互, 避免冗余数据的多处存放。
当前, VGOP平台的建设目标是成为一个开放性的统一平台, 运营商应该逐步实现VGOP平台的数据处理与分析能力, 各网元或业务基础平台间的数据统一同步到VGOP平台, 然后由VGOP平台进行数据的总协调和总处理。
数据稽核平台有望破局
值得一提的是, 所有的数据不一致问题的处理都离不开数据稽核。数据稽核通过技术手段有效消除了营帐系统与各网元或业务基础平台用户数据的差异, 使营帐系统同各网元或业务基础平台的数据保持一致。
当前, 数据稽核系统尚缺乏统一的平台和自动化的稽核机制, 主要依靠人工干预的方式进行数据稽核和比对, 在下一步, 随着数据稽核平台的上线, 运营商的数据稽核也必将会发挥应有的作用。
笔者认为, 站在运营商内部角度, 数据一致性问题的解决可以有效降低因各网元或业务基础平台数据不一致导致的收入流失, 提高业务收入;同时, 我们也应意识到, 数据一致性问题是一项长期、持续的工作, 需要各个环节的人员不断积累经验, 优化手段, 对症下药, 甚至从整个IT系统架构进行全盘考虑, 才能有效的解决数据一致性问题。