Tal Yitzhak

The Latest From Tal Yitzhak

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

  1月 28, 2022 | < 1 min read

  ソフトウェア サプライチェーンへの攻撃が増加している中、エアギャップのある環境で DevSecOps のベストプラクティスを実施することは必須です。組織の内部ネットワークのセキュリティを確保するために、内部ネットワークと外部ネットワークを分離する傾向が強まっています。基本的には、インターネットから閉鎖・切断された環境を作ります。 エアギャップ ソリューションは、より厳格なセキュリティ要件を提供しますが、それだけでは十分ではありません。ソフトウェア開発者が使用するサード パーティの依存関係、CI プロセス、デプロイメント パイプラインについても、セキュリティ上の脆弱性やライセンス違反がないかどうかをスキャンする必要があります。 どうやって? JFrog Xray のようなセキュリティ脆弱性ソリューションを組み合わせることで、エアギャップ環境を保護し、内部の開発環境で使用されるすべての脆弱な Artifact を除外することができます。 前回のブログでは、ちょっとしたツールやスクリプトを使うことで、エアギャップのある環境でもリモートの依存関係にアクセスし続けることができることを紹介しました。今回は、ソフトウェアを保護し、開発環境で厳格なセキュリティポリシーを適用するための手順とベストプラクティスを紹介します。 セットアップ例：DMZ の使用 以下のセットアップは、DMZ に JFrog Xray を設置してリモートの依存関係にある脆弱性をスキャンするソリューションの例を示しています。JFrog Xray は内部ネットワークにも設置し、ソフトウェアパッケージの継続的なスキャンを行い、将来の潜在的な脆弱性から組織を保護します。 エアギャップ・ソリューションで Xray を使用する際のベストプラクティス 内部ネットワークと DMZ の両方に Xray を設置する必要があります。これにより、Artifact の継続的なスキャンが保証され、すでに「承認」された依存関係に対して将来発生する可能性のある新しい脆弱性から Artifact を保護することができます。 ポリシーとウォッチは、内部ネットワーク用と DMZ 用を分けます。DMZ では依存関係解決のための大まかなポリシーを適用することもありますが、特定の製品/リリースを意識することもある内部ネットワーク環境では、より厳格なアプローチをとることができます。 JFrog CLI を使用して、内部の Xray データベースを最新の脆弱性情報で更新します（完全にエアギャップがある場合）。 DBの同期は、自動的、定期的に（スケジューラーを使用して）、毎日行う 同期プロセス（オンラインでの同期も含む）が実行されているか監視する 本番環境に導入する前に、エアギャップ フローのすべてのプロセスをテストできるように、ステージング環境にて実装します。 DMZ では、特定の違反の無視、パッチ適用、テスト、脆弱な依存関係の使用について必要に応じて SecOps が管理します。 * JFrog…

  さらに見る
• インターネットが使えない？問題ありません。JFrog Artifactoryをエアギャップで使用する – パート1

  8月 18, 2021 | < 1 min read

  事実上、すべての開発組織はビルドに必要な依存関係をダウンロードするために、Maven Central、NuGet Gallery、npmjs.org、Docker Hubなどの外部のパブリックリソースにアクセスする必要があります。Artifactoryを使用する大きな利点の1つは、これらのリモートリソースをプロキシし、ダウンロードされたアーティファクトをキャッシュするリモートリポジトリです。これにより、初めてアーティファクトを要求した開発者やCIサーバがあれば、そのアーティファクトはキャッシュされ、内部ネットワーク上のArtifactoryのリモートリポジトリから直接利用できるようになります。これがArtifactoryを使ってリモートリソースを操作する通常の方法です。 しかし、金融機関や軍事施設など、より厳しいセキュリティ要件を持つ組織では業務をインターネットに公開するような設定は禁止されています。 エアギャップを利用する このようなケースに対応するためには、少なくとも2つのArtifactoryインスタンスを用意することをお勧めします。1つはDMZ上、もう1つはエアギャップ上です。 通常、2つのシナリオがあります。 ネットワークに未接続 一方通行の接続 ネットワークに未接続 このシナリオでは2つのArtifactoryインスタンス間にはネットワーク接続がありません。インターネットから依存関係を取得するためには外部インスタンスが依存関係をダウンロードし、それを外部デバイス（ハードドライブやUSBフラッシュドライブなど）にエクスポートし、内部インスタンスが開発者やCIサーバーで使用するためにそれをインポートする必要があります。   依存関係の取得 ここではリモートリポジトリから依存関係を取得する2つの方法をご紹介します。 依存関係の宣言 コードから依存関係の宣言だけを残します。宣言されたコードを実行に必要なツールを備えたDMZ上の仮想マシンにインストールします。 例えば、npmパッケージを開発している場合はDMZマシンにnpmクライアントをインストールする必要があります。 対応するクライアントは必要な依存関係をArtifactoryに要求して再帰的にnレベルの依存関係もダウンロードします。 専用スクリプト 必要なすべてのパッケージを繰り返し検索し、Artifactoryに「ヘッドリクエスト」を送信して、リモートリソースからそれらのパッケージをダウンロードするスクリプトまたはメカニズムを実装します。 例えば、次のbashの例ではキーがmaven centralのアーティファクトパスを表し、値がキャッシュされる必要のあるアーティファクトファイルのバージョンであるハッシュマップを維持します。 declare -A dependencies=( ['junit/junit']="4.13.2/junit-4.13.2.pom 4.13.2/junit-4.13.2.jar" ['org/webjars/jquery']="2.1.1/jquery-2.1.1.jar 3.6.0/jquery-3.6.0.jar 2.1.3/jquery-2.1.3.jar" ) for d in "${!dependencies[@]}" do echo -e "caching dependency : $d, based on versions: ${dependencies[$d]}" for v in ${dependencies[$d]} do curl -s -o…

  さらに見る
