脆弱性診断・ペネトレーションテスト（VAPT）
Vulnerability Assessment & Penetration Testing
システムとサービスの脆弱性を探し、そのうち実際に悪用されうるものと、業務への影響を確かめます。
脆弱性診断とペネトレーションテストを合わせて行うのが基本で、定期診断のように診断だけを、重要なサービスにはペネトレーションテストだけをご依頼いただくこともできます。
このシステムの脆弱性は、実際に悪用されうるのか？
危険なものから直せるよう、発見事項ごとに実際の影響と再確認できる証跡、改善の方向を残します。
専門家確認済み
このような状況に適しています
- 診断する対象が明確なとき
外部業者が作ったシステムを引き継いだときや、サーバーをクラウドへ移したあとのように、診断する対象が決まっていて、その脆弱性と実際の影響を知りたいときです。
- リリースや大きな変更の前後に確認したいとき
まもなく新しいサービスを公開するものの、このまま出してよいか不安なら、公開前に一度、大きな変更のあとにもう一度確かめます。
- 外部から独立した診断結果を求められたとき
大口顧客との契約、取引先のセキュリティチェックリスト、入札、認証審査の準備などで、外部のペネトレーションテスト報告書を提出する必要がある場合です。
- 対策したことの根拠が必要なとき
監査で指摘された脆弱性や、事故のあとに補強した部分が本当に直っているかを、最初と同じ方法で改めて確かめ、根拠として残します。
SAFE SQUAREのアプローチ
広く調べ、人が確かめます
診断基準とツール、AIエージェントで対象全体を広く調べ、出てきた結果は専門家が一つずつ直接確かめて誤検知を取り除きます。
業務の流れまで理解します
注文・決済・権限といった業務の流れを先に理解してから弱点をつなぎ、複数の弱点が重なって初めて開く経路までたどります。
直ったかを再確認できるように
発見事項ごとに確認した条件と証跡を残し、開発・運用の担当者が自ら確かめられ、対処後も同じ方法で見直せるようにします。
診断とペネトレーションテストの違い
二つは目的と深さが異なります。
| 項目 | 脆弱性診断（VA） | ペネトレーションテスト（PT） |
|---|---|---|
| 確認すること | 対象全体から、既知の種類の脆弱性と設定の問題を幅広く見つけます。 | 見つかった弱点を攻撃者のようにつなげ、実際にどこまで侵入できるかを確かめます。 |
| 方法 | 決められた診断項目を対象全体に当てはめます。 | 弱点をつなぎながら、統制された条件で直接検証します。 |
| 得られる結果 | 脆弱性の一覧と危険度、対処方法 | 攻撃経路と実際の業務への影響、再現可能な証跡 |
| こんなとき | 定期的な診断、リリース前の基本確認、広い範囲を一度に調べたいとき | 重要なサービス、外部に独立した検証結果を示す必要があるとき、診断結果の実際のリスクを確かめたいとき |
このようなところを診断します
対象ごとに、設定や構成から機器・ソフトウェアそのものまで、関連する領域をあわせて診断します。以下の領域は例で、ここにない対象もご相談の中で一緒に決めます。
Web・API・モバイル
- 対象
- お客様が使うWebサービスとモバイルアプリ、その背後のAPIと管理画面、連携する外部サービスまでを一つのサービスとして見ます。
- 診断できる領域
- ログイン・セッション・アカウント管理
- ユーザーごとの権限とデータアクセス
- 入力の処理とサーバー側の脆弱性
- 注文・決済など基本的な業務フローのアクセス制御
- モバイルアプリの保存・通信・コード保護
- 管理画面と内部API
- ファイルの処理と外部連携
- サーバー・フレームワークの設定
認証・権限（AD・LDAP・SSO）
- 対象
- 社内のアカウントと権限を管理するディレクトリ（AD・LDAP）、一度のログインで複数のシステムに入れるSSOと認証サーバー、権限がやり取りされるシステム全般です。
- 診断できる領域
- AD・LDAPの構成とポリシー
- SSO・フェデレーション（組織間の認証連携）の設定
- 権限昇格の経路
- サービスアカウントと委任の設定
- 認証サーバーと多要素認証
- 入社・異動・退職に伴うアカウント管理
- 決済・承認の流れの権限構造
サーバー・ネットワーク・クラウド
- 対象
- オンプレミスのサーバーとネットワーク、AWS・GCP・Azureなどのクラウド、コンテナ・Kubernetesの運用環境です。
- 診断できる領域
- 外部に公開されたサービスと管理画面
- サーバー・OS・ミドルウェアの脆弱性
- ネットワークの構成と分離
- クラウドのアカウント・権限管理（IAM）と設定
- ストレージ・鍵・シークレットの管理
- コンテナ・Kubernetes
- ログ・監視の設定
AIエージェント・LLMサービス・AIインフラはAIシステムのセキュリティ評価・ペネトレーションテストで、制御システムとIoT・組み込み機器・ファームウェアは産業制御・ハードウェアのセキュリティ検証で扱います。
どの情報から始めるか
診断担当者が対象についてどれだけ知って始めるかによって、見えるものとかかる手間が変わります。目的に合わせて一緒に決めます。
ブラックボックス
事前情報なしで、外部の攻撃者と同じ条件から始め、外から見える姿をそのまま確かめます。内側はグレーボックスやホワイトボックスでより深く見られます。
グレーボックス
テストアカウントと基本的な構成情報をもとに、ログイン後の機能まで確かめます。実際の攻撃条件と診断範囲のバランスが取りやすい方法です。
ホワイトボックス
ソースコード、設計、設定情報まで受け取り、内側から確かめます。外からは見えない問題まで見つけられます。
進め方
目標・範囲・条件の合意
対象と目標、診断範囲、開始時にいただく情報のレベルを一緒に決めます。
準備
テスト用アカウントと環境情報を準備し、対象の構造を把握します。
診断・検証
診断で見つかった事項を一つずつ確かめ、ペネトレーションテストで、そのうち実際に悪用できるものと業務への影響を、決めた条件の中で検証します。
結果の報告・説明
セキュリティ状態の要約と発見事項、実際の影響、証跡、改善の方向を、意思決定者と技術担当者にご説明します。
対策後の再確認
ご希望があれば、対処した部分を同じ方法で再び診断し、結果に反映します。
安全に進めるためにサービスに影響しうる試験は事前に決めた場合にのみ行い、テストアカウントと範囲を決めて、実際のユーザーのデータに触れないよう進めます。安全な進め方と中断基準、事実と推定の区別、資料の保管・廃棄といった共通の原則は、仕事の進め方と原則にまとめています。
お客様に残る成果
セキュリティ状態の要約
意思決定者がひと目で把握できるよう、確認した範囲と主なリスク、先に直すべきことを要約します。
発見事項と実際の影響
脆弱性ごとに危険度と実際の悪用の可能性、業務への影響を説明します。
再現可能な証跡
ペネトレーションテストでたどった攻撃経路を含め、各結果を再確認できる手順と条件、根拠を残します。
改善の方向
悪用の可能性と業務への影響に沿って、何からどう直すかを整理します。
ログインした会員が、ほかの会員の注文履歴と配送先を閲覧できる
危険度：高- 対象
- コマースアプリの注文照会API・グレーボックス、一般会員のテストアカウント2つ
- 実際の影響
- 会員の氏名・連絡先・配送先が、ほかの会員に見えてしまうおそれがあります。確認はテストアカウントの間だけで行いました。
- 残した証跡
- 確認した条件（ログイン状態とアカウントの権限）、リクエスト・レスポンスの記録、画面
- 改善の方向
- 注文を照会するときに、リクエストした会員と注文の持ち主が同じかをサーバー側で確かめます。同じ作りのほかの照会APIもあわせて点検します。
- 再確認
- 対処後、同じアカウントと条件で再確認し、結果に「対処確認済み」と記録します。
社外から攻撃者に見える自社の資産や情報を見つけることは、エクスポージャー・インテリジェンスで扱います。決済や特典のような業務ルールのすき間が実際の損失につながるかは、ビジネスロジック・サービス悪用の検証で確かめます。