GENZ, Inc.

SaaS開発・提供向け SaaSの脆弱性診断

契約したプランと権限の範囲どおりにテナント間のデータ分離が効いているかを、利用中の環境で手動の診断も交えて判定します。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

SaaSでよくあるセキュリティ不備

BtoB SaaSでは、複数企業で基盤を共有し、画面とAPIを同時に提供します。セキュリティ不備を曖昧にせず、テナント分離・認可・権限・入出力・認証の5つに分けて確認します。

他社テナントのデータまで参照できてしまう

問合せ条件からテナント識別子が抜けると、A社の利用者がB社の顧客情報を参照できてしまいます。同じ欠落はキャッシュや検索索引にも起きます。

テナント分離

画面では守られていても、API直接呼び出しで突破される

画面遷移を前提に認可を置くと、API側で所有者を確かめる処理が抜けます。要求のIDを差し替えるだけで、他者の情報を取得・更新できてしまいます。

APIの認可制御

権限のない利用者が管理機能にアクセスできる

ロールを外しても発行済みのセッションが生きていると、降格後や退職後の利用者が管理画面のURLへ直接到達し、設定や利用者情報を書き換えられます。

管理機能への到達

入力値の処理不備で、データベースの情報が漏れる

検索条件やレポート出力を問合せ文へ組み込むと、条件式を書き換えるSQLインジェクションで他社データが抜き出されます。XSSも同じ経路に残ります。

入出力の処理

認証・セッション管理の穴で、なりすましを許す

パスワード再設定の本人確認が甘いと、なりすましによるパスワード変更を許してしまいます。ログイン前のセッションIDが認証後も有効なままだと、奪われたセッションがなりすましに利用されます。

認証とセッション
02 RISK

脆弱性が残存することで起きる問題

脆弱性の影響は技術上の不備にとどまりません。顧客データ、導入審査、事後対応へ連鎖し、取引継続や新規案件の獲得を妨げるおそれがあります。

倉庫のバックヤードで担当者が在庫回収や棚卸差異の対応に追われている実写画像。
03 REVIEW

診断時におさえるべきセキュリティ観点

ツールで既知パターンを広く確認するだけでは、SaaSのテナント境界や権限設計に沿う不備を拾いきれません。設計資料と実際の要求を照合し、データ分離・API認可・権限・入出力・認証の5観点で検証します。

他社テナントへの越境を防ぐ

テナント間のアクセス制御と分離設計の検証

テナント設計とデータモデルを読み、テナント識別子がデータベースやキャッシュで維持されるかを確認します。異なるテナントのアカウントを使い、参照・更新・削除で越境しないことまで確かめます。

確認する資料
  • テナント設計
  • データモデル
API直接呼び出しの突破を防ぐ

全APIリクエストに対する認可チェックの検証

API仕様とパラメータ定義から、要求ごとの操作主体と対象データを整理します。URL・本文・ヘッダー内のIDを別テナントの値へ替え、参照・更新・削除・検索の各APIが拒否するかを検証します。

確認する資料
  • API仕様
  • パラメータ定義
管理機能への不正な到達を防ぐ

権限設計と管理機能へのアクセス制御の検証

権限一覧と画面遷移図を照合し、ロールごとに到達できる画面と機能を確定します。URLの直接指定を試し、権限のない状態や権限を外した後に、管理機能を利用できないことまで見ます。

確認する資料
  • 権限一覧
  • 画面遷移図
命令の注入による情報漏れを防ぐ

SQLインジェクション・XSSなど入出力処理の検証

入力値の経路は検索欄や登録フォームに限りません。テナントを跨ぐ検索条件やレポート出力まで画面一覧と入力仕様から拾い、画面・CSV・ログと出力先ごとに命令として解釈されないかを検証します。

確認する資料
  • 画面一覧
  • 入力仕様
セッション奪取のなりすましを防ぐ

認証方式とトークン・セッション管理の検証

認証フロー仕様を読み、ログイン、パスワード再設定、多要素認証の適用条件を整理します。トークンやセッションIDの発行・更新・破棄を追い、有効期限切れやログアウト後に再利用できないかを確認します。

確認する資料
  • 認証フロー仕様
04 TEST DESIGN

診断の進め方・具体的な診断内容

診断観点を予算と期限に収めるため、対象の棚卸しから報告・再診断までの4段階で実行計画を組みます。

STEP 01 対象を棚卸しし、今必要な診断範囲に絞り込む対象を棚卸しし範囲を絞り込む
どう確かめるか

対象を棚卸しし、今必要な診断範囲に絞り込む

画面、API、管理機能、ネットワークを棚卸しし、セキュリティ要求事項と期限を照合します。扱う情報と利用範囲を踏まえて優先度を決め、今回の診断対象と除外範囲を合意します。

  • 01画面・API・管理機能・ネットワークを一覧にして棚卸しする
  • 02セキュリティ要求事項と回答期限を照らし合わせる
  • 03扱う情報と利用範囲から今回の対象と除外範囲を合意する
OUTPUT診断対象と除外範囲の一覧
STEP 02 ツール診断と手動診断で、網羅と深掘りを両立する既知はツール・認可は手作業で
どう確かめるか

ツール診断と手動診断で、網羅と深掘りを両立する

