【正文】 這些操作會(huì)引起服務(wù)器端程序?qū)?shù)據(jù)庫(kù)表userInfoTable和 userBlackTable的相應(yīng)修改。 如圖 314. 代理服務(wù)端實(shí)現(xiàn) 第 31 頁(yè) 共 71 頁(yè) 圖 315 服務(wù)器端主界面 用戶管理 服務(wù)器端程序在初始化的時(shí)候，通過(guò)訪問(wèn)數(shù)據(jù)庫(kù)表 userInfoTable將所有注冊(cè)了的用戶信息顯示出來(lái)，方便管理員進(jìn)行管理。 第 30 頁(yè) 共 71 頁(yè) 圖 314 共享審批示意圖 基于云計(jì)算的網(wǎng)絡(luò)虛擬磁盤系統(tǒng)，采用嚴(yán)格的共享審批機(jī)制，對(duì)用戶的共享行為進(jìn)行審計(jì)，該審計(jì)由相關(guān)負(fù)責(zé)人完成，通過(guò)審批通過(guò)的文件共享行為才能夠順利進(jìn)行，并且系統(tǒng)對(duì)所有的共享行為及審批結(jié)果進(jìn)行了詳細(xì)的日志記錄，在一定程序上對(duì)相關(guān)負(fù)責(zé)人的行為進(jìn)行了監(jiān)控，防止出現(xiàn)如前面提到的公司高管泄露機(jī)密的隱患。 圖 313 加載受限安全策略 權(quán)限審批 對(duì)于一般的企業(yè)文件管理系統(tǒng)，內(nèi)部文件共享的機(jī)制并不完善。安全策略有三項(xiàng)：保存與打印控制 、 文字拷貝控制 、 屏幕拷貝控制。通過(guò)對(duì)文檔內(nèi)容級(jí)的安全保護(hù)，實(shí)現(xiàn)機(jī)密信息分密級(jí)且分權(quán)限的內(nèi)部安全共享機(jī)制。 （ 2） 加載： 如果用戶 A將該權(quán)限授予用戶 B，則用戶 B不僅可以在他的用戶空間里面看到用戶 A在服務(wù)器端存放的映像文件 I里面的信息，還可以下載該映像文件 I，并可將下載后的映像文件 I在用戶 B的本地加載為本地磁盤，從而使用里面的文件，但用戶 B對(duì)該本地磁盤的修改不會(huì)更新到服務(wù)器端對(duì)應(yīng)的映像文件 I中。當(dāng)用戶由于某些需要將該用戶的數(shù)據(jù)和其他某用戶進(jìn)行共享時(shí)，可以通過(guò)權(quán)限控制來(lái)實(shí)現(xiàn)其他用戶瀏覽或下載該用戶在服務(wù)器端的映像文件，從而達(dá)到數(shù)據(jù)共享的目的 。 用戶 對(duì) 本地 加載 的映像文件 進(jìn)行操作后，可以手動(dòng) 上傳到 云 端 或者在退出系統(tǒng)后自動(dòng)上傳 。 用戶 除了查看 自己在 云 端的映像文件 的內(nèi)容之外，還可以查看 其他用戶授予 該 用戶瀏覽或 加 載權(quán)限的映像文件里面的內(nèi)容。 用戶可以查看映像文件里面保存的內(nèi)容，并可將映像文件下載到本地并加載為本地磁盤。 第 26 頁(yè) 共 71 頁(yè) 相關(guān)技術(shù)實(shí)現(xiàn)見(jiàn)下面的 Filedisk— 文件驅(qū)動(dòng)源碼分析。由映像文件加載后的磁盤的截圖見(jiàn)圖 35。 ? 加載映像文件：對(duì)于新創(chuàng)建的映像文件，直接用 filedisk加載成本地磁盤。 創(chuàng)建虛擬映像、加載、卸載虛擬磁盤 圖 39 虛擬磁盤界面 ? 創(chuàng)建映像文件：用戶選擇待創(chuàng)建的映像文件所在的盤符、文件名以及文件大?。ū咀髌酚诚裎募臄U(kuò)展名為 .vdk），點(diǎn)擊確定后，客戶端程序首先向服務(wù)器進(jìn)行映像創(chuàng)建的申請(qǐng)，服務(wù)器端程序接受到后，為待創(chuàng) 建的映像文件分配一個(gè)隨機(jī)密鑰 M4，并用 M1進(jìn)行 加密然后 傳給客戶端的對(duì)應(yīng)用戶。 除此之外，用戶可以右鍵，更改映像文件的名稱、將映像文件的自動(dòng)加載狀態(tài) 第 25 頁(yè) 共 71 頁(yè) 置為 “ 是 ” 從而在下次登錄的時(shí)候能自動(dòng)加載該映像文件。如果自動(dòng)加載這一欄為 “ 否 ” ，則將對(duì)應(yīng)的狀態(tài)值置為 “ 未加載 ” 。 解密完成后，調(diào)用 filedisk的 mount命令 ，將 該映像文件 加載為本地磁盤。 解密之后，再用會(huì)話密鑰 M1進(jìn)行加密，并傳給客戶端。 然后，客戶端程序檢查參數(shù)是否自動(dòng)加載，如果為 “ 是 ” ，則向服務(wù)器發(fā)送加載該映像文件的請(qǐng)求。 首先，服務(wù)器會(huì)依據(jù)該用戶的用戶名對(duì)數(shù)據(jù)庫(kù)表 userFileTable執(zhí)行一個(gè) SQL查詢語(yǔ)句，查詢結(jié)果即為該用戶在服務(wù)器端存放的所有映像文件的相關(guān)信息，包括文件所有者、映像文件名、映像文件大小、屬性、是否自動(dòng)加載。 通過(guò)掛接系統(tǒng)鍵盤鉤子，即可完成對(duì)屏幕打印鍵的 控制 。 Win32系統(tǒng)會(huì)為鉤子建立一個(gè)鉤子鏈 (HookChain),一個(gè)鉤子鏈實(shí)際上是一個(gè)指針 第 24 頁(yè) 共 71 頁(yè) 列表 ， 其指針指向鉤子的各個(gè)處理函數(shù) ， 這些函數(shù)是一種特殊的回調(diào)函數(shù)。 屏幕拷貝 控制 屏幕拷貝主要通過(guò)對(duì)用戶鍵盤操作進(jìn)行控制完成，一方面禁用屏幕拷貝按鈕，另外 一方面禁止具有屏幕拷貝功能的進(jìn)程出現(xiàn)。為了實(shí)現(xiàn)上述功能 ， Windows提供了存放于 USER32. dll中的一組 API函數(shù)、消息和預(yù)定義數(shù)據(jù)格式等 ， 并通過(guò)對(duì)這些函數(shù)、消息的使用來(lái)管理在進(jìn)程間進(jìn)行的剪貼板數(shù)據(jù)交換。 Windows剪貼板是一種開(kāi)銷比較小的 IPC(InterProcess Communication,進(jìn)程間通訊 )機(jī)制。其關(guān)鍵技術(shù)是對(duì)剪貼板的監(jiān)控。這時(shí)鉤子函數(shù)既可以加工處理 （ 改變 ） 該消息 ， 也可以不進(jìn)行處理而繼續(xù)傳遞該消息 ， 還可以強(qiáng)制結(jié)束消息的傳遞。鉤子函數(shù)可以監(jiān)視指定窗口的某種消息 ， 而且所監(jiān)視的窗口可以是其他進(jìn)程所創(chuàng)建的。 鉤子實(shí)際上是一段用來(lái)處理系統(tǒng)消息的程序 ， 通過(guò)系統(tǒng)調(diào)用 ， 將其掛入到系統(tǒng) ，它是 Windows的消息處理機(jī)制中的一個(gè)監(jiān)視點(diǎn)。 頁(yè)面保存與打印控制 對(duì)于業(yè)務(wù)上的文檔，大部分為 word文檔和 pdf文檔，因此對(duì)這兩種主流文檔的保 第 23 頁(yè) 共 71 頁(yè) 存和打印控制是非常必要的。二是操作環(huán)境的記錄與跟蹤審計(jì)。 DLL 注入技術(shù) 本系統(tǒng)還為 移動(dòng)辦公提供了支持。 如果一個(gè)塊發(fā)生損壞或機(jī)器故障，系統(tǒng)會(huì)在其他地方讀取另一個(gè)副本，并將此副本復(fù)制一份，通過(guò)查看文件塊分配索引表，根據(jù)負(fù)載均衡原則，將新的副本存放在選定的數(shù)據(jù)結(jié)點(diǎn)上，以保證副本的數(shù)量回到正常水平，這個(gè)過(guò)程 對(duì)用戶是完全透明的。 為了恢復(fù) 損壞的塊以及 應(yīng)對(duì) 磁盤或機(jī)器的故障，每個(gè)塊都將自己 的另外兩個(gè)副本放在其它數(shù)據(jù)結(jié)點(diǎn)上，并保證副本數(shù)目的恒定。 圖 38 文件分塊存儲(chǔ)索引 上圖 38是 NameNode上文件分塊存儲(chǔ)索引。由于本系統(tǒng)采用虛擬磁盤技術(shù)，每個(gè)映像文件都是加密后的密文，因而可以保證數(shù)據(jù)的保密性。文件的分塊不需要存儲(chǔ)在同一個(gè)磁盤上，因此它們可以利用集群上的任意一個(gè)磁盤。 在分布式文件系統(tǒng)中使用抽象塊會(huì)帶來(lái)很多好處。 容災(zāi)備份技術(shù) HDFS文件塊的概念 與普通的文件系統(tǒng)中分塊的概念基本相同 ，不過(guò)是更大的單元，默認(rèn)為 64 MB，這樣的一個(gè)好處是減少尋址時(shí)間開(kāi)銷。 但是，二級(jí)名稱節(jié)點(diǎn)的狀態(tài)是比主節(jié)點(diǎn)滯后的，所以主節(jié)點(diǎn)的數(shù)據(jù)若 全部丟失，損失仍在所難免。 該 節(jié)點(diǎn)一般在其他單獨(dú)的物理計(jì)算機(jī)上運(yùn)行，因?yàn)樗残枰加么罅?CPU和內(nèi)存來(lái)執(zhí)行合并操作。 對(duì)于二級(jí)名稱節(jié)點(diǎn)，其 不能作為名稱節(jié)點(diǎn)使用。 17. } 18. } 容崩自檢機(jī)制 沒(méi)有名稱節(jié)點(diǎn)，文件系統(tǒng)將無(wú)法使用 。 13. } 14. })。 9. FileSystem fs = ((dst), conf)。 5. InputStream in = new BufferedInputStream(new FileInputStream(localSrc))。 文件寫入剖析如圖37： 圖 37 文件寫入剖析 在 eclipse 中， 實(shí)現(xiàn)將本地文件復(fù)制到 Hadoop 文件系統(tǒng) (HDFS)并顯示進(jìn)度 : 1. public class FileCopyWithProgress { 2. public static void main(String[] args) throws Exception { 3. String localSrc = args[0]。云終端通過(guò)調(diào)用 Create向 NameNode發(fā)送請(qǐng)求，然后通過(guò) FSDataOutputStream數(shù)據(jù)流進(jìn)行文件寫入，數(shù)據(jù)將分塊存儲(chǔ)在各個(gè)數(shù)據(jù)結(jié)點(diǎn)上。因此，云終端與云端進(jìn)行通信時(shí)，終端 HDFS開(kāi)始分布式計(jì)算，向名稱結(jié)點(diǎn) NameNode請(qǐng)求并獲得數(shù)據(jù)分塊位置，終端通過(guò)讀取 FSDataInputStream數(shù)據(jù)流，從各個(gè)數(shù)據(jù)結(jié)點(diǎn)上分別讀取數(shù)據(jù)塊并在終端進(jìn)行合并，最后關(guān)閉管道，結(jié)束本次讀取。它們存儲(chǔ)并提供定位塊的服務(wù) (被用戶或名稱節(jié)點(diǎn)調(diào)用時(shí) )，并且定時(shí)的向名稱節(jié)點(diǎn)發(fā)送它們存儲(chǔ)的塊的列表。 第 19 頁(yè) 共 71 頁(yè) 圖 35 HDFS結(jié)構(gòu)圖 客戶端代表用戶通過(guò)與名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)交互來(lái)訪問(wèn)整個(gè)文件系統(tǒng) ， 如圖 35。這些信息以兩種形式將文件永久保存在本地磁盤上：命名空間鏡像和編輯日志。 HDFS集群有兩種節(jié)點(diǎn)，以管理者 工作者的模式運(yùn)行，即一個(gè)名稱節(jié)點(diǎn) （ 管理者 ）和多個(gè)數(shù)據(jù)節(jié)點(diǎn) （ 工作者 ） 。一個(gè)數(shù)據(jù)集通常由數(shù)據(jù)源生成或復(fù)制，接著在此基礎(chǔ)上進(jìn)行各種各樣的分析。 HDFS HDFS是為以流式數(shù)據(jù)訪問(wèn)模式存儲(chǔ)超大文件而設(shè)計(jì)的文件系統(tǒng)，在較低配置要求硬件的集群上運(yùn)行。對(duì)于大多數(shù)作業(yè)，一個(gè)理想的分片大小往往是一個(gè) HDFS塊的大小，默認(rèn)是 64 MB. map任務(wù)的執(zhí)行節(jié)點(diǎn)和輸入數(shù)據(jù)的存儲(chǔ)節(jié)點(diǎn)是同一節(jié)點(diǎn)， Hadoop的性能達(dá)到最佳。即使是相同的機(jī)器，沒(méi)有處理的或其他同時(shí)運(yùn)行的作業(yè)也會(huì)使負(fù)載平衡得以實(shí)現(xiàn)，并且在分片變得更細(xì)時(shí)，負(fù)載平衡質(zhì)量也會(huì)更佳。 擁有許多分片就意味著處理每個(gè)分片的時(shí)間與處理整個(gè)輸入的時(shí)間相比是比較小的。如果其中一個(gè)任務(wù)失敗， jobtracker 可 以 重 新 調(diào) 度 任 務(wù) 到 另 外 一 個(gè) MapReduce,稱為輸入分片 第 18 頁(yè) 共 71 頁(yè) (input split)或分片。 jobtracker通過(guò)調(diào)度任務(wù)在 tasktracker上運(yùn)行，來(lái)協(xié)調(diào)所有運(yùn)行在系統(tǒng)上的作業(yè)。 Hadoop通過(guò)把作業(yè)分成若干個(gè)小任務(wù) (task)來(lái)工作，其包括兩種類型的任務(wù)： map任務(wù)和 reduce任務(wù)。這使得企業(yè)能夠?qū)①Y源切換到需要的應(yīng)用上，根據(jù)需求訪問(wèn)計(jì)算機(jī)和存儲(chǔ)系統(tǒng)。 第 17 頁(yè) 共 71 頁(yè) 圖 34 透明加解密過(guò)程 云平臺(tái) 管理 技術(shù) 云計(jì)算簡(jiǎn)介 云計(jì)算 (Cloud Computing)是分布式處理 (Distributed Computing)、并行處理 (Parallel Computing)和網(wǎng)格計(jì)算 (Grid Computing)的發(fā)展，或者說(shuō)是這些計(jì)算機(jī)科學(xué)概念的商業(yè)實(shí)現(xiàn)。 用戶進(jìn)行讀寫操作后， IO 管理器根據(jù)用戶操作生成文件讀寫操作指針 IRP， IRP 傳遞到驅(qū)動(dòng)程序，執(zhí)行指定的派遣函數(shù)。 驅(qū)動(dòng)級(jí)透明加密技術(shù)基于 windows 的文件系統(tǒng)（過(guò)濾）驅(qū)動(dòng)（ IFS）技術(shù)，由于工作在受 windows 保護(hù)的內(nèi)核層， 運(yùn)行速度更快，加解密操作更穩(wěn)定。 由于 本系統(tǒng)的加解密是在驅(qū)動(dòng)級(jí)上實(shí)現(xiàn)的，在每次讀寫文件時(shí)自動(dòng)使用特定的密鑰進(jìn)行加解密，對(duì)用戶完全透明。 加解密采用 分組長(zhǎng)度 128 位 的 AES 加密算法。 該系統(tǒng)在不改變用戶使用習(xí)慣、計(jì)算機(jī)文件格式和應(yīng)用程序的情況下，采取“驅(qū)動(dòng)級(jí)透明動(dòng)態(tài)加解密技術(shù)”，對(duì)指定類型的文件進(jìn)行實(shí)時(shí)、強(qiáng)制、透明的加解密。一旦密鑰丟失，用戶文件可能永遠(yuǎn)無(wú)法取回了。 第 16 頁(yè) 共 71 頁(yè) 文件過(guò)濾驅(qū) 動(dòng) 技術(shù) —— AES 透明加密 傳統(tǒng)的加解密軟件的幾個(gè)弊端： ? 每次加解密都需要用戶手動(dòng)輸入密鑰，過(guò)程較為麻煩。 2) 應(yīng)用層源碼分析 mount 調(diào)用 DefineDosDevice在應(yīng)用層創(chuàng)建一個(gè)指向設(shè)備命名空間的符號(hào)鏈接，用CreateFile 打開(kāi)此鏈接，然后調(diào)用 DeviceIoControl ，控制碼是IOCTL_FILE_DISK_OPEN_FILE，內(nèi)核程序響應(yīng)后，執(zhí)行真正打開(kāi)源映像文件的操作。 如： IOCTL_DISK_GET_DRIVE_GEOMETRY，IOCTL_CDROM_GET_DRIVE_GEOMETRY。 （ 2） IOCTL_FILE_DISK_CLOSE_FILE：將 IO包插入隊(duì)列，設(shè)置對(duì)象為有信號(hào)。 第 15 頁(yè) 共 71 頁(yè) FileDiskReadWrite：將 IO包插入隊(duì)列，然后調(diào)用 KeSetEvent函數(shù)，激活事件對(duì)象；對(duì)應(yīng) Read， Write操作。 FileDiskCloseFile：調(diào)用 ZwClose關(guān)閉文件。 （ 2） IOCTL_FILE_DISK_CLOSE_FILE：調(diào)用 FileDiskCloseFile。 FileDiskThread 首先調(diào)用 KeSetPriorityThread更改自身線程的優(yōu)先級(jí)為L(zhǎng)OW_REALTIME_PRIORITY，然 后開(kāi)始 for(。 } 主函數(shù)入口；備份 傳入路徑，查詢注冊(cè)表值，調(diào)用 ZwCreateDirectoryObject創(chuàng)建設(shè)備目錄，重復(fù) 4次調(diào)用 FileDiskCreateDevice創(chuàng)建設(shè)備，初始化操作函數(shù)指針。 return status。 if (NT_SUCCESS(status)) { n_created_devices++。 n n_devices。 if (NT_SUCCESS(status)) { n_created_devices++。 n n_devices。 } ZwMakeTemporaryObject(dir_handle)。object_attributes )。 status