レッドチームとは？ペネトレーションテストとの違い・演習内容・導入判断を解説|セキュリティ対策Lab

投稿日時: 2026年09月24日更新日時: 2026年09月24日

レッドチームとは、実際の攻撃者を想定し、組織のセキュリティ対策が実環境でどこまで機能するかを検証する攻撃側のチームです。NISTは、潜在的な攻撃者の能力を模倣し、組織のセキュリティ態勢に対して攻撃や悪用を試みる、認可されたチームとして定義しています。

ペネトレーションテストと似ていますが、目的は同じではありません。ペネトレーションテストが主にシステムへの侵入可能性や脆弱性の影響を確認するのに対し、レッドチーム演習では、攻撃者が目的を達成するまでの一連の行動を想定し、SOCやCSIRTが検知できるか、初動で封じ込められるか、権限管理や社内手続きが攻撃を止められるかまで確認します。

従業員600人以上の企業では、EDR、SIEM、MFAなどを導入済みでも、それらが実際の攻撃時に連携して機能するか確認できていないケースがあります。レッドチーム演習は、こうした「導入済みの対策が実戦で機能するか」を検証する段階で利用します。

レッドチームとは

「レッドチーム」は本来、攻撃側を担当するチームを指します。実際の評価活動は「レッドチーム演習」「Red Teaming」と呼ばれます。

NISTの用語集では、レッドチームを「潜在的な敵対者の攻撃または悪用能力を模倣するために認可・組織された人々のグループ」と定義しています。目的は、攻撃が成功した場合の影響と、防御側であるブルーチームがどのように機能したかを実環境で確認し、組織のサイバーセキュリティを改善することです。

英国NCSCも、SOCの検知能力を検証する方法としてレッドチーム演習を挙げています。NCSCは、レッドチームを「認可された個人またはチームが、非破壊的な攻撃を模擬するもの」と説明し、SOCが演習中の活動を検知できなかった場合、その検知ギャップを改善対象にできるとしています。

イスラエル国家サイバー局（INCD）の「Cyber Defense Methodology for an Organization」でも、ペネトレーションテストとレッドチーム演習をセキュリティ評価の手段として位置付けています。独立したチームによる攻撃シミュレーションを通じて、セキュリティ対策だけでなく監視・対応能力を確認する考え方です。

レッドチームとペネトレーションテストの違い

レッドチーム演習とペネトレーションテストは、どちらも認可された範囲で攻撃者の視点を使います。ただし、評価する対象と終了条件が異なります。

手法	主な目的	主な評価対象	攻撃シナリオ	防御側の検知・対応評価
脆弱性診断	弱点の発見と是正	Web、サーバー、クラウド、設定など	原則として個別の脆弱性単位	通常は主目的ではない
ペネトレーションテスト	侵入可能性や影響の確認	定めたシステム、ネットワーク、アプリ等	対象範囲内で侵入・権限昇格などを検証	実施する場合もあるが主目的とは限らない
レッドチーム演習	実際の攻撃者を想定した防御力の検証	人、プロセス、ID、端末、ネットワーク、クラウド、監視体制	目的達成まで複数経路を組み合わせる	主要な評価対象
パープルチーム演習	検知・防御の改善	SOC、EDR、SIEM、ログ、検知ルール等	攻撃側と防御側が情報共有しながら反復	共同で改善する
机上演習	判断・連携・手順の確認	CSIRT、情シス、法務、広報、経営層等	シナリオを提示して対応を検討	技術検知より意思決定・連携を評価

NIST SP 800-115は、ペネトレーションテストを含む技術的なセキュリティテストについて、計画、実施、結果分析、改善までの考え方を示しています。一方、レッドチームは「特定の脆弱性が存在するか」よりも、「攻撃者が目的を達成する過程を組織が止められるか」という視点が強くなります。

たとえば、外部公開Webアプリケーションの認証不備を確認し、その影響範囲を検証するのであればペネトレーションテストが適しています。これに対して、外部からの侵入、認証情報の悪用、内部での横展開、クラウドへの到達を想定し、その過程でSOCがどこまで検知・封じ込めできるかを確認したい場合は、レッドチーム演習の方が目的に合います。

