一千萬個為什麽

搜索

當工程師部署和運行代碼時,哪些流程或工具能夠實現責任分離?



在高度監管的環境中,例如金融服務部門,職責分離是避免重要機制在發展責任和生產特權的個人之間發生沖突。

傳統上,這意味著開發人員開發代碼,然後將其交給運營,但是在許多DevOps運營模式中,開發和運營之間的隔離至少是模糊的:

花了幾個月時間鉆研責任分離機制的根源之後,它似乎主要存在以滿足 Sarbanes Oxley 404條款:內部控制的管理評估:

(a)規則要求。   歐盟委員會應制定規則,規定1934年“證券交易法”第13(a)或15(d)條規定的每份年度報告應包含內部控制報告,      (1)說明管理層建立和維持適當的財務報告內部控制結構和程序的責任;和     (2)截至發行人最近一個會計年度末,評估發行人的財務報告內部控制結構和程序的有效性。     (b)內部控制評估和報告。關於(a)款規定的內部控制評估,每個為發行人編制或發布審計報告的註冊會計師事務所均應證明並報告發行人管理層所作的評估。根據本款作出的證明應按照董事會發布或采納的鑒證業務標準進行。任何此類證明不得作為單獨約定的主題。

根據評論意見,重要的是要提出一些假設我正在做:

  • I am predominantly considering mass-market financial services, i.e. transaction volumes are high but relatively low value. This would be as opposed to commercial financial services which has a different transaction value profile.
  • A financial institution's online offering will be made up of many components that have differing risk considerations:
    • Move Money - Moving money between accounts or transfers between accounts of different owners. An operation that has to consider Anti-Money Laundering, Fraud Protection, and Embargo'ed countries to name a few.
    • Customer Acquisition - Less "Risky" as it has low transaction volumes compared to Move Money but still needs consideration.
    • Internet Banking - Covers a wide range of services with varying levels of risk, Move Money would be considered part of this.
  • Conceivably a different approach could be taken for each depending on the risk, however, in the interests of keeping it simple, I am working towards a solution that would apply to some of the riskiest operations.

TL;DR: It is the responsibility of the management to ensure that adequate internal controls are in place that comply with the Securities and Exchange Commission's regulations.

Sarbanes Oxley 404通常通過完成自上而下的風險評估來滿足,其中一部分將評估共謀風險並提出緩解策略。

在采用DevOps實踐和文化的公司內部,開發人員可以定期訪問源代碼管理和生產,如何實現職責分離,或者更普遍地如何緩解共謀風險。

轉載註明原文: 當工程師部署和運行代碼時,哪些流程或工具能夠實現責任分離?

一共有 3 個回答:

你的問題似乎沒有對它所涉及的平臺/操作系統做任何假設。這就是為什麽在大型機環境中添加關於如何完成/解決這個問題的答案是有意義的,在這種情況下,“工程師”(如問題標題中)實際上是幾十人(可能有幾百人)的人群參與其中。我的回答是基於使用我最熟悉的SCM產品(不知道是否需要公開產品名稱)。


1.建築


以下是我如何回答你的問題的亮點:

  • 所有代碼(以及相關的工件,如可執行文件等)都存儲在文件中,這些文件一起被稱為 庫結構
  • 對於每個(可能是遠程的)目標系統上的每個環境,都有一個服務器(在大型機中稱為“啟動任務”),它負責對庫結構中的任何內容進行ALL(全部重復)更新。有一些例外情況(如安全人員或空間管理團隊),但除此之外,沒有人(重復:無人)有權將更新應用到該庫結構中的任何文件。換句話說: 服務器獲得對整個庫結構的獨占更新權限 。註意:如果你走進去限制他們的訪問(首先他們會抵制......),那麽OPS人們會去瘋狂的,所以要確保你被高層管理人員(CxO)所覆蓋,以實施這些訪問規則......
  • 實際的軟件改變了我由一個組件組成的一個組件(一個在半夜微小的代碼修復......),或者它也可能是數百或數千個來源,可執行文件或任何其他工件(在發布期間周末)。為了使它們易於管理,應同時將(或多或少)移動的內容捆綁在一起,稱為 軟件更改包
  • >

有了上述內容,服務器應用到庫結構的任何更新都只能通過定義明確的工作流程來實現,我們稱之為 軟件更改包的生命周期 (如果您願意,可以使用SDLC)。要真正執行該工作流程中的各個步驟,就需要這樣做:

  • 只有服務器才會執行所需的(及預先配置的)步驟。
  • 在完成所需的批準(來自人類)以執行此步驟後,服務器將僅執行特定步驟(=更新庫結構中的某處)。
  • 批準只能由擁有角色的用戶提供,允許他們(=權限)發布此類批準。

2.角色和權限


The server will ensure that the user trying to make something happen (like 'approve something') will only be able to do so, if the user's permissions are appropriate. That part is easy. But you don't want to use the SCM system to administer all those permissions for all the users involved, that's what belongs in your security system (not the SCM system!), so that you can adapt your workflow (in your SCM system) to go check those permissions whenever appropriate. The steps below provide some more details on that.

