個別設計型セキュリティ検証
Bespoke Security Validation
守るべき条件が実際に守られているかを、確認する問いと方法から設計して検証します。
業務ルールと認証・権限、システム間の信頼と分離、データ保護、対象技術の特性を踏まえ、何をどの条件と方法で確認するかを設計します。結果は、保護条件が守られる場合と崩れる場合、その根拠と改善の方向としてまとめます。
この保護条件は、実際に守られているか？ 検討済み
守られる条件と根拠、改善の方向を整理します。
このような状況に適しています
- 必ず守るべき条件があるとき
「決済金額は変更されてはならない」「ほかのお客様の情報は見られてはならない」といった、必ず守るべき条件が実際に守られているかを確認したい場合です。
- 新しい環境や技術を導入するとき
AI・LLMサービスや新しい構成のように、従来の診断項目だけでは判断が難しく、検証方法から設計する必要がある場合です。
- リリースや大きな変更を控えているとき
業務の流れと権限の設計が意図どおりに機能するかを、公開前に確認したい場合です。
何を観点に設計するか
保護目標に合った問いを選びます。すべての検証にすべての観点が必要なわけではありません。
- 業務ルール
価格・数量・処理の順序・承認のように、業務の流れが設計したルールどおりにだけ機能するか
- 認証・権限
権限や認証の手続きを外れて、情報や機能にアクセスできるか
- 信頼・分離
システム・テナント・ネットワーク間の信頼関係と分離が、実際に保たれているか
- データ保護
重要な情報が、処理・保存・伝達の過程で権限なく露出したり持ち出されたりしないか
- 技術の特性
モバイルアプリ、AI・LLMサービス、組み込み機器のように、対象の技術に合わせた検証方法が別に必要か
進め方
必要に応じて、シナリオベースのペネトレーションテスト（Scenario-Based Penetration Testing）として進めます。
確認する問いを決める
守るべき条件と、それが崩れたときの影響を併せて整理します。
条件と方法の設計
対象の技術と業務の流れに合った検証方法を決め、必要なアカウントと環境、提供いただく情報の範囲を決めます。
安全条件の合意
許可する行為と禁止する行為、中止の条件、検証環境を開始前に合意します。
検証
設計した方法で確認し、必要に応じてシナリオに沿って条件が崩れるかを再現します。
結果の説明
条件が守られる場合と崩れる場合、その根拠と影響、改善の方向を説明します。
お客様に残る成果
守られる場合と崩れる場合
それぞれが生じる条件を区別して説明します。
根拠
確認した内容を再現できる手順と証跡を残します。
改善の方向と未確認の範囲
改善の方向と、今回の設計で確認しなかった部分を示します。
認証審査や法的判断を代替するものではありません。対処後の再確認は別途決めます。