文章目錄

(資料圖片)

前言第一章、數(shù)據(jù)第二章、OSI七層網(wǎng)絡(luò)模型&TCP/IP四層模型2.1 數(shù)據(jù)封裝與解封2.2 應(yīng)用層2.3 傳輸層2.4 網(wǎng)絡(luò)層2.5 數(shù)據(jù)鏈路層2.6 物理層2.7 小結(jié) 第三章、數(shù)據(jù)的保密性與完整性3.1 數(shù)據(jù)可用性3.2 數(shù)據(jù)完整性3.3 數(shù)據(jù)保密性 第四章、為什么說HTTPS能保證數(shù)據(jù)傳輸?shù)耐暾院捅Ｃ苄阅兀?.1 HTTP通信原理4.2 HTTPS通信原理4.3 抓包比較http和https頭信息 第五章、總結(jié)

前言

在GB/T 22239-2019《信息安全技術(shù) 網(wǎng)絡(luò)安全等級保護(hù)基本要求》中對不同級別的信息系統(tǒng)都提出了數(shù)據(jù)完整性和數(shù)據(jù)保密性的要求，安全通用要求、云計算安全擴(kuò)展要求、移動互聯(lián)安全擴(kuò)展要求、物聯(lián)網(wǎng)安全擴(kuò)展要求、工業(yè)控制系統(tǒng)安全擴(kuò)展要求要五大部分均涉及數(shù)據(jù)保密性和數(shù)據(jù)完整性。

很多小伙伴不理解數(shù)據(jù)保密性和數(shù)據(jù)完整性到底是什么，本文主要解釋以下兩個問題。 1. 如何理解數(shù)據(jù)的保密性與完整性？ 2. 如何保證數(shù)據(jù)的保密性與完整性？

第一章、數(shù)據(jù)

這里我們說的數(shù)據(jù)指的是所有能輸入計算機(jī)并被計算機(jī)程序處理的符號的介質(zhì)的總稱，是用于輸入電子計算機(jī)進(jìn)行處理，具有一定意義的數(shù)字、字母、符號和模擬量等的通稱。

第二章、OSI七層網(wǎng)絡(luò)模型&TCP/IP四層模型

在學(xué)習(xí)數(shù)據(jù)的保密性和完整性之前，先了解下數(shù)據(jù)在OSI七層模型的每一層是如何存在的以及數(shù)據(jù)在每層之間是如何傳輸?shù)摹? 注意：物理層并不是指具體的物理設(shè)備，也不是指用來傳輸信息的物理媒體，指的是傳輸原始比特流的物理連接，上圖只有物理層是實線連接的。

TCP/IP四層模型是OSI七層模型簡化而來的，兩種模型對應(yīng)關(guān)系見下圖。 介紹完兩種模型，接下來就進(jìn)入正題了，數(shù)據(jù)在每層是如何傳輸?shù)哪兀?/p>

2.1 數(shù)據(jù)封裝與解封

數(shù)據(jù)封裝：數(shù)據(jù)的封裝是一個自上而下的過程，我們在客戶端應(yīng)用（比如微信）上發(fā)送一個“hello”，數(shù)據(jù)流經(jīng)每一層時是怎樣變化的呢？首先一個用戶在發(fā)給電腦一個請求，先傳給應(yīng)用層應(yīng)用將數(shù)據(jù)處理完，之后交給傳輸層加好TCP或者UDP的報頭，傳給網(wǎng)絡(luò)層再添加一層IP的報頭，再交給數(shù)據(jù)鏈路層添加mac的頭部和尾部，最后送到物理鏈路層轉(zhuǎn)為比特流進(jìn)行傳出，這就是封裝過程。

數(shù)據(jù)解封：數(shù)據(jù)封裝的逆過程，數(shù)據(jù)的解封是一個自下而上的過程。

上圖可以看出，每一層數(shù)據(jù)是由上一層數(shù)據(jù)+本層首部信息組成的，其中每一層的數(shù)據(jù) ，稱為本層的協(xié)議數(shù)據(jù)單元 ，即PDU。

2.2 應(yīng)用層

應(yīng)用層功能：

應(yīng)用層：為用戶的應(yīng)用提供服務(wù)并支持網(wǎng)絡(luò)訪問；會話層：負(fù)責(zé)管理網(wǎng)絡(luò)中計算之間的通信，提供傳輸層不具備的連接相關(guān)功能；表示層：負(fù)責(zé)轉(zhuǎn)化數(shù)據(jù)格式，并處理數(shù)據(jù)加密和數(shù)據(jù)壓縮。 即負(fù)責(zé)一切與應(yīng)用程序相關(guān)的功能

