香港中小企密碼管理+多重驗證:老闆實務指南
分類:行業情報 | 日期:2026-10-23
最後更新:2026年10月 | 由 IT SUPPORTKING 技術團隊編寫

引言:老闆痛點——密碼問題從來不是「記唔記得」,而是「邊個仲入得到」
香港中小企老闆最常見的密碼場面,通常不是技術名詞,而是一串日常畫面。老闆自己記住十幾個帳號,為了記得住,於是同一組密碼在電郵、雲端檔案、訂單系統、銀行相關服務、社交專頁之間輪流用;新同事入職,老闆在即時通訊群組貼一次共享密碼,之後每個人再轉貼、再截圖,密碼的流向從此無人追得到;舊同事離職,主帳號停了,但共享密碼、驗證因素、群組權限、保險庫取用權仍然留著,老闆以為「已經停了」,其實只是停了其中一條路。
另一種痛點更隱蔽:電郵被入侵不是單一帳號事件。電郵通常是其他服務登記確認及密碼重設的樞紐,入侵者拿到電郵,往往可以重設其他服務,改聯絡資料,轉走客戶查詢,甚至冒認公司向客戶或供應商發訊息。香港 HKCERT 的公開提示正是按這個次序提醒:優先保障電郵、金融服務及社交網絡帳號,因為電郵被攻破的連鎖影響最大(來源:HKCERT,查閱日期:2026-10-23)。老闆要處理的,從來不是「教員工記密碼」,而是建立一套即使有人忘記、有人離職、有人電話遺失,公司仍然可以收回、仍然可以復原、仍然查得到邊個做過邊件事的制度。
本文的目的,是給老闆一張可以逐項對的指南:密碼重用點解危險、密碼管理器點揀、主密碼點守、共享點做先至唔會失控、多重驗證邊種方法先至擋得到釣魚、短訊點解最弱、通行密鑰點過渡、離職憑證停用點排次序、備用碼同鎖死點應變,以及向任何 IT 支援供應商簽約之前,應該點樣問清楚。本文講的是通用做法,不是針對某一個行業的合規手冊。
服務邊界圍欄:以下係通用密碼管理及多重驗證檢查清單,唔係本站服務承諾。協調員已於 2026-10-23 以 curl 親驗 live https://www.itsupportking.com/pricing(200),全頁完全沒有密碼管理器、多重驗證相關字眼。因此本站密碼管理器設定、主密碼管理、共享密碼庫管理、多重驗證設定及管理、通行密鑰設定、備用碼管理、離職憑證停用執行,是否包括、是否另收費,全部未公佈,以查詢為準,簽約前問清楚並寫入協議。查詢時要求對方以電郵或者服務協議書面確認,唔好只信口頭承諾。
本站 live /pricing 六級(2026-10-23 複驗,價錢寫法一律用「/月」形式,不另加計價單位,scope 以 live 文字為準):基礎遙距版 HK$600/月包正版 Office 365 商業授權、送企業級 Router 連安裝、無限次遙距支援(週一至五 9am-6pm);專業進階版 HK$1,200/月加緊急事故優先響應、新員工電腦入職設置、數據備份建議及設定、單一聯絡窗口(週一至六 9am-6pm);企業設備版 HK$2,200/月加商務電腦設備、硬件全保養(壞機即換)、每 3 年免費升級換機;全方位無憂版 HK$2,950/月加多功能商務打印機及維修保養;設計專用版 HK$4,950/月加 AutoCAD 正版授權及 Adobe Creative Cloud 全套;旗艦網頁版 HK$5,950/月加企業網站設計及開發、網站維護及伺服器託管。六級之中沒有一級寫明包括密碼或驗證服務,讀者不要將下文的通用做法誤讀為套餐內容。
一、密碼重用風險:一個外洩點解可以變成成間公司
實務做法
第一,理解攻擊機制:不是猜中,而是直接試真組合。 憑證填充的做法,是將由一次外洩取得的用戶名加密碼組合,拿到其他無關網站逐個嘗試,依賴的正是用戶在多處重用同一組合(來源:公開憑證填充定義,查閱日期:2026-10-23)。這一點同暴力猜測不同:猜測是逐個試可能的密碼,憑證填充是用已經被盜的真實組合去試其他服務,因此即使密碼本身不算極弱,重用已經足夠令攻擊成立(來源:公開憑證填充比較,查閱日期:2026-10-23)。老闆檢查的第一條問題不應是「密碼夠唔夠複雜」,而是「同一個密碼出現過喺幾多個服務」。
第二,畫出連鎖圖:由個人帳號到工作電郵,再到重設樞紐。 員工用同一密碼登記個人購物帳號同工作電郵,一次零售服務外洩就變成公司帳號風險;工作電郵一旦被入侵,攻擊者可以利用電郵重設其他服務,改聯絡資料,截取客戶查詢(來源:公開憑證重用風險分析,查閱日期:2026-10-23)。HKCERT 的外洩提示亦按同一邏輯排序:先保障電郵,因為電郵通常用作其他服務登記確認及密碼重設(來源:HKCERT,查閱日期:2026-10-23)。實務上,老闆要為電郵、雲端檔案、訂單及財務相關系統、網店後台、社交專頁、供應商平台、遙距登入,各自列出「如果呢個帳號被入侵,攻擊者下一步可以去邊」,而不是只列出帳號名單。
第三,分開個人同工作,連重設途徑都要分開。 工作帳號的重設電郵不應用私人電郵,重設電話不應用私人電話號碼的同一個短訊途徑作唯一後備,否則私人帳號被入侵就等於工作帳號的重設途徑一併被入侵。工作與私人共用同一個重設郵箱、共用同一個密碼、共用同一個驗證應用程式內的同一個帳號,全部都是連鎖點。正確做法是:工作帳號有自己的登入組合、自己的驗證因素、自己的重設聯絡人,私人帳號的變動不應自動影響工作帳號。
第四,管理員帳號要當作另一級風險處理。 一般員工帳號被入侵,可能只影響一個部門的檔案或一個應用程式;管理員帳號被入侵,影響通常橫跨用戶目錄、系統設定、保安設定及敏感業務資料,攻擊者可以停用保安控制、開後門帳號、橫向取用多個部門資料(來源:公開憑證重用風險分析,查閱日期:2026-10-23)。因此管理員密碼絕對不能同一般帳號相同,管理員驗證方法要更強,管理員登入要有紀錄,管理員帳號不應用作日常收發電郵或處理文件。
外洩之後的處理次序
外洩懷疑一出現,次序本身就是止血。公開的通用處理次序是:立即更改受影響帳號的密碼,同時更改所有重用過同一密碼的帳號,開啟多重驗證,檢查帳號活動有無陌生登入、改密碼、新裝置,留意財務帳號有無陌生交易(來源:公開外洩處理清單,查閱日期:2026-10-23)。只改一個帳號、只改被通知的那一個服務,是最常見的處理錯誤:攻擊者手上的組合清單不會因為你改了一個服務而自動失效,其他重用同一組合的服務仍然開著。
常見錯誤
- 以為密碼夠長、夠複雜就等於安全,忽略同一密碼在十幾個服務重用。
- 工作同私人用同一密碼、同一重設電郵,個人服務外洩直接變成公司事件。
- 管理員同日常帳號用同一組合,日常帳號一失守,管理權限一併失守。
- 外洩後只改被通知的帳號,沒有逐個改晒所有重用同一組合的服務。
- 共用帳號出事時無法稽核,因為幾個人用同一個登入,紀錄分不清邊個人做過邊件事。
二、密碼管理器點揀:不是買一個應用程式,而是買一套可收回的制度
實務做法
第一,先講清楚管理器解決咩問題,解決唔到咩問題。 管理器的核心價值,是令每帳號獨特強密碼變得可行:用戶只需記住一個主密碼,管理器為每個帳號產生及儲存隨機高強度密碼,登入時自動填寫,減少因記憶負擔而重用(來源:公開商業密碼管理器說明,查閱日期:2026-10-23)。管理器解決的是「記不住所以重用」的問題,不是「釣魚網站本身」的問題,也不是「裝置有惡意軟件」的問題。自動填寫只應在正確網站填寫,員工仍然要識得分辨假登入頁;裝置本身有惡意軟件,自動填寫的密碼仍然可能被盜。買管理器之前,老闆要先接受這兩個邊界,否則會以為買了管理器就等於買了全部保安。
第二,個人版同商業版的分別,在管理控制,不在儲存格數。 商業級工具的額外價值在管理控制:集中睇到邊個帳號存在、邊個有取用權、密碼幾時最後輪換,而管理員本身不應因此自動睇到密碼明文;員工離職時撤銷保險庫取用權,共享密碼要輪換(來源:公開商業密碼管理器說明,查閱日期:2026-10-23)。個人版通常以個人使用為中心,沒有公司層面的取用權管理、共享權限分級、離職撤銷、稽核紀錄。十人以下的小公司即使人少,只要有共享登入、有離職、有客戶資料,就應該用商業版的思維去選:不是看價錢牌上的個人版是否較平,而是看離職那一日,公司能不能在一個位置收回全部取用權。
第三,瀏覽器內置儲存只能作起點,不能作公司制度。 瀏覽器內置儲存密碼好過完全不用管理器,但專用管理器一般在加密標準、跨瀏覽器支援、安全共享及通行密鑰管理方面較完整;瀏覽器儲存的保護取決於瀏覽器帳號本身的密碼及雙重驗證(來源:公開管理器比較及瀏覽器儲存說明,查閱日期:2026-10-23)。實務風險是:員工換瀏覽器、換裝置、離職交還裝置時,瀏覽器儲存的密碼散落在不同裝置、不同瀏覽器帳號,公司沒有一張完整清單可以對。公司制度要求的是「一張清單、一個撤銷點」,瀏覽器內置儲存給不到這一張清單。
第四,用十項準則選型,不要用廣告詞選型。 下表是選型時要逐項問清楚的準則,每一項都要以產品官方文件及合約為準,不要只信銷售簡報:
| 準則 | 要問清楚的內容 |
|---|---|
| 加密模型 | 保險庫是否在裝置上加密、服務商本身能否讀取內容;若服務商可以讀取,零知識的假設即不成立 |
| 獨立審計 | 有無公開的獨立審計結果、審計範圍是否包括加密及取用控制,抑或只包括一般營運 |
| 管理員控制 | 管理員能否睇到帳號清單及取用權,而不自動睇到密碼明文;政策能否強制主密碼強度及保險庫驗證 |
| 共享權限 | 共享單位是項目抑或帳號;檢視、編輯、隱藏密碼三種權限如何分;隱藏不等於不能使用,見第三節 |
| 通行密鑰支援 | 是否支援儲存及使用通行密鑰;同步與綁定裝置兩種如何分;見第五節 |
| 匯出及轉換 | 匯出格式是甚麼、匯出要經過甚麼批准及紀錄;轉換去另一產品的成本及資料遺失風險 |
| 外洩監察 | 有無對照已知外洩清單的提示;提示出現後,輪換流程由邊個執行 |
| 復原方法 | 主密碼遺失、管理員復原、緊急取用的完整程序,見第七節;復原程序必須在出事前測試過 |
| 裝置覆蓋 | 是否覆蓋公司全部裝置及瀏覽器;離線取用如何安排;舊裝置不支援時點處理 |
| 存放及合約 | 資料存放地點、合約條款、服務終止時資料如何取回及刪除;以上以合約為準,不要憑印象假設 |
第五,雲端託管同自行架設的取捨,要計維護成本,不只計月費。 雲端託管由服務商負責更新、備份及可用性,公司要接受的是服務商的加密模型及合約條款;自行架設由公司自己負責更新、備份、復原及保安修補,表面上控制較多,實際上維護負擔全部回到公司身上。十人以下、沒有專職技術人員的中小企,自行架設往往不是較安全,而是較容易因為無人更新、無人備份、無人測試復原而出事。選型時要問:更新由邊個做、備份由邊個做、復原測試由邊個做,答不到這三條,就不要選需要公司自己維護的方案。
第六,試用要試完整流程,不要只試登入一次。 試用清單應該包括:由瀏覽器匯入舊密碼、刪除瀏覽器舊儲存、為電郵及雲端檔案換上新產生的獨特密碼、建立一個共享庫並授權給另一位同事、將共享庫權限由編輯改為檢視、撤銷一位測試帳號的取用權並確認共享密碼已輪換、模擬主密碼遺失走一次復原程序、匯出一次並檢查匯出檔案的保護。試用只試到「登入好方便」就簽約,等於只試了管理器最不重要的部分。
常見錯誤
- 全公司用個人版,每人各自管理,公司沒有取用權清單,離職時無從收回。
- 繼續用瀏覽器內置儲存加試算表、即時通訊傳密碼,管理器買了但舊習慣沒有停。
- 只比較月費,沒有比較復原、匯出、共享權限、審計四項,簽約後才發現最需要的功能不在合約內。
- 自行架設之後無人更新、無人備份,復原第一次測試就是真正出事那一次。
- 將銀行、支付平台、社交平台的登入一律放入共享庫,沒有先檢查各服務本身對共享登入及第三方取用的條款;各服務條款不同,一律容許的假設並不成立,須以各服務條款為準。
三、主密碼與共享:一個主密碼守不住,全庫即失守;共享做錯,稽核即失效
實務做法
第一,主密碼的設計原則是長度重於複雜度。 NIST SP 800-63B 系列指引要求用戶自選密碼最少八個字元,驗證方要支援最少六十四個字元的自選密碼;複雜度規則不應強制,重點應放在長度(來源:公開 NIST 指引整理,查閱日期:2026-10-23)。版本細節以 NIST 官方原文為準,本文只用多個來源一致的方向(長度重於複雜度),不以二手整理作版本定論。英國式實務建議亦指出,為管理器帳號設強密碼,可以用三個或以上隨機詞語組成(來源:公開管理器保安建議,查閱日期:2026-10-23)。實務做法是:主密碼用一句自己記得住、別人猜不到的長通行短語,由幾個無關詞語組成,不要用公司名、生日、電話、服務名、鍵盤順序;主密碼絕對不能在其他任何服務重用,因為主密碼一失守,全庫即失守。
第二,主密碼不能放在保險庫自己裡面。 這是新手最常犯的邏輯錯誤:將主密碼寫進自己要靠主密碼才開得到的保險庫,等於將門匙鎖在屋內。主密碼的備份要與保險庫分開處理,見第七節。公司層面,主密碼不是「老闆記得就得」:老闆請假、生病、離開,保險庫的取用權必須有第二條合法途徑,而且這條途徑必須在事前設好、事前測試過,不是出事當日才想辦法。
第三,保險庫本身必須有強驗證,而且要有後備因素。 公開建議指出,為管理器帳號設雙重驗證,如有選項就設多於一種第二因素作後備;及時更新管理器應用程式或瀏覽器(來源:公開管理器保安建議,查閱日期:2026-10-23)。保險庫的驗證方法不能弱於保險庫內保護的帳號:保險庫只用短訊驗證,保險庫內卻放著銀行及電郵密碼,等於用最弱的鎖守最貴的櫃。保險庫驗證應優先用驗證器應用程式或硬件鑰匙,短訊只作過渡後備,而且要寫明過渡期及遷移計劃。
第四,共享的正確單位是項目,不是帳號。 每人用自己的帳號登入,需要共享的登入項目放在共享庫內授權;共用同一個登入帳號會失去稽核能力,出事時分不清邊個人做過邊件事(來源:公開商業管理器部署說明,查閱日期:2026-10-23)。共享庫的權限要分三層理解:檢視權限是可以用該項目登入,編輯權限是可以改密碼及改共享對象,管理權限是可以改整個共享庫的成員。老闆要為每個共享庫寫明擁有人、成員、權限、覆核周期,共享庫沒有擁有人,就等於沒有人負責輪換及清理。
第五,「隱藏密碼」不等於「不能使用」,不要誤解為絕對保密。 部分管理器可以設定成員可以用項目登入,但看不到密碼明文,這個設定可以減少密碼被抄走、被轉貼,但不能阻止成員在登入後用該帳號做事,也不能阻止有技術能力的成員在登入過程中取得密碼。因此隱藏密碼是減少外洩面的控制,不是稽核的替代品。真正需要稽核的共享帳號,應該盡量改為每人獨立帳號加委派權限,而不是長期共用同一個登入;實在無法分拆的共享帳號,必須有使用紀錄、輪換清單及離職即輪換的規則。
第六,共享密碼的輪換觸發點要寫死,不要靠自覺。 輪換不是「有時間先換」,而是以下任何一項出現即觸發:看過該密碼的員工離職或轉職;懷疑密碼曾經在即時通訊、電郵、試算表、截圖出現;服務通知可能外洩;共享庫成員有變動;管理員帳號有異常登入。輪換的動作不只是改密碼,還包括:更新共享庫項目、通知仍然需要取用的人用新項目登入、確認舊密碼已經失效、檢查有無其他地方仍然存著舊密碼(例如舊試算表、舊訊息、瀏覽器儲存),以及留下輪換紀錄。輪換只改密碼、沒有清理舊儲存,等於換了門鎖但舊門匙仍然放在門口地氈下。
常見錯誤
- 主密碼用公司名加年份,短、易猜,而且在其他服務重用。
- 主密碼寫在保險庫內、寫在同一部電話的備忘、貼在熒幕邊,備份與主途徑放在同一位置。
- 保險庫只用短訊驗證,保險庫內卻放著電郵及財務相關密碼。
- 幾個人共用同一個登入帳號,出事時紀錄分不清邊個人。
- 以為隱藏密碼就等於安全,忽略成員仍然可以用該帳號做事,忽略離職後沒有輪換。
- 共享密碼在即時通訊傳過一次之後,從來沒有輪換,舊訊息變成永久後門。
四、MFA 方式比較與短訊弱點:不是「開了多重驗證」就等於擋得到釣魚
實務做法
第一,先分清楚因素類別,再比較方法。 多重驗證的因素分為三類:你知道的資料(例如密碼)、你擁有的物件(例如受信任電話或硬件鑰匙)、你是誰的特徵(例如指紋或面部特徵)(來源:公開多重驗證說明,查閱日期:2026-10-23)。同一密碼加同類的第二個密碼不算多重驗證;密碼加短訊、密碼加驗證器、密碼加硬件鑰匙,才是不同類別的組合。老闆檢查時,第一句要問的不是「開了沒有」,而是「第二因素屬於邊一類、綁定邊一個網站、被釣魚時會唔會一併被交出去」。
第二,用一張表比較,不要用「強」一個字概括。 下表按公開指引的方法強度整理,重點在釣魚抵抗力及主要弱點,不是使用方便程度:
| 方法 | 釣魚抵抗力 | 主要弱點 | 適用位置 |
|---|---|---|---|
| 短訊或語音一次性密碼 | 低 | 電話號碼轉移、電訊攔截、假頁即時轉交 | 只作過渡後備,不作管理員及財務相關帳號的唯一第二因素 |
| 電郵驗證碼或連結 | 低 | 取決於郵箱本身是否安全;郵箱被入侵即等於後備一併失守 | 只作低風險服務的後備,不作電郵本身的第二因素 |
| 驗證器應用程式一次性密碼 | 中 | 假頁即時轉交;種子被抄走或被釣走即失效;不綁定網站來源 | 一般員工的基準方法,離線可用,不依賴電話號碼 |
| 簡單按批准的推送通知 | 中以下 | 疲勞攻擊:重複推送直至用戶按錯批准;假頁轉交 | 不應單獨使用;如必須用,要加數字配對及異常監察 |
| 附數字配對的推送通知 | 中 | 可以減少誤批,但仍然不是綁定網站來源的驗證,假頁仍然可以轉交數字 | 過渡期的改善方法,不是抗釣魚的終點 |
| 硬件保安鑰匙(FIDO2) | 高,抗釣魚 | 遺失、損壞、備用鑰匙管理;舊系統可能不支援 | 管理員、老闆、財務相關帳號優先;高風險角色必備 |
| 綁定裝置的通行密鑰 | 高,抗釣魚 | 私鑰不能匯出,遺失裝置要靠備用鑰匙或既定復原程序 | 管理員及高風險帳號的終點方法之一 |
| 同步通行密鑰 | 高,抗釣魚,但取決於同步帳號 | 同步帳號本身被入侵,通行密鑰的保安即受影響 | 一般員工的方便終點,但同步帳號本身必須用強驗證 |
| 憑證式智能卡 | 高,抗釣魚 | 管理成本高、發卡及回收流程重 | 大型或受規管環境較常見,中小企一般先由硬件鑰匙起步 |
方法強度的公開對照是:同一平台的驗證方法強度表將驗證器應用程式、FIDO2 保安鑰匙、憑證驗證列為高,OATH 硬件及軟件令牌列為中,短訊及語音列為中,密碼本身列為低(來源:公開驗證方法強度表,查閱日期:2026-10-23);另一份教學材料則將短訊及語音列為低至中,並明言短訊及語音屬於舊式方法,容易受電話號碼轉移攻擊影響,建議遷移去應用程式或硬件方法(來源:公開驗證方法教學,查閱日期:2026-10-23)。兩份材料的用詞略有不同,方向一致:短訊不是與硬件鑰匙同級的方法。上表「釣魚抵抗力」一欄只量度抗釣魚能力,驗證器一次性密碼抗釣魚為中,不等於方法強度表將驗證器列為高的整體評價;兩者量度維度不同,並無矛盾。
第三,短訊弱點要分三層講,不要只講「短訊唔安全」四個字。 第一層是即時轉交:短訊一次性密碼可以在假登入頁即時被轉交去真網站,用戶以為自己在登入真網站,其實是在幫攻擊者登入(來源:公開多重驗證比較,查閱日期:2026-10-23)。第二層是電話號碼轉移:攻擊者說服電訊商將受害人號碼轉移到攻擊者控制的電話卡,直接截取短訊碼(來源:公開多重驗證比較,查閱日期:2026-10-23)。第三層是傳送本身的攔截風險:短訊傳送有電訊協議層面的弱點,不是只靠用戶小心就可以解決。香港本地電話號碼轉移攻擊的個案數字及電訊商核實程序,本批沒有官方統計,本文只寫通用機制,不寫本地個案數字。結論是:短訊好過完全沒有第二因素,但不能作為管理員、電郵、財務相關帳號的長期唯一第二因素;短訊只能作過渡後備,而且要有寫明的遷移期及遷移完成標準。
第四,驗證器應用程式比短訊強,但仍然不是抗釣魚。 驗證器一次性密碼不依賴電話號碼及電訊網絡,離線亦可產生,這是它比短訊強的地方;但它仍然可以被即時轉交:用戶在假頁輸入的密碼,攻擊者可以在有效期內即時拿到真網站使用(來源:公開抗釣魚驗證比較,查閱日期:2026-10-23)。因此「由短訊轉去驗證器」是進步,不是終點。終點是綁定網站來源的驗證:驗證儀式以密碼學綁定真實網站的來源,令在假網站取得的憑證不能拿到真網站重放;符合此定義的包括 FIDO2/WebAuthn 通行密鑰及硬件鑰匙、憑證式智能卡;短訊、語音、電郵驗證碼、簡單推送不在此列(來源:公開抗釣魚驗證定義,查閱日期:2026-10-23)。
第五,推送疲勞是人的弱點,不是技術的細節。 簡單按批准的推送通知有疲勞攻擊風險:攻擊者重複觸發推送,直至疲倦或分心的用戶按錯批准(來源:公開抗釣魚驗證比較,查閱日期:2026-10-23)。要求輸入登入畫面顯示的數字可以減少誤批,但仍然不是綁定網站來源的驗證,不能等同抗釣魚驗證。實務規則要寫死:收到無預期的推送,一律拒絕並報告;深夜、休假、正在開會時收到的推送,更加要拒絕;報告途徑要事先講明是向邊個人、用邊個渠道,不要只寫「向 IT 報告」而沒有人名及後備渠道。
第六,強制開啟才算數,「可以開」不算數。 多重驗證只供個別員工自願開啟,結果一定是最高風險的帳號未必開、管理員未必開、新入職未必開、例外帳號長期開不到。實務做法是:電郵、雲端檔案、業務系統、遙距登入,全部強制開啟;管理員及財務相關帳號強制用較強方法;例外帳號要有書面原因、批准人、覆核日期,例外不是永久豁免。強制範圍亦要包括舊式登入協議:部分舊協議不支援現代驗證,停用舊式驗證、監察異常登入及新裝置權杖使用,是部署多重驗證時要一併檢查的項目(來源:公開多重驗證繞過分析,查閱日期:2026-10-23)。只開新登入的多重驗證,舊協議仍然開著,等於新門裝了新鎖、舊門仍然沒有鎖。
第七,優先次序:先守樞紐,再推全員。 部署次序建議是:第一批是電郵及管理員帳號,因為電郵是重設樞紐,管理員是權限樞紐;第二批是財務相關、客戶資料、訂單系統;第三批是全部員工的雲端檔案及業務系統;第四批是社交專頁、供應商平台等外部服務。每一批完成要有清單:邊個帳號已開、邊種方法、後備方法係咩、例外帳號有幾多、舊協議停了沒有。沒有清單的「已經推晒」只是感覺,不是事實。
常見錯誤
- 全公司只用短訊,管理員同電郵都只用短訊,以為「有開」就等於安全。
- 由短訊轉去驗證器之後就停步,沒有向硬件鑰匙或通行密鑰的終點走。
- 推送通知沒有數字配對,員工收到無預期推送照按批准,沒有報告機制。
- 多重驗證只供自願開啟,管理員及新入職長期未開,例外帳號無人覆核。
- 新登入開了多重驗證,舊式登入協議仍然開著,攻擊者由舊路徑繞過。
- 後備方法比主方法弱,例如主方法用硬件鑰匙,後備卻只用短訊,實際保安水平等於後備方法。
五、由密碼到通行密鑰的過渡:開了通行密鑰,不等於舊密碼已經失效
實務做法
第一,理解通行密鑰是甚麼。 通行密鑰以公開密鑰密碼學綁定指定網站,沒有可供外洩的共享秘密,不會被拿到假網站重放(來源:公開 NIST 指引整理,查閱日期:2026-10-23)。登入時裝置用私鑰簽署挑戰,並以指紋、面部特徵或裝置密碼確認用戶意圖,私鑰本身不會傳送給網站。這個設計解決了密碼的兩個根本問題:密碼可以被釣走,密碼可以在外洩資料庫被重用;通行密鑰沒有這兩個問題,因為沒有共享秘密可以被釣走或被重用。
第二,分清楚同步與綁定裝置,兩者的風險完全不同。 同步通行密鑰經平台鑰匙圈備份到多部裝置,方便但保安同時取決於同步帳號本身的保護;綁定裝置的通行密鑰私鑰不能匯出,遺失裝置就要靠備用鑰匙或既定復原程序(來源:公開抗釣魚驗證比較,查閱日期:2026-10-23)。同步通行密鑰在 NIST 補充指引中被認可為可滿足中級驗證保證,綁定裝置通行密鑰可滿足更高一級;同步帳號本身必須有相應強度的多重驗證,私鑰操作要在本地裝置進行(來源:公開通行密鑰指引整理,查閱日期:2026-10-23;細節以 NIST 官方原文為準)。中小企的實務分工是:一般員工用同步通行密鑰求方便,但同步帳號本身必須用強驗證;管理員及高風險帳號用綁定裝置的硬件鑰匙,並備有第二支備用鑰匙。
第三,過渡期最大的陷阱是舊密碼仍然有效。 只開啟通行密鑰而沒有檢查舊密碼是否仍然有效,等於留下可被釣魚的舊路徑;通行密鑰部署必須同時檢查後備登入方法是否同樣強,否則最弱的後備方法就是實際保安水平(來源:公開通行密鑰部署提醒,查閱日期:2026-10-23)。過渡清單必須包括:該服務是否容許停用密碼登入、停用後後備方法係咩、舊裝置的登入工作階段有無撤銷、管理員能否看到邊個帳號仍然用密碼登入。服務不容許停用密碼,就要誠實寫明:通行密鑰只是多了一個較安全的登入方法,不是已經移除了可被釣魚的路徑。
第四,分批過渡,不要一次過全公司轉。 第一批是老闆及管理員,先在電郵及管理員帳號試同步與綁定裝置兩種,試埋遺失裝置的復原流程;第二批是經常處理客戶及財務資料的員工;第三批才是全員。每一批都要試三件事:正常登入、換裝置登入、遺失裝置後的復原。復原沒有試過的通行密鑰部署,出事那一日就是第一次測試。
第五,舊系統要誠實分流。 不是所有舊系統都支援通行密鑰或現代驗證。舊系統的實務做法是:先用驗證器應用程式或硬件令牌作第二因素頂住,同時將舊系統列入更換或隔離清單,限制舊系統的取用範圍及取用人員,不要將舊系統的弱驗證合理化為「公司標準」。舊系統的帳號密碼更要獨特、更要定期覆核,因為舊系統往往就是攻擊者最容易找到的入口。
常見錯誤
- 開了通行密鑰就以為完成,沒有檢查舊密碼及弱後備方法是否仍然開著。
- 同步帳號本身只用短訊驗證,同步通行密鑰的保安被同步帳號拖低。
- 管理員只用同步通行密鑰,沒有備用硬件鑰匙,遺失裝置即鎖死。
- 一次過全公司轉,沒有分批、沒有試復原,問題一次過爆發。
- 舊系統不支援就放棄,舊系統帳號長期只用密碼,而且密碼在多處重用。
六、離職停用流程(憑證專用):先停用、後刪除,共享密碼即輪換
本節只講登入憑證及驗證因素的停用次序,不包括裝置回收、郵箱去向、客戶交接等完整離職交接項目;完整交接需要另外一張清單,本節的憑證清單是其中一張,不可以代替整張交接清單。
實務做法
第一,觸發點要寫明,不要等最後一日。 離職通知一到,老闆或負責人就要即刻做三件事:確認最後工作日期同存取權限終止的時間點,並以書面通知相關人員;列出離職員工掂過的全部憑證系統(公司電郵、雲端檔案、業務系統、網店後台、社交專頁、供應商平台、遙距登入、密碼管理器共享庫、驗證因素);指明每樣嘢的接手人及覆核人。憑證停用清單應該由入職那一張帳號清單直接對照出來:入職嗰張清單寫得愈齊,離職嗰陣先至有嘢可以對;入職嗰陣無記錄,日後停用就只能靠記憶逐個搵,必然有遺漏。
第二,次序是先停用、後刪除。 停用即時截斷登入,刪除是不可逆轉的清除;資料交接、共享庫擁有權轉移、授權回收要在刪除之前完成,否則資料可能進入刪除倒數後無法取回。離職當日的憑證次序建議是:先停用主帳號登入;同一個時段內移除管理員角色及特權;撤銷全部有效工作階段,令已經登入的裝置即時失效;撤銷驗證因素登記,包括驗證器應用程式、硬件鑰匙、通行密鑰、備用碼;將共享庫擁有權轉移給接手人,並撤銷離職員工的共享庫取用權;輪換離職員工看過的全部共享密碼;移除群組成員身份及委派權限;檢查電郵轉寄規則及自動回覆是否仍然指向離職員工;檢查離職員工有用公司電郵登記過的外部服務及試用帳號,逐個轉移或關閉;資料交接完成並經覆核之後,才回收授權及刪除帳號。
第三,共享密碼輪換是離職停用的核心,不是可做可不做的附加項目。 離職員工看過的共享密碼,即使他沒有惡意,只要密碼仍然有效,就等於離職後仍然有一條不需要帳號的入口。輪換要做到四點:改密碼、更新共享庫項目、確認舊密碼已經失效、清理舊儲存(舊訊息、舊試算表、瀏覽器儲存)。輪換清單要逐項剔,輪換完成要有紀錄,紀錄要交給老闆或負責人覆核,不是只由執行人自己講「已經換晒」。
第四,驗證因素撤銷要逐項對,不要只停主帳號。 主帳號停用之後,已經登記的驗證器、硬件鑰匙、通行密鑰、備用碼,若沒有逐項撤銷及作廢,仍然可能在特定復原流程中被利用。硬件鑰匙要收回或作廢,通行密鑰要由服務端移除登記,備用碼要作廢並補發給接手人(如適用),驗證器種子要移除。臨時員工、兼職、承包商的憑證停用要用同一張清單,不要因為「只是臨時」就簡化;臨時帳號最容易被遺忘,遺忘的臨時帳號往往就是最長壽的入口。
第五,管理員離職要加多一層。 管理員離職時,除了上述全部項目,還要:轉移全部共享庫及群組擁有權;檢查管理員有無開過例外帳號、後備帳號、緊急帳號;檢查管理員有無持有其他人的驗證因素或備用碼;更換管理員共用的緊急聯絡方法;覆核管理員任期內的異常登入及權限變動紀錄。管理員離職的覆核人不能是離職管理員自己,必須是老闆或另一位負責人。
第六,停用完成要有書面覆核,不是口頭確認。 覆核紀錄至少包括:離職員工姓名、最後工作日期、停用日期及時間點、停用項目清單及每項完成標記、共享密碼輪換清單、擁有權轉移清單、例外項目及跟進人、覆核人簽署。覆核紀錄要保存,保存期要按公司政策定,不要只存在執行人的電郵或訊息內。沒有書面覆核的停用,日後出事時無法證明已經停用,也無法知道邊一項漏了。
常見錯誤
- 只停主帳號,共享密碼、驗證因素、群組、委派權限全部留低。
- 離職當日即刪除帳號,資料交接未完成,共享庫變成無人管理的孤兒。
- 共享密碼沒有輪換,離職員工仍然可以用舊密碼經共享入口登入。
- 硬件鑰匙沒有收回、通行密鑰沒有移除、備用碼沒有作廢。
- 臨時帳號用簡化流程,結果臨時帳號變成長期入口。
- 停用只有口頭確認,沒有書面清單及覆核人,出事時無法追查邊一項漏了。
七、備用碼與鎖死應變:復原程序要在出事前測試過,出事當日不是第一次測試
實務做法
第一,備用碼的存放原則是與主途徑分開。 備用碼若放在同一部電話、同一電郵或同一個保險庫內,電話遺失或保險庫鎖死時會一併失效;實體密封存放要加取用紀錄。實務做法是:備用碼印出或抄寫一份,放入密封信封,存放在上鎖的地方,信封上寫明適用帳號、存放日期、取用紀錄欄;取用一次就要紀錄邊個人、幾時、為甚麼取用,用過的備用碼要作廢並補發。備用碼絕對不能放在即時通訊群組、共享試算表、未加密的電郵內,因為這些位置本身就是最容易外洩的位置。
第二,每個帳號要有第二種驗證因素作後備,不要只靠一部電話。 公開建議指出,為管理器帳號設雙重驗證,如有選項就設多於一種第二因素作後備(來源:公開管理器保安建議,查閱日期:2026-10-23)。後備因素可以是第二支硬件鑰匙、另一部裝置上的驗證器、密封存放的備用碼,三者之中至少要有兩種已經登記及測試過。後備因素的強度不能弱於主方法:主方法用硬件鑰匙,後備卻只用短訊,實際保安水平等於後備方法,見第四節。
第三,電話遺失、換電話、驗證應用程式轉移,要有寫明的程序。 程序至少包括:向邊個人報告、用邊個渠道報告、身份核實用哪一種方法、核實失敗時的升級途徑、重設過程有無紀錄、新驗證因素登記前舊因素是否即時撤銷。身份核實不能只靠「認得把聲」或「用舊電話號碼收短訊」,因為電話遺失時舊電話號碼本身可能已經不在員工手上。求助台冒認是多重驗證的另一條旁路:攻擊者冒認員工要求重設密碼或重新登記驗證因素;因此重設及重新登記前必須有身份核實程序,高權限帳號更要額外核實步驟(來源:公開多重驗證繞過分析,查閱日期:2026-10-23)。
第四,緊急帳號(break-glass)要事先設好、事先鎖好、事先監察。 緊急帳號的作用,是當正常管理員帳號全部鎖死、驗證因素全部失效時,仍然有一條可以恢復管理的路徑。緊急帳號的實務要求是:只在緊急時用,平時不作日常用途;驗證方法用綁定裝置的硬件鑰匙,並備有第二支備用鑰匙;登入憑證密封存放,存放地點與日常管理員憑證分開;每次使用都要有紀錄及事後覆核;緊急帳號本身也要有強驗證,不能因為是後備就用弱方法。緊急帳號沒有事先設好,出事時才想開,已經太遲;緊急帳號設好但沒有監察,緊急帳號本身變成無人看管的後門。
第五,鎖死演練要定期做,而且要做真演練。 演練不是「睇一次程序文件」,而是真的模擬:一位員工假裝電話遺失,走一次報告、核實、撤銷舊因素、登記新因素的完整流程;一位管理員假裝主密碼遺失,走一次管理員復原或緊急取用的完整流程;一次演練要計出邊一步卡住、邊一步無人識做、邊一步需要的文件或鑰匙不在手。演練發現的問題要在演練紀錄內寫明跟進人及完成日期,不是演練完就算。沒有演練過的復原程序,出事當日的第一次測試一定會在最不合適的時間暴露問題。
第六,懷疑外洩時的即時動作要分開「止血」同「調查」。 止血動作是:更改受影響及重用過的密碼、撤銷有效工作階段、撤銷可能被盜的驗證因素並重新登記、輪換相關共享密碼、檢查轉寄規則及新裝置;調查動作是:檢查登入紀錄、權限變動紀錄、共享庫取用紀錄,確認影響範圍。止血不要等調查完成,調查不要只靠記憶。涉及客戶個人資料的外洩應變,法律及通報要求要按專業意見處理,本文不作法律結論,見結語免責。
常見錯誤
- 備用碼放在同一部電話、同一電郵、同一個保險庫,電話遺失即一併失效。
- 只有一部電話一種驗證因素,換電話、電話損壞即鎖死。
- 後備方法比主方法弱,後備短訊變成實際入口。
- 求助台重設只靠認人、認聲,沒有身份核實程序及紀錄。
- 緊急帳號沒有事先設好,或者設好之後無人監察,變成後門。
- 復原程序從來沒有演練過,出事當日才發現文件、鑰匙、批准人全部不在手。
八、日常營運清單:密碼制度不是做一次,而是每個月對一次
日常營運不需要複雜的工具,需要的是一張固定周期對的清單。以下清單可以每月由老闆或負責人對一次,每季做一次較深的覆核:
- 新入職:帳號清單是否即日建立、每帳號是否獨特密碼、驗證因素是否即日登記、共享庫授權是否按角色給予、舊員工的共享密碼有無需要輪換。
- 在職覆核:檢查管理器報告有無弱密碼、重用密碼、外洩提示;弱密碼及重用密碼要逐項換,不要只睇報告總數。
- 權限覆核:檢查群組、共享庫、委派權限有無多餘成員;轉職員工的舊權限有無收回;臨時權限有無到期未收回。
- 驗證覆核:檢查邊個帳號仍然只用短訊、邊個帳號有例外、例外原因及覆核日期是否仍然有效;舊式登入協議是否仍然開著。
- 裝置覆核:檢查裝置鎖定、登出習慣、瀏覽器舊儲存是否已經清理;離開座位是否鎖定熒幕;共用裝置的登入工作階段是否已經登出。
- 離職覆核:檢查上個月離職的憑證停用清單是否全部完成並有覆核紀錄;共享密碼輪換清單是否全部完成。
- 演練覆核:檢查上一次鎖死演練的跟進項目是否已經完成;下一次演練日期是否已經定好。
- 釣魚應對:員工收到假登入頁、假短訊、無預期推送時,是否知道拒絕並報告;報告途徑是否仍然有效;求助台收到重設要求時,身份核實程序是否仍然執行。
九、簽約前要問的問題清單
以下問題全部針對「本站是否包括」而寫,因為 live /pricing 全頁沒有寫明密碼或驗證服務。每條問題都要要求對方以電郵或者服務協議書面確認,唔好只信口頭承諾;答不到的問題,要寫入協議的跟進項目,不要假設已經包括。
- 密碼管理器是否包括?包括哪一級?是商業版抑或個人版?月費已包抑或另收費?管理員控制、共享庫、稽核紀錄是否包括?
- 密碼管理器選型由邊個決定?選型準則是否書面列明(加密模型、獨立審計、共享權限、通行密鑰支援、匯出格式、復原方法)?選錯產品後的轉換成本由邊個承擔?
- 主密碼遺失時點算?管理員復原是否包括?緊急取用提名人、等候期、批准程序、取用紀錄如何寫入協議?
- 保險庫本身的多重驗證用哪一種方法?有無第二種後備因素?後備因素是否與主方法同樣強,抑或弱於主方法?
- 共享密碼如何管理?共享單位是項目抑或帳號?檢視、編輯、隱藏密碼三種權限如何分?已離職人員看過的共享密碼,輪換由邊個執行、幾時完成、有無清單覆核?
- 多重驗證設定是否包括?包括邊啲系統(電郵、雲端檔案、業務系統、遙距登入)?是否強制開啟,抑或只係「可以開」?強制範圍有無例外帳號,例外原因及覆核人是誰?
- 短訊驗證是否容許作長期方法,抑或只作過渡後備?過渡期幾時完結?管理員及財務相關帳號是否一律不用短訊作唯一第二因素?
- 推送通知是否要求數字配對?有無疲勞推送的監察及通報方法?員工收到無預期的推送,應該點做、向邊個報告?
- 通行密鑰是否包括設定及遷移?用同步抑或綁定裝置?舊密碼後備路徑是否會檢查?後備路徑的強度是否與主路徑一致?
- 舊式登入協議是否會檢查及停用?停用前有無清單,確認邊啲舊裝置或舊系統會受影響?受影響系統的替代方案是甚麼?
- 離職憑證停用是否包括?由邊個執行?清單是否包括主帳號停用、工作階段撤銷、驗證因素撤銷、備用碼作廢、共享密碼輪換、群組及委派權限移除、保險庫取用權撤銷?
- 離職停用與刪除的次序如何寫入協議?資料交接完成前是否只停用、不刪除?刪除前的覆核人是誰?完成後有無書面紀錄交給公司?
- 備用碼由邊個保管?存放地點是否與主登入途徑分開?取用有無紀錄?備用碼用過一次之後是否作廢及補發?
- 電話遺失、換電話、驗證應用程式轉移,程序是甚麼?身份核實用哪一種方法?核實失敗時的升級途徑是甚麼?重設過程有無紀錄?
- 管理員帳號如何分隔?日常帳號與管理員帳號是否分開?管理員驗證方法是否更強?緊急帳號有無、存放及監察方法如何寫入協議?
- 密碼庫備份是否包括?備份存放地點、取用權、密碼庫備份還原演練是否包括、由邊個負責做、演練紀錄點保存?以上全部要求簽約前書面確認,絕不只信口頭承諾。
- 員工培訓是否包括?培訓內容是否包括釣魚識別、疲勞推送處理、求助台冒認應對、備用碼存放、離職輪換?
- 月費不包甚麼?(例如密碼管理器授權、硬件鑰匙、通行密鑰遷移、離職憑證停用執行、培訓、還原演練,邊啲已包、邊啲另收費、邊啲不提供?)全部要求簽約前問清楚並寫入協議。
- 支援時間以哪一級為準?基礎遙距版週一至五 9am-6pm、專業進階版起週一至六 9am-6pm,超出時間的憑證鎖死或外洩應變如何安排及收費?
- 價錢以 live /pricing 當前列明為準:基礎遙距版 HK$600/月、專業進階版 HK$1,200/月、企業設備版 HK$2,200/月、全方位無憂版 HK$2,950/月、設計專用版 HK$4,950/月、旗艦網頁版 HK$5,950/月;計價單位未公佈,以查詢為準;任何一級的密碼或驗證服務範圍有變,必須以更新後的 live /pricing 或服務協議為準,不要憑本文推斷。
結語:老闆要守的不是密碼本身,而是「邊個仲入得到」這張清單
密碼管理的終點,不是全公司用同一套複雜規則,而是老闆隨時可以答到四條問題:邊個帳號用邊個密碼(答案應該是每個帳號獨特,連老闆自己都記不住全部,因為管理器記住);邊個共享庫有邊個人(答案應該是一張可以即時拉出來的清單);邊個帳號用邊種驗證方法(答案應該是管理員及電郵用最強方法,一般員工至少用驗證器或以上,短訊只作過渡);邊個人離職之後邊啲憑證已經停用、邊啲共享密碼已經輪換(答案應該是一份有覆核人的書面紀錄)。答不到這四條,密碼制度就只是買了工具,沒有建立制度。
本文是一般資訊,不是法律意見。如涉及《個人資料(私隱)條例》(第 486 章),特別是保障資料原則四要求資料使用者採取所有切實可行的步驟保障個人資料免受未經授權或意外的查閱、處理、刪除、遺失或使用(來源:條例原文原則四,查閱日期:2026-10-23),本文的密碼及驗證做法只是其中一類可考慮的切實可行步驟,不是「用多重驗證即等於符合條例」的結論;具體安排是否足夠,要按資料種類、可能造成的損害、儲存地點、設備保安措施、取用人員、傳送保安整體判斷,如有疑問,應諮詢專業意見。價錢及套餐範圍以 live /pricing 當前列明及雙方簽署的服務協議為準,本文的通用做法不構成任何服務承諾。
- 最後覆核日期:2026-10-23
- 適用版本:對應 live /pricing 當時六級收費(見引言一節)