SaaS台帳管理とは？利用中SaaS・委託先・データ転送経路を可視化する実務

SaaS台帳管理が必要な理由

SaaS台帳は購入リストでも契約台帳でもありません

SaaS台帳が必要になる場面では、すでに購買部門や法務部門が契約一覧を持っていることが少なくありません。しかし、契約一覧だけでは今も現場で使われているか、どの部門が管理責任を持つか、どのデータがどこへ流れているかが分からないことがよくあります。無料プランの試用、部門単位の導入、外部委託先が裏側で使っているサービス、連携だけ残っている古いサービスは、契約台帳から抜けやすいからです。

そのため SaaS台帳は、購買や契約の記録を再利用しつつも、主役を利用中サービスの現状確認へ置き換える必要があります。どのサービスが、どの業務で、誰の責任で、どのデータを扱い、どこへつながっているかまで追えないと、事故や障害のときに調査範囲と判断責任が曖昧になります。

主役は「利用中SaaS」「管理責任者」「データ転送経路」です

SaaS台帳管理を実務に落とすうえで重要なのは、SaaS を「契約済みの箱」として見るのではなく、今も使われている業務の一部として扱うことです。社内の誰が管理責任者か、どの業務が依存しているか、個人情報や営業情報、ログやファイルがどこへ保管・転送されるか、SSO や API で何とつながっているかまで見えるようにすると、初めて棚卸しの価値が出ます。

ここで似た記事との役割を分けておきます。SaaSベンダーリスクの記事は、契約、監査、通知、継続評価を主役にした管理記事です。一方で本記事は、利用中SaaSをどう台帳へ戻し、どこまで可視化するかを主役にします。また外部公開資産台帳の記事は外から見える資産の棚卸しが主役であり、こちらは業務利用中のSaaSと委託先、データ転送経路へ絞ります。

SaaS台帳に最低限入れる項目

とくに抜けやすいのは、保持データと転送先、そして外部接点です。たとえば「SaaS そのものは把握しているが、どの API 連携が残っているか分からない」「サポート窓口や公開ドキュメント用ホストが今も生きているかは別管理」という状態は珍しくありません。ここが曖昧だと、事故時に何を止めるべきか、誰へ確認すべきかが決まりません。

逆に、全部を最初から細かく書こうとすると台帳は続きにくくなります。まずは「利用中サービス」「管理責任者」「用途」「保持データ」「主な連携先」「外部接点」「更新日」をそろえ、そこから契約や監査の詳細を別トラックで深める方が現実的です。

データ転送経路はどこまで可視化するか

データ転送経路の可視化というと、すべてのデータパケットやネットワークの詳細図まで描かないといけないと思われがちです。しかし、SaaS台帳の段階で必要なのは、通信解析の完全再現ではなく、どのサービスがどのデータを受け取り、どこへ渡し、どの連携が業務停止に直結するかを判断できる粒度です。まずは重要業務と重要データに絞って、関係するSaaS、委託先、連携先、外部接点を段階的に可視化する方が運用へ乗ります。

内部利用と外部接点を別管理にしない方が事故時に強くなります

事故や障害のときに困るのは、社内で使っているSaaS一覧と、外から見える接点の一覧が別管理になっている状態です。SaaS の管理画面は閉じていても、公開ドキュメント、コールバック用URL、障害告知ページ、サポート窓口、古いホスト名が残っていると、そこから現場や顧客への案内や調査が始まります。逆に外から見える接点を見つけても、それがどの業務のどのSaaSと結び付くかを説明できないと、調査の優先順位が付きません。

そのため SaaS台帳では、外部接点を別ファイルへ切り離し過ぎず、少なくとも「どのSaaSにひも付く接点か」「どの部門と管理責任者が担当か」が追えるようにしておく方が安全です。この点で公開資産台帳とシャドーAPIの棚卸しは、SaaS台帳とつながる補助線になります。

SaaS台帳と公開資産台帳は役割が違います

ここは混同しやすい点です。公開資産台帳は、外から見えるホスト、URL、証明書、DNS、公開面の管理が主役です。一方、SaaS台帳は、業務で利用中のサービス、委託先、管理責任者、保持データ、転送経路、連携先が主役です。つまり見る対象が違うのですが、API、サポート導線、ドキュメント用ホスト、通知用URLのような接点では互いに重なります。

本記事では、SaaS台帳を「内側の利用実態」と「外から見える接点」をつなぐ運用台帳として扱います。外部公開面の詳細な棚卸し手順は外部公開資産台帳の記事に譲り、こちらではそれを利用中SaaSの責任とデータ経路へどう戻すかを重視します。

NISTとCISAから見る見直しサイクル

NIST SP 800-161 Rev.1 は、一覧化して終わりではなく継続評価を前提にしています

NIST SP 800-161 Rev.1↗は、サプライチェーンリスクを継続的に特定し、評価し、低減していく考え方を示しています。SaaS台帳へ引き直すと、これは「導入時の質問票で終わらせず、利用中サービス、依存業務、保持データ、連携先、管理責任者を継続的に更新する」という意味に近づきます。つまり、一覧化の価値は台帳を作る瞬間ではなく、変更が起きた時に戻れることにあります。