我們在應(yīng)用軟件（如微信、qq等）用戶端發(fā)出一條消息“hello”，應(yīng)用層將這條消息處理為一個五層的數(shù)據(jù)包，這里我們可以認(rèn)為數(shù)據(jù)包的內(nèi)容為我們發(fā)出的“hello”應(yīng)用消息。

2.3 傳輸層

傳輸層功能：

提供應(yīng)用程序接口，為網(wǎng)絡(luò)應(yīng)用程序提供網(wǎng)絡(luò)訪問的途徑；提供可以從多個應(yīng)用層序接收消息的功能（多路復(fù)用），同時也提供可以把消息分發(fā)給應(yīng)用程序的功能（多路分解）；對數(shù)據(jù)進(jìn)行錯誤檢測、流量控制。 即為上層提供端到端的（一臺主機(jī)到另一臺主機(jī)）、透明的、可靠的數(shù)據(jù)傳輸服務(wù)。所謂透明的傳輸是指在通信過程中傳輸層對上層屏蔽了通信傳輸系統(tǒng)的具體細(xì)節(jié)。

應(yīng)用層將消息封裝成數(shù)據(jù)包后，將數(shù)據(jù)包傳遞到傳輸層，傳輸層會對五層數(shù)據(jù)包進(jìn)行進(jìn)一步的封裝，即為該數(shù)據(jù)包添加一個TCP/UDP頭部（TCP或者UDP二者其中一個，具體取決于軟件選擇那個協(xié)議），其中含有源端口號和目的端口號，源端口號即為軟件使用的上一層協(xié)議的端口號，目的端口號為接收數(shù)據(jù)方接收該數(shù)據(jù)的端口號。例如當(dāng)我們用瀏覽器訪問一個https開頭的網(wǎng)頁時，實際上我們是在訪問對方服務(wù)器的443端口。

2.4 網(wǎng)絡(luò)層

網(wǎng)絡(luò)層功能：

該層解決數(shù)據(jù)由一個計算機(jī)的IP如何路由到目標(biāo)計算機(jī)的過程規(guī)范。 即通過路由算法，為報文或分組通過通信子網(wǎng)選擇最適當(dāng)?shù)穆窂剑?確保數(shù)據(jù)及時傳送。

一個網(wǎng)絡(luò)里有那么多主機(jī)，我們的計算機(jī)消息發(fā)送出去后，數(shù)據(jù)包怎么才能成功的傳輸?shù)轿覀冎付ǖ闹鳈C(jī)上呢？在發(fā)送數(shù)據(jù)時，網(wǎng)絡(luò)層會對該數(shù)據(jù)包添加一個IP包頭，其中含有數(shù)據(jù)包的源IP和目標(biāo)IP，數(shù)據(jù)傳輸?shù)倪^程中就是根據(jù)這層的目標(biāo)IP找到需要通信的主機(jī)。

前三層的數(shù)據(jù)包很重要，在一個包中稱為上三層數(shù)據(jù)，是最有價值的包，不能被別人篡改，一旦被篡改就有可能造成通信出錯或者信息泄露。（例如本來A發(fā)給B的數(shù)據(jù)，上三層數(shù)據(jù)被篡改后發(fā)給了C）

接下來的兩層在網(wǎng)絡(luò)中也是必不可少的，雖然上三層在數(shù)據(jù)包中指明了傳輸?shù)穆肪€，但是上三層數(shù)據(jù)包是無法通過介質(zhì)進(jìn)行傳播的（例如網(wǎng)線、WiFi、光纖），那如果數(shù)據(jù)包想過介質(zhì)進(jìn)行傳播的話怎么辦呢，這就需要用到下面的兩層了。

2.5 數(shù)據(jù)鏈路層

數(shù)據(jù)鏈路層功能：

為了保證傳輸，從網(wǎng)絡(luò)層接收到的數(shù)據(jù)被分割成特定的可被物理層傳輸?shù)膸?。幀是用來移動?shù)據(jù)的結(jié)構(gòu)包，它不僅包括原始數(shù)據(jù)，還包括發(fā)送方和接收方的物理地址以及檢錯和控制信息。 即通過各種控制協(xié)議，將有差錯的物理信道變?yōu)闊o差錯的、能可靠傳輸數(shù)據(jù)幀的數(shù)據(jù)鏈路。

