一、电子政务的内容和网络规范的内容

（一）电子政务的内容

电子政务是指国家机关在政务活动中，全面应用现代信息技术、网络技术以及办公自动化技术等进行办公、管理和为社会提供公共服务的一种全新的管理模式。广义电子政务的范畴，应包括所有国家机构在内；而狭义的电子政务主要包括直接承担管理国家公共事务、社会事务的各级行政机关。

电子政务是一个系统工程，应该符合三个基本条件：

第一，电子政务是必须借助于电子信息化硬件系统、数字网络技术和相关软件技术的综合服务系统；硬件部分：包括内部局域网、外部互联网、系统通信系统和专用线路等；软件部分：大型数据库管理系统、信息传输平台、权限管理平台、文件形成和审批上传系统、新闻发布系统、服务管理系统、政策法规发布系统、用户服务和管理系统、人事及档案管理系统、福利及住房公积金管理系统......,等等数十个系统。
第二，电子政务是处理与政府有关的公开事务，内部事务的综合系统。包括政府机关内部的行政事务以外，还包括立法、司法部门以及其他一些公共组织的管理事务，如检务、审务、社区事务等；
第三，电子政务是新型的、先进的、革命性的政务管理系统。电子政务并不是简单地将传统的政府管理事务原封不动地搬到互联网上，而是要对其进行组织结构的重组和业务流程的再造。因此，电子政府在管理方面与传统政府管理之间有显著的区别。

（二）网络规范的内容

互联网企业应该坚持依法办网、文明办网、诚信办网，正确处理经济效益和社会效益关系，始终把社会效益放在首位；认真开展行业自律，进一步严格内部管理，完善制度规定，规范信息发布流程，切实维护网络信息安全和公共利益。
积极开展从业人员网络法制和职业道德教育；建立健全网站编辑和版主行为规范，提高从业人员道德操守，增强社会责任意识；提倡网上理性思考、文明发言、有序参与，营造积极健康的网上舆论环境。
相关部门依法加强对网络公关行为的监督，严厉打击非法网络公关行为。同时提醒公众，如果个人和单位网上合法权益受到侵害，应及时通过正常渠道向相关网站提出投诉，网站经核实无误后有责任及时处理。

二、政务应急平台的内容

《应急管理信息化平台》坚持以人为本，按照预防与应急救援并重、常态与非常态相结合的要求，构筑应急管理信息化发展“四横四纵”总体架构，形成“两网络”、“四体系”、“两机制”体系结构。满足国家应急管理标准体系，融合“大数据云平台”、“感知平台”、“应急通讯平台”、“EGIS一张图”、“区块链”、“数据中台”和“知识图谱”等理念，突出“政务协同”、“监测预警”和“应急指挥”，以“顶层设计、分级分期、立足应急、服务民生”的建设思路，逐步建设省、市、区县、乡镇-企业应急管理信息化体系，应急综合管理平台采用“定人、定位、定岗、定责、定时”五定应急管理责任制和“人、地、物、事、组织、知识”的有效关联，充分发挥“互联网+”、“新媒体”、“大数据”在《应急管理信息化平台》中的应用。
紧紧抓住应急管理事业改革发展的重大战略机遇，构建科学、全面、开放的应急管理信息化体系，加快现代信息技术与应急管理业务深度融合，促进体制机制创新、业务流程再造和工作模式创新，不断提高风险监测预警、应急指挥保障、智能决策支持、政务服务和舆情引导应对等应急管理能力，全面支撑具有一体化、立体化、智能化、集成化、扁平化、可视化、标准化特征的现代应急管理体系建设。形成应急管理厅（局）应急管理新局面。

三、电子政务安全的内容

电子政务安全是指保护电子政务网络及其服务不受未经授权的修改、破坏或泄漏，防止电子政务系统资源和信息资源受自然和人为有害因素的威胁和危害，电子政务安全就是电子政务的系统安全和信息安全。由于电子政务的工作内容和工作流程涉及到国家秘密与核心政务，它的安全关系到国家的主权、安全和公众利益，所以电子政务安全的实施和保障是非常重要的。

