クラウドサービスのリスク審査はなぜ疲弊するのか？～実態と業務のヒント～
DXに不可欠のクラウドサービスの活用。組織で利用するには事前のセキュリティチェックも欠かせませんが、その審査には多くの負担が伴っているのが実情です。
グラフ1：クラウドサービス利用状況（企業）の推移※
※総務省「令和４年通信利用動向調査の結果(令和5年5月29日)」より。
グラフ2：世界のパブリッククラウドサービス市場規模（売上高）の推移及び予測※
※総務省「情報通信白書 令和5年版 -第2部 情報通信分野の現状と課題」より。
企業が商用クラウドサービスの利用する狙いの1つに、セキュリティリスクの責任範囲の一部をサービス提供側に移管しながらも、内製でシステム構築する場合と比較して素早くビジネスを開始させることができる利点があり、展開する事業の優位性を高められる可能性があります。
図：クラウドサービス導入の主なメリット
上記の前提として、自社で使用するクラウドサービスがセキュリティリスクに脅かされないよう信頼できるものなのか、事前に審査を行う必要があります。筆者は、中堅から大手企業10社以上のセキュリティ担当部門やリスク管理部門の担当者の方とこのテーマで議論をさせていただきました。
なお、実際のヒアリングでは「SaaS」としての話題がほとんどですが、後述する話題はクラウドサービス全体に適用できるものですので、本稿ではIaaS、PaaSなども含めたクラウドサービス全体をトピックとして扱います。
場合によっては、事業部から週1回程度クラウドサービスの利用申請があるというケースも（画像はイメージ）
現在、大半の企業では組織独自のクラウドサービス使用時のチェックリストを作成し、利用部門からの申請を受けて審査を実施されているようです。なお、この審査業務は企業によって2週間～1か月以上を要するのが実情とお聞きしており、昨今のクラウドサービスの利用増加に伴って、審査業務の現場は大変疲弊しているとお聞きします。このパートでは、著者が考える「疲弊」の理由をいくつか挙げてみます。
●チェック項目が多岐にわたる&増加していく
多くの企業では表形式のチェックリストを作成し、利用部門からの申請に基づいて、ITセキュリティ部門やリスク管理部門が審査を行っています。セキュリティに関する一般的な項目としては、通信やデータの暗号化、多要素認証、シングルサインオン、アクセス制御関連、ログの保管状況、マルウェア対策の導入状況、監視体制やバックアップ取得状況など多岐にわたります。
企業によっては、組織独自のチェック項目の中に「標的型攻撃やランサムウェア攻撃対策をどのように実施しているか」という、敢えて抽象度の高い質問をサービス事業者に投げかけ、その回答内容に応じて事業者のレベルを測る、という対応をされているケースもお聞きしています。
また、改正個人情報保護法の施行後、個人情報を扱う企業体制や管理プロセスなども特化して審査項目を設けているケースも多くなってきています。
●事業者へのチェックを直接行っている
審査中に不明点があれば、利用部門（利用組織内では事業部門であることが多いでしょう）からサービス事業者へ詳細な確認を依頼する必要が出てきます。利用部門側がITやクラウドサービスの知識が十分ではなかったり、不慣れなどの理由でベンダに適切に確認ができない場合、審査を行うIT・セキュリティ部門やリスク管理部門自らがサービス事業者へ照会されているケースも聞きます。
●シャドーIT化していくクラウドサービス
一方、上記では事業部門側から申請があり、審査プロセスを通るという前提で記載しましたが、実情としてはいわゆるシャドーIＴと呼ばれる、未把握のクラウドサービス利用が行われている実態もあります。
ある企業では、「審査を行うITセキュリティ部門が知らないところでクラウドサービスの契約・使用開始する」ということが、社内的に行えないように予め購買部門に働きかけ、社内プロセスとして必ずＩＴセキュリティ部門が介在するプロセスとして未然に社内のリスクヘッジを行っている、という実例もお聞きしたことがあります。
このように、審査するための項目の設定や実際に必要な情報を引き出す工程の中で、非常に煩雑で時間や労力の要するオペレーションが発生する実情があり、利用部門および審査を行うITセキュリティ部門やリスク管理部門などクラウドサービスを安全に使用させるという目的を達成するための審査業務において組織が疲弊しているといった話をよく聞きます。
また、冒頭に記載したとおり、企業はクラウドサービスを利用して素早くビジネスを開始することが目的であるため、このチェック自体も「従業員にクラウドサービスを使用させないために審査を行う」のではなく、「クラウドサービスを可能な限り安全に使用してもらうために審査を行う」が目的です。
このため、申請されたクラウドサービスが単純に危険だからといって「使用しないでください」という判断は会社の利益を損なうことに繋がりかねません。ITセキュリティ部門は安全性が担保できないサービスの利用申請については、代替サービスを提案したり、申請されたサービスを「いかに安全に使ってもらうか」、が審査を実施する側の腕の見せどころだとも言えるでしょう。
先に「企業は組織独自のチェックリストを作成している」と記載しましたが、この評価項目の作成に非常に悩まれているようです。外部公開され、企業が審査の参考にできるものとして経済産業省が公開しているクラウドサービスレベルのチェックリストがあります。
画面：経済産業省「クラウドサービスレベルのチェックリスト(2010年8月16日)」の一例
各カテゴリや項目の例としては「可用性」、「信頼性」、「性能」、「拡張性」、「サポート」、「データ管理」、「セキュリティ」の8カテゴリ全49項目で構成されており、企業はこのリストで審査を行うことが可能です。一例を挙げると、サービス稼働率や障害発生時の体制、ログの保存期間、認証の取得、暗号化の有無などが含まれています。
一方で、 「■チェックリスト策定の背景と目的」に、「必ずしも全ての項目についてレベルを定める必要があるわけではない。また、チェックリストに掲載されていない項目についても状況に応じて確認しておく必要がある点に留意の上、利用いただきたい」と記載されていることにも注意してください。本チェックシートの利用においては公開が2010年8月であることも認識した上で、自社において評価項目が妥当であるかは検討する必要があります。
これ以外に、政府や公的機関が設けているクラウドサービスの認証制度を取得できているかを確認するということも有効です。日本では「ISMAP」、米国では「FedRAMP」があります。ただ、これらはあくまで各国政府の調達基準に基づいた認証制度であり、認証を受けているサービスが政府機関のみに提供されているケースもあります。あくまで、自社が定めるセキュリティの基準があることを前提に、公開内容と照らし合わせ、導入が適切か判断することが求められます。
また、企業によっては信頼に足る外部評価機関のチェックを通っているクラウドサービスかどうかを確認しているところもあります。具体的には以下のような評価機関・組織です。
●Cloud Security Alliance（CSA）のSTAR認証
CSAは、クラウドコンピューティングのセキュリティを保証するため、ベストプラクティスの共有・利用を促進し、その使用に関する教育プログラムを提供することを目的としたNPOです。STAR※という独自の認証制度を持ち、2024年2月25日現在、サービス事業者・サービス名ごとにレベル1（自己評価）とレベル2（CSAによる認定）の情報が公開されています。レベル3（継続的監視）は、現在準備中です（2024年3月現在）。原文は英語ですが、日本法人であるCSAジャパンでは、一部の事業者のセルフチェックリスト（日本語）※を公開しています。
※Security, Trust Assurance and Riskの略称。
※CSAでは、Consensus Assessments Initiative Questionnaire（CAIQ）レポートと呼んでいます。
図：CSAのSTAR認証を受けているサービス事業者の画面例（トレンドマイクロの場合）
●Shared AssessmentsのStandardized Information Gathering (SIG)
Shared Assessmentsは、サードパーティのリスク保証を推進するためのベストプラクティス、教育、製品の開発を専門とする世界規模の会員組織です。GDPR、NIST-SP800-161、ISO27001など、米国・欧州・アジア地域の各業界標準をカバーしたサードパーティリスク管理製品を開発・提供しています。
クラウドサービスの審査業務を行う目的は、企業のビジネス目標を達成するために安心してクラウドサービスを利用できる環境をＩＴセキュリティ部門やリスク管理部門を通じて従業員に提供する、と言えるかと思います。
そのため、審査の基準で考えるべきは「ビジネスの目的に応じて必要な安全性や可用性を担保できているか」であり、サービス自体の安全性の観点だけでなく、そのクラウドサービスが「どのような用途」で「どのような使い方」によって、その過程で「どのような情報を扱うか」などによって適切に評価を行う必要があります。
上記を言い換えると、重要な情報を扱うクラウドサービスの導入・利用は入念に審査を行うべきであり、逆にシンプルな目的で機微な情報が扱われないクラウドサービスの場合は審査の粒度を落とす、などの効果・効率を考えた審査プロセスの最適化が求められると考えられます。
加えて、対象業務に重要度を設定した上で、その重要度に応じて簡易審査や詳細審査に分類する考え方もあります。例えば、審査を「簡易審査」と「詳細審査」に分けるなどして、簡易審査はベンダが公開する評価情報を随時閲覧してその評価をもって審査を完了する、詳細調査が必要な場合は不足される情報について追加でベンダへ確認を行う、といった考え方です。このように対象の業務や利用形態に加えて扱う情報などにより審査プロセスに選択肢を持たせることも適切にクラウドサービスを審査するためのヒントになります。
また、前述した通り、企業が公開している情報をうまく活用する方法として、「脆弱性対応がしっかりできている企業やサービスなのか」といったよくある疑問については、認証取得やコンプライアンスへの準拠を確認すると、その企業やサービスが一定の脆弱性管理プロセスを満たした上で提供されていることを効率的に確認できるケースもあります。
クラウドサービスの審査は初回の申請時のみに着目されがちですが、クラウドサービスの性質上、仕様の変更も頻繁に行われます。なお、企業がそのクラウドサービスが取得する認証情報なども審査以後に変更されている可能性があります。このためクラウドサービス利用開始時に審査を行った場合も、定期的に審査を実施して継続的に安全を担保することが求められます。
世の中にはクラウドサービスのリスク審査の代行サービスが存在しており、審査業務自体をアウトソースするという考え方も出てきています。審査業務をアウトソースするメリットは業務を移管することによる作業時間の減少が挙げられます。とは言え、自社で実施していたことを他社に移管することになるため、利用部門からの申請・審査～実際の利用開始までの時間はあまり短縮されないケースも多いと聞きます。アウトソースを検討する際は、実際のプロセスを検証するなどしてプロセスがどのように変化するかを理解しておく必要があります。
上記の留意点に加えて、適切な審査はあくまでビジネスインパクト（用途、使い方、扱う情報など）を企業や事業の特性をもって判断されるべきものであり、このような性質の業務であることを考えた場合、完全な審査業務のアウトソースは企業によっては適さない場合もあるでしょう。
クラウドサービスのリスク評価結果を機能として提供しているセキュリティソリューションも存在します。例えばトレンドマイクロの「Trend Vision One」のAttack Surface Risk Managementでは、組織内における「承認済/不承認」のクラウドサービスの利用状況の可視化に加え、そのクラウドサービスが準拠しているコンプライアンス・実装されているセキュリティ機能などのリスク評価結果を提供しています（下記画面の「コンプライアンス」や「セキュリティ機能」の項目を参照）。また、Trend Vision Oneの他機能と連携することで、この評価結果を用いた利用制限も行えます。
画面：Trend Vision OneのAttack Surface Risk Managementを活用したリスク評価（Microsoft Teamsの場合。2024年2月26日現在）
まとめ ・審査の負荷を軽減する方法として審査の代行や評価項目を公開するサービスなども存在している。クラウドサービスを利用する目的や扱う情報などにより基準を複数設けたり、認証取得やコンプライアンス準拠などを参考とするなどして適切に審査を行える |
最後に
DX推進の流れはますます加速し、これに追従する形で企業のクラウドサービス利用は更に増加すると考えられます。本記事ではクラウドサービス審査における実態や課題、それに付随するヒントを記載しましたが、上記で述べた審査の代行サービスやソリューションは万能ではありません。繰り返しとなりますが、該当クラウドサービスが「どのような用途」で「どのような使い方」によって、その過程で「どのような情報を扱うか」などによって適切に評価を行う必要があります。本記事で記載した各企業の担当者の現場の苦悩や独自の工夫が本記事をお読みの皆様のヒントになれば幸いです。
＜関連記事＞
FedRAMPとは？～制度の概要と認証までのプロセスを解説～
ISMAPとは？クラウドサービスリストへの登録のメリットは？
Security GO新着記事
ダークパターンとは？企業にとってのリスクを解説
（2024年11月20日）
PPAPだけじゃない？セキュリティリスクにつながりかねない商習慣3選
（2024年11月20日）
病院でランサムウェア被害が起きたらどうする？ボードゲームでシミュレーション
（2024年11月19日）