當(dāng)上三層的數(shù)據(jù)包到了數(shù)據(jù)鏈路層，就意味著這個信息已經(jīng)成功到達(dá)計算機(jī)的網(wǎng)卡，下一步就可以通過網(wǎng)線傳輸了，這時我們的信息就需要一個載體來進(jìn)行傳輸，于是在第二層會給上三層數(shù)據(jù)包加上一個二層頭部（MAC子層）和二層尾部（FCS）。

2.6 物理層

物理層功能：

為數(shù)據(jù)端設(shè)備提供傳送數(shù)據(jù)通路、傳輸數(shù)據(jù)。

所謂的物理層，是指光纖、電纜或者電磁波等真實存在的物理媒介。這些媒介可以傳送物理信號，比如亮度、電壓或者振幅。

網(wǎng)卡二層數(shù)據(jù)幀包送到網(wǎng)線上，這時候二層的數(shù)據(jù)幀包會被轉(zhuǎn)化成一段連續(xù)的比特流，然后以電脈沖的形式傳輸?shù)浇粨Q機(jī)，最后到達(dá)目標(biāo)主機(jī)物理層。（對于數(shù)字應(yīng)用來說，我們只需要兩種物理信號來分別表示0和1，比如用高電壓表示1，低電壓表示0，就構(gòu)成了簡單的物理層協(xié)議。針對某種媒介，電腦可以有相應(yīng)的接口，用來接收物理信號，并解讀成為0/1序列。）

2.7 小結(jié)

數(shù)據(jù)封裝就是不斷的加頭，數(shù)據(jù)解封過程就是不斷的去頭的過程。

第三章、數(shù)據(jù)的保密性與完整性

上章節(jié)介紹完了OSI和TCP/IP模型，我們比較清楚數(shù)據(jù)在每一層中是如何存在的了，以及數(shù)據(jù)是如何從主機(jī)A層層傳輸?shù)街鳈C(jī)B。要保證數(shù)據(jù)安全，就要保證數(shù)據(jù)經(jīng)過每一層時的安全性。

我們這里說到的數(shù)據(jù)安全是參照GB/T 22239-2019《信息安全技術(shù) 網(wǎng)絡(luò)安全等級保護(hù)基本要求》以及國際標(biāo)準(zhǔn)化組織對數(shù)據(jù)安全的定義，保障數(shù)據(jù)安全，即保障數(shù)據(jù)的可用性、保密性、完整性。

3.1 數(shù)據(jù)可用性

定義：指數(shù)據(jù)可被授權(quán)實體按要求訪問、正常使用或在非正常情況下能恢復(fù)使用的特性。

舉個例子，我們常說的DDOS攻擊，就是利用目標(biāo)系統(tǒng)的網(wǎng)絡(luò)服務(wù)功能缺陷或者直接消耗大量系統(tǒng)資源，使目標(biāo)系統(tǒng)無法提供正常的服務(wù)，其實這就是破壞數(shù)據(jù)的可用性。

現(xiàn)在主要是采用現(xiàn)代信息存儲手段對數(shù)據(jù)進(jìn)行主動防護(hù)，如通過磁盤陣列、數(shù)據(jù)備份、異地容災(zāi)等手段，以規(guī)避硬件故障、軟件故障、環(huán)境風(fēng)險、人為故障、自然災(zāi)害等風(fēng)險，保證數(shù)據(jù)的可用性。

3.2 數(shù)據(jù)完整性

定義：是指信息在傳輸、存儲和處理過程中，保持信息不被破壞或修改、不丟失和信息未經(jīng)授權(quán)不能改變的特性。換句話說，接收到的數(shù)據(jù)必須與發(fā)送的數(shù)據(jù)相同。

國密算法中，能夠提供數(shù)據(jù)完整性的算法主要是：SM3； 國際算法中，能夠提供數(shù)據(jù)完整性的算法主要是：MD5、SHA256、SHA512。

校驗技術(shù)指的是類似TCP協(xié)議的CRC校驗碼或者海明校驗碼等，這是協(xié)議層面的，如果按照這要求連接，那么這條指標(biāo)基本全部符合，所以目前測評難點(diǎn)不是在這里，而是在密碼技術(shù)如何實現(xiàn)完整性。 傳輸過程中的完整性主要通過協(xié)議（比如TLS、SSH協(xié)議）來實現(xiàn)，通過MAC(消息校驗碼)來實現(xiàn)整個數(shù)據(jù)報文的完整性和加密性，因此，在測評中，如果采用TLS/SSL協(xié)議、SSH協(xié)議，默認(rèn)其實應(yīng)該是符合傳輸過程中的完整性要求的。

