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

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

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

安全性結構不能一蹴而就，企業(yè)也不能僅僅依靠滲透性測試來完善安全防御建設。隨著技術的進步，更需要能準確地辨別是炒作還是跟風。作為企業(yè)安全部門的重要角色，安全架構師在具備相應能力的同時，不斷學習也是一個不容忽視的方面。但愿以后安全行業(yè)的從業(yè)人員中能有更多合格的安全架構師。身為安全行業(yè)的小朋友，還有很多地方需要學習。一路上，謝謝。夜深人靜，擱筆。