Information Security Fundamentals and Practices 資訊安全概論與實務

第四篇第16章 資訊技術服務管理

ITIL 的觀念 • 把使用資訊技術的單位當作客戶。 • 資訊服務的提供者 (如資訊部) 在組織裡常被視為支援單位，與資訊技術使用者 (如業務部或財務部) 之間是平行的同事關係。但 ITIL 要資訊服務提供者把資訊技術使用者當作「客戶」。 • 不能只從技術的角度看資訊服務。 • 技術當然是資訊服務不可或缺的基礎。但為了真正地做好資訊服務，ITIL 更強調組織、流程、人員和訓練等管理層面的努力。 • 強調全程服務的觀念。 • 資訊技術的使用單位經常無法自行提出資訊服務的明確需求，因此資訊部門應當協助規劃。使用者只需要感受到資訊服務的可用性，至於複雜的資訊技術及基礎架構都是資訊部門自己應該掌握的事。

預期的成果

ITIL 基本架構 • ITIL 將資訊技術服務管理分為以下兩個部份： • 服務施行 (service delivery) • 對象是「客戶」，例如財務部。資訊部以下列之管理程序定義單位對單位的資訊服務。 • 服務支援 (service support) • 對象是「使用者」，例如財務專員。下列之管理程序定義處理問題的流程。 • 服務台不算一個管理程序，它是提供服務的單一窗口。資訊安全管理

服務施行 服務水準管理 (I) • 服務水準管理 (service level management, SLM) 是資訊服務的總管流程，包括以下主要成分： • 服務目錄 (service catalogue) 是服務水準管理的基礎，它定義資訊單位提供的每項服務，包括服務細項、服務限制與服務績效評估方法。 • 服務水準協議 (service level agreement, SLA) 定義資訊服務提供者與客戶之間的關係。它描述客戶所接受的產品或服務、雙方的責任、財務協議、和績效的量測與報告。 • 作業層協議 (operational level agreement, OLA) 定義內部各支援單位如何協力支援一個 SLA。它描述內部各單位間彼此的責任，包括提供技術服務的流程與時間表。 • 支持契約 (underpinning contracts, UC)定義外部供應商對資訊單位所提供的服務。 • 財務管理 • 容量管理服務水準管理 • 可用性管理 • 持續性管理

服務水準管理 (II) • 資訊服務提供者 (資訊部) 與客戶 (財務部與業務部) 訂定 SLA，它需要內部各組的 OLA 和外部供應商的 UC 來支持。 • 例如資訊部在服務目錄中說明，同時在與業務部的 SLA 中承諾：公司的電子商務系統全年不得中斷超過三次，且每次中斷要在三小時內恢復。這個承諾需要電信業者的 UC 來支持，也需要網路組與應用系統組在 OLA 內做對應的承諾。供應商 A 供應商 B UC UC OLA 網路組應用系統組 OLA OLA 教育訓練組行政管理組 OLA 資訊部 SLA SLA 財務部業務部

服務施行 財務管理 • 服務水準管理 • 財務管理 (financial management) 是透過一套大家可以接受的模型，來訂立成本歸屬與分攤原則，用以計算資訊服務的價格。它包括以下幾個不同層面： • 預算 (budgeting)：資訊部門必須做短期和長期的預算以維持與增進資訊技術服務。 • 資訊技術會計 (IT accounting)：資訊部門需要進行成本分析，而且各項支出應經過批准並維持在預算內。 • 計費 (chargeback)：對使用資訊服務的客戶要有計費方式。在絕大多數的組織內，資訊單位不會真的向各單位「收費」，但 ITIL 透過計費，在成本和服務水準之間看到績效與進步的機會。 • 容量管理 • 可用性管理財務管理 • 持續性管理

服務施行 容量管理 (I) • 服務水準管理 • 容量管理 (capacity management) ：透過對目前和未來之容量與效能需求的收集分析，將資訊資源做最佳的運用，並保有適當的擴充彈性。 • 容量規劃人員要和業務、財務與服務支援部門共同建立年度基礎建設成長計畫 (infrastructure growth plan)，涵蓋的範圍包括網路頻寬、儲存伺服器容量、個人電腦數量等。 • 在開發應用程式時應儘早考慮容量需求，以期產品規格具備容量的成長彈性。例如公司要開發電子商務交易系統，應在規劃初期就考慮網路頻寬與資料庫延展性等問題。 • 財務管理 • 容量管理 • 可用性管理 • 持續性管理

