DX時代のクラウドサービス管理の在り方

新型コロナウイルス感染症（COVID-19）対策のためのリモートワーク環境の整備、「政府情報システムのためのセキュリティ評価制度（ISMAP）」の運用開始等も相まって、クラウドサービスの利用はさらに増えています。その一方でクラウドサービス利用に関連するセキュリティ事故も頻繁に発生しており、これらへの対策が急務となっています。
本稿では、最近の国内の金融機関におけるクラウドサービス利用状況や、課題感を踏まえたクラウドサービスの管理ルールにおける見直しポイントについて解説します。

クラウドサービス利用に関連した最近の事故事例
金融機関におけるクラウドサービス利用の状況
金融機関のクラウドサービス管理における課題感
管理ルールの見直しポイント
まとめ

最近でもクラウドサービス利用に関連した事故等は多く報告されています。そのうち代表的なものを2点ピックアップします。

【データ保護に関連する法令等への違反】
日本国内で利用されているサービスであっても、その運用の一部を海外に委託、あるいはデータセンター等のインフラが海外に存在している可能性があります。利用規約等において内容が明記され、その通りに運用されているのであればこのこと自体には問題はありませんが、規約内容の不明瞭さや利用者の確認が不十分であることで、意図せず個人情報保護の法令に違反してしまうことが有り得ます。また、必ずしもクラウドサービス事業者が利用者として求める水準の情報管理体制やガバナンスを保持していないことも考えられますので、クラウドサービスの利用にあたってはこれらをしっかりと確認しておくことが重要です。

【クラウドサービスの設定不備に起因する情報漏えい】
クラウドストレージ領域に対して、インターネットから不特定多数の人が自由に閲覧できる状態となっていたという事例はいまだによく見られます。利用者による単純な設定ミスのみではなく、クラウドサービスのバージョンアップや仕様変更に起因する事故も発生しています。これらは利用者側で設定を行うパラメータに起因するケースがほとんどであるため、どのようにして正しい設定を行い、またそれを維持するのかが問われています。

現在では、規模の差はあれ多くの金融機関が何らかの形でクラウドサービスを利用している状況です。
たとえば、財務会計システムを含む大半のシステムをパブリッククラウドへシフトし、勘定系システムの稼働に向けた計画の推進や、オープン勘定系システムのパブリッククラウドでの稼働を開始しているケースも見られます。こういった事例のように、重要なシステムでのクラウドサービス利用が広がっています。
従来は、クラウドサービスの可用性や機密性への懸念により採用を見送るケースもありました。しかし、実際には複数の国・地域やデータセンターをまたいだシステム冗長構成が比較的容易に実現できることや、多種多様なセキュリティサービスや機能を組み合わせてセキュリティ強度の向上が期待できること（ゼロトラストセキュリティ対応とも親和性が高い）など、非常に優れていることがわかってきました。重要なシステムでクラウドサービスが採用されているという事実がこれを裏付けていると言えます。
一方で、クラウドサービスの使い方も変わってきています。「IaaS/PaaS」を採用し、既存システムのリプレイスのタイミングに合わせて重要度の低いシステムから順番に移行していくような従来からの流れは現在も変わりませんが、FAQ・チャットボットを利用するシステムやデータ活用等に「SaaS」を採用するケースも増えています。一般的にDXの推進に「SaaS」活用は欠かせないと考えられており、ユーザー部門主導でより短期間で導入できるアジリティ面は「SaaS」利用の大きなメリットです。（図表1参照）。

【図表1　SaaSの特徴】

安全にクラウドサービスを利用するためにはクラウドサービス事業者と利用者双方における統制が必要であり、利用者としてはこれらを評価するためのプロセスを整備することが重要です（図表2参照）。

【図表2　クラウドサービス利用時における評価プロセスの整備例】

上記の例ではクラウドサービス利用の検討対象案件ごとにクラウド化の是非の判断から始まり、最終的には本番稼働直前の水際対策の設定チェックまでを一連のプロセスとして行います。ここまでのルールは整備していなくとも、多くの各金融機関においてすでに何かしらのクラウドサービス管理におけるルールが整備、運用されています。
従来はクラウドサービスの利用数はそれほど多くなかったため、比較的十分な時間と工数を掛けてこのような評価が可能でしたが、昨今では利用数が大きく増えたことにより、評価プロセス実施の負荷が高まっています。そのため、いかにして評価の効率性と確認の強度（場合によってはより高い強度の確認が求められる）を両立するのかが課題となっています。
とりわけ「SaaS」の評価における負荷増が顕著です。サービスの機能や仕様のバリエーションが多岐にわたるため、これらの把握に一定の時間が掛かることに加え、規模の小さいクラウドサービス事業者や必ずしもITリテラシーが高くないユーザー部門の担当者が評価プロセスに関与することで、期待される質の回答を得るまでのやり取りが多くなりがちな点も負荷増の要因と考えられます。

