クラウドネイティブセキュリティでオブザーバビリティが注目される理由：クラウドセキュリティモニタリングのベストプラクティス（6）（2/2 ページ）

» 2024年03月29日 05時00分公開

オブザーバビリティツールがセキュリティで注目される理由

　ここで注目されるのが、オブザーバビリティのアプローチだ。まず、アプリケーションを実行する際のインフラ監視がある。また、アプリケーションがインフラと相まってどう動くかを監視するアプリケーションパフォーマンス監視（APM）も求められる。さらに単体のログだけでなくさまざまなログを収集して監視し、管理する必要もある。この3つの軸で、クラウドネイティブ環境で動くアプリケーションの状態を見ていくのが、オブザーバビリティだ。

　オブザーバビリティのアプローチは、クラウドネイティブなアプリケーションのセキュリティの状態を監視するのにも有効だ。そのため、最近のオブザーバビリティのソリューションでは、アプリケーションの稼働状況だけでなく、セキュリティも結び付けて監視するようになっている。

　従来のツールだけでは、クラウドネイティブなアプリケーションのセキュリティ監視が十分でないという認識が広がっている。複雑で細分化して動くアプリケーションへの未知の攻撃が増えていく。こうした攻撃に対処するには、クラウドネイティブであることを前提とし、さまざまな軸でアプリケーションを把握できなければならない。ここにオブザーバビリティの価値がある。

　インフラはもちろん、その上で動くKubernetesの環境、さらにはその上にあるアプリケーションについて、より細かい粒度でログを収集する。そして集めた情報を迅速に分析して、次にとるべきアクションに結び付ける。この過程でアノマリー検知やインサイトを取得するために、オブザーバビリティのツールを使うこととなる。

　例えば、サーバレスの「Azure Functions」を利用しているなら、モニタリングには「Azure Monitor」が使える。とはいえ、アプリケーション全体ではAzure Functions以外のPaaSサービスも使うだろう。場合によっては、他のクラウドのサービスと連携して動くかもしれない。すると、利用するサービスごとにモニター機能を用いて監視することとなる。

　一つ一つのモニターを見ていけば、障害や脆弱（ぜいじゃく）性を見つけられるかもしれない。しかし複数のモニターツールを見て問題を発見し、見つかった問題から根本原因を追及して対処方法を見出すとなれば、問題発生からかなり長い時間ビジネスを止めることになりかねない。

　アプリケーションを構成する要素ごとにトレースやログ、メトリックスを見ていくことになるが、それらの違いを意識せずに同じタイムラインで「見える化」をする必要がある。そうすることで、いつどのタイミングで、どんな問題が発生しているかが分かる。

　異なるログを同じタイムラインで見られるようにするツールは以前からあった。ただし、何か問題が発生した際に、その時に動いていたアプリケーションのモジュールを特定し、該当するソースコードのどの部分が実行されたかまで見えるようにできるかどうかが重要だ。これが、複数ログを管理する仕組みとオブザーバビリティツールの違いでもある。

オブザーバビリティツールは開発、運用、セキュリティの共通言語に

　もう一つの捉え方として、現状ではアプリケーション側の人が、システムインフラの運用のところまで見ざるを得ない状況にもある。かつては、開発と運用は分かれていたので、アプリケーションの開発側の人は、運用の情報を自ら見ることは基本的にできなかった。何らか問題が発生した際に、運用側に頼んで必要なログなどを取得してもらう状況だった。

　一方、オブザーバビリティツールでは、開発側の人が自ら、運用側の情報を見られるようになる。一方、運用側からも開発の状況が把握できる。つまり、開発と運用が、タイムラグなく同じ情報を見られる。言い換えれば、オブザーバビリティツールが開発と運用の共通言語になる。

　さらに、開発、運用に加えてセキュリティを担保するために活動している人たちがいる。彼らはこれまで、業務を進めるのに自分たちだけのツールを用いてきた。そこにオブザーバビリティツールが登場し、クラウドネイティブな環境のセキュリティを担保するのに便利に使えることが分かってきた。

　開発、運用、セキュリティの全ての担当者が、共通の情報を見ながらコミュニケーションできる。これでDevSecOpsにおける組織間の壁が低くなり、問題への対処も速くなる。