セキュリティ技術入門の演習ケース集
この教材の要約
技術入門で学んだ脆弱性、権限、ログ、設定不備の知識を、実務に近いケース判断へ変える演習教材です。
概念図
技術演習ケース
├─ 事象を読む
│ ├─ 認可不備
│ ├─ ログ異常
│ ├─ 権限過多
│ └─ 設定不備
├─ 優先度を考える
│ └─ 何を先に止めるか
└─ 防御へ戻す
├─ 設計
├─ 実装
├─ 設定
└─ 監視
はじめに
技術専門トラックの本編では、基盤、脆弱性、認証、実装、ハードニング、IAM、ログ、インシデント対応を整理してきました。
この章では、それらを場面判断として結び直します。1
IPA や OWASP が継続して強調する代表的な脆弱性と、NIST/CISA が示すログ、権限、インシデント対応の基礎を、場面でつなぎ直すのがこの章の目的です。1
各ケースでは、「どこが危険か」「何を優先するか」「どう守るか」を考えてください。
ケース1：IDを変えると他人のデータが見えた
レビュー中、URLパラメータのIDを変えると、別ユーザの詳細画面が表示されました。
ログインは必要ですが、対象データの切り替えができてしまいます。
考えるポイント
- これは認証の問題か、認可の問題か
- 影響範囲はどこまでか
- どこで防ぐべきか
推奨観点
- 認可不備として捉える
- 画面制御だけでなく、実処理側で対象データと利用者権限を照合する
- 類似APIや一覧画面にも同種の不備がないか確認する
ケース2：ログイン失敗が深夜に急増した
深夜帯に、通常より多いログイン失敗が短時間に集中しました。
一部では、失敗後に成功している記録もあります。
考えるポイント
- 何のログをまず見るべきか
- 単なる入力ミスと何が違うか
- どの優先度で扱うべきか
推奨観点
- 認証ログを中心に、時間帯、送信元、対象アカウントを確認する
- ブルートフォースやクレデンシャルスタッフィングの可能性を考える
- 成功しているなら侵害リスクを上げて扱う
ケース3：一時対応で管理者権限を付けたままだった
障害対応で一時的に広い権限を付与したところ、対応後に戻し忘れていました。
その間に、想定していない設定変更も見つかりました。
考えるポイント
- 何が危険か
- どの記録を見るべきか
- 再発防止として何を変えるべきか
推奨観点
- 権限過多と運用不備の両面で捉える
- 権限変更履歴と設定変更履歴を確認する
- 一時権限の期限化やレビュー手順を検討する
ケース4：エラーページに内部情報が出ていた
本番環境で例外が起きたとき、スタックトレースや内部パスがそのまま表示されていました。
同時に、運用ログには調査に必要な情報が十分残っていません。
考えるポイント
- 利用者向け表示と運用ログのどちらに問題があるか
- どう分けて設計すべきか
推奨観点
- 両方に問題がある
- 利用者向けには内部情報を出しすぎず、運用側には追跡可能な記録を残す
- エラーハンドリングを「隠すか出すか」ではなく「誰に何を見せるか」で設計する
ケース5：公開不要のポートが残っていた
本番サーバで、運用チームも使っていない管理用ポートが開いたままでした。
過去の暫定対応の名残と思われます。
考えるポイント
- なぜ危険か
- 何を確認してから閉じるべきか
- 再発防止には何が必要か
推奨観点
- 不要な入口として捉える
- 実際の利用有無、影響範囲、設定由来を確認する
- 構成管理と定期棚卸しを運用に組み込む
ケース6：外部生成AIへ設定断片を貼りそうになった
開発効率化のため、設定ファイルの一部とエラーログ断片を外部生成AIへ貼って相談しようとしています。
トークンらしき文字列と内部構成情報が含まれています。
考えるポイント
- 何が秘密情報にあたりうるか
- 利用可否は誰が判断すべきか
- 代替手段は何か
推奨観点
- トークン、内部構成、接続情報は重要情報として扱う
- 自社ルールで利用可否を確認する
- マスキングや社内承認済み手段の利用を検討する
ケースから共通して分かること
技術系の事故やリスクには、次の共通点があります。
- 認証、認可、権限、ログ、構成がつながっている
- 単一の設定ミスより、複数の弱さの組み合わせで事故になる
- 技術対応だけでなく、運用ルールやレビュー手順も重要である
次に読む
関連トピック
| 関係 | 教材 | 使い方 |
|---|---|---|
| 前提 | 技術者として知っておくべきインシデント対応の流れ | ケースで優先度を考える前提にする |
| 次に読む | セキュリティ技術入門の総合確認 | 演習後に技術入門全体を確認する |
| 復習 | Webアプリで押さえるべき代表的な脆弱性 | 認可不備や入力系脆弱性へ戻る |