精华内容
下载资源
问答
  • 机密数据保密系统
    千次阅读
    2012-08-27 12:24:45

    您作为企业的管理者,是否担心花重金研发的产品源代码,以及图纸,设计文档,被员工复制带走造成泄密呢?下面这些泄密途径,您考虑到了吗?

    - 内部人员将机密电子文件通过U盘等移动存储设备从电脑中拷出带走;
    - 内部人员将自带笔记本电脑接入公司网络,把机密电子文件复制走;
    - 内部人员通过互联网将机密电子文件通过电子邮件、QQ、MSN等发送出去;
    - 内部人员将机密电子文件打印、复印后带出公司;
    - 内部人员通过将机密电子文件光盘刻录或屏幕截图带出公司;
    - 内部人员把含有机密电子文件的电脑或电脑硬盘带出公司;
    - 含有机密电子文件的电脑因为丢失,维修等原因落到外部人员手中。
    - 外部电脑接入公司网络,访问公司机密资源盗取机密电子文件泄密。

    机密数据保密系统是以研发机构的防泄密需求为原型,结合游戏公司,ERP开发公司,研究设计院,工控企业,通讯研发等数据保密需求的特点而设计,采用世界上最先进的第三代透明加密技术---内核级纵深立体加密技术,吸收云和无盘工作站的优点,是目前最优秀的源代码,图纸,文档等机密数据保密系统。

    机密数据保密系统示意图

    特点:

    --研发应用软件安装在本地,机密数据在服务器上。服务器上的机密数据在使用过程中不落地,或落地即加密。

    --员工电脑上的所有开发的成果只能存放到服务器上,或者本地的加密盘中。

    --沙盘是和外界隔绝的,所以不会泄密。本地列为百名单的软件如QQ,MSN,IE浏览器等可以正常上网,但不会泄密。

    --SDC沙盒是个容器,什么都能装,和进程无关,和文件格式无关,什么软件都可以跑。和文件也大小无关,不会去破坏文件。也不像其他的加密软件一样,修改文件自身内容。可靠性高。

    --任何涉密资料拿出涉密环境,都必须经过审核流程。

    --外来PC接入网络,无法使用网内任何机密资源,不能访问服务器,成为孤岛。

    应用例:

    某游戏开发公司

    需求:开发团队开发的游戏源代码为公司核心机密信息,不能被员工带回家。
    设计文档的使用范围也需要控制。该公司主要使用C/C++/java开发,开发工具使用VC和Ecipse,
    代码管理使用CVS。
    解决方案:构建机密数据保护系统,所有源代码及相关文档,编译结果都加密保护起来,达到了数据防扩散目的。

    这种模型,同类单位,如软件设计院等,都适用。


    更多相关内容
  • 金甲企业数据保密系统EDS的详细功效说明书,可以了解此类软件的具体功能和适用范围,非常适合想上此类加密软件实施项目的单位和个人了解和参考
  • 随着企业信息化的发展,信息系统越来越多的使用于日常工作中,成为不可或缺的...虚拟化、云计算等技术的发展更是为许多跨地区、跨国家的企业节约了大笔的专线费用,并且提供了信息传送的实时性、可靠性、保密性的保证。
  • 二、 大数据安全与隐私保密需求 2.1 大数据安全 2.2 大数据隐私保密 三、 大数据安全与隐私保护技术框架 3.1 大数据安全技术 1.大数据访问控制 2.安全检索 四、基本密码学工具 4.1 加密技术 4.2 数字签名...

    目录

    一、 绪

    二、 大数据安全与隐私保密需求 

    2.1 大数据安全

    2.2 大数据隐私保密

    三、 大数据安全与隐私保护技术框架

    3.1 大数据安全技术

    1.大数据访问控制

     2.安全检索

    四、基本密码学工具

    4.1 加密技术

    4.2 数字签名技术

    4.3 Hash 和 MAC 技术

    五、隐私保密技术基础知识

    5.1 数据隐私保护场景

    5.2 隐私保密需求


    一、 绪

            随着云计算、物联网及移动互联网技术的迅速发展,人们已经迈入大数据时代。大数据技术正在加速推进数据资源的汇集,成为当代社会的三大产业支柱之一。但同时,大量数据的融合、分析与应用对用户带来了前所未有的隐私泄露威胁正引发学术界产业界和广大互联网用户的广泛关注。目前安全与隐私保密问题已成为大数据技术中重要的研究内容之一。

    二、 大数据安全与隐私保密需求 


    2.1 大数据安全


          大数据普遍存在巨大的数据安全需求。大数据由于价值密度高,往往成为众多黑客觊觎的目标,吸引了大量攻击者铤而走险。例如在2017年,我国某著名互联网公司内部员工盗取并贩卖涉及交通、物流、医疗、社交、银行等个人信息50亿条,通过各种方式在网络黑市贩卖。

           经典的数据安全需求包括数据机密性、完整性和可用性等,其目的是防止数据在数据传输、存储等环节中被泄露或破坏。通常实现信息系统安全需要结合攻击路径分析、系统脆弱性分析以及资产价值分析等,全面评估系统面临的安全威胁的严重程度,并制定对应的保护、响应策略,使系统达到物理安全、网络安全、主机安全、应用安全和数据安全等各项安全要求。而在大数据场景下,不仅要满足经典的信息安全需求,还必须应对大数据特性所带来的各项新技术挑战。

           挑战之一是如何在满足可用性的前提下保护大数据机密性。安全与效率之间的平衡一直是信息安全领域关注的重要问题,但在大数据场景下,数据的高速流动特性以及操作多样性使得安全与效率之间的矛盾更加突出。以数据加密为例,它是实现敏感数据机密性保护的重要措施之一。     

           挑战之二是如何实现大数据的安全共享。访问控制是实现数据受控共享的经典手段之一。但在大数据访问控制中,用户难以信赖服务商能够正确实施访问控制策略,且在大数据应用中实现用户角色与权限划分更为困难。以医疗领域应用为例,一方面医生为了完成其工作可能需要访问大量信息,专业性很强,安全管理员难以一一设置;但另一方面又需要对医生行为进行监测与控制,限制医生对病患数据的过度访问。因此,实现大数据访问控制不仅需要智能化的安全策略管理,而且需要可信的访问控制策略实施机制。

           挑战之三是如何实现大数据真实性验证与可信溯源。当一定数量的虚假信息混杂在真实信息中时,往往容易导致人们误判。例如,一些点评网站上的虚假评论可能误导用户去选择某些劣质商品或服务。导致大数据失真的原因是多种多样的,包括伪造或刻意制造的数据干扰工干预的数据采集过程中引入的误差、在传播中的逐步失真、数据源更新与失效等,这些因素都可能最终影响。数据分析结果的准确性。需要基于数据的来源真实性、传播途径、加工处理过程等,了解各项数据可信度,防止分析得出无意义甚至错误的结果。

    2.2 大数据隐私保密

           由于有相当一部分大数据是源自人的,所以除安全需求外,大数据普遍还存在隐私保护需求。大量事实表明,未能妥善处理隐私保护问题会对用户造成极大的侵害。以往企业认为,数据经过匿名处理后,不包含用户的标识符,就可以公开发布了。但事实上,仅通过这种简单匿名保护并不能达到隐私保护目标。

           由于去匿名化技术的发展,实现身份匿名越来越困难。攻击者可从更多的渠道获取数据,通过多数据源的交叉比对、协同分析等手段可对个人隐私信息进行更精准的推测,使原有基于模糊、扰动技术的匿名方案失效。不仅同质数据源可以去匿名化,不同类型数据之间也可以关联。通过搜集用户的旅游签到、电影点评、购物记录等足够多的信息碎片,将跨应用的不同账号联系起来,将用户不同侧面的信息联系起来,也可以识别出用户的真实身份。例如新浪微博明星小号曝光导致明星形象危机的事件层出不穷。此外,用户轨迹、行为分析也可能导致用户个人身份泄露。

           总体而言,目前用户数据的收集、存储、管理与使用等均缺乏规范,更缺乏监管,主要依靠企业的自律。用户无法确定自己的隐私信息的用途。而在商业化场景中,用户应有权决定自己的信息如何被利用,实现用户可控的隐私保护。例如用户可以决定自己的信息何时以何种形式披露,何时被销毁,主要包括数据采集时的隐私保护、数据共享和发布时的隐私保护、数据分析时的隐私保护、数据生命周期的隐私保护以及隐私数据可信销毀等。

    三、 大数据安全与隐私保护技术框架

           不同的安全需求与隐私保护需求一般需要相应的技术手段支撑。例如,针对数据采集阶段的隐私保护需求,可以采用隐私保护技术,对用户数据做本地化的泛化或随机化处理。针对数据传输阶段的安全需求,可以采用密码技术实现。而对于包含用户隐私信息的大数据,则既需要采用数据加密、密文检索等安全技术实现其安全存储,又需要在对外发布前采用匿名化技术进行处理。但这种技术划分也并不是绝对的,相同的需求可以用不同技术手段实现。以位置隐私保护为例,虽然传统上多采用泛化、 失真等隐私保密技术。

    3.1 大数据安全技术

           大数据安全技术旨在解决数据在传输、存储与使用各个环节面临的安全威胁。其面临的核心挑战在于满足数据机密性、完整性、真实性等安全目标的同时,支持高效的数据查询、计算与共享。介绍以下几类关键技术:

    1.大数据访问控制

           大数据访问控制包括采用和不采用密码技术两种技术路线。前者的代表是密文访问控制,无须依赖可信引用监控器,安全性强,但加密带来的计算负担影响性能。后者的主要代表是角色挖掘、风险自适应访问控制,其特点是效率高、灵活度高,但依赖可信引用监控器实施数据的安全策略,面临可信引用监控器构建困难的问题。


    1)基于密码学的访问控制
           为了保障云环境中数据的安全共享,数据属主需要确保解密密钥只授权给合法用户,这通常使用基于密码学的访问控制技术来解决。根据使用的加密算法类型可大致分为两类:一类基于传统的公钥密码学,另一类基于函数加密(也称功能加密)的公钥密码学。前者基于传统的公钥密码学(如公钥基础设施( PKI )等)保护数据的加密密钥,或将其存储在专门的“锁盒”里。后者是一种新的公钥加密技术,支持细粒度访问控制和丰富的策略表达方式。属性加密( ABE ,也称基于属性的加密或属性基加密)是一种典型的函数加密,当前 ABE 密文访问控制技术的研究主要集中在权限撤销、多权威机构等方面。

    2)角色挖掘
           角色挖掘起源于基于角色的访问控制,能够辅助管理员发现系统中的潜在角色,从而简化管理员的权限管理工作。其中,基于机器学习的角色挖掘技术可用性更强,角色可合理解释,而且策略反映权限实际使用情况。生成角色模型用途广泛,既可用于策略中错误的发现和标识,也可用于权限使用过程中的异常检测。


    3)风险自适应访问控制
            针对大数据场景中安全管理员缺乏足够的专业知识,无法准确地为用户分配数据访问权限的问题,人们提出了风险自适应访问控制技术,将风险量化并为使用者分配访问配额。评估并积累用户访问资源的安全风险,当用户访问的资源的风险数值高于某个预定的门限时,限制用户继续访问。通过合理定义与量化风险,提供动态、自适应的访问控制服务。


     2.安全检索

           加密是保护云环境中数据安全的重要手段,但是密文数据的高效使用离不开密文检索,典型需求包括关键词检索与区间检索。前者又常被称为可搜索加密( searchable encryption ),包括对称可搜索加密和非对称可搜索加密。后者又可以进一步划分为单维、二维和多维区间检索。除密文检索外,安全检索还包括隐秘信息获取( PIR )以及健忘 RAM ( Oblivious RAM , ORAM )等多种类型。

    1) PIR 系列与 ORAM 
           隐秘信息获取是源于数据库检索领域的一种安全需求,指用户在不向远端服务器暴露查询意图的前提下对服务器的数据进行查询并取得指定数据; Oblivious RAM 在读写过程中向服务器端隐藏访问模式等。两者均关注用户保护访问模式,防止用户的意图被攻击者或服务器探知,区别在于后者同时还关注数据机密性。


    2)对称可搜索加密
           可搜索加密研究快速检索出包含特定关键词或满足关键词布尔表达式的密文文档的方法。对称可搜索加密( Symmetric Searchable Encryption , SSE )适用于数据提交者与查询者相同的使用场景。 SSE 经历了顺序查询、倒排索引、索引树等构造发展历程,当前查询性能已有了极大提升。它关注的安全目标由基础性的选择关键字语义安全(如 IND - CKA 、IND2-CKA等)扩展至查询模式安全性、查询的前向安全性等多种安全性质。相关研究包括多关键字查询、模糊查询、 Top — k 查询和多用户 SSE 等。


    3)非对称可搜索加密
           与 SSE 不同,非对称可搜索加密( Asymmetric Searchable  Encryption , ASE )的主要应用场景是第三方检索。由于数据所有者与检索者不是同一个人,所以一般采用公钥技术实现关键词陷门生成与检索。


    4)密文区间检索
           密文区间检索是实际应用中另一大类重要需求,旨在利用数据之间存在的顺序关系,不必按顺序扫描,而以更快速的方法查找指定区间的数据。典型方案包括近邻数据分桶、保序加密、密文索引树等。各类方案提供不同程度的安全性,例如方案是否暴露所有数据间的顺序关系、查询条件上下界的大小关系、区间之间的包含关系等。各类方案的效率也存在显著差异,一个优秀的密文区间检索方法能很好地实现检索效率与安全性之间的平衡。

    四、基本密码学工具

           密码学可有效地保障信息的机密性、完整性、认证性和不可否认性,是大数据安全和隐私保护的基础工具。重点介绍密码学的一些基本概念:

    4.1 加密技术

    传统加密技术的主要目标是保护数据的机密性。一个加密算法被定义为一对数据变换。其中一个变换应用于数据起源项,称为明文,所产生的相应数据项称为密文。而另一个变换应用于密文,恢复出明文。这两个变换分别称为加密变换和解密变换。习惯上,也使用加密和解密这两个术语。加密和解密的操作通常都是在一组密钥控制下进行的,分别称为加密密钥和解密密钥。主要有两大类加密技术:一类是对称加密,另一类是公钥加密。对称加密的特征是加密密钥和解密密钥一样或相互容易推出;公钥加密(也称非对称加密)的特征是加密密钥和解密密钥不同,从一个难以推出另一个。

    1.对称加密技术

           对称加密分为两种:一种是将明文消息按字符逐位地加密,称为序列密码(也称流密码);另一种是将明文消息分组(每组含有多个字符),逐组地进行加密,称为分组密码,例如分组密码 AES 和SM4以及序列密码 ZUC 。 AES 是美国国家标准技术研究所( NIST )公布的一个分组密码,其分组长度为128b,密钥可为128b、192b或256b。SM4是中国公布的一个商用分组密码标准,其分组长度和密钥长度均为128b。 ZUC (祖冲之序列密码算法)是一个序列密码,已成为国际3GPP标准,也是中国的国家标准。 ZUC 算法逻辑上分为上中下3层,上层是16级线性反馈移位寄存器( LFSR ),中层是比特重组( BR ),下层是非线性函数

    2.公钥加密技术

           公钥密码是由 Diffie 和 Hellman 于1976年首次提出的。与对称密码不同,公钥密码采用两个不同的密钥将加密功能和解密功能分开。一个密钥称作私钥,像在对称密码中一样,该密钥被秘密保存。另一个密钥称作公钥,不需要保密。公钥密码必须具有如下重要特性:给定公钥,要确定出私钥是计算上不可行的。

    公钥密码的设计比对称密码的设计具有更大的挑战性,因为公钥为攻击算法提供了一定的信息。目前使用的公钥密码的安全性基础主要是数学中的困难问题。最流行的有两大类:一类是基于大整数因子分解问题的,如 RSA 公钥加密;另一类是基于离散对数问题的,如椭圆曲线公钥加密、SM2公钥加密等。1977年由 Rivest 、 Shamir 和 Adleman 提出了第一个比较完善的公钥密码,这就是著名的 RSA 算法。 RSA 也是迄今应用最广泛的公钥密码,其安全性基于大整数因子分解困难问题:已知大整数 N ,求素因子 p 和 q ( N = pq )是计算困难的。1985年, Koblitz 和 Miller 分别独立地提出了椭圆曲线密码,( Elliptic Curve Cryptography , ECC )。椭圆曲线密码的安全性基于椭圆曲线群上计算离散对数困难问题。椭圆曲线密码能用更短的密钥来获得更高的安全性,而且加密速度比 RSA 快,因此,在许多资源受限的环境中得到了广泛的应用。SM2椭圆曲线公钥密码算法是中国的一个公钥密码标准,包括公钥加密算法、数字签名算法、密钥交换协议。

    4.2 数字签名技术

            数字签名是一种以电子形式存储的消息签名。数字签名算法由一个签名者对数据产生数字签名,并由一个验证者验证签名的可靠性。每个签名者有一个公钥和一个私钥,其中私钥用于产生数字签名,验证者用签名者的公钥验证签名。一个数字签名方案应具备如下基本特点:

    (1)不可伪造性。在不知道签名者私钥的情况下,任何其他人都不能伪造签名。

    (2)不可否认性。签名者无法否认自己对消息的签名。

    (3)保证消息的完整性。任何对消息的更改都将导致签名无法通过验证。

    公钥密码可提供功能强大的数字签名方案,而无须接收者秘密保存验证密钥。

           目前诸多数字签名方案主要基于公钥密码。除了 RSA 数字签名方案外,目前还有很多不同功能、不同类型的数字签名方案。 ISO 数字签名标准 ECDSA 和中国的商用密码标准SM2椭圆曲线数字签名就是两个重要的数字签名标准。 ECDSA 数字签名是使用椭圆曲线对数字签名算法 DSA 的模拟。 ECDSA 于1998年成为 ISO 标准,于1999年成为 ANS 标准,于2000年成为 IEEE 和 FIPS 标准。 ECDSA 是 EIGamal 公钥密码的一种变形,其安全性依赖于椭圆曲线群上计算离散对数困难问题。SM2数字签名与 ECDSA 数字签名一样,其安全性也依赖于椭圆曲线群上计算离散对数困难问

    题。

    4.3 Hash 和 MAC 技术

           Hash 函数(也称杂凑函数或哈希函数◇可将任意长的消息压缩为固定长度的 Hash 值。 Hash 函数需具有如下性质:

    (1)单向性。对一个给定的 Hash 函数值,构造一个输入消息将其映射为该函数值是计算上不可行的。

    (2)抗碰撞性。构造两个不同的消息将它们映射为同一个 Hash 函数值是计算上不可行的。

     Hash 函数可用于构造分组密码、序列密码和消息认证码,也是数字签名的重要组件,可破坏输入的代数结构,进行消息源认证;也可用于构造伪随机数生成器,进行密钥派生等。典型的 Hash 函数有 SHA —256算法,SM3算法和 SHA —3算法。
    与 Hash 数技术相关的是消息认证码( Message Authentication Code , MAC )技术。 MAC 算法也是基于一个大尺寸数据生成一个小尺寸数据,在性能上也需要避免碰撞,但 MAC 算法有密钥参与,计算结果类似于一个加密的 Hash 函数值,攻击者难以在篡改内容后伪造它。因此, MAC 值可单独使用,而 Hash 数值一般配合数字签名使用。 MAC 算法主要基于分组密码或普通 Hash 算法改造, HMAC 是最常用的 MAC 算法,它通过 Hash 函数来实现消息认证。 HMAC 可以和任何迭代 Hash 函数(如MD5、 SHA —1)结合使用而无须更改这些 Hash 函数。

    五、隐私保密技术基础知识

           大数据时代,人类活动前所未有地被数据化。移动通信、数字医疗、社交网络、在线视频、位置服务等应用积累并持续不断地产生大量数据。以共享单车为例,截至2017年5月底,国内共享单车累计服务已超过10亿人次,注册用户超过1亿个。面向这些大规模、高速产生、蕴含高价值的大数据的分析挖掘不但为本行业的持续增长做出了贡献,也为跨行业应用提供了强有力的支持。共享单车的骑行路线在交通预测、路线推荐、城市规划方面具有重要意义。

           而随着数据披露范围的不断扩大,隐藏在数据背后的主体也面临愈来愈严重的隐私挖掘威胁,例如根据骑行路线推理个人用户的家庭住址、单位地址、出行规律,或者匿名用户被重新识别出来,进而导致“定制化”攻击,等等,为用户为满足用户保护个人隐私的需求及相关法律法规的要求,大数据隐私保护技术需确保公开发布的数据不泄露任何用户敏感信息。同时,隐私保护技术还应考虑到发布数据的可用性。因为片面强调数据匿名性,将导致数据过度失真,无法实现数据发布的初衷。因此,数据隐私保护技术的目标在于实现数据可用性和隐私性之间的良好平衡。

    5.1 数据隐私保护场景

    一般来说,一个隐私保护数据发布方案的构建涉及以下4个参与方:

    (1)个人用户:收集数据的对象。

    (2)数据采集/发布者:数据采集者与用户签订数据收集、使用协议,获得用户的相关数据。数据采集者通常也负责数据发布(用户本地隐私保护情景除外)。根据数据发布的目的和限制条件,数据发布者对数据进行一定的处理并以在线交互或离线非交互方式提供给数据使用者,在进行数据处理时还须预防潜在的恶意攻击。

    (3)数据使用者:任意可获取该公开数据的机构和个人。数据使用者希望获得满足其使用目的尽可能真实有效的数据。

    (4)攻击者:可获取该公开数据的恶意使用者。攻击者可能具有额外的信息或者知识等,试图利用该公开识别特定用户身份,获取关于某特定用户的敏感信息,进而从中牟取利益。

    5.2 隐私保密需求

    用户隐私保需密求可分为身份隐私、属性隐私、社交关系隐私、位置与轨迹隐私等几大类。

    (1)身份隐私。它是指数据记录中的用户 ID 或社交网络中的虚拟节点对应的真实用户身份信息。通常情况下,政府公开部门或服务提供商对外提供匿名处理后的信息。但是一旦分析者将虚拟用户 ID 或节点和真实的用户身份相关联,即造成用户身份信息泄露(也称为“去匿名化”)。用户身份隐私保护的目标是降低攻击者从数据集中识别出某特定用户的可能性。

    (2)属性隐私。属性数据用来描述个人用户的属性特征,例如结构化数据表中年龄、性别等描述用户的人口统计学特征的字段。宽泛地说,用户购物历史、社交网络上用户主动提供的喜欢的书、音乐等个性化信息都可以作为用户的属性信息。这些属性信息具有丰富的信息量和较高的个性化程度,能够帮助系统建立完整的用户轮廓,提高推荐系统的准确性等。然而,用户往往不希望所有属性信息都对外公开,尤其是敏感程度较高的属性信息。例如,某些视频观看记录被公开会对用户的形象造成不良影响。但是,简单地删除敏感属性是不够的,因为分析者有可能通过对用户其他信息(如社交关系、非敏感属性、活动规律等)进行分析、推测将其还原出来。属性隐私保护的目标是对用户相关属性信息进行有针对性的处理,防止用户敏感属性特征泄露。

    (3)社交关系隐私。用户和用户之间形成的社交关系也是隐私的一种。通常在社交网络图谱中,用户社交关系用边表示。服务提供商基于社交结构可分析出用户的交友倾向并对其进行朋友推荐,以保持社交群体的活跃和黏性。但与此同时,分析者也可以挖掘出用户不不愿公开的社交关系、交友群体特征等,导致用户的社交关系隐私甚至属性隐私暴露。社交关系隐私保护要求节点对应的社交关系保持匿名,攻击者无法确认特定用户拥有哪些社交关系。

     (4)位置轨迹隐私。用户位置轨迹数据来源广泛,包括来自城市交通系统、 GPS 导航、行程规划系统、无线接入点以及各类基于位置服务的 APP 数据等。用户的实时位置泄露可能会给其带来极大危害,例如被锁定并实施定位攻击。而用户的历史位置轨迹分析也可能暴露用户隐私属性、私密关系、出行规律甚至用户真实身份,为用户带来意想不到的损失。用户位置轨迹隐私保护要求对用户的真实位置进行隐藏或处理,不泄露用户的敏感位置和行动规律给恶意攻击者,从而保护用户安全。

            从数据类型角度看,用户隐私数据可表示为结构化数据或非结构化数据。通常,用户的属性信息(如年龄、性别、购物记录等)属于典型的结构化数据,可表示为数据库表;用户位置、轨迹数据一般以点集的形式表示,也属于结构化数据。而用户社交关系数据则表现为相对复杂的网络关系,属于非结构化数据,一般用图结构表示。



       

    展开全文
  • 互联网企业数据安全体系建设

    千次阅读 2020-06-25 09:05:34
    Facebook数据泄露事件一度成为互联网行业的焦点,几百亿美元市值瞬间蒸发,这个代价足以在地球上养活一支绝对庞大的安全团队,甚至可以直接收购几家规模比较大的安全公司了。 虽然媒体上发表了很多谴责的言论,但...

    一、背景

    Facebook数据泄露事件一度成为互联网行业的焦点,几百亿美元市值瞬间蒸发,这个代价足以在地球上养活一支绝对庞大的安全团队,甚至可以直接收购几家规模比较大的安全公司了。

    虽然媒体上发表了很多谴责的言论,但实事求是地讲,Facebook面临是一个业界难题,任何一家千亿美元的互联网公司面对这种问题,可能都没有太大的抵抗力,仅仅是因为全球区域的法律和国情不同,暂时不被顶上舆论的浪尖罢了。但是全球的趋势是越来越重视隐私,在安全领域中,数据安全这个子领域也重新被提到了一个新的高度,所以笔者就借机来说一下数据安全建设。(按照惯例,本文涉及敏感信息的部分会进行省略处理或者一笔带过。)

    二、概念

    这里特别强调一下,“隐私保护”和“数据安全”是两个完全不同的概念,隐私保护对于安全专业人员来说是一个更加偏向合规的事情,主要是指数据过度收集和数据滥用方面对法律法规的遵从性,对很多把自身的盈利模式建立在数据之上的互联网公司而言,这个问题特别有挑战。有些公司甚至把自己定义为数据公司,如果不用数据来做点什么,要么用户体验大打折扣,要么商业价值减半。GDPR即将实施,有些公司或将离场欧洲,就足见这件事的难度不容小觑。当然市场上也有一些特别推崇隐私保护的公司,他们很大程度上并不能真正代表用户意愿,而只是因为自家没有数据或缺少数据,随口说说而已。

    数据安全是实现隐私保护的最重要手段之一。对安全有一定了解的读者可能也会察觉到,数据安全并不是一个独立的要素,而是需要连同网络安全、系统安全、业务安全等多种因素,只有全部都做好了,才能最终达到数据安全的效果。所以本文尽可能的以数据安全为核心,但没有把跟数据安全弱相关的传统安全体系防护全部列出来,对于数据安全这个命题而言尽可能的系统化,又避免啰嗦。另外笔者也打算在夏季和秋季把其他子领域的话题单独成文,譬如海量IDC下的入侵防御体系等,敬请期待。

    三、全生命周期建设

    尽管业内也有同学表示数据是没有边界的,如果按照泄露途径去做可能起不到“根治”的效果,但事实上以目前的技术是做不到无边界数据安全的。下图汇总了一个全生命周期内的数据安全措施:

    四、数据采集

    数据泄露有一部分原因是用户会话流量被复制,尽管有点技术门槛,但也是发生频率比较高的安全事件之一,只是是很多企业没有感知到而已。下面从几个维度来说明数据采集阶段的数据保护。

    流量保护

    全站HTTPS是目前互联网的主流趋势,它解决的是用户到服务器之间链路被嗅探、流量镜像、数据被第三方掠走的问题。这些问题其实是比较严重的,比如电信运营商内部偶有舞弊现象,各种导流劫持插广告(当然也可以存数据,插木马),甚至连AWS也被劫持DNS请求,对于掌握链路资源的人来说无异于可以发动一次“核战争”。即使目标对象IDC入侵防御做的好,攻击者也可以不通过正面渗透,而是直接复制流量,甚至定向APT,最终只是看操纵流量后达到目的的收益是否具有性价比。

    HTTPS是一个表面现象,它暗示着任何互联网上未加密的流量都是没有隐私和数据安全的,同时,也不是说有了HTTPS就一定安全。HTTPS本身也有各种安全问题,比如使用不安全的协议TLS1.0、SSL3,采用已经过时的弱加密算法套件,实现框架安全漏洞如心脏滴血,还有很多的数字证书本身导致的安全问题。

    全站HTTPS会带来的附带问题是CDN和高防IP。历史上有家很大的互联网公司被NSA嗅探获取了用户数据,原因是CDN回源时没有使用加密,即用户浏览器到CDN是加密的,但CDN到IDC源站是明文的。如果CDN到源站加密就需要把网站的证书私钥给到CDN厂商,这对于没有完全自建CDN的公司而言也是一个很大的安全隐患,所以后来衍生出了Keyless CDN技术,无需给出自己的证书就可以实现CDN回源加密。

    广域网流量未加密的问题也要避免出现在“自家后院”——IDC间的流量复制和备份同步,对应的解决方案是跨IDC流量自动加密、TLS隧道化。

    业务安全属性

    在用户到服务器之间还涉及两个业务安全方向的问题。第一个问题是账号安全,只要账号泄露(撞库&爆破)到达一定数量级,把这些账号的数据汇总一下,就必定可以产生批量数据泄露的效果。

    第二个问题是反爬,爬虫的问题存在于一切可通过页面、接口获取数据的场合,大概1小时爬个几百万条数据是一点问题都没有的,对于没有彻底脱敏的数据,爬虫的效果有时候等价于“黑掉”服务器。账号主动地或被动地泄露+爬虫技术,培育了不少黑产和数据获取的灰色地带。

    UUID

    UUID最大的作用是建立中间映射层,屏蔽与真实用户信息的关系链。譬如在开放平台第三方应用数据按需自主授权只能读取UUID,但不能直接获取个人的微信号。更潜在的意义是屏蔽个体识别数据,因为实名制,手机号越来越能代表个人标识,且一般绑定了各种账号,更改成本很高,找到手机号就能对上这个人,因此理论上但凡带有个体识别数据的信息都需要“转接桥梁”、匿名化和脱敏。譬如当商家ID能唯一标识一个品牌和店名的时候,这个原本用于程序检索的数据结构也一下子变成了个体识别数据,也都需要纳入保护范畴。

    五、前台业务处理

    鉴权模型

    在很多企业的应用架构中,只有在业务逻辑最开始处理的部分设置登录态校验,后面的事务处理不再会出现用户鉴权,进而引发了一系列的越权漏洞。事实上越权漏洞并不是这种模型的全部危害,还包括各种K/V、RDS(关系型数据库)、消息队列等等,RPC没有鉴权导致可任意读取的安全问题。

    在数据层只知道请求来自一个数据访问层中间件,来自一个RPC调用,但完全不知道来自哪个用户,还是哪个诸如客服系统或其他上游应用,无法判断究竟对当前的数据(对象)是否拥有完整的访问权限。绝大多数互联网公司都用开源软件或修改后的开源软件,这类开源软件的特点是基本不带安全特性,或者只具备很弱的安全特性,以至于完全不适用于海量IDC规模下的4A模型(认证、授权、管理、审计)。外面防御做的很好,而在内网可以随意读写,这可能是互联网行业的普遍现状了。主要矛盾还是鉴权颗粒度和弹性计算的问题,关于这个问题的解决方案可以参考笔者的另外一篇文章《初探下一代网络隔离与访问控制》,其中提到Google的方法是内网RPC鉴权,由于Google的内网只有RPC一种协议,所以就规避了上述大多数安全问题。

    对于业务流的鉴权模型,本质上是需要做到Data和App分离,建立Data默认不信任App的模型,而应用中的全程Ticket和逐级鉴权是这种思想下的具体实现方法。

    服务化

    服务化并不能认为是一个安全机制,但安全却是服务化的受益者。我们再来温习一下当年Bezos在Amazon推行服务化的一纸号令:

    1)所有团队今后将通过服务接口公开他们的数据和功能。 2)团队必须通过这些接口相互通信。 3)不允许使用其他形式的进程间通信:不允许直接链接,不允许直接读取其他团队的数据存储,不支持共享内存模式,无后门。唯一允许的通信是通过网络上的服务接口调用。 4)他们使用什么技术并不重要。HTTP,Corba,Pubsub,自定义协议 - 无关紧要。贝索斯不在乎。 5)所有服务接口无一例外都必须从头开始设计为可外部化。也就是说,团队必须规划和设计能够将接口展示给外部开发人员。没有例外。 6)任何不这样做的人都会被解雇。

    服务化的结果在安全上的意义是必须通过接口访问数据,屏蔽了各种直接访问数据的途径,有了API控制和审计就会方便很多。

    内网加密

    一些业界Top的公司甚至在IDC内网里也做到了加密,也就是在后台的组件之间的数据传输都是加密的,譬如Goolge的RPC加密和Amazon的TLS。由于IDC内网的流量比公网大得多,所以这里是比较考验工程能力的地方。对于大多数主营业务迭代仍然感觉有压力的公司而言,这个需求可能有点苛刻了,所以笔者认为用这些指标来衡量一家公司的安全能力属于哪一个档位是合理的。私有协议算不算?如果私有协议里不含有标准TLS(SHA256)以上强度的加密,或者只是信息不对称的哈希,笔者认为都不算。

    数据库审计

    数据库审计/数据库防火墙是一个入侵检测/防御组件,是一个强对抗领域的产品,但是在数据安全方面它的意义也是明显的:防止SQL注入批量拉取数据,检测API鉴权类漏洞和爬虫的成功访问。

    除此之外,对数据库的审计还有一层含义,是指内部人员对数据库的操作,要避免某个RD或DBA为了泄愤,把数据库拖走或者删除这种危险动作。通常大型互联网公司都会有数据库访问层组件,通过这个组件,可以审计、控制危险操作。

    六、数据存储

    数据存储之于数据安全最大的部分是数据加密。Amazon CTO Werner Vogels曾经总结:“AWS所有的新服务,在原型设计阶段就会考虑到对数据加密的支持。”国外的互联网公司中普遍比较重视数据加密。

    HSM/KMS

    业界的普遍问题是不加密,或者加密了但没有使用正确的方法:使用自定义UDF,算法选用不正确或加密强度不合适,或随机数问题,或者密钥没有Rotation机制,密钥没有存储在KMS中。数据加密的正确方法本身就是可信计算的思路,信任根存储在HSM中,加密采用分层密钥结构,以方便动态转换和过期失效。当Intel CPU普遍开始支持SGX安全特性时,密钥、指纹、凭证等数据的处理也将以更加平民化的方式使用类似Trustzone的芯片级隔离技术。

    结构化数据

    这里主要是指结构化数据静态加密,以对称加密算法对诸如手机、身份证、银行卡等需要保密的字段加密持久化,另外除了数据库外,数仓里的加密也是类似的。比如,在 Amazon Redshift 服务中,每一个数据块都通过一个随机的密钥进行加密,而这些随机密钥则由一个主密钥进行加密存储。用户可以自定义这个主密钥,这样也就保证了只有用户本人才能访问这些机密数据或敏感信息。鉴于这部分属于比较常用的技术,不再展开。

    文件加密

    对单个文件独立加密,一般情况下采用分块加密,典型的场景譬如在《互联网企业安全高级指南》一书中提到的iCloud将手机备份分块加密后存储于AWS的S3,每一个文件切块用随机密钥加密后放在文件的meta data中,meta data再用file key包裹,file key再用特定类型的data key(涉及数据类型和访问权限)加密,然后data key被master key包裹。

    文件系统加密

    文件系统加密由于对应用来说是透明的,所以只要应用具备访问权限,那么文件系统加密对用户来说也是“无感知”的。它解决的主要是冷数据持久化后存储介质可访问的问题,即使去机房拔一块硬盘,或者从一块报废的硬盘上尝试恢复数据,都是没有用的。但是对于API鉴权漏洞或者SQL注入而言,显然文件系统的加密是透明的,只要App有权限,漏洞利用也有权限。

    七、访问和运维

    在这个环节,主要阐述防止内部人员越权的一些措施。

    角色分离

    研发和运维要分离,密钥持有者和数据运维者要分离,运维角色和审计角色要分离。特权账号须回收,满足最小权限,多权分立的审计原则。

    运维审计

    堡垒机(跳板机)是一种针对人肉运维的常规审计手段,随着大型IDC中运维自动化的加深,运维操作都被API化,所以针对这些API的调用也需要被列入审计范畴,数量级比较大的情况下需要使用数据挖掘的方法。

    工具链脱敏

    典型的工具脱敏包括监控系统和Debug工具/日志。在监控系统类目中,通常由于运维和安全的监控系统包含了全站用户流量,对用户Token和敏感数据需要脱敏,同时这些系统也可能通过简单的计算得出一些运营数据,譬如模糊的交易数目,这些都是需要脱敏的地方。在Debug方面也出过Debug Log带有CVV码等比较严重的安全事件,因此都是需要注意的数据泄漏点。

    生产转测试

    生产环境和测试环境必须有严格定义和分离,如特殊情况生产数据需要转测试,必须经过脱敏、匿名化。

    八、后台数据处理

    数仓安全

    目前大数据处理基本是每个互联网公司的必需品,通常承载了公司所有的用户数据,甚至有的公司用于数据处理的算力超过用于前台事务处理的算力。以Hadoop为代表的开源平台本身不太具备很强的安全能力,因此在成为公有云服务前需要做很多改造。在公司比较小的时候可以选择内部信任模式,不去过于纠结开源平台本身的安全,但在公司规模比较大,数据RD和BI分析师成千上万的时候,内部信任模式就需要被抛弃了,这时候需要的是一站式的授权&审计平台,需要看到数据的血缘继承关系,需要高敏数据仍然被加密。在这种规模下,工具链的成熟度会决定数据本地化的需求,工具链越成熟数据就越不需要落到开发者本地,这样就能大幅提升安全能力。同时鼓励一切计算机器化&程序化&自动化,尽可能避免人工操作。

    对于数据的分类标识、分布和加工,以及访问状况需要有一个全局的大盘视图,结合数据使用者的行为建立“态势感知”的能力。

    因为数仓是最大的数据集散地,因此每家公司对于数据归属的价值观也会影响数据安全方案的落地形态:放逐+检测型 or 隔离+管控型。

    匿名化算法

    匿名化算法更大的意义其实在于隐私保护而不在于数据安全(关于隐私保护部分笔者打算另外单独写一篇),如果说对数据安全有意义,匿名化可能在于减少数据被滥用的可能性,以及减弱数据泄漏后的影响面。

    九、展示和使用

    这个环节泛指大量的应用系统后台、运营报表以及所有可以展示和看到数据的地方,都可能是数据泄露的重灾区。

    展示脱敏

    对页面上需要展示的敏感信息进行脱敏。一种是完全脱敏,部分字段打码后不再展示完整的信息和字段,另一种是不完全脱敏,默认展示脱敏后的信息,但仍然保留查看明细的按钮(API),这样所有的查看明细都会有一条Log,对应审计需求。具体用哪种脱敏需要考虑工作场景和效率综合评估。

    水印

    水印主要用在截图的场景,分为明水印和暗水印,明水印是肉眼可见的,暗水印是肉眼不可见暗藏在图片里的识别信息。水印的形式也有很多种,有抵抗截屏的,也有抵抗拍照的。这里面也涉及很多对抗元素不一一展开。

    安全边界

    这里的边界其实是办公网和生产网组成的公司数据边界,由于办公移动化程度的加深,这种边界被进一步模糊化,所以这种边界实际上是逻辑的,而非物理上的,它等价于公司办公网络,生产网络和支持MDM的认证移动设备。对这个边界内的数据,使用DLP来做检测,DLP这个名词很早就有,但实际上它的产品形态和技术已经发生了变化,用于应对大规模环境下重检测,轻阻断的数据保护模式。

    除了DLP之外,整个办公网络会采用BeyondCorp的“零信任”架构,对整个的OA类应用实现动态访问控制,全面去除匿名化访问,全部HTTPS,根据角色最小权限化,也就是每个账号即使泄露能访问到的也有限。同时提高账号泄露的成本(多因素认证)和检测手段,一旦检测到泄露提供远程擦除的能力。

    堡垒机

    堡垒机作为一种备选的方式主要用来解决局部场景下避免操作和开发人员将敏感数据下载到本地的方法,这种方法跟VDI类似,比较厚重,使用门槛不高,不适合大面积普遍推广。

    十、共享和再分发

    对于业务盘子比较大的公司而言,其数据都不会是只在自己的系统内流转,通常都有开放平台,有贯穿整个产业链的上下游数据应用。Facebook事件曝光其实就属于这类问题,不开放是不可能的,因为这影响了公司的内核—-赖以生存的商业价值。

    所以这个问题的解决方案等价于:1)内核有限妥协(为保障用户隐私牺牲一部分商业利益);2)一站式数据安全服务。

    防止下游数据沉淀

    首先,所有被第三方调用的数据,如非必要一律脱敏和加密。如果部分场景有必要查询明细数据,设置单独的API,并对账号行为及API查询做风控。

    其次如果自身有云基础设施,公有云平台,可以推动第三方上云,从而进行(1)安全赋能,避免一些因自身能力不足引起的安全问题;(2)数据集中化,在云上集中之后利于实施一站式整体安全解决方案(数据加密,风控,反爬和数据泄露检测类服务),大幅度降低外部风险并在一定程度上降低作恶和监守自盗的问题。

    反爬

    反爬在这里主要是针对公开页面,或通过接口爬取的信息,因为脱敏这件事不可能在所有的环节做的很彻底,所以即便通过大量的“公开”信息也可以进行汇聚和数据挖掘,最终形成一些诸如用户关系链,经营数据或辅助决策类数据,造成过度信息披露的影响。

    授权审核

    设置专门的团队对开放平台的第三方进行机器审核及人工审核,禁止“无照经营”和虚假三方,提高恶意第三方接入的门槛,同时给开发者/合作方公司信誉评级提供基础。

    法律条款

    所有的第三方接入必须有严格的用户协议,明确数据使用权利,数据披露限制和隐私保护的要求。像GDPR一样,明确数据处理者角色和惩罚条约。

    十一、数据销毁

    数据销毁主要是指安全删除,这里特别强调是,往往数据的主实例容易在视野范围内,而把备份类的数据忽略掉。 如果希望做到快速的安全删除,最好使用加密数据的方法,因为完整覆写不太可能在短时间内完成,但是加密数据的安全删除只要删除密钥即可。

    十二、数据的边界

    数据治理常常涉及到“边界”问题,不管你承不承认,边界其实总是存在的,只不过表达方式不一样,如果真的没有边界,也就不存在数据安全一说。

    企业内部

    在不超越网络安全法和隐私保护规定的情况下,法律上企业对内部的数据都拥有绝对控制权,这使得企业内部的数据安全建设实际上最后会转化为一项运营类的工作,挑战难度也无非是各个业务方推动落地的成本。但对规模比较大的公司而言,光企业内部自治可能是不够的,所以数据安全会衍生出产业链上闭环的需求。

    生态建设

    为了能让数据安全建设在企业内部价值链之外的部分更加平坦化,大型企业可能需要通过投资收购等手段获得上下游企业的数据控制权及标准制定权,从而在大生态里将自己的数据安全标准推行到底。如果不能掌控数据,数据安全也无从谈起。在话语权不足的情况下,现实选择是提供更多的工具给合作方,也是一种数据控制能力的延伸。

    十三、ROI和建设次第

    对于很多规模不大的公司而言,上述数据安全建设手段可能真的有点多,对于小一点公司即便什么事不干可能也消化不了那么多需求,因为开源软件和大多数的开发框架都不具备这些能力,需要DIY的成分很高,所以我们梳理一下前置条件,优先级和ROI,让数据安全这件事对任何人都是可以接受的,当然这种情况其实也对应了一些创业空间。

    基础

    账号、权限、日志、脱敏和加密这些都是数据安全的基础。同时还有一些不完全是基础,但能体现为优势的部分:基础架构统一,应用架构统一,如果这两者高度统一,数据安全建设能事半功倍。

    日志收集

    日志是做数据风控的基础,但这里面也有两个比较重要的因素:

    1. 办公网络是否BeyondCorp化,这给数据风控提供了极大地便利。
    2. 服务化,所有的数据调用皆以API的形式,给日志记录提供了统一的形式。

    数据风控

    在数据安全中,“放之四海皆准”的工作就是数据风控,适用于各类企业,结合设备信息、账号行为、查询/爬(读)取行为做风控模型。对于面向2C用户类,2B第三方合作类,OA员工账号类都是适用的。具体的策略思想笔者打算在后续文章《入侵防御体系建设》中详细描述。

    作者简介

    赵彦,现任美团集团安全部高级总监,负责集团旗下全线业务的信息安全与隐私保护。加盟美团前,曾任华为云安全首席架构师,奇虎360企业安全技术总监、久游网安全总监、绿盟科技安全专家等职务。白帽子时代是Ph4nt0m Security Team的核心成员,互联网安全领域第一代资深从业者。

    关于美团安全

    美团安全部的大多数核心人员,拥有多年互联网以及安全领域实践经验,很多同学参与过大型互联网公司的安全体系建设,其中也不乏全球化安全运营人才,具备百万级IDC规模攻防对抗的经验。安全部也不乏CVE“挖掘圣手”,有受邀在Black Hat等国际顶级会议发言的讲者,当然还有很多漂亮的运营妹子。

    目前,美团安全部涉及的技术包括渗透测试、Web防护、二进制安全、内核安全、分布式开发、大数据分析、安全算法等等,同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级IDC规模、数十万终端接入的移动办公网络自适应安全体系,这套体系构建于零信任架构之上,横跨多种云基础设施,包括网络层、虚拟化/容器层、Server 软件层(内核态/用户态)、语言虚拟机层(JVM/JS V8)、Web应用层、数据访问层等,并能够基于“大数据+机器学习”技术构建全自动的安全事件感知系统,努力打造成业界最前沿的内置式安全架构和纵深防御体系。

    随着美团的高速发展,业务复杂度不断提升,安全部门面临更多的机遇和挑战。我们希望将更多代表业界最佳实践的安全项目落地,同时为更多的安全从业者提供一个广阔的发展平台,并提供更多在安全新兴领域不断探索的机会。

    招聘信息

    美团安全部正在招募Web&二进制攻防、后台&系统开发、机器学习&算法等各路小伙伴。如果你想加入我们,欢迎简历请发至邮箱zhaoyan17@meituan.com

    具体职位信息可参考这里:https://mp.weixin.qq.com/s/ynEq5LqQ2uBcEaHCu7Tsiw

    美团安全应急响应中心MTSRC主页:security.meituan.com

    展开全文
  • 系统安全性和保密性设计

    千次阅读 2019-06-19 14:24:59
    国家商用密码定义了一系列算法,我了解到的是SM2、SM3、SM4,因为国家对一些系统有安全要求,必须通过支持这三种算法,颁布相应授权证书。国密算法(国家商用密码算法简介)。 SM2是替代RSA的算法,算法流程参考图解...

    这个话题很大,我只是把我经历的或者说知道的,写一写,总总结,我并不是这方面的高手。
    1 安全基础
    1.1 国密算法
    国家商用密码定义了一系列算法,我了解到的是SM2、SM3、SM4,因为国家对一些系统有安全要求,必须通过支持这三种算法,颁布相应授权证书。国密算法(国家商用密码算法简介)
    SM2是替代RSA的算法,算法流程参考图解SM2算法流程(合
    几个算法对比可以参见 国密算法SM1/SM2/SM3/SM4,我并不关心算法的实现,因为我只需要购买加密机就可以了,只要加密机支持这些算法,对接加密机就可以了。
    从下图很容易想到几个问题
    1、根密钥如何保证安全
    应用系统使用的密钥是分散出来的,那么根密钥很容易想到也应该做分散。然后就是根密钥的灌装了。
    2、这个前置与加密机之前的通讯安全如何保障?
    应用系统不直连加密机,那么就需要设计一个前置系统。那么前置系统与机密机之间的安全设计呢?从下图可以看到加密机管理控制台有哪些功能,
    这里面可以想象到加密机的前置系统,与加密机之间的接口通讯,采用了对称了加密,他们在内网,通过设置ip白名单进行授信。
    2
    3、应用系统通过前置与加密机通信?
    前置和加密机也大都会采用对成加密,但是接口报文的加、解密是在交给加密机来处理,所以报文是安全的,而被截获的报文,即使知道了应用与加密机的加密密钥,那么也是密文,还是不知道如何解密。
    1
    1.2 MD5、SHA摘要算法
    摘要算法很厉害,因为他不可逆,计算一个文件是否更改,只要看看他的摘要是否发生变化就可以。我的应用场景主要是在登录的时候使用。第2.3.3章 WEB系统最佳实践属性配置之shiro.properties第2.1.7章 WEB系统最佳实践Spring文件配置之spring-shiro.xml这两篇文章提到我的计算使用的是SHA-1,应用的shiro权限框架,这里稍微带一带。下图的密码流程,很容易就想到几个问题
    1、客户端做MD5值,再调用后台请求之前,MD5做几次呢?
    客户端一定是计算摘要的,是不是选择MD5算法抛开一边。但是一次MD5是可以破解的,比如在线MD5破解,密码通常6位~20位,MD5值是32位,因此再做一次MD5值,就相当难破解了,所以客户端只需要做2次MD5就可以了。
    2、SHA-1安全吗
    2017年2月23日,CWI Amsterdam与Google宣布了一个成功的SHA-1碰撞攻击,我相信有人攻击我的代价和他的收益没那么大,所以可以放心使用了。但是shiro也可以支持sha2.
    3、加盐值是怎么产生的?
    给出8位的长度,随机生成16个字节的加盐值,不容易猜吧。

    byte[] salt = DigestsUtil.generateSalt(saltSize);
    record.setSalt(EncodesUtil.encodeHex(salt));
    

    4、多少次迭代合适呢?
    网上大多数采用的是1024,虽然我不知道为什么,应该够用了。
    5、保存到数据库中的密码安全吗?
    最终存放到数据的密码长度为40位,在数据库中是无法猜到用户的账号密码的,内贼是可以防住了。可是运维的权限呢,如果运维更改了账号和密码,临时登录进去,再改回来。这就需要数据库的审计功能了。
    2
    1.3 数字签名
    数字签名是保障信息的不可抵赖性。现在的开放接口大多提供一个appId和appKey给到接入方,可以看看蚂蚁金赋开放平台的做法,照着做就是了。实际应用,大多会砍一砍。
    从下面可以思考几个问题,既然是数字签名,那么其实算法是公开的,那么问题就在于如何让appKey保密。
    1、appKey存放到哪里呢
    很多时候appKey写到了后台配置文件中,如果人员离职,这个appKey就带走了,不过还好大多数开放平台,appKey都可以更新,appId是不变的。
    2、前端后端分离的appKey暴露了怎么办?
    比如使用springboot+vue做前后端分离或者js访问开放平台的,有些人把appKey写到了前端,直接暴露有人觉得很危险,于是想到了,将appKey做分散,或者js做了混淆,只是增加了难度,而那些做爬虫的人,才不关心你怎么封装的,直接抓包看请求,这就需要用到了数字证书了。
    1
    从下图可以看到密码传输到终端用户,为什么很多企业用户花钱需要手机短信把,因为解决了密码传输的问题。
    1
    appId作为参数传到后台

    private <T extends AlipayResponse> RequestParametersHolder getRequestHolderWithSign(BatchAlipayRequest request) throws AlipayApiException {
    
           List<AlipayRequestWrapper> requestList = request.getRequestList();
           //校验接口列表非空
           if (requestList == null || requestList.isEmpty()) {
               throw new AlipayApiException("40", "client-error:api request list is empty");
           }
    
           RequestParametersHolder requestHolder = new RequestParametersHolder();
    
           //添加协议必须参数
           AlipayHashMap protocalMustParams = new AlipayHashMap();
           protocalMustParams.put(AlipayConstants.METHOD, request.getApiMethodName());
           protocalMustParams.put(AlipayConstants.APP_ID, this.appId);
           protocalMustParams.put(AlipayConstants.SIGN_TYPE, this.signType);
           protocalMustParams.put(AlipayConstants.CHARSET, charset);
           protocalMustParams.put(AlipayConstants.VERSION, request.getApiVersion());
    
           if (request.isNeedEncrypt()) {
               protocalMustParams.put(AlipayConstants.ENCRYPT_TYPE, this.encryptType);
           }
    
           //添加协议可选参数
           AlipayHashMap protocalOptParams = new AlipayHashMap();
           protocalOptParams.put(AlipayConstants.FORMAT, format);
           protocalOptParams.put(AlipayConstants.ALIPAY_SDK, AlipayConstants.SDK_VERSION);
           requestHolder.setProtocalOptParams(protocalOptParams);
    
           Long timestamp = System.currentTimeMillis();
           DateFormat df = new SimpleDateFormat(AlipayConstants.DATE_TIME_FORMAT);
           df.setTimeZone(TimeZone.getTimeZone(AlipayConstants.DATE_TIMEZONE));
           protocalMustParams.put(AlipayConstants.TIMESTAMP, df.format(new Date(timestamp)));
           requestHolder.setProtocalMustParams(protocalMustParams);
    
           //设置业务参数
           AlipayHashMap appParams = new AlipayHashMap();
    
           //构造请求主题
           StringBuilder requestBody = new StringBuilder();
           // 组装每个API的请求参数
           for (int index = 0; index < requestList.size(); index++) {
               AlipayRequestWrapper alipayRequestWrapper = requestList.get(index);
               AlipayRequest alipayRequest = alipayRequestWrapper.getAlipayRequest();
               Map<String, Object> apiParams = alipayRequest.getTextParams();
               apiParams.put(AlipayConstants.METHOD, alipayRequest.getApiMethodName());
               apiParams.put(AlipayConstants.APP_AUTH_TOKEN, alipayRequestWrapper.getAppAuthToken());
               apiParams.put(AlipayConstants.ACCESS_TOKEN, alipayRequestWrapper.getAccessToken());
               apiParams.put(AlipayConstants.PROD_CODE, alipayRequest.getProdCode());
               apiParams.put(AlipayConstants.NOTIFY_URL, alipayRequest.getNotifyUrl());
               apiParams.put(AlipayConstants.RETURN_URL, alipayRequest.getReturnUrl());
               apiParams.put(AlipayConstants.TERMINAL_INFO, alipayRequest.getTerminalInfo());
               apiParams.put(AlipayConstants.TERMINAL_TYPE, alipayRequest.getTerminalType());
               apiParams.put(AlipayConstants.BATCH_REQUEST_ID, String.valueOf(index));
    
               // 仅当API包含biz_content参数且值为空时,序列化bizModel填充bizContent
               try {
                   if (alipayRequest.getClass().getMethod("getBizContent") != null
                       && StringUtils.isEmpty(appParams.get(AlipayConstants.BIZ_CONTENT_KEY))
                       && alipayRequest.getBizModel() != null) {
                       apiParams.put(AlipayConstants.BIZ_CONTENT_KEY,
                           new JSONWriter().write(alipayRequest.getBizModel(), true));
                   }
               } catch (NoSuchMethodException e) {
                   // 找不到getBizContent则什么都不做
               } catch (SecurityException e) {
                   AlipayLogger.logBizError(e);
               }
               requestBody.append(new JSONWriter().write(apiParams, false));
               if (index != requestList.size() - 1) {
                   requestBody.append(BATCH_API_DEFAULT_SPLIT);
               }
           }
           appParams.put(AlipayConstants.BIZ_CONTENT_KEY, requestBody.toString());
    
           // 只有新接口和设置密钥才能支持加密
           if (request.isNeedEncrypt()) {
    
               if (StringUtils.isEmpty(appParams.get(AlipayConstants.BIZ_CONTENT_KEY))) {
    
                   throw new AlipayApiException("当前API不支持加密请求");
               }
    
               // 需要加密必须设置密钥和加密算法
               if (StringUtils.isEmpty(this.encryptType) || getEncryptor() == null) {
    
                   throw new AlipayApiException("API请求要求加密,则必须设置密钥类型和加密器");
               }
    
               String encryptContent = getEncryptor().encrypt(
                   appParams.get(AlipayConstants.BIZ_CONTENT_KEY), this.encryptType, this.charset);
    
               appParams.put(AlipayConstants.BIZ_CONTENT_KEY, encryptContent);
           }
    
           requestHolder.setApplicationParams(appParams);
    
           if (!StringUtils.isEmpty(this.signType)) {
    
               String signContent = AlipaySignature.getSignatureContent(requestHolder);
               protocalMustParams.put(AlipayConstants.SIGN,
                   getSigner().sign(signContent, this.signType, charset));
    
           } else {
               protocalMustParams.put(AlipayConstants.SIGN, "");
           }
           return requestHolder;
       }
    

    AlipaySignature这个类可以看到参数根据字母的顺序进行排序

    public static String getSignContent(Map<String, String> sortedParams) {
           StringBuffer content = new StringBuffer();
           List<String> keys = new ArrayList<String>(sortedParams.keySet());
           Collections.sort(keys);
           int index = 0;
           for (int i = 0; i < keys.size(); i++) {
               String key = keys.get(i);
               String value = sortedParams.get(key);
               if (StringUtils.areNotEmpty(key, value)) {
                   content.append((index == 0 ? "" : "&") + key + "=" + value);
                   index++;
               }
           }
           return content.toString();
       }
    

    DefaultSigner中包含了签名的方法

    public String sign(String sourceContent, String signType, String charset) {
           String sign = null;
           try {
               sign = AlipaySignature.rsaSign(sourceContent, this.privateKey, charset, signType);
           } catch (AlipayApiException e) {
               throw new RuntimeException(e);
           }
           return sign;
       }
    

    1.4 数字证书
    私钥加密,公钥解密,这个大家都很容理解,自己写的证书,浏览器是不识别的,因为没有授权。很容易理解,你自己颁布的证书,只有你自己可以认,虽然也是对称的,但是并不是CA机构所认可。数字证书解决通讯安全的问题,也就是说抓包是被加密的。但是它并不能解决源头授信的问题。
    下图是参考一个spring-cloud项目,生成公私钥对,以及公私钥对存储的流程。
    java学习-AES加解密之AES-128-CBC算法是对称算法,这里可自行指定对称算法。按照下图的流程,公私钥的存储周期,可以通过redis的销毁机制来控制。这里可以思考几个问题
    1、私钥存到密钥的加密因子在哪里?
    这个是固定的,很多人也都会想到写到配置文件中。
    2、对离职人员的防范
    哔哩哔哩源码的泄露是来自内部员工,史上最大账号密码数据库泄露,41GB数据文件出现在暗网,这些案例可以看到,基本出问题来自内部。采用下图的方式,是可以一定程度上防范。因为公私钥对有生命周期,即使开发人员或者SE知道算法,但是生成过程并不会干预。
    2
    2 访问控制
    2.1 系统之间
    在这里插入图片描述
    2.1.1 每30秒获取允许访问的清单
    既然Eureka作为服务中心,调用者订阅服务即可,不用关心服务提供者是谁,思考一下:
    1 为何获取这个允许放单的清单从哪里来呢?
    ServiceAuthRestInterceptor这段代码可以看出这个配置实际上是从数据库中获取的,这是一个技术业务问题。

    @Override
    @Override
       public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
           HandlerMethod handlerMethod = (HandlerMethod) handler;
           // 配置该注解,说明不进行服务拦截
           CheckClientToken annotation = handlerMethod.getBeanType().getAnnotation(CheckClientToken.class);
           IgnoreClientToken ignoreClientToken = handlerMethod.getMethodAnnotation(IgnoreClientToken.class);
           if (annotation == null) {
               annotation = handlerMethod.getMethodAnnotation(CheckClientToken.class);
           }
           if (annotation == null || ignoreClientToken != null) {
               return super.preHandle(request, response, handler);
           } else {
               String token = request.getHeader(serviceAuthConfig.getTokenHeader());
               try {
                   IJWTInfo infoFromToken = serviceAuthUtil.getInfoFromToken(token);
                   String uniqueName = infoFromToken.getUniqueName();
                   for (String client : serviceAuthUtil.getAllowedClient()) {
                       if (client.equals(uniqueName)) {
                           return super.preHandle(request, response, handler);
                       }
                   }
               }catch(ClientTokenException ex){
                   response.setStatus(HttpStatus.FORBIDDEN.value());
                   logger.error(ex.getMessage(),ex);
                   response.setContentType("UTF-8");
                   response.getOutputStream().println(JSON.toJSONString(new BaseResponse(ex.getStatus(), ex.getMessage())));
                   return false;
               }
               response.setStatus(HttpStatus.FORBIDDEN.value());
               response.setStatus(HttpStatus.INTERNAL_SERVER_ERROR.value());
               response.getOutputStream().println(JSON.toJSONString(new BaseResponse(RestCodeConstants.EX_CLIENT_FORBIDDEN_CODE,"Client is Forbidden!")));
               return false;
           }
       }
    

    2 拦截器
    授权系统拦截

    @Configuration("securityWebConfig")
    @Primary
    public class WebConfiguration extends WebMvcConfigurerAdapter {
       @Bean
       GlobalExceptionHandler getGlobalExceptionHandler() {
           return new GlobalExceptionHandler();
       }
    
       @Override
       public void addInterceptors(InterceptorRegistry registry) {
           /*
               增加服务权限烂机器
            */
           registry.addInterceptor(getServiceAuthRestInterceptor()).addPathPatterns("/**");
           /*
               增加用户权限拦截器
            */
           registry.addInterceptor(getUserAuthRestInterceptor()).addPathPatterns("/**");
           super.addInterceptors(registry);
       }
    
       /**
        * 配置服务权限拦截
        * @return
        */
       @Bean
       ServiceAuthRestInterceptor getServiceAuthRestInterceptor() {
           return new ServiceAuthRestInterceptor();
       }
    
       /**
        * 配置用户用户token拦截
        * @return
        */
       @Bean
       UserAuthRestInterceptor getUserAuthRestInterceptor() {
           return new UserAuthRestInterceptor();
       }
    }
    
    
    auth:
     serviceId: ace-auth
     user:
       token-header: Authorization
       limit-expire: 1440 # 一天过期
     client:
       id: your-system
       secret: 123456
       token-header: client-token
    
    @Scheduled(cron = "0/30 * * * * ?")
       public void refreshAllowedClient() {
           log.debug("refresh allowedClient.....");
           BaseResponse resp = serviceAuthFeign.getAllowedClient(serviceAuthConfig.getClientId(), serviceAuthConfig.getClientSecret());
           if (resp.getStatus() == 200) {
               ObjectRestResponse<List<String>> allowedClient = (ObjectRestResponse<List<String>>) resp;
               this.allowedClient = allowedClient.getData();
           }
       }
    

    2.1.2 access token
    access token的产生使用到了一个第三方jar,通过私钥进行了加密,通过公钥进行解密.
    在系统初始化的时候,公私钥就产生了。
    1 token的产生

    @Configuration
    @Slf4j
    public class AuthServerRunner implements CommandLineRunner {
       @Autowired
       private RedisTemplate<String, String> redisTemplate;
       private static final String REDIS_USER_PRI_KEY = "AG:AUTH:JWT:PRI";
       private static final String REDIS_USER_PUB_KEY = "AG:AUTH:JWT:PUB";
       private static final String REDIS_SERVICE_PRI_KEY = "AG:AUTH:CLIENT:PRI";
       private static final String REDIS_SERVICE_PUB_KEY = "AG:AUTH:CLIENT:PUB";
    
       @Autowired
       private KeyConfiguration keyConfiguration;
    
       @Autowired
       private AECUtil aecUtil;
    
       @Autowired
       private RsaKeyHelper rsaKeyHelper;
    
       @Autowired
       private GatewayRouteBiz gatewayRouteBiz;
    
       @Override
       public void run(String... args) throws Exception {
           boolean flag = false;
           if (redisTemplate.hasKey(REDIS_USER_PRI_KEY)&&redisTemplate.hasKey(REDIS_USER_PUB_KEY)&&redisTemplate.hasKey(REDIS_SERVICE_PRI_KEY)&&redisTemplate.hasKey(REDIS_SERVICE_PUB_KEY)) {
               try {
                   keyConfiguration.setUserPriKey(rsaKeyHelper.toBytes(aecUtil.decrypt(redisTemplate.opsForValue().get(REDIS_USER_PRI_KEY).toString())));
                   keyConfiguration.setUserPubKey(rsaKeyHelper.toBytes(redisTemplate.opsForValue().get(REDIS_USER_PUB_KEY).toString()));
                   keyConfiguration.setServicePriKey(rsaKeyHelper.toBytes(aecUtil.decrypt(redisTemplate.opsForValue().get(REDIS_SERVICE_PRI_KEY).toString())));
                   keyConfiguration.setServicePubKey(rsaKeyHelper.toBytes(redisTemplate.opsForValue().get(REDIS_SERVICE_PUB_KEY).toString()));
               }catch (Exception e){
                   log.error("初始化公钥/密钥异常...",e);
                   flag = true;
               }
           } else {
               flag = true;
           }
           if(flag){
               Map<String, byte[]> keyMap = rsaKeyHelper.generateKey(keyConfiguration.getUserSecret());
               keyConfiguration.setUserPriKey(keyMap.get("pri"));
               keyConfiguration.setUserPubKey(keyMap.get("pub"));
               redisTemplate.opsForValue().set(REDIS_USER_PRI_KEY, aecUtil.encrypt(rsaKeyHelper.toHexString(keyMap.get("pri"))));
               redisTemplate.opsForValue().set(REDIS_USER_PUB_KEY, rsaKeyHelper.toHexString(keyMap.get("pub")));
               keyMap = rsaKeyHelper.generateKey(keyConfiguration.getServiceSecret());
               keyConfiguration.setServicePriKey(keyMap.get("pri"));
               keyConfiguration.setServicePubKey(keyMap.get("pub"));
               redisTemplate.opsForValue().set(REDIS_SERVICE_PRI_KEY, aecUtil.encrypt(rsaKeyHelper.toHexString(keyMap.get("pri"))));
               redisTemplate.opsForValue().set(REDIS_SERVICE_PUB_KEY, rsaKeyHelper.toHexString(keyMap.get("pub")));
           }
           log.info("完成公钥/密钥的初始化...");
           List<GatewayRoute> gatewayRoutes = gatewayRouteBiz.selectListAll();
           redisTemplate.opsForValue().set(RedisKeyConstants.ZUUL_ROUTE_KEY, JSON.toJSONString(gatewayRoutes));
           log.info("完成网关路由的更新...");
       }
    }
    
    public String generateToken(IJWTInfo jwtInfo) throws Exception {
           return jwtHelper.generateToken(jwtInfo, keyConfiguration.getServicePriKey(), expire);
       }
    
    <dependency>
              <groupId>io.jsonwebtoken</groupId>
                 <artifactId>jjwt</artifactId>
              <version>0.7.0</version>
          </dependency>
    
    @Scheduled(cron = "0 0/10 * * * ?")
       public void refreshClientToken() {
           log.debug("refresh client token.....");
           BaseResponse resp = serviceAuthFeign.getAccessToken(serviceAuthConfig.getClientId(), serviceAuthConfig.getClientSecret());
           if (resp.getStatus() == 200) {
               ObjectRestResponse<String> clientToken = (ObjectRestResponse<String>) resp;
               this.clientToken = clientToken.getData();
           }
       }
    
    
     public IJWTInfo getInfoFromToken(String token) throws Exception {
          try {
              IJWTInfo infoFromToken = jwtHelper.getInfoFromToken(token, serviceAuthConfig.getPubKeyByte());
              Date current = infoFromToken.getExpireTime();
              if(new Date().after(current)){
                  throw new ClientTokenException("Client token expired!");
              }
              return infoFromToken;
          } catch (ExpiredJwtException ex) {
              throw new ClientTokenException("Client token expired!");
          } catch (SignatureException ex) {
              throw new ClientTokenException("Client token signature error!");
          } catch (IllegalArgumentException ex) {
              throw new ClientTokenException("Client token is null or empty!");
          }
      }
    
    

    2 token检查
    这里可以看到拦截器,通过反编译,将带CheckClientToken 注解的请求都拦截下来了。加了注解,就需要验证token。

     @Override
      public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
          HandlerMethod handlerMethod = (HandlerMethod) handler;
          // 配置该注解,说明不进行服务拦截
          CheckClientToken annotation = handlerMethod.getBeanType().getAnnotation(CheckClientToken.class);
          IgnoreClientToken ignoreClientToken = handlerMethod.getMethodAnnotation(IgnoreClientToken.class);
          if (annotation == null) {
              annotation = handlerMethod.getMethodAnnotation(CheckClientToken.class);
          }
          if (annotation == null || ignoreClientToken != null) {
              return super.preHandle(request, response, handler);
          } else {
              String token = request.getHeader(serviceAuthConfig.getTokenHeader());
              try {
                  IJWTInfo infoFromToken = serviceAuthUtil.getInfoFromToken(token);
                  String uniqueName = infoFromToken.getUniqueName();
                  for (String client : serviceAuthUtil.getAllowedClient()) {
                      if (client.equals(uniqueName)) {
                          return super.preHandle(request, response, handler);
                      }
                  }
              }catch(ClientTokenException ex){
                  response.setStatus(HttpStatus.FORBIDDEN.value());
                  logger.error(ex.getMessage(),ex);
                  response.setContentType("UTF-8");
                  response.getOutputStream().println(JSON.toJSONString(new BaseResponse(ex.getStatus(), ex.getMessage())));
                  return false;
              }
              response.setStatus(HttpStatus.FORBIDDEN.value());
              response.setStatus(HttpStatus.INTERNAL_SERVER_ERROR.value());
              response.getOutputStream().println(JSON.toJSONString(new BaseResponse(RestCodeConstants.EX_CLIENT_FORBIDDEN_CODE,"Client is Forbidden!")));
              return false;
          }
      }
    
    @Retention(RetentionPolicy.RUNTIME)
    @Target(value={ElementType.METHOD,ElementType.TYPE})
    public @interface CheckClientToken {
    }
    

    这里配置那些需要检查客户端token

    @RestController
    @RequestMapping("depart")
    @CheckClientToken
    @CheckUserToken
    public class DepartController extends BaseController<DepartBiz,Depart> {}
    

    token拦截器得到token后,如果token过期,那么就刷新token。那么客户端token是否过期呢,则需要在客户端调用时,设置token过期标志,那么带来的问题是,为什么客户端自己不去刷新token呢?这就是上图中的access token是1个小时刷新一次,那么当在调用的时候,刚好1个小时呢,不就出问题了,所以这里做了一下主动刷新token。

    @Component
    @Log
    public class OkHttpTokenInterceptor implements Interceptor {
    	@Autowired
    	@Lazy
    	private ServiceAuthUtil serviceAuthUtil;
    	@Autowired
    	@Lazy
    	private ServiceAuthConfig serviceAuthConfig;
    	@Autowired
    	@Lazy
    	private UserAuthConfig userAuthConfig;
    
    
    	@Override
    	public Response intercept(Chain chain) throws IOException {
    		Request newRequest = chain.request()
    				.newBuilder()
    				.header(userAuthConfig.getTokenHeader(), BaseContextHandler.getToken())
    				.build();
    		Response response = chain.proceed(newRequest);
    		if(HttpStatus.FORBIDDEN.value()==response.code()){
    			if(response.body().string().contains(String.valueOf(RestCodeConstants.EX_CLIENT_INVALID_CODE))){
    				log.info("Client Token Expire,Retry to request...");
    				serviceAuthUtil.refreshClientToken();
    				newRequest = chain.request()
    						.newBuilder()
    						.header(userAuthConfig.getTokenHeader(), BaseContextHandler.getToken())
    						.header(serviceAuthConfig.getTokenHeader(),serviceAuthUtil.getClientToken())
    						.build();
    				response = chain.proceed(newRequest);
    			}
    		}
    	    return response;
    	}
    
    }
    
    

    2.1.3 获取公钥
    获取公钥由系统自动完成,避免了人为干预。

    @Scheduled(cron = "0 0/1 * * * ?")
        public void refreshUserPubKey(){
            BaseResponse resp = serviceAuthFeign.getUserPublicKey(serviceAuthConfig.getClientId(), serviceAuthConfig.getClientSecret());
            if (resp.getStatus() == HttpStatus.OK.value()) {
                ObjectRestResponse<byte[]> userResponse = (ObjectRestResponse<byte[]>) resp;
                this.userAuthConfig.setPubKeyByte(userResponse.getData());
            }
        }
        @Scheduled(cron = "0 0/1 * * * ?")
        public void refreshServicePubKey(){
            BaseResponse resp = serviceAuthFeign.getServicePublicKey(serviceAuthConfig.getClientId(), serviceAuthConfig.getClientSecret());
            if (resp.getStatus() == HttpStatus.OK.value()) {
                ObjectRestResponse<byte[]> userResponse = (ObjectRestResponse<byte[]>) resp;
                this.serviceAuthConfig.setPubKeyByte(userResponse.getData());
            }
        }
    

    3 网络安全
    3.1 VPN
    VPN是企业网在internet等公共网络上的延伸,它通过一个私有的通道在公共网络上创建一个安全的私有连接。
    五分钟搞懂内网和外网之间的通信的原理,先搞明白公网ip和私有ip,大家知道企业宽带很贵,首先因为他有固定的公网ip,很容易理解出他是独享的,因为运营商可以让多个家庭宽带使用同一个公网ip,企业宽带凭什么比民用宽带贵?有没有更便宜的企业宽带,一般企业用户都要求是双线。那么什么是双线呢?
    什么是双线宽带,这里提到了南电信北网通的问题,也就是南北网络互通的问题。
    有了固定ip,就可以解决异地机房通信的问题。先看一下深信服IPSec VPN快速配置文档,通过防火墙的配置,可以实现家庭宽带与企业网络建立虚拟专用网,说白话,就是企业网访问家庭网络,就像访问内网一样。思考几个问题
    1、家庭宽带和家庭宽带是不是没法实现vpn呢?
    没有固定ip,连对方是谁也不清楚,连通讯都建立不起来,又怎么建立转有通道呢,有防火墙也没有用。
    2、企业网络与企业网络之前一定能建立VPN吗?
    例如阿里云与企业网络建立vpn,怎么建立呢?
    3、IPSec协议的工作原理是什么?
    建立网络专用通道,那么很容易理解IPSec是网络层协议,IPSec简介VPN和IPsec协议
    在这里插入图片描述
    3.2 防火墙
    防火墙监控到内网有一台机器一直在请求DNS服务器,分析:
    1、先分析一下HTTP请求流程
    一次完整的HTTP请求过程,域名解析会先搜索浏览器自身的DNS缓存,缓存时间比较短,大概只有1分钟,且只能容纳1000条缓存。
    如果通过程序请求,而不是浏览器,会有DNS缓存吗?再看看这篇文章一文搞懂DNS缓存,浏览器和应用程序以及IPS网络运营商都会对DNS进行缓存。如果后台程序只访问一个地址,为什么会一直发送DNS呢?
    2、为什么总是在请求DNS服务器呢?
    防火墙抓包,全是在请求DNS。什么情况才会导致不断请求DNS呢?如果后台程序有循环bug,一直在请求某个网站,那么是否DNS就请求频繁呢?
    2
    通过zabbix可以监控到网络的请求情况,那么
    1、Incoming指的是什么呢?
    2、Outgoing指的是什么呢?
    3、网络流量算大吗?

    2

    展开全文
  • 工资管理系统具有对工资数据计算精确、检索迅速、查找方便、数据存储量大、保密性好、美观的报表打印效果、管理维护成本低等。这些优点能够极大地提高职工工资管理的效率,也是企业经营管理科学化、正规化的重要途径...
  • 如何有效地保证数据库系统的安全,实现数据保密性、完整性和有效性,已经成为业界人士探索研究的重要课题之一,本文就安全防入侵技术做简要的讨论。
  • 编者按:本文分析了知识管理安全性对企业的重要性,特别是高保密企业单位,介绍了天翎知识管理平台是如何实现知识管理安全性的,保证数据安全,为企业创新赋能的。 概要: 知识管理安全的重要性 知识管理...
  • 供电企业信息安全管理孙子兵法对我国信息安全保密的思考数字图书馆信息安全策略研究 1电力信息安全信息安全是指计算机网络系统中的硬件软件和其他数据等不受非法用法的破坏主要指未经授权的访问者无法使用访问数据和...
  • 企业数据治理落地和同行面试基础

    万次阅读 2021-11-14 14:00:38
    依据国家关于加强数字化改革对数据开发利用数字化转型的企业推进落实数据治理;数据治理正在逐步形成为业界的共识,数据治理涵盖数据发现可用、数据及时稳定产出、数据质量保障、数据安全合规、数据生产的经济性,...
  • 企业数据安全管理

    千次阅读 2022-01-07 10:41:13
    企业恐惧的不是强大的对手而是自己的商业机密变成了对方手里的底牌,机密到底是怎样泄漏的? 小心10%的不忠实雇员 在众多的公司安全威胁因素中,10%的不忠实雇员给企业带来的震荡是管理者们最担忧的。 很多...
  • 毕业设计 企业人事管理系统

    热门讨论 2011-05-10 20:42:47
    Browser/Server结构(简称B/S结构)是现代流行的信息系统结构,在B/S结构下,应用系统被分为前台(WEB页面)和后台(服务器)两部分,其作用分别是:应用请求由客户端浏览器产生,数据访问和事务处理由服务器完成...
  • 有一种方案既能满足用户数据安全的需求,又能比较迅速灵活地完成部署……
  • 落实数据合规,保障数据安全

    千次阅读 2021-03-11 11:44:00
    自2017年《中华人民共和国网络安全法》正式实施后,国内网络安全与数据合规方面的...第四十条 网络运营者应当对其收集的用户信息严格保密,并建立健全用户信息保护制度。 第四十一条 网络运营者收集、使用个人信...
  • 企业层面看,在深刻认识到数据安全保护重要性的同时,建立本地化运营团队,构建大数据安全系统,展开数据长期的分析和提炼,包括数据生产、采集、分析、应用开发,把大数据分析能力赋能给各层面人员做决策支持。...
  • 试验数据管理系统TDM与SDM

    千次阅读 2020-04-15 16:06:48
    产品研发过程主要包括设计、仿真和试验三个...市场上的仿真数据管理软件主要来源于两个方面,一方面是CAE软件自带的仿真数据管理模块,另一方面是PLM厂商所推出的仿真数据管理系统。 SDM(Simulation Data Manageme...
  • 系统的安全性设计  要设计一个安全的系统,除了要了解一些前面讲到的常用的保护手段和技术措施外,还要对系统中可能出现的安全问题或存在的安全隐患有充分的认识,这样才能对系统的安全作有针对性的设计和强化,即...
  • 论信息系统的安全性与保密性设计

    千次阅读 2020-06-28 10:23:32
    范文以“论信息系统的安全性与保密性设计”为题书写,希望对大家有所帮助。 【摘要】 2017年5月,我参加了某省质量技术监督局“生产制造一体化监管平台”项目(以下简称一体化平台),并担任系统架构师职务,负责...
  • 企业数据防泄漏解决方案的介绍!

    千次阅读 2018-09-29 11:48:14
    随着企业信息化的蓬勃发展,企业信息文档安全保护和知识产权保护方面面临着越来越严峻的挑战。...因此,如何用现有的技术手段来防护企业的核心数据,让企业的创新不被有意或无意泄露,从而保障企业的核心竞争力。
  • 企业人事管理系统便是以计算机为工具,通过对人事管理所需的信息管理,不仅把管理人员从繁琐的数据计算处理中解脱出来,而且优化了管理体系,使其高效化,简易化,智能化,也提高了透明度和互动性。
  • 化工行业的配方保密管理

    千次阅读 2020-06-08 10:40:59
    一、配方保密管理的重要性 配方,英文叫Formula,指为某种物质的配料提供方法和配比的处方。配方对于化工厂来说,是至关重要的无形资产之一,一个独特的配方能够确保这些企业的产品在市场中保持独有的竞争性。但是...
  • 数据运营平台-数据采集

    千次阅读 2020-11-20 18:29:38
    行为数据采集 业务数据采集与转换 第三方系统API对接 用户数据关联 人工数据采集 数据输出 行为数据采集 1.埋点采集 ①跨平台打通 确定性方法识别 利用用户帐号体系中,可以是系统生成的 UserID,可以是...
  • 基于区块链的医疗数据共享系统

    千次阅读 2020-04-06 22:52:07
    基于区块链的医疗数据共享系统 I. Abstract 随着大数据时代的到来,数据已经成为重要的资源,发挥数据价值的关键在于数据流通。但是,由于隐私泄漏等问题,各行业的数据共享发展缓慢,可以说,解决数据流通面临的...
  • 采用网上直报方式,不仅可以克服上述缺点,更可以降低数据采集工作处理时间,节省人力物力,提高企业工作效率,满足不断增长的业务需求。因此,建立电力调度信息报送系统是电力调度信息报送与披露工作的重要手段之一...
  • 涉密网络保密管理规定

    千次阅读 2021-07-13 01:14:45
    涉密网络保密管理规定为保守国家秘密和企业商业秘密,加强在网络维护管理过程中涉及国家和企业保密工作的管理,下面小编给大家介绍关于涉密网络保密管理规定的相关资料,希望对您有所帮助。涉密网络保密管理规定第一...
  • 欢迎添加微信互相交流学习哦!...企业人事管理系统是一个面向企业人事部门工作人员,为其提供服务的综合信息系统,管理人员通过本系统可以完成相关的日常工作。系统采用了面向对象的分析与设计,开发采用Grails架构。..
  • 某大中型企业。有多个部门,财务部、人事部、销售部、工程部。同部门之间采用二层交换网络相连;不同部门之间采用VLAN路由方式互访。企业有一台内部web服务器,承载着内部网站,方便员工了解公司的即时信息。局域网...
  • 数据安全分类分级剖析

    千次阅读 2021-09-15 00:04:46
    数据分类分级对于数据的安全管理至关重要,安全分类分级是一个“硬核课题”,从数据治理开始,除了标准化和价值应用,重要的课题就是质量+安全。安全是底线,是价值应用的前提和基础。数据分类可以为数据资产结构化...
  • 互联网企业:如何建设数据安全体系? 原创: 赵彦 美团点评技术团队 总第248篇 2018年 第40篇 一、背景 Facebook数据泄露事件一度成为互联网行业的焦点,几百亿美元市值瞬间蒸发,这个代价足以在地球上养活一...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 28,403
精华内容 11,361
关键字:

企业数据保密系统