安全與合規

資訊安全管理系統（ISMS）對企業資產的全面保護加上 DevOps 對數位產品價值的驅動力，為企業帶來四大顯著價值： 1. 規範式敏捷 組織可基於最小可行治理原則達成企業目標，同時又能讓創新與響應變化保持彈性。 2. 降低成本 以自動化的方式進行持續整合、測試與交付，取代原先耗費大量人力與紙本的繁瑣驗證。 3. 可視性 以價值流為出發並以數據作為驅動，提升整體流程與資訊的透明度。 4. 業務持續性 透過關鍵指標的建立、持續性監控與快速響應，提升企業數位業務的韌性。 無論以利害關係人、工程人員或是稽核人員的角度，透過 DevOps 的實踐可大幅地促進組織在 ISMS 實施與審查的效率，讓企業在顧及安全性與可靠性的同時，保持市場的競爭力。 CPHT 擁有豐沛的實務經驗與領域專家，能夠為企業打造基於安全與有序的 DevOps 顧問與培訓方案。歡迎進一步了解我們的企業服務。

早在 2020 年，歐盟便提出數位服務法(Digital Services Act)，而在今年四月，歐盟議會與成員國對該法達成一致1。台灣也在今年跟進了這個法案，並且提出了數位中介服務法的草案。頓時，「言論自由受到箝制、影響國際競爭力、扼殺產業」等聳動的標題與質疑躍於媒體之上。然而對於使用者的我們來說，該如何看待此事？ 大家還記得嗎？一年多前的美國總統大選，關於社交平台的輿論操弄與控制一事吵得不可開交。還記得嗎？每逢台灣選舉或者各種特殊事件時，社交平台便會出現所謂的水軍與帶風向。另外，大家是否曾經擔心受怕自己經營許久的臉書2、IG3、Youtube4、Twitter5等社交平台上的內容被無故停權，甚至被消失嗎？在此類的事件裡，可曾想過如果有誰能夠幫忙你要求平台業者給予你更好的回應，那該有多好嗎？ 而這個誰能是誰？是平台業者？是某個正義的勇士？還是只有你安身立命所在國家的政府呢？此外，在這些虛擬資產上，政府是怎樣的角色呢？ 數位轉型的風也吹了好些年，而政府為了數位發展甚至成立了數發部。所謂的數位轉型是透過數位的力量，形塑新的商業價值。政府向來對於實體財產有較完善的管理法規，但對於數位服務與虛擬資產來說，則甚少有很好的著力點。政府開始關注虛擬資產，試著為人民提供必要的價值，是否對於政府來說才是該有的數位轉型呢？以此而言，數位中介法便是個很好的著力點。 歐盟為此法提供了一個很好的先例，但實際上要如何訂立規則，才能面對演變迅速的虛擬世界與所處的國情呢？我想並沒有一個很好的最佳實務做法，但可以想見的是抨擊與疑慮肯定會與 GDPR 公佈時一樣沸沸揚揚。這些疑慮大致上不外乎兩種，一種是言論自由，而另一種則是影響產業發展。近幾年，花了大量的時間研究個資與隱私保護和一些國際法規的演變與發展之後，每次看著「言論自由」這個詞彙，總會不禁想起一個問題： 當資訊不對等且受到操弄時，我們所做出的判斷與言論，還能稱得上自由地表達了想法嗎？ 進一步地翻開草案的總說明文件6，可以發現法案的初衷： ...民眾已普遍透過個別要求，使用藉由電子方式遠距提供之數位格式之服務。其中,尤其是線上平臺服務，已不再只是單純利用各項服務，而是得以一同參與、互動、形塑服務內容之提供；因此民眾使用數位中介服務，已為日常生活的組成部分，同時也為民眾個人及社會全體帶來新的風險及挑戰。為適應數位中介服務轉換及創新之驅力，建構安全、可預測及信賴之網路環境，並維護憲法所保障之基本權利... 或許我們不需要法案的特別說明，都能深刻理解與認同這些服務已經走入我們的生活，並且驅動著我們的行為與思考。當我們因為某些傳播開來的訊息而忿忿不平，甚至為此在自己的虛擬空間裡留下足跡時，我們是否想過： 當資訊不對等且受到操弄時，所留下的足跡真的是你我想要保護的資產嗎？ 當服務提供者為你極力地吶喊著自由，或者是任意的第三者為你極力地吶喊著自由時，你是否在一同群情激憤之前，稍微停下來思考一下「這些自由本身與背後意圖是否與你所想像的一致？」還是只是字一樣而已？自由何其珍貴，而真正的自由需要在資訊對等與透明的情況下，以不受外力影響的心智表達自己真正的想法。 因此，我個人對於法案的提出，反而抱持著積極的態度！ 首先，若是台灣率先提出此類法規，礙於市場規模，我認為法規所能發揮的約束力可能相當有限，然而當具有更大市場的歐盟對同類法規達成一致時，台灣便可以有更好的施力點，甚至能讓台灣跟上國際對於此類議題的腳步，而進一步協助產業完善相關機制，走出國門！產業不應以競爭力為由作為反對的訴求，而政府也不應該只是提出法案，更應該協助產業完善自身的管理，或者提供技術與資源上的協助。不過對於法案的內容倒是有一個擔憂之處： 在有限時間裡，法院是否有足夠資源與能力有效地為此法案提供服務，並且做出合理的判定？ 為了讓法院能夠有效地進行判斷，主管機關是否能夠確切且有效地提供足夠且適切的資料來協助法院進行判定，將是極為重要的事情。因此，主管機關應當善盡查證義務，並且盡可能地保持資訊透明與公正。據此，有以下建議： 法規雖然對於裁定結果有揭露的要求，但應該要求主管單位提供更為主動且易於閱讀與理解的資訊。大家不妨想像一下！當社會出現爭議事件時，看著判決書資料庫介面，我們是否有能力可以查到對的資訊？當我們想要從資料中得到關鍵的洞察時，我們是否能夠輕易地匯整出關鍵的資訊？因此，主管單位應當提供簡單易理解的統計資訊儀表板，針對被提起的議題品質與背後成因進行分析，並且揭露。

