該銀行將其項目外包給許多承包商。 「外部」編寫程式碼，然後以不太方便的形式傳輸結果。 具體來說，流程是這樣的：他們移交了一個通過功能測試的項目，然後在銀行週邊進行整合、負載等測試。 人們經常發現測試失敗。 然後一切都回到了外部開發人員手中。 正如您所猜測的，這意味著錯誤修復的準備時間很長。
該銀行認為，有可能且有必要將整個管道（從提交到發布）納入其旗下。 這樣一切都是統一的，並由銀行負責產品的團隊控制。 也就是說，就好像外部承包商只是在辦公室隔壁房間的某個地方工作一樣。 在公司堆疊上。 這是一個普通的 DevOps。
秒從哪裡來？ 銀行的安全對外部承包商如何在網段中工作、某人擁有哪些存取權限、如何以及由誰使用代碼提出了很高的要求。 只是 IB 還不知道，當承包商在外面工作時，幾乎沒有遵循銀行標準。 然後幾天後每個人都需要開始觀察它們。
承包商可以完全存取產品代碼這一簡單的事實已經讓他們的世界發生了翻天覆地的變化。
這一刻，我想跟大家講的DevSecOps的故事就開始了。
銀行從這種情況中得出了哪些實際結論？
關於一切都以錯誤的方式進行這一事實存在著許多爭議。 開發人員表示，安全只是忙著試圖幹擾開發，而他們就像看守人一樣，不假思索地試圖禁止。 反過來，安全專家在兩種觀點之間猶豫不決：「開發人員在我們的電路中創建了漏洞」和「開發人員不會創建漏洞，漏洞本身就是開發人員」。 如果沒有新的市場需求和 DevSecOps 範式的出現，這場爭論將會持續很長一段時間。 可以解釋的是，這種「開箱即用」考慮到資訊安全要求的流程自動化將幫助每個人保持快樂。 從某種意義上說，規則是立即寫下來的，並且在遊戲過程中不會改變（資訊安全不會意外地禁止某些事情），並且開發人員讓資訊安全了解所發生的一切（資訊安全不會突然遇到某些事情） 。 每個團隊也負責最終的安全，而不是一些抽象的老大哥。
- 由於外部員工已經可以存取程式碼和許多內部系統，因此有可能從文件中刪除「開發必須完全在銀行基礎設施上進行」的要求。
- 另一方面，我們需要加強對正在發生的事情的控制。
- 妥協的辦法是創造跨職能團隊，讓員工與外部人員密切合作。 在這種情況下，您需要確保團隊使用銀行伺服器上的工具。 從開始到結束。
也就是說，可以允許承包商進入，但需要給他們單獨的部分。 這樣他們就不會從外部將某種感染帶入銀行的基礎設施，也不會看到超出必要的內容。 好吧，這樣他們的行為就會被記錄下來。 用於防止洩漏的 DLP，所有這些都包括在內。
原則上，所有銀行遲早都會遇到這個問題。 在這裡，我們走了一條老路，並就「外部」工作的這種環境的要求達成了一致。 出現了最大範圍的存取控制工具、漏洞檢查工具、電路、元件和測試的防毒分析。 這稱為 DevSecOps。
突然之間，我們發現，如果在 DevSecOps 之前，銀行安全無法控制開發人員這邊發生的事情，那麼在新的範式中，安全性的控制方式與基礎設施上的普通事件相同。 現在才出現關於程序集、庫控制等的警報。
剩下的就是將團隊轉移到新模型。 好吧，創建基礎設施。 但這些都是小事，就像畫貓頭鷹一樣。 實際上，我們幫助建立了基礎設施，當時開發流程正在改變。
發生了什麼變化
我們決定分小步驟實施，因為我們知道許多流程會崩潰，許多「外部人員」可能無法承受所有人監督下的新工作條件。
首先，我們創建了跨職能團隊，並學會根據新要求來組織專案。 從組織意義上來說，我們討論了哪些流程。 結果是一張包含所有負責人的組裝流水線圖。
- CI： Git、Jenkins、Maven、Roslyn、Gradle、jUnit、Jira、MF Fortify、CA Harvest、GitlabCI。
- 光盤： Ansible、Puppet、TeamCity、Gitlab TFS、Liquidbase。
- 測試： Sonarqube、SoapUI、jMeter、Selenium：MF Fortify、Performance Center、MF UFT、Ataccama。
- 介紹 （報告、溝通）：Grafana、Kibana、Jira、Confluence、RocketChat。
- 操作 （維護、管理）：Ansible、Zabbix、Prometheus、Elastic + Logstash、MF Service Manager、Jira、Confluence、MS Project。
選定的堆疊：
- 知識庫 - Atlassian Confluence；
- 任務追蹤器 - Atlassian Jira；
- 工件儲存庫 - “Nexus”；
- 持續整合系統－「Gitlab CI」；
- 連續分析系統——“SonarQube”；
- 應用安全分析系統－「Micro Focus Fortify」；
- 通訊系統－「GitLab Mattermost」；
- 組態管理系統－「Ansible」；
- 監控系統 - “ELK”、“TICK Stack”（“InfluxData”）。
他們開始組建一支團隊，準備將承包商拖進去。 人們認識到有幾件重要的事情：
- 一切都應該統一，至少在傳輸程式碼時是如此。 因為有很多承包商，有很多不同的開發流程，每個流程都有自己的特色。 有必要讓每個人都適應大約一種，但要有選擇。
- 承包商很多，手動創建基礎設施並不合適。 任何新任務都應該非常快速地啟動 - 也就是說，實例應該幾乎立即部署，以便開發人員擁有一套解決方案來管理他們的管道。
要踏出第一步，有必要了解正在做什麼。 我們必須確定如何到達那裡。 我們首先協助繪製基礎設施和 CI/CD 自動化方面的目標解決方案的架構。 然後我們開始組裝這個傳送帶。 我們需要一種基礎設施，對每個人來說都是一樣的，並且運行相同的傳送帶。 銀行認為，我們提供了經過計算的選項，然後決定建造什麼以及用什麼資金。
接下來是電路的創建 - 軟體安裝、配置。 開發用於基礎設施部署和管理的腳本。 接下來是向傳送帶支撐的過渡。
我們決定在飛行員身上測試一切。 有趣的是，在試點過程中，銀行中首次出現了某個堆疊。 除此之外，也為試點範圍提供了其中一種解決方案的國內供應商，以便快速啟動。 保全人員在他駕駛時認識了他，這給他留下了難忘的印象。 當我們決定切換時，幸運的是，基礎設施層被替換為 Nutanix 解決方案，之前已經在銀行中了。 而且，之前它是用於VDI的，但我們將其重新用於基礎設施服務。 小批量時，它不適合經濟，但大批量時，它成為開發和測試的絕佳環境。
堆疊的其餘部分或多或少是每個人都熟悉的。 使用了 Ansible 中的自動化工具，並與安全專家密切合作。 該銀行在該專案之前就使用了 Atlassin 堆疊。 Fortinet 安全工具 - 它是由安全人員自己提出的。 測試框架是由銀行創建的，沒有提出任何問題。 儲存庫系統提出了問題；我必須習慣它。
承包商獲得了新的堆疊。 他們給了我們時間為 GitlabCI 重寫它，並將 Jira 遷移到銀行領域，等等。
一步步
步驟1。 首先，我們使用了國內廠商的解決方案，該產品連接到新建立的DSO網段。 選擇該平台是因為其交付時間、擴展靈活性和完全自動化的可能性。 進行的測試：
- 可靈活且完全自動化地管理虛擬化平台基礎架構（網路、磁碟子系統、運算資源子系統）。
- 虛擬機器生命週期管理的自動化（範本、快照、備份）。
平台安裝和基本配置完成後，用作第二階段子系統（DSO 工具、零售系統開發概要）的放置點。 建立了必要的管道集 - 建立、刪除、修改、備份虛擬機器。 這些管道被用作部署過程的第一階段。
結果是提供的設備不符合銀行對性能和容錯的要求。 該銀行的 DIT 決定創建一個基於 Nutanix 軟體包的綜合體。
階段2。 我們採用了定義的堆疊，並為所有子系統編寫了自動安裝和後配置腳本，以便盡快將所有內容從試點傳輸到目標電路。 所有系統都部署在容錯配置中（此功能不受供應商許可策略的限制）並連接到指標和事件收集子系統。 IB 分析了其要求的合規性並給予了批准。
階段3。 將所有子系統及其設定遷移到新的 PAC。 重寫了基礎設施自動化腳本，並以完全自動化的方式完成了DSO子系統的遷移。 IP開發的輪廓是由開發團隊的管道重新創建的。
步驟4。 應用軟體安裝自動化。 這些任務是由新團隊的團隊領導者所製定的。
步驟5。 開發。
遠端存取
開發團隊要求在使用電路時具有最大的靈活性，並且在專案一開始就提出了從個人筆記型電腦進行遠端存取的要求。 該銀行已經有了遠端存取功能，但不適合開發人員。 事實上，該方案使用了使用者與受保護 VDI 的連線。 這適合那些在工作場所只需要郵件和辦公包裹的人。 開發人員需要大量的客戶端、高效能和大量資源。 當然，它們必須是靜態的，因為對於使用 VStudio（例如）或其他 SDK 的使用者來說，使用者會話的遺失是不可接受的。 為所有開發團隊組織大量厚靜態VDI，大大增加了現有VDI解決方案的成本。
我們決定直接遠端存取開發部門的資源。 Jira、Wiki、Gitlab、Nexus、建置與測試平台、虛擬基礎架構。 保全人員要求只有符合以下條件才可以進入：
- 使用銀行已有的技術。
- 基礎結構不應使用儲存生產帳戶物件記錄的現有網域控制器。
- 存取權限應僅限於特定團隊所需的資源（以便一個產品團隊無法存取另一個團隊的資源）。
- 對系統中 RBAC 的最大控制。
因此，為該細分市場創建了一個單獨的網域。 此網域包含所有開發部門資源，包括使用者憑證和基礎架構。 該域中記錄的生命週期是使用銀行中現有的 IdM 進行管理的。
直接遠端存取是在銀行現有設備的基礎上組織的。 存取控制分為 AD 組，上下文規則對應這些 AD 組（一個產品組 = 一組規則）。
虛擬機器範本管理
創建組裝和測試循環的速度是開發單位負責人設定的主要KPI之一，因為準備環境的速度直接影響管線的整體執行時間。 考慮了兩種準備基礎 VM 映像的選項。 第一個是最小影像尺寸，所有系統產品默認，最大程度符合銀行的設定政策。 第二個是基礎鏡像，其中包含已安裝的重型POPPO，其安裝時間可能會極大地影響管道的執行速度。
開發過程中還考慮了基礎設施和安全要求 - 保持映像最新（修補程式等）、與 SIEM 整合、根據銀行標準進行安全設定。
因此，我們決定使用最少的圖像，以盡量減少保持更新的成本。 更新基本作業系統比為新版本的 POPPO 修補每個映像要容易得多。
根據結果，形成了所需的最低操作系統集的列表，其更新由運營團隊進行，管道中的腳本完全負責更新軟體，並在必要時更改版本已安裝的軟體- 只需將所需的標籤傳輸到管道即可。 是的，這需要 DevOps 產品團隊擁有更複雜的部署場景，但它大大減少了支援基礎映像所需的操作時間，否則可能需要維護一百多個基礎 VM 映像。
互聯網
銀行安全的另一個障礙是從開發環境存取網路資源。 而且，這種訪問可以分為兩類：
- 基礎設施接入。
- 開發者訪問。
基礎設施存取是透過使用 Nexus 代理外部儲存庫來組織的。 也就是說，不提供從虛擬機器的直接存取。 這使得在資訊安全方面達成妥協成為可能，這明確反對提供開發部門對外部世界的任何存取。
出於顯而易見的原因，開發人員需要存取互聯網（stackoverflow）。 儘管如上所述，所有命令都可以遠端存取電路，但當您無法從 IDE 中銀行的開發人員工作場所執行 ctrl+v 時，這並不總是很方便。
與 IS 達成協議，最初在測試階段，將透過基於白名單的銀行代理提供存取權限。 項目完成後，存取權限將轉入黑名單。 準備了龐大的存取表，其中表明了專案開始時需要存取的主要資源和儲存庫。 協調這些訪問需要花費相當多的時間，這使得堅持以最快的速度過渡到黑名單成為可能。
Результаты
該項目在不到一年前結束。 奇怪的是，所有承包商都按時切換到新堆棧，並且沒有人因新的自動化而離開。 IB並不急於分享正面的回饋，但也不抱怨，從中我們可以得出結論，他們喜歡它。 衝突已經平息，因為資訊安全再次受到控制，但不會幹擾開發過程。 團隊的責任被賦予了更多，資訊安全的整體態度也變得更好。 該銀行明白向 DevSecOps 的過渡幾乎是不可避免的，並且在我看來，以最溫和、最正確的方式做到了這一點。
亞歷山大·舒賓，系統架構師。
來源： www.habr.com