何でもかんでも「クラウドサービスだから利用禁止」にしないためには？ クラウド時代のセキュリティ運用の在り方を考える：失敗、成功事例に学ぶクラウドネイティブセキュリティの勘所（4）

クラウドサービス利用が拡大したことで、企業には新たなセキュリティ運用における課題が生まれています。しかも、運用部門、セキュリティ管理責任者、企画部門など、それぞれの職務によって異なる問題と悩みを抱えています。こうした課題が積み重なった結果、「クラウドサービスは禁止」と決定する極端なケースもあります。本稿では、クラウド時代のセキュリティ運用を考えます。

[小林 勝，キンドリルジャパン]

　クラウドサービスの利用が拡大したことで、さまざまな職務によって異なる問題と悩みがある状況です。それらが積み重なった結果、「クラウドサービス利用を禁止する」という極端な対応を進めるケースも起きています。

　クラウドセキュリティに対する不安からクラウド移行に踏み切れない企業や、クラウド移行したもののクラウドセキュリティに依然として懸念がある企業に向けて、クラウドで実現するセキュリティ対策を事例と併せて解説する本連載。

　今回は、運用部門、セキュリティ管理者、企画部門が抱えている現在の課題を整理し、「クラウドサービス利用を禁止する」という極端な対応にならないために、どのようなクラウドセキュリティを推進すべきかを考えます。

　残念ながら、「こうすれば全てが解決する！」といえるような魔法の答えがあるわけではありませんが、少しでも運用時の課題解決につながる対策として参考になれば幸いです。

運用部門が抱える業務上の課題

　クラウドシステムは、運用部門の手の届かないプロバイダーやネットワークに大きく依存しています。運用部門においては、次のような業務が課題になりつつあります。

複数の技術要素が絡んでいるのに、原因特定の迅速さが求められる

　ユーザーからシステムに関する連絡を受けた後、起きている事象とその原因を特定する必要があるため、時間がかかります。「何となく重い」「何となく不安定」など感覚で指摘してくるケースもあります。被疑箇所を見つけ出すために、端末担当、ネットワーク担当、サーバ担当、クラウド担当など各部署に連絡して、連携する必要もあり、問題解決まで時間がかかります。

ログやアラートの洪水問題

　クラウドの利用によって生み出されるログやアラート量は増加傾向にあります。洪水ともいえるような大量のアラートを全てチェックすると運用担当者への負荷が高まります。リスクの低いアラートであっても内容判別が難しく、調査に数日かかることもあります。

熟練者の運用スキルを全社共有

　複数の監視システムを使用していると、複数のアラートが上がっても関連性がなく、担当者が個別に対応する必要があります。社内の特定の熟練者への依存度が高まります。

プロアクティブな故障の余地把握

　インシデント発生後の対応になるため、事前の計画的な対応が困難です。固定閾値（しきいち）のみでの判別にする場合、熟練者の経験値への依存度が高くなりますし、固定閾値に依存した監視の場合、振る舞いによる異常や予兆を把握することが難しくなります。

　クラウドサービスを利用するようになったことで、「これはセキュリティインシデントなのか？　それともシステム障害なのか？」と考えてしまうような状態が起こりがちです。

　2022年10月10日に起きた全銀ネットの障害発生時、私が聞き取りをしたお客さまの半数が、「自社で何らかのセキュリティインシデントが起こっているのではないかとうたぐった」と言っていました。「トラブルの原因は自社のセキュリティインシデントではない」ことを証明するために、まさに全社的なシステムチェックが必要だったのです。これは運用部門にとって、負荷が高い作業が必要です。

　さまざまなメーカーのネットワーク機器、クラウドサービスを活用していると、セキュリティ対策チームがサイロ化されがちです。「怪しいログが記録されている」「アプリケーションの動作がおかしい」といった異常が起こっても、情報共有ができない事態になりかねません。

　アラート数が膨大になると、「閾値を下げて、アラート件数を下げよう」といった本末転倒な運用体制に変更する例も出ています。膨大なアラートの中から即座に対応すべきものを見つけ出す、経験値とスキルを持った特定のセキュリティエンジニアに仕事が集中する事態になることも多いようです。

　クラウドセキュリティの一環として、従来のセンター集約型セキュリティからSASE（Secure Access Service Edge）に移行する企業もあります。

