サプライチェーン・BCP・セキュリティ管理

Aug 4, 202522 min

この章の到達目標

攻撃を防ぐことだけでなく、実際に侵害された場合の事業への影響、復旧の順序、必要な経営判断 まで説明できるようにする。

2023年度のCIサービス侵害・リスクアセスメント、2025年度の管理体制とレジリエンスに直結する。

1. 用語一覧

優先用語・技術科目Bで押さえるポイント
Aサプライチェーン攻撃委託先、開発基盤、更新の配布経路を介した侵害
Aリスクアセスメントリスクの特定、分析、評価、対応
A情報資産・脅威・脆弱性リスクの成立条件と影響の分析
A攻撃シナリオ攻撃者の侵入手段、成立条件、被害の連鎖
ABCP / BCM事業継続計画と、継続的な管理活動
ABIA業務影響度分析、優先して復旧する業務
ARTO / RPO目標復旧時間・目標復旧時点
Aバックアップオフライン・イミュータブル・復元テスト
A3-2-1バックアップ複数のコピー、媒体の分散、オフサイト保管
A復旧手順・復旧訓練バックアップからの再構築、復旧の順序
A委託先管理契約条件、監査、インシデントの報告、再委託
A脆弱性管理資産の把握、優先順位付け、パッチの適用
Aインシデント対応体制指揮系統、初動、報告、外部との連携
BSBOMソフトウェアの部品構成、依存関係と脆弱性の追跡
BSCAOSS・依存ライブラリの脆弱性の検出
BSLSAビルド・供給過程の完全性を高める枠組み
Bコード署名配布元・成果物の完全性と秘密鍵の管理
BCI/CDのセキュリティビルド環境、Secrets、実行権限、成果物の保護
BCVE / CVSS脆弱性の識別子・深刻度の評価
BEPSS / KEV悪用される確率の推定・実際に悪用が確認された脆弱性
BISO/IEC 27001ISMSの要求事項、リスク管理
BNIST CSF 2.0Govern・Identify・Protect・Detect・Respond・Recover
Bゼロトラスト継続的な検証、最小権限、アクセス制御（sc_7）
BIT全般統制（ITGC）アクセス管理、変更管理、運用管理
B職務分掌 / SoD承認者と実行者の分離、不正・誤謬の抑止
BSLA / SLOサービス水準の合意と運用の目標
BDR / DRサイト災害復旧、代替環境への切替え
Bホット・ウォーム・コールドサイト復旧時間・費用・準備状況の違い
Bフェイルオーバー障害時の待機系への切替え
Bリスクの移転・受容保険、外部委託、残留リスクの経営判断
CTPRM第三者・委託先のリスクの継続的な管理
CVEX脆弱性が対象製品に与える影響の表明
Cin-toto / Sigstoreソフトウェアの供給過程の証跡・署名の検証
CISO 22301事業継続マネジメントシステム
CISMAP政府情報システム向けクラウドサービスの評価制度
Cサイバーレジリエンス攻撃を受けても事業を維持し、復旧し、適応する能力

2. サプライチェーン攻撃

2.1 3つの経路

経路例特徴
委託先・取引先保守事業者のリモート接続、子会社のネットワーク対策の弱い組織を踏み台にする
開発基盤CI/CDサービス、ソースコードリポジトリ、ビルドサーバ正規のビルド工程で不正なコードが混入する
配布経路ソフトウェアの更新サーバ、OSSのパッケージ正規の署名付きで多数の利用者に配布される

2.2 CI/CDのセキュリティ（2023年度関連）

CIサービスには、本番環境へのデプロイの権限、クラウドの認証情報、署名鍵などの Secrets が集まる。CIが侵害されると、これらがすべて漏えいする。

リスク対策
Secretsの漏えい長期間有効な認証情報を置かない。OIDC連携で、実行のたびに短時間だけ有効な認証情報を発行する
過剰な権限パイプラインごとに必要最小限の権限にする
外部からの持込みフォークからのプルリクエストでSecretsを使えないようにする
サードパーティのアクション・プラグインバージョンをタグではなくコミットのハッシュで固定する
成果物の改ざん成果物に署名し、デプロイ前に検証する
変更の承認本番へのデプロイに承認を必須にする（職務分掌）

漏えいが判明したときの対応：CIに登録していたすべてのSecretsを 失効・再発行 する。漏えいの期間中に、それらの認証情報が使われた形跡がないかを、クラウドやリポジトリのログで確認する。

2.3 ソフトウェアの完全性