• JFrog PipelinesでJenkinsビルドを効率的に実施

  3月 16, 2021 | < 1 min read

  現在、Jenkinsは最も人気のあるオープンソースのCIツールです。マーケットにいち早く参入したことで、JenkinsはCIを普及させました。他のCIツールと同様、Jenkinsは開発者がソースリポジトリにコードをコミット後、自動的にビルドしてテストを行うことが可能です。これにより開発者はバグを早期に把握し、素早くデプロイすることができます。 初期リリースから10年以上経った今、Jenkinsは岐路に立たされています。Jenkinsコミュニティの大部分にとってJenkinsは”容認”するツールとなっています。Jenkinsスプロール（管理するサーバの数が増える）という言葉はIT用語として定着しています。多数のプラグインを使用することで互いに干渉してJenkinsは複雑になってしまいます。この”プラグイン地獄”を回避する一つの方法は、より多数のサーバーやインスタンスにワークロード（とプラグイン）を分散することです。しかし開発チームがJenkinsのインスタンスを増加することによってサイロ化してしまい、今度は増加するJenkinsの構成を管理することになるという課題に直面します。残念ながら、複雑さの種類が変わるだけになってしまいます。また、Jenkinsはコンテナやマイクロサービス以前の時代のために作成されました。どのようなツールであれ、その価値を維持するためには、技術トレンドと上手く連携する必要があります。 このブログではSDLCの一部としてJFrog Pipelinesを使用し、CI/CD DevOpsフローを加速し、改善する方法をご説明します。 JFrog Pipelinesはソフトウェアを構築、テスト、デプロイするための自動化ソリューションです。以下のような機能を含む、すべての主要なDevOpsパイプラインプロセスのエンドツーエンドのオーケストレーションと最適化を提供します: Pipelinesは単体のCI/CDソリューションではなく、Artifactoryとバイナリを中心としたJFrog Platformの一部 プラグインフリーのアーキテクチャ - プラグインのメンテナンスは面倒 ネイティブStepによる迅速かつシンプルなパイプライン設定 無限に拡張できる（Jenkinsスプロールと比較して）集中型サービス YAML – 習得が容易 JFrog Xrayよる脆弱性スキャンとライセンス・コンプライアンス JFrogのソリューションエンジニアとしてEnterprise+を導入するお客様からよく受ける質問や懸念事項をご紹介します。具体的にはJenkinsからJFrog Pipelinesへの移行方法です。 なぜ、動作しているプロセスを変更してデプロイを危険にさらす必要があるのでしょうか？ すべてのCI/CDプロセスをJFrog Pipelinesに移行するには膨大な時間がかかりませんか？ Jenkinsではプラグインがあります。JFrogでも同様にサポートされるのでしょうか？ Jenkinsパイプライン例 以下のエンドツーエンドのKubernetes CI/CD Jenkinsパイプラインを使用し、JFrog Pipelinesがどのように機能するのかを示します。このパイプラインは一般的に知られているpet-clinic Mavenプロジェクトをビルドし、Dockerでコンテナ化し、作成したイメージをHelm chartを使用してK8sクラスタ環境にデプロイします。この処理には以下のステップが含まれています: 継続的インテグレーション（CI） Mavenプロジェクト（Pet Clinic Springアプリケーション）をビルドし、作成されたバイナリをArtifactoryにデプロイします。 新しいアプリケーションをDockerでコンテナ化し、新しいイメージをArtifactoryにデプロイします。 継続的デリバリー（CD） k8s用のパッケージマネージャであるHelmをインストールします。 Artifactoryで利用可能なHelm Chartを使用し、アプリケーションが保存されているイメージをk8sベースの本番環境にデプロイします。 上記のパイプライン（JenkinsfileとDockerfile）のコードサンプルはこちらにあります。 この一般的なCI/CDの例を利用して実装可能なテクニックを見てみましょう。 JFrogパイプラインで効率的に実施 JFrog Pipelinesを開始するには3つの基本的なテクニックがあります。最初の2つはJenkinsとのインテグレーションを実現するもので順番を問わずに実施するもできますし、これら2つのインテグレーション・アプローチの内の1つだけを選択することもできます。JenkinsをJFrog Pipelinesとのインテグレーション後は#3に進むことができます: Incoming Webhookを使用してJenkins（CI）からPipelines（CD）をトリガー SDLCの一部を移行する方法はJFrog Pipelines（CI）からJenkinsインテグレーションを使用して、Jenkins（CD）を起動 プロセスを合理化するために自動化を推進し、JFrog Pipelinesを使用して新しいCI/CDプロセスを設計します。 1. JFrog…

  さらに見る