個別設計型セキュリティ検証

Bespoke Security Validation

事業と利用者の視点で懸念される被害から出発し、その被害につながる経路を集中的に検証します。

ビジネスロジックの悪用、容易に解析・改ざんされるアプリ、漏れうる個人情報、実際には分離されていないネットワークのように、懸念される脅威を選び、関連するシステムと運用の過程をたどって、実際の可能性と影響を確かめます。分野ごとに検証項目とシナリオを設計し、結果はシナリオごとに何が突破され何が防がれたか、その根拠としてまとめます。

懸念している被害は、実際に起こりうるのか？

シナリオごとの成立条件と影響、改善の方向をまとめます。

確認済み

懸念される被害一つから出発し、その被害につながりうるシナリオごとに防がれるか突破されるかを確かめます。下の検証結果の例と同じ状況です。

こんな状況に適しています

事業に関わる被害が心配なとき
「クーポンやポイントが不正に使われないか」「自社のアプリが複製・改ざんされないか」のような、事業と利用者の視点の懸念が実際に起こりうるかを確かめたい場合です。
個人情報や重要資料を多く扱うとき
顧客情報や中核となる技術資料がどこに残り、どこから漏れうるかを確かめたい場合です。
新しい環境や技術を導入するとき
AIエージェント・LLMサービスや新しい構成を導入するにあたり、「人の承認なしに外部へ送らない」のように自社で定めた線が実際に守られているかを確かめたい場合です。点検基準がまだない技術なら、検証方法から設計します。

特化型検証の分野

分野ごとに事業・利用者の視点の懸念から出発し、個別に設計した検証項目を使います。複数の分野を組み合わせることができ、ここにない懸念も一緒に設計します。

ABUSE

ビジネスロジック悪用の検証

クーポン・ポイント・返金・予約のような業務ルールを、正規の手順の外で利用して利益を得られないか？

主な検証範囲: 価格・数量・割引の計算
決済・キャンセル・返金の流れ
クーポン・ポイント・特典の重複利用
処理の順序と承認手順の飛ばし
マクロ・ボットなどの自動化された大量リクエストへの備え
他のユーザー権限の機能の利用
適している組織: コマース、予約・チケット、金融・ポイント、ゲーム、サブスクリプションサービス
守るべき条件の例: 「決済が完了した後は、金額が変わってはならない」

CLIENT

アプリ・クライアントのロジック保護構造の検証

自社のアプリを解析されたとき、中核のロジックとセキュリティ機能はどれほど容易に見え、改ざん・回避されうるか？

主な検証範囲: アプリ・クライアントのコードの解析難易度
難読化とコード保護の水準
完全性の検証と改ざん検知
ルート化・脱獄・デバッグ環境への対応
API呼び出しと内部通信の構造が解析できないか
アプリに含まれる鍵・設定・重要なロジック
決済・認証・ライセンスのロジックの保護水準
適している組織: ゲーム、金融アプリ、モバイルサービス、IoT・スマート機器、有料サービス
守るべき条件の例: 「改ざんされたアプリでは、決済・認証の機能を使えてはならない」

DATA

個人情報・機微情報の露出可能性の検証

個人情報と重要な情報はどこに残り、どこから漏れうるか？

主な検証範囲: 個人情報・機微情報の収集範囲
アプリ・サーバー・クラウドでの保存状態
APIとネットワークを通じた送信
ログ・エラーメッセージ・デバッグ情報
キャッシュ・一時ファイル・バックアップ
URL・ブラウザ・アプリ内部のデータ
権限のないユーザーがアクセスできないか
共有リンク・ストレージの公開設定
退職者・休眠アカウントに残る権限
保存期間・廃棄後に残るデータ
小さな情報が組み合わさって機微情報になる場合
適している組織: 個人情報・決済・医療データを扱う組織、大量の顧客データを持つ組織、個人情報保護の規制対象
守るべき条件の例: 「個人情報は、仮名化せずに分析環境へ渡ってはならない」

法的な適合性の判断ではなく、技術的な露出と悪用の可能性を確かめます。

EXFIL

ネットワーク分離・情報持ち出し統制の検証

分離したはずのネットワークと資料が実際に隔離されているか、重要な資料が外へ出ていく道はないか？

