一、Saas的安全性設計

一般常見的安全性設計分為兩類：系統級和程序級。

系統級：

1、使用HTTPS協議以SSL（Security Socket Layer）交換數據，增強通信安全；

2、 通過數字簽名防止傳輸過程篡改；

3、 對用戶身份識別的UserToken使用DES算法數據加密；

4、業務數據定時自動備份；

程序集：

1、 完整的權限配置，包括功能權限和數據權限；

2、 客戶端輸入校驗，防止JS攻擊、XSS攻擊、SQL注入等；

3、 輔助安全設計，比如密碼控件、圖片驗證碼、手機確認碼等；

安全性

安全壓倒一切。大多數用戶只是問問SaaS廠商是不是采用了安全套接層（SSL）技術，而安全性涵蓋的不僅僅只有這個方面。要向潛在的SaaS廠商詢問下列問題：

●放置服務器的數據中心有沒有24×7全天候的物理安全措施？

●數據中心有沒有得到保護（保安是不是24小時在周圍至少巡視一次）？

●誰有權訪問這些服務器（只有內部員工可以訪問，還是承包商也可以訪問？）

●有沒有日志記錄誰何時進入、何時離開？如果有日志，那么隔多長時間審計這些日志？ ●應用程序有沒有使用基于行業標準的128位加密技術？

●如果多個客戶使用的應用程序放在同一臺服務器上，那么它們有沒有采用邏輯或物理分隔，從而確保你的數據不被未授權的人所看到？

●SaaS廠商中可以訪問你企業數據的工作人員有沒有經過犯罪背景調查？知道被定罪的重罪犯是不能訪問你企業那些敏感的個人數據，這很重要。

●廠商有沒有正規的業務連續性方案（BCP）？對方愿不愿意與你共享該方案、它能消除你的擔憂嗎？

二、SaaS Multi-Tenant在數據存儲上存在三種主要的方案

（1） 方案一：獨立數據庫

這是第一種方案，即一個Tenant一個Database（見圖3-14），這種方案的用戶數據隔離級別最高，安全性最好，但成本也高。

優點：

為不同的租戶提供獨立的數據庫，有助于簡化數據模型的擴展設計，滿足不同租戶的獨特需求； 如果出現故障，恢復數據比較簡單。 缺點：

增大了數據庫的安裝數量，隨之帶來維護成本和購置成本的增加。

這種方案與傳統的一個客戶、一套數據、一套部署類似，差別只在于軟件統一部署在運營商那里。如果面對的是銀行、醫院等需要非常高數據隔離級別的租戶，可以選擇這種模式，提高租用的定價。如果定價較低，產品走低價路線，這種方案一般對運營商來說是無法承受的。

（2） 方案二：共享數據庫，隔離數據架構

這是第二種方案，即多個或所有租戶共享Database，但一個Tenant一個Schema。 優點：

為安全性要求較高的租戶提供了一定程度的邏輯數據隔離，并不是完全隔離； 每個數據庫可以支持更多的租戶數量。 缺點：

如果出現故障，數據恢復比較困難，因為恢復數據庫將牽扯到其他租戶的數據； 如果需要跨租戶統計數據，存在一定困難。

（3） 方案三：共享數據庫，共享數據架構

這是第三種方案，即租戶共享同一個Database、同一個Schema，但在表中通過TenantID區分租戶的數據。這是共享程度最高、隔離級別最低的模式。

優點：

三種方案比較，第三種方案的維護和購置成本最低，允許每個數據庫支持的租戶數量最多。

缺點：

隔離級別最低，安全性最低，需要在設計開發時加大對安全的開發量； 數據備份和恢復最困難，需要逐表逐條備份和還原。

如果希望以最少的服務器為最多的租戶提供服務，并且租戶接受以犧牲隔離級別換取降低成本，這種方案最適合。

三、數據庫層性能優化 建立合適的索引