前言 隨著企業提升響應市場變化的速度，不管企業的規模為何，抑或屬於哪一種產業，DevOps 儼然成為現代 IT 的重要典範。但在快速迭代的業務發展下，由於傳統的安全治理較為繁瑣，也使企業在導入 DevOps 的過程中，從需求、設計、實作，到後續的監控和改善，較難看見充分的安全實踐，組織亦缺乏在每個流程階段，衡量當前安全的成熟狀況。 什麼是 OWASP DSOMM？ DSOMM 2 的全名為 DevSecOps Maturity Model（DevSecOps 成熟度模型），或許大家較耳熟能詳 OWASP 的另一個軟體安全的成熟度模型 SAMM（Software Assurance Maturity Model，軟體保證成熟度模型），SAMM 針對五個業務功能（治理、設計、實作、驗證、維運）定義了一系列的安全實踐及評量指標，協助組織將安全覆蓋至全軟體開發生命週期。SAMM 為較高層級的規範性模型，而 DSOMM 則為更具體的 DevSecOps 實踐。

安全的運行環境對於雲端服務來說，是個重要的議題，而對於使用者來說更為重要。 因此，對實體或虛擬主機進行弱點檢查與監測，能為雲端服務提供一個安全的基礎，也能滿足組織對於資安的基本要求。然而，安全威脅多樣，且各式作業系統的組態設定又各有巧妙，要如何才能有效率地完成這個工作，對於維運人員來說是相當令人頭疼的事情。 SCAP2 (Security Content Automation Protocol) 是由美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST3)所維護與制定的協定，主要用意是為主機的組態設定與安全需求提供一個共同交互與發展的基礎。同時也為 NIST 800-53 關於運行主機的安全要求與最佳實踐提供一個自動化的基礎。 OpenScap4 則是基於 SCAP 的具體實作，它主要透過使用 SCAP 裡的 XCCDF5(Extensible Configuration Checklist Description)與 OVAL6(Open Vulnerability and Assessment Language)。XCCDF 透過 XML 形式的描述語言具體地提供評估與檢查一個主機時，應該進行的項目列表。測項可能是一些安全需求下的組態設定的檢查，也可能來自 OVAL 所識別的弱點測試。