　しかし、SASEへの移行後、「アプリケーションの動作が遅い」といった声に対しては、どこに原因があるのか、セキュリティ侵害の有無に加え、ネットワーク、SASE基盤、クラウド基盤をそれぞれチェックしなければならず、原因特定に時間がかかるといった事態も起こっています。

運用部門が進めるべき対策は、オブザーバビリティの活用

　そうした事態を避けるために、オブザーバビリティ（Observability：可観測性）が注目されています。オブザーバビリティとは、「Observe（観察する）」と「Ability（能力）」の組み合わせた言葉です。日本語では「可観測性」や「観察する能力」と翻訳されることが多い印象です。

　オブザーバビリティは、ユーザーエクスペリエンス（UX）を監視指標に加えるなど、IT環境全体の見える化を目的としたものです。

　固有のサービス、固有のネットワーク機器によった監視体制から、システム全体を俯瞰（ふかん）的に監視する体制に切り替えていきます。システム全体の状態を即時把握することにより、問題への迅速な初動対応を進められます。報告されるアラートから原因を特定する従来の手法とは異なり、あらゆるITコンポーネントからリアルタイムにデータを収集し、システム（サービス）全体を可視化します。

　オブザーバビリティに取り組むことで、多角的な視点でセキュリティ上の問題点を洗い出すことができるようになります。

セキュリティ管理責任者、経営企画部門の課題

　セキュリティ管理責任者にとって、クラウドは手ごわいサービスです。業務部門が簡単にSaaSを導入できるようになった結果、セキュリティ管理責任者が管理していないのに導入されているSaaS、いわば「野良クラウド」が増加しており、複数の課題が発生しています。

セキュリティ管理責任者が把握していないクラウドサービスの導入

　簡単に導入できるSaaSがシャドーITのような存在になっています。全社的なコスト、アセットがきちんと把握できない状態にも陥りがちです。

ガバナンス統制面でトラブルが起こる可能性

　セキュリティ管理責任者が把握していないため、本来は認めていない情報の活用や情報流出につながるリスクが発生します。また流出していても気が付きにくい状況に陥ります。

利用するクラウドが事業展開している国の法に合致しているのか分からない

　グローバル展開する企業の場合、利用するクラウドサービスがその国の法律に合致しているのかどうかチェックが必要となる場合もあります。とくに個人情報を取り扱う場合には「データの越境」などに注意が必要です。

利用者側にはどうしようもないSaaS側のインシデントでも、非難の対象になる

　ご存じの通り、クラウドサービスには責任共有モデルがあり、利用者側では関与できない領域が存在します。しかし、全く関与できない領域でセキュリティインシデントが起きた場合でも、利用している企業の責任を問う声が発生するケースがあります。

　とあるSaaSでクロスサイトスクリプティング（XSS）攻撃を受け、11社の流通業のEC（電子商取引）サイトから延べ43万件以上の顧客情報が流出し、カード情報も含まれていたケースがありました。SaaS事業者の責任範囲内で攻撃された一方、ECサイト事業者へ非難の声も上がりました。「情報流出するようなSaaS事業者を利用するのが悪い」という声でした。自社に責任はなくても、利用しているクラウドサービスで事故が起これば、企業やブランド価値が下がりかねない事態です。

　各部門が独自にクラウドサービスを利用している場合、担当部門に厳しい処罰が下されるケースもあるでしょう。こうした事態を避けるために、「クラウドサービス利用を禁止する」という極端な対応を進めるケースも起きています。

　そうした事態を避けるためには、クラウドサービスを利用する際には共有する体制を作ることが必要です。利用するクラウドサービスは、評価と管理をすることも欠かせません。

　しかし、野良クラウドが利用されていないのかどうかを検知し、利用するクラウドサービスを評価、管理する一連のプロセスには多くの課題があります。特に難しいのが利用するサービスの評価と管理です。利用サービスに問題がないかどうかをチェックする場合、どのようなチェック体制を設ければよいのか？　チェックに必要な情報はどのように集めればよいのか？　特にグローバルでサービスを展開しているクラウド事業者の場合、利用する国の法律に準拠しているのかどうかのチェックが容易ではありません。

セキュリティ管理責任者、経営企画部門は評価基準、選定フローを整備する

　クラウドサービス事業者も積極的に情報を出している会社もあれば、個別に問い合わせをしなければ情報を出してくれないこともあります。

