Transcript Ch16_資訊技術服務管理

潘天佑博士 主編
版權聲明：本教學投影片僅供教師授課講解使用，投影片內之圖片、文字及其相關內容，
未經著作權人許可，不得以任何形式或方法轉載使用。
第四篇 第16章
Information Security Fundamentals and Practices - 16
2
把使用資訊技術的單位當作客戶。


資訊服務的提供者 (如資訊部) 在組織裡常被視為支援單位，與資訊技術
使用者 (如業務部或財務部) 之間是平行的同事關係。但 ITIL 要資訊服務提
供者把資訊技術使用者當作「客戶」。
不能只從技術的角度看資訊服務。


技術當然是資訊服務不可或缺的基礎。但為了真正地做好資訊服務，ITIL
更強調組織、流程、人員和訓練等管理層面的努力。
強調全程服務的觀念。


資訊技術的使用單位經常無法自行提出資訊服務的明確需求，因此資訊
部門應當協助規劃。使用者只需要感受到資訊服務的可用性，至於複雜
的資訊技術及基礎架構都是資訊部門自己應該掌握的事。
Information Security Fundamentals and Practices - 16
3
傳統資訊服務
ITIL/ITSM 導入後
• 技術導向
• 流程導向
• 緊急救火
• 防範未然
• 被動地解決問題
• 主動地面對問題
• 服務使用者
• 把使用者當做客戶
• 一次次的解決問題
• 建立解決問題的制度
• 資訊部門內部的思維
• 整體業務的思維
• 以營運為重心
• 以服務為重心
• 主觀地認定績效
• 以客觀數據評量績效
Information Security Fundamentals and Practices - 16
4


ITIL 將資訊技術服務管理分為
以下兩個部份：
服務施行
服務施行 (service delivery)
服務水準管理
服務台
財務管理
事件管理
容量管理
問題管理
可用性管理
變更管理
持續性管理
釋出管理


對象是「客戶」，例如財務部。
資訊部以下列之管理程序定義
單位對單位的資訊服務。
服務支援 (service support)


對象是「使用者」，例如財務
專員。下列之管理程序定義處
理問題的流程。
服務台不算一個管理程序，它
是提供服務的單一窗口。
Information Security Fundamentals and Practices - 16
服務支援
資
訊
安
全
管
理
組態管理
5

服務水準管理 (service level management, SLM) 是資訊
服務的總管流程，包括以下主要成分：




服務目錄 (service catalogue) 是服務水準管理的基礎，它
定義資訊單位提供的每項服務，包括服務細項、服務限
制與服務績效評估方法。
服務水準協議 (service level agreement, SLA) 定義資訊服務
提供者與客戶之間的關係。它描述客戶所接受的產品或
服務、雙方的責任、財務協議、和績效的量測與報告。
作業層協議 (operational level agreement, OLA) 定義內部各
支援單位如何協力支援一個 SLA。它描述內部各單位間彼
此的責任，包括提供技術服務的流程與時間表。
支持契約 (underpinning contracts, UC)定義外部供應商對
資訊單位所提供的服務。
Information Security Fundamentals and Practices - 16
服務施行
服務水準管理
財務管理
容量管理
可用性管理
持續性管理
6
供應商 A

資訊服務提供者 (資訊部) 與客
戶 (財務部與業務部) 訂定
SLA，它需要內部各組的 OLA 和
外部供應商的 UC 來支持。

例如資訊部在服務目錄中說明，
同時在與業務部的 SLA 中承諾：
公司的電子商務系統全年不得中
斷超過三次，且每次中斷要在三
小時內恢復。這個承諾需要電信
業者的 UC 來支持，也需要網路
組與應用系統組在 OLA 內做對
應的承諾。
UC
UC
OLA
網路組
OLA
應用系
統組
OLA
教育訓
練組
OLA
行政管
理組
資訊部
SLA
財務部
Information Security Fundamentals and Practices - 16
供應商 B
SLA
業務部
7

