fbpx

シフトレフト、シフトアップ #AquaSecurity #DevSecOps #ContainerSecurity #Kubernetes #docker

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。


本ブログは「Aqua Security」社の技術ブログで2019年6月12日に公開された「Shift Security Left, Then Shift Up」の日本語翻訳です。

シフトレフト、シフトアップ

アプリケーション開発ライフサイクルの早い段階でセキュリティが組み込まれている「シフトレフト」というセキュリティアプローチは周知のことであると思います。アプリケーションがすでにデプロイされた後にセキュリティの問題を発見するよりも、早期に行う方が容易かつ効果的です。デプロイ後に見つかった問題は、原因を突き止めて誰が修正できるかを追跡するのが難しくなり、問題の修正にかかる時間が長くなります。

コンテナを使用することは、開発とデリバリーの高速化、移植性の向上など、従来のソフトウェア開発モデルに比べて多くの利点があります。1年に2、3回のリリースの代わりに、継続的インテグレーションと継続的デリバリー(CI/CD)は、毎日、あるいは1日に数回、新しいバージョンのコードを迅速にリリースすることができます。

シフトレフトは、開発およびデプロイのさまざまな段階でセキュリティテストを組み込んで、脆弱性、不適切な構成、その他の問題を運用に移す前に検出する、ポリシー主導のアプローチです。

シフトレフトを実行することで、脆弱性がなく、かつ可能な限り正しく構成されているソフトウェア導入を支援し、攻撃対象を減らすことができます。ただし、攻撃が試みられたかどうか、そして明らかにそれが成功したかどうかまではわかりません。アプリケーションへの可視性を提供したり、疑わしい活動をリアルタイムでブロックしたりすることはありません。セキュリティを左にシフトすることは必要かつ効果的な方法ですが、同時にアクティブでレスポンシブなランタイムコントロールによって補完されなければなりません。

シフトアップ

従来のアプリケーションとクラウドネイティブアプリケーションの違いの1つは、アプリケーションがインフラを意識する必要がなく、インフラからアプリケーションを切り離しインフラが抽象化されていることです。パブリックワークロードを展開するさまざまなモデル、特にパブリッククラウドでは、基盤となるインフラ(OS含む)へのアクセスが制限されるか、完全にブロックされることがあります。伝統的なネットワークとホストベースのセキュリティに焦点を合わせているセキュリティ運用チームにとって、この新しい現実は彼らの注意点をアプリケーション層にシフトすることを強要します。これをシフトアップと名付けます。

シフトアップセキュリティがどのように機能するかを説明するために、私たちはさまざまなクラウドネイティブ環境に反映されている責任共有モデルを理解する必要があります。責任共有モデルは、クラウドプロバイダと顧客の間でセキュリティタスクと責任を分けます。AWSなどのクラウドプロバイダは、ホストOSや仮想化レイヤーからサービスが運用される施設の物理的セキュリティまで、さまざまなコンポーネントを運用・管理・制御するため、このモデルは顧客の運用上の負担を軽減するのに役立ちます。

それぞれのシナリオでどれだけシフトアップを考慮する必要があるのか、クラウドでコンテナを実行する際のシナリオをいくつか見てみましょう。

独自のKubernetesクラスタ環境で実行している場合

パブリッククラウドで仮想マシンを起動することで、オープンソースでもディストリビューションでも、独自のKubernetesクラスタを実行できます。そのような場合、Kubernetesコンポーネントとワークロード自体(コンテナのそのもの)を保護するのはあなたの責任です。仮想マシンのOSを選定する際に、AmazonLinuxのようなクラウドプロバイダが提供するOSにしろ、他のLinuxディストリビューションを利用するにしろ、セキュリティを考慮しなければいけませんが、後者は利用者の責任範囲となります。他の顧客からのテナントの分離など、 他のインフラのセキュリティ層に対処する必要はありません。それはクラウドプロバイダの仕事です。
物理レイヤーはクラウドプロバイダにより管理されるため、上の層に目を向ける(シフトアップする)必要があります。

クラウドプロバイダが提供するマネージドKubernetes環境で実行している場合(ex.EKS)

このシナリオでは、Kubernetesマスターはクラウドプロバイダによって管理されます。 つまり、クラスター全体のセキュリティの側面はそれらによって管理されます。ワーカーノードVMのオペレーティングシステムはカスタマイズできます。仮想マシンのセキュリティ管理(パッチ適用、強化など)は別途必要ですが、Kubernetesクラスタそのもののセキュリティ面については考慮が必要ではないという点でシフトアップされています。

「Serverless Container」サービス環境で実行しているコンテナを実行している場合(ex.AWS Fargate)

AWS FargateやAzure Container Instancesなどのサービスを使用すると、基盤となるVM インスタンスをまったく管理しなくても、コンテナを利用することができます。インフラ、オーケストレータ、またはホストのセキュリティを管理することはできません。なぜなら利用できないためです。唯一の責任範囲はコンテナの中身となります。これは、現在、最も明確な事例となります。つまり、シフトアップを意識する必要があります。

セキュリティ体制を強化する方法について知りたい方は以下のサイトから動画を入手してください。

シフトの"すすめ"

シフトレフト、シフトアップのアプローチは、開発サイクルにおけるセキュリティ面で重要な役割となります。セキュリティ担当者はますますパブリッククラウド環境にコンテナをデプロイする現状に、シフトアップを考慮することが不可欠であることに慣れる必要があります。

クラウドネイティブなシステムに移行するとともに、考慮すべきセキュリティ対策も変化していきます。もしまだファイアウォールやホストのセキュリティに焦点を当てているのであれば、今ある現実を受け止め、上のレイヤーに対するセキュリティ(シフトアップ)が必要であることを認識すべきです。

New call-to-action
新規CTA