另外還記得第二章講數(shù)據(jù)封裝過程嗎？在數(shù)據(jù)鏈路層需要添加頭部MAC子層和尾部FCS，可以用來保證數(shù)據(jù)的完整性。

數(shù)據(jù)存儲過程中的完整性，主要是核查數(shù)據(jù)庫表(業(yè)務(wù)數(shù)據(jù)、審計數(shù)據(jù))是否存在哈希字段，在業(yè)務(wù)數(shù)據(jù)或?qū)徲嫈?shù)據(jù)中，數(shù)據(jù)在前端一般通過json或xml格式進(jìn)行傳輸，那么數(shù)據(jù)在存儲過程完整性應(yīng)該是核查相關(guān)數(shù)據(jù)庫表字段中是否包含完整性校驗字段。

一般很少有系統(tǒng)能實現(xiàn)數(shù)據(jù)存儲過程的完整性校驗，但是如果通過TLS/SSL、SSH等協(xié)議，可以通過傳輸過程中的完整性在一定程度上彌補(bǔ)存儲過程中的完整性，所以在測評中，如果傳輸過程中能保證數(shù)據(jù)完整性，那么此項一般默認(rèn)符合。

3.3 數(shù)據(jù)保密性

定義：是不將有用信息泄漏給非授權(quán)用戶的特性。換句話說，確保數(shù)據(jù)信息只能被授權(quán)者看到。

可以通過信息加密、身份認(rèn)證、訪問控制、安全通信協(xié)議等技術(shù)實現(xiàn)，目前保密性主要是通過加密算法來實現(xiàn)。

國密算法中，能夠提供數(shù)據(jù)保密性的算法主要是：SM1和SM2，少數(shù)使用祖沖之，無線局域網(wǎng)中使用SM4。 國際算法中，能夠提供數(shù)據(jù)保密性的算法主要是：DES、3DES、RSA、AES、ECC等。

檢查數(shù)據(jù)傳輸過程中的保密性，主要核查是否采用TLS/SSL、SSH等加密協(xié)議。注意：如果使用MD5進(jìn)行密碼加密，很多測評機(jī)構(gòu)會默認(rèn)不符合。原因是通常情況下客戶端拿到原密碼進(jìn)行MD5加密，然后進(jìn)行存儲或者校驗，但是如果網(wǎng)站使用http協(xié)議，那么傳輸數(shù)據(jù)容易被中間人劫持，中間人在得到MD5加密后的密文后可以采用跑大型字典的方法進(jìn)行爆破，所以MD5也就不太安全了。

數(shù)據(jù)存儲過程中的保密性，這個比較容易理解，主要是核查相關(guān)鑒別數(shù)據(jù)（賬戶的口令）、業(yè)務(wù)數(shù)據(jù)、審計數(shù)據(jù)是否加密存儲（非明文存儲）。

在測評中，操作系統(tǒng)鑒別數(shù)據(jù)一般都會符合，默認(rèn)都是使用哈希算法；業(yè)務(wù)系統(tǒng)的鑒別數(shù)據(jù)，這個一般需要核查下數(shù)據(jù)庫表，查看是否是明文存儲；至于業(yè)務(wù)數(shù)據(jù)和個人信息等一般系統(tǒng)都明文存儲（主要原因是影響系統(tǒng)性能），所以一般不符合。

ps：如果使用有加密功能并且開啟加密功能的數(shù)據(jù)庫或者數(shù)據(jù)庫加密設(shè)備，默認(rèn)該項為符合。

第四章、為什么說HTTPS能保證數(shù)據(jù)傳輸?shù)耐暾院捅Ｃ苄阅兀?/p>

上文分析我們可以看出，要想保證數(shù)據(jù)在傳輸過程的完整性和保密性，需要檢查是否采用了TLS/SSL協(xié)議。我們知道HTTPS是在HTTP基礎(chǔ)上加了SSL（Secure Socket Layer，安全套接字層），TLS是SSL的升級版。那么為什么說HTTP不能保證數(shù)據(jù)傳輸安全，而HTTPS可以保證數(shù)據(jù)傳輸過程的完整性和保密性呢？