財務管理 (financial management) 是透過一套大家可
以接受的模型，來訂立成本歸屬與分攤原則，用以
計算資訊服務的價格。它包括以下幾個不同層面：



預算 (budgeting)：資訊部門必須做短期和長期的預算以
維持與增進資訊技術服務。
資訊技術會計 (IT accounting)：資訊部門需要進行成本
分析，而且各項支出應經過批准並維持在預算內。
計費 (chargeback)：對使用資訊服務的客戶要有計費方
式。在絕大多數的組織內，資訊單位不會真的向各單位
「收費」，但 ITIL 透過計費，在成本和服務水準之間看
到績效與進步的機會。
服務施行
服務水準管理
財務管理
容量管理
可用性管理
持續性管理
Information Security Fundamentals and Practices - 16
8



容量管理 (capacity management) ：透過對目前和未
來之容量與效能需求的收集分析，將資訊資源做最
佳的運用，並保有適當的擴充彈性。
容量規劃人員要和業務、財務與服務支援部門共同
建立年度基礎建設成長計畫 (infrastructure growth
plan)，涵蓋的範圍包括網路頻寬、儲存伺服器容
量、個人電腦數量等。
在開發應用程式時應儘早考慮容量需求，以期產品
規格具備容量的成長彈性。例如公司要開發電子商
務交易系統，應在規劃初期就考慮網路頻寬與資料
庫延展性等問題。
Information Security Fundamentals and Practices - 16
服務施行
服務水準管理
財務管理
容量管理
可用性管理
持續性管理
9


ITIL 將每一項資訊服務管理 (例如容量管理) 劃分為三個階層：

戰略層 (strategic)：服務管理的長期目標與達到目標的高階活動。

戰術層 (tactical)：提供該項服務管理所需之程序，以程序引導工作與活動。

作業層 (operational)：程序的實際執行，以提供服務給客戶與終端使用者。
依據以上三個層面，容量管理也被劃分為：



業務 (business) 容量管理：考量組織的業務在未來的需求與成長，以及會如
何影響 SLA 與基礎建設的資源需求。
服務 (service) 容量管理：從組織的角度考量應用與業務的流程；檢視資源
需求趨勢與週期，以確保服務可以滿足SLA。
資源 (resource) 容量管理：從個別的基礎建設元件 (如網路頻寬) 考量資源的
需求。
Information Security Fundamentals and Practices - 16
10





可用性管理 (availability management) 是從耐用度、到
維護、到維修、到備援、到服務可用性的不同層次來
確保正常服務的提供。
持續性管理 (continuity management) 是針對資訊技術
所面臨的各種災難式威脅加以分析並準備因應措施，
確保整體企業的延續。
這兩個服務管理有某些同質性與關聯性。ITIL 把它們
分開討論，但 ISO 20000 則將兩者合併。
服務施行
服務水準管理
財務管理
容量管理
這(兩)個領域檢視業務對資訊系統可用性的需求，並
確保緊急應變計畫完整且按時接受測試。
可用性管理
較高的可用性與持續性通常需要較高的成本，因此它
們與服務水準、財務及容量管理都有關係。
持續性管理
Information Security Fundamentals and Practices - 16
11
組織的資訊系統
百病叢生
同仁沒有時間做前
每個支援需求都是
瞻性規劃或進修
緊急需求
資訊同仁不斷處理
重複發生的問題
Information Security Fundamentals and Practices - 16
12
服務台
事件管理
問題管理
變更管理
釋出管理
組態管理
• 累積標準的事件處理經驗與準則，以提高第一線
的事件解決率。
• 事件發生時的處理原則是盡快透過暫行方式讓使
用者能繼續工作。
• 追蹤分析事件的根本成因，並對已知的錯誤加以
控管。
• 為徹底解決問題，須對資訊基礎架構進行的變動
進行規劃與控管。
• 變更的內容要有充分的計畫與測試，確保變更的
有效性。
• 充分的掌握資訊基礎架構的項目、關係和狀態，
任何變更都有記錄。
Information Security Fundamentals and Practices - 16
13