技術内容
SBOMソフトウェアに含まれる部品（ライブラリ、バージョン）の一覧。新しい脆弱性が公表されたとき、影響を受ける製品をすぐに特定できる。形式はSPDX、CycloneDX
SCA依存ライブラリの既知の脆弱性やライセンスを検査する
VEXSBOMに含まれる脆弱性について、「その製品では影響を受けない」などの状態を表明する。対応の要否の判断を効率化する
SLSAビルドの来歴（Provenance）の記録や、ビルド環境の隔離など、供給過程の完全性のレベルを定めた枠組み
コード署名配布物に署名し、配布元と完全性を保証する。署名鍵が漏えいすると、不正なプログラムにも正規の署名ができてしまうため、HSMで保管する
in-toto / Sigstore供給過程の各工程の証跡、署名と透明性ログ

依存関係の混乱（Dependency Confusion）や、似た名前のパッケージ（タイポスクワッティング）にも注意する。社内のパッケージは社内のリポジトリを優先して参照するよう設定する。

3. 脆弱性管理

3.1 流れ

  1. 資産の把握：ハードウェア、ソフトウェア、バージョン、公開しているか、管理者は誰か
  2. 情報の収集：ベンダーの公表、JVN、CISAのKEVカタログ
  3. 影響の判断：自社の資産が該当するか、設定上の前提を満たすか
  4. 優先順位付け
  5. 対応：パッチの適用、回避策（設定の変更、機能の無効化、接続元の制限）
  6. 確認：適用の確認、再スキャン

3.2 優先順位付けの指標

指標内容使い方
CVE脆弱性の識別子
CVSS深刻度（基本値・現状値・環境値）基本値だけで判断せず、自社の環境で評価する
EPSS今後30日以内に悪用される確率の推定深刻度が高くても悪用の可能性が低いものとの区別
KEV実際に悪用が確認された脆弱性の一覧最優先で対応

優先順位の考え方：インターネットに公開している、実際に悪用されている、重要な資産に関係する、の3点が揃うものを最優先にする。VPN装置やファイアウォールなど、境界の機器の脆弱性は特に優先度が高い。

パッチをすぐに適用できない場合は、回避策と、悪用された場合の検知策（ログの監視強化）を併用する。

4. リスクアセスメント

4.1 用語

  • リスク は、情報資産・脅威・脆弱性が揃ったときに成立する。
  • リスクの大きさ ＝ 影響の大きさ × 発生の可能性
手順内容
リスクの特定資産、脅威、脆弱性、既存の管理策を洗い出す
リスクの分析影響の大きさと発生の可能性を見積もる
リスクの評価受容基準と比較し、対応の優先順位を決める
リスクへの対応低減・回避・移転・受容
対応内容例
低減管理策で発生の可能性や影響を小さくするMFA、バックアップ
回避リスクの原因となる活動をやめるカード情報を自社で保持しない
移転（共有）他者と分担するサイバー保険、外部委託
受容対策をとらずに受け入れる経営層が承認 し、残留リスクとして記録する

外部委託しても、説明責任は委託元に残る。リスクの移転で問われやすい論点である。

4.2 攻撃シナリオに基づくリスク分析

資産ごとに脅威を並べるのではなく、「攻撃者がどこから入り、何を経由して、何に到達するか」という シナリオ で分析する方法。

例：「保守事業者のリモート接続用の認証情報が漏えい → 保守用のVPNから工場のネットワークに侵入 → 制御システムのサーバを暗号化 → 生産停止」

シナリオの各段階に対して、防止・検知・対応の管理策が存在するかを確認する。

5. 委託先管理

段階確認すること
選定セキュリティ体制、認証の取得状況（ISMS、ISMAPなど）、過去の事故
契約セキュリティの要求事項、インシデント発生時の 報告の期限と連絡先、監査の権利、再委託の条件（事前の承認）、契約終了時のデータの返却・削除
運用定期的な評価・監査、アクセス権の見直し、リモート接続の管理
終了アカウント・接続経路の削除、データの削除の確認

再委託：委託先がさらに別の事業者に委託していると、委託元から見えないところで情報が扱われる。再委託を事前承認制にし、再委託先にも同等の管理を求める。

リモート保守の接続：常時接続ではなく必要なときだけ有効にする、接続元を限定する、MFA、操作を記録する、委託先ごと・担当者ごとにアカウントを分ける（共用アカウントを使わない）。

TPRM：取引先・委託先のリスクを、契約時だけでなく継続的に管理する活動。

6. BCPとDR

6.1 BIA（業務影響度分析）

業務ごとに、停止した場合の影響（売上、法令、顧客、安全）と、停止が許容される時間を分析し、優先して復旧する業務 を決める。

指標意味何で決まるか
RTO停止から どれだけの時間で 復旧するか業務が停止に耐えられる時間
RPOどの時点まで のデータを復旧するか失ってよいデータの量
MTPD最大許容停止時間これを超えると事業の継続が困難になる

