クラウドがITセキュリティをAppSecへと変える仕組み

クラウドコンピューティングは、これまでにない効率化とイノベーションを可能にし、テクノロジーの世界に間違いなく大きな変革をもたらしました。しかし、あまり語られることのない重要な変化も引き起こしました。クラウドによって、インフラがアプリケーションの一部になったのです。

この変化は、セキュリティの実践方法に大きな影響を及ぼします。全般的に、現在のセキュリティツールや実践手法は、中央IT部門やセキュリティチーム向けに設計され、それらのチームのスキルや環境に対応するよう構築されています。クラウドアプリでは、ネットワークアクセス、OSのパッチ適用、アクセス権限などに関する判断は、IT部門ではなく開発者が行います。判断は一元的にではなく、アプリケーションごとに個別に行われます。また、特定のレビュー段階に限らず、開発プロセスの一部として常に行われます。

それでも、こうした判断がもたらすセキュリティ上の影響は変わりません。ポートが開いていれば、データセンターのネットワークセグメントと同じように、クラウドVPCが侵害される可能性があります。パッチ未適用のコンテナは、ベアメタルマシンと同様にハッキングされるおそれがあります。同じリスクが存在し、アプリの規模によってはさらに深刻化することもあります。

そのため、こうした脅威への対処方法を見直す必要があります。ただし今回は、アプリのコンテキストに即して考えなければなりません。チームもプロセスもスキルも異なります。この記事では、アプリケーションの範囲がインフラにまで広がった経緯を説明し、セキュリティへの影響を掘り下げます。セキュリティ対策の設計、ツールの選定、チームの編成に役立つ視点だと考えています。

表記について：ここでは「クラウド」という言葉を、クラウドコンピューティングだけでなく、コンテナ、サーバーレス、その他多くの新しいテクノロジーも含む意味で使います。また「クラウド以前と以後」と表現していますが、実際には移行の過程にある企業はほとんどありません。この単純化した見方は、全体像を描くために意図的に採用しています。複雑な世界であることは十分承知しています。

クラウド以前のアプリケーション

クラウド以前、アプリケーションは大規模なITスタック上に構築されていました。実際には、今もほとんどの企業が主にこの方式で運用していますが、ここでは過去形で説明します。

データセンターでは、中央IT部門が慎重に容量を管理し、リソースを割り当てていました。企業はラックスペースの量を管理し、サーバーを購入して稼働させ、ハードウェア障害に対処し、誰がどのサーバーを使っているかを把握する必要がありました。アプリケーションにサーバーが必要な場合は、申請書類を提出して承認を得なければなりませんでした。サーバーを追加するには、費用を増やすか、ほかの人にサーバーを割り当てないかのどちらかだったからです。

仮想化が登場すると、通常はvSphereのような別のITレイヤーが加わり、物理マシン上で仮想マシンを管理するようになりました。効率は上がりましたが、基本的なプロセスは変わりませんでした。容量には限りがあり、共有されていたため、サーバーを利用するにはチケットを申請する必要があり、中央ITグループがサーバー容量とその上の仮想化レイヤーの両方を管理しなければなりませんでした。

サーバー以外にも、IT部門はネットワークを管理していました。ネットワークは物理スイッチやルーターで構成され、容量よりもアクセス制御、つまりどのユーザーがネットワークにアクセスできるか、どのネットワーク同士を接続できるかに重点が置かれていました。ネットワークは複雑になりがちです。そのため、データセンター内の複雑な通信権限の管理や帯域幅の割り当てでも、中央IT部門が重要な役割を果たしていました。

ハードウェアに加え、IT部門は一元管理されるリソースも扱っていました。その一例が、仮想マシン用のゴールデンイメージです。これらのゴールデンVMには、法令遵守、セキュリティ、全般的な品質の観点から精査された承認済みソフトウェアが含まれていました。中央IT部門はこれらのVMも監視し、脆弱性の修正や社内ポリシーの変更に合わせて更新していました。アプリケーションは多くの場合、手作業でVMにインストールされ、更新に対応するため必要に応じて再起動されていました。

マネージドサービスも、一元管理されるリソースの一例です。たとえば、アプリケーションの稼働に必要な大規模なOracleデータベースをIT部門が管理していたケースがあります。1人以上のDBA（データベース管理者）がインデックスやテーブルを管理し、必要に応じて各アプリケーションチームと連携しながら、チームのニーズに合わせて調整していました。

その上に、アプリケーションそのものがありました。アプリケーションはコードとライブラリで構成され、動作させるには非常に特定の環境にデプロイする必要がありました。ハードウェア、ベースVM、DBの利用、CDN、その他の要素を変更する場合は、チケットを申請して待たなければなりませんでした。

当時は、リソースに限りがあり、共有する必要があったため、それも理にかなっていました。サーバー、ネットワーク、ストレージなど、物理的な容量を追加するには、多くの時間と費用がかかりました。中央アプリケーションの導入や拡張にも、中央IT部門の大きな労力が必要でした。中央IT部門も共有リソースの一つであり、容量の拡大には時間と費用がかかります。そのため、あるアプリがより多くのリソースを得れば、別のアプリが使える分は減るという、ゼロサムゲームになっていました。

クラウド以後のアプリケーション

そこにクラウドが登場し、こうした制約を取り払いました。

