クラウドネイティブセキュリティのベストプラクティス：CI/CDパイプラインのセキュリティ #AquaSecurity #CICD #ベストプラクティス

本ブログは「Aqua Security」社の技術ブログで2020年1月22日に公開された「 Cloud Native Best Practices: Security Policies in CI/CD Pipelines 」の日本語翻訳です。

クラウドネイティブセキュリティのベストプラクティス：CI/CDパイプラインのセキュリティ

---

従来の DevOps の権限のシフトシフトを実践することで、組織はソフトウェア開発ライフサイクル(SDLC)の早い段階でセキュリティの問題を検出できるようになりました。組織は Jenkins・GoCD・Bamboo などの CI/CD ツールを使用して、アプリケーションを継続的に開発・テスト・本番環境へデプロイできます。コンテナがクラウドネイティブアプリケーション開発での最適なアーキテクチャとなりつつあり、開発者は開発ニーズに基づいて有名なリポジトリのコンテナイメージに依存しがちになります。

ただし、信頼できるリポジトリのコンテナイメージにもアプリケーションが攻撃を受けやすい脆弱性を含んでいる場合があります。さらにアプリケーションの開発中に使用されるパッケージやライブラリなどのソフトウェアの依存関係にも、脆弱性が含まれる場合があります。

組織が潜在的な攻撃ベクターを削減し、リスクを排除することを確実とするために、脆弱性の特定は早ければ早いほど良いでしょう。セキュリティチームに CI/CD パイプライン内の非準拠イメージをブロックするツールを提供することは、最初の防衛線です。開発段階でイメージをスキャンし脆弱性・シークレット・マルウェアの検出を行うと、セキュリティチームは Image Assurance Policy (Aquaの機能の1つ)を実施してポリシーに抵触するイメージをブロックし、開発者に問題の内容を通知します。

この時点で自問するかもしれません。「開発者が使用しているイメージをスキャンすることは重要だと思うが、どのように始めればいいのか、どのように開発を遅くしないようにするのか」と。

本ブログでは、 CI/CD パイプライン内でイメージをスキャンする利点を確認するとともにベストプラクティスについて説明します。Aqua Cloud Native Security Platform(CSP)がそれらをどのように適用できるか説明していきます。

• Assurance Policiesをパイプライン毎に設定
• 承認されたベースイメージの使用
• 柔軟な管理

Assurance Policiesをパイプライン毎に設定

CI/CD パイプラインのセキュリティゲートとして Aqua CSP を追加します。Aqua CSP のAssurance Policy で定義した設定をもとに、アプリケーションがセキュリティチェックにクリアすることを確認します。Assurance Policy は脆弱性だけではなく、特権・ユーザスペース・埋め込まれたシークレット・マルウェアなどの他のセキュリティチェックを実施できます。非常に柔軟なルールに基づいて、ポリシーに抵触するイメージが CI/CD パイプラインを素通りすることを防ぐセキュリティポリシーです。必要な数だけAssurance Policy を作成し、専用のポリシーを各パイプラインに割り当てることができます。例えば開発用パイプラインにのみ適用される Assurance Policy と本番リリースパイプラインに適用される Assurance Policy を定義できます。

承認されたベースイメージの使用

Aqua CSP はスキャンされたイメージのベースイメージを識別できるため、承認されたベースイメージからビルドされたイメージのみを許可するように設定できます。例えば alpine:3.3 を承認済みのベースイメージとして設定します。開発者が alpine:2.2 イメージまたはその他のベースイメージを使用するアプリケーションを構築した場合、Aqua CSP は CI/CD パイプラインでビルドを失敗させます。これにより攻撃対象範囲を最小限に抑えることができ、セキュリティチームによって承認されたベースイメージのみを使用させることでイメージ管理プロセスを制御し実用的にすることができます。

柔軟な管理

Aqua CSP が検知した脆弱性すべてに利用可能な修正が提供されている訳ではないため、すべての脆弱性へすぐに対処できるわけではありません。そのため、Aqua CSP では脆弱性の例外を処理する方法がいくつか提供されています。

特定の脆弱性を許可

特定の脆弱性を許可することで、その脆弱性が含まれるイメージのビルド・デプロイを失敗させないことができます。特定のイメージ・リポジトリ全体・すべてのイメージに対して、脆弱性を許可する設定が可能です。許可した脆弱性が一定期間経過した後に削除されるように設定することもできます。例えば30日間は CVE-2019-1234 を無視するよう設定ができ、その間イメージはブロックされません。設定した時間が経過すると、Aqua CSP はAssurance Policy を実施し、特定の脆弱性を持つイメージをブロックします。

ポリシーの例外設定

Assurance Policy の設定で、利用可能な修正がない脆弱性の無視・特定の期間内(例えば過去30日以内)に公開された脆弱性の無視・特定の CI/CD パイプラインで無視する脆弱性の指定ができます。

イメージのホワイトリスト

イメージをホワイトリストに登録するということは、コンプライアンスステータスに関係なく、そのイメージを使用したデプロイを承認することを意味します。ホワイトリストは特定の脆弱性のみだけではなく、そのイメージに存在するすべてのセキュリティ問題に適用されてしまいます。

Assurance Policy の柔軟な例外管理により、パイプラインの脆弱性の処理方法を制御できます。セキュリティニーズと開発効率のバランスを取ることができます。パイプラインを移動するときにイメージを保護し、脆弱性とその修正方法を開発者に通知する一方で、脆弱性を選択的に処理させることによりイメージのビルドを迅速にサポートします。

次は?

これで Aqua CSP を CI/CD に統合すべきであると感じていただければ幸いです。次のステップとして、許可されていないコンテナイメージがコンテナランタイムにアクセスできた場合でも、コンテナイメージを実行できないようにする必要があります。そのためコンテナホストに Aqua Enforcer をデプロイし、Runtime Policy を適用して本番環境での不正なイメージの実行をブロックします。これによりランタイムコンテナ保護の実装が可能となり、オペレーティングシステムコールレベルでコンテナを保護し、Aqua CSP 独自のランタイム保護をさらに活用できます。