一、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資源佔用較高，影響裝置對連線的處理能力。