注意：https并非是應(yīng)用層的一種新協(xié)議，只是http通信接口部分用SSL/TLS協(xié)議代替而已。通常，http是直接和tcp通信的，當(dāng)使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了。SSL是獨(dú)立于HTTP協(xié)議的，所以不光是http協(xié)議，其他運(yùn)行在應(yīng)用層的協(xié)議，如smtp和telnet協(xié)議，也可配合ssl協(xié)議使用。

4.1 HTTP通信原理

作為標(biāo)準(zhǔn)的C/S模型，http協(xié)議總是由客戶端發(fā)起，服務(wù)器進(jìn)行響應(yīng)。通信過程如下：

DNS解析，域名系統(tǒng)DNS將域名解析成IP地址建立TCP連接，進(jìn)行TCP的三次握手瀏覽器發(fā)送請求服務(wù)器響應(yīng)瀏覽器，向瀏覽器發(fā)送數(shù)據(jù)通信完成，TCP連接關(guān)閉

http協(xié)議屬于明文傳輸協(xié)議，通信雙方?jīng)]有進(jìn)行認(rèn)證，存在如下的問題：

竊聽風(fēng)險：第三方可以獲知通信內(nèi)容篡改風(fēng)險：第三方可以修改通信內(nèi)冒充風(fēng)險：第三方可以冒充他人身份參與通信

4.2 HTTPS通信原理

https通信是建立在ssl連接層之上的請求和響應(yīng)，通信過程如下：

客戶端和服務(wù)器端通過TCP建立連接，并發(fā)送https請求。服務(wù)器響應(yīng)請求，并將數(shù)字證書發(fā)送給客戶端，數(shù)字證書包括公共秘鑰、域名、申請證書的公司?？蛻舳耸盏椒?wù)器端的數(shù)字證書之后，會驗證數(shù)字證書的合法性。如果公鑰合格，那么客戶端會生成client key，一個用于進(jìn)行對稱加密的密鑰，并用服務(wù)器的公鑰對客戶端密鑰進(jìn)行非對稱加密?？蛻舳藭俅伟l(fā)起請求，將加密之后的客戶端密鑰發(fā)送給服務(wù)器。服務(wù)器接收密文后，會用私鑰對其進(jìn)行非對稱解密，得到客戶端秘鑰。并使用客戶端秘鑰進(jìn)行對稱加密，生成密文并發(fā)送?？蛻舳耸盏矫芪模⑹褂每蛻舳嗣罔€進(jìn)行解密，獲取數(shù)據(jù)。

HTTPS是在HTTP基礎(chǔ)上加了SSL（Secure Socket Layer，安全套接字層），具有如下優(yōu)勢：

所有信息都是加密傳播，第三方無法竊聽具有校驗機(jī)制，一旦被篡改，通信雙方會立刻發(fā)現(xiàn)配備身份證書，防止身份被冒充

4.3 抓包比較http和https頭信息

查看http中的 request 與 response，可以看出是明文傳輸?shù)摹?查看https網(wǎng)站，可以看到內(nèi)容全部加密。

那么https是不是就是沒有風(fēng)險的呢？當(dāng)然不是，任何安全措施或安全協(xié)議都不可能保證絕對安全，比如SSL 2.0就被爆出有很多安全漏洞，如同一加密密鑰用于消息身份驗證和加密、弱消息認(rèn)證代碼結(jié)構(gòu)和只支持不安全的MD5哈希函數(shù)、SSL握手過程沒有采取任何防護(hù)等等漏洞。攻擊者就可以利用該漏洞對發(fā)起網(wǎng)絡(luò)攻擊。

關(guān)于http是如何一步一步演變成https的，可以看下https://blog.csdn.net/csdnlijingran/article/details/88922340?，介紹的很詳細(xì)。

第五章、總結(jié)

本文主要圍繞數(shù)據(jù)完整性和數(shù)據(jù)保密性，在第二章介紹了OSI模型和TCP/IP模型，以及數(shù)據(jù)封裝和解封的過程，在第三章介紹了數(shù)據(jù)完整性和保密性的具體含義，以及具體測評過程中的檢查方法，第四章則介紹了HTTP與HTTPS的通信原理，以及HTTPS能夠保證數(shù)據(jù)傳輸過程完整性和保密性的原理。

本文是作者查閱了大量資料和平時工作學(xué)習(xí)歸納總結(jié)的，寫的不對的地方歡迎指正。