既存の脆弱性診断とは？目的や種類、実施頻度をUS・UK公的機関の推奨から解説でも、脆弱性診断とペネトレーションテストの役割を整理しています。

レッドチーム・ブルーチーム・パープルチームの違い

レッドチーム演習では、防御側をブルーチームと呼びます。

ブルーチームは、SOC、CSIRT、情報システム部門など、実際にログ監視、アラート調査、端末隔離、アカウント停止、インシデント対応を行う側です。

パープルチームは、レッドチームとブルーチームを完全に分離せず、攻撃手法と検知結果を共有しながら防御を改善する方式です。

英国NCSCは、レッドチーム演習とパープルチーム演習を次のように区別しています。

レッドチーム演習：攻撃側が模擬攻撃を行い、防御側が検知・対応できるかを評価する
パープルチーム演習：攻撃側とSOCが協力し、検知できなかった活動があれば、その場で検知ルールなどを改善する

レッドチームは「現状の能力を測る」用途、パープルチームは「検知能力を改善する」用途に向いています。

レッドチーム演習で何を確認するのか

レッドチーム演習の対象は、脆弱性の数ではありません。実際の攻撃を想定した一連の流れの中で、どこで攻撃を止められるかを確認します。

主な評価項目は次の通りです。

評価領域	確認する内容
外部侵入への防御	外部公開システム、リモートアクセス、認証基盤などから重要資産へ到達できるか
ID・権限管理	一般アカウントから過剰な権限へ到達できないか、特権IDの利用を検知できるか
横展開対策	1台の端末や1つのアカウントが侵害された後、他システムへ被害が広がるか
EDR・SIEM・SOC	攻撃活動をログやアラートとして検知し、調査・隔離につなげられるか
クラウド	オンプレミスだけでなく、Microsoft 365、Entra ID、AWS、Azureなどへの侵害拡大を検知できるか
データ保護	重要データへのアクセスや大量取得、外部送信を制御・検知できるか
インシデント対応	誰が判断し、どの時点で端末隔離、アカウント停止、経営報告などを行うか
人・業務プロセス	必要に応じて、ソーシャルエンジニアリングや承認手続きの弱点も評価する

すべてを一度の演習に含める必要はありません。重要資産と脅威シナリオを決め、今回の演習で何を確認するかを限定します。

CISAの2026年レッドチーム評価で分かった「SOCの差」

2026年8月25日、米国CISAは2組織に対して同時に実施したレッドチーム評価の結果を「A Tale of Two SOCs: Insights From Two Red Team Assessments」として公表しました。

CISAは、レッドチーム評価について、実際の攻撃者の手口を模倣し、組織が悪意ある活動を検知、調査、対応できるか確認するものと説明しています。

評価対象となった2組織では、レッドチームが類似した手法を使いましたが、防御側の対応は大きく異なりました。

組織Aでは、複数の端末への初期アクセス後、ドメイン権限の昇格、重要業務システムやクラウド環境への移動までSOCが十分に対応できませんでした。CISAによると、EDRではレッドチームの活動に関連する中・低重要度のアラートが発生していましたが、通常業務による大量の誤検知やアラートに埋もれていました。

組織Bでは、初期侵害後のアラートをSOCが確認し、影響を受けた端末を隔離しました。このためCISAは、実際の侵害が進んだと仮定する「assume breach」方式へ切り替えて、その後の検知・対応を継続評価しています。OTのDMZにあるホストへの活動やクラウドアカウントの不審な利用についても、防御側が検知・隔離しています。

この結果から分かるのは、レッドチーム演習の評価を「攻撃者が侵入できたか」だけで判断すべきではないことです。

組織Bでも最終的な評価ではドメインやクラウドを含む重要環境まで攻撃シナリオが進められましたが、実際の防御では初期段階から検知・封じ込めが行われています。評価すべきなのは、どの地点で検知したか、判断まで何分かかったか、隔離や認証情報の失効が実行できたか、SOCとシステム管理者が連携できたかです。

CISAは、この評価から、アラートのチューニング不足、組織間のサイロ、クラウド対策の不足を主な課題として挙げています。