容量管理 (II) • ITIL 將每一項資訊服務管理 (例如容量管理) 劃分為三個階層： • 戰略層 (strategic)：服務管理的長期目標與達到目標的高階活動。 • 戰術層 (tactical)：提供該項服務管理所需之程序，以程序引導工作與活動。 • 作業層 (operational)：程序的實際執行，以提供服務給客戶與終端使用者。 • 依據以上三個層面，容量管理也被劃分為： • 業務 (business) 容量管理：考量組織的業務在未來的需求與成長，以及會如何影響 SLA 與基礎建設的資源需求。 • 服務 (service) 容量管理：從組織的角度考量應用與業務的流程；檢視資源需求趨勢與週期，以確保服務可以滿足SLA。 • 資源 (resource) 容量管理：從個別的基礎建設元件 (如網路頻寬) 考量資源的需求。

服務施行 可用性與持續性管理 • 服務水準管理 • 可用性管理 (availability management) 是從耐用度、到維護、到維修、到備援、到服務可用性的不同層次來確保正常服務的提供。 • 持續性管理 (continuity management) 是針對資訊技術所面臨的各種災難式威脅加以分析並準備因應措施，確保整體企業的延續。 • 這兩個服務管理有某些同質性與關聯性。ITIL 把它們分開討論，但 ISO20000 則將兩者合併。 • 這(兩)個領域檢視業務對資訊系統可用性的需求，並確保緊急應變計畫完整且按時接受測試。 • 較高的可用性與持續性通常需要較高的成本，因此它們與服務水準、財務及容量管理都有關係。 • 財務管理 • 容量管理可用性管理持續性管理

資訊服務的惡性循環

服務支援

服務支援 服務台 • ITIL 裡的服務台 (service desk) 不是一個管理程序；它是一項與每個服務支援程序都有關的「功能」。 • 服務台是所有資訊服務對外的單點接觸 (single point of contact)，也就是資訊部門的門面。服務台的表現直接影響客戶對資訊服務的整體評價。 • 使用者對資訊服務提供者所提出的需求都從服務台開始；若這個需求需要更多的內部資源，也由服務台轉送。服務台可以降低資訊部門受干擾的機會。服務台 • 問題管理 • 事件管理 • 變更管理 • 釋出管理 • 組態管理

服務支援 事件管理 • 服務台 • 事件管理 (incident management) 對事件的處理原則是透過暫行方式讓使用者能繼續工作。目的是儘速回復到服務水準以避免資訊服務中斷太久。 • 在事件管理這個程序我們不看造成服務中斷的根本成因 (root cause)，只快速排除眼前的事件。 • 例如有位業務經理將一台常為不明原因當機的筆記型電腦送到資訊部的服務台，依事件管理程序，服務台可以協助該經理將重要資料複製到一台臨時筆記型電腦，供他繼續使用；再將問題電腦轉給技術人員設法修復。 • 在推動資訊科技服務管理時，事件管理與服務台常是優先建置的程序。一來它們的實施方法比較簡單；二來客戶最容易感受到服務的明顯進步。 • 問題管理事件管理 • 變更管理 • 釋出管理 • 組態管理

服務支援 問題管理 • 服務台 • 問題管理 (problem management) 在找出一個或多個事件的根本成因；從這裡我們開始看基礎建設發生服務中斷與品質不佳的問題。 • 例如郵件伺服器發生當機，我們儘快以事件管理程序重新開機以恢復伺服器運作。在檢視事件記錄後發現該伺服器一週內已經當機三次，於是我們啟動問題管理，並且記錄調查到的當機原因。 • 當找到「根本成因」之後，可能需要啟動變更管理。此外，要將事件的根本成因反饋給服務台，讓相同的事件在未來可以被快速、正確地處理。 • 在ITIL各個程序中，增強問題管理能力是報酬率最高的投資。 • 事件管理 • 變更管理問題管理 • 釋出管理 • 組態管理

