DevOps と DevSecOps: ある銀行ではどうだったか

その銀行はプロジェクトを多くの請負業者に委託しています。 「外部」はコードを書き、その結果をあまり便利ではない形式で送信します。 具体的には、プロセスは次のようになります。機能テストに合格したプロジェクトが引き渡され、銀行境界内で統合や負荷などのテストが行​​われました。 テストが失敗していることがしばしば発見されました。 その後、すべてが外部開発者に戻りました。 ご想像のとおり、これはバグ修正に長い時間がかかることを意味しました。

同銀行は、コミットからリリースまでパイプライン全体を自社の傘下に置くことが可能であり、必要であると判断した。 そのため、すべてが均一であり、銀行内の製品を担当するチームの管理下に置かれます。 つまり、外部請負業者がオフィスの隣の部屋で単に仕事をしているかのようです。 企業スタック上。 これは普通の DevOps です。

セックはどこから来たのですか？ この銀行のセキュリティは、外部請負業者がネットワーク セグメントでどのように作業できるか、誰かがどのようなアクセス権を持っているか、誰がどのようにコードを操作するかについて、高い要求を課しています。 ただ、請負業者が屋外で作業する場合、銀行の基準がほとんど守られていないことを IB がまだ知らなかっただけです。 そして、数日以内に全員がそれらを観察し始める必要があります。

請負業者が製品コードに完全にアクセスできるという単純な事実が明らかになっただけで、すでに世界はひっくり返りました。

この瞬間から、DevSecOps の物語が始まりました。それについてお話したいと思います。

この状況から銀行はどのような実際的な結論を導き出したのでしょうか?

すべてが間違った方法で行われているという事実については、多くの論争がありました。 開発者らは、セキュリティは開発を妨害するのに忙しいだけで、監視員のように何も考えずに禁止しようとしていると述べた。 次に、セキュリティ専門家は、「開発者が回路に脆弱性を作成する」か、「開発者は脆弱性を作成するのではなく、開発者自身である」という観点のどちらを選択するかで迷っていました。 新たな市場の需要と DevSecOps パラダイムの出現がなければ、この論争は長期間続いていたでしょう。 「すぐに使える」情報セキュリティ要件を考慮したプロセスの自動化そのものが、誰もが満足し続けるのに役立つと説明することができました。 ルールはすぐに文書化され、ゲーム中に変更されないという意味で (情報セキュリティは予期せず何かを禁止しません)、開発者は何が起こるかすべてについて情報セキュリティに常に知らせます (情報セキュリティは突然何かに遭遇するわけではありません)。 。 各チームは、抽象的な兄貴分ではなく、最終的な安全性にも責任を負います。

1. 外部従業員はすでにコードと多くの内部システムにアクセスできるため、「開発は完全に銀行のインフラ上で実行されなければならない」という要件を文書から削除することはおそらく可能でしょう。
2. 一方で、何が起こっているかに対する管理を強化する必要があります。
3. 妥協案は、従業員が外部の人々と緊密に連携する、部門を超えたチームの創設でした。 この場合、チームが銀行のサーバー上のツールを使用していることを確認する必要があります。 最初から最後まで。

つまり、請負業者の参入は許可されますが、請負業者には別のセグメントを割り当てる必要があります。 外部から銀行のインフラに何らかの感染を持ち込まないように、また必要以上のものを見ないようにするためです。 つまり、彼らの行動が記録されるのです。 漏れに対する保護のための DLP、これらすべてが含まれています。

原則として、すべての銀行が遅かれ早かれこれに至ります。 ここで私たちは、人里離れた道を歩み、「外部」が機能する環境の要件について合意しました。 最大限の範囲のアクセス制御ツール、脆弱性チェックツール、回路、アセンブリ、テストのウイルス対策分析が登場しました。 これは DevSecOps と呼ばれます。

