低程式碼/無程式碼平臺為網路安全帶來哪些挑戰?

zktq2021 發表於 2022-01-24

通常,應用程式開發需要花費大量的時間來規劃、設計、測試和優化編寫的程式碼。為了滿足日益增長的快速應用程式開發需求,公司現在意識到DevOps可以擴大開發人員和IT運營商之間的協作。其中一種方法是低程式碼、無程式碼技術。隨著低程式碼開發市場的快速發展,預計到2021年將增加138億美元。

近年來,低程式碼平臺已經出現在技術領域,通過視覺化工具取代程式碼編寫,實現更快的應用程式開發。沒有程式碼屬於“低程式碼”這一術語,這意味著軟體的設計和建立不需要程式碼。想想像WordPress或Wix.com這樣擁有網頁設計工具的平臺。

讓我們來看看圍繞這些平臺的最常見的安全挑戰。

缺乏透明度

當談到低程式碼技術時,可能最大的挑戰是公司無法控制員工開發的內容。如果沒有IT方面的透明度,就很難管理正在構建的內容,公司也會失去對其低程式碼安全風險的跟蹤。

其中大部分與非程式碼流程有關,這些流程已簡化、可轉移且可供未經培訓的員工使用。在傳統的軟體開發中,專家和開發人員在整個安全軟體開發 (SSDLC) 生命週期中的共同編寫程式碼。

為了避免這個問題,組織在開發應用程式時應該積極關注開放可見性。對於無程式碼工作場所,可以通過雲解決方案來實現。有了基於雲的平臺,就有了更大的工作流整合,這為可見性和跟蹤提供了機會。

缺少資料監管

在談論資料管理時,一個常見的問題是:誰有權訪問資料,資料是如何受限制或使用的。畢竟,資料對任何公司來說都是寶貴的資產,而且存在被惡意利用的風險。組織允許的控制級別因平臺而異。

當涉及到資料時,它可以指代被利用風險較低的資料。例如,如果一個組織的分流系統存在程式碼洩漏,這並不是一個真正的問題。另一方面,無論大小,組織通常都擁有黑客可以利用的業務運營中使用的關鍵資料。想想客戶地址簿、獨特的商業軟體、敏感的銀行資訊等等。發生資料洩露會給公司帶來很大的麻煩。

例如,作為一個媒體管理和儲存工具,Dropbox允許使用者共享、授權或限制資料,並跟蹤更改變化。然而,在資料管理領域,有更復雜的工具可以提供更深入的日誌記錄、重新共享和訪問控制(選擇性地分配訪問級別),而這些工具在許多無程式碼業務應用程式中是找不到的。

缺乏審計或系統提供商

由於低程式碼企業的構建者和所有者本身就是公司,他們也採取了預防措施來保護自己的數字資產。從這些供應商那裡獲得幫助的公司無法訪問程式程式碼或進行控制。這樣,他們就不可能完全檢查這些系統,以識別或檢測軟體錯誤。

希望執行安全控制的客戶必須在可用資源的限制範圍內這樣做。例如:

第三方 程式碼安全審計

進行黑盒測試

法定證書和協議

獲得網路安全保險

為了讓客戶放心,低程式碼提供商已開始遵循更清晰的加密方法。同樣,安全審查程式碼的透明度或呈現方式完全取決於所選擇的平臺。

基於業務的邏輯錯誤

低程式碼業務解決方案具有內建許可權和各種控制功能,通常基於對客戶偏好的洞察和先前的分析。這使企業可以輕鬆構建安全的應用程式。但當從業務角度看待軟體開發而忽略 IT方面時,就會出現問題。這也很常見,因為現在構建應用程式要容易得多,這可以可以看作是更多的非技術工作和更少的程式碼衝突。然而,任何技術都存在安全風險。

當這種情況發生時,人們就會在低程式碼或無程式碼平臺上迷失自己的創造力或業務,並最終犯錯誤。業務邏輯問題不能用工具識別,因為它們主要是由人為錯誤引起的。

綜述

眾所周知,無程式碼平臺基於便利性和易用性有其自身的優勢。另一方面,這些平臺用有問題的安全方法來支付傳統的代價。底線是,必須應用程式碼級別的網路犯罪保護和安全加密程式,尤其是在“全民開發”進行應用程式開發時。


文章來源:

https://gbhackers.com/security-challenges-in-low-code-no-code-platforms/


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70000012/viewspace-2853723/,如需轉載,請註明出處,否則將追究法律責任。