ITIL 裡的服務台 (service desk) 不是一個管理程序；
它是一項與每個服務支援程序都有關的「功
能」。
服務台是所有資訊服務對外的單點接觸 (single
point of contact)，也就是資訊部門的門面。服務台
的表現直接影響客戶對資訊服務的整體評價。
使用者對資訊服務提供者所提出的需求都從服務
台開始；若這個需求需要更多的內部資源，也由
服務台轉送。服務台可以降低資訊部門受干擾的
機會。
服務支援
服務台
事件管理
問題管理
變更管理
釋出管理
組態管理
Information Security Fundamentals and Practices - 16
14


事件管理 (incident management) 對事件的處理原則
是透過暫行方式讓使用者能繼續工作。目的是儘速
回復到服務水準以避免資訊服務中斷太久。
在事件管理這個程序我們不看造成服務中斷的根本
成因 (root cause)，只快速排除眼前的事件。


例如有位業務經理將一台常為不明原因當機的筆記型電
腦送到資訊部的服務台，依事件管理程序，服務台可以
協助該經理將重要資料複製到一台臨時筆記型電腦，供
他繼續使用；再將問題電腦轉給技術人員設法修復。
在推動資訊科技服務管理時，事件管理與服務台常
是優先建置的程序。一來它們的實施方法比較簡
單；二來客戶最容易感受到服務的明顯進步。
Information Security Fundamentals and Practices - 16
服務支援
服務台
事件管理
問題管理
變更管理
釋出管理
組態管理
15

問題管理 (problem management) 在找出一個或多個
事件的根本成因；從這裡我們開始看基礎建設發生
服務中斷與品質不佳的問題。



例如郵件伺服器發生當機，我們儘快以事件管理程序重
新開機以恢復伺服器運作。在檢視事件記錄後發現該伺
服器一週內已經當機三次，於是我們啟動問題管理，並
且記錄調查到的當機原因。
當找到「根本成因」之後，可能需要啟動變更管
理。此外，要將事件的根本成因反饋給服務台，讓
相同的事件在未來可以被快速、正確地處理。
在ITIL各個程序中，增強問題管理能力是報酬率最高
的投資。
Information Security Fundamentals and Practices - 16
服務支援
服務台
事件管理
問題管理
變更管理
釋出管理
組態管理
16



變更管理 (change management) 是基礎建設或服務
的任何部分在變更時的控制程序。由於程序受到控
制，所以被核准的變更容易順利地執行。
服務支援
服務台
變更管理的原則是變更的結果不會產生新事件。
變更管理與變更控制 (change control) 不同：變更控
制使用在每一次的變更行動中；而變更管理則檢視
所有受控制的變更，以確保基礎建設的穩定。

有兩組人同時對一台伺服器做變更，分別都控制得宜、
變更成功。但事後發現兩個變更之間有衝突，導致系
統失敗。這個例子裡的變更控制都成功；但變更管理
卻失敗。變更管理程序應該要求兩個變更行為的事先
協調。
Information Security Fundamentals and Practices - 16
事件管理
問題管理
變更管理
釋出管理
組態管理
17



釋出管理 (release management) 是在已決定變更之後
負責成功地推出新版本。同時，被更新的項目需要透
過組態管理留下記錄。
釋出管理是一個主要流程。它是經常性的活動，而不
是只有在軟、硬體的大型推出時才去重視。
許多同仁使用公司新採購的筆記型電腦卻不能連結無
線網路，服務台將重複發生的事件回報給問題管理經
理。經研判根本成因是新電腦的無線網路卡與公司使
用多年的基地台有不相容的現象，因此建議更新基地
台。變更管理經理評估後同意變更，由釋出管理經理
規畫與管理新基地台的推出，並通知組態管理經理更
新組態管理資料庫內無線基地台的資料。
Information Security Fundamentals and Practices - 16
服務支援
服務台
事件管理
問題管理
變更管理
釋出管理
組態管理
18