第1步:配置權限(在安全系統中)

  • Define security entities in your security system, with well defined names for those entities. A few samples (add as many similar ones to fit your own needs):

    • PrmUnit, used for getting permission to request a Promote to say Unit-testing.
    • PrmQA, used for getting permission to request a Promote to say Qa-testing (let's assume this is the highest level of testing).
    • PrdEnduser, used by end-users involved in some level of testing, to indicate that they are satisfied by the results produced by some kind of testing. And because of that, those end-users agree with the change moving forward in the library structure.
    • PrdRelmgnt, used by release managers to authorize an Activation in production (= the last/highest level in the library structure).
  • Define groups of users in your security system. A few samples (add as many similar ones to fit your own needs):

    • GrpDevs, which (say) corresponds to your developers (probably more then just 1).
    • GrpEnduser, which (say) corresponds to your end-users (at least 1, preferably with more similar users).
    • GrpRelMgnt, which (say) corresponds to your release managers (at least 1, preferably a few more users).
  • Grant permissions, also using your security system, to allow access to selected "security entities" for selected "groups of users". To continue the example above, here is what seems appropriate (adapt to fit your own needs):

    • Group GrpDevs gets access to (only!) security entity PrmUnit.
    • Group GrpEnduser gets access to (only!) security entity PrdEnduser.
    • Group GrpRelMgnt gets access to (both!) security entity PrmQA and PrdRelmgnt.

第2步:配置工作流程(在SCM系統中)

在您的安全系統中配置權限後(如第1步中所述),SCM系統中的所有工作就是配置生命周期中各個步驟與安全系統中相關安全實體的匹配方式。也就是說,只有那些對所需安全實體具有適當訪問權限的用戶才允許請求服務器執行工作流程中的相應步驟。

下面是一些如何配置SCM系統來實現一些魔術的例子:

  • 如果用戶可以訪問 PrmUnit ,那麽這樣的用戶可以請求升級單元 - 測試。很明顯, GrpDevs 組中的用戶是授權的用戶(註意:不是,例如組 GrpRelMgnt 中的用戶)。
  • 如果用戶有權訪問 PrmQA ,則允許該用戶向 QA - 測試請求升級。很顯然,組 GrpRelMgnt 中的用戶是授權此用戶的用戶(註意:例如,不在組 GrpDevs 中的用戶或組 GrpEnduser )。
  • 如果用戶有權訪問 PrdEnduser ,則允許此用戶授權在庫結構中向前移動的更改(這通常是組<�代碼> GrpRelMgnt 甚至可以查看更改)。顯然, GrpEnduser 組中的用戶是僅此用戶授權的用戶。
  • 如果用戶有權訪問 PrdRelmgnt ,則允許該用戶在生產中授權 Activation (=庫結構中的最後一個/最高級別)。

3.期待意外,並為此做好準備


以上只是一個藍圖,希望有助於理解最終它是如何處理職責分離的服務器......只要您有CxO掩蓋您強加一些不是每個人都會喜歡的訪問規則。

為了完成上述的圖片,服務器創建一個審計跟蹤(記錄)系統中發生的任何事情。所以在任何時候,總是可以回答這樣的問題

什麽時候發生以及為什麽,以及哪個授權用戶實際上批準了它...... upfront?

但是,可能最難的部分是有足夠的報告工具可用(並知道如何使用它們)。至少(很容易)滿足IT審計員的要求(他們的問題可能非常具有挑戰性)。而且還要指出SCM系統中的相關日誌記錄,以回答各種“發生了什麽事” - 在部分產品停產的危機情況下的問題。


PS: I leave it to everybody's own judgement if my answer is yes or no DevOps-compliant.

基於我對法國“內部控制”監管的了解,與您指向的美國證券交易委員會規定類似,我假設這裏鏈接到法國法律文本並不會真正有用,而且我知道它沒有很好的翻譯。

在一個理想的“你建立它,你運行它”的模型中,團隊中的每個人都將對這個變化負責。風險評估不能通過職責分離來強制執行,我知道要保持符合法規的唯一方法是對交易進行周期性的短周期審計以及不可更改的操作跟蹤,以便回到執行釋放的人員。結果 這意味著交易和行動的所有日誌都被推送到了一個團隊無法訪問的限制區域,記錄的“應該”被團隊無法訪問的功能測試所捕獲的更改會變得更糟通過審計並跟蹤其作者。

這不適用於所有產品,在法國寫信時允許任何公司發放資金(主要是銀行),必須確保每筆交易都會被記錄下來,因此不會承擔錯過交易的風險。
另一方面,當有人要求貸款時,他們沒有追究任何商業要約或風險評估的法律義務,因此處理該客戶選擇和計算提供的費用的產品更容易適合某個帖子 - 釋放審計模型。

主要思想是,發布模式必須根據風險評估義務進行調整。

相關資源是 ISO27001 規範。

IMHO, Developers & Operations could be represented by nothing more than just two git repositories for the same codebase, with distinct permissions model each, so that teams will not interfer in the work of each other, at all.

Let's call them Dev.mygithub.co & ops.mygithub.co, just as an example.

這個想法是,開發人員可以自由地創建/分支/合並他們的內容 - git提供完整的可追溯性,這是重要的,同時,在監管框架意味著審查工作的時刻,可以提高,因為合並是以受控方式進行的。

將這個概念提升到一個新的層次,一個開發分支可以通過另一個 Pull Request 動作傳播到遠程Ops的生產。 最後一部分必須由操作人員的手和眼睛來實現,因為他們有責任將其投入生產並選擇審查級別。

這種方案允許無限的靈活性,全面的可追溯性,能夠通過各種流程盡早發現問題,分離關註點並在流程中提供非常合理的用戶體驗!

N.B. The model described above may be followed even if Ops & Dev overlap totally!