DevSecOps 以前は銀行セキュリティが開発者側で何が起こるかを制御できなかったとしても、新しいパラダイムではセキュリティはインフラストラクチャ上の通常のイベントと同じ方法で制御されることが突然明らかになりました。 アセンブリやライブラリの制御などに関するアラートが表示されるようになりました。

あとはチームを新型に移行するだけだ。 さて、インフラを作りましょう。 しかし、これらは些細なことであり、フクロウを描くようなものです。 実は私たちもインフラ面でお手伝いをさせていただいたのですが、当時は開発プロセスが変わりつつありました。

変化したこと

私たちは、多くのプロセスが崩壊し、多くの「外部」が全員の監督下での新しい労働条件に耐えられない可能性があることを理解していたため、それを少しずつ導入することにしました。

まず、私たちは部門横断的なチームを作り、新しい要件を考慮してプロジェクトを組織する方法を学びました。 組織的な意味で、どのようなプロセスを行うかについて議論しました。 その結果、すべての責任者を含む組み立てパイプラインの図が作成されました。

• CI： Git、Jenkins、Maven、Roslyn、Gradle、jUnit、Jira、MF Fortify、CA Harvest、GitlabCI。
• CD： 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」）。

彼らは請負業者を社内に引き入れる準備ができているチームを作り始めました。 いくつかの重要な点があることに気づきました。

• 少なくともコードを送信するときは、すべてを統一する必要があります。 なぜなら、独自の特徴を持つさまざまな開発プロセスと同じくらい多くの請負業者が存在したからです。 全員をほぼ XNUMX つに合わせる必要がありましたが、オプションがありました。
• 請負業者が多く、インフラの手動作成は向いていない。 新しいタスクは非常に迅速に開始される必要があります。つまり、開発者がパイプラインを管理するための一連のソリューションを用意できるように、インスタンスはほぼ瞬時にデプロイされる必要があります。

最初の一歩を踏み出すには、何が行われているかを理解する必要がありました。 そして、そこに到達する方法を決定する必要がありました。 私たちは、インフラストラクチャと CI/CD 自動化の両方でターゲット ソリューションのアーキテクチャの描画を支援することから始めました。 次に、このコンベアの組み立てを開始しました。 私たちは、全員にとって同じ、同じコンベヤーが稼働する XNUMX つのインフラストラクチャを必要としていました。 私たちは計算に基づいてオプションを提供し、銀行はそれを考えて、何をどのような資金で建設するかを決定しました。

次は回路の作成～ソフトウェアのインストール、設定です。 インフラストラクチャの導入と管理のためのスクリプトの開発。 次にコンベアサポートへの移行です。

私たちはパイロットですべてをテストすることにしました。 興味深いことに、試験運用中に、特定のスタックが初めて銀行に出現しました。 とりわけ、迅速な立ち上げのためのパイロットの範囲として、ソリューションの XNUMX つを提供する国内ベンダーが提供されました。 警備員は彼が操縦していたことを知り、忘れられない印象を残しました。 私たちが切り替えを決めたとき、幸いなことに、インフラストラクチャ層は以前からすでに存在していた Nutanix ソリューションに置き換えられました。 また、以前はVDI用でしたが、インフラサービス用に再利用しました。 少量の場合は経済に適合しませんでしたが、大量の場合は開発とテストに最適な環境になりました。

スタックの残りの部分は、多かれ少なかれ誰もがよく知っているものです。 Ansible の自動化ツールが使用され、セキュリティ専門家がそれらと緊密に連携しました。 Atlassin スタックは、プロジェクトの前に銀行によって使用されていました。 フォーティネット セキュリティ ツール - セキュリティ担当者自身によって提案されました。 テストフレームは銀行によって作成され、質問はありませんでした。 リポジトリ システムには疑問が生じたので、慣れる必要がありました。

請負業者には新しいスタックが与えられました。 彼らは、GitlabCI 用に書き直したり、Jira を銀行セグメントに移行したりする時間を与えてくれました。

一歩一歩