　このように決して容易な状況ではありませんが、クラウドサービスを利用する際には、社内で利用申請から選定プロセスに至るまで明確なフローを構築する必要があります。例外を作ることなく、フローにのっとった選定が欠かせません。

　また、一度選定基準をクリアしたサービスであっても、定期的な監査の実施が必要です。可能であれば、年に1回程度のペースで監査することが望ましいでしょう。

　利用するクラウドサービスを評価する際の基準を明確にしておくことも必要です。主な判断基準は次の通りです。それぞれメリットとデメリットがあります。

チェックリストを作成し、クラウドプロバイダーに確認する

　利用者は独自基準で評価できます。ただし、手間と時間がかかります。チェックリストを評価するセキュリティ専門家も欠かせません。

クラウドプロバイダーの公開基準を基に評価する

　プロバイダーに問い合わせることなく評価できるので、手軽に評価できます。ただし、公開基準から情報を読み取れる専門家が必須です。また、公開情報が十分ではないことも多い印象です。

CASBが提供しているスコアを使用する

　CASB（Cloud Access Security Broker）が提供するスコアをそのまま使用するため簡単で、スコアを利用者側の要求事項と照らし合わせて評価もできます。ただし、一般的なスコア付けであり、利用者の環境や要件を考慮したスコア付けではありません。クラウドサービスがCASBで評価されているかどうかはベンダー次第で、特に日本のクラウドサービスは評価されていないケースも多い印象です。

VRMやTPRMを用いて評価する

　VRM（Vendor Risk Management）やTPRM（Third Party Risk Management）は昨今注目されつつある評価方法であり、最近はクラウドサービスの評価もできます。評価者が独自にチェックリストを用意する必要がなく、カスタマイズも可能です。ただし、クラウドサービス評価は比較的新しいアプローチで、有効性は明確ではありません。

ISMAPを利用して評価する

　ISMAP（Information system Security Management and Assessment Program）は2023年、内閣官房（内閣サイバーセキュリティセンター・情報通信技術〈IT〉総合戦略室）、総務省、経済産業省が所管して発足した「政府情報システムのためのセキュリティ評価制度」です。始まったのが2023年ということもあり、登録されているクラウドサービスは2023年9月時点で48にとどまっています。全てのクラウドサービスが登録されているとは限りません。

おわりに

　それぞれの選択肢に一長一短があることを踏まえると、「自分の会社に適したクラウドサービスの評価基準とはどのようなものだろうか？」と社内で話し合い、自社に合致したチェックリストを作ってみることからスタートすることをお勧めしたいと思います。

　その際、社内で保有する情報資産の重要度をあらためて確認し、クラウドの信頼度と照らし合わせ、評価基準を変えていくことも必要になると思います。

　「社内の情報資産の重要度評価は、セキュリティ運用をしている部門や運用部門だけでは難しい」という声もあるでしょう。経営層を巻き込み、社内の情報資産にはどのようなものがあり、その重要度をどう評価するか、外部に流出するとどのようなデメリットがあるのかなどを話し合っていくことも必要でしょう。

　しかも、こうした議論は一度結論が出たら終わりではなく、クラウドの評価同様、定期的に実施することが望ましいといえます。

　自社でこうした一連の取り組みは難しいという場合もあるでしょう。外部パートナー企業と連携しながら、情報資産の価値と利用するクラウドサービスに対する評価付けをあらためて考えてみることも有効な方法です。

筆者プロフィール

小林 勝（こばやし まさる）

キンドリルジャパン コンサルト事業本部 技術戦略アソシエイトディレクター コンサルトパートナー

セキュリティ全般の技術戦略、ビジネス開発などを担当。グローバル196の国と地域のICT環境にも精通し、グローバルガバナンス、各国の法令対応などを得意とする。ゼロトラストアーキテクチャ、OT/IoTセキュリティ対策の啓蒙、サービス開発、クラウドセキュリティ対策支援、クラウド統合監視基盤の企画戦略を経験。分散型デジタルID、QKD（量子鍵配送）、免疫システムに着目した次世代セキュリティの研究に従事。経済安全保障、重要インフラ、サプライチェーンリスクマネジメントをテーマとした講演を多数実施。著書に『ゼロトラストアーキテクチャ入門』などがある。