インターネットが使えない?問題ありません。Xray は機能します – パートⅡ

Secure Your Air-gapped Environment

ソフトウェア サプライチェーンへの攻撃が増加している中、エアギャップのある環境で DevSecOps のベストプラクティスを実施することは必須です。組織の内部ネットワークのセキュリティを確保するために、内部ネットワークと外部ネットワークを分離する傾向が強まっています。基本的には、インターネットから閉鎖・切断された環境を作ります。

エアギャップ ソリューションは、より厳格なセキュリティ要件を提供しますが、それだけでは十分ではありません。ソフトウェア開発者が使用するサード パーティの依存関係、CI プロセス、デプロイメント パイプラインについても、セキュリティ上の脆弱性やライセンス違反がないかどうかをスキャンする必要があります。

どうやって? JFrog Xray のようなセキュリティ脆弱性ソリューションを組み合わせることで、エアギャップ環境を保護し、内部の開発環境で使用されるすべての脆弱な Artifact を除外することができます。

前回のブログでは、ちょっとしたツールやスクリプトを使うことで、エアギャップのある環境でもリモートの依存関係にアクセスし続けることができることを紹介しました。今回は、ソフトウェアを保護し、開発環境で厳格なセキュリティポリシーを適用するための手順とベストプラクティスを紹介します。

セットアップ例:DMZ の使用

以下のセットアップは、DMZ に JFrog Xray を設置してリモートの依存関係にある脆弱性をスキャンするソリューションの例を示しています。JFrog Xray は内部ネットワークにも設置し、ソフトウェアパッケージの継続的なスキャンを行い、将来の潜在的な脆弱性から組織を保護します。

Using an external DMZ, with JFrog Xray installed to scan your remote dependencies for vulnerabilities

エアギャップ・ソリューションで Xray を使用する際のベストプラクティス

  • 内部ネットワークと DMZ の両方に Xray を設置する必要があります。これにより、Artifact の継続的なスキャンが保証され、すでに「承認」された依存関係に対して将来発生する可能性のある新しい脆弱性から Artifact を保護することができます。
  • ポリシーとウォッチは、内部ネットワーク用と DMZ 用を分けます。DMZ では依存関係解決のための大まかなポリシーを適用することもありますが、特定の製品/リリースを意識することもある内部ネットワーク環境では、より厳格なアプローチをとることができます。
  • JFrog CLI を使用して、内部の Xray データベースを最新の脆弱性情報で更新します(完全にエアギャップがある場合)。
    • DBの同期は、自動的、定期的に(スケジューラーを使用して)、毎日行う
    • 同期プロセス(オンラインでの同期も含む)が実行されているか監視する
  • 本番環境に導入する前に、エアギャップ フローのすべてのプロセスをテストできるように、ステージング環境にて実装します。
  • DMZ では、特定の違反の無視、パッチ適用、テスト、脆弱な依存関係の使用について必要に応じて SecOps が管理します。

* JFrog Xray を簡単に導入するためのベストプラクティス


実装例:アイデンティティ・エアギャップ環境に基づくリポジトリのキュレーション・プロセス

大規模な開発チームが世界中に存在するようなエンタープライズ企業では、ID ベースのソリューションがデファクトスタンダードなアプローチになりつつあります。次世代のエアギャップ環境では、リクエストに関するすべてを識別することが基本となります。より具体的には、トラッキングです。

  • 内部環境からは利用できない外部のサードパーティ依存リクエスト
  • そのような依存関係が会社のポリシーによって使用できない場合、その承認/不承認

次の図は、IDベースのエアギャップ ソリューションにおけるサードパーティ依存関係の選択、整理、およびダウンロードのプロセスを説明しています。全てが、 Artifact 管理のコンテキストにおいて特に高度に規制された安全な環境の中で行われます。なお、内部ネットワークに設置された  Artifactory は Curated レポジトリと呼ばれるスキャン済み Artifact のみを保存するレポジトリを持ち、DMZ に設置された Artifactory はインターネットへのアクセスが可能な Open レポジトリを持ちます。

Process of managing the security of your software binaries in an air gapped environment

エアー ギャップ環境における、ソフトウェア バイナリのセキュリティ管理プロセス

 

各ステップ詳細

  1. 開発者である Kermit が、新しいサードパーティの依存関係を宣言して、プロジェクトをビルドしようとする
  2. Kermit は「404 Not Found」を受信。この依存関係は、インターナル Artifactory の Curated リポジトリで解決不可であるため
  3. Webhook リクエストが送信され、「Self Service Curate Process」が通知される
  4. このリクエストに対する “Ticket #1” が(ServiceNow / Jira 等チケットシステムを介して)オープン
  5. この依存関係をダウンロードするために、DMZ Artifactory にリクエストが送信される
  6. DMZ Artifactory はインターネットから依存関係をプル
  7. Xray が依存関係をスキャン
  8. 脆弱性情報が Webhook により通知される

バイオレーションが生じていない場合:

  1. “Ticket #1” はクローズ
  2. Kermit に通知が届き、Curated リポジトリから依存関係のダウンロードが可能となる。スキャン後は Curated レポジトリから Open  リポジトリへアクセス可能となり依存関係が解決可能となるため

バイオレーションが生じた場合:

  1. 依存関係の使用を制限する Xray ポリシーのバイオレーションを示す “Ticket #2” がオープン
  2. Kermit に、バイオレーションによって依存関係の使用が現在制限されていることが通知され、SecOps がバイオレーションをレビュー
  3. Kermit はバイオレーション依存関係をサンドボックス環境でテストし、使用可能であれば (脆弱な機能が不必要である可能性有)、承認されるべきであるというエビデンスを SecOps に提供
  4. Kermit は、依存性についてのテストと調査の結果を “Ticket 2” に反映
  5. SecOps エンジニアは “Ticket #2” の更新通知を受信

バイオレーション Artifact が SecOps に使用を承認された場合:

  1. SecOps が承認し、Webhook が送信
  2. Dependency は Open レポジトリから Curated リポジトリにプルされる
  3. “Ticket #2” がクローズ

バイオレーション Artifact が SecOps によって使用を承認されない場合:

  1. Kermit は、SecOps によるレビュー結果として、使用が承認されないことの通知を受信

このソリューションの利点