複雑化する「セキュリティチェックシート」の問題 情シス目線で現状とリスクを整理：セキュリティ有識者が徹底解説

2022年6月16日、サイボウズの青野代表が「セキュリティチェックシートが抱える問題点」についてツイートしたところ、とても大きな反響がありました。本連載（全5回）では、セキュリティチェックシートの問題点を洗いだしながら、「クラウドサービスを利用するためのリスク評価とコントロール」について解説します。

[井上 幸，Conoris Technologies]

　とある先進的な大企業のエグゼクティブとお話した際、「さまざまなリスクがあるにもかかわらず、なぜクラウドサービスの利用をポジティブに認めているのですか」と質問したところ、「優秀な人が入社して、定着して活躍してもらうために必要だから」という回答をもらい面食らいました。

　クラウドシフトが生産性や売上を上げるだけでなく、従業員の定着や活躍につながるという考えはそれまでの私にはない視点でした。日本企業が労働生産性を上げ国際競争力を高めるためには、クラウドの活用は不可欠であると思わざるを得ませんでした。

　一方、サイバーセキュリティ攻撃によるクラウドサービスのインシデントが年々増加して、大企業ほどクラウド活用に慎重な姿勢がみられます。SaaS（Software as a Service）を中心としたクラウドサービスを従業員にどのように安全に利用してもらうかというのは、情報システム部門にとって非常に悩ましいテーマとなりました。

　このような背景を踏まえ、本連載では次世代の情報システム部門に求められる「クラウドサービスを利用するためのリスク評価とコントロール」について、全5回にわたって解説します。

著者プロフィール：井上 幸（Conoris Technologies　代表取締役）

新卒でワークスアプリケーションズに入社し、ERPの営業や統合ID管理システムの導入・保守に携わる。その後、リクルートにて法人営業・コンサルタントを経て、新規事業開発へ異動。HR系SaaSの企画・営業担当として、サービスの成長に寄与した。パーソルグループのCVCにてベンチャーキャピタリストとして従事した後、Conoris Technologies（旧ミツカル）を2020年6月に創業しベンダーリスクマネジメントSaaS「Conoris」を提供している。

ツイートが大反響を呼んだ「セキュリティチェックシート問題」

　2022年6月16日、サイボウズの青野代表が「セキュリティチェックシートが抱える問題点」についてTwitterでツイートしたところ、600を超えるリツイートと2700以上のいいねが集まり、大きな反響を呼びました。

　セキュリティチェックシートとは、ユーザー企業がクラウドサービスを導入する際に、自社の求めるセキュリティ要件や可用性を満たしているかどうかを事前に確認する目的で、事業者に記入を求めるものです。

　ユーザー企業の導入部門とクラウドサービス事業者が回答する総設問数は50〜150にもなることが多く、一部の業界や企業では300を超える場合もあります。設問数が少ない場合は、基本的にExcelやスプレッドシートへの記入をメールで依頼し、下図のように導入企業のユーザー部門、情報システム部門、そしてベンダーの3者間でやりとりします。

セキュリティチェックシートの3社間のやりとり（出典：ミツカル）

　本業務で大変なのは、「社外の人も含めたやりとりが多いワークフローによる管理の煩雑さ」と「フォーマットの異なるセキュリティチェックシートを記入依頼すること」によって、三者三様の課題が発生することです。本記事ではまず、セキュリティシートの提出をする「情報システム部門のセキュリティ担当の課題」から解説します。

情報システム部門が抱える3つの問題

　現場の判断でクラウドサービスを導入できる企業の場合、利用の許可をとるためセキュリティチェックシートを用意します。DX推進や新しいサービスの活用に意欲的な企業であれば、情報システム部門が確認しなければならないセキュリティチェックシートの数は年間数百件にもなります。

　そもそもセキュリティ担当者が人手不足の企業が多い中、情報システム部門のセキュリティ担当はマルウェアやランサムウェアなどの対応に追われながら、セキュリティチェックシートに対応する場合は珍しくありません。工数不足はもちろん、それ以外にもさまざまな問題が発生します。

1.人とスキルの問題

　セキュリティチェックシートの確認は、一定のITとセキュリティの知識がないと対応できないため、対応者が固定化、属人化しやすいという問題があります。また、チェックマニュアルを整備できている企業は少なく、チェック基準のズレや過去の承認情報との不整合が起きています。少ない人数で対応すると時間がかかり、現場のサービス導入が遅れるといった問題もあります。

2.チェックシートの設問票の問題