电子政务安全的目标是满足政务业务的安全需要—电子政务系统的功能性安全要求和应对信息技术带来的信息安全威肋、—电子政务系统的自身安全要求。也就是保护政务信息资源价值不受侵犯，保证信息资产的拥有者面临最小的风险和获取最大的安全利益，使政务的信息基础设施、信息应用服务和信息内容为抵御上述威肋、而具有保密性、完整性、真实性、可用性和可控性的能力。

目前大部分的网络都遭受过来自内部和外部的双重攻击，包括对网络中数据信息的危害和对网络设备的危害。威肋、电子政务安全的因素有非人为和人为的两个方面。非人为的威肋、主要是如地震、火灾等的自然灾难和由于技术的局限性造成的破坏，如操作系统的安全隐患、硬件设备的设计漏洞等。人为的威肋、主要有内部人员安全威肋、、被动攻击、主动攻击、邻近攻击和分发攻击等5类。据统计，75%以上的安全问题是由内部人员引起的，已成为最大的安全隐患。内部人员安全威肋、分为恶意和非恶意两种。恶意攻击是指内部人员出于某种目的对所使用的政务系统实施的攻击。无意的攻击是指操作者由于误操作，对重要数据、文件等发送或存储到不安全的设备上，以及对数据造成严重的损害。

被动攻击，主要包括被动攻击者监视、接收、记录开放的通信信道上的信息传送。
主动攻击，指攻击者主动对信息系统所实施的攻击，包括企图避开安全保护、引入恶意代码，及破坏数据和系统的完整性。如破坏数据的完整性、越权访问、冒充合法用户、插入和利用恶意代码、拒绝服务攻击等。
邻近攻击，指攻击者试图在地理上尽可能接近被攻击的网络、系统和设备，目的是修改、收集信息，或者破坏系统。
分发攻击，是指攻击者在电子政务软件和硬件的开发、生产、运输和安装阶段，恶意修改设计、配置的行为。
这些安全隐患不可能依靠某种单一的安全技术就能得到解决，必须在综合分析电子政务整体安全需求的基础上构筑一个完整的安全保障体系。

四、电子政务安全管理的主要问题

根据电子政务的典型业务模型,我们需要考虑电子政务安全管理的如下问题:

办公环境的安全问题为了保障电子政务安全,首先需要考虑办公环境的安全问题,即电子化的办公系统在运行过程中的安全问题。其中包括办公人员的身份确认问题,不同级别的政府官员和办公人员的权限控制问题,办公系统中的数据安全使用和存储问题,日常的病毒防范问题,对付网络攻击的问题,以及物理环境安全问题等。
内部网络的安全问题电子政务系统是在网络环境下运行的,因此,网络安全是安全保障的重要内容之一,它具体包括不同政府部门或不同级别的机构之间广域网数据传输的机密性和完整性问题,上下级之间网络互访的可控性问题,及广域网有效带宽的可用性问题等。此外,还包括政府移动办公的安全问题,如政府官员移动办公的身份确认、权限控制和数据通信加密等问题。
对外服务的安全问题电子政务不仅仅是内部办公的问题,还涉及许多对外服务的内容,包括对企业和个人的服务。这其中也存在很多安全问题,例如公众访问权限可约束的问题,信息服务文档的防篡改问题,网络服务平台的可用性问题,网络访问的可控性问题,信息交互的机密性、完整性及不可否认性问题等。

五、电子政务信息安全等级保护、电子政务认证和权限管理的应用、政务信息交换的安全机制的相关内容

（一）电子政务等级保护的基本含义