既知の攻撃パターンはツールで広く検査します。他テナントのIDを指す要求も形は正当なため、ツールは異常と判定しきれません。仕様を踏まえた手動診断で認可を確かめ、結果を根拠とともに残します。

  • 01既知の攻撃パターンはツールの検査で広く網をかける
  • 02他テナントのIDを指す要求を手作業で送り、認可処理が適切かを確かめる
  • 03仕様を踏まえて判定した結果に根拠となる証跡を添えて残す
OUTPUTツール診断と手動診断の記録
STEP 03 検出した脆弱性を、リスクと優先度で整理する到達性と影響から優先度を決める
どう確かめるか

検出した脆弱性を、リスクと優先度で整理する

検出結果を手動で確かめ、到達可能性と影響範囲、テナント・権限の境界を確認します。深刻度が高い項目から悪用のしやすさも踏まえて優先的に対応し、一定の期間受容すると判断した項目は理由と見直し時期を記録します。

  • 01検出結果を手作業で確かめて到達可能性と影響範囲を見定める
  • 02深刻度が高い項目から悪用のしやすさを踏まえて優先度を分ける
  • 03一定の期間受容する項目は理由と見直しの時期まで記録する
OUTPUT優先度つきの是正計画
STEP 04 診断報告書の共有から是正・再診断まで伴走する確かめた範囲と未確認を書き分け
どう確かめるか

診断報告書の共有から是正・再診断まで伴走する

報告書には、確認範囲、脆弱性の内容、影響、確認手順、是正優先度を記載します。セキュリティチェックシートへの回答材料を共有し、是正後の再診断は、範囲と条件を取り決めたうえで対応します。

  • 01確認した範囲と脆弱性の内容・影響・確認手順を書きまとめる
  • 02セキュリティチェックシートへの回答材料を共有する
  • 03是正後に再診断する範囲と条件を取り決める
OUTPUT確認範囲と検出結果の記録
05 RATIONALE

私たちGENZが、このようなBtoB SaaSのセキュリティ診断を代行します

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

オフィスで担当者同士がノートPCを前に、在庫管理システムのテスト観点を相談しながら整理している風景。第三者視点のテスト支援を想起させる実写写真。

専門知識を持ったセキュリティエンジニアが、第三者の視点で診断するメリット

  • 開発側の思い込みや先入観に影響されず、設定や実装の不備を検出できる
  • 診断観点にもとづく網羅的な検査で、見逃しを減らせる
  • 開発チームが診断の工数から解放され、開発に専念できる
06 SERVICE

5,000件以上の実績に裏付けられた伴走型支援

GENZは、フルメニューを一律に勧めず、取引要件・予算・期限に合わせて診断範囲と優先順位を合意します。報告書、是正後の再診断、関連するソフトウェアテストまで、同じ窓口で伴走します。

SVC 01

今必要な範囲に絞る段階的提案

取引先の要件、予算、時期を伺い、画面・API・権限のうち優先する範囲を整理します。必要な範囲だけご依頼いただき、次の段階へ広げられます。

在庫のリスク要因を並べ、優先順位を高低で示した赤白紙カード基調の無文字図解。
SVC 02

確認手順と是正優先度を示す診断報告書

検出箇所、確認手順、影響範囲、是正優先度を報告書にまとめます。セキュリティチェックシートや商談の説明材料としてご活用いただけます。

仕様変更に応じてリグレッションテストの対象範囲が更新される様子を示した赤白紙カード基調の無文字図解。
SVC 03

是正後の再診断まで対応

指摘箇所を是正いただいたあと、取り決めた範囲と条件で再診断します。APIからWebアプリ、ネイティブアプリまで同じ窓口で対応します。

第三者の視点で計画・設計・実施・報告が一貫してつながる流れを示した赤白紙カード基調の無文字図解。
SVC 04

ソフトウェアテストと同じ窓口で頼める

脆弱性診断に加え、機能テストや第三者検証、負荷テストも同じ窓口でご相談いただけます。発注先を分けず、要件整理と進捗共有を一本化します。

機能テストと関連テスト(性能・セキュリティ等)を並べて区分した赤白紙カード基調の無文字図解。
07 FLOW

ご相談から納品までの流れ

対象範囲と判断基準を先に合わせ、進捗と残るリスクを共有しながら進めます。

ヒアリングで対象範囲を具体化する

対象システム、拠点、扱うデータ、連携先、業務フロー、リリース時期を確認し、未検証領域を可視化します。

診断計画と優先順位を合意形成

事故影響、変更量、利用頻度、代替手段の有無から優先順位を定め、必要な工数と計画を具体化します。

診断実施と進捗・課題を毎回共有

実施状況、発見事項、阻害要因、追加確認が必要な仕様を共有し、終盤のまとめ出しを避けます。

報告書納品と再診断支援まで実施

診断完了レポートに結果、証跡、未実施範囲、残留リスクを整理し、修正後の再診断条件まで引き継ぎます。

5,000件以上の対応実績

SaaSの診断範囲・優先順位を、GENZに相談する

相談時には、診断する画面・API・権限の範囲、着手の優先順位、必要工数の考え方、機能テスト・負荷テストなど関連テストの要否を、取引要件とご予算に合わせて一緒に整理します。