セキュリティを左にシフトするとは、ツールだけでなく文化を変えること

著者

2019年10月29日

0 分で読めます

これは、KubernetesのAppSec戦略の構築に関する全4回シリーズの第2回です。第1回はこちらです。

組織がDevOpsのプラクティスを取り入れ、アプリケーションの構築・保守方法を変革するにつれて、アプリケーション開発のさまざまな側面が変化しています。

多くの組織では、サイト信頼性エンジニアリングを取り入れ、「自分で構築したものは自分で運用する」という考え方を採用することで、従来のシステム管理が変化しました。特にサービスメッシュの普及に伴い、ネットワークはソフトウェアで記述されることが増えています。モニタリングの議論も、既知の未知を解決することから、可観測性や未知の未知に焦点を当てる方向へ移っています。こうした傾向は明らかです。アプリケーション運用のさまざまな側面が、ますます開発者に委ねられています。セキュリティに関して言えば、この移行はまだ始まったばかりです。セキュリティを効果的に移行するには、ツールを慎重に選び、意図的に文化を築く必要があります。

ソフトウェアの単位としてのコンテナ

ツールと文化について考えるにあたり、コンテナを例に見てみましょう。前回の記事で触れたように、コンテナはソフトウェアの標準的な単位になりつつあります。イメージを構築し、組織の境界を越えて共有し、その内容について検証し、プラットフォームやプログラミング言語ごとに異なるパッケージ方法を意識せずに済むように活用しています。

単一のパッケージ形式、パッケージリポジトリ、本番環境にパッケージをインストールする仕組みという考え方は、新しいものではありません。たとえば、RPMパッケージとリポジトリ、そしてYumのようなツールは、このモデルに当てはまると言えるでしょう。しかし、コンテナには、技術的というより組織的な重要な違いが2つあります。

OSのパッケージングは、多くの場合、運用部門内の別チームが担当していました。
単一のパッケージ形式だけを使う組織はほとんどありません。OSやプログラミング言語ごとに、独自のパッケージングツールチェーンがあります。

コンテナイメージで新しいのは、パッケージングの責任が例外なく開発者や開発チームに移りつつあることです。たとえば、GitHub上には公開されているDockerfileが200万件以上あります。以前の世代のパッケージングや組織の慣習を前提に構築されたテスト・セキュリティツールは、現代の開発者のワークフローやツールチェーンにはうまく適合しません。たとえば、パッチの適用は、本番環境に直接変更を加える方法から、変更不可のアーティファクトを再構築して再デプロイする方法へと移行しつつあります。

コンテナの脆弱性管理に関心がありますか？Snykがコンテナのセキュリティ確保にどう役立つか、詳しくはこちら。

開発者中心のツール

イメージの標準化は、進行中の変化に対応する、真に開発者中心のツールを構築する多くの機会をもたらします。新世代のツールには、どのような特長があるでしょうか。

ローカルで使える — 開発者の多くはローカルマシンでコードを読み書きします。ローカルで動作するツールなら、新しい領域への理解を深められます
IDEと連携する — 開発者が統合開発環境を使うなら、使用するツールも統合されていることが重要です
ソース管理システムと直接連携する — Gitベースが主流になりつつあるソース管理システムは、開発者の日々の作業の中心です。特にGitOpsのようなアプローチを採用する開発者が増えるなか、開発者向けツールもチームの一員となる必要があります
CI/CDパイプラインで設定できる — 効果的なソフトウェアデリバリーには継続的インテグレーションが不可欠です。また、開発者へのフィードバックループが短いうちに品質管理を組み込むのに最適な場所でもあります

ソフトウェア開発ライフサイクル（SDLC）全体をカバーするツールには、開発者がアプリケーションへの理解を深め、「自分のマシンでは動くのに」という問題を避けられるという利点があります。

共有を重視するDevOps文化

品質とセキュリティは開発者だけの領域ではありません。成功には、熟練した運用担当者やセキュリティの専門家も欠かせません。責任が開発チームへ移るなか、セキュリティを左にシフトする方法を指導し、教育する専門家が必要です。サイト信頼性エンジニアリング（SRE）チームが、アプリケーションをより適切に運用できるよう開発者を支援するのと同様に、セキュリティにも同じ姿勢が求められます。

組織の壁を越えて異なる専門領域間の共有を促すツールは、望ましいだけでなく必須です。各機能が競合する別々のツールを使う、あるいは一方のグループが二流のユーザー体験を強いられる、といった選択肢では不十分です。運用担当者と開発者が別々のツールを使えば、組織のサイロ化につながるだけです。だからといって、すべてを支配する単一のツールが必要というわけではありません。現代の開発者向けツールは、アプリケーションと開発プロセスへのフィードバックを重視します。開発者向けツールは、運用ツール（詳細な調査や経時的なレポートが可能なもの）と適切に連携し、各役割で使われる抽象化にも対応すべきです。

まとめ

「左にシフトする」という議論では、フィードバックループの短縮を目的として、従来のIT部門から開発チームへ責任を移すことがよく話題になります。しかし、ツールを変えずに働き方だけを根本から変えようとしても、うまくいくことはほとんどありません。複雑なソフトウェアの開発自体が、複雑な社会技術システムです。セキュリティ課題のオーナーシップを開発者により深く委ねるなら、開発者が必要とするツールは、従来の運用担当者向けツールとは異なることも理解する必要があります。