精华内容
下载资源
问答
  • 安全机制设计原则
    千次阅读
    2020-03-21 16:27:56

    安全机制设计八大原则:

    ①经济性原则(Economy of Mechanism)

    • 安全机制设计尽可能简单短小,从而在排查缺陷、检测漏洞时代码更容易处理

    ②默认拒绝原则(Fail-Safe Defaults)

    • 只要没有授权的信息就不允许访问
    • 不能出现本该允许的请求被拒绝与本该拒绝的请求被允许

    ③完全仲裁原则(Complete Mediation)

    • 授权检查覆盖任何一个访问操作
    • 安全机制又能力标识每一个访问操作请求的所有源头
    • 能够对待为了提高性能而缓存的检查结果

    ④开放设计原则(Open Design)

    • 不将安全机制的设计作为秘密,不将系统安全性寄托在保守安全机制设计秘密的基础上
    • 应在隔开安全机制设计方案的前提下,借助容易保护的特定元素,如密钥、口令等来增强系统的安全性
    • 开放设计有助于安全机制接受广泛的审查

    ⑤特权分离原则(Separation of Privilege)

    • 细分特权,分配给多个主体,减少每个特权拥有者的权利

    ⑥最小特权原则(Least Privilege)

    • 每个程序和每个用户应该只拥有完成工作所需特权的最小集合
    • 限制由意外或错误所引起的破坏
    • 将特权程序之间的潜在交互数降低到正确操作所需的最小值,尽量避免非经意、不必要、不恰当的使用特权

    ⑦最少公共机制原则(Least Common Mechanism)

    • 将多个用户公用或被全体用户依赖的机制数量降到最少

    ⑧心理可接受原则(Psychological Acceptability)

    • 安全机制的良好交互性、安全机制、安全目标的吻合性
    更多相关内容
  • 智能家居的设计原则衡量一个住宅小区智能化系统的成功与否,并非仅仅取决于智能化系统的多少、系统的先进性或集成度,而是取决于系统的设计和配置是否经济合理并且系统能否成功运行,系统的使用、管理和维护是否方便...
  • 桥梁设计原则的模糊评价方法研究,姜英杰,,本文考虑到桥梁设计的基本原则,安全性,适用性,耐性久,美观及经济原则。参照相关的文献和法规结合桥梁设计进行建立了模糊综合
  • 小型数据中心规划和设计原则

    千次阅读 2019-01-13 19:07:44
     为规范电子信息系统机房设计,确保电子信息系统安全、稳定、可靠地运行,做到技术先进、经济合理、安全适用、节能环保等要求。  ●机房虽然是按照重要性进行分级,但不同级别的机房,其投资、系统冗余和能耗是...

    640?wx_fmt=gif

    一、小型数据中心的定义

      数据中心(Data Center)是大范围协作的特定设备网络,用来在Internet网络基础设施上加速信息的传递。又可以细分为企业级数据中心、其他数据中心等。

      企业数据中心(Enterprise Data Center, EDC)通过实现统一的数据定义与命名规范、集中的数据环境,从而达到数据共享与利用的目标。企业数据中心按规模划分为部门级数据中心、企业级数据中心、互联网数据中心以及主机托管数据中心等。其中互联网数据中心(Internet Data Center, IDC)是一种以电信级机房设备向用户提供专业化和标准化的数据存放业务及其它相关服务的中心。用户可通过数据中心的主机托管、整机租赁、虚拟主机等服务,并租用数据中心的技术力量,搭建自己的互联网平台。

      其中,随着时间的推移,小型数据中心的指标定义也不断在变化,在2-3年前,100平米以下的可以定义为小型数据中心,但是随着机房逐渐的集中化、大型化,当前200平米以下的面积的机房定义为小型数据中心更为贴切。具体划分请参看下表:

    640?wx_fmt=jpeg


    二、构建小型数据中心的几个核心要素

    • 整体设计

    1、选址问题

      数据中心具有极高的安全性要求,一旦发生问题将会影响社会的正常生产、生活。因此,即使发生诸如地震、水灾、雷击等自然灾害和机器设备发生故障、火灾等偶然事件,数据中心也必须具备很高的安全可靠性以保证业务不会停止。提高安全可靠性可通过各种手段实现,比如构筑具有冗余性的系统和构筑较易修补故障的系统等等。但是数据中心地理位置的合理规划对提高“灾害回避性”是极为重要的。在调查用地位置有关项目和用地本身的性状时,必须对自然条件和社会条件从过去到未来进行多方面研究。

      其中,《电子计算机机房设计规范》(GB 50174-93)中规定,电子信息系统机房位置选择应符合下列要求:

      ◆水源充足,电力比较稳定可靠,交通通信方便,自然环境清洁;

      ◆远离产生粉尘、油烟、有害气体以及生产或贮存具有腐蚀性、易燃、易爆物品的工厂、仓库、堆场等;

      ◆远离水灾隐患区域;

      ◆远离强振源和强噪声源;

      ◆避开强电磁场干扰。

      另外国内《电子信息系统机房设计规范》(GB 50174—征求意见稿)应该很快就会有个明确的结果,里面会对选址有更详细的说明,在这里不再赘述。

    ANSI/TIA-942-2005标准附录F中关于选址的有关参考:

      ◆数据中心不应靠近附近机场的飞行航线。

      ◆与铁路及及高速公路距离大于800m,以保证降低化学物质溅落危险。

      ◆与军事基地距离大于800m,与核设施、国防设施等大于1600m。

      ◆其它注意事项:污染风险/接近警察局、消防队、医院、地区规划、多路接入、震动问题、环境问题。

    2、数据中心规划与设计

      建设的数据中心应当满足当前与未来的需要,在规划时,要注意以下几点需求:

    A、解决系统过热问题

      传统数据中心普遍存在局部过热的问题。传统数据中心因设计不合理而制冷不能按实际设备的需要进行分配,导致总体能源浪费高且存在局部过热而宕机。机房空调设置不合理,没有采用机房专用的精密空调,而是直接采用了家庭舒适性空调。电源线缆布放过细,存在重大的安全隐患。没有配备保障电源,机房的设备安全运行无法保证。

      科学的数据中心动力配置,成本会在建设初期提高,相比由此带来的系统稳定运营带来的业务高可靠性,同时体现出的节能减耗带来的低成本价值。

    B、解决系统宕机问题

      大量企、事业等都会自己建设或者通过电信服务商,IDC运营服务商等拥有自己的机房,但是由于各种原因会出现数据中心停机和暂时关闭的情况,会给企业带来不可估量的损失。第一、建立自身的灾备中心,除了IT支撑之外,灾备中应该加入业务影响分析、策略制定、业务恢复预案、人员架构、通信保障、第三方合作机构等,成为业务连续性规划(BCP)。第二、对关键设备进行N+x冗余备份,尽量减少在设备自身的问题。

    C、注重整体的绿色节能问题

      所谓数据中心的“绿色”,业界标准并不统一,也没有形成可以参考的规范。笔者认为,绿色标准可以体现在两个方面:第一、整体设计的科学合理和设备的节能环保。绿色应该体现在通过科学的机房配置建设设计或改善,来形成动力环境最优化的配置,实现初始投入最小化;在保障机房设备稳定运营的同时,达到节能减耗;同时服务器、网络存储等设备要实现最大化的效能比。第二、满足IT环境的基本运营,同时确保可扩展性。要合理规划数据中心的使用寿命,争取达到总体TCO最小化。

    D、关注数据中心的重点设计

      为规范电子信息系统机房设计,确保电子信息系统安全、稳定、可靠地运行,做到技术先进、经济合理、安全适用、节能环保等要求。

      ●机房虽然是按照重要性进行分级,但不同级别的机房,其投资、系统冗余和能耗是不同的。级别高的机房,系统冗余较高,相对来说,其投资和能耗也较高。在满足系统可靠性的前提下,合理确定机房等级和系统配置,可以降低投资,减少能源消耗。

      ●当机柜内或机架上的设备为前进风/后出风方式冷却时,机柜或机架的布置宜采用面对面、背对背方式。

      ●A级和B级电子信息系统机房的主机房不宜设置外窗。当主机房设有外窗时,应采用双层固定窗,并应有良好的气密性。

      ●空调设计应根据当地气候条件,选择采用以下节能措施:大型机房宜采用水冷冷水机组空调系统;北方地区采用水冷冷水机组的机房,冬季可利用室外冷却塔作为冷源,通过热交换器对空调冷冻水进行降温;空调系统可采用电制冷与自然冷却相结合的方式。

      ●主机房和辅助区内的主要照明光源应采用高效节能荧光灯,其镇流器的谐波限值应符合国家标准GB17625.1的规定,灯具应采用分区、分组的控制措施。

    (二)产品选择与布局

    1、电源选择

      针对小型数据中心,UPS等电源系统应该采用节省空间的紧凑式设计,具有内置旁路维护开关以及可扩展的电池,尽量降低用户的总体拥有成本。还应具有用户友好的智能及系统管理功能。

      采用产品应该兼顾产品的成本和性能,达到IT管理人员对总体拥有成本的需求,在一些小型数据中心,IT管理人员常常必须自己对部分电源解决方案进行管理和维护,身边没有电源专业人员,所以采购产品要性能非常良好,同时易于管理。

      所选产品还应配有范围广泛的可选附件,如具有环境监测功能的网络管理卡。利用这种网络管理卡,用户可以对UPS进行远程或基于Web的管理。能够与系统管理器整合,实现对整个数据中心的轻松管理。

    2、空调的选择

      数据中心各设备产生的热量需采用空气冷却的方法去解决,数据中心的最佳制冷设备就是机房专用精密空调。数据中心和网络系统的IT硬件运行时会产生大量集中的热量,同时对温度和湿度的变化也极其敏感,温度和湿度的轻微浮动,就可能导致系统发生严重问题;在IT设备机房中,热负荷几乎全部来自IT硬件、照明设备、支持设备和发动机散发的显热,IT设备机房含有很少的潜热,因为人员较少,外部空气有限,物理结构上还往往含有防潮层。

      ●对于东北地区的城市来说,四季分明,冬天温度相对比较低,所以不适宜使用水冷系列,自然冷却冷水主机加冷冻水机组的节能效果很明显,耗电量明显减少。

      ●对于华北地区的城市而言,自然冷却冷水机组加冷冻水机组可以比普通冷水主机加冷冻水机组节能30%,和其他空调系统相比耗电量也明显减少,节能效果显著。

    ●对于平均温度很高的华东、华南地区的城市,水冷冷水主机加冷冻水机组的系统总投资较少,在计算设备制冷总功率和耗电量时,直接蒸发式机组较高,水冷冷水主机加冷冻水机组系统较风冷直接蒸发式机组要节能可达到20%左右。

    3、设备的布局

    A、机柜摆放

      在现代机房的机柜布局中,人们为了美观和便于观察会将所的的机柜朝同一个方向摆放,如果按照这种摆放方式,机柜盲板有效阻挡冷热空气的效果将大大折扣。正确的摆放方式应该是将服务器机柜面对面或背对背的摆放方式摆放,这样变形成了冷风通道和热风通道,机柜之间的冷热风不会混合在一起,形成短路气流,大大提到制冷效果,保护好冷热通道不被破坏。

    B、IT设备摆放

      随着服务器的小形化、高密度化、刀片式服务器的产生,这些服务器摆放的位置越来越不容IT管理者的忽视,高功率设备发热量大,比普通IT设备可能要高1倍或更多,如果将这些高功率负载和高密度的服务器组合摆放在一个机柜内,这样便会出现一个高密设备度群形成了一个巨大的发热群体,这种情况最容易导致数据中心的局部热点,IT管理人员不得不降低整个机房环境的温度或是添加专门的制冷设备,来处理这个局部发热点;针对这样的问题,可以将这些高功率设备和高密度服务器均分在每个机柜内,这样就不会出现高功率高密度设备群,也无法形成数据中心的热点和冷却的难点,将降低制冷设备运行费用和采购费用。

    三、构建小型数据中心的几个需注意的问题

    1、基础设施与动力环境设计、安装合理

      第一,数据中心应配置保证电源,至少配置N+x的UPS电源,确保市电中断以后能确保设备正常运行。如果条件可以,应该再配置一台发电机,确保市电中断时间过长造成的影响。

      第二,数据中心要配置机房专用的精密空调,并做好整体监控,能够根据机房环境和湿度的变化随时对空调的运行进行调节。

      第三,数据中心要建设专用的送风通道。数据中心的设备由于能耗大,发热量也大,下送风方式效果最好,因此必须在机房设置地板,建立专用的下送风通道。

      第四,要进行专门的规划。要根据公司的发展做好规划,最好能对机房进行全面的规划,然后根据业务发展的需要分步实施。只有这样,机房的建设才会正规,才不会出现电源线缆发热的情况。

    2、重点关注耗能的各个部分,严防超标

      第一、IT设备系统。由服务器、存储和网络通信等设备所产生的功耗约占数据中心机房所需的总功耗的50%左右。其中服务器所占的总功耗为40%左右,另外10%功耗由存储设备和网络通信设备均分。

      第二、空调系统。由它所产生的功耗约占数据中心机房所需的总功耗的37%左右。其中25%左右的功耗来源于空调的制冷系统所产生的功耗,12%左右的功耗来源于空调送风和回风系统所产生的功耗。

      第三、UPS供电系统。它们的功耗约占机房总功耗的10%左右。其中7%左右来源于UPS供电系统所产生的功耗,3%左右来源于UPS输入供电系统系统所产生的功耗。

      第四、照明系统。它约占数据中心机房所需的功耗的3%左右。

    3、注重数据中心的整体成本,达到最大效用比

      构建小型数据中心更应该注重节能和可持续发展,因为随着业务的发展,机房随时可能进行改建和扩建。数据中心的建设不仅仅是服务器、存储等设备的性价比问题,数据中心本身的建设也要遵循环保规范。一般来说,一提起数据中心的绿色环保措施,人们首先想到的就是减少能耗、增添能效、减少空调数量以便节省能源等,措施基本都集中在对硬件设备的改造上。软件同样也是实现数据中心绿色节能环保的主要手段。软件为绿色数据中心做的最大贡献体现在,软件可以改变数据中心中数据系统的架构,从而带来服务器使用数量以及服务器中各种硬件设备的减少,由此实现绿色数据中心的目标。

    640?wx_fmt=png

    资料免费送(点击链接下载)

    史上最全,数据中心机房标准及规范汇总(下载)

    数据中心运维管理 | 资料汇总(2017.7.2版本)                                         

    加入运维管理VIP群(点击链接查看)

    《数据中心运维管理》VIP技术交流群会员招募说明

    扫描以下二维码加入学习群

    640?wx_fmt=jpeg

    展开全文
  • 数据库设计的基本规范和原则

    千次阅读 2017-08-11 09:03:52
    关键字: 数据库建表原则·1. 原始单据与实体之间的关系可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体。在特殊情况下,它们可能是一对多或多对一的...

    关键字: 数据库建表原则

    ·1. 原始单据与实体之间的关系

    可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体。在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后,对我们设计录入界面大有好处。

    〖例〗:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。

     

    ·2. 主键与外键

    一般而言,一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键,也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。

    主键与外键的设计,在全局数据库的设计中,占有重要地位。当全局数据库的设计完成以后,有个美国数据库设计专家说:“键,到处都是键,除了键之外,什么也没有”,这就是他的数据库设计经验之谈,也反映了他对信息系统核心(数据模型)的高度抽象思想。因为:主键是实体的高度抽象,主键与外键的配对,表示实体之间的连接。

     

    ·3. 基本表的性质

    基本表与中间表、临时表不同,因为它具有如下四个特性:

    (1) 原子性。基本表中的字段是不可再分解的。

    (2) 原始性。基本表中的记录是原始数据(基础数据)的记录。

    (3) 演绎性。由基本表与代码表中的数据,可以派生出所有的输出数据。

    (4) 稳定性。基本表的结构是相对稳定的,表中的记录是要长期保存的。

    理解基本表的性质后,在设计数据库时,就能将基本表与中间表、临时表区分开来。

     

    ·4. 范式标准

    基本表及其字段之间的关系, 应尽量满足第三范式。但是,满足第三范式的数据库设计,往往不是最好的设计。为了提高数据库的运行效率,常常需要降低范式标准:适当增加冗余,达到以空间换时间的目的。

    〖例〗:有一张存放商品的基本表,如表1所示。“金额”这个字段的存在,表明该表的设计不满足第三范式,因为“金额”可以由“单价”乘以“数量”得到,说明“金额”是冗余字段。但是,增加“金额”这个冗余字段,可以提高查询统计的速度,这就是以空间换时间的作法。

    在Rose 2002中,规定列有两种类型:数据列和计算列。“金额”这样的列被称为“计算列”,而“单价”和“数量”这样的列被称为“数据列”。

    表1 商品表的表结构

    商品名称  商品型号  单价  数量   金额

    电视机    29吋      2,500  40  100,000

     

    ·5. 通俗地理解三个范式

    通俗地理解三个范式,对于数据库设计大有好处。在数据库设计中,为了更好地应用三个范式,就必须通俗地理解三个范式(通俗地理解是够用的理解,并不是最科学最准确的理解):

    第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解;

    第二范式:2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性;

    第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余.

    没有冗余的数据库设计可以做到。但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,允许冗余。

     

    ·6. 要善于识别与正确处理多对多的关系

    若两个实体之间存在多对多的关系,则应消除这种关系。消除的办法是,在两者之间增加第三个实体。这样,原来一个多对多的关系,现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体,实质上是一个较复杂的关系,它对应一张基本表。一般来讲,数据库设计工具不能识别多对多的关系,但能处理多对多的关系。

    〖例〗:在“图书馆信息系统”中,“图书”是一个实体,“读者”也是一个实体。这两个实体之间的关系,是一个典型的多对多关系:一本图书在不同时间可以被多个读者借阅,一个读者又可以借多本图书。为此,要在二者之间增加第三个实体,该实体取名为“借还书”,它的属性为:借还时间、借还标志(0表示借书,1表示还书),另外,它还应该有两个外键(“图书”的主键,“读者”的主键),使它能与“图书”和“读者”连接。

     

    ·7. 主键PK的取值方法

    PK是供程序员使用的表间连接工具,可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时,建议字段的个数不要太多,多了不但索引占用空间大,而且速度也慢。

     

    ·8. 正确认识数据冗余

    主键与外键在多表中的重复出现,不属于数据冗余,这个概念必须清楚,事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余!而且是一种低级冗余,即重复性的冗余。高级冗余不是字段的重复出现,而是字段的派生出现。

    〖例〗:商品中的“单价、数量、金额”三个字段,“金额”就是由“单价”乘以“数量”派生出来的,它就是冗余,而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性,因为同一数据,可能从不同时间、地点、角色上多次录入。因此,我们提倡高级冗余(派生性冗余),反对低级冗余(重复性冗余)。

    消费流水表的 原余额,现余额,消费金额其中原余额冗余 ,但是也要保留。

     

    ·9. E–R图没有标准答案

    信息系统的E–R图没有标准答案,因为它的设计与画法不是惟一的,只要它覆盖了系统需求的业务范围和功能内容,就是可行的。反之要修改E–R图。尽管它没有惟一的标准答案,并不意味着可以随意设计。好的E—R图的标准是:结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。

     

    ·10. 视图技术在数据库设计中很有用

    与基本表、代码表、中间表不同,视图是一种虚表,它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口,是基表数据综合的一种形式, 是数据处理的一种方法,是用户数据保密的一种手段。为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。

    对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统,视图的作用更加重要。这些系统的基本表完成物理设计之后,立即在基本表上建立第一层视图,这层视图的个数和结构,与基本表的个数和结构是完全相同。并且规定,所有的程序员,一律只准在视图上操作。只有数据库管理员,带着多个人员共同掌握的“安全钥匙”,才能直接在基本表上操作。请读者想想:这是为什么?

     

    ·11. 中间表、报表和临时表

    中间表是存放统计数据的表,它是为数据仓库、输出报表或查询结果而设计的,有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的,存放临时记录,为个人所用。基表和中间表由DBA维护,临时表由程序员自己用程序自动维护。

     

    ·12. 完整性约束表现在三个方面

    域的完整性:用Check来实现约束,在数据库设计工具中,对字段的取值范围进行定义时,有一个Check按钮,通过它定义字段的值城。参照完整性:用PK、FK、表级触发器来实现。用户定义完整性:它是一些业务规则,用存储过程和触发器来实现。

     

    ·13. 防止数据库设计打补丁的方法是“三少原则”

    (1) 一个数据库中表的个数越少越好。只有表的个数少了,才能说明系统的E–R图少而精,去掉了重复的多余的实体,形成了对客观世界的高度抽象,进行了系统的数据集成,防止了打补丁式的设计;

    (2) 一个表中组合主键的字段个数越少越好。因为主键的作用,一是建主键索引,二是做为子表的外键,所以组合主键的字段个数少了,不仅节省了运行时间,而且节省了索引存储空间;

    (3) 一个表中的字段个数越少越好。只有字段的个数少了,才能说明在系统中不存在数据重复,且很少有数据冗余,更重要的是督促读者学会“列变行”,这样就防止了将子表中的字段拉入到主表中去,在主表中留下许多空余的字段。所谓“列变行”,就是将主表中的一部分内容拉出去,另外单独建一个子表。这个方法很简单,有的人就是不习惯、不采纳、不执行。

    数据库设计的实用原则是:在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念,综合观点,不能孤立某一个原则。该原则是相对的,不是绝对的。“三多”原则肯定是错误的。试想:若覆盖系统同样的功能,一百个实体(共一千个属性) 的E–R图,肯定比二百个实体(共二千个属性) 的E–R图,要好得多。

    提倡“三少”原则,是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库,将应用数据库集成为主题数据库,将主题数据库集成为全局综合数据库。集成的程度越高,数据共享性就越强,信息孤岛现象就越少,整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数就会越少。

    提倡“三少”原则的目的,是防止读者利用打补丁技术,不断地对数据库进行增删改,使企业数据库变成了随意设计数据库表的“垃圾堆”,或数据库表的“大杂院”,最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章,不计其数,导致企事业单位的信息系统无法维护而瘫痪。

    “三多”原则任何人都可以做到,该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则,它要求有较高的数据库设计技巧与艺术,不是任何人都能做到的,因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。

     

    ·14. 提高数据库运行效率的办法

    在给定的系统硬件和系统软件条件下,提高数据库系统的运行效率的办法是:

    (1) 在数据库物理设计时,降低范式,增加冗余, 少用触发器, 多用存储过程。

    (2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条),复杂计算要先在数据库外面,以文件系统方式用C++语言计算处理完成之后,最后才入库追加到表中去。这是电信计费系统设计的经验。

    (3) 发现某个表的记录太多,例如超过一千万条,则要对该表进行水平分割。水平分割的做法是,以该表主键PK的某个值为界线,将该表的记录水平分割为两个表。若发现某个表的字段太多,例如超过八十个,则垂直分割该表,将原来的一个表分解为两个表。

    (4) 对数据库管理系统DBMS进行系统优化,即优化各种系统参数,如缓冲区个数。

    (5) 在使用面向数据的SQL语言进行程序设计时,尽量采取优化算法

    总之,要提高数据库的运行效率,必须从数据库系统级优化、数据库设计级优化、程序实现级优化,这三个层次上同时下功夫。

     

    上述十四个技巧,是许多人在大量的数据库分析与设计实践中,逐步总结出来的。对于这些经验的运用,读者不能生帮硬套,死记硬背,而要消化理解,实事求是,灵活掌握。并逐步做到:在应用中发展,在发展中应用。

     

    本文来自CSDN博客,转载请标明出处:

    http://blog.csdn.NET/lovegod12/archive/2009/03/13/3986346.aspx

     

     

     

     

     

     

    SQL数据库建表前期优化

    关于数据库优化方面的文章很多,但是有的写的似是而非,有的不切实际,对一个数据库来说,只能做到更优,不可能最优,并且由于实际需求不同,优化方案还是有所差异,根据实际需要关心的方面(速度、存储空间、可维护性、可拓展性)来优化数据库,而这些方面往往又是相互矛盾的,下面结合网上的一些看法和自己的一些观点做个总结。

      一个系统的性能的提高,不单单是试运行或者维护阶段的性能调优,也不单单是开发阶段的事情,而是在整个软件生命周期都需要注意。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。

     

      一、 分析阶段

     

      一般来说,在系统分析阶段往往有太多需要关注的地方,系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力,但是,我们必须注意,性能是很重要的非功能性需求,必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。

      另一方面,在分析阶段应该根据各种需求区分出系统的类型,大的方面,区分是OLTP(联机事务处理系统)和OLAP(联机分析处理系统)。

     

      二、 设计阶段

     

      设计阶段可以说是以后系统性能的关键阶段,在这个阶段,有一个关系到以后几乎所有性能调优的过程—数据库设计。

      在数据库设计完成后,可以进行初步的索引设计,好的索引设计可以指导编码阶段写出高效率的代码,为整个系统的性能打下良好的基础。

      以下是性能要求设计阶段需要注意的:

      1、数据库逻辑设计的规范化

      数据库逻辑设计的规范化就是我们一般所说的范式,我们可以这样来简单理解范式:

      第1规范:没有重复的组或多值的列,这是数据库设计的最低要求。

    第2规范: 每个非关键字段必须依赖于主关键字,不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖,大部分情况下,数据库设计都应该达到第二范式。

      第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖,达到第三范式应该是系统中大部分表的要求,除非一些特殊作用的表。

      更高的范式要求这里就不再作介绍了,个人认为,如果全部达到第二范式,大部分达到第三范式,系统会产生较少的列和较多的表,因而减少了数据冗余,也利于性能的提高。

      2、合理的冗余

      完全按照规范化设计的系统几乎是不可能的,除非系统特别的小,在规范化设计后,有计划地加入冗余是必要的。

      冗余可以是冗余数据库、冗余表或者冗余字段,不同粒度的冗余可以起到不同的作用。

      冗余可以是为了编程方便而增加,也可以是为了性能的提高而增加。从性能角度来说,冗余数据库可以分散数据库压力,冗余表可以分散数据量大的表的并发压力,也可以加快特殊查询的速度,冗余字段可以有效减少数据库表的连接,提高效率。

      3、主键的设计

      主键是必要的,SQLSERVER的主键同时是一个唯一索引,而且在实际应用中,我们往往选择最小的键组合作为主键,所以主键往往适合作为表的聚集索引。聚集索引对查询的影响是比较大的,这个在下面索引的叙述。

      在有多个键的表,主键的选择也比较重要,一般选择总的长度小的键,小的键的比较速度快,同时小的键可以使主键的B树结构的层次更少。

      主键的选择还要注意组合主键的字段次序,对于组合主键来说,不同的字段次序的主键的性能差别可能会很大,一般应该选择重复率低、单独或者组合查询可能性大的字段放在前面。

      4、外键的设计

    外键作为数据库对象,很多人认为麻烦而不用,实际上,外键在大部分情况下是很有用的,理由是:

      外键是最高效的一致性维护方法,数据库的一致性要求,依次可以用外键、CHECK约束、规则约束、触发器、客户端程序,一般认为,离数据越近的方法效率越高。

      谨慎使用级联删除和级联更新,级联删除和级联更新作为SQL SERVER 2000当年的新功能,在2005作 了保留,应该有其可用之处。我这里说的谨慎,是因为级联删除和级联更新有些突破了传统的关于外键的定义,功能有点太过强大,使用前必须确定自己已经把握好其功能范围,否则,级联删除和级联更新可能让你的数据莫名其妙的被修改或者丢失。从性能看级联删除和级联更新是比其他方法更高效的方法。

      5、字段的设计

      字段是数据库最基本的单位,其设计对性能的影响是很大的。需要注意如下:

      A、数据类型尽量用数字型,数字型的比较比字符型的快很多。

      B、数据类型尽量小,这里的尽量小是指在满足可以预见的未来需求的前提下的。

      C、尽量不要允许NULL,除非必要,可以用NOT NULL+DEFAULT代替。

      D、少用TEXT和IMAGE,二进制字段的读写是比较慢的,而且,读取的方法也不多,大部分情况下最好不用。

      E、自增字段要慎用,不利于数据迁移。

      6、数据库物理存储和环境的设计

      在设计阶段,可以对数据库的物理存储、操作系统环境、网络环境进行必要的设计,使得我们的系统在将来能适应比较多的用户并发和比较大的数据量。

      这里需要注意文件组的作用,适用文件组可以有效把I/O操作分散到不同的物理硬盘,提高并发能力。

      7、系统设计

      整个系统的设计特别是系统结构设计对性能是有很大影响的,对于一般的OLTP系统,可以选择C/S结构、三层的C/S结构等,不同的系统结构其性能的关键也有所不同。

    系统设计阶段应该归纳一些业务逻辑放在数据库编程实现,数据库编程包括数据库存储过程、触发器和函数。用数据库编程实现业务逻辑的好处是减少网络流量并可更充分利用数据库的预编译和缓存功能。

      8、索引的设计

      在设计阶段,可以根据功能和性能的需求进行初步的索引设计,这里需要根据预计的数据量和查询来设计索引,可能与将来实际使用的时候会有所区别。

      关于索引的选择,应该主意:

      A、根据数据量决定哪些表需要增加索引,数据量小的可以只有主键。

      B、根据使用频率决定哪些字段需要建立索引,选择经常作为连接条件、筛选条件、聚合查询、排序的字段作为索引的候选字段。字段(列)允许为空一般来说不建立索引。

      C、把经常一起出现的字段组合在一起,组成组合索引,组合索引的字段顺序与主键一样,也需要把最常用的字段放在前面,把重复率低的字段放在前面。

    D、一个表不要加太多索引,因为索引影响插入和更新的速度。

    本篇文档来自:

    http://hi.baidu.com/zhnantz/blog/item/2349a1019be1a9c7277fb5b5.html


     

    SQL数据库操作优化

    1.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:

    select id from t where num is null

    可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:

    select id from t where num=0

    2.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。

    3.应尽量避免在 where 子句中使用 or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,如:

    select id from t where num=10 or num=20

    可以这样查询:

    select id from t where num=10

    union all

    select id from t where num=20

    4.in和 not in 也要慎用,因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如:

    select id from t where num in(1,2,3)

    对于连续的数值,能用 between 就不要用 in 了

    select id from t where num between 1 and 3

    5.尽量避免在索引过的字符数据中,使用非打头字母搜索。这也使得引擎无法利用索引

    见如下例子:

    SELECT * FROM T1 WHERE NAME LIKE ‘%L%’  –搜索含有L的

    SELECT * FROM T1 WHERESUBSTING(NAME,2,1)=’L’

    SELECT * FROM T1 WHERE NAME LIKE ‘L%’    –搜索开头是L的

    即使NAME字段建有索引,前两个查询依然无法利用索引完成加快操作,引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。

    6.必要时强制查询优化器使用某个索引,如在 where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描:

    select id from t where num=@num

    可以改为强制查询使用索引:

    select id from t with(index(索引名)) where num=@num

    7.应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。尽量使用列名=表达式。如:

    SELECT * FROM T1 WHERE F1/2=100

    应改为:

    SELECT * FROM T1 WHERE F1=100*2

     

    SELECT * FROM RECORD WHERESUBSTRING(CARD_NO,1,4)=’5378’

    应改为:

    SELECT * FROM RECORD WHERE CARD_NO LIKE‘5378%’

     

    SELECT member_number, first_name, last_nameFROM members

    WHERE DATEDIFF(yy,datofbirth,GETDATE())> 21

    应改为:

    SELECT member_number, first_name, last_nameFROM members

    WHERE dateofbirth <DATEADD(yy,-21,GETDATE())

    即:任何对列的操作都将导致表扫描,它包括数据库函数、计算表达式等等,查询时要尽可能将操作移至等号右边。

    8.应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。如:

    select id from t wheresubstring(name,1,3)=’abc’–name以abc开头的id

    select id from t wheredatediff(day,createdate,’2005-11-30’)=0–‘2005-11-30’生成的id

    应改为:

    select id from t where name like ‘abc%’

    select id from t wherecreatedate>=’2005-11-30’ and createdate<’2005-12-1’

    9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。

    10.在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。

    11.很多时候用 exists是一个好的选择,尽量用exists代替in:

    select num from a where num in(select numfrom b)

    用下面的语句替换:

    select num from a where exists(select 1from b where num=a.num)

     

    SELECT SUM(T1.C1)FROM T1 WHERE(

    (SELECT COUNT(*)FROM T2 WHERET2.C2=T1.C2>0)

    用下面的语句替换:

    SELECT SUM(T1.C1) FROM T1WHERE EXISTS(

    SELECT * FROM T2 WHERE T2.C2=T1.C2)

    两者产生相同的结果,但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。

    如果你想校验表里是否存在某条纪录,不要用count(*)那样效率很低,而且浪费服务器资源。可以用EXISTS代替。如:

    IF (SELECT COUNT(*) FROM table_name WHEREcolumn_name = ‘xxx’)

    可以写成:

    IF EXISTS (SELECT * FROM table_name WHEREcolumn_name = ‘xxx’)

    经常需要写一个T_SQL语句比较一个父结果集和子结果集,从而找到是否存在在父结果集中有而在子结果集中没有的记录,如:

    SELECT a.hdr_key FROM hdr_tbl a—- tbl a 表示tbl用别名a代替

    WHERE NOT EXISTS (SELECT * FROM dtl_tbl bWHERE a.hdr_key = b.hdr_key)

    SELECT a.hdr_key FROM hdr_tbl a

    LEFT JOIN dtl_tbl b ON a.hdr_key =b.hdr_key WHERE b.hdr_key IS NULL

    SELECT hdr_key FROM hdr_tbl

    WHERE hdr_key NOT IN (SELECT hdr_key FROMdtl_tbl)

    三种写法都可以得到同样正确的结果,但是效率依次降低。

    效率:exists>inner(left,right)join>in

    12.尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。

    13.避免频繁创建和删除临时表,以减少系统表资源的消耗。

    14.临时表并不是不可使用,适当地使用它们可以使某些例程更有效,例如,当需要重复引用大型表或常用表中的某个数据集时。但是,对于一次性事件,最好使用导出表。

    15.在新建临时表时,如果一次性插入数据量很大,那么可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果数据量不大,为了缓和系统表的资源,应先createtable,然后insert。

    16.如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先 truncate table TableName,然后 drop tableTableName,这样可以避免系统表的较长时间锁定。

    17.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。

    18.尽量避免大事务操作,提高系统并发能力。

    19.尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。

    20. 避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如:

    SELECTname FROM employee WHERE salary > 60000

    在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。

    21.充分利用连接条件,在某种情况下,两个表之间可能不只一个的连接条件,这时在 WHERE 子句中将连接条件完整的写上,有可能大大提高查询速度。

    例:

    SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD BWHERE A.CARD_NO = B.CARD_NO

    SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD BWHERE A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO=B.ACCOUNT_NO

    第二句将比第一句执行快得多。

    22、使用视图加速查询

    把表的一个子集进行排序并创建视图,有时能加速查询。它有助于避免多重排序操作,而且在其他方面还能简化优化器的工作。例如:

    SELECT cust.name,rcvbles.balance,……other columns

    FROM cust,rcvbles

    WHERE cust.customer_id =rcvlbes.customer_id

    AND rcvblls.balance>0

    AND cust.postcode>“98000”

    ORDER BY cust.name

    如果这个查询要被执行多次而不止一次,可以把所有未付款的客户找出来放在一个视图中,并按客户的名字进行排序:

    CREATE VIEW DBO.V_CUST_RCVLBES

    AS

    SELECT cust.name,rcvbles.balance,……other columns

    FROM cust,rcvbles

    WHERE cust.customer_id =rcvlbes.customer_id

    AND rcvblls.balance>0

    ORDER BY cust.name

    然后以下面的方式在视图中查询:

    SELECT * FROM V_CUST_RCVLBES

    WHERE postcode>“98000”

    视图中的行要比主表中的行少,而且物理顺序就是所要求的顺序,减少了磁盘I/O,所以查询工作量可以得到大幅减少。

    23、能用DISTINCT的就不用GROUP BY

    SELECT OrderID FROM Details WHERE UnitPrice> 10 GROUP BY OrderID

    可改为:

    SELECT DISTINCT OrderID FROM Details WHEREUnitPrice > 10

    24.能用UNION ALL就不要用UNION

    UNION ALL不执行SELECT DISTINCT函数,这样就会减少很多不必要的资源。 

    25.尽量不要用SELECT INTO语句。

    SELECTINTO 语句会导致表锁定,阻止其他用户访问该表。

     

    上面我们提到的是一些基本的提高查询速度的注意事项,但是在更多的情况下,往往需要反复试验比较不同的语句以得到最佳方案。最好的方法当然是测试,看实现相同功能的SQL语句哪个执行时间最少,但是数据库中如果数据量很少,是比较不出来的,这时可以用查看执行计划,即:把实现相同功能的多条SQL语句考到查询分析器,按CTRL+L看查所利用的索引,表扫描次数(这两个对性能影响最大),总体上看询成本百分比即可。

    http://www.cnblogs.com/yongheng178/archive/2010/09/18/1829989.html

     


     

    数据库命名规范

    表1. 基本数据库对象命名

    数据库对象

    前缀

    举例

    表(Table)

    Student

    字段、列(Column)

    Title,CustomerName

    视图(View)

    v或vw

    vActivity,VW_Car

    存储过程(Stored procedure)

    pr或proc

    prDelOrder

    触发器(Trigger)

    tr或trig

    trOrder_D

    索引(Index)

    ix_

    ix_CustomerID

    主键(Primary key)

    PK_

    PK_Admin

    外键(Foreign key)

    Fk_

    FK_Order_OrderType

    Check约束(Check Constraint)

    CH_

    CK_TableColumn

    Unique约束

    UQ_

    UQ_TableColumn

    Default默认值

    DF_

    DF_Status

    用户定义数据类型(User-defined data type)

    udt

    udtPhone

    用户定义函数(User-defined function)

    FN或Fun_

    fnDueDate

     

    (1)表格、字段的命名:

    单数表名、字段名 还是 复数表名、字段名  (用单数来命名表名)?可能大家很少会考虑到给表名起单数还是复数,比如,对存储客人信息的表,我们应该起Customer,还是Customers?我主张起单数表名,下面是来自《SQL Server 2000 宝典》的一段引用:主张用复数表名的阵营认为:表是由一组记录构成的,所以应当使用复数名词来命名它。他们经常使用的理由是:客户表是客户们的集合,而集合意味着多个,因此应当称他们为Customers表。除非你只有一个客户,但这种情况你根本用不着数据库。根据笔者的非正式调查,有3/4的SQL Server开发人员支持使用单数命名。这些开发人员认为,客户表是客户的集合,而不是客户们的集合。一组行不应当也不会被成为rows set(行们的集合),而会被称为row set(行集)。并且,通常在讨论时人们会使用单数名称来称呼表,说Customer表比说Customers表听起来更为清晰,避免无谓的表格后缀(没必要添加无所谓的后缀)。特殊情况下可以加复数,如用户表User,而User是数据库关键字,如果使用User表的时候,一般这样select * from [User]。此时最好使用Users

    这两点我想大家都知道:1、表是用来存储数据信息的。2、表是行的集合。那么如果表名已经能够很好地说明其包含的数据信息,就不需要再添加体现上面两点的后缀了。

    (2)多对多关系中连接表(中间表)的命名

    大家知道,如果要实现两个实体间的多对多关系,需要三张表,其中一张是解析表。考虑下面这样一个多对多关系,这是一个经典的学生选课问题:一个学生可以选很多门课,一门课可以有很多学生。此时为了实现上面的关系,就需要一张解析表(这张表只存储学生ID和课程ID,而学生的信息和课程信息分别存在各自的表中),这个表的起名,建议的写法是将两个表的表名合并(如果表名比较长可做简化),此处如 StudentCourse。这个表中字段分别命名为StudentId、CourseID(既是此表的复合主键,同时分别为连接Student表和Course表的外键,等下到主键和外键的命名处再说),这样就实现了学生和课程之间的多对多关系,当然,这个关系还可以加点额外的东西,比如给StudentCourse表中加AccessLevel字段,值域D{只读,完全,禁止},就可以实现访问级别。

    (3)约定俗成的字段名前/后缀

    数据库开发的时间久了,慢慢就会摸索出一个规律来:就是很多的字段都有些共同的特性。比如说,有的字段是代表时间的(例如发帖时间,评论时间),有的是代表数量的(例如浏览数,评论数),有的是代表真假类型的(例如是否将博客随笔显示在首页)。对于这种同一类型的字段,应该使用统一的 前缀或者 后缀去标识它。

    我们来举几个例子看得更明白一点。

    以大家都熟悉的论坛来说,需要记录会员最后一次登录的时间,这时候一般人都会把这个字段命名为LoginTime 或者 LoginDate。这时候,已经产生了一个歧义:对于另一名开发者来说,如果仅看表的字段名称,不去看表的内容,很容易将LoginTime理解成 登录的次数,因为,Time还有一个很常用的意思,就是次数。为了避免这种情况发生,应该明确的规定:所有表示时间的字段,统一以 Date 来作为结尾。我们经常需要统计发帖数、回帖数信息,这时候,开发人员通常会这样去命名字段:PostAmount、PostTime、PostCount,同样,由于Time的歧义,我们首先排除掉不使用PostTime作为字段名。接下来,Amount 和 Count 都可以表示计数的意思,用哪个合适呢?这里,我推荐使用Count。为什么呢?如果你做过Asp开发,相信一定知道 RecordCount 这个属性,命名的时候有一个原则:就是使用约定俗成的名称,而不要去自创名称。既然微软都用Count后缀来表示数目,我们为什么不呢?

    于是,所有表示数目的字段,都应该以Count作为结尾。将这一概念做以推广,很容易得出,浏览次数为 ViewCount,登录次数为LoginCount 等等。再举一个例子,我们很少在数据库里直接保存图片等二进制数据,通常是仅保存图片的URL路径;在文章管理系统中,如果是转载文章,也会用到记录文章出处的字段。个人建议所有代表链接的字段,均为Url结尾。于是,图片路径的字段命名为 ImageUrl,文章出处字段的命名为SourceUrl。

    最后一个例子,我们经常需要用到布尔值,比方说,这篇随笔要不要显示到首页,这篇随笔是不是保存到草稿箱等等。同样,按照微软的建议,布尔类型的值均以 Is、Has、Exist 或者 Can开头。如果让我来建表示是否将随笔放到首页的字段,它的名字一定是这样的:IsOnIndex

    (4)字段命名时需注意的一个问题

    我发现有很多开发人员喜欢给字段加上表名作为它的前缀,举个例子,如果有个表叫User,那么他就会将这个表中的字段命名为:UserId、UserPassword、UserName、UserPhone 等等。个人认为,这是没有必要的,因为你已经确切的知道了这个表存储的是User的信息,那么其中的字段必然是针对于User的。而且,在Join连接操作中,你的SQL代码看上去也会更加的精简一些,诸如 [User].UserName =Aritcle.ArticleAuthor 这样的代码完全可以实现为 [User].Name = Article.Author。(没必要添加无所谓的后缀)

    这里还存在一个特例,就是表的外键包含的字段。在这种情况下,我倾向于使用表名+ID 的方式,比如 CategoryId、UserId 等。假设有表Article,那么它的主键我会命名为Id,关联用户表User的外键包含的字段,我会命名为UserId。之所以这样,是因为在语言(比如C#)中创建对象时,有时候会使用代码生成器(根据数据库的字段名生成对象的字段、属性名),此时生成的代码更规整一些。(对于外键要用到,外表名+Id)

    (5)外键的命名

    外键的命名为 fk_外键所在的表名_外键引用的表名。因为外键所在的表为从表,所以上式可以写为 fk_从表名_主表名。外键包含的字段的命名,外键包含的字段和外键是完全不同的概念。外键包含字段的命名,建议为:外键所在的表名 + Id。考虑这样一个关系,表Hotel,字段Id, Name, CityId。表City,字段Id,Name。因为一个城市可能有好多家酒店,所以是一个一对多的关系,City是主表(1方),Hotel是从表(多方)。在Hotel表中,CityId是做为外键使用。在实现外键的时候我们可以这样写:

    Alter Table HotelInfo

    Add Constraint fk_HotelInfo_City ForeignKey (CityID) References City(ID)

    On Delete No Action On update No Action

    很明显,fk_HotelInfo_City是外键的名字,CityId是外键包含的字段的名字。

    在创建数据库表的时候,一般需要写成三个SQL脚本文件。第一个文件仅包含所有的创建表的SQL语句,即CreateTable 语句。第二个文件包含删除关系和表的语句,其中,所有删除关系的语句,即Drop Constraint 语句集中在这个文件的上半部分,所有删除表的语句,Drop Table语句,集中在这个文件的下半部分。第三个文件包含建立表之间关系的语句。这种做法会在你移植数据库的时候产生较大的便利,原因我就不解释了,您一试便知。而对于多对多关系中解析表的外键包含的字段,顺理往下推,我们可以这样写(再次回到学生选课的多对多例子中):

    建立解析表StudentCourse与Student表的外键关系:

    Alter Table StudentCourse

    Add Constraint fk_StudentCourse_StudentForeign Key (StudentId) References Student (Id)

    On Delete No Action On Update No Action

    建立解析表StudentCourse与Course 表的外键关系:

    Alter Table StudentCourse

    Add Constraint fk_StudentCourse_CourseForeign Key (CourseId) References Course(Id)

    On Delete No Action On Update No Action

    (6)以Not Null的思路建表

    我发现很多开发人员在建表的时候,如果要新建一个字段,他的思路是这样的:默认这个字段是可以为Null的,然后去判断是不是非要NotNull不可,如果不是这样,OK,这个字段可以为Null,接着继续进行下一个字段。结果往往是一张表除了主键以外所有的字段都可以为Null。之所以会有这样的思路,是因为Null好啊,程序不容易出错啊,你插入记录的时候如果不小心忘输了一个字段,程序依然可以Run,而不会出现 “XX字段不能为Null”的错误消息。但是,这样做的结果却是很严重的,也会使你的程序变得更加繁琐,你不得不进行一些无谓的空值处理,以避免程序出错。更糟的是,如果一些重要数据,比如说订单的某一项值为Null了,那么大家知道,任何值与Null相操作(比如加减乘除),结果都是Null,导致的结果就是订单的总金额也为Null。

    你可以运行下面的代码尝试一下:

    Select Null + 5 As Result

    你可能会说,就算我将字段设置成Not Null,但是它依然可以接受空字符串,这样一来在程序中还是要进行空值处理。请别忘了,数据库还赋予你一个强力武器,就是 Check 约束,当你需要确保一个字段既不可以为Null,又不可以为空的时候,可以这么写:

    ColumnName    Varchar(50)       Not Null Constraint ck_ColumnNameCheck(Len(ColumnName) > 0)

    所以,合理的思维方式应该是这样的:默认这个字段是 Not Null的,然后判断这个字段是不是非为Null不可,如果不是这样,OK,这个字段是Not Null的,进行下一个字段。

    一个建表的范例脚本个建表的范例脚本

    我正在建立我自己的个人空间,其中的文章表是这样写的:

    Create Table Article

    (

        Id           Int Identity(1,1) Not Null,

       Title         Varchar(50)       Not Null Constraint uq_ArticleTitleUnique,

       Keywords      Varchar(50)       Not Null,

       Abstract      Varchar(500)      Not Null,

       Author        Varchar(50)       Not Null Default ‘张三’,

       Type          TinyInt           Not Null Default 0 Constraintck_ArticleType Check(Type in (0,1,2)), – 0,原创;1,编译;2,翻译

       IsOnIndex     Bit               Not Null Default 1,   – 是否显示在首页

       Content       Text              Not Null,

       SourceCode    Varchar(100)      Null, – 程序源码的下载路径

       Source        Varchar(50)       Not Null Default ‘TraceFact’,   – 文章出处

       SrcUrl        Varchar(150)      Null, – 文章出处的URL

       PostDate      DateTime          Not Null Default GetDate(),

        ViewCount     Int               Not Null Default 0,

       ClassId       Int               Not Null   – 外键包含的字段,文章类别

       Constraint pk_Article Primary Key(Id)  – 建立主键

    )

    可以看到,在这里我使用了Check 约束,以确保文章类型只能为0,1,2。这里,我想说的是Check约束的命名规则:尽管Check约束是针对字段的,但在同一数据库中,却不能有同名的Check约束。所以,建议使用 ck_ + 表名 + 字段名来命名它,比如这个范例脚本中的 ck_ArticleType。除此以外,我还使用了Unique约束,以确保文章标题的唯一性。由于这是我的博客文章表,不应该出现重复的题目,这样可以避免在使用 Insert 语句时插入重复值。类似于Check约束,这里的命名规则是:uq_+ 表名 + 字段名。

    (7)触发器的命名

    由三部分构成:

    前缀(tr),描述了数据库对象的类型。

    基本部分,描述触发器所加的表。

    后缀(_I、_U、_D),显示了修改语句(Insert,Update及Delete)

    (8)存储过程的命名

    大家知道,系统存储过程的前缀是 sp_,为了避免将用户存储过程与系统存储过程混淆,这里我推荐大家使用 pr 作为自己定义的存储过程的命名。

    同时,命名的规则是:采用自解释型的命名,比如:prGetItemById。

    这里,有个有意思的地方值得深思。我们按上面规则命名存储过程的时候,可以用两种方式:

    动词放前面,名词放后面。

    名词放前面,动词放后面。

    我个人推荐使用方式2,现在说说原因:

    以NorthWind 为例,假如对于 Employees 表你有4个存储过程,分别命名为:prEmployeeInsert、prEmployeeUpdate、prEmployeeDelById、prEmployeeGetById

    同时对于 Products 表你有类似的4个存储过程,分别命名为:prProductInsert、prProductUpdate、prProductDelById、prProductGetById

    这时,你用企业管理器查看时,会发现存储过程像下面这样整整齐齐的排列:

    prEmployeeDelById

    prEmployeeGetById

    prEmployeeInsert

    prEmployeeUpdate

    prProductDelById

    prProductGetById

    prProductInsert

    prProductUpdate

    很容易就会发现,当你的存储过程越多时,这种命名方法的优势就越明显。

    (9)存储过程中参数的命名

    存储过程中的入口参数,我建议与其对应的字段名相同,这里,假设要写一个更新Northwind数据库Employees表的存储过程(做了简化),可以这么写:

    Create Procedure prEmployeeUpdateById

       @EmployeeId       Int,

       @LastName     NVarchar(20),

       @FirstName    NVarchar(10)

    As

       Update Employees Set

          LastName = @LastName,

          FirstName = @FirstName

       Where

          EmployeeId = @EmployeeId

       If @@error <> 0 or @@RowCount = 0

          Raiserror 16001 ‘更新用户失败’

    总结:

    (Id统一这样命名不进行ID获取id这样的命名)

    1.数据库表的命名:用头个字母大写的方式进行命名,对于有多个单词组成的在适当看具体情况进行裁剪。

    2.对于字段命名,采取和表命名一样的规则,个人习惯的命名规则是:表名+字段名。(自己觉得可以允许这样适当的冗余)

    3.外键命名:外表名+Id

    4.对于存储过程的命名遵循上面所说的原则,pr+名词(通常指表名)+动词操作。

    5.对于存储过程中参数的命名:和该存储过程所作用的数据表的相关字段一样也就是在其前面加一个@。对于存储过程中相应临时参数的命名也是一样的,用头个字母大写的方式进行命名。

    6.对于触发器的命名:用tr前缀:tr+所作用的表名+After/Before(I/D/U) trProductAfterI

    展开全文
  • 安全架构的设计

    千次阅读 2021-03-17 14:27:02
    公有云安全概述 云安全职责划分-共同担责 软件即服务SAAS 云服务厂家几乎负责所有的安全性,因为租户只能访问、管理和使用其提供的应用程序,但无法对应用程序做破坏性操作。例如:SAAS服务厂家提供安全、日志、...

    公有云安全概述

    云安全职责划分-共同担责

    软件即服务SAAS

    云服务厂家几乎负责所有的安全性,因为租户只能访问、管理和使用其提供的应用程序,但无法对应用程序做破坏性操作。例如:SAAS服务厂家提供安全、日志、运维、审计、应用安全性检测等,二租户只能给管理租户账户和权限。

    平台及服务PAAS

    云服务厂家负责平台的安全性,租户负责平台上部署的应用,包括所有的应用安全配置。两者职责几乎均分。例如RDS关系型数据库服务,云服务厂家提供RDS实例管理安全、RDS实例的修复和核心配置。租户对数据库账户、访问安全等负责。

    基础设置即服务IAAS

    云服务厂家负责基本的安全,而租户负责在此基础上搭建的其它安全。相比PAAS,IAAS租户承担更多的职责。

    租户安全关注点——治理和企业风险管理

    组织治理和度量云计算带来的企业风险的能力。 例如违约的判决先例,用户组织充分评估云提供商风险的能 力,当用户和提供商都有可能出现故障时保护敏感数据的责任,及国际边界对这些问题有何影响等都是关注点。

    法律问题:合同和电子举证

    使用云计算时潜在的法律问题。 本节涉及的的问题包括信息和计算机系统的保护要求、安全漏 洞信息披露的法律、监管要求,隐私要求和国际法等。

    合规性和审计管理

    保持和证明使用云计算的合规性。 本节涉及评估云计算如何影响内部安全策略的合规性、以及不同的合规性要求(规章、法规等)。同时还提供在审计过程中 证明合规性的一些指导。

    信息治理

    治理云中的数据。 本节涉及云中数据的识别和控制;以及可用于处理数据迁移到 云中时失去物理控制这一问题的补偿控制。也提及其它项,如谁负责数据机密性、完整性和可用性等。

    管理平面和业务连续性

    保护访问云时使用的管理平台和管理结构,包括 Web 控制台 和 API。确保云部署的业务连续性。

    基础设施安全

    核心云基础架构安全性,包括网络、负载安全和混合云安全考虑。该领域还包括私有云的安全基础。

    虚拟化及容器(Container)技术

    虚拟化管理系统、容器和软件定义的网络的安全性。

    事件响应、通告 和补救

    适当的和充分的事件检测、响应、通告和补救。尝试说明为了启动适当的事件处理和取证,在用户和提供商两边都需要满足的一些条目。本域将会帮助您理解云给您现有的事件处理程序带来的复杂性。

    应用安全

    保护在云上运行或在云中开发的应用软件。包括将某个应用迁移到或设计在云中运行是否可行,如果可行,什么类型的云平 台是最合适的(SaaS, PaaS, or IaaS)。

    数据安全和加密

    实施数据的安全和加密控制,并保证可扩展的密钥管理。

    身份、授权和访问管理

    管理身份和利用目录服务来提供访问控制。关注点是组织将身 份管理扩展到云中遇到的问题。本节提供洞察评估一个组织准备就绪进行基于云的身份、授权和访问管理(IdEA)。

    安全即服务

    提供第三方促进安全保障、事件管理、合规认证以及身份和访问监督。

    相关技术

    与云计算有着密切关系的已建立的新兴技术,包括大数据,物联网和移动计算。

    租户云上安全诉求及方案

    业务连续不中断

    业务中断的主要原因

    网络攻击

    网络的每一层都有可能成为攻击者的切入点,非应用层的攻击可能导致基础网络不可用,如DDOS、DOS可以让企业网络出口几乎等于不可用,针对应用层的CC攻击可以让服务器无法正常对外提供服务,无论针对哪一层进行的攻击行为,都有可能导致客户的业务中断,无法正常运行。

    漏洞

    没有及时修补的漏洞、0Day,都使得企业的业务运行在不安全的环境下,利用漏洞的攻击可以让黑户非法窃取数据、造成业务中断、数据丢失等。以在护网行动中暴露出来的coremail为例,可造成coremail的配置文件信息泄露,其中包括数据库连接的用户名密码等敏感信息

    病毒

    如果近几年来让大家印象深刻的导致业务中断的事件,由勒索病毒(永恒之蓝、warnnacry)为代表的病毒大家再熟悉不过了,病毒对在很多方面都可以导致业务系统不可用:服务器资源高占用、死机、数据被删除、数据被加密等。

    网络攻击的分类

    网络攻击按照流量特点可以分为流量型攻击单包攻击两种。

    流量攻击也就是我们熟知的DOS、DDOS,使用大量的流量或者应用层连接造成业务不可用。

    单包攻击虽然没有大量的流量,但是通过构造特殊的报文来攻击网络中设备的漏洞,可直接造成网络设备的宕机、网络拓扑信息泄露。

    流量型攻击分类

    流量型攻击从攻击层面可以分为网络层和应用层,通过构造大量报文造成接口流量拥塞、设备处理卡顿,从而达到正常业务流量无法得到及时处理的问题,借此来中断业务。

    TCP flood

    攻击者首先伪造地址对服务器发起SYN请求,服务器就会回应一个ACK+SYN,而真实的IP没有发送请求,不作回应。服务器没有收到回应,会重试3-5次并且等待一个SYN Time(一般30秒-2分钟)后,丢弃这个连接。如果攻击者大量发送这种伪造源地址的 SYN请求,服务器端将会消耗非常多的资源来处理这种半连接(SYN_RECV状态),保存遍历会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行 SYN+ACK的重试,服务器无暇理睬正常的连接请求造成拒绝服务。这种情况称作服务器端受到了SYN Flood攻击(SYN洪水攻击)

    UDP flood

    UDP协议是一种无连接的服务,攻击者向服务器发送大量UDP协议数据包,导致服务器带宽和系统资源耗尽,无法提供正常服务。比较常见的是攻击者利用大量UDP小包冲击DNS服务器或Radius认证服务器、流媒体视频服务器等。UDP Flood攻击包括小包和大包两种方式进行攻击。

    ICMP flood

    ICMP Flood 攻击属于流量型的攻击方式,攻击者使用工具发送大量的伪造源IP的ICMP报文,造成服务器带宽资源被大量占用,给服务器带来较大的负载,影响服务器的正常服务。由于目前很多防火墙直接过滤ICMP报文, 因此ICMP Flood出现的频度较低。

    HTTP flood

    常见的HTTP Flood攻击分为HTTP get flood、HTTP post flood,是指利用应用层Http协议,向服务器发送海量Http请求,造成服务器繁忙和资源耗尽,无法正常提供服务的DDoS攻击。

    HTTPS floofd

    与HTTP flood类似,只是基于HTTPS。

    DNS flood

    分为DNS Query Flood和DNS Reply Flood。DNS Query Flood采用的方法是向被攻击的服务器发送大量的域名解析请求,域名解析的过程给服务器带来了很大的负载,每秒钟域名解析请求超过一定的数量就会造成DNS服务器解析域名超时,导致DNS服务器无法为合法用户提供服务。通常攻击者所请求解析的域名是随机生成或者是网络世界上根本不存在的域名,被攻击的DNS DNS服务器就需要进行频繁的字符串匹配,由于在本地无法查到对应的结果,服务器必须使用递归查询向上层域名服务器提交解析请求,引起连锁反应,从而给DNS服务器带来更大的负载。DNS reply flood就是黑客发送大量的DNS reply报文到DNS缓存服务器,导致缓存服务器因为处理这些DNS reply报文而资源耗尽,影响正常业务。

    SIP flood

    攻击者通过发送大量的INVITE消息到SIP服务器,导致被攻击SIP服务器分配大量的资源用以记录和跟踪会话,直到资源耗尽而无法响应合法用户的呼叫请求。

    SIPSession Initiation Protocol,会话初始协议)的开发目的是用来帮助提供跨越因特网的高级电话业务。因特网电话(IP电话)正在向一种正式的商业电话模式演进,SIP就是用来确保这种演进实现而需要的NGN(下一代网络)系列协议中重要的一员。支持H.264协议。

    单包攻击种类

    最常见的DoS攻击就是我们常常提到的单包攻击,这类攻击一般都是以个人为单位的黑客发动的,攻击报文也比较单一,虽然破坏力强大,但是只要掌握了攻击的特征,防御起来还是比较容易的。

    畸形报文攻击:通常指攻击者发送大量有缺陷的报文,从而造成主机或服务器在处理这类报文时系统崩溃。

    扫描类攻击:是一种潜在的攻击行为,并不具备直接的破坏行为,通常是攻击者发动真正攻击前的网络探测行为。

    特殊控制报文攻击:也是一种潜在的攻击行为,不具备直接的破坏行为,攻击者通过发送特殊控制报文探测网络结构,为后续发动真正的攻击做准备。

    扫描窥探攻击

    利用ping扫射(包括ICMP和TCP)来标识网络上存活着的系统,从而准确定位潜在的目标;利用TCP和UDP端口扫描,就能检测出操作系统和监听着的潜在服务。攻击者通过扫描窥探就能大致了解目标系统提供的服务种类和潜在的安全漏洞(识别目标弱点),为进一步侵入系统做好准备。

    畸形报文攻击

    通过向目标系统发送有缺陷的IP报文,使得目标系统在处理这样的IP报文时发生错误,或者造成系统崩溃,影响目标系统的正常运行。主要的畸形报文攻击有Ping of Death、Teardrop等。

    特殊报文攻击

    攻击者利用一些合法的报文对网络进行侦察或者数据检测,这些报文都是合法的应用类型,只是正常网络很少用到。

     

     

     

    网络攻击防范

    防火墙,antiddos

    安全组:防护对象为弹性云服务器

    网络ACL:防护对象为VPC的子网

     

     

    计费项:基础防护+业务带宽+弹性防护

    付费方式:预付+后付

    计费周期:基础防护带宽(Gbit/s)、业务带宽(Mbit/s)按照月/年计费,购买时生成预付费订单付费。

    后付费周期:弹性防护带宽(Gbit/s)按自然日计费,按照前一日实际发生的超出基础防护攻击峰值生成后付费账单。

    漏洞

    漏洞会影响到很大范围的软硬件设备,包括操作系统本身及其支撑软件,网络客户和服务器软件,路由器和安全防火墙等。换而言之,在这些不同的软硬件设备中都可能存在不同的安全漏洞问题。

    常见漏洞按照分类可以分为三大类:主机漏洞、Web漏洞和数据库漏洞。

    主机漏洞:内存破坏类漏洞、CGI类漏洞、输入验证类漏洞、配置错误类漏洞、系统本地补丁、常见协议弱口令、木马病毒

    Web漏洞:SQL注入攻击、跨站脚本、文件包含、远程代码执行、主流CMS漏洞。

    数据库漏洞:常见类型数据库漏洞,如Oracle、MySQL、SQL Server、DB2、Informix、Sybase

    基于威胁类型分类:

    获取控制:劫持执行程序流程,使程序执行指定任意指令或命令,控制应用系统或操作系统。

    获取信息:劫持程序访问预期外的资源并被攻击者获取,影响系统的机密性。

    拒绝服务:导致目标应用或系统暂时或永久性失去相应服务的能力

    基于技术类型分类:

    内存破坏类:栈缓冲区溢出,堆缓冲区溢出,静态数据区溢出。

    错误逻辑类:安全检查的实现逻辑上上有问题。

    设计错误类:系统设计上对安全机制的考虑不足导致在设计阶段引入安全漏洞。

    错误配置类:系统运维过程中默认不安全的配置状态。

    输入验证类:对用户输入没有做充分的检查过滤就用于后续操作导致的漏洞。

    漏洞防御

    针对Web安全的防御主要可以分为以下两个方面:

    用户侧:在用户侧通过限制用户可访问的Web站点类型,限制恶意站点,从而达到防御Web攻击的目的。

    站点侧:在站点上规范开发,开发时从语言编写层面防御针对Web攻击,让攻击行为无法被执行。

    病毒

    病毒是一组程序或指令的集合,它能够通过某种途径潜伏在计算机存储介质或程序中,当达到某种条件(如特定时间或者特定网络流量等)时被激活,从而对计算机资源进行一定程度的破坏。

    病毒的传播途径多种多样,在早期以移动介质传播为主,但是随着Internet技术的发展,以及E-mail和一批网络工具的出现,使得计算机病毒的种类迅速增加,扩散速度也大大加快,计算机病毒的传播方式迅速转变以网络系统间的传播为主。

    网络(电子邮件、网页链接、P2P共享)、U盘等

    病毒特征

    病毒具有以下特征:

    传染性

    可以通过多种方式传播,在当今互联网时代,病毒可以通过网络迅速传播到世界的各个地方。

    破坏性

    一般的病毒会删除、加密系统内文件,少部分的病毒会对计算机的硬件进行不可逆的破坏,如CIH病毒。

    隐蔽性

    一般病毒很难被发现,他们会伪装地和正常程序名称很像,让人很难察觉,如svh0st这种名称,不仔细观察会认为是系统进程(svhost是windows系统正常的系统进程)。有的病毒会依附于正常程序,当正常程序执行时它们也会被调用。

    潜伏性

    并不是所有的病毒都会立即执行,而是等待设定的触发条件达到才会执行,比如某个时间点。

    不可预见性

    不同类型的病毒之间从代码角度来看差距很大,很难不查看代码的具体行为就判断出该程序是不是病毒,同时对代码的一点修改,就可以让病毒的行为改变,从而绕过杀毒软件已经退出的检测、查杀手段。

    病毒分类

    按破坏性分类:

    良性病毒:良性病毒并不破坏系统中的数据,而是干扰用户的正常工作,导致整个系统运行效率降低、系统可用内存总数减少、使某些应用程序不能运行。

    恶性病毒:恶性病毒发作时以各种形式破坏系统中的数据。如删除文件、修改数据、格式化硬盘或破坏计算机硬件。

    传播媒介分类:

    单机病毒:单机病毒的载体是磁盘,常见的是病毒从软盘传入硬盘,感染系统,然后再传染其他软盘,软盘又传染其他系统。

    网络病毒:网络病毒的传播媒介不再是移动式载体,而是网络通道,这种病毒的传染能力更强,破坏力更大。

    按传染方式分类

    文件型病毒:文件型病毒是指能够感染文件、并能通过被感染的文件进行传染扩散的计算机病毒。

    系统引导型病毒:这类病毒隐藏在硬盘或软盘的引导区,当计算机从感染了引导区病毒的硬盘或者软盘启动,或者当计算机从受感染的磁盘中读取数据时,引导区病毒就会开始发作。

    混合型病毒:混合型病毒综合了系统引导型和文件型病毒的特性,它的危害比系统引导型和文件型病毒更为严重。这种病毒不仅感染系统引导区,也感染文件,通过这两种方式来感染,更增加了病毒的传染性以及存活率。

    宏病毒:宏病毒是一种寄存于文档或模板的宏中的计算机病毒,主要利用MicrosoR word提供的宏功能来将病毒带进到带有宏的Doc文档中,一旦打开这样的文档,宏病毒就会被激活,进人计算机内存中,并驻留在Nonnal模板上。

    按连接方式分类:

    源码型病毒:源码型病毒攻击的对象是高级语言编写的源程序,在源程序编译之前插入其中,并随源程序一起编译、连接成可执行文件。

    入侵型病毒:入侵型病毒将自身连接入正常程序之中。这类病毒难以被发现,清除起来也较困难。

    操作系统型病毒:操作系统型病毒可用其自身部分加入或替代操作系统的部分功能,使系统不能正常运行。

    外壳型病毒:外壳型病毒将自身连接在正常程序的开头或结尾。

    病毒防范

    针对病毒大家最了解的防御手段:杀毒软件,Anti Virus,一般简称AV,从查杀原理来区分,AV可以分为两种类型:

    扫描性:描病毒程序本身的特征,然后与杀软病毒库中的特征码作对比,能够匹配说明就是病毒,但随着病毒越来越多,病毒库的体积会越来越臃肿,客户需要频繁地升级病毒库。

    主动防御性:将可疑程序放到一个“沙箱”内运行,“沙箱”是一个模拟的操作系统,沙箱会观察该程序是否会执行一些危险行为,表现出明显的病毒特征,如果在模拟的操作系统内该程序表现出一些危险行为,沙箱会判定该程序为病毒。

    从防范的位置来看,一般在主机侧(用户主机、服务器)通过安装杀毒软件、定期查杀、更新系统等行为进行防范,在网络侧通过部署具有防病毒功能的防火墙、物理沙箱设备来进行主动防御。

    华为云租户业务防护方案

    漏洞扫描服务VSS具有web网站扫描主机扫描HSShost security service两种扫描能力。

    漏洞扫描服务帮您快速检测出您的网站和主机存在的漏洞,提供详细的漏洞分析报告,并针对不同类型的漏洞提供专业可靠的修复建议。

    体验式扫描

    第一次使用漏洞扫描服务的新用户,在未进行域名认证时,可以对网站进行体验式扫描,预估网站风险。

    主机漏洞扫描

    支持深入扫描

    通过配置验证信息,可连接到服务器进行OS检测,进行多维度的漏洞、配置检测。

    支持内网扫描

    可以通过密钥的方式访问业务所在的服务器,适配不同企业网络管理场景。

    支持弱密码扫描

    多场景可用

    全方位的OS连接,涵盖90%的中间件,支持标准Web业务弱密码检测、操作系统、数据库等弱口令检测。

    丰富的弱密码库

    丰富的弱密码匹配库,模拟黑客对各场景进行弱口令探测,同时支持自定义字典进行密码检测。

    支持中间件扫描

    丰富的扫描场景

    支持主流Web容器、前台开发框架、后台微服务技术栈的版本漏洞和配置合规扫描。

    多扫描方式可选

    支持通过标准包或者自定义安装等多种方式识别服务器中的中间件及其版本,全方位发现服务器中的漏洞风险

    网站漏洞扫描

    具有OWASP TOP10和WASC的漏洞检测能力,支持扫描22种类型以上的漏洞。

    扫描规则云端自动更新,全网生效,及时涵盖最新爆发的漏洞。

    支持HTTPS扫描。

    一站式漏洞管理

    支持任务完成后短信通知用户。如果您希望在扫描任务执行完成后收到短信通知,请购买专业版或者企业版。

    提供漏洞修复建议。如果您需要查看修复建议,请购买专业版或者企业版。

    支持下载扫描报告,用户可以离线查看漏洞信息,格式为HTML。如果您需要下载扫描报告,请购买专业版或者企业版。

    支持重新扫描。

    自定义扫描

    支持任务定时扫描。

    支持端口扫描。

    支持弱密码扫描。如果您需要对网站进行弱密码检测,请购买专业版或者企业版。

    支持自定义登录方式。

    支持Web 2.0高级爬虫扫描。

    web网站扫描采用网页爬虫的方式全面深入的爬取网站url,基于多种不同能力的漏洞扫描插件,模拟用户真实浏览场景,逐个深度的分析网站细节,帮助用户发现潜在的安全隐患。同时内置了丰富的无害化扫描规则,以及扫描速率动态调整能力,可有效避免用户网站业务受到影响。

     

    主机扫描需要经过用户授权(支持账密授权、脚本授权方式)访问用户主机,能够自动发现并检测主机操作系统、中间件等版本漏洞信息和基线配置,基于实时同步官网更新的漏洞库匹配漏洞特征,帮助用户及时发现主机安全隐患。

     

    Web应用防火墙(Web Application FirewallWAF,通过对HTTP(S)请求进行检测,识别并阻断SQL注入、跨站脚本攻击、网页木马上传、命令/代码注入、文件包含、敏感文件访问、第三方应用漏洞攻击、CC攻击、恶意爬虫扫描、跨站请求伪造等攻击,保护Web服务安全稳定。

    操作全程可管控

     

    用户可通过云服务基线查看各项风险的详细信息和指导建议。

    身份认证

    • 检查是否启用IAM用户
    • 检查租户的用户列表,是否至少有两个已启用的用户,且其中一个用户所属的用户组不是admin用户组。启用IAM用户,是指通过IAM服务启用除企业管理员以外的其他用户,且该用户不属于admin组。

    访问控制

    • 网络ACL规则检查
    • 检查所有网络ACL的规则是否存在不安全规则,即是否存在开放过大的访问控制策略。不安全规则,即方向为入方向,动作为允许,协议为任一类别协议,源地址为0.0.0.0/0(所有地址),源端口范围为1-65535或0,目的地址为0.0.0.0/0(所有地址),目的端口范围为1-65535、0或者特定的业务端口,如22。

    安全组规则检查

    • 检查所有安全组的规则是否存在不安全规则,即是否存在开放过大的访问控制策略。不安全规则,即方向为入方向,协议为任一类别协议,源地址为0.0.0.0/0(所有地址),端口为1-65535或者特定的业务端口,如22。

    日志审计

    • 检查是否启用云审计服务
    • 检查租户是否已经开通云审计服务,并且至少有一个追踪器的状态是正常的。云审计服务,可以提供云账户下资源的操作记录,通过操作记录,用户可以实现安全分析、资源变更、合规审计、问题定位等常见应用场景。
    • 检查是否启用OBS桶日志记录
    • 检查租户的所有OBS桶是否开启日志记录功能。OBS桶日志记录,是指用户开启一个桶的日志记录功能后,OBS会自动对这个桶的访问请求记录日志,并生成日志文件写入用户指定的桶(即目标桶)中。

    数据安全

    • OBS桶的ACL权限检查
    • 检查所有OBS桶,是否给匿名用户赋予桶访问权限或者ACL访问权限。桶ACL是基于账号或用户组的桶级访问控制,桶的拥有者可以通过桶ACL授予指定账号或用户组特定的访问权限。为安全起见,不建议通过桶ACL为匿名用户赋予桶的相关权限。如果匿名用户被授予了访问桶的权限,则表示所有人都可以访问对应的桶,并且不需要经过任何身份认证。

    RDS实例安全组规则检查

    • 检查所有RDS实例关联的安全组的规则是否存在不安全规则,即是否存在开放过大的访问控制策略。不安全规则,即方向为入方向,协议为任一类别协议,源地址为0.0.0.0/0(所有地址),端口为1-65535或者数据库业务端口,如3306。

    基础防护

    • 检查是否启用Anti-DDoS流量清洗
    • 检查租户的弹性云服务器、弹性负载均衡资源是否启用了Anti-DDoS流量清洗。启用Anti-DDoS流量清洗,是指为华为云内资源(弹性云服务器、弹性负载均衡),开启流量清洗防护,抵御DDoS攻击。

    检查ECS实例是否启用企业主机安全

    • 检查租户的弹性云服务器是否安装主机安全客户端,且防护状态是否开启。启用企业主机安全,是指为云主机安装主机安全客户端并开启防护。从而提升主机整体安全性,帮助企业降低主机安全风险。
    • 云审计服务管理控制台支持创建数据事件追踪器,用于记录数据操作日志。        

    追踪器分类

    管理事件追踪器和数据事件追踪器。

    管理事件追踪器用于记录管理事件,即针对云资源的操作日志,例如创建、登录、删除等。

    数据事件追踪器用于记录数据事件,即针对数据的操作日志,例如上传、下载等。

    策略根据授权的精细程度

    细粒度策略Role-Based Access ControlRBAC)策略

    RBAC策略:将服务作为一个整体进行授权,授权后,用户可以拥有这个服务的所有权限,RBAC策略无法针对服务中的具体操作做权限控制

    细粒度策略:以API接口为粒度进行权限拆分,授权更加精细,可以精确到具体操作。授权后,用户可以对这个服务执行特定的操作,例如:针对ECS服务,控制用户仅能变更云服务器规格。

    态势感知(Situation AwarenessSA是可视化威胁检测和分析的平台。态势感知能够检测出超过20大类的云上安全风险,包括DDoS攻击、暴力破解、Web攻击、后门木马、僵尸主机、异常行为、漏洞攻击、命令与控制等。利用大数据分析技术,态势感知可以对攻击事件、威胁告警和攻击源头进行分类统计和聚合分析,为用户呈现出全局安全攻击态势。

    通过采集全网流量数据和安全防护设备日志信息,并利用大数据安全分析平台进行处理和分析,态势感知检测出威胁告警,同时将主机安全、Web防火墙和DDoS流量清洗等安全产品上报的告警进行汇聚,最终为用户呈现完整的全网攻击态势,进而为安全事件的处置决策提供依据。

    云审计服务CTS

    日志审计模块是信息安全审计功能的核心必备组件,是企事业单位信息系统安全风险管控的重要组成部分。在信息系统逐步云化的背景下,包括我国SAC/TC在内的全球各级信息、数据安全管理部门已对此发布多份标准,如:ISO IEC27000、GB/T 20945-2013、COSO、COBIT、ITIL、NISTSP800等。

    云审计服务(Cloud Trace Service,以下简称CTS,是华为云安全解决方案中专业的日志审计服务,提供对各种云资源操作记录的收集、存储和查询功能,可用于支撑安全分析、合规审计、资源跟踪和问题定位等常见应用场景。

    云审计服务的功能主要包括:

    记录审计日志:支持记录用户通过管理控制台或API接口发起的操作,以及各服务内部自触发的操作。

    审计日志查询:支持在管理控制台对7天内操作记录按照事件来源、事件名称、操作类型、资源名称/ID、事件状态和时间范围等多个维度进行组合查询。

    审计日志转储:支持将审计日志周期性的转储至对象存储服务(Object Storage Service,简称OBS)下的OBS桶,转储时会按照服务维度压缩审计日志为事件文件。

    事件文件加密:支持在转储过程中使用数据加密服务(Data Encryption Workshop,简称DEW)中的密钥对事件文件进行加密。

    关键操作通知:支持在检测到部分关键操作时,使用消息通知服务(Simple Message Notification,简称SMN)向用户发送邮件、短信通知。

    统一身份IAM

    1. 对华为云的资源进行精细访问控制
    2. 跨账号的资源操作与授权
    3. 使用企业已有账号登录华为云

    统一身份认证(Identity and Access Management,简称IAM是华为云提供权限管理的基础服务,可以帮助您安全地控制华为云服务和资源的访问权限。

    IAM无需付费即可使用,您只需要为您账号中的资源进行付费。

    • 云堡垒机提供了用户管理、用户组管理、角色管理,认证方式支持账号和密码、USBKey和动态令牌多种令牌认证模式。
    • 云堡垒机提供了访问控制策略、命令控制策略和改密策略等三种方式。

     

    数据保密不扩散

    生命周期

    存储系统缺陷

    缺乏加密

     尽管一些高端NAS和SAN设备包含自动加密功能,但市场上的许多产品并不包含这些功能。这意味着组织需要安装单独的软件或加密设备,以确保其数据已被加密保护。

    云存储

    越来越多的企业选择将部分或全部数据存储在云中。尽管有人认为云存储相比内部部署的存储更安全,但云计算增加了存储环境的复杂性,并且通常需要存储人员学习新工具,并实施新程序,以确保数据得到充分保护。

    数据销毁

    从硬盘或其他存储介质中删除数据时,可能会留下可能导致未经授权的人员恢复该信息的痕迹。存储管理人员和管理者需要确保从存储中删除的任何数据都被完全覆盖,以至于无法恢复。

    物理安全

    有些组织对其存储设备的物理安全性没有足够的重视。在某些情况下,他们没有考虑到内部人员(例如员工或清洁团队的成员)可能能够访问物理存储设备,并提取数据,从而绕过所有精心策划的基于网络的安全措施的情况。

    对称加密的最大优点是:加密速度非常快,缺点是:密钥难于保存和传输

    当前的著名对称加密算法有

    DES/3DES数据加密标准

    IDEA国际数据加密算法

    RC系列

    CAST

    Blowfish/Twofish

    AES高级数据加密标准等等

     

    非对称算法有如下特点:

    公钥加密,私钥解密,公钥公开,私钥保密,加解密速度很慢

    密钥管理服务(KMS – Key Management Service应运而生。密钥管理系统可对密钥进行全生命周期的管理,包括创建、启用、禁用、更新、轮换、销毁等操作。

    通过使用硬件安全模块(HSM – Hardware Security Module),为租户创建和管理密钥,防止密钥明文暴漏在 HSM 之外,从而防止密钥泄露,保护密钥安全。

    硬件安全模块(HSM)通常以硬件加密机的形式对外提供服务,提供主要功能如下:

    • 生成、存储、导入、导出和管理加密密钥,包括对称密钥和非对称密钥。
    • 使用对称和非对称算法加密和解密数据。
    • 使用加密哈希函数计算消息摘要和基于哈希的消息身份验证代码。
    • 对数据进行加密签名(包括代码签名)并验证签名。
    • 以加密方式生成安全随机数据。

    对于密钥在内的敏感信息,HSM同时提供逻辑层面与物理层面的保护,以防止未经授权的访问或者可能的入侵。

    自2010年起,NIST推荐选取2048位及以上的RSA密钥长度,在更长密钥下保证速度就变得越来越重要了。对此,有些HSM已经支持同等安全程度仅需更短密钥的椭圆曲线密码学(ECC)。

    云加密机

    云密码机采用虚拟化技术,在一台硬件密码设备上实现同时运行多个虚拟化的密码机(VSM,可与云计算管理系统无缝对接,实现对VSM的独立管理,并支持虚拟化多种密码体系的VSM,用户使用VSM与使用传统密码机一致。

    云加密机具有以下特点:

    独享云端硬件芯片

    采用独有的硬件虚拟化与隔离技术,用户独享云端密码芯片资源,实现用户密钥硬件隔离的同时保障业务性能。

    多层安全设计

    采用主机可信链路、密钥协商、平台与VSM管理角色分离等技术实现端到端的安全。

    弹性密码计算

    密码运算资源动态调配,高峰期动态增加、低谷期动态释放。

    全业务支持

    支持金融支付、身份认证、数字签名等应用安全,满足各种重要系统对于数据安全性的严苛要求。

    多用户/应用支持

    通过完善的审核控制和身份认证机制,支持多用户之间的设备及管理隔离,同时仍支持多应用调用。

    集中设备管理支持

    由统一的管理中心进行设备集中管理和监控,管理员随时可掌握设备的工作状态。与用户密钥管理权限分离,用户也可集中管理自身的密码设备密钥,保证用户密钥的安全性。

    安全性

    采用国密局批准的硬件芯片实现密码算法,采用多路物理噪声源芯片生成高强度随机数。

    可靠性

    采用多级阵列技术,支持VSM集群、热备,切实保障用户的业务连续性。

    兼容性

    为应用提供与实体密码设备相同的功能与接口,可完全兼容传统应用并方便其向云端迁移。

    加密存储

    磁盘加密

    系统盘、数据盘、硬盘快照和硬盘备份的加解密操作。加解密密钥的管理由密钥管理系统实现。

    全盘加密技术是主要是对磁盘进行全盘加密,正常一块500G的硬盘解密一次所需时间需要3-4个小时,主要做法是对系统盘不做加密防护,而是采用外围技术进行安全访问控制。

    文件加密

    根据要求在操作系统层自动地对写入存储介质的数据进行加密的技术。文档加密主要的技术分为磁盘加密、应用层加密、驱动级加密等几种技术,应用层加密因为对应用程序的依赖性比较强,存在诸多兼容性和二次开发的问题,逐步被各信息安全厂商所淘汰。

    数据库加密

    应用系统加密

    将应用系统数据先在内存中进行加密,然后文件系统把每次加密后的内存数据写入到数据库文件中去,读入时再逆方面进行解密。加密方法相对简单,只要妥善管理密钥就可以了。缺点对数据库的读写都比较麻烦,每次都要进行加解密的工作,对程序的编写和读写数据库的速度都会有影响。

    数据库服务端加密

    数据库服务端加密需要对数据库管理系统本身进行操作。这种加密是指数据在物理存取之前完成加解密工作。这种加密方式的优点是加密功能强,并且加密功能几乎不会影响DBMS的功能,可以实现加密功能与数据库管理系统之间的无缝耦合。其缺点是加密运算在服务器端进行,加重了服务器的负载,而且数据库管理系统和加密器之间的接口需要数据库管理系统开发商的支持。

    数据库客户端加密

    数据库客户端加密实现加密的好处是不会加重数据库服务器的负载,并且可实现网上的传输,加密比较实际的做法是将数据库加密系统做成数据库管理系统的一个外层工具,根据加密要求自动完成对数据库数据的加解密处理。

    采用这种加密方式进行加密,加解密运算可在客户端进行,它的优点是不会加重数据库服务器的负载并且可以实现网上传输的加密,缺点是加密功能会受到一些限制,与数据库管理系统之间的耦合性稍差

    数据销毁

    数据覆写

    低程度的就是将磁带或磁盘完全覆写;高程度则需符合美国国防部DoD 5220-22-M 保安认证程序,结合数种清除与覆写程序,让硬盘每一个空间都被重复清除及覆写。

    物理消磁

    小型消磁机做单卷消磁,但消磁机磁波高,大量消磁委托专门公司相比更迅速安全

    焚毁

    储存媒体通过焚毁,达到数据保密的目的

    捣碎/剪碎

    实体捣碎

    化学腐蚀

    化学腐蚀是指是运用化学物质溶解、腐蚀、活化、剥离磁盘记录表面信息的销毁方法。

    存储类型

    机密性

    可靠性

    EVS

    KMS 提供密钥。用户主密钥(CMK -  Customer Master Key)由 KMS 生成、管理和销毁,用于加密和解密数据加密密钥。华为云提供整卷加密功能。

    三副本备份,数据持久性高达99.99995%

    通过VBS实现云硬盘的备份与恢复,且支持通过云硬盘备份创建新的云硬盘

    VBS

    由 KMS 提供密钥。CMK 由 KMS生成、管理和销毁,用于加密和解密数据加密密钥。华为云提供整卷加密功能。

    数据持久性高达99.999999999%

    OBS

    提供两种加密密钥管理方式:

    用户提供加密密钥(SSE-C 方式):由用户提供密钥、密钥的 哈希值、加密算法 AES256。须使用 HTTPS 发请求。

    KMS 托管密钥(SSE-KMS 方式):由 KMS 提供密钥。用户向区域中的桶上传 SSE-KMS加密的对象时,OBS 将自动创建用于加密和解密数据的 CMK。

    数据持久性高达99.999999999%,服务可用性达99.99%

    数据检查:存储前一致性检查,确保存入数据是上传数据

    分片冗余:数据分片后多份冗余存储在不同磁盘,后台自行检测一致性并及时修复受损数据

    RDS

    供数据机密性的双重保证:

    通过数据库管理系统对数据库文件进行加密处理,即使数据泄露或丢失,也无法进行破译。

    华为云建议租户对要进行上传的数据进行加密,然后再保存到数据库中。

    三副本备份,数据持久性高达99.99995%;主备数据库实例可在故障发生时快速切换,服务可用性达99.95%, 

    备份与恢复:备份,支持自动备份以及创建快照;恢复,支持恢复到某个备份文件点

    IMS

    由 KMS 提供密钥。CMK 由 KMS生成、管理和销毁,用于加密和解密数据加密密钥。华为云提供两种方式创建加密镜像:通过加密弹性云服务器创建和通过

    外部镜像文件创建。

    使用多份冗余存储私用镜像,数据持久性高达99.999999999%

     

    专属加密(Dedicated Hardware Security ModuleDedicated HSM是华为云为用户提供的云上数据加密的服务,可处理加解密、签名、验签、产生密钥和密钥安全存储等操作。

    同时,Dedicated HSM可提供认证合规的金融数据加密机、服务器加密机以及签名验签服务器等,灵活支撑用户业务场景。能够帮助用户满足数据安全方面的监管要求,以及云上业务数据的隐私性要求。

    数字签名

    • 难以伪造
    • 无法抵赖
    • 不可更改
    • 不能转移

    信息摘要

    为了保证数据在传输过程中不被修改,消息完整性保证方法因此而生

    消息验证码(Message Authentication Code)

    整个数据进行散列运算,将得到的摘要信息随着消息一起发送,收到数据的一方用同样的方法计算临时摘要,对比消息中携带的摘要信息即可知道消息是否被修改。能够实现这一点的根本在于散列函数对于被计算的值,存在一点差距(1bit的不一样),产生的摘要信息都会不同。常见的摘要算法有:HMAC,SHA.

    数据加密

    通过算法法将一条正常的消息(明文)转换成乱码(密文),再将乱码转换回正常的消息,实现加密(编码)和解密(译码)的过程。有些加密算法是对称的—用来加密的能力可同样用来解密,而另一些算法是不对称的—用来加密的能力无法用来解密。

    对称加密算法有:DESAES3DES

    非对称的加密算法:DSARSA

     

     

     

    数据库层加密

    数据库系统安全框架可以划分为网络安全层宿主操作系统层数据库管理系统层

    网络安全层安全

    网络层次的安全防范技术主要由加密技术认证技术数字签名技术防火墙技术入侵检测技术等。

    操作系统层安全

    一个安全的操作系统应该具有访问控制内存管理审计加密数据传送加密文件系统安全进程通信机制等功能。

    操作系统安全策略用于配置本地计算机的安全设置,包括密码策略、账户锁定策略、审核策略、IP安全策略、用户权力指派、加密数据的恢复及其他安全选项

    安全管理策略是指网络管理员对系统实施安全管理所采取的方法和策略。针对不同的操作系统和网络环境采用的安全策略也不同。

    数据库管理系统层次安全

    其主要技术包括对数据库系统文件进行加密处理,保证即使数据不幸泄漏或者丢失,也难以破译和阅读。

    数据库管理系统层次安全主要分为以下4类:

    DBMS 代码漏洞

    这是由于数据库设计本身引起的安全漏洞,处于数据库产品的代码设计层面,比如缓冲区溢出漏洞,这样的漏洞只能通过厂商的补丁进行修补。

    DBMS 架构缺陷

    比如对口令加密的算法强度不够,在Oracle中,口令的 hash 变换算法,已经被模拟实现。这样的漏洞,一方面可以通过厂商的补丁进行修复,另外还需要进行安全配置的规避。

    DBMS 安全配置漏洞

    这是由于数据库的不合理配置而引起的安全问题,这类问题是最为常见的数据库安全问题,最容易受到攻击者的利用。数据库管理员维护数据库的安全,主要就是在这一个层面进行实施。

    用户造成的DBMS安全隐患

    这是由于对数据库的不合理使用造成的安全问题,比如在编写存储过程的时候,由于程序员的安全意识不足,导致了SQL注入漏洞,这就演变成了一个严重的安全问题。这类问题很难被数据库管理员发现,但是一旦被利用,就会造成巨大的破坏。

    数据库加密技术

    对数据库安全性的威胁有时候来自于内部,一些内部用户可能非法获取用户名和密码,或利用其它方法越权使用数据库。因此,有必要对数据库中存储的数据进行加密

    加密的基本要求

    • 加密粒度要合适,基于文件的数据库加密技术。
    • 采用秘钥动态管理:数据库客体之间隐含着复制的逻辑关系,一个逻辑结构可能对应着多个数据库,所以数据库秘钥数量大,组织存储工作较复杂,需要采用秘钥动态管理。
    • 处理数据要合理。首先要处理恰当的数据来写,否则DBMS将会因加密后的数据不符合定义的数据类型而拒绝加载;其次,需要考虑数据库加密后不增加空间开销。

    数据加密的三种方式

    1. 系统中加密。
    2. 客户端(DBMS外层)加密。
    3. 服务器端(DBMS内核层)加密。

    客户端加密的好处是不会加重数据库服务器的负载,并且可实现网上的传输加密,这种加密方式通常利用数据库外层工具实现,缺点是加密功能会受到一些限制。

    服务器端的加密需要对数据库管理系统本身进行操作,属核心层加密,如果没有数据库开发商的配合,其实现难度相对较大。此外,对那些希望通过ASP获得服务的企业来说,只有在客户端实现加解密,才能保证其数据的安全可靠。

    存取管理技术

    存取管理技术主要包括用户认证技术访问控制技术

    用户认证技术包括用户身份验证用户身份识别技术

    访问控制技术包括数据浏览控制修改控制。浏览控制是为了保护数据的保密性,而修改控制是为了保护数据的正确性和提高数据的可信性。

     

    用户认证和访问控制技术:保护数据的最佳方式便是限制其访问。

    访问控制四个主要级别:

    自主访问控制(DAC:在这个层次上,基于一些预设的权衡性政策,根据用户身份及特权授予其访问权限。通过这一方法,用户可以授权其他用户访问该数据,处于这一特性,这也被用于大多数企业。用户能够在存在需求时,对权限进行添加或删减。

    基于内容的访问控制:在这里权限的授予与否是基于内容而定的。在一个组织中,同一时间可能运行多个项目,因此用户需要访问的数据只需是和项目有关的。

    细粒度访问控制:可设置不同级别的访问控制。例如,我们能够在Oracle虚拟数据库中看到这些内容。

    强制访问控制(MAC):这是个基于用户和数据对象分类的模型。分类基于不同等级,被称为访问类。一个访问类包含多层安全水平,可以用于给不同类适当的读写权限。

    传统数据库防护弊端

    在对安全体系的设计和治理方案中,主要依靠传统边界安全防护,如防火墙、下一代防火墙、IPSIDS等安全控制类产品;随着边界安全防护的进一步落地,逐步开始向内容安全防护过度,如上网行为管理、堡垒机、数据库审计等安全设备;而随着数据大集中之后,数据库里的数据越来越有价值,而目前的防护体系中针对数据库的安全防护是空白的。很多客户认为自己有灾备软件、有数据库审计就能对数据库进行安全管理,但实际上灾备软件只能恢复数据库原有数据,数据库审计只能事后对访问情况进行追溯,如果业务系统存在SQL注入漏洞,恶意攻击者就可以通过绕过WAF等行为对数据库造成攻击,客户无法实时保障数据不被窃取或篡改,无法做到针对数据库的事前预防和事中阻断。

    从目前信息安全等级保护整改遗留的难点分析。等级保护整改中涉及物理安全、网络安全、服务器安全、制度安全等各部分的整改,相对来说通过技术、制度、传统安全设备的配置可以较快速和稳妥的进行加固。但是在数据库安全、应用系统安全上的安全加固以及整改却成棘手之事。不同的数据库以及各版本都有漏洞,但由于业务系统的长时间不间断运行,担心由于补丁及版本升级造成业务瘫痪,故把这部分的安全问题暂时搁置;另外,由于应用系统开发商已经把业务系统交付多年,虽然代码层面可能留有一些漏洞,但是让项目组重新对代码进行加固,阻力和压力都是很大的。

    防火墙等设备主要是基于网络层的访问控制,很难对数据库协议以及应用层协议作出分析与控制;就算近几年发展的如火如荼的下一代防火墙,也很难对数据库协议进行精准解码并且作出实时阻断;IPS、IDS主要也是对边界攻击进行扫描分析,数据库层面的分析也很难进行控制;Web应用防火墙,其主要是通过规则库的方式来进行攻击拦截,而目前很多0day攻击、SQL注入攻击等方式,都可以绕开WAF直接对数据库进行拖库。传统的安全防护手段是无法解决数据库安全的问题

    云数据库安全防护的需求

    传统数据库的安全防护方法已不能完全适应云计算架构,云数据库中的弹性、多租户以及新的物理/逻辑架构和抽象控制都需要新的安全策略。

    云数据库漏洞防护需求。在多租户环境下,通过数据访问组件可以实现租户之间的访问隔离和存储隔离,然而云数据库自身存在的数据库管理系统(DBMS)漏洞有被外部攻击者非法利用的风险,导致租户之间的隔离措施失效。对于云数据库DBMS自身安全漏洞来说,首先要防护已经公布在CVE、CNNVD上,对数据库影响大、危害等级高的数据库漏洞,如导致数据库宕机、绕过身份验证、泄露敏感文件、利用难度低等。

    来自外部SQL注入防护需求。云数据库面向租户或应用提供数据的读写服务,同样要面对来自应用侧的SQL注入或攻击。外部攻击者以Web应用服务器为跳板,利用Web应用漏洞进行SQL注入,对普通用户进行提权,进行数据窃取或非法登录。云数据库中敏感信息管控需求。对于涉及敏感数据的云数据库运维来说,系统维护人员、外包人员、开发人员可能拥有直接访问数据库的权限,他们故意或无意地高危操作可能会对数据造成破坏,比如大范围的删除、修改以及高权限人员违规对敏感数据的批量导出行为。云数据库访问操作全面审计需求。通过监控模块对云数据库的性能分析可知,云数据库开启自身的审计和监控非常占用服务器资源,另外,如果仅利用数据库自带的审计功能,数据库管理员可随时关闭,导致无审计记录,事后追踪将缺乏依据。因此,需要采用独立的云数据库审计软件实现全面审计。

    云数据库中生产数据脱敏需求。云数据库中存储大量真实的生产数据,经常会被企业用来测试、分析和科学研究,如果都采用生产区的真实数据,一旦发生敏感数据泄露事件,程序开发、测试和分析人员都将承担一定责任;另一方面如果采用完全混淆的模拟数据,正常的开发、测试和分析工作将无法正常进行,数据利用陷入两难境地。敏感数据存储、备份和导出的加密需求。公有云上的关系型数据库服务(RDS)运行在一个多租户、分布式的环境,每个租户可建立自己数据库权限体系,若数据库中的敏感数据以明文存储,高权限用户可直接操纵数据库,窃取所有敏感信息;同时无法从权限上将数据库管理员的正常维护工作和敏感信息访问操作分开,敏感数据存储、备份和导出缺乏保护,这

    也是数据安全的一个薄弱环节。

    数据库入侵检测

    数据库入侵检测(Database Intrusion DetectionDBID

    数据库安全防护的重要内容,它继承并发展了基于主机和网络入侵检测的思想,首先采集数据库系统的审计数据或当前用户访问记录,其次对这些数据进行分析,使其能够满足规则挖掘或入侵检测的要求,最后判断当前的用户行为是否为攻击或误用行为,若该行为是攻击或误用行为则做出响应,维护数据库的安全。常用的数据库入侵检测技术有如下几种:

    基于统计的入侵检测技术

    基于统计的入侵检测技术是异常检测常用的一种技术,它假设正常的数据库操作存在一定的统计规律,利用用户在特定方面的度量标准提取其正常行为轮廓,通过设置阈值等方法,将待检测数据与已有的正常行为轮廓进行比较,如果超出阈值则认为是发生了入侵行为,优点是它不需要预先知道系统的安全缺陷,缺点是不能检测具有时序关系的入侵行为。

    基于专家系统的入侵检测技术

    专家系统是以安全专家对入侵行为的经验作为基础建立的,以知识库和推理机为中心,它将入侵行为编码为 if-then 形式的推理规则,检测时推理机根据推理规则对待检测数据进行推理演算,判断是否发生入侵行为,它对已知的攻击行为检测率高,对未知的攻击行为不能进行有效检测,规则库更新困难。

    基于模式匹配的入侵检测技术

    基于模式匹配的入侵检测技术是一种误用检测方法,它将已知的入侵特征表示成规则,形成规则库,将待检测数据与已知的入侵模式进行匹配,如果匹配成功,则认为发生了入侵行为,它使用时具有通用、简单的优点,却只能检测已知的攻击行为,检测效率较低。

    基于数据挖掘的入侵检测技术

    数据库用户在长期访问数据库的过程中会遵从一定的行为规律如哪些用户一般在什么时间的登录、哪些用户经常对哪些数据库对象执行哪些操作等,因此,通过对采集的大量数据库审计数据进行分析会发现用户在访问数据库过程中隐含的一些特定模式,即用户正常使用数据库的行为规律。对审计数据进行基于数据挖掘的入侵检测,数据准备完成对数据的过滤和预处理,消除数据集合中的噪声,对数据变量进行转换等工作;进而,利用数据挖掘方法,如聚类、关联、分类、序列分析等对数据实施数据挖掘分析,提取系统用户行为模式;在检测阶段将用户行为模式与规则库中规则进行匹配,如果匹配成功,则说明该行为模式正常,对规则库进行必要更新,任何继续检测其余行为模式,如果匹配不成功,则发出入侵警告。

    安全防护技术

    SQL注入是指通过把特定SQL命令插入到HTTP请求中,达到欺骗服务器以执行恶意SQL命令目的,从而窃取、篡改或者恶意删除数据

    防护SQL注入主要在两个阶段进行。

    第一是在Web服务源码编写阶段进行防护

    开发人员在编写源码时遵循防范SQL注入的经验性指导原则,使用“检查参数格式过滤特殊字符绑定参数”等方式使得SQL注入失效。但是这种方式的有效性取决于开发人员的安全防范知识水平的高低,往往容易留下不易察觉的漏洞。

    第二是在Web服务运行阶段进行防护,也就是部署入侵检测系统。

    传统的入侵检测系统有两种

    基于程序分析的SQL注入检测系统

    Web服务程序进行分析,包括静态分析和动态分析两种策略。

    静态分析是分析源代码,找出潜在的安全漏洞。

    动态分析是在程序运行时完成,通过编写特定的测试用例来测试程序。缺点是必须获知Web应用的源代码,而且分析覆盖率不能得到保障,容易出现漏测。

    基于特征匹配的SQL注入方法。建立当前数据库服务的特征语法树,从中提取出合法的SQL语句语法树,然后进行模式匹配,如果被检测的SQL语句不符合合法模式就产生警告。但是这种方法需要预先知道源代码,并且进行大量人工工作来分析出合法SQL模式。或者通过分析大量SQL注入实例,生成非法SQL语句的匹配模型,然后对实际运行的SQL语句进行模式匹配,如果被检测SQL语句符合非法模型,则判定为SQL注入。这种方法无需获知应用的源代码。但是这种方法的成功率高度依赖非法模型的全面性和准确性。需要耗费大量人工分析,并且容易出现检测遗漏。

    基于机器学习的SQL注入检测技术。 其主要方法步骤是:

    从HTTP请求中提取SQL查询语句,并进行预处理。

    然后通过词法分析和语法分析生成语法查询树。

    对语法树进行特征提取,提取的特征如语法分析树的高度,节点个数,样本长度,空格、数字、特殊字符占原始样本比例和语法树子树个数等。

    使用有监督学习算法对样本进行训练学习,形成一个SVM二分类器,并用该分类器对SQL语句进行检测。

    该方法的缺点在于需要人工进行特征分析,忽略了语法树所带来的语义结构特殊关系。生成的语法树节点中,树节点之间的连接存在潜在语义关系,然而原始方法中忽略了这一关系。

    数据脱敏

    数据脱敏又称为数据去隐私化,或数据变形

    在给定的规则、策略下对敏感数据进行变换、修改的技术机制,能够在很大程度上解决敏感数据在不可控环境中使用的问题,是数据库安全技术之一。

    数据脱敏的原理

    数据脱敏在保留数据原始特征的条件下,对某些敏感信息通过脱敏规则进行数据的变形,实现敏感隐私数据的可靠保护。在不违反系统规则条件下,对真实数据进行改造并提供测试使用,如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。只有授权的管理员或用户,在必须知晓的情况下,才可通过特定的应用程序与工具访问数据的真实值,从而降低重要数据在共享、移动时的风险。

    数据脱敏在不降低安全性的前提下,使原有数据的使用范围和共享对象得以扩展,能够帮助企业用户按照数据使用的目标,通过定义精确、灵活地脱敏策略,按照用户的权限等级,针对不同类别的数据以不同方式进行脱敏,实现跨工具、应用程序和环境的迅速、一致性的访问限制。

    数据脱敏通常遵循的几条原则包括

    数据脱敏算法一般来说是不可逆的,必须防止使用非敏感数据推断、重建敏感原始数据。

    脱敏后的数据应具有原始数据的特征。带有数值分布范围、具有制定格式的数据,在脱敏后应该与原始数据信息相似。姓名和地址等字段应该符合基本的语言认知,而不是无意义的字符串。在一些高要求的情况下,还可能要求具有与原始数据一致的字段唯一性、频率分布等等。

    保留数据的引用完整性,若被脱敏的字段是数据表主键,那么相关的引用记录必须保持同步更改。

    对可能生成敏感数据的非敏感字段也进行脱敏处理。例如,在病人的诊治记录中为隐藏姓名与病情的对应关系,将“姓名”作为敏感字段进行变换。但是,如果能够通过某“住址”的唯一性推导出“姓名”,则需要将“住址”一起变换。

    脱敏过程应是自动化、可重复的。生产环境中的数据生成速度快,脱敏过程需要能够在规则的引导下自动化进行,才能达到可用性要求。脱敏结果的稳定性,在某些场景下,对同一字段脱敏的每次计算结果都相同或者都不同,以满足数据使用方安全性等指标的要求。

    数据脱敏分类:根据数据的使用环境,可以将数据脱敏分为静态脱敏和动态脱敏。

    静态脱敏(SDM

    一般用在非生产环境,将敏感数据从生产环境抽取并脱敏后给到非生产环境使用,常用于培训、分析、测试、开发等非生产系统的数据库。静态脱敏可将脱敏设备部署于生产环境与测试、开发、共享环境之间,通过脱敏服务器实现静态数据抽取、脱敏、装载。

    动态脱敏(DDM

    常用在生产环境,在访问敏感数据即时进行脱敏,一般用来解决在生产环境需要根据不同情况对同一敏感数据读取时进行不同级别脱敏的场景。动态脱敏采用代理部署方式:物理旁路,逻辑串联。应用或者运维人员对数据库的访问必须都经过动态脱敏设备才能根据系统的规则对数据访问结果进行脱敏。

    数据脱敏的方法

    替换

    以虚构的数据代替真实的数据。

    无效化

    用特殊符号代替真值或真值得一部分,例如遮盖身份证号码的前6-14位。

    随机化

    采用随机数据代替真值,保持替换值的随机性以模拟样本的真实性。

    乱序

    对敏感数据列的数值进行重新随机分布,混淆原数值和其他字段之间的联系。

    平均取值

    针对数值型数据,首先计算它们的均值,然后使脱敏后的值在均值附近随机分布,从而保持数据的总和不便。

    反关联

    查找可能由某些字段推断出另一敏感字段的映射,并对这些字段进行脱敏,例如从出生日期可推断出身份证号。

    偏移

    通过随机移位改变数字数据。

    对称加密

    一种特殊的可逆脱敏方法。通过加密密钥和算法对原始数据进行加密,密文格式与原始数据在逻辑规则上一致,通过解密密钥可以恢复数据。

    动态环境控制

    根据预定义的规则,仅改变部分回应数据,如不在约定情况下访问业务数据时,控制数据内容,屏蔽特定字段内容。例如,重要客户信息只给业务模块的关键用户显示。

    华为数据库安全防护方案

     

    华为数据库安全产品是一个综合性安全产品,包含了数据库防火墙、数据泄露保护和数据库审计保护功能,同时内置了多种合规知识库,满足客户快速遵从法律合规和保护敏感数据需求。

    数据库防火墙

    注入防御:SQL注入防御

    访问控制:数据库访问控制、职责分离

    拖库识别和防御:拖库识别和防御

    自动学习:基于数据库活动行为生成数据库防火墙策略

    防火墙规则:组、表、过程规则

    敏感数据发现

    发现分类:自动发现和分类敏感数据

    合规扫描:包含SOX、HIPAA、PCI、DSS等规范

    策略:生成屏蔽策略

    扫描:主动扫描与定时扫描

    分级:支持不同级别的扫描,包括实例、库、表

    数据库审计

    合规遵从:SOX、HIPAA、PCI等,国际规范

    监控能力:实时监控、列级监控、运行状态、性能监控

    事件能力:登录、访问、查询、存储过程和命令管理等活动

    告警能力:实时风险告警

    审计日志:流量、入侵、安全等日志

    动态数据脱敏

    实时:实时脱敏

    分级:列级、行级、条件屏蔽

    多种支持:表、存储过程、视图屏蔽

    配置无影响:不用修改DB和应用层

    内容安全

    网络内容安全目前大致可以分为两类

    第一类是基于内容的访问控制

    包括网络协议恢复,基于数据包的流量监测,特征码匹配的病毒防护,基于内容的反垃圾邮件等技术;

    第二类是基于信息传播的互联网安全管理问题

    反映的是网络用户公开发布的信息所带来的对社会公共安全问题,这里面所涉及的技术主要包括主题信息监控、舆情监控、社交网络社团挖掘等。

     

    公有云推出的内容审核服务对用户上传的图片、文字、视频进行内容审核,自动识别涉黄、暴恐、政治敏感信息,并对其进行过滤。

    内容审核以开放API(Application Programming Interface,应用程序编程接口)的方式提供给用户,用户通过实时访问和调用API获取推理结果,帮助用户自动采集关键数据,打造智能化业务系统,提升业务效率。

    目前内容审核包括内容审核-图像、内容审核-文本、内容审核-视频。提供了图像反黄检测、文本内容检测、图像内容检测和视频审核服务。

    在视频内容审核,网站论坛,在线商城,电商评论,聊天,注册昵称,弹幕审核。

    法律合规要求

    • 系统中存储什么信息?
    • 系统的信息位于何处?
    • 谁能够访问系统?
    • 他们可以访问什么?
    • 访问是否合适?

    等保是一个持续的过程,产品的部署只是形式,整网的系统化安全建设和持续的产品安全能力提升才是源头活水。
    第二十一条
    国家实行网络安全等级保护制度。网络运营者应当按照网络安全等级保护制度的要求,履行下列安全保护义务,保障网络免受干扰、破坏或者未经授权的访问,防止网络数据泄露或者被窃取、篡改
    第三十一条
    国家对公共通信和信息服务、能源、交通、水利、金融、公共服务、电子政务等重要行业和领域,以及其他一旦遭到破坏、丧失功能或者数据泄露,可能严重危害国家安全、国计民生、公共利益的关键信息基础设施,在网络安全等级保护制度的基础上,实行重点保护。关键信息基础设施的具体范围和安全保护办法由国务院制定。
    第五十九条
    网络运营者不履行本法第二十一条、第二十五条规定的网络安全保护义务的,由有关主管部门责令改正,给予警告;拒不改正或者导致危害网络安全等后果的,处一万元以上十万元以下罚款,对直接负责的主管人员处五千元以上五万元以下罚款。

    主要依据:根据系统被破坏后,对公民、社会、国家造成的损害程度定级。

    网络安全等级保护是根据信息系统在国家安全、经济建设、社会生活中的重要程度,以及信息系统遭到破坏后对国家安全、社会秩序、公共利益,以及公民、法人和其他组织的合法权益的危害程度等因素,将信息系统安全等级由低到高分为五个等级。

    第一级为自主保护级,适用于一般的信息和信息系统,其受到破坏后,会对公民、法人和其他组织的权益有一定影响,但不危害国家安全、社会秩序、经济建设和公共利益。

    第二级为指导保护级,适用于一定程度上涉及国家安全、社会秩序、经济建设和公共利益的一般信息和信息系统,其受到破坏后,会对国家安全、社会秩序、经济建设和公共利益造成一定损害

    第三级为监督保护级,适用于涉及国家安全、社会秩序、经济建设和公共利益的信息和信息系统,其受到破坏后,会对国家安全、社会秩序、经济建设和公共利益造成较大损害

    第四级为强制保护级,适用于涉及国家安全、社会秩序、经济建设和公共利益的重要信息和信息系统,其受到破坏后,会对国家安全、社会秩序、经济建设和公共利益造成严重损害

    第五级为专控保护级,适用于涉及国家安全、社会秩序、经济建设和公共利益的重要信息和信息系统的核心子系统,其受到破坏后,会对国家安全、社会秩序、经济建设和公共利益造成特别严重损害。

    测评结论

    符合性判别依据

    综合得分计算公式

    符合

    信息系统中未发现安全问题,等级测评结果中所有测评项得分均为5分。

    100分

    基本符合

    信息系统中存在安全问题,但不会导致信息系统面临高等级安全风险。

     

     

    >=75或视情况而定

    不符合

    信息系统中存在安全问题,而且会导致信息系统面临高等级安全风险。

     

     

     

     

    华为云全栈防护体系

    租户业务安全设计

    需求分析

    生产环境

    针对物理层面的主要防护对象为机房,防护措施为:租用运营商机房,防护目标为:租用成熟的运营商机房,依靠其成熟的管理能力和经验,使客户企业专注于上层应用构建。

    针对网络层面的主要防护对象为:互联网恶意攻击、用户访问。具体防护措施:部署高防DDoS、防火墙、WAFDP等产品、部署两套独立的VPN产品。防护目标:通过部署安全防护措施,阻断来自互联网上不同类型的恶意攻击,针对省份、地市的业务用户和信息化用户,采用两套不同的VPN设备,对齐访问来源最大限度的进行控制。

    针对网络主机层面的主要防护对象为设备配置,防护措施为:人工安全加固,防护目标为:随客户机房搬迁,进行网络设备、安全设备、主机、应用的安全加固工作。

    针对网络应用层面的主要防护对象为跨网段访问控制,防护措施为:三层方式访问,VLAN间隔离,防护目标为:将客户机房生产环境下挂的物理服务器和虚拟机服务器网关指向核心交换,不同应用系统使用不同的VLAN进行隔离,跨VLAN不能进行通讯。

    针对主机层面的防护对象为:恶意代码、软件;虚拟机,防护措施:企业级防病毒软件、虚拟机快照,防护目标:通过在部分Windows服务器上部署企业级杀毒软件,对恶意代码与软件进行查杀,了解主机安全情况,定期对虚拟机进行快照,以便在出现问题后快速进行回滚操作。

    防护安全目标

     

     

     

     

    安全巡检

    通过客户SOC 或态势感知对“主机安全服务”、“漏洞扫描服务”、“WAF”以及“DDoS高防”等安全产品的日志或告警进行实时监控并检查安全隐患;使用漏洞扫描、渗透测试、SOC等工具定期审计业务平台整体安全状况,并输出相应的安全报告;通过现网安全系统,如DDoS/WAF/主机安全/数据库审计等安全产品,分析溯源安全攻击情况,,并及时清除安全隐患。

    应急响应

    紧急安全事件发生时,根据应急预案及时实施应急响应操作,保障平台业务稳定;紧急、高危漏洞发布后,第一时间梳理影响范围及修复方案,处理安全威胁;定期进行应急演练不断强化应急处置能力。

    权限管理

    根据人员岗位变动,实时调整权限管理规则,避免越权事件发生;根据变更计划对变更执行人员的权限实时分配,避免信息泄露、人为操作隐患。

     

    客户的业务部署在运营商的云端环境,通过域名方式访问。

    在华为云灾备环境部署数据备份环境,华为云环境和客户业务环境通过Ipsec VPN打通,实现两者之间的通信,以此让灾备环境可以跨云进行备份。

    当出现故障时,将业务域名通过修改DNS解析到华为云端,客户访问的业务将会经过华为云端的抗DDOS、WEB应用防火墙(WAF)进行清洗,将DOS流量、针对WEB业务的攻击流量过滤。之后经过LB分发到华为云内部署的备份应用服务器、数据库服务器,从而实现业务的不中断访问,并通过华为云内的一系列云安全服务保证业务安全性。

    同时在华为云内部署针对数据库、应用服务器漏洞扫描服务器、数据库加密服务,提供针对主机的安全服务、针对数据的数据库安全服务。

    外网边界通过DDoS防御保护业务可用性:由于华为云在外网边界,已经部署了防火墙、DDoS、VPN、IPS等安全设备。因此仅需要对互联网提供的服务进行DDoS的防护。建议采用DDoS流量清洗+DDoS高防联动的方案对所有EIP提供防护,最大限度提高高防IP的使用率,降低在低攻击带宽场景下的业务时延。

    内网边界通过NGFW实现安全隔离:由于专线之间不存在大规模的DDoS流量攻击,因此建议在运营商云平台到华为云专线之间增加NGFW来一体化实现包含反病毒,IPS,DLP在内的应用层流量检测和威胁流量阻断。

    租户间通过安全组网络隔离:以业务系统为界进行VPC子网隔离,同一应用中不同节点根据节点业务端口进行细粒度划分,最大程度上保证云主机网络安全性。

     

     

    对外服务业务系统EIP开启WAF防护:使用华为云WAF对客户业务系统进行Web攻击防护,阻断SQL注入、跨站脚本、CSRF、命令注入等攻击行为。为进一步提高WAF策略防护的精确度,建议业务上线初期使用检测不阻断的原则。

    Web漏洞扫描实时跟进漏洞信息:使用漏洞扫描系统定期对客户业务系统和主机进行扫描,能够做到实时跟进系统、Web漏洞,及时修复漏洞,即使无法及时修复也可以通过外层防护的方式防止漏洞被利用造成安全问题。

    渗透测试验证业务Web漏洞与逻辑问题等:业务系统上线前,组织华为专家团队针对客户云业务系统进行无破坏性渗透测试,通过人工验证的方式验证现网存在的Web漏洞,并出具测试报告给业务团队进行漏洞整改,整改后进行新一轮回归测试,进一步确保业务系统安全性。

    数据加密服务保证业务数据保密性、完整性和可用性:华为云KMS可以为OBS(对象存储)、EVS(云硬盘)等服务提供加密功能,用户不需要花费大量成本来保证密钥的保密性、完整性及可用性。KMS还能与CTS集成,审计所有密钥的使用情况,帮助用户满足审计和合规性要求;

    数据库安全服务严格控制数据访问权限、保证数据脱敏:数据库安全服务可以为客户业务系统数据库提供数据访问控制、数据脱敏、数据库审计和注入攻击防护等功能,进一步保障数据的安全存储。

    态势感知系统掌握云业务整体安全

    态势感知应用大数据和AI技术,通过客户网络流量,应用日志数据以及租户部署的WAF,DDoS,主机安全,漏洞扫描等安全产品输出信息,进行动态的系统级整体安全状况分析和展示,及时处理安全告警事件,降低系统级的安全威胁风险。

    渗透测试进一步验证业务安全性

    渗透测试是除安全产品防护、安全扫描之外,保护客户云业务安全性的重要手段,渗透测试采用黑盒测试的方法,从黑客角度出发,测试客户云业务安全性,除一般的Web漏洞以外还可以针对业务源代码的逻辑漏洞进行验证测试,进一步加强了业务系统的安全保障。

    堡垒机细粒度授权保障运维操作规范性

    除堡垒机自身特有的审计功能以外,重点对运维人员的操作权限进行细粒度划分,操作权限细分到IP地址和时间,根据应用系统责任人不同划分不同的可操作IP地址,且权限到期自动收回;指令控制方面,严格限制高危操作的执行范围,对影响系统稳定性的操作严格过滤。

    安全事件响应

    针对上线业务系统将行开展安全巡检,包括日志分析、告警分析、异常流量监控、攻击状态识别、系统漏洞扫描、系统渗透式测试等。主动识别系统可能存在的安全事件,及时知会业务团队,启动问题处理,及时消除安全风险。定期就整体的系统安全性状态进行汇报。

    漏洞情报共享

    华为自研的全球漏洞系统PSRT,收集全球的软件(含商用以及开源)漏洞,通过版本信息识别可以确认漏洞影响的版本,根据CVSS模型结合具体业务进行漏洞的安全威胁风险性评估,提供漏专业的洞修复建议。漏洞修复以服务可用性为第一优先级,在业务可用的前提下提供风险最小的漏洞修复方案。

    业务生命周期管理

     

     

     

     

    安全方案设计

    结合企业业务场景,从网络层,应用层,主机层,数据以及管理多个方面进行了安全方案设计,量身定制安全体系,进行网络隔离和账号权限管控,为企业提供全方位的安全性保障

    网络隔离

    根据业务平面(管理面/业务面)和业务类型两个维度进行细粒度的的子网/安全组划分,通过配置子网ACL/安全组规则实现不同网络分区间的隔离

    管理账号权限划分

    通过对账户下的子用户按照最小权限原则规划角色,避免误操作以及权限外操作造成的损失

    安全监控

    • 专业的监控人员人员。
    • 专业的监控平台
    • 7*24不间断监控

    定期对系统进行安全巡检,包括日志分析、告警分析、异常流量监控、攻击状态识别、系统漏洞扫描、系统渗透式测试等。主动识别系统可能存在的安全事件,及时知会业务团队,启动问题处理,及时消除安全风险。

    应急响应

    • 一旦发生疑似入侵事件,华为云安全专家团队立即进入应急响应流程。
    • 华为安全专家在客户授权下对系统账户,计划任务,关键文件等事项的检查并结合华为云米兰达大数据平台排查主机是否被黑客入侵。
    • 一旦确认入侵,华为安全专家会立刻采取措施对正在进行的攻击进行处理,阻止黑客的进一步攻击。
    • 查找和清理病毒,蠕虫等恶意程序以及WEB站点中的Web shell,挂马等,帮助客户快速恢复业务。
    • 分析黑客的入侵手法,尽可能定位入侵原因
    • 提供修复建议,进行加固,防止再次入侵
    • 撰写安全应急报告

     

    展开全文
  • 1.0.1 为规范数据中心的设计,确保电子信息系统安全、稳定、可靠地运行,做到技术先进、经济合理、安全适用、节能环保,制定本规范。 1.0.2 本规范适用于新建、改建和扩建的数据中心的设计。 1.0.3 数据中心的设计应...
  • 第五章.系统安全分析与设计

    千次阅读 2022-02-16 17:51:55
    系统安全分析与设计第一节.信息系统安全属性第二节.对称加密技术与非对称加密技术对称加密技术非对称加密技术第三节.信息摘要与数字签名信息摘要数字签名第四节.数字信封与PGP数字信封的原理PGP练习题——设计邮件...
  • 为了在电信专用房屋设计中做到技术先进、经济合理、安全适用、确保质量的原则,特制定本规范。本规范适用于各电信运营企业新建的长途电信枢纽楼、电信综合楼、本地电信楼、卫星通信地球站、海缆登陆站、移动通信基站...
  • 译者序AWS用户广泛,产品线复杂,AWS发布的白皮书《Architecting for the Cloud-AWS Best Practices》介绍了常见场景下云...本手册分为两部分第一部分 传统环境和云环境的差异(上一篇文章)第二部分 云架构设计原...
  • 另外我公司非常珍惜建设单位给予我们的这次宝贵的机会,若我公司有幸中标,我们将依据本《施工组织设计》确定的原则,遵循我公司的技术管理规定和质量体系文件,在设计交底图纸会审之后编制详细的专项工程施工方案和...
  • 是确保优质、低耗、安全、文明、高速完成全部施工任务的重要经济技术文件。 (2) 编制依据: 1)本工程设计图纸; 2)本工程的招标文件及招标答疑; 3)现行国家有关规范、标准、规程。 (A)《土方与爆破工程施工及验收...
  • 一、核心原则 1、尽量不在数据库做运算 俗话说:别让脚趾头想事情,那是脑瓜子的职责。作为数据库开发人员,我们应该让数据库多做她所擅长的事情。尽量不在数据库做运算,复杂运算移到程序端CPU,尽可能简单应用...
  • 3.经济性和适用性 软件安全需求的获取 方法:头脑风暴,策略分解,使用用例和滥用案例建模,问卷调查与访谈,数据分类,主/客体关系矩阵,软件安全需求跟踪矩阵 安全设计 目的:软件安全设计的目的是将安全属性设计...
  • 然后对系统建设进行了经济效益、技术开发与社会操作等方面的可行性分析,描述了用户角色构成,通过功能用例图描述了系统多层次功能构成,描述了业务流程实施步骤,阐述了系统在性能、安全等方面的非功能性需求。...
  • 核心技术方法”,为项目智能化系统工程设计适用的智能化系统整体解决方案。 智能化系统中的各个子系统通过集成,应当相互联系,资源共享、信息共享, 增强对突发事件的响应能力;提高设备利用率,降低能耗,节约...
  • 数据库设计方法和原则

    万次阅读 2015-03-22 22:41:29
    数据库设计方法和原则 11 个重要的数据库设计规则 来源: 开源中国社区 英文原文: 11 Important Database designing rules  简介  在您开始阅读这篇文章之前,我得明确地告诉您,我并不是一个数据库设计...
  • 1.2.1 以满足招标文件的全部要求为基本原则,领会设计理念,体现设计意图,发挥集团总公司的整体优势,达到优质高速、安全文明、技术先进、经济适用的目的。 1.2.2 围绕工程质量目标,在质量控制上,以预控和过程控制为...
  • 交互设计原则

    千次阅读 2013-11-18 11:21:12
    交互设计原则:不要全盘复制机械时代产品的用户界面,而一定要按照信息时代的客观情况进行改良 交互设计原则:没有人愿意停留在新手级别 http://ued.5173.com/wp-content/2010/08/QQ 截图未命名.png ...
  • 用户手册 编写说明前言技术工作总结报告1项目概述2研制背景和意义3主要研制过程4设计原则5组成框图6工作原理7工作流程8关键技术和创新点入侵式安全9国内外同类产品比较10逻辑框图和电路原理图11主要器件及说明12主要...
  • 这是一份我暑假实训的时候按要求出的一份安全防护方案的设计,大家不要抄好吗! 一、 背景概述 4 二、 工控系统信息安全需求 5 2.1工业控制系统和传统IT系统差异化分析 5 2.2工业控制系统所面临威胁分析 7 ...
  • 数据安全分类分级剖析

    千次阅读 2021-09-15 00:04:46
    数据分类分级对于数据的安全管理至关重要,安全分类分级是一个“硬核课题”,从数据治理开始,除了标准化和价值应用,重要的课题就是质量+安全安全是底线,是价值应用的前提和基础。数据分类可以为数据资产结构化...
  • 性能优化原则和优化模式

    千次阅读 2018-10-02 12:08:32
    “存在即合理”,世界上没有完美的设计方案,任何方案都是一系列设计原则的妥协结果,所以本文主要关注点是解决所碰到的问题而不是如何绕过这些设计原则。下面对文中重要的设计原则进行详细阐述,在后面需要运用该...
  • 电气控制电路图——(3)设计

    千次阅读 2020-06-02 12:19:07
    一、电气控制电路设计原则 1、保证控制电路安全可靠原则 (1)选用可靠的元件。选用可靠的元件就是选用机械和电气寿命长、结构坚实、容量充足、动作可靠、抗干扰性能好的电器 。 (2)应具有完善的保护环节和必要的...
  • 信息安全发展的三个阶段:通信保密,信息安全,信息保障 Wind River的安全专家则针对IoT设备安全提出了如下建议: 安全启动 设备首次开机时,理应采用数字证书对运行的系统和软件作认证; 访问控制 采用不同...
  • 2.面向性能的设计与开发

    千次阅读 2018-10-05 16:17:55
    最佳系统性能始于设计,并贯穿系统的整个生命周期。在初始设计阶段仔细考虑性能问题,在生产过程中更容易调整系统。 本章包含以下部分: ...• 应用设计原则 • 负载测试,建模和实现 • 部署新应用程序
  • 一直以来都多少涉及到计算机安全的方面的话题,近期正好有时间,就开始正式系统的去学习计算机安全相关的概念,开始两章都是些基础概念,算作梳理。一、计算机安全的概念: 1、计算机安全是指为了自动化信息系统...
  • 没有一个平台化的底座很难落地,毕竟在构建能力的时候需要涉及很多技术,例如,拆分微服务、构建微服务、做持续集成/持续交付、自动化测试、敏捷部署、自动化运维、建立数据标准以及构建数据安全体系等。如果一个...
  • 如何设计真正基于通证经济落地的商业生态模式设计? 作者:廖国东 我一直在寻找一种不存在群体互害的商业模式,而且财富的积累也不是一个零和游戏,所以我从没放弃过探索或创造出一种通赢运行机制:只要合理的利益...
  • 端对端原则的思考及反思

    千次阅读 2018-03-31 18:21:47
    中文摘要摘要:端到端原则是一种分布式系统中各模块间功能定位的设计原理,指从代价和性能的角度分析,在网络的最核心的部分应该只做数据的传输而不能去做一些其他的应用,而数据是否正确传输则应该放到应用层去检查...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 13,475
精华内容 5,390
关键字:

安全设计原则 经济适用原则

友情链接: dingshiguanji.rar