April 26 08:38~10:10
四月初的時候介紹了「Quality Attribute Scenarios(9):Security」,趁著四月還沒結束趕快把Security General Scenarios一併寫完,不然時間越拖越久就越懶得寫。翻開課本第86-88頁。
元素 | 可能的內容 |
Source | 個人或系統:已被正確辨識、未被正確辨識、未知身分 身分:內部或外部,授權或未授權 存取:有限的資源或大量的資源 |
Stimulus | 嘗試要:顯示資料、改變或刪除資料、存取系統服務、降低系統服務的可用性(阻斷系統服務) |
Artifact | 系統服務、系統內的資料 |
Environment | 線上或離線、連線或非連線、在防火牆內或在防火牆外 |
Response | 授權使用者;隱藏使用者的身分辨識資料;阻斷對資料或服務的存取動作;允許對資料或服務的存取動作;賦予或取消對資料或服務存取權限;記錄使用者對於資料或服務的存取、修改、刪除等動作;將資料儲存成無法直接讀取的格式;偵測出大量且無法解釋的使用服務之要求,並通知使用者或其他系統,然後限制對此服務的可用性 |
Response Measure | 成功規避安全措施所需花費的時間、工夫、資源;偵測出發動攻擊者的身分的可能性;在DoS攻擊之下,系統還有多少百分比的服務可以正常運作;是否有能力回復被篡改的資料或是服務;資料或服務受損害的程度;正常取存資料或服務被阻斷的程度 |
有了上面這個Security General Scenario Generation表格,鄉民們就可以替自己的軟體架構定義出很多個security QAS。接下來請看幾個例子:
Quality Attribute | Source | Stimulus | Artifact | Environment | Response | Response Measure |
Security | 外部合法使用者 | 連續訂一千張火車票 | 系統訂票服務 | 線上,在防火牆內 | 記錄使用者IP;阻斷該使用者對訂票服務的存取;通知系統管理者以便報警處裡 | 其他正常訂票的使用者不能被影響;惡意大量訂票者無法成功訂票 |
Security | 內部系統維護人員 | 讀取客戶的個人資料,包含電話與信用卡資料等 | 系統資料庫 | 線上,在防火牆內 | 記錄內部使用者登入系統的時間與對資料庫所做的所有動作,將客戶資料經編碼後存放於資料庫中;所有讀取客戶資料的動作都需要通知上層主管 | 編碼後的客戶資料若被竊取,竊取者以一台Intel i7等級的電腦採用暴力法破解,至少需要20年以上才可能成功 |
Security | 外部非法駭客 | 送出大量封包 | 系統服務 | 線上,在防火牆內 | 記錄使用者IP;阻斷該IP所送出的所有封包;通知系統管理者 | 在DoS攻擊之下,所有系統服務都必須正常運作,且系統的反應時間不可低於正常狀況的40%。 |
Security | 外部非法駭客 | 破解系統密碼後遠端登入系統 | 系統資料庫 | 線上,在防火牆內 | 記錄使用者在系統內的所有操作 | 必須有能力回復被刪除的資料 |
以上就是security QAS的內涵以及幾個簡單的範例。當寫出系統的security QAS之後,軟體架構師或是開發人員可能會發現要實作安全性的系統其實成本還滿高的,但是如果不把這些項目逐一列出,就很難評估這些成本。這就好像買汽車的時候,有些車只給兩顆,有些卻搭配了六顆以上。當使用者把「安全性」這個非功能需求給列出來,才會發現有些產品比較貴是有它貴的道理。安全性越高通常也代表著產品的價格越貴(不管是硬體還是軟體都是一樣的道理),汽車商可以用「安全氣囊個數」、「鋼板厚度」、「耐撞測試報告」等資料來說服購車者。那麼軟體勒?當你的客戶需要高安全性的軟體系統時,列出security QAS不失為一種好方法。
***
友藏內心獨白:這一系列的文章好硬,寫的人好累…Orz。
沒有留言:
張貼留言