1ステップ。 まず、国内ベンダーのソリューションを使用し、製品を新しく作成した DSO ネットワーク セグメントに接続しました。 このプラットフォームは、納期、拡張性の柔軟性、完全自動化の可能性を理由に選択されました。 実施したテスト:

• 仮想化プラットフォーム インフラストラクチャ (ネットワーク、ディスク サブシステム、コンピューティング リソース サブシステム) の柔軟かつ完全に自動化された管理の可能性。
• 仮想マシンのライフサイクル管理 (テンプレート、スナップショット、バックアップ) の自動化。

プラットフォームのインストールと基本構成の後、それは第 XNUMX 段階のサブシステム (DSO ツール、小売システム開発概要) の配置ポイントとして使用されました。 仮想マシンの作成、削除、変更、バックアップなど、必要なパイプラインのセットが作成されました。 これらのパイプラインは、展開プロセスの最初の段階として使用されました。

その結果、提供された機器は銀行のパフォーマンスと耐障害性の要件を満たしていません。 銀行の DIT は、Nutanix ソフトウェア パッケージに基づいて複合体を作成することを決定しました。

段階2。 私たちは定義されたスタックを取得し、すべてがパイロットからターゲット回路にできるだけ早く転送されるように、すべてのサブシステムの自動インストールと構成後のスクリプトを作成しました。 すべてのシステムはフォールト トレラント構成で展開され (この機能はベンダーのライセンス ポリシーによって制限されません)、メトリクスとイベント収集サブシステムに接続されました。 IB は要件への準拠を分析し、ゴーサインを出しました。

段階3。 すべてのサブシステムとその設定を新しい PAC に移行します。 インフラストラクチャ自動化スクリプトが書き直され、DSO サブシステムの移行が完全自動モードで完了しました。 IP開発の輪郭は、開発チームのパイプラインによって再現されました。

4ステップ。 アプリケーションソフトウェアのインストールを自動化します。 これらのタスクは、新しいチームのチーム リーダーによって設定されました。

5ステップ。 搾取。

リモートアクセス

開発チームは回路の操作に最大限の柔軟性を求め、個人のラップトップからのリモート アクセスの要件はプロジェクトの最初の段階で提起されました。 この銀行はすでにリモート アクセスを備えていましたが、開発者には適していませんでした。 実際、このスキームでは、保護された VDI へのユーザーの接続が使用されていました。 これは、職場で郵便物と事務用パッケージのみが必要な人々に適していました。 開発者は、大量のリソースを備えた、高パフォーマンスのヘビー クライアントを必要とします。 そしてもちろん、VStudio (たとえば) や他の SDK を使用するユーザーのユーザー セッションが失われることは許容できないため、静的である必要があります。 すべての開発チーム向けに多数のシックな静的 VDI を編成すると、既存の VDI ソリューションのコストが大幅に増加しました。

私たちは、開発部門のリソースへの直接リモート アクセスに取り組むことにしました。 Jira、Wiki、Gitlab、Nexus、ビルドベンチとテストベンチ、仮想インフラストラクチャ。 警備員は、以下の条件を満たす場合にのみアクセスを提供できるように要求しました。

1. 銀行ですでに利用可能なテクノロジーを使用します。
2. インフラストラクチャでは、本稼働アカウント オブジェクトのレコードを保存する既存のドメイン コントローラーを使用しないでください。
3. アクセスは、特定のチームが必要とするリソースのみに制限する必要があります (ある製品チームが別のチームのリソースにアクセスできないようにするため)。
4. システム内の RBAC を最大限に制御します。

その結果、このセグメントに対して別のドメインが作成されました。 このドメインには、ユーザー認証情報とインフラストラクチャの両方のすべての開発セグメント リソースが収容されていました。 このドメインのレコードのライフサイクルは、銀行内に存在する IdM を使用して管理されます。