信息安全等级保护是国家在国民经济和社会信息化的发展过程中，提高信息安全保障能力和水平，维护国家安全、社会稳定和公共利益，保障和促进信息化健康发展的基本策略。27 号文件对信息安全等级保护做出了系统的描述——“信息化发展的不同阶段和不同的信息系统有着不同的安全需求，必须从实际出发，综合平衡安全成本和风险，优化信息安全资源的配置，确保重点。要重点保护基础信息网络和关系国家安全、经济命脉、社会稳定等方面的重要信息系统。”

电子政务信息安全等级保护是根据电子政务系统在国家安全、经济安全、社会稳定和保护公共利益等方面的重要程度，结合系统面临的风险、系统特定安全保护要求和成本开销等因素，将其划分成不同的安全保护等级，采取相应的安全保护措施，以保障信息和信息系统的安全。电子政务等级保护工作分为管理层面和用户层面两个方面的工作。管理层的主要工作是制定电子政务信息安全等级保护诉讼的管理办法、定级指南、基本安全要求、等级评估规范以及对电子政务等级保护工作的管理等。用户层的主要工作是依据管理层的要求对电子政务系统进行定级，确定系统应采取的安全保障措施，进行系统安全设计与建设，以及运行监控与改进。本指南的内容主要针对用户层面的工作。

电子政务信息安全等级保护遵循以下原则：

重点保护原则
电子政务等级保护要突出重点。对关系国家安全、经济命脉、社会稳定等方面的重要电子政务系统，应集中资源优先建设。
“谁主管谁负责、谁运营谁负责”原则
电子政务等级保护要贯彻“谁主管谁负责、谁运营谁负责”的原则，由各主管部门和运营单位依照国家相关法规和标准，自主确定电子政务系统的安全等级并按照相关要求组织实施安全保障。
分区域保护原则
电子政务等级保护要根据各地区、各行业电子政务系统的重要程度、业务特点和不同发展水平，分类、分级、分阶段进行实施，通过划分不同的安全区域，实现不同强度的安全保护。
同步建设原则
电子政务系统在新建、改建、扩建时应当同步建设信息安全设施，保证信息安全与信息化建设相适应。
动态调整原则
由于信息与信息系统的应用类型、覆盖范围、外部环境等约束条件处于不断变化与发展之中，因此信息与信息系统的安全保护等级需要根据变化情况，适时重新确定，并相应调整对应的保护措施。

（二）电子政务认证和权限管理的应用

基于角色的访问控制模型RBAC

工作流的访问控制常使用基于角色的访问控制RBAC（Role-based Access Control）模型来实现。因为角色代表了组织中的职责和分工，所以基于角色的访问控制可以很好的反映一个组织的安全规范，利用角色层次和角色约束，可以在更大范围实现安全策略，简化组织的安全管理。在RBAC中，权限和角色相关，用户（user）被当作相应角色（role）的成员而获得角色的权限（permission）。这大大简化了权限的管理。角色针对组织中的各种功能创建，根据需要，可以把新的权限赋予角色，当然也可以把权限从角色收回。用户依据他们的责任和资历被指派角色，用户被指派的角色可以容易地从一个转到另一个。用户对信息的访问在指派角色的基础上被管制。使用RBAC，通过对角色、用户的角色分配和角色权限的分配，实施职责分离的SOD（separation of duties）约束，可以有效避免欺诈行为的发生；通过最小权限分配也可以避免在组织和系统内发生大的损失。

RBAC96是被普遍使用的RBAC模型，并较多地应用于工作流管理系统。它对权限（permission）的解释比较宽泛，依赖于模型应用的系统类别，如对文件系统来说，可以是对文件的读写和执行操作；对关系型数据库管理系统来说，则体现在对表和视图等对象的保护，对应的权限可以是对表和视图等的查询、修改、删除等操作。对工作流管理系统来说，权限可以解释为对流程及其任务的访问控制，包括执行、取消等操作。

