数据安全及解决及方案

-.z数据平安解决方案目录数据平安解决方案11.数据平安与防泄密保护系统模型21.1.数据威胁模型22.数据平安与防泄密系统模型形式化描述33.数据加密与封装技术33.1.数据加密保护机制33.2.数据加密策略33.3.数据加密保护流程34.密钥管理技术34.1.密胡管理模型35.数字证书35.1.签名和加密35.2.一个加密通信过程的演化35.2.1.第一阶段35.2.2.第二阶段35.2.3.第三阶段35.2.4.第四阶段35.2.5.第五阶段35.2.6.完整过程35.3.数字证书原理36.内容平安3数据平安与防泄密保护系统模型数据威胁模型数据的平安技术主要建立在**性(Confidentiality)、完整性(Integrity)和可用性(Availability)三个平安原则根底之上。实际上,数据面临着严重的威胁(如以下图所示),主要受到通信因素、存储因素、身份认证、访问控制、数据发布、审计因素、制度因素和人员问题八大因素,具体因素内容在图2-1中详细的列举出来。数据威胁模型(1)通信威胁通信威胁指数据在网络通信和传输过程中所面临的威胁因素,主要包括数据截获算改、盗窃和监听、蠕虫和拒绝效劳攻击。(2)存储因素存储因素是指数据在存储过程中由于物理平安所面临的威胁,包括自然因素或者人为因素导致的数据破坏、盗窃或者丧失。(3)身份认证身份认证因素是指数据面临的各种与身份认证有关的威胁,包括外部认证效劳遭受攻击、通过非法方式(如使用特洛伊木马、网络探等)获取用户认证信息、身份抵赖。(4)访问控制因素访问控制因素是指数据面临的所有对用户授权和访问控制的威胁因素,主要包括未经授权的数据访问、用户错误操作或滥用权限、通过推理通道获取一些无权获取的信息。(5)数据发布因素数据发布因素是指在开放式环境下,数据发布过程中所遭受的隐私侵犯、数据盗版等威胁因素。(6)审计因素审计因素是指在审计过程中所面临的威胁因素,如审计记录无法分析、审计记录不全面、审计攻能被攻击者或管理员恶意关闭。(7)法律制度因素法律制度因素是指由于法律制度相关原因而使数据面临威胁,主要原因包括信息平安保障法律制度不健全、对攻击者的法律责任追究不够。(8)内部人员因素人员因素是指因为内部人士的疏忽或其它因素导致数据面临威胁,如管理员滥用权力、用户滥用权限、管理员的平安意识不强等。数据平安与防泄密系统模型形式化描述一个平安的数据防泄密信任模型包括主体、客体、数据内容加密保护、权限许可状态管理等四局部。其中,数据内容瞬态加密保护是最为核心也最为根底的阶段,而权限许可状态决定了数据使用控制的平安许可粒度。数据平安与防泄密系统模型(1)主体数据平安与防泄密信任模型中主体是指数据使用主体、分发主体、创立主体、管理主体。其中,前两者是数据用户,而后两者则是用于管理数据的主体。(2)客体客体是指授权主体执行权限的对象,包括一切形式的电子数据作品。(3)数据内容加密保护数据内容瞬态加密保护模型本质上是在内核态平安执行环境(Kemelenvironment,KE)下,对原始明文内容在特定的密钥管理组件控制下实施瞬态同步(SYN)加解密(Crypto),生成受保护内容C的一个复合模型。涉及到相关加解密(对称加解密、非对称加解密)、摘要和签名等根本操作,而对称加密涉及到ECB、CBC、OFB、CFB等加密模式密钥包括密胡的生成、分发、撤消、更新等环节。(4)权限许可状态管理权限许可状态管理模型通过不同的授权方式(比方用户授权、使用时间、设备授权、环境授权、文件授权等)对文件设置不同的操作权限,细化到阅读次数、使用有效期限、使用地点等权限,防止用户非法拷贝、复制、打印、下载文件、通过电子、移动硬盘等传输介质泄密。数据加密与封装技术数据加密保护机制数据加密保护基于如下机制:过滤驱动文件透明加\解密:采用系统指定的加解密策略(如加解密算法、密钥和文件类型等),在数据创立、存储、传输的瞬态进展自动加密,整个过程完全不需要用户的参与,用户无法干预数据在创立、存储、传输、分发过程中的平安状态和平安属性。内容加密:系统对数据使用对称加密密钥加密,然后打包封装。数据可以在分发前预先加密打包存储,也可以在分发时即时加密打包。内容完整性:内容发送方向接收方发送数据时,数据包包含数据的Hash值,接收方收到数据包解密后获得数据明文,计算Hash值,并与对应数据包中携带的Hash值作比较,两者一样表示该数据信息未在传输过程中被修改。身份认证:所有的用户都各自拥有自己唯一的数字证书和公私钥对,发送方和接收方通过PKI证书认证机制,相互确认对方身份的合法性。可靠与完整性:为保证数据包的可靠性和完整性,数据包中携带的重要信息(如内容加密密钥)采用接收方的公钢进展加密封装,从而将数据包绑定到该接收方,确保仅有指定的接收方才能正确解密该数据包,使用其私钥提取内容加密密钢。另外,发送方向接收方发送数据包前,先用其私钥对封装后的数据包进展数字签名。接收方对收到的数据包采用发送方的公朗对数字签名进展验证,从而确认数据包是否来自于发送方,且在传输过程中未被修改。数据加密策略数据加解密系统采用系统指定的加解密策略(如加解密算法、密钥和文件类型等)自动的对数据进展加解密操作,从而对数据平安方便有效的进展保护。针对不同的文件类型,系统将自动采用不同的密钥以及算法对数据文件进展加密,实时动态的对数据进展保护。数据加密策略主要包括加解密算法、密钥生成算法、密钥保护算法、密钥类型以及文件类型等。本模型主要采用的密码学算法列表如下:数据加解密策略列表数据加密保护流程开放络环境下数据加密保护流程包括:开放网络环境下数据加密保护流程图数据创立者创立电子文档,客户端采用过滤驱动透明加解密技术对电子文档进展加密,数据以密文形式存储在终端中创立者设置数据消息平安属性Leve/ (如)以及相关权限信息Metedata.不同的等级对应不同的权限操作创立者将内容加密密钥以效劳端的公钥进展加密创立者将数据明文作Hash计算,并将数据密文、明文Hash值、密钥加密密钥以及权限信息进展打包封装创立者通过私钥对数据包进展签名以保证数据包的可靠性和完整性,发送给效劳端备份存储效劳端收到数据包后,用创立者的公钥验证数据签名以确认数据包的可靠性和完整性,并利用自己的私钥提取内容加密密钥以及数据的相关平安属性效劳端通过提取出来的内容加密密钥对数据密文进展解密后,将得到的数据明文做Hash计算与数据包中提取出来的Hash值做比较,假设比较一致,则根据相关平安属性对数据进展备份存储场景描述：A：发送方B：接收方A要发送一段消息给B,但是又不想以明文发送,所以就需要对消息进展加密.如果采用对称加密技术,则加密与解密用的是同一把秘钥.除非B事先就知道A的秘钥,并且保存好.这样才可以解密A发来的消息.由于对称技术只有一把秘钥,所以秘钥的管理是一个很麻烦的问题.而非对称技术的诞生就解决了这个问题.非对称加密与解密使用的是不同的秘钥,并且秘钥对是一一对应的,即用A的私钥加密的密文只有用A的公钥才能解密.这样的话,每个人都有两把秘钥,私钥和公钥,私钥是只有自己才知道的,不能告诉别人,而公钥是公开的,大家都可以知道.这样,当A想要发送消息给B的时候,只需要用B的公钥对消息进展加密就可以了,由于B的私钥只有B才拥有,所以A用B的公钥加密的消息只有B才能解开.而B想更换自己的密钥时也很方便,只须把公钥告诉大家就可以了.则,既然非对称加密如此之好,对称加密就没有存在的必要了啊,其实不然,由于非对称加密算法的开销很大,所以如果直接以非对称技术来加密发送的消息效率会很差.则怎么办呢?解决的方法也很简单,就是把对称加密技术与非对称加密技术结合起来使用.A要发送一个消息给BA先生成一个对称秘钥,这个秘钥可以是随机生成的,A用B的公钥加密第一步生成的这个对称秘钥A把加密过的对称秘钥发给BA用第一步生成的这个对称秘钥加密实际要发的消息A把用对称秘钥加密的消息发给B对于B他先收到A发来的对称秘钥,这个秘钥是用B的公钥加密过的,所以B需要用自己的私钥来解密这个秘钥然后B又收到A发来的密文,这时候用刚刚解密出来的秘钥来解密密文这样子的整个过程既保证了平安,又保证了效率.密钥管理技术密胡管理模型在一个平安系统中,总体平安性依赖于许多不同的因素,例如算法的强度、密钥的大小、口令的选择、协议的平安性等,其中对密钥或口令的保护是尤其重要的。根据柯克霍夫假设(KerckhoffsAssumption),密码系统的平安完全取决于可随时改变的密钥。即使密码算法公开,也不会危及密码体制的平安性,但是,当密钥丧失时,非法用户将有可能窃取**信息。另外,有预谋的修改密钥和对密钥进展其他形式的非法操作,将涉及到整个平安系统的平安性。因此,密钥管理在整个密码系统中是极其重要的。密钥管理包括密钥的产生、装入、存储、备份、分配、更新、撤消和销毁等环节,是提供数据**性、数据完整性、可用性、可审查性和不可抵赖性等平安技术的根底。数字证书签名和加密我们说加密，是指对*个内容加密，加密后的内容还可以通过解密进展复原。比方我们把一封进展加密，加密后的内容在网络上进展传输，接收者在收到后，通过解密可以复原的真实内容。这里主要解释一下签名，签名就是在信息的后面再加上一段内容，可以证明信息没有被修改正，怎么样可以到达这个效果呢.一般是对信息做一个hash计算得到一个hash值，注意，这个过程是不可逆的，也就是说无法通过hash值得出原来的信息内容。在把信息发送出去时，把这个hash值加密后做为一个签名和信息一起发出去。接收方在收到信息后，会重新计算信息的hash值，并和信息所附带的hash值(解密后)进展比照，如果一致，就说明信息的内容没有被修改正，因为这里hash计算可以保证不同的内容一定会得到不同的hash值，所以只要内容一被修改，根据信息内容计算的hash值就会变化。当然，不怀好意的人也可以修改信息内容的同时也修改hash值，从而让它们可以相匹配，为了防止这种情况，hash值一般都会加密后(也就是签名)再和信息一起发送，以保证这个hash值不被修改。至于如何让别人可以解密这个签名，这个过程涉及到数字证书等概念，我们后面在说到数字证书时再详细说明，这里您先只需先理解签名的这个概念。一个加密通信过程的演化我们来看一个例子，现在假设“效劳器〞和“客户〞要在网络上通信，并且他们打算使用RSA(参看前面的RSA简介)来对通信进展加密以保证谈话内容的平安。由于是使用RSA这种公钥密码体制，“效劳器〞需要对外发布公钥(算法不需要公布，RSA的算法大家都知道)，自己留着私钥。“客户〞通过*些途径拿到了“效劳器〞发布的公钥，客户并不知道私钥。“客户〞具体是通过什么途径获取公钥的，我们后面再来说明，下面看一下双方如何进展**的通信。第一阶段“客户〞->“效劳器〞：你好“效劳器〞->“客户〞：你好，我是效劳器“客户〞->“效劳器〞：因为消息是在网络上传输的，有人可以冒充自己是“效劳器〞来向客户发送信息。黑客在“客户〞和“效劳器〞之间的*个路由器上截获“客户〞发给效劳器的信息，然后自己冒充“效劳器〞。例如上面的消息可以被黑客截获如下：“客户〞->“黑客〞：你好“黑客〞->“客户〞：你好，我是效劳器因此“客户〞在接到消息后，并不能肯定这个消息就是由“效劳器〞发出的，*些“黑客〞也可以冒充“效劳器〞发出这个消息。如何确定信息是由“效劳器〞发过来的呢.有一个解决方法，因为只有效劳器有私钥，所以如果只要能够确认对方有私钥，则对方就是“效劳器〞。因此通信过程可以改进为如下：第二阶段“客户〞->“效劳器〞：你好“效劳器〞->“客户〞：你好，我是效劳器“客户〞->“效劳器〞：向我证明你就是效劳器“效劳器〞->“客户〞：你好，我是效劳器{你好，我是效劳器}[私钥|RSA]注意：这里约定一下，{}表示RSA加密后的内容，[|]表示用什么密钥和算法进展加密，后面的例如中都用这种表示方式，例如上面的{你好，我是效劳器}[私钥|RSA]就表示用私钥对“你好，我是效劳器〞进展加密后的结果。为了向“客户〞证明自己是“效劳器〞，“效劳器〞把一个字符串用自己的私钥加密，把明文和加密后的密文一起发给“客户〞。对于这里的例子来说，就是把字符串“你好，我是效劳器〞和这个字符串用私钥加密后的内容{你好，我是效劳器}[私钥|RSA]发给客户。“客户〞收到信息后，她用自己持有的公钥解密密文，和明文进展比照，如果一致，说明信息确实是由效劳器发过来的。也就是说“客户〞把{你好，我是效劳器}[私钥|RSA]这个内容用公钥进展解密，然后和“你好，我是效劳器〞比照。因为由“效劳器〞用私钥加密后的内容，由并且只能由公钥进展解密，私钥只有“效劳器〞持有，所以如果解密出来的内容是能够对得上的，那说明信息一定是从“效劳器〞发过来的。假设“黑客〞想冒充“效劳器〞：“黑客〞->“客户〞：你好，我是效劳器“客户〞->“黑客〞：向我证明你就是效劳器“黑客〞->“客户〞：你好，我是效劳器{你好，我是效劳器}[...|RSA]“客户〞->“黑客〞：这里黑客无法冒充，因为他不知道私钥，无法用私钥加密*个字符串后发送给客户去验证。由于“黑客〞没有“效劳器〞的私钥，因此它发送过去的内容，“客户〞是无法通过效劳器的公钥解密的，因此可以认定对方是个冒牌货！到这里为止，“客户〞就可以确认“效劳器〞的身份了，可以放心和“效劳器〞进展通信，但是这里有一个问题，通信的内容在网络上还是无法**。为什么无法**呢.通信过程不是可以用公钥、私钥加密吗.其实用RSA的私钥和公钥是不行的，我们来具体分析下过程，看下面的演示：第三阶段“客户〞->“效劳器〞：你好“效劳器〞->“客户〞：你好，我是效劳器“客户〞->“效劳器〞：向我证明你就是效劳器“效劳器〞->“客户〞：你好，我是效劳器{你好，我是效劳器}[私钥|RSA]“客户〞->“效劳器〞：{我的**是aaa，密码是123，把我的余额的信息发给我看看}[公钥|RSA]“效劳器〞->“客户〞：{你的余额是100元}[私钥|RSA]注意上面的的信息{你的余额是100元}[私钥]，这个是“效劳器〞用私钥加密后的内容，但是我们之前说了，公钥是发布出去的，因此所有的人都知道公钥，所以除了“客户〞，其它的人也可以用公钥对{你的余额是100元}[私钥]进展解密。所以如果“效劳器〞用私钥加密发给“客户〞，这个信息是无法**的，因为只要有公钥就可以解密这内容。然而“效劳器〞也不能用公钥对发送的内容进展加密，因为“客户〞没有私钥，发送给“客户〞也解密不了。这样问题就又来了，那又如何解决呢.在实际的应用过程，一般是通过引入对称加密来解决这个问题，看下面的演示：第四阶段“客户〞->“效劳器〞：你好“效劳器〞->“客户〞：你好，我是效劳器“客户〞->“效劳器〞：向我证明你就是效劳器“效劳器〞->“客户〞：你好，我是效劳器{你好，我是效劳器}[私钥|RSA]“客户〞->“效劳器〞：{我们后面的通信过程，用对称加密来进展，这里是对称加密算法和密钥}[公钥|RSA]“效劳器〞->“客户〞：{OK，收到！}[密钥|对称加密算法]“客户〞->“效劳器〞：{我的**是aaa，密码是123，把我的余额的信息发给我看看}[密钥|对称加密算法]“效劳器〞->“客户〞：{你的余额是100元}[密钥|对称加密算法]在上面的通信过程中，“客户〞在确认了“效劳器〞的身份后，“客户〞自己选择一个对称加密算法和一个密钥，把这个对称加密算法和密钥一起用公钥加密后发送给“效劳器〞。注意，由于对称加密算法和密钥是用公钥加密的，就算这个加密后的内容被“黑客〞截获了，由于没有私钥，“黑客〞也无从知道对称加密算法和密钥的内容。由于是用公钥加密的，只有私钥能够解密，这样就可以保证只有效劳器可以知道对称加密算法和密钥，而其它人不可能知道(这个对称加密算法和密钥是“客户〞自己选择的，所以“客户〞自己当然知道如何解密加密)。这样“效劳器〞和“客户〞就可以用对称加密算法和密钥来加密通信的内容了。到这里，“客户〞就可以确认“效劳器〞的身份，并且双方的通信内容可以进展加密，其他人就算截获了通信内容，也无法解密。确实，好似通信的过程是比较平安了。但是这里还留有一个问题，在最开场我们就说过，“效劳器〞要对外发布公钥，那“效劳器〞如何把公钥发送给“客户〞呢.我们第一反响可能会想到以下的两个方法：A：把公钥放到互联网的*个地方的一个下载地址，事先给“客户〞去下载。B：每次和“客户〞开场通信时，“效劳器〞把公钥发给“客户〞。但是这个两个方法都有一定的问题，对于A方法，“客户〞无法确定这个下载地址是不是“效劳器〞发布的，你凭什么就相信这个地址下载的东西就是“效劳器〞发布的而不是别人伪造的呢，万一下载到一个假的怎么办.另外要所有的“客户〞都在通信前事先去下载公钥也很不现实。对于B方法，也有问题，因为任何人都可以自己生成一对公钥和私钥，他只要向“客户〞发送他自己的私钥就可以冒充“效劳器〞了。示意如下：“客户〞->“黑客〞：你好//黑客截获“客户〞发给“效劳器〞的消息“黑客〞->“客户〞：你好，我是效劳器，这个是我的公钥//黑客自己生成一对公钥和私钥，把公钥发给“客户〞，自己保存私钥“客户〞->“黑客〞：向我证明你就是效劳器“黑客〞->“客户〞：你好，我是效劳器{你好，我是效劳器}[黑客自己的私钥|RSA]//客户收到“黑客〞用私钥加密的信息后，是可以用“黑客〞发给自己的公钥解密的，从而会误认为“黑客〞是“效劳器〞因此“黑客〞只需要自己生成一对公钥和私钥，然后把公钥发送给“客户〞，自己保存私钥，这样由于“客户〞可以用黑客的公钥解密黑客的私钥加密的内容，“客户〞就会相信“黑客〞是“效劳器〞，从而导致了平安问题。这里问题的根源就在于，大家都可以生成公钥、私钥对，无法确认公钥对到底是谁的。如果能够确定公钥到底是谁的，就不会有这个问题了。例如，如果收到“黑客〞冒充“效劳器〞发过来的公钥，经过*种检查，如果能够发现这个公钥不是“效劳器〞的就好了。为了解决这个问题，数字证书出现了，它可以解决我们上面的问题。先大概看下什么是数字证书，一个证书包含下面的具体内容：证书的发布机构证书的有效期公钥证书所有者〔Subject〕签名所使用的算法指纹以及指纹算法证书的内容的详细解释会在后面详细解释，这里先只需要搞清楚一点，数字证书可以保证数字证书里的公钥确实是这个证书的所有者(Subject)的，或者证书可以用来确认对方的身份。也就是说，我们拿到一个数字证书，我们可以判断出这个数字证书到底是谁的。至于是如何判断的，后面会在详细讨论数字证书时详细解释。现在把前面的通信过程使用数字证书修改为如下：第五阶段“客户〞->“效劳器〞：你好“效劳器〞->“客户〞：你好，我是效劳器，这里是我的数字证书//这里用证书代替了公钥“客户〞->“效劳器〞：向我证明你就是效劳器“效劳器〞->“客户〞：你好，我是效劳器{你好，我是效劳器}[私钥|RSA]注意：上面第二次通信，“效劳器〞把自己的证书发给了“客户〞，而不是发送公钥。“客户〞可以根据证书校验这个证书到底是不是“效劳器〞的，也就是能校验这个证书的所有者是不是“效劳器〞，从而确认这个证书中的公钥确实是“效劳器〞的。后面的过程和以前是一样，“客户〞让“效劳器〞证明自己的身份，“效劳器〞用私钥加密一段内容连同明文一起发给“客户〞，“客户〞把加密内容用数字证书中的公钥解密后和明文比照，如果一致，则对方就确实是“效劳器〞，然后双方协商一个对称加密来保证通信过程的平安。到这里，整个过程就完整了，我们回忆一下：完整过程“客户〞->“效劳器〞：你好“效劳器〞->“客户〞：你好，我是效劳器，这里是我的数字证书“客户〞->“效劳器〞：向我证明你就是效劳器，这是一个随机字符串//前面的例子中为了方便解释，用的是“你好〞等内容，实际情况下一般是随机生成的一个字符串。“效劳器〞->“客户〞：{一个随机字符串}[私钥|RSA]“客户〞->“效劳器〞：{我们后面的通信过程，用对称加密来进展，