組態管理 (configuration management) 經由識別、控
制、維護與驗證組態項目 (configuration items) 的版
本，來為基礎建設或服務提供邏輯模型。



簡單的說，組態管理經理對資訊基礎建設擁有一個清楚
的描述。這個描述稱為「組態管理資料庫 (CMDB)」。
CMDB 通常是經過設計的電腦資料庫，裡面儲存各種元
件的版本、設定、參數及現狀，包括電腦、伺服器、網
路連結等等，可能非常複雜。
CMDB 裡的每個項目稱為一個「組態項目 (CI)」，當一
個元件被變更時，它相對的 CI 就要經過組態管理做資
料更新。因此，CMDB 隨時存有最新、最正確的基礎建
設資訊。
服務支援
服務台
事件管理
問題管理
變更管理
釋出管理
組態管理
Information Security Fundamentals and Practices - 16
19


ISO 20000 的全名是「資訊技術服務管理」(Information Technology –
Service Management, ITSM)，它發表於2005年，是以英國標準協會的
BS15000 為基礎，而這些又都是從 ITIL 演進而來。
ISO 20000 分兩個部份：



第一部分為「規格」也就是正式的標準，規定一個組織要符合標準並通過
驗證所需要做的事。
第二部分是由基本要求所延伸的「實務準則」，主要描述在 ISO 20000 範圍
內的服務管理最佳實務 (best practice)。
ISO 20000 與前面介紹的 ISO 27001 相同，也使用 PDCA 的方法論。從
下一頁圖形 (參考 ISO 20000 標準) 我們可以看到左邊的輸入項目經過
ITSM的PDCA循環產出右邊的輸出項目。組織的許多方面都會進步，包
括業務、團隊、處理問題的流程、和與組織外部的互動。
Information Security Fundamentals and Practices - 16
20
業務需求
業務結果
規劃 (P)
規劃 ITSM
客戶需求
新服務或變
更服務需求
其它程序，
如供應商
服務台
其他團隊如
資安小組
客戶滿意度
行動 (A)
執行 (D)
持續進步
建置 ITSM
新的或變更
的服務
其它程序，
如供應商
檢查 (C)
監視、衡量與
審查 ITSM
Information Security Fundamentals and Practices - 16
團隊及成員
滿意度
21
服務施行程序
容量管理
持續性與可用
性管理管理
服務水準管理
服務報告
資訊安全管理
資訊技術服務
之預算與計價
控制程序
組態管理
變更管理
釋出程序
釋出管理
解決程序
關係程序
事件管理
商業關係管理
問題管理
供應商管理
Information Security Fundamentals and Practices - 16
22


服務報告 (service report) 的目的是經由正確、可靠的週期性報告，來
進行決策與溝通。服務報告有效地協助服務水準管理：在訂定SLA之
後，服務報告是客戶與服務提供者之間最佳的溝通、追蹤與測量的工
具。
服務報告都要清楚地描述報告的性質、目的、對象與資料來源的細
節；它應該包括：

與服務水準目標的績效比較。

不符合SLA或安全規範的項目或是問題。

數量或是資源使用率等負載特性。

在重大事件或變更等大事發生後的績效報告。

週期性的 (每天、每週、每月或每期) 趨勢報告。

滿意度分析。
Information Security Fundamentals and Practices - 16
23


對一個商業組織而言，與它關係最密切的外部組織有二：下游的「客
戶 (customers)」與上游的「供應商 (suppliers)」。即使在組織內部，
一個服務提供單位，如資訊部，也有這種上、下游關係需要管理。
商業關係管理 (business relationship management) 的目的在建立並維護
服務提供者與客戶間的良好關係。以下是一些應有的作法：