主な検証範囲: ネットワーク分離・セグメンテーションが設計どおりに保たれているか
開発・本番・外部ネットワーク間の境界統制
重要な文書・データの大量収集の可能性
外部へ出ていく経路と、統制が及ぶ範囲
VDI・リモートワーク・ファイル転送の区間の統制
DLP・ファイアウォールなど持ち出し統制の実効性
適している組織: ネットワーク分離を運用する組織（金融・公共・防衛）、中核技術・設計資料を持つ組織、内部者による漏えいの懸念
守るべき条件の例: 「設計資料は、業務ネットワークの外へ持ち出せてはならない」

ISOLATION

テナント・システム分離の検証

複数の顧客企業が共同で使うサービスで、ある顧客企業のデータや機能が他社へ渡ってしまわないか？

主な検証範囲: 顧客企業間のデータ・ファイル・検索の分離
管理者・サポート機能のアクセス範囲
システム・サービス間の信頼関係
共有インフラの分離
連携サービスに渡す権限
適している組織: 法人向けSaaS、プラットフォーム、複数のグループ会社が共同で使うシステム
守るべき条件の例: 「ある顧客企業のデータは、他の顧客企業から見えてはならない」

AI・新技術の保護条件の検証

AIエージェントや新しく導入した構成が、自社で定めた線を実際に越えないか？

主な検証範囲: エージェントのツール権限と承認の境界
外部からの入力が動作と回答に与える影響
モデルを通じたデータの持ち出し
出力が他のシステムへ渡るときの処理
操作の記録と追跡
組み込み機器や新しい通信方式のように基準がない技術の保護条件
適している組織: AIエージェント・LLMサービスの導入、新しい構成・技術のリリース
守るべき条件の例: 「AIエージェントは、人の承認なしに外部へ情報を送ってはならない」

個別設計型の検証ならではの強み

BUSINESS

事業の視点から出発します

技術の一覧ではなく、金銭的損失、情報漏えい、サービスの悪用のように事業に関わる被害から出発します。

ATTACKER

攻撃者が解析するように見ます

アプリとサービスを攻撃者が解析するように調べ、中核のロジックとデータがどれほど容易に見えてしまうかを確かめます。

AREA

分野ごとに検証項目があります

ロジック悪用、アプリ保護、個人情報、ネットワーク分離、AIのように、分野ごとに設計した検証項目を使い、懸念に合わせて組み合わせます。

PROOF

結果を被害の単位で残します

シナリオごとに、突破されたか防がれたか、どんな条件でか、事業にとってどんな意味があるかを、根拠とともに残します。

進め方

必要に応じて、シナリオベースのペネトレーションテスト（Scenario-Based Penetration Testing）として進めます。

確認する問いを決める
懸念される被害を決め、それを防ぐために守るべき条件と、崩れたときの影響をあわせて整理します。
条件と方法の設計
対象の技術と業務の流れに合った検証方法を決め、必要なアカウントと環境、提供いただく情報の範囲を決めます。
安全条件の合意
許可する行為と禁止する行為、中止の条件、検証環境を開始前に合意します。
検証
設計した方法で確認し、必要に応じてシナリオに沿って実際に突破されるかを確かめます。
結果の説明
シナリオごとに防がれたか突破されたかと、その根拠、事業への影響、改善の方向をご説明します。

お客様に残る結果

シナリオ別の結果

シナリオごとに、防がれたか突破されたかと、そうなる条件をまとめます。

事業への影響

それぞれの結果が、金銭・情報・サービスの面でどんな意味を持つかを説明します。

根拠

確認した内容を再現できる手順と証跡を残します。

改善の方向と未確認の範囲

改善の方向と、今回の設計で確認しなかった部分を示します。

検証結果の例説明のために作成した例で、実際のお客様の事例ではありません。

保護目標

クーポンとポイントは、定められた条件のもとで一度だけ使えること

分野：ビジネスロジック悪用・対象：コマースアプリと注文・決済API

シナリオ	結果	根拠
通常の注文・決済	防がれた	割引額をサーバー側で計算し直しています。
決済のキャンセルと再利用が重なるとき	突破された	同じクーポンをもう一度適用できてしまいます。
アプリが送る価格の値	防がれた	アプリが送った価格は使わず、サーバーの値で決済しています。
紹介ポイント	補完が必要	アカウントを新規作成するたびにポイントが貯まり、付与の上限や大量登録を除く基準がありません。

事業への影響: 割引が重複して適用され、ポイント目当てのアカウントに販促予算が使われるおそれがあります。
改善の方向: クーポンの利用と復元を一度に処理し、紹介ポイントには本人確認・付与の上限と大量登録の確認基準を設けます。

認証審査や法的判断を代替するものではありません。対処後の再確認は別途決めます。