業務安全(quán)架構的一些見解 從研發到白盒滲透測試

業務交互流程實際上取決于具體提供的功(gōng)能、數據和邏輯。例如，從業務層面來看，它是否會涉及敏感數據、涉及的數據是否已經處理等。；應用和中間部件、應用和中間部件是承載整個(gè)業務的具體體現，也是應用安全(quán)和數據安全(quán)關注的焦點。從安全(quán)研發培訓到安全(quán)包SDK，從代碼白盒掃(sǎo)描到卡發布，數據生産如何提供給應用，如何應用消費，如何實現相應的權限控制等。基礎網絡架構，一個(gè)請求如何從客戶端到服務，服務是通過哪些路由直接完成的。這可能是個(gè)問題。需要注意的是，軟件架構師給你的評估文件中的網絡架構圖可能隻是他所知道的一部分，更多的時候，他們似乎不關注；物理部署狀态，IDC還是雲，刀片服務器還是ECS？雲服務器還是一個(gè)問題。除了自個(gè)的設置之外，還需要考慮APS系統本身的設置範圍和其他所有不同的設置，還需要考慮APS系統的設置。

盡管如此，即使能夠真正遵守(shǒu)規範，建立起評審機制，但是在(zài)大型企業中，結構評審的工作(zuò)仍然可能很多。商業叠代變化很快，每周都會有幾次結構評審，如何提高效率？先将可自動化的自動化掉，比如安全(quán)産品的部署，以及黑白盒的掃(sǎo)描。第二，将無法自動化的能力轉移到測試部門、研發部門，使之具有安全(quán)屬性。使研究與(yǔ)開發能夠理解安全(quán)包的使用，并具有編寫安全(quán)代碼的能力，同時使測試部門能夠具備一些基本的滲透測試能力。較終将既不能自動化也不能轉移的能力沉澱在(zài)知識庫和案例庫(踩坑經驗的Checklist)中。它是第一步，第二步是跟蹤結果，根據結果建立積極(jí)的反饋，驅動或推動其他團隊繼續跟進。

當然，還有一些細節沒(méi)有寫，相關的結構評估表也沒(méi)有貼出來，那麽如何才能成爲(wéi)一名合格的安全(quán)結構師呢？相信大家都心裏同樣有自個(gè)的答案。當你有這樣的視野時，許多事情并不難自己做。

安全(quán)性結構不能一蹴而就，企業也不能僅僅依靠滲透性測試來完善安全(quán)防禦建設。随着技術的進步，更需要能準确地辨别是炒作(zuò)還是跟風。作(zuò)爲(wéi)企業安全(quán)部門的重要角色，安全(quán)架構師在(zài)具備相應能力的同時，不斷學習也是一個(gè)不容忽視的方面。但願以後安全(quán)行業的從業人員中能有更多合格的安全(quán)架構師。身爲(wéi)安全(quán)行業的小朋友，還有很多地方需要學習。一路上，謝謝。夜深人靜，擱筆。