ISO 22301 (BCMS 營運持續管理系統) 主導稽核員

-

隔了很多年之後，難得又有機會參加ISO 22301  (BCMS 營運持續管理系統) 的原場主導稽核員培訓課程。最大的挑戰，當然還是仔細閱讀條文，並準備第五天下午的考試。稽核員考試多半已採用數位線上考試，ISO 22301比較特別一點，在2026年的現在仍維持紙筆測驗，但考試為秉持公平原則，只提供條文本文於作答時查閱。不可以參考其他材料。

比起大家耳熟能詳的ISO 27001，BCMS雖然為「數位發展部資通安全署」認可之資通安全專業證照，但它著重的重點就不只在資訊技術，而是讓導入單位提供產品的活動，盡可能不要發生無法控制、無預期的中斷(disruptions)。若發生，則應從中斷中復原(recover from disruptions)。

想當然爾，會導入本標準的單位，花錢事小。它們看重的是基礎關鍵設施或服務的責任，或是在意商譽、營業收入或信譽的重要營利事業單位。

BCMS的重點在提供一套架構與方法論，幫助導入的機構依照一套類別與準則，整理出對應的最大可容忍中斷時間(MTPD)，以及讓服務至少回復到最低時間的回復目標(RTO)。鑑別出與產品或業務最相關的關鍵活動(prioritized activities)。

光找出關鍵活動並沒有用。單位必須在事前採取借鏡自 ISO 31000的風險處理架構，預先將關鍵活動相關的中斷風險都先盤點，並採行風險處理措施。

假使單位遇到極罕見但依然發生的災害，或者人禍時，則進入第二道防線──啟動BCP計畫，讓應變團隊與資源(人、機、料、法)分別就緒，透過人員撤離、移轉場區、使用備用機台.....等不同方式，盡量減少業務中斷的時間。人命的損失難以估計，因此安全問題必須被優先考量。此外，對生產事業而言，可能仰賴選商取得諸多原物料或資源，亦可能是要將商品轉運、加工，委外廠商與供應鏈亦應考慮其中。 國際衝突、全球化與氣候變遷，還有ICT的備妥性等等，自然也是不能忽略的環節。


參考:

https://www.iso.org/obp/ui/#iso:std:iso:22301:ed-2:v1:en


 

 


留言

張貼留言

這個網誌中的熱門文章

The Disk2vhd Disaster — and How StarWind’s V2V Brought Redemption! --About Windows Server 2012 STD P2V

-
Our company has been operating a Windows Server 2012 STD host installed on a physical 2U rack server for years. As services on the machine are nearing decommission and hardware failure risks are increasing, we've decided to virtualize the system to streamline operations. Summary(Suggestion) Use StarWind’s V2V Converter / P2V Converter directly — it saves valuable time. If you have sufficient privileges, the converted system can be mounted directly to another Hyper-V host . If the server has multiple partitions , choose to clone the entire physical machine. Avoid converting individual disks separately to prevent unexpected complications. Background ChatGPT and Microsoft’s commonly recommended P2V conversion tool is Disk2vhd . It allows conversion without shutting down Windows. Most articles from ~10 years ago suggest this tool. I initially tried splitting the system: storing the recovery and C drive in one VHD, and the database D drive in another, to reduce file size. Sy...
Read more »

如何刪除Trello的卡片資訊 (deleting Trello cards)

-
圖片
Trello是個很棒的圖形化任務管理工具，對於想試試任務管理、看板方法的人相當有幫助。依照Ruddy Lee 所言 [ 原文出處 ] ，「讓工作流程被視覺化，讓我們的決策更接近事實、更容易作為改善的依據、更容易管理及更有效率」。這句話實在說得太棒了。 Trello很容易上手，唯獨在某件事情上有些困擾。如果放了不需要的卡片，該如何將其真的刪掉呢？依照程式預設的介面，卡片只是被「封存」(Archive)，實際上還存在Trello之中。 原來的Trello應該是考慮防呆或誤刪，不讓卡片輕易消失。但這樣容易累積很多垃圾卡片，日子久了很難進行整理。 參考Trello的 [ 官網 ]，真的要刪掉任務卡片，請點 Archive按鈕下面的一行灰色小字 Share and more....，在展開的對話方塊的最下方， 才會出現 Delete的選項。這樣，才是真正的刪除。
Read more »

Redis 在 C#的應用

-
Redis適用的場合   1.代替主機的Session機制，利於擴展多部主機  2.簡單、不講求精準的計數，如人氣排行榜等；可以容忍部分lost  3.極端要求前端回應速度、使用者體驗好的場合 (轉址查詢) 4.有許多人查詢"共同"、高度相似的資料集，讀多於寫 (查選課...火車班表...公車路線) 5.有某些資料是會定期失效清除的(Token) ，例如實作登入失敗進行鎖定的機制 6.競爭性資源的鎖定機制，例如 搶票系統的交易鎖( SETNX )   Redis不適用的場合   1.只有後端管理者在使用的場合，沒有多人競爭、搶快的必要 2.全都講求即時計算，不能接受時間差  3.因為精準數問題，避免儲存金額或是貨幣數字 4.沒有足夠資源建置cluster機制，單點失效或快取miss造成的損失與遲滯問題反而更嚴重   Redis Key的設計與使用 1.利用namespace的方式來標示有意義的內容，如 usr:vip:faculty:sigfried  2.key 跟 value不要過長(key 小於1K)  3.思考每筆key的生命週期該存活多久，設定有效期限  4.針對人、事、物資料可以把資料抽象到一個雜湊表裡；不要把JSON 的key-value 組合拆開、一個個當字串值塞進redis 的value  5. keys 指令 會把效能拖垮， 用 keys xxxxx* 無法預估筆數；應該 用scan 取代，可以限制回傳筆數、分批執行，例如 redis-cli scan 0 match key99* count 1000  6.設計key 時避免使用特殊字元     Redis Key的設定與組態 1.記得設定密碼認證，並限定存取來源 2.將敏感、耗時語法rename，避免在production遭到誤用，例如:  rename-command keys mykeysys 3.C#應用不使用using資源語法，因為是單執行緒 4.利用docker環境安裝 5.擷取 redis 最大占用記憶體      config get maxmemory  6...
Read more »