いかにして効率的かつ要点を抑えた評価を行うのか。前述の図表2の「（3）リスク評価」と「（4）設定チェック」にフォーカスして解説します。

リスク評価における判断基準の整備
リスク評価の項目を一覧化していたとしても、その回答内容の良し悪しやリスク受容の可否については都度の判断が必要なケースは少なくありません。あらかじめ統制の水準や判断の基準を定めて利用部門に開示できれば、効率的かつ目線が合った評価が可能となります。例えば、クラウドサービス事業者の情報セキュリティ統制の体制を確認する評価項目があったとして、さほど重要ではないシステムの場合はクラウドサービス事業者に求める情報が開示されれば「可」と判断できますが、重要度の高いシステムの場合はさらにSOC2レポートやISMAP認定等の第三者機関によるお墨付きがあることを踏まえて「可」と判断する、といったイメージです。
また、これらの基準は、「IaaS/PaaS」と「SaaS」を区別して定めることが重要です。例えば「ロックイン」のリスクへの統制の場合、「IaaS/PaaS」では、特定のクラウドサービスにロックインされないための移行性の確保（データ移行用のツールやインタフェースの確保）が重要ですが、「SaaS」の場合はそもそも移行先となるような代替サービスが存在しないことも考えられます。そのため、移行性の確保よりも当該サービスが利用できなくなった場合の業務継続の要否や、必要な場合の代替手段（例えば手動運用）の考慮が重要となるのです。こういった違いを踏まえた検討をしておかないと、せっかく定めたルールが実態に即さない使いにくいものとなってしまいます。
加えて、一部の技術関連のリスクについては、どのような使い方をするのか（=ユースケース）を踏まえた判断の基準を検討することも有効です（図表3参照）。特に「SaaS」の場合は、サービス仕様等の把握のためにリスク評価時に追加のヒアリング等が必要となるケースが多いと思われますが、あらかじめ想定される使い方や気にすべき機能等から具体的な統制要件を整理しておくことで、そのような確認の負荷を軽減することができます。

設定チェック（水際対策）の基準の整備
設定チェックの基準の整備にあたっては、米国CIS（Center for Internet Security）のCISベンチマークを参考にすることが考えられます。このガイドラインは、サービスごとの具体的なパラメータレベルでの推奨事項が示されているのが特徴です。CISベンチマークの基準がないサービスや企業固有の要件への対応のためには、同じく米国CSA（Cloud Security Alliance）の Cloud Control Matrixや各サービスのベストプラクティス文書等を参考にすることが考えられます。
導入するためのネットワーク構成や対応できるサービスが限られる等の前提はありますが、CSPM（Cloud Security Posture Management）ソリューションの利用も有効です。このソリューションでは、あらかじめ作成済みのパラメータ設定の定義内容との差分がないのかをAPI等を通じて自動チェックします。この方法であれば、手動での設定値確認と比べるとかなり負荷が軽減できます。ただし、メーカー標準で用意されている項目以外の会社独自の項目等の監視を行うためには、定義設定のチューニング等が必要となります。
なお、CISベンチマーク等を活用する場合もCSPMソリューションを利用する場合も、いずれも一度セキュリティ設定をしたらそれで終わりというわけにはいきません。セキュリティ設定の維持や、外部環境の変化等に伴う内容を見直しの運用ルールをしっかりと決めておくことが重要です。また、基準からの逸脱事項の検知時においては、影響分析や対応優先度付け等が必要となるため、これを容易にするためにそれぞれのセキュリティ設定がリスクと紐付けて管理されていることが望ましいと言えます。

クラウドサービス利用の環境が変わってくるなか、いかにして効率的かつ強度を保った管理を行うのかが課題です。このような課題へのアプローチとして、リスク評価を効率化するための判断基準の整備と、ガイドラインやソリューションを活用した設定チェックの基準の整備が有効だと言えるでしょう。

KPMGコンサルティング
マネジャー　宮本 広道