コンテンツにスキップ

インシデント対応計画

正式文書

  • PDF または正式 URL へのリンク: 英語版「Authoritative document」を参照

所管

項目
所管 Takayuki KIKUCHI
最終確認日 2026-04-13

目的

本文書は、情報セキュリティの事象およびインシデントを管理するための計画を定め、セキュリティインシデントを発見した、または対応していると考える従業員またはインシデント対応者向けの指針を示す。

適用範囲

本計画は、情報セキュリティまたはデータプライバシーに関するすべての事象またはインシデントを対象とする。

事象およびインシデントの定義

セキュリティ事象とは、当社が管理するデータ、システム、またはネットワークの機密性、可用性、完全性、またはプライバシーに関連する、観測可能な出来事である。

セキュリティインシデントとは、当社が管理するデータ、システム、またはネットワークの機密性、可用性、完全性、またはプライバシーに損害または影響が生じたセキュリティ事象である。

報告

Rendering Consulting Inc.(以下「当社」)の従業員、請負業者、ユーザー、または顧客が、情報セキュリティの事象またはインシデント、インシデントの可能性、差し迫ったインシデント、不正アクセス、ポリシー違反、セキュリティ上の弱点、または不審な活動に気付いた場合は、次のいずれかの連絡手段を用いて、直ちにその内容を報告しなければならない。

  • メール(kikuchi@ren-con.jp)に、事象またはインシデントに関する情報または報告を送付する

報告者は、犯罪の目撃者として適切に行動し、観測または発見した内容について具体的な詳細を含めるものとする。

深刻度

CEO は事象およびインシデントのチケットを監視し、次の区分に基づきチケットの深刻度を割り当てる。

P2/P3 — 中程度および低程度

この深刻度に該当する事案は、単なる疑いや異常な挙動にとどまる。未検証であり、追加の調査が必要である。システムに明確なリスクがある兆候はなく、緊急対応は不要である。暗号化済みノート PC の紛失・盗難、不審なメール、障害、ノート PC 上の異常な活動などが含まれる。

P1 — 高程度

高程度の事案は、攻撃者や積極的な悪用がまだ実証されておらず、発生していない可能性もあるが、発生の可能性が高い問題に関する。暗号化なしのノート PC の紛失・盗難、悪用リスクの直接的な脆弱性、当社システム上の敵対的な持続性やリスクを伴う脅威(バックドア、マルウェアなど)、業務データ(パスワード、脆弱性情報、決済情報など)への悪意あるアクセスなどが含まれ得る。

P0 — 重大

重大な事案は、悪意ある行為者が関与し、身体被害のリスクを個人に及ぼす脅威など、積極的に悪用されているリスクに関する。この区分に該当するには、積極的な悪用の確認が必要である。

エスカレーションおよび社内報告

インシデントのエスカレーション連絡先は、付録 A を参照する。

深刻度 エスカレーション経路
P0 — 重大 P0:CEO へ直ちに通知する。
P1 — 高程度 CEO にも、チケット番号を添えてメールまたは Slack で通知しなければならない。
P2/P3 — 中程度および低程度 対応のため CEO に割り当てられたサポートチケットを作成しなければならない。

文書化

報告されたすべてのセキュリティ事象、インシデント、および対応活動は、GitHub に文書化し、適切に保護しなければならない。

検証済みのすべての P0 セキュリティインシデントに対して、根本原因分析(RCA)を実施してもよい。根本原因分析報告書は文書化し、インシデントチケットに参照を記載しなければならない。根本原因分析は CEO がレビューし、ポストモーテム会合の開催の要否を判断する。

インシデント対応プロセス

重大な事案については、対応チームは、調査、悪用の封じ込め、脅威の根絶、システムおよびサービスの復旧、脆弱性の是正、およびインシデントから得られた教訓を含むポストモーテム報告の文書化を目的とした反復的な対応プロセスに従う。

概要

  • 事象の報告
  • トリアージおよび分析
  • 調査
  • 封じ込めおよび無力化(短期/トリアージ)
  • 復旧および脆弱性の是正
  • 強化および検知の改善(教訓、長期的対応)

詳細

  • CEO がインシデント対応を統括する
  • 必要に応じて、物理的または仮想の場所(例:Slack チャネル)として中央の「ウォールーム」を指定する
  • インシデントが解決するまで、定間隔でインシデント対応会合を開催する
  • 必要に応じて法務および経営幹部に通知する

インシデント対応会合のアジェンダ

  • インシデントチケットおよびタイムラインの更新。新たな侵害指標(IOC)の文書化
  • 調査に関する質疑応答の実施
  • 緊急緩和策の適用
  • 外部報告/侵害報告
  • 長期的緩和策の計画。根本原因分析(RCA)の文書化
  • その他必要な項目