国内インシデントから考えるレッドチームの評価範囲

レッドチーム演習を「サーバーへの技術的な侵入テスト」として設計すると、実際の攻撃経路を見落とす場合があります。

セキュリティ対策Labが2026年に取り上げた安藤ハザマの事案では、攻撃者が名刺管理システムへ不正アクセスしたのではなく、警察官を名乗る人物にだまされた正規権限を持つ社員が、約5,000件の名刺情報を自らダウンロードし、電子メールで送信しました。

安藤ハザマ、ソーシャルエンジニアリングで約5,000件の個人情報漏洩で整理した通り、この事案では「正しいIDでログインしていること」と「正しい目的で操作していること」が一致していません。

また、はてなが2026年4月に受けた資金流出事案では、警察関係者を名乗る電話を起点に、ビデオ通話、偽の身分証明、心理的な隔離、リモートデスクトップなどが組み合わされ、最終的に総額11億7,981万円の資金が流出しました。

はてなの11.8億円流出はボイスフィッシングが起点で追跡したこの事案も、単純な「脆弱なサーバーへの侵入」とは異なります。

この2件をレッドチームの設計に当てはめると、確認対象は次のように広がります。

正規ユーザーによる大量データ取得を異常として検知できるか
DLPやメール送信制御が大量の個人情報送信を検知できるか
高額送金や重要操作に複数承認が設定されているか
電話やチャットで官公庁、役員、取引先を名乗る人物から依頼された場合の本人確認手順があるか
「上司に相談するな」と指示された場合でも、独立した相談・エスカレーション経路が機能するか

ただし、従業員を対象としたソーシャルエンジニアリングを演習に含める場合は、経営・法務・人事を含む明確な承認、対象範囲、禁止事項、中止条件が必要です。実在機関へのなりすましや従業員への心理的負担を伴うシナリオを、技術チームだけの判断で実施するべきではありません。

レッドチーム演習が向いている企業

レッドチーム演習は、すべての企業が最初に実施すべきセキュリティ評価ではありません。

次のような状態の企業では、レッドチームによる評価結果を改善につなげやすくなります。

EDR、SIEM、SOCなどの検知・監視環境を導入している
CSIRTやインシデント対応担当者が決まっている
重要システム、重要データ、特権アカウントを把握している
MFA、パッチ管理、脆弱性管理など基本対策を運用している
ペネトレーションテストや脆弱性診断を実施している
「製品を導入したか」ではなく「実際に攻撃を検知・封じ込められるか」を確認したい
SOCやMDRの検知品質を第三者視点で評価したい

逆に、資産台帳がない、外部公開資産を把握していない、MFAが未導入、重大脆弱性の修正が長期間止まっている、インシデント対応担当者が決まっていない状態では、まず基本的な脆弱性管理やペネトレーションテスト、インシデント対応体制の整備を進める方が課題を特定しやすい場合があります。

インシデント時の部門間連携や経営判断を確認したい場合は、机上演習とは？セキュリティインシデント対応訓練の目的・進め方・効果を解説のようなシナリオ型演習が適しています。

レッドチーム演習の進め方

レッドチーム演習は、攻撃手法よりも先に目的とルールを決めます。

1. 守るべき資産と評価目的を決める

「社内へ侵入できるか」のような曖昧な目的ではなく、何を守る能力を評価するかを決めます。

例としては、顧客データ、設計情報、Active Directory、Microsoft 365、決済環境、工場ネットワークなどがあります。

評価目的も、「重要データへの到達をSOCが検知できるか」「侵害端末からクラウドへの横展開を止められるか」など具体化します。

2. 想定する攻撃者とシナリオを決める

自社に関係する脅威を基に、外部攻撃者、認証情報を取得した攻撃者、委託先アカウントを悪用する攻撃者などを設定します。

MITRE ATT&CKなどを利用し、自社が想定する脅威の戦術・技術と、現在の検知ルールを対応付ける方法があります。

3. Rules of Engagementを定める

レッドチーム演習では、事前に実施条件を文書化します。

最低限、次を明確にします。