1、索引應該創建在條件（where）、排序（order by）、分組（group by）等操作所涉及的列上；

2、 索引應該有較強的選擇性，即應盡可能建立在重復數據少的數據列中；

3、 如果多個條件經常需要組合起來查詢，應合理使用聯合索引；

4、一次查詢中只能使用一個索引，可使用相應的分析工具分析索引效果；

5、 索引不是越多越好（一個表最好在5個索引以內），過多的索引可能導致CUD（新增、修改、刪除）的性能降低，并且占用更多的空間。

四、應用層性能優化：Cache

其實很難說Cache就是應用層性能的優化策略。因為大部分情況下，Cache所緩存的內容就是數據庫中存儲的內容。采用Cache策略其實也是對數據庫層的一種優化，因為其避免了對于數據庫的頻繁訪問。 MemCached和JBoss Cache應該是兩類比較典型的Cache。

五、日志記錄

日志記錄就是要對用戶在系統中的操作行為和操作的數據等進行記錄，以便對用戶在系統中的操作進行查證，以保證用戶行為是不可偽造的、不可銷毀的、不可否認的。也就是說，用戶在系統中的行為是有據可查的，不能在系統中偽造自己的行為，或者偽造其他用戶的行為；同時，用戶是不能銷毀這些證據的，不能否認自己的行為。 日志記錄具體包括兩部分：行為日志記錄和數據日志記錄。

（1） 行為日志記錄

行為日志記錄就是要對用戶在系統中所訪問的每一個頁面，在各頁面中所做的每一個行為都記錄下來，記錄用戶的身份和行為的時刻。

例如，租戶A的用戶A1在2011年7月13日 17:07:50訪問了XXX系統的重要客戶列表頁面，做了刪除客戶信息的操作。

行為日志記錄的實現，可以采用面向方法的方案來實現，例如，通過過濾器或攔截器的方式（Spring前置裝備），來對所有的頁面請求行為及頁面里的提交行為多進行攔截，然后將其記錄在日志文件里或數據庫里。行為日志記錄是辨別用戶在系統中行為的一個重要依據，對于系統使用與系統運營分開的SaaS系統就顯得尤為重要。

（2） 數據日志記錄

數據日志記錄，就是要對用戶在系統中所操作的數據進行記錄，記錄數據的變更過程及變更的歷史。這在多人操作同一個數據的系統中顯得尤為重要。可以通過流程引擎記錄流程日志。

例如，用戶A在財務系統中提交了一張財務報銷單，報銷金額是1000元，在經過了用戶B、C、D等一系列人的修改和審批后，用戶A看到的報銷金額變成了500元，如果沒有報銷金額的變更日志記錄，用戶A一定會很疑惑，是誰因為什么原因修改了這個報銷金額。

那么，系統就很有必要對報銷金額的變更進行日志記錄。

（3） 日志記錄的安全

日志記錄是對用戶在系統中行為進行查證的依據，是用來跟蹤和保障系統安全的，那么，日志記錄本身的安全性也是需要重點考慮的。

首先，日志記錄應該是只讀的，最好能加上時間戳，不應該被認為修改或者偽造；其次，日志記錄涉及用戶的隱私，應該是保密的，要防止被非法使用。

租戶的日志只向Tenant管理員開發，并且Tenant管理員也只能查詢租戶自己的日志。

六、數據加密算法（會犧牲一定性能）

1、 使用AES對稱加密算法；

2、 每個企業生成一個數據密鑰（生成后不能改變，否則先前加密過的數據無法進行解密）；

3、 企業key是利用企業管理員的密碼明文去加密存儲的，這就要求每個企業在建立時，必須先建立一個管理

員；

4、 該企業下的每個用戶使用其自身的登錄密碼原文對數據密碼進行AES加密，并存儲到用戶表中。（密鑰加

密）；

5、 用戶保存敏感數據時，使用以準備好的密鑰對數據進行AES加密；