特別な考慮事項

社内起因の事案

悪意ある行為者が社内従業者、請負業者、ベンダー、またはパートナーである事案は、慎重な取り扱いが必要である。インシデントマネージャーは CEO に直接連絡し、他の従業員とは議論しない。これらは重大な事案であり、フォローアップが必須である。

通信の侵害

インシデント対応チームの一員として名乗る前に、インシデント対応者は Slack を利用できる状態にしておかなければならない。IT 通信にリスクがある場合は、帯域外の手段が選ばれ、携帯電話を介してインシデント対応者に伝達される。

ルートアカウントの侵害

Azure のルートアカウントまたはグローバル管理者の侵害が判明している、または想定される場合は、付録 D のプレイブックに従う。

追加要件

  • 疑われる事象および報告された事象・インシデントは文書化しなければならない
  • 疑われるインシデントは評価され、事象またはインシデントのいずれかに分類しなければならない
  • インシデント対応は、本計画および関連手順に従って実施しなければならない
  • すべてのインシデントは正式に文書化し、文書化された根本原因分析を実施しなければならない
  • インシデント対応者は、NIST SP 800-86「インシデント対応へのフォレンジック手法の統合ガイド」などの業界の指針およびベストプラクティスに従い、インシデント関連の証拠を収集、保管、保全しなければならない
  • 疑われるおよび確認された不正アクセス事象はインシデント対応チーム(IRT)がレビューする。侵害の有無の判断は CEO および法務顧問のみが行う
  • 当社は、CEO および法務顧問が判断するところにより、当社のポリシー、契約上の義務、および規制上の要件に従い、関連するインシデントまたは侵害について、顧客、パートナー、ユーザー、影響を受けた当事者、および規制当局に、不当な遅滞なく適切に通知する
  • 本インシデント対応計画は、少なくとも年に一度レビューし、正式にテストする。IR 計画のテスト活動の結果、所見および教訓は正式に文書化し、セキュリティ、コンプライアンス、監査の要件を支援するために保管する

外部コミュニケーションおよび侵害報告

当社または顧客のシステム、ネットワーク、および/またはデータへの不正アクセスが発生した場合、法務および経営幹部は技術チームと協議する。法務および CEO は、侵害報告または外部コミュニケーションの要否を判断する。侵害は、すべての契約上の義務および適用法に従い、不当な遅滞なく、顧客、消費者、データ主体、および規制当局に報告しなければならない。

法務および/または経営管理の承認なく、いかなる者も、インシデントまたは潜在的侵害に関する情報を第三者または権限のない者に開示してはならない。

緩和および是正

法務および経営幹部は、インシデントまたは侵害の結果として講じるべき即時または長期的な緩和または是正措置を判断する。緩和または是正措置が必要な場合、経営幹部は、計画、コミュニケーション、および実行に関して担当者を指揮する。

顧客、データ管理者、および当局との協力

法務および経営幹部が判断するところにより、必要に応じて、当社はインシデントまたはデータ侵害が発生した場合のすべての義務を果たすために、顧客、データ管理者、および規制当局と協力する。

役割と責任

当社の情報資源を利用するすべての従業員およびユーザーは、情報資産の保護に責任を負う。次の表は、インシデント対応の役割ごとの具体的な責任を定める。

対応チームメンバー

役割 責任
インシデントマネージャー インシデントマネージャーは、対応期間中の主要かつ最終的な意思決定者である。インシデントの解決およびインシデント対応措置の正式な終了について最終的な責任を負う。連絡先は付録 A を参照する。

責任には次が含まれる:

- 必要に応じて、すべての機能から適切な人員が積極的に関与していることを確保する
- 適切な担当者またはチームに、定期的な間隔で状況更新を伝える
- 短期的にインシデントを解決する
- 必要なフォローアップ措置を判断する
- フォローアップ活動を適切な担当者に割り当てる
- 侵害報告の引き金となり得るインシデントの詳細を、書面で CEO に速やかに報告する
インシデント対応チーム(IRT) 関与し、インシデントに積極的に取り組んでいる者。IRT のすべてのメンバーは、インシデントが正式に解決されるか、インシデントマネージャーにより正式に解散されるまで、インシデント対応に関与し続ける。
エンジニア(サポートおよび開発) 資格のあるエンジニアはオンコールに配置され、主要リソースが利用できない場合はインシデントマネージャーとして、またはインシデント対応に動員された際は IRT のメンバーとして行動し得る。エンジニアは、情報システムの技術および構成要素、ログ、監視、アラートツールを含むセキュリティ統制、適切なコミュニケーションチャネル、インシデント対応プロトコル、エスカレーション手順、および文書化要件を理解する責任を負う。エンジニアがインシデント対応に関与した場合、IRT のメンバーとなる。
ユーザー 当社の従業員および請負業者。ポリシーに従い、問題、疑われる問題、弱点、不審な活動、およびセキュリティの事象・インシデントを報告する責任を負う。
顧客 当社サービスの利用に関する問題を報告する責任を負う。報告された問題が解決されたことを確認する責任を負う。
法務顧問 CEO および経営幹部と共同で、インシデントが法的または規制上のリスクを生じるか、報告対象の侵害とみなされるかを判断する責任を負う。外部への侵害通知は、いかなる外部当事者に送付する前に、すべて法務が書面でレビューし承認する。
経営幹部 CEO および法務顧問と共同で、インシデントが報告対象の侵害とみなされるかを判断する責任を負う。外部への侵害通知は、いかなる外部当事者に送付する前に、適切な会社役員が書面でレビューし承認する。侵害の発生の判断にあたり、当社はステークホルダーの合意形成を図る。合意に至れない場合、最終的な侵害の判断は CEO が行う。

経営のコミットメント

当社の経営は本ポリシーを承認し、当社または顧客に悪影響を及ぼし得るセキュリティ事象およびインシデントに合理的に対応するために必要なリソース、ツール、および研修の提供にコミットする。

例外

本ポリシーへの例外の申請は CEO に提出し、CEO の承認を得なければならない。例外は文書化する。

違反および執行

本ポリシーに違反していることが判明した場合は CEO に報告しなければならない。本ポリシーに違反した場合、システムおよびネットワークの利用権限の直ちの剥奪または停止、ならびに雇用契約に従った懲戒処分(解雇を含む)を含み得る。

付録 A — 連絡先

インシデント対応チームの連絡先は、主要連絡先リストを参照する。

付録 B — インシデント収集フォーム

オンラインフォーム(日本語):インシデント収集フォーム影響を受けた情報システムごとに 1 回送信する(各フォームとも URL は同一)。各回答は 1 台のシステムを記述するものとする。

付録 D — Azure グローバル管理者侵害プレイブック

目的

本ランブックの目的は、Azure グローバル管理者アカウントの利用をどのように管理するかについて具体的な指針を示すことにある。本ランブックは詳細なインシデント対応戦略に代わるものではない。本ランブックは次の IR ライフサイクルに焦点を当てる。

  • 支配の確立
  • 影響の特定
  • 必要に応じた復旧
  • 根本原因の調査
  • 改善

侵害指標(IOC)、初期手順(止血)、およびそれらを実行するための詳細手順を以下に示す。

前提

  • Azure CLI が構成およびインストール済みであること
  • 報告プロセスがすでに整備されていること
  • Microsoft Defender for Cloud が有効であること
  • Microsoft Sentinel または Azure Monitor が有効であること

侵害指標

  • アカウントにとって異常な活動:
  • 新しい Entra ID(Azure AD)ユーザーまたはサービス プリンシパルの作成
  • Azure Monitor または診断設定の無効化
  • Microsoft Defender for Cloud の無効化
  • ロール割り当てまたは Privileged Identity Management(PIM)設定への異常な変更
  • サブスクリプションレベルのポリシーへの予期しない変更
  • 新規または予期しない仮想マシンまたはリソースの起動
  • アカウントの連絡先または請求情報の変更

是正手順 — 支配の確立

侵害の可能性があるアカウントに関する Microsoft のドキュメントでは、以下の具体的なタスクが挙げられている。

  1. できるだけ早く Microsoft Azure サポートに連絡する
  2. グローバル管理者のパスワードを変更・ローテーションし、アカウントに関連付けられた MFA デバイスを登録する
  3. すべてのサービス プリンシパルおよびマネージド ID のシークレット、クライアント資格情報、アクセスキーをローテーションする
  4. Microsoft Entra ID のサインインログおよび監査ログで不審な活動を確認する
  5. 特定された不審な操作についてランブックを開く
  6. インシデントをクローズする
  7. インシデントをレビューし、何が起きたかを把握する
  8. 根本問題を修正し、改善を実施し、必要に応じてランブックを更新する

追加のアクション項目 — 影響の特定

作成されたリソースおよび変更操作をレビューする。将来のアクセスを可能にするために作成された項目がある場合がある。確認すべき例は次のとおりである。

  • Entra ID のクロステナント アクセス構成
  • Entra ID のユーザーおよびサービス プリンシパル
  • Azure Storage アカウントおよびコンテナ
  • Azure Virtual Machines およびスケールセット
  • Azure Key Vault のアクセス ポリシー