また、NIST の指針更新紹介↗でも、委託先がもたらすサイバーリスクを継続的に把握し、対応する考え方が前に出ています。SaaS台帳はその入口として、どの委託先とサービスが現場へ影響するかを最初に説明できる形にしておくべきです。

CISA は実行手順として始めることを重視しています

CISA's Supply Chain Risk Management Essentials↗は、責任者と実務担当者が組織のサプライチェーンリスク管理を始めるための実行手順を示しています。ここから読み取れるのは、完璧な情報が集まるまで待つのではなく、まず利用中サービスと依存関係を見える化し、見直しの単位を決めることが重要だという点です。

さらにCISA の ICT Supply Chain Risk Management↗は、情報通信技術の supply chain を広く見ています。SaaS だけを単独で見るのではなく、委託先、連携先、管理者権限、外部接点までまとめて考える方が、現実の運用に近い整理になります。

変更時レビューの起点を決めると台帳が古くなりにくくなります

実務で効くのは、年1回の棚卸しよりも「どのイベントで台帳へ戻るか」を決めることです。たとえば、新規導入、SSO 追加、API 連携追加、保持データの変更、委託先変更、事故、契約終了、無料枠から本契約への移行などは、台帳更新の自然なトリガーです。こうしたイベントを決めておくと、現場の変化が台帳へ戻りやすくなります。

SaaS台帳は監査資料だけではなく、障害時の案内、セキュリティレビュー、委託先見直し、レポート作成にもつながります。セキュリティ報告書の雛形やSaaSベンダーリスクの管理記事と接続しておくと、一覧化した情報を判断材料へ戻しやすくなります。

SaaSや委託先の外部接点を整理するならASM診断 PRO

ASM診断 PRO は、SaaS台帳や委託先台帳そのものを置き換える製品ではありません。ただし、年次見直しや事後レビューのときに、外から見える公開ドキュメント、コールバック用URL、サポート窓口、放置されたホスト名、API 接点を洗う入口としては使いやすい構成です。契約や監査の代替ではなく、台帳に戻すべき外部接点の現状確認を補助する位置づけです。

とくに「契約上は把握しているが、今もどこが公開されているか分からない」「委託先や利用中SaaSにひも付く公開面を外から洗いたい」という場面では、利用中SaaSの台帳と外部観点の棚卸しをつなぐ導線があると会話しやすくなります。SaaS台帳を運用資料として生かすには、内側の管理情報だけでなく、外から見える接点の現状確認も合わせた方が現実的です。

よくある質問（FAQ）

契約台帳があれば SaaS台帳は不要ですか

不要ではありません。契約台帳は調達や法務の管理に有効ですが、今も使われているか、どの部門が管理責任者か、どのデータがどこへ流れているかまでは抜けやすいです。SaaS台帳は利用実態と依存関係を補うために必要です。

無料プランや部門導入のサービスも載せるべきですか

はい。正式契約の有無より、現場で利用中かどうかが重要です。無料プランや試験導入でも、ファイル共有、フォーム受付、通知、自動連携に使われていれば、障害や情報流出の影響は現実に発生します。

データ転送経路はどこまで細かく書けばよいですか

最初から通信レベルで完全再現する必要はありません。まずは、どのSaaSがどのデータを保持し、どの委託先や連携先へ渡し、どの外部接点が残っているかを説明できる粒度で十分です。重要業務と重要データから優先的に深める方が実務に合います。

公開資産台帳と SaaS台帳は同じファイルにすべきですか

同じである必要はありませんが、少なくとも相互にたどれるようにした方が安全です。公開ドキュメント、API 接点、コールバック用URL、サポート窓口のような重なり部分では、別管理だと事故時の調査が遅れやすくなります。

SaaS台帳の更新は誰が持つべきですか

セキュリティ部門だけに寄せず、管理責任者を持つ利用部門と中央管理側が分担するのが現実的です。利用部門が用途と依存関係を更新し、中央側が変更イベントや年次見直しで抜け漏れを点検する形が続きやすいです。

まとめ

SaaS台帳管理の主役は、契約済みサービスの列挙ではありません。今も利用中のSaaS、委託先、管理責任者、重要業務、保持データ、連携先、外部接点を同じ判断資料へ戻せることが重要です。ここが見えていれば、障害、事故、契約更新、委託先見直しのどれが来ても、誰が何を確認すべきかを早く決められます。

また、公開資産台帳と SaaS台帳は役割が違いますが、API、サポート導線、公開ドキュメント、コールバック用URLのような接点ではつなげて持つ方が実務で強くなります。まずは利用中サービスと管理責任者をそろえ、次に保持データ、転送経路、外部接点、変更イベントを足してください。そうすると台帳が単なる一覧ではなく、運用と判断の基盤へ変わります。