　日本のセキュリティチェックシートは、プライバシーマークや個人情報保護法に対応するため「個人情報の委託先チェック」や「ASPチェックシート」の延長で策定されたものが多いという特徴があります。そのため、顧客の個人情報や機密情報を取り扱わないにもかかわらず、余計な設問への回答を求めたり、データセンターでの運用を前提とした設問になっていたりするものが多いという印象です。新興系のクラウドサービス事業者はほとんどがパブリッククラウドでインフラ構築しているため、余計な設問が混乱を生み、やりとり回数を増やしています。

　変化の激しいクラウドサービスやセキュリティの世界において、トレンドや関連法を追いかけながらチェック項目を随時改定する必要があります。しかし、情報システム部門の担当者は業務で忙殺され、セキュリティチェックシートのアップデートに手が回らず余計な設問が残るといった問題が起きているのです。

　「業界で統一のチェック基準を設ければ解決するのではないか」という意見が頻繁に挙げられますが、大手企業になるほど業法や業界ルール、自社独自のポリシーが存在するため、6〜7割までは基準を定型化できますが、一定の独自性は必ず残るとみています。

3.導入後の管理の問題

　1つのセキュリティチェックシートの完成までに関係者にかかる時間は膨大です。全員が苦労しながら対応していますが、一回承認が下りると年次チェックはおろか、最終的な購入有無すらも確認していない企業がほとんどです。

　クラウドサービスは開発が速く、利用規約改定もあるため、導入時に利用可能と判断されたとしても数年後、同じ評価になるとは限りません。また、クラウドサービスのインシデントの多くはユーザー側が原因で発生しています。利用管理責任者や担当者は、格納している情報の種類（個人情報・機密情報など）を少なくとも年に1回は確認することが、インシデントが発生した際の速やかな対応につながります。

業務事例で理解する、セキュリティシートの問題点

　セキュリティシートの問題例を一つ出してみましょう。あなたは大企業の情報システム部門のセキュリティ担当です。ユーザー部門の依頼を受けてクラウドサービスのセキュリティチェックシートを対応しました。無事チェックを通過し、現場に利用許可を出しました。その後数年にわたり、20の部門で同じサービスのセキュリティチェックシートの申請を受け、承認しました。

　その後、導入したサービスでユーザーの設定ミスが起きる仕様が発覚し、実際インシデントが起きていることがニュースになりました。情報システム部長から、社内の当該サービスの利用者を調べ、直ちに警告と是正を連絡するようお達しがきます。

　あなたは業務の合間をぬって過去のセキュリティチェックシートからサービスの申請提出者を洗い出し、警告と是正を依頼するメールを送ります。しかし、既に退職していてメール送信エラーになる人がいたり、異動して管理者ではなくなった旨を伝えるメールが何件もきたりします。結局、全ての部門へアナウンスを完了するのに2週間かかり、各部門のチェックと対応の完了連絡までに約1カ月の時間を要することになりました。

　上記はあくまで極端な例ですが、管理者や利用方法が変わる中、「もともとは個人情報を格納しない前提でサービスの利用を許可したにもかかわらずいつの間にかそのルールが破られている」といったことがあります。また、「アクセスログが取得できないことを懸念していたものの、データのアップロード機能がないことから利用を許可したサービスに、いつの間にかアップロード・ダウンロード機能が追加されて情報漏えいリスクが発生していた」というような事件も、驚くくらい“普通”に起こり得ます。

　業務が継続管理に不向きな方法でされており、チェック者に対応する余力がないのが実情です。個人的には、今の日本のクラウドサービスのリスク評価において継続管理が一番の課題だと考えています。

　仕事柄、多くのセキュリティ担当の方とお話をしていますが、この部分について課題感を感じている方はとても多いです。大手上場企業のIT監査にて、SaaSの定期チェックに関する指摘が増えているというお話を耳にすることも増えています。恐らく数年以内に、導入後の利用状況とリスクの継続的な管理が必須になるのではと予想していますが、管理件数が多い企業では既存手法で管理する限界が比較的早くやってくると考えています。

　自分の会社は記事内で挙げられている点がきちんと対応できているという、年間の申請件数が100以上ある企業の方がいましたら、とても素晴らしいことなので、是非役職者の方からメンバーをたたえてあげてください。数が多ければ多いほど、称賛に値するくらい管理が難しい業務です。

　次回はセキュリティチェックシートの課題（ユーザー編）として、導入部門の視点で課題をご紹介できればと思っています。