技術與實務

讓安全為數位轉型護航

讓安全為數位轉型護航

COVID-19 的疫情進一步地加速了全球數位轉型的腳步,按微軟 CEO Satya Nadella 所述1「當前兩個月所獲得的數位轉型進展是過去需要兩年才能達到的成果」。數位轉型透過數位的力量為客戶帶來更好的使用經驗,提升企業競爭力的同時,也進一步地擴大了可被攻擊的接觸面積,根據 Ponemon2 的 2020 研究報告指出,受訪者中有 82% 表示其數位轉型項目至少經歷一次資料外洩的問題。另外,為了能夠更了解客戶,提供更完善的服務,資料的收集與應用更是當前商業競爭的重中之重,然而隨著日漸提升的資料隱私保護意識,與相關規範的建立與落實,資訊安全已然無法視為NICE TO HAVE的選項,而是MUST TO HAVE的因子。因此,在考慮數位轉型策略的同時,將安全納入考量,並且雙軌併行,才是當前企業所應該考量的作法。 鑑於此,筆者認為企業把資訊安全融入數位轉型中,有五個關鍵步驟! 1. 了解組織的資訊安全能力 唯有了解自身當前的狀況,才能知道與需求之間的落差! 在規劃數位轉型計畫的同時,誠實地面對組織當前實施安全的現況與能力,才能夠了解與期待之間的落差,並且建構可行的路徑。所謂可行的路徑,便是逐步地將安全工具、驗證能力、與安全文化逐步地與數位工具與商業服務進行融合。也只有透過一開始便考量安全,才能夠務實地將安全融入數位轉型的過程中。 數位轉型所涉及的層面包含了工具採用、文化和流程變更、與人才培養,過程必然對組織裡的每個人產生衝擊。如果將安全作為轉型成功後,才進一步加強的目標。可以想見的是安全將永遠會是拖慢並且減損轉型成果的障礙! 2. 將所屬產業的安全需求納入規劃 企業經營自然無法自外於當地法規對於所屬產業的要求,也無法無視消費者對於企業的期待。因此,數位轉型絕非暫緩合規要求的理由,相反的是一開始便將合規需要納入轉型中,才是事半功倍的最佳途徑。試想當組織內的成員好不容易適應新作法後,卻要立即地面對加入額外要素的作法變更。調適與落實所產生的成本將會是企業無法承受之重。 對於並無具體法規規範的產業來說,基於自動化工具所採用的安全規範與指引,將會是比較直覺且成本較低的選擇,比方說 NIST 與 OWASP。

繼續閱讀
自動化建置 GCP HTTP 負載平衡器

自動化建置 GCP HTTP 負載平衡器

開始接觸 Pulumi 後,發現 GCP + Python 可以參考的資料很少,以建置 GCP HTTP Load Balancer 來說,Pulumi 官方提供了 Typescript 的寫法1,若自行對應相同資源的 Python API 範例,則會在執行時遇到一些小錯誤(稍後會提到)。因此本篇將會分享如何透過 Python 建立 GCP HTTP Load Balancer,完整的實作程式碼請至 GitHub 2查看。 架構說明 透過 HTTP Load Balancer,將請求導流至後端的 Nginx 伺服器,由於 VM 在初始化時,會透過 startup script 從外網抓取相關套件並安裝,因此需要為 VM 配置 Public IP 或 NAT proxy,讓 VM 可以與網際網路進行通訊。但為安全考量,我們只允許來自 Load Balancer 的請求,禁止透過 VM 的 Public IP 來存取服務。

繼續閱讀
User Story Mapping

User Story Mapping

牆上掛著滿滿的待辦事項,大家你一言我一句地為團隊產品貢獻自己的想法與點子! 上述是當我們談起設計思維,甚至是敏捷時,頭腦中會浮現的景象。然而,當待辦事項在不同成員齊力產生出不同抽象程度的工作項目時,試問我們要如何有效地從中找出最重要的事情,並且準時地交付給客戶? User Story Mapping 是管理使用者故事的一種有效技巧,不僅能夠協助團隊逐步地構建產品的待辦項目,也能夠用來整理已經開始迷航的待辦項目黑洞。它具體有以下好處: 以使用者為出發點,透過使用者旅程逐步具體化使用者故事; 確保所有參與者圍繞在同一個產品目標與主題上; 具有全局觀的排序,產生可執行的釋出計畫; 簡單易懂的可視化待辦事項結構; 引起討論,促進協作。 環境與工具 便於走動與張貼的環境,可以善用團隊常用的戰情室; 白報紙數張(如果不夠大可以接在一起)或白板一個; 建議人數 <= 8 人/組; 白板筆 x 三種顏色 ; 便利貼一包 x 三種顏色; 計時器; 安全可開放討論的氛圍。 流程 步驟一:由召集者或者是產品管理者,說明此次的目標,並且確保所有參與者了解 (~ 10 分鐘): a.

繼續閱讀
為你的自動化基礎設施拉上保險系列之二

為你的自動化基礎設施拉上保險系列之二

Policy (政策) 政策! 是什麼東東 ? 提到政策,就會不小心想到治理、授權等等讓人頭皮發麻的詞。然而,政策在軟體服務中是相當常見的某種需求。簡單來說,軟體服務的政策是什麼呢? 一組管理軟體服務行為的規則。 舉凡,定義哪些是受信任的主機、使用者能夠存取哪些功能、網路路由、和服務可以部署到何處等,都能視為服務管理政策。所以當你試著實作 feature toggle、試著實作管理員和一般用戶等功能時,便已經涉及到服務政策的機制了。 傳統上的作法,工程師會在服務中實作相關的資料存取與檢查。先不論此類實作所耗費的額外運算資源,如果有多個團隊在實作多個服務,而都需要基於相同規則進行檢查時,要如何進行?如何能夠和服務管理政策管理者有更好的合作?落實管理政策與提供服務彼此之間如何不互相拉扯等待,而導致服務提供效率降低? 追根究柢,可以把問題濃縮成: 如何讓開發團隊專注在產品主功能開發,讓政策管理者能夠用一致的方法進行管理,而且兩者之間的更動不會輕易地影響對方? Open Policy Agent 為這個問題提供了一個新的解決方式! Open Policy Agent (OPA) Open Policy Agent(OPA, 讀音為 歐趴) 最初是由 Styra 所建立,後來貢獻到 CNCF。目前由 Styra、Google、Microsoft、和 VMWare 構成開源專案的主要貢獻者團隊,撰文的當下它也已經順利地從 CNCF 畢業了。OPA 實現了一個輕量的政策管理服務,因此可以作為服務的 sidecar 運行,也能作為獨立的政策管理服務運行於整體服務群內。軟體服務可以基於給定的資訊透過 RESTful API 的方式「查詢」相關政策的判斷結果。此舉成功地解耦了政策管理的相關實作,讓軟體服務可以專注於使用者功能,至於政策則可以透過一個獨立的服務來實現。政策的管理者與資源的提供者,可以透過統一的管理服務來更新相關政策,從而改變團隊的合作模式,並且可以更高效且一致地施行政策。

繼續閱讀