RPOが「1時間」なら、少なくとも1時間ごとにバックアップ（または複製）が必要になる。RTOとRPOが短いほど、費用が高くなる。

6.2 DRサイト

種類準備状況復旧時間費用
ホットサイト本番と同等の設備が稼働し、データも同期している短い（数分〜数時間）高い
ウォームサイト設備はあるが、データの復元や設定が必要中程度中程度
コールドサイト場所と電源などだけ長い（数日以上）安い

ランサムウェアとDR：本番とDRサイトのデータをリアルタイムで同期していると、暗号化されたデータも同期される。同期とは別に、過去の時点に戻せるバックアップが必要である。

6.3 バックアップ

要件内容
3-2-1ルール3つのコピー、2種類の媒体、1つはオフサイト（遠隔地）
オフラインネットワークから切り離す（テープ、取外し可能な媒体）
イミュータブル一定期間、変更・削除ができない設定（WORM、オブジェクトロック）
認証の分離バックアップシステムの管理者アカウントをADと分ける。ADが侵害されてもバックアップを削除されない
世代管理侵入から暗号化までの潜伏期間を考慮し、十分に古い世代まで保持する
復元テスト実際に復元できることを定期的に確認し、復元にかかる時間がRTO以内かを測る

ランサムウェアの攻撃者は、暗号化の前にバックアップを探して削除する。「バックアップを取っている」だけでは不十分で、攻撃者の手が届かないこと を設問では問われる。

6.4 復旧の順序

ランサムウェアからの復旧では、次の順序を考える。

  1. 侵入経路を塞ぐ（脆弱性の修正、侵害されたアカウントの無効化）。塞がずに復旧すると再び侵入される
  2. 認証基盤（AD）を復旧・健全化する：他のシステムが依存しているため
  3. BIAで優先度が高い業務のシステム
  4. その他のシステム
  • 復元するバックアップの中にマルウェアや、攻撃者が作成したアカウントが含まれていないか確認する（侵入時期より前の世代を選ぶ）。
  • 再構築したシステムは、監視を強化した状態で接続する。

7. 管理の枠組み

7.1 NIST CSF 2.0

機能内容
Govern（統治）方針、役割、リスク管理の戦略、サプライチェーンのリスク管理（2.0で追加）
Identify（識別）資産、リスクの把握
Protect（防御）アクセス制御、教育、データの保護
Detect（検知）監視、異常の検知
Respond（対応）インシデントへの対応
Recover（復旧）復旧計画の実行

7.2 その他の枠組み

枠組み内容
ISO/IEC 27001ISMSの要求事項。リスクアセスメントに基づき管理策を選び、適用宣言書にまとめる
ISO 22301事業継続マネジメントシステムの要求事項
ISMAP政府がクラウドサービスを調達する際の評価制度
サイバーセキュリティ経営ガイドライン経営者が認識すべき原則と、担当者に指示すべき重要項目

7.3 IT全般統制と職務分掌

統制内容
アクセス管理アカウントの申請・承認・定期的な棚卸し、退職者の削除
変更管理本番環境の変更の申請・承認・テスト・記録
運用管理ジョブの監視、バックアップ、障害対応

職務分掌：開発者が本番環境に直接リリースできる、承認者と実行者が同じ、という状態は、不正や誤りを見逃す原因になる。CI/CDで承認の工程を必須にすることも職務分掌の実装である。

7.4 SLAとSLO

  • SLA：サービス提供者と利用者の 合意（稼働率、復旧時間、報告の期限）。違反時の取決めを含む。
  • SLO：提供者が内部で設定する運用の 目標。
  • 委託先との契約では、セキュリティインシデントの報告期限をSLAに含めることが重要。

8. 経営判断として問われること

科目Bの管理系の設問では、技術者として経営層に何を提示するかが問われる。

判断提示すべき情報
システムの停止・ネットワークの遮断被害が拡大する見込み、停止による業務への影響、代替手段
リスクの受容残留リスクの内容、発生した場合の影響、受容する期間と再評価の時期
対策への投資低減されるリスク、費用、導入までの期間
公表・報告法令上の報告義務、顧客・取引先への影響、公表の時期

9. 設問を読むときのチェックリスト

  1. 守るべき 業務・資産 は何か。その RTO / RPO は
  2. 外部の組織（委託先、クラウド、OSS）との 接点 はどこか
  3. 委託先との 契約・権限 は適切か
  4. 侵害されたとき、バックアップは攻撃者から守られているか
  5. 復旧の 順序 と、その前に塞ぐべき侵入経路は
  6. 誰が 判断・承認 するのか

~Yu Tokunaga