服務支援 變更管理 • 服務台 • 變更管理 (change management) 是基礎建設或服務的任何部分在變更時的控制程序。由於程序受到控制，所以被核准的變更容易順利地執行。 • 變更管理的原則是變更的結果不會產生新事件。 • 變更管理與變更控制 (change control) 不同：變更控制使用在每一次的變更行動中；而變更管理則檢視所有受控制的變更，以確保基礎建設的穩定。 • 有兩組人同時對一台伺服器做變更，分別都控制得宜、變更成功。但事後發現兩個變更之間有衝突，導致系統失敗。這個例子裡的變更控制都成功；但變更管理卻失敗。變更管理程序應該要求兩個變更行為的事先協調。 • 事件管理 • 問題管理 • 釋出管理變更管理 • 組態管理

服務支援 釋出管理 • 服務台 • 釋出管理 (release management) 是在已決定變更之後負責成功地推出新版本。同時，被更新的項目需要透過組態管理留下記錄。 • 釋出管理是一個主要流程。它是經常性的活動，而不是只有在軟、硬體的大型推出時才去重視。 • 許多同仁使用公司新採購的筆記型電腦卻不能連結無線網路，服務台將重複發生的事件回報給問題管理經理。經研判根本成因是新電腦的無線網路卡與公司使用多年的基地台有不相容的現象，因此建議更新基地台。變更管理經理評估後同意變更，由釋出管理經理規畫與管理新基地台的推出，並通知組態管理經理更新組態管理資料庫內無線基地台的資料。 • 事件管理 • 問題管理 • 變更管理 • 組態管理釋出管理

服務支援 組態管理 • 服務台 • 組態管理 (configuration management) 經由識別、控制、維護與驗證組態項目 (configuration items) 的版本，來為基礎建設或服務提供邏輯模型。 • 簡單的說，組態管理經理對資訊基礎建設擁有一個清楚的描述。這個描述稱為「組態管理資料庫 (CMDB)」。 • CMDB 通常是經過設計的電腦資料庫，裡面儲存各種元件的版本、設定、參數及現狀，包括電腦、伺服器、網路連結等等，可能非常複雜。 • CMDB 裡的每個項目稱為一個「組態項目 (CI)」，當一個元件被變更時，它相對的 CI 就要經過組態管理做資料更新。因此，CMDB 隨時存有最新、最正確的基礎建設資訊。 • 事件管理 • 問題管理 • 變更管理 • 釋出管理組態管理

ISO20000 • ISO 20000 的全名是「資訊技術服務管理」(Information Technology – Service Management, ITSM)，它發表於2005年，是以英國標準協會的 BS15000 為基礎，而這些又都是從 ITIL 演進而來。 • ISO20000 分兩個部份： • 第一部分為「規格」也就是正式的標準，規定一個組織要符合標準並通過驗證所需要做的事。 • 第二部分是由基本要求所延伸的「實務準則」，主要描述在 ISO 20000 範圍內的服務管理最佳實務 (best practice)。 • ISO20000 與前面介紹的 ISO 27001 相同，也使用 PDCA 的方法論。從下一頁圖形 (參考 ISO 20000 標準) 我們可以看到左邊的輸入項目經過ITSM的PDCA循環產出右邊的輸出項目。組織的許多方面都會進步，包括業務、團隊、處理問題的流程、和與組織外部的互動。

ITSM 的 PDCA 業務需求業務結果客戶需求客戶滿意度新服務或變更服務需求新的或變更的服務其它程序，如供應商其它程序，如供應商服務台團隊及成員滿意度其他團隊如資安小組

ISO20000 的程序 服務施行程序容量管理服務水準管理資訊安全管理持續性與可用性管理管理服務報告資訊技術服務之預算與計價控制程序組態管理變更管理釋出程序關係程序解決程序釋出管理事件管理商業關係管理問題管理供應商管理

服務報告 • 服務報告 (service report) 的目的是經由正確、可靠的週期性報告，來進行決策與溝通。服務報告有效地協助服務水準管理：在訂定SLA之後，服務報告是客戶與服務提供者之間最佳的溝通、追蹤與測量的工具。 • 服務報告都要清楚地描述報告的性質、目的、對象與資料來源的細節；它應該包括： • 與服務水準目標的績效比較。 • 不符合SLA或安全規範的項目或是問題。 • 數量或是資源使用率等負載特性。 • 在重大事件或變更等大事發生後的績效報告。 • 週期性的 (每天、每週、每月或每期) 趨勢報告。 • 滿意度分析。