服務提供者與客戶應該至少一年有一次的服務審查會議，討論服務範圍、
契約、績效與需求等。這些會議應有記錄。
服務提供者應該注意商業需求與重大變更，為正確的回應做準備。
應該建立申訴的流程，所有正式的服務申訴都應被記錄、調查、採取行
動、提出報告並正式結案。
服務提供者應指定員工來管理客戶滿意度與商業關係。訂定程序來取得客
戶反饋意見並採取修正行動，改善措施應被記錄並用以改進服務程序。
Information Security Fundamentals and Practices - 16
24

供應商管理 (supplier management) 是藉由管理供應商來確保自己能為
客戶提供緊密而且高品質的服務。以下是一些應有的作法：





服務提供者須要有文件化的供應商管理程序，每個供應商應由一位合約經
理 (contract manager) 負責管理。
供應商所提供的服務也應有 SLA 清楚說明，並由雙方同意。與供應商的 SLA
應該要與客戶的 SLA 密切配合。
如果主要供應商底下還有下包商，那麼主要供應商與下包商的責任與關係
應有明文規定。主要供應商需要有程序來確保下包商能符合合約要求。
應該至少一年有一次的審查會議來檢討合約或正式協議，以確保商業需求
與合約義務依然吻合。與供應商之間應有處理合約爭議的程序。
應依據服務水準目標來監視並審查供應商的績效，經由這個過程所識別的
改善措施應被記錄並用以改進服務程序。
Information Security Fundamentals and Practices - 16
25


資訊安全管理 (information security management) 是在所有服務活動中
有效的管理資訊安全。
我們在資訊安全課程的最後一章介紹 ITSM 有兩個主要原因：



紊亂與隨機是資訊安全事件的溫床；最安全的系統是「管理完善」的系
統。ITSM 全方位的管理資訊技術服務的各個面向，可以從根本來降低資訊
安全管理的負擔。
ISMS 從安全著眼看組織的資訊管理；而 ITSM 則從組織的資訊管理著眼看資
訊安全在其中扮演的角色。前者為資訊安全管理提供詳細的做法；後者則
為資訊安全管理提供更廣的角度。
ISO 20000 明文說 ISO 17799 (與 ISO 27001 對應的資訊安全管理之作業
要點) 為資訊安全管理的指導，也就是說 ITSM 的資訊安全管理要求與
ISMS 一致。已經通過 ISO 27001 驗證的組織在做 ISO 20000 驗證時，可
以跳過資訊安全管理這一項。
Information Security Fundamentals and Practices - 16
26






ITSM 的資訊安全管理要求有適當位階的管理階層需要核可資訊安全政
策；要在適當時機對所有相關人員及客戶宣導這個政策。
ITSM 要求執行適當的安全控制來：

執行資訊技術服務政策。

管理當使用服務或系統時的相關風險。
當要變更安全控制項目時，需要進行變更前評估。
針對使用我方資訊系統或服務的外部組織，若有任何安排牽涉到它
們，都應該以正式的安全需求協議為基礎。
ISMS 所討論有關資訊安全事件 (security incidents) 的通報與記錄，應該
與 ITSM 的事件管理程序吻合。
應對資訊安全事件的種類、數量與衝擊進行量化的監視。這個過程所
識別的改善措施應被記錄並用以改進服務程序。
Information Security Fundamentals and Practices - 16
27

與資訊安全有關的事件數量。

與資訊安全相關的問題被結案的數量。

稽核與管審會的缺失被解決的數量。

按時完成稽核與管審會的比率。

被識別的風險數量 (包括新威脅與警告項目)

SLA 內有說明資訊安全規格的百分比。

UC 內有說明資訊安全規格的百分比。

資訊安全相關的補丁釋出速度。

因為資訊安全問題而取消變更的數量。

因為資訊安全問題而取消釋出的數量。
Information Security Fundamentals and Practices - 16
28