直接リモート アクセスは銀行の既存の機器に基づいて組織されました。 アクセス制御は、コンテキストに関するルールが対応する AD グループに分割されました (XNUMX つの製品グループ = XNUMX つのルール グループ)。

VM テンプレートの管理

環境を準備する速度はパイプライン全体の実行時間に直接影響するため、アセンブリおよびテスト ループの作成速度は、開発部門の責任者によって設定される主な KPI の XNUMX つです。 基本 VM イメージを準備するための XNUMX つのオプションが検討されました。 XNUMX つ目は、最小画像サイズ、すべてのシステム製品のデフォルト、設定に関する銀行のポリシーへの最大限の準拠です。 XNUMX つ目は基本イメージです。これには強力な POPPO がインストールされており、そのインストール時間はパイプラインの実行速度に大きく影響する可能性があります。

開発中には、イメージを最新の状態に保つ (パッチなど)、SIEM との統合、銀行標準に従ったセキュリティ設定など、インフラストラクチャとセキュリティの要件も考慮されました。

その結果、イメージを最新の状態に保つコストを最小限に抑えるために、最小限のイメージを使用することが決定されました。 POPPO の新しいバージョン用に各イメージにパッチを適用するよりも、ベース OS を更新する方がはるかに簡単です。

結果に基づいて、最小限必要なオペレーティング システムのセットのリストが作成され、その更新は運用チームによって実行され、パイプラインのスクリプトがソフトウェアの更新と、必要に応じてバージョンの変更をすべて担当します。インストールされているソフトウェアの必要なタグをパイプラインに転送するだけです。 はい、これには Devops 製品チームがより複雑な展開シナリオを用意する必要がありますが、ベース イメージのサポートに必要な運用時間が大幅に短縮されます。そうしないと、維持するために XNUMX を超えるベース VM イメージが必要になる可能性があります。

インターネットアクセス

銀行セキュリティに関するもう XNUMX つの障害は、開発環境からインターネット リソースへのアクセスでした。 さらに、このアクセスは XNUMX つのカテゴリに分類できます。

1. インフラストラクチャへのアクセス。
2. 開発者アクセス。

インフラストラクチャへのアクセスは、Nexus を使用して外部リポジトリをプロキシすることによって組織されました。 つまり、仮想マシンからの直接アクセスは提供されませんでした。 これにより、開発部門から外部へのアクセスを提供することを断固として反対する情報セキュリティとの妥協点に達することが可能になりました。

開発者は明白な理由 (スタックオーバーフロー) からインターネットへのアクセスを必要としていました。 上で述べたように、すべてのコマンドは回路にリモート アクセスできましたが、IDE の銀行の開発者の作業場から Ctrl+V を実行できない場合、必ずしも便利とは限りません。

IS とは、最初のテスト段階では、ホワイトリストに基づいて銀行プロキシを通じてアクセスが提供されるという合意に達しました。 プロジェクトが完了すると、アクセスはブラックリストに移されます。 プロジェクトの開始時にアクセスが必要な主要なリソースとリポジトリを示す巨大なアクセス テーブルが用意されました。 これらのアクセスの調整にはかなりの時間がかかり、そのためブラックリストへの可能な限り迅速な移行を主張することが可能になりました。

結果

このプロジェクトは XNUMX 年弱前に終了しました。 奇妙なことに、すべての請負業者が時間通りに新しいスタックに切り替え、新しい自動化のために退職する人は一人もいませんでした。 IB は肯定的なフィードバックを急いで共有することはありませんが、文句も言わないため、IB は気に入っていると結論付けることができます。 情報セキュリティが再び制御されていると感じられるようになり、開発プロセスには干渉しないため、紛争は沈静化しました。 チームにはより多くの責任が与えられ、情報セキュリティに対する全体的な姿勢が良くなりました。 銀行は、DevSecOps への移行がほぼ不可避であることを理解しており、私の意見では、最も穏やかで正しい方法でそれを実行しました。

アレクサンダー・シュービン、システムアーキテクト。

出所： habr.com