商業關係管理 • 對一個商業組織而言，與它關係最密切的外部組織有二：下游的「客戶 (customers)」與上游的「供應商 (suppliers)」。即使在組織內部，一個服務提供單位，如資訊部，也有這種上、下游關係需要管理。 • 商業關係管理 (business relationship management) 的目的在建立並維護服務提供者與客戶間的良好關係。以下是一些應有的作法： • 服務提供者與客戶應該至少一年有一次的服務審查會議，討論服務範圍、契約、績效與需求等。這些會議應有記錄。 • 服務提供者應該注意商業需求與重大變更，為正確的回應做準備。 • 應該建立申訴的流程，所有正式的服務申訴都應被記錄、調查、採取行動、提出報告並正式結案。 • 服務提供者應指定員工來管理客戶滿意度與商業關係。訂定程序來取得客戶反饋意見並採取修正行動，改善措施應被記錄並用以改進服務程序。

供應商管理 • 供應商管理 (supplier management) 是藉由管理供應商來確保自己能為客戶提供緊密而且高品質的服務。以下是一些應有的作法： • 服務提供者須要有文件化的供應商管理程序，每個供應商應由一位合約經理 (contract manager) 負責管理。 • 供應商所提供的服務也應有 SLA 清楚說明，並由雙方同意。與供應商的 SLA 應該要與客戶的 SLA 密切配合。 • 如果主要供應商底下還有下包商，那麼主要供應商與下包商的責任與關係應有明文規定。主要供應商需要有程序來確保下包商能符合合約要求。 • 應該至少一年有一次的審查會議來檢討合約或正式協議，以確保商業需求與合約義務依然吻合。與供應商之間應有處理合約爭議的程序。 • 應依據服務水準目標來監視並審查供應商的績效，經由這個過程所識別的改善措施應被記錄並用以改進服務程序。

資訊安全管理 (I) • 資訊安全管理 (information security management) 是在所有服務活動中有效的管理資訊安全。 • 我們在資訊安全課程的最後一章介紹 ITSM 有兩個主要原因： • 紊亂與隨機是資訊安全事件的溫床；最安全的系統是「管理完善」的系統。ITSM 全方位的管理資訊技術服務的各個面向，可以從根本來降低資訊安全管理的負擔。 • ISMS 從安全著眼看組織的資訊管理；而 ITSM 則從組織的資訊管理著眼看資訊安全在其中扮演的角色。前者為資訊安全管理提供詳細的做法；後者則為資訊安全管理提供更廣的角度。 • ISO 20000 明文說 ISO17799(與 ISO27001 對應的資訊安全管理之作業要點) 為資訊安全管理的指導，也就是說 ITSM 的資訊安全管理要求與ISMS 一致。已經通過 ISO 27001 驗證的組織在做 ISO 20000 驗證時，可以跳過資訊安全管理這一項。

資訊安全管理 (II) • ITSM 的資訊安全管理要求有適當位階的管理階層需要核可資訊安全政策；要在適當時機對所有相關人員及客戶宣導這個政策。 • ITSM 要求執行適當的安全控制來： • 執行資訊技術服務政策。 • 管理當使用服務或系統時的相關風險。 • 當要變更安全控制項目時，需要進行變更前評估。 • 針對使用我方資訊系統或服務的外部組織，若有任何安排牽涉到它們，都應該以正式的安全需求協議為基礎。 • ISMS 所討論有關資訊安全事件 (security incidents) 的通報與記錄，應該與 ITSM 的事件管理程序吻合。 • 應對資訊安全事件的種類、數量與衝擊進行量化的監視。這個過程所識別的改善措施應被記錄並用以改進服務程序。

資訊安全管理評量範例 • 與資訊安全有關的事件數量。 • 與資訊安全相關的問題被結案的數量。 • 稽核與管審會的缺失被解決的數量。 • 按時完成稽核與管審會的比率。 • 被識別的風險數量 (包括新威脅與警告項目) • SLA 內有說明資訊安全規格的百分比。 • UC 內有說明資訊安全規格的百分比。 • 資訊安全相關的補丁釋出速度。 • 因為資訊安全問題而取消變更的數量。 • 因為資訊安全問題而取消釋出的數量。

Information Security Fundamentals and Practices 資訊安全概論與實務