対象システムと対象外システム
実施可能な時間帯
使用してよいアカウントや環境
データの取得・保存・持ち出しに関する制限
業務停止につながる操作の禁止
従業員を対象とする演習の可否
クラウド・SaaS・委託先に関する制約
緊急停止条件
実施責任者と連絡先
実際のインシデントと演習を識別するための確認経路

英国NCSCも、本番環境で攻撃シミュレーションを行う場合、システム動作を変更したり、最悪の場合は停止させたりするリスクがあると注意しています。

4. 防御側の検知・対応を記録する

演習中は、攻撃側の成功・失敗だけでなく、防御側の反応を記録します。

確認したいのは、次のような時間と判断です。

最初のログ・アラートが発生した時刻
SOCが異常として認識した時刻
調査を開始した時刻
端末隔離やアカウント停止を判断した時刻
関係部門へ連絡した時刻
経営層やCSIRTへエスカレーションした時刻
攻撃経路を特定した時刻

これにより「EDRが検知した」という製品単位の評価ではなく、組織として封じ込めまで実行できたかを確認できます。

5. 改善項目を担当者と期限まで落とす

レッドチームの報告書を作って終了すると、同じ検知ギャップが残ります。

改善項目は、EDRルール、SIEM相関ルール、ログ取得、IAM、ネットワーク分離、運用手順、承認フローなどに分け、担当部署と期限を設定します。

検知ルールの改善が主目的であれば、レッドチームからパープルチーム方式へ切り替え、同じ攻撃シナリオを再実行しながら検知できる状態まで調整する方法もあります。

レッドチームサービスを選ぶときの確認項目

外部事業者へ委託する場合は、「高度な攻撃ができるか」だけでなく、演習を安全に管理できるかを確認します。

確認項目	確認内容
演習目的の設計	自社の重要資産や脅威モデルに合わせてシナリオを設計できるか
対象範囲	オンプレミス、クラウド、ID、SaaSなど必要な範囲に対応できるか
SOC評価	検知、調査、隔離、エスカレーションまで評価できるか
ルール管理	Rules of Engagement、中止条件、緊急連絡体制を文書化するか
データ管理	演習中に取得した情報の保存、暗号化、削除方法が定められているか
第三者環境	SaaS、クラウド、委託先など第三者の利用規約・許可条件を確認するか
報告書	攻撃経路だけでなく、検知ギャップと改善優先度を示すか
再評価	改善後に再テストできるか
パープルチーム支援	検知ルール改善まで伴走できるか

攻撃成功を競う演習ではありません。業務影響を抑えながら、防御側が改善できる情報を残せることが選定条件になります。

情報システム部門・CSIRTが確認したいポイント

レッドチーム演習を検討する前に、次を確認すると実施目的を整理できます。

重要資産と「侵害されたくない到達点」を定義しているか
SOCやCSIRTがどの範囲を監視しているか説明できるか
EDR、SIEM、クラウド、認証基盤のログが必要な期間保存されているか
SOCが端末隔離やアカウント停止を実行できる権限を持つか
クラウド環境の侵害を想定した対応手順があるか
正規アカウントによる異常操作も監視対象になっているか
大量データ取得や外部送信を検知できるか
委託先やSaaSを演習対象にする場合の許可条件を確認しているか
実際のインシデントが演習中に発生した場合の切り分け手順があるか
演習後の改善項目に担当部署と期限を設定できるか

これらに回答できない場合、レッドチーム演習そのものより、資産管理、ログ設計、脆弱性管理、ペネトレーションテスト、机上演習などを先に実施した方が、改善項目を整理しやすいことがあります。

まとめ

レッドチームは、脆弱性を多く見つけることではなく、実際の攻撃者を想定した一連の行動に対して、組織の防御・検知・対応がどこまで機能するかを確認するための手法です。

ペネトレーションテストで「侵入可能か」を確認した後、EDR、SIEM、SOC、CSIRT、ID管理、クラウド、業務手続きまで含めて「侵入を検知し、被害拡大を止められるか」を確認したい段階でレッドチーム演習が選択肢になります。

実施前には、重要資産、評価目的、対象範囲、禁止事項、中止条件を明確にし、演習後は検知ルールや運用手順の改善まで追跡します。