ハードウェア容量は問題ではなくなりました。開発者はクラウドアカウントにアクセスできれば、予算の範囲内で必要なだけサーバーをプロビジョニングできます。セルフサービス型のソフトウェア制御により、中央IT部門の関与なしに、サーバーの規模を柔軟に拡大・縮小できます。

ネットワークも他に依存しなくなりました。アプリケーションチームは独自のVirtual Private Cloud（VPC）を作成でき、クラウドプラットフォームがほかの環境から分離します。ネットワークへのアクセスはアプリケーションのニーズに応じて細かく設定でき、すべてソフトウェア上でセルフサービスにより構成できます。

クラウドVMはデータセンター時代のVMほど一元管理されなくなりましたが、コンテナはこの結びつきを完全に断ち切りました。コンテナのビルド手順は通常、ソースコードリポジトリで定義され、アプリとともにビルドされるため、中央IT部門が可視性を確保するのは難しく、実際にはパッチを適用することも不可能です。中央管理の「ゴールデンイメージ」も魅力を失いつつあります。アプリを再ビルドしない限りイメージへのパッチが適用されず、開発者が外部のベースイメージに頼るケースも増えているためです。

一元管理されていたアプリケーションは、データベース、認証、メッセージングなどを提供する、クラウドプラットフォーム組み込みの使いやすいサービスに置き換わりました。多くの中央アプリケーションとは異なり、これらのサービスはAPIを通じて利用でき、開発チームによるセルフサービスのプロビジョニングと利用を前提に設計されています。小規模なアプリケーションはパッケージ化されたコンテナに置き換わり、Docker Hubから簡単に利用できる、アプリのトポロジーを構成する別のマイクロサービスとなりました。どちらの場合も、チケットを申請して限られたITリソースの割り当てを待つ必要はなくなりました。

最後に、DevOpsチーム（SREやPlatformと呼ばれることもあります）が生まれ、中央IT部門は各チームと連携する運用チームに置き換わりました。こうしたチームは、アプリケーションが利用するインフラを管理しようとするのではなく、Kubernetesなどのツールやサービスを提供し、開発者がアプリに組み込まれたインフラレイヤーを自ら運用できるようにします。

アプリケーションとしてのインフラを保護する

クラウドの普及に伴い、一元管理されたインフラの多くは不要になっていきます。その代わり、インフラはアプリケーションそのものの一部になります。CDN、APIゲートウェイ、ミドルウェアなどがアプリケーションの一部となり、開発チームの自立性とスピードを高めていることから、この流れは今後も続くでしょう。この変化はパブリッククラウドで始まりましたが、同じ手法を取り入れたプライベートクラウドにも広がっています。

しかし、セキュリティ上の懸念がなくなったわけではありません。

パッチ未適用のコンテナは、放置されたVMやベアメタルマシンと同じように簡単にハッキングされる可能性があります。不必要に開かれたポートがあれば、ホストされている場所にかかわらず、機密データへのアクセスを攻撃者に許してしまう可能性があります。データベース内の暗号化されていないデータも、特に共有サービスに保存されている場合、すぐに侵害されるおそれがあります。同じ攻撃経路が存在するため、アプリケーションを保護する対策を講じながら、こうしたセキュリティ上の懸念に注意を払う必要があります。

変えるべきなのは、こうして、インフラの脅威からどう守るかです。現在のソリューションや実践手法は、独立して動くアプリケーションチームではなく、中央ITチーム向けに設計されています。チームごとに使えるよう、既存のものを調整することもありますが、その用途に本当に適しているケースは非常にまれです。

「アプリケーションとしてのインフラ」という新たな現実に基づく視点を取り入れる必要があります。この見直しは大きな課題で、簡単な箇条書きにまとめられるものではありませんが、検討すべき変更点をいくつか紹介します。

• クラウド製品を保護するために、セキュリティ組織の構造を見直しましょう。ITスタック向けのセキュリティはIT組織の構造と連携しやすいよう設計されていましたが、アプリケーションスタック向けのセキュリティは、開発組織と連携できる構造にすべきです。このテーマについてはまだ多く語りたいことがありますが、詳しくは別の記事で取り上げることになりそうです……

• アプリケーション開発者のニーズを理解しましょう。テクノロジーだけでなく、開発者を取り巻く現実も理解するために時間をかけ、実践方法、ツール、期待することを開発者に合わせて調整しましょう。業界のベストプラクティスは開発者ではなくIT部門のニーズに基づいていることが多いため、それを鵜呑みにしないでください。

• クラウド以前のソリューションが、クラウドアプリにも適していると思い込まないでください。旧来のスタックと新しいスタックで同じツールを使い続けるのは便利ですが、異なる両方の環境にうまく対応できるとは限りません。ベンダーが提供するほかのツールや、他のベンダーの製品も確認し、クラウド環境に適したツールを選びましょう。

• 柔軟で、APIを活用し、セルフサービスで使えるセキュリティツールに投資しましょう。ITチームは中央機能であり、カスタム統合に多くの時間をかけられます。一方、開発チームやスタックには、より大きな違いがあります。さまざまな環境に適応しながら、同等のセキュリティ制御とガバナンスを提供できるツールに投資しましょう。

この移行は一夜にして実現するものではありません。10年後には、クラウド以前のアプリは、現在のメインフレーム環境のように、旧来のセキュリティ制御を伴うレガシーと見なされるでしょう。今こそ、新しい世代のセキュリティを築き始めるときです。