如上图按照政务系统目前的管理内容及权限控制的需求，本文实现了资源权限管理的基本功能，在用户管理模块包括基于部门、员工数据的用户管理；用户身份验证（基于安全考虑，用户密码采用MD5加密保存）；用户的角色分配；获取用户的角色列表等几部分功能。在任务处理权限控制方面，通过为任务分配角色，并与用户的角色列表进行对照，在用户工作台列表显示用户可以处理的任务实例；并通过在任务定义时设置任务可以读写的业务表字段，达到控制角色用户对业务表的操作权限。

在资源操作权限管理方面，为了提高资源管理的灵活性和可扩展性，系统增加了资源类别的管理。政务系统资源的一级类为“办公桌面”，以区分本系统之外的其它资源类别。

基于WEB程序的特点，为降低资源操作管理的复杂度，在“办公桌面”类别之下又设置了“链接资源”和“按钮资源”等二级类。在“链接资源”类别下对页面板块、菜单等资源进行了细分，使对资源的管理简化为对页面板块、菜单链接地址的管理，而对应的操作主要是“点击链接进入”。这样，可以对不同的部门角色分配不同的板块及菜单链接权限，用户登录后，系统会根据用户编号获取用户角色所拥有的办公板块及菜单链接显示在办公桌面上，使得用户只能看到有限的工作菜单，执行与其角色相匹配的有限操作。如通过设置，可以让国土部门的土地登记人员，只能执行与土地登记业务有关的操作，包括执行土地登记审批业务的特定环节、查询土地登记业务数据、监控土地登记业务流程（包括浏览查询已完成流程、超期限流程等；如果是登记业务主管人员，还可以冻结或取消流程）等。

对按钮资源的管理，目前只在流程监控的“重新指派任务完成人”操作中使用。有权限的用户，如系统管理员等，可以根据需要在浏览“未完成业务流程列表”时，点击“重新指派任务”按钮，执行重新指派任务完成人的操作，以重新启动因员工请假等原因而无法继续的业务过程。没有权限的用户如果点击按钮，系统会拒绝操作的执行并给出提示。

今后，随着办公资源的丰富，还可以进一步增加对按钮操作的控制，如数据的添加、数据的修改等，可以通过对操作界面中添加、修改按钮的限制达到控制资源操作权限的目的。

（三）政务信息交换的安全机制

标准解读
标准核心从政务信息共享模型中所涉及的三方（共享数据提供方、共享数据交换服务方与共享数据使用方）及三阶段（共享数据准备、共享交换和共享数据使用）分析政务数据在共享流转过程中所存在的安全风险，并基于安全风险提出了 144 项安全技术要求，覆盖政务信息共享数据安全技术要求框架，共享数据准备、共享数据交换、共享数据使用阶段及相关基础设施的安全技术要求。
安全技术要求涵盖政务信息共享的全生命周期
标准围绕数据共享阶段划分为三个阶段，分别是准备阶段、交换阶段和使用阶段，而从数据的全生命周期维度来看，即从数据采集、治理、存储、使用及销毁等核心环节，这些环节的要求在三个阶段中均有不同维度的体现，如在数据共享准备阶段，即包含了数据采集、数据治理、数据存储的要求；在数据使用阶段包含了对数据治理、使用及销毁等要求，基本可覆盖数据的全生命周期。另外，从数据的重要性来看，标准主要还是按照一般数据及敏感数据进行大的分类，针对敏感数据会提出更有针对性的安全要求，但在对敏感数据的划分上，标准中并未有明确的指出。
安全技术要求上更加强调国家密码的应用
针对各阶段的数据安全技术应用，标准提出包括数据加密、数据脱敏、数据水印、数据溯源、身份认证、安全传输等安全技术要求，而在涉及使用密码学技术层面的要求上，标准中特别强调要符合 GM/T 0054—2018 等国家相关标准规定的密码技术，一是推进国密算法的应用；二是通过使用国密算法亦能进一步确保底层核心技术的安全性。另外在安全技术要求上，标准中首次提出了数据召回的概念，希望能通过召回技术对失效或敏感数据进行管控，进一步保障在使用过程中的安全，但在标准中未明确如何实现召回的要求。