加/解密過程：

1、 企業注冊時，為企業生成一個唯一的key，存放于企業表中；

2、 用戶注冊后，用戶表中存放一個利用用戶密碼明文加密過的企業key；

3、 用戶登錄后，通過密碼明文，解密出企業key，并存放到相應位置，待加/解密時使用；

4、 用戶修改密碼時，要使用原密碼將企業key解密，并用新密碼重新加密保存；

七、基于SaaS云計算網絡性能測試指標

衡量云計算的網絡性能根據使用的網絡設備不同擁有很多指標。最常見最關鍵的性能指標包括以下幾項：新建速率（CPS）、并發數（CC）吞吐量（GoodPut）、響應時間（Response Time）。

（1） 新建速率

新建速率指通過數據中心中間網絡每秒可以處理的TCP Session速率，單位為CPS（Connections Per Second）。 新建速率中的“新建”是指一個TCP Session成功建立并關閉的整個過程，將TCP關閉方式選擇使用TCP FIN報文觸發的4次握手關閉方式。此種方式最符合當前普遍的網絡協議應用模型。在部分特殊業務需求的測試場景下，還可以采用TCP RESET方式進行快速會話關閉，以檢驗網絡系統能夠支持的極限性能。

新建速率指標將主要體現數據中心網絡設備的CPU運算處理能力。對新建速率測試開始前，應記錄網絡處理設備的CPU/Memory等關鍵性能指標，測試過程中和結束后對這些指標進行監控，實時了解整個網絡的運行情況。

（2） 并發數

并發數指通過數據中心中間網絡可以同時并發存在的最大TCP Session數量，單位為CC（Current Connections）。 并發數指標體現了整網會話保持與表項存儲的能力，與網絡處理設備的內存大小有直接關系。

對于并發數指標測試來說，尤其需要關注其上層協議的具體應用，一個Telnet連接保持1小時與一個http連接保持1小時在協議處理流程上是有很大不同的，應盡量根據實際網絡中的業務流量設計測試模型。

（3） 吞吐量

吞吐量指當前網絡可以有效傳輸的最大http數據量，也被稱為有效吞吐GoodPut，區別于傳統意義上的測試指標吞吐量ThroughPut，結果單位為BPS（Byte Per Second）。

吞吐量指標除了受新建速率的直接影響外，還會受到網絡中各設備的交換架構、接口總線等元件單位間處理能力的限制，也直接體現了整個網絡的應用數據吞吐轉發能力。

吞吐量測試結果很大程度上依賴于新建速率能力，其間關系類似于傳統吞吐量BPS（Bit Per Second）與網絡設備包轉發能力PPS（Packets Per Second）之間的關系。在測試吞吐量的過程中，首先測得網絡的新建速率，然后將新建速率測試結果乘以一定比率系數，作為吞吐量測試中使用的的穩定新建速率參數始終不變，測試時逐步提高HTTP有效載荷大小，通過觀察出現HTTP連接出現失敗前的有效載荷最大傳輸速率，得到其吞吐量測試結果。

（4） 響應時間

響應時間指從客戶端發起http請求，到得到正確數據響應所經歷的時間，一般用來衡量中間網絡的綜合處理能力，單位為毫秒。

響應時間指標測試方法主要有兩種：一種是基于真實服務器的業務響應時間測試，此測試結果包含了中間網絡設備與服務器兩部分處理延遲時間；另一種是通過測試儀模擬服務器快速響應請求的測試，這種測試方法可以盡量減少服務器端處理延遲的影響，得到近乎純粹的網絡處理延遲時間。

響應時間測試要在一定的新建速率下進行，這樣做也是為了盡量貼近實際網絡情況。但此測試中的新建速率需要維持在一個較低的水平線上，最好是根據真實環境平均值設定，這是因為新建速率較高時會導致CPU資源占用較高，影響設備對連接的處理能力。