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

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

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

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

缺乏透明度

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

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

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

缺少資料監管

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

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

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

缺乏審計或系統提供商

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

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

第三方 程式碼安全審計

進行黑盒測試

法定證書和協議

獲得網路安全保險

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

基於業務的邏輯錯誤

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

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

綜述

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

文章來源：

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