SCS評価制度★3のログ管理は、取得・保管・レビューの3つが揃って初めて要件を満たします。取得しているだけでは不十分で、改ざんされない状態で保管し、定期的に確認した記録が残っているかまで問われます。Microsoft 365の監査ログは有効ですが、既定の保持期間とオンプレミス側の取得漏れに注意が必要です。
SCS評価制度の★取得について、現状アセスメントからギャップ分析、技術対策の実装、申請サポートまでをワンストップでご支援しています。
SCS評価制度 対応支援 を見る →SCS評価制度 総合ガイドログは「取っている」だけでは足りない
ログ管理は、バックアップと並んで実施しているつもりで要件を満たしていないことが多い領域です。サーバーやクラウドの既定設定でログは出ているため、「取っています」と答えられてしまうからです。
しかし問われるのは次の3点です。
| 観点 | 問われること | よくある不足 |
|---|---|---|
| 取得 | 必要なログを、決めた範囲で取得しているか | 既定のまま。何が記録され何が記録されないか把握していない |
| 保管 | 改ざんされない状態で、必要な期間保管しているか | ローテーションで上書き。管理者が消せる場所に置いている |
| レビュー | 定期的に確認し、異常時の対応を決めているか | インシデントが起きるまで誰も見ていない |
とくに3番目が抜けやすく、ここが空白だと取得しているだけで運用されていないと判断されます。バックアップ要件で復元テストが問われるのと同じ構造です。
何のログを取るか
すべてのシステムのすべてのログを集めようとすると、容量も工数も破綻します。侵害の調査に使えるかを基準に対象を絞ってください。
| ログの種類 | 優先度 | 調査で何が分かるか |
|---|---|---|
| 認証ログ（成功・失敗） | 高 | 不正ログインの試行、侵入の起点 |
| 特権アカウントの操作 | 高 | 権限昇格、設定の改変 |
| 重要データへのアクセス | 高 | 持ち出しの範囲、影響を受けた情報 |
| 設定変更の履歴 | 中 | 攻撃者による防御機能の無効化 |
| ウイルス対策・EDRの検知 | 高 | 侵入の検知時刻、対処の記録 |
| ネットワーク機器の通信ログ | 中 | 外部との不審な通信 |
設計時は「何が記録されないか」も併せて書き出してください。取得対象外の範囲を把握していること自体が、管理されている証拠になります。
保存期間をどう決めるか
保存期間は、法令上の要求がある場合を除き、自社で定めて運用します。決め方の軸はインシデントの発覚までにかかる時間です。
侵入から発覚までに数か月かかる事例は珍しくありません。発覚した時点でログが残っていなければ、いつ、どこから、何を持ち出されたかを説明できず、取引先への報告もできません。
| ログの種類 | 保存期間の考え方 |
|---|---|
| 認証・特権操作 | 調査の起点になるため長めに確保する |
| 重要データへのアクセス | 影響範囲の特定に必要。認証ログと同等以上 |
| 一般的な操作ログ | 容量とのバランスで短めに設定してよい |
実務では、容量の制約から一律に長期保存はできません。種類ごとに期間を分けて定義し、その根拠を書いておくことが現実的な落としどころです。「全ログを何年」と決めて実現できないより、根拠のある使い分けのほうが説明できます。
改ざん防止と権限分離
攻撃者は痕跡を消すためにログを削除します。業務用の管理者アカウントで消せる場所にログを置いている状態は、実質的にログがないのと同じです。
- 別の場所へ転送する：発生元のサーバー上だけに置かず、別のストレージやサービスへ集約する
- 書き換えを拒否する設定にする：一定期間の削除・上書きをストレージ側で拒否する仕組みを使う
- 権限を分ける：ログの閲覧権限と削除権限を分け、削除できる人を限定して多要素認証を必須にする
3番目は追加費用がかからないため、まず着手すべき項目です。
定期レビューがないと形骸化する
ログを毎日全件見る必要はありません。求められるのは確認する仕組みがあり、記録が残っていることです。
- 頻度を決める：月次で認証失敗の急増や深夜帯の特権操作を確認する、といった粒度で足ります
- 見る観点を決める：観点を書き出しておくと、担当が替わっても同じ確認ができます
- アラートを設定する：多数回のログイン失敗など、明らかな異常は自動通知にします
- 結果を記録する：異常なしの場合も「確認した」記録を残します
異常が見つかったときに誰へ報告し、誰が判断するかも決めておいてください。この流れは技術対策の全体像で扱うインシデント対応と接続します。
Microsoft 365での実装
Microsoft 365を利用している場合、統合監査ログ（Unified Audit Log）でサインイン、ファイル操作、管理操作などを記録できます。追加購入なしで利用できる範囲が広く、まずここを有効化して設定を確認するのが出発点です。
ただし次の2点に注意してください。
- 既定の保持期間には上限がある：ライセンスによって保持期間が異なります。長期保存が必要なら、上位ライセンスか外部ストレージへの転送を検討します
- M365の外は対象外：オンプレミスのサーバー、ネットワーク機器、業務システムのログは別途取得が必要です
設定項目の対応関係はMicrosoft 365でSCS★3に対応する設定チェックリストに整理しています。SIEMによる統合監視については、★3の段階では必須ではありません。まず取得と保存を確実にするほうが優先されます。
残しておく証跡
- ログ管理方針：取得対象、取得しない範囲、保存期間とその根拠、保管先、責任者
- 設定内容の記録：どのシステムでどのログを有効化しているかの一覧
- レビュー記録：実施日、確認した観点、結果、異常時の対応
- 権限一覧：ログを閲覧・削除できるアカウントと多要素認証の状況
なお、個々の評価基準の文言はIPAが公開する★3の評価基準（81基準）に定義されています。本記事はその文言の解説ではなく、要求を満たすために実務でどう設計するかを整理したものです。申請前には必ず公開されている最新の基準を参照してください。
よくある質問
SCS★3ではログを何年保存すればよいですか？
一律の年数が定められているわけではありません。インシデントの発覚までに時間がかかることを前提に、調査に耐える期間を自社で定めて運用します。実務では認証・特権操作のログを長めに、一般的な操作ログを短めにと使い分ける設計が現実的です。
どのログを取得対象にすればよいですか？
優先度が高いのは、認証（成功・失敗）、特権アカウントの操作、重要データへのアクセス、設定変更、ウイルス対策やEDRの検知記録です。すべてのシステムのすべてのログを集めようとすると容量と工数が破綻するため、対象を決めて記録に残すことが重要です。
Microsoft 365の監査ログだけで足りますか？
Microsoft 365内の操作については有効ですが、オンプレミスのサーバー、ネットワーク機器、業務システムのログは別途取得が必要です。また既定の保持期間を超える保存を求める場合は、追加のライセンスまたは外部ストレージへの転送を検討することになります。
ログを取っていれば要件を満たしますか？
満たしません。取得に加えて、改ざんされない状態で保管していること、定期的に確認していること、異常を検知したときに誰がどう対応するか決まっていることまでが問われます。とくに定期レビューの記録がないと、取得しているだけで運用されていないと見なされます。
SIEMは導入すべきですか？
★3の段階では必須ではありません。まずログの取得と保存を確実にするほうが優先されます。SIEMによる統合監視は★4以降で本格的に問われる領域です。導入してもアラートに対応できる体制がなければ、運用されていない状態になります。
まとめ
SCS評価制度★3のログ管理で問われるのは、必要なログを決めた範囲で取得し、改ざんされない状態で保管し、定期的に確認した記録が残っているかです。
まず取得対象と「取得しない範囲」を書き出し、ログの閲覧権限と削除権限を分けるところまでは、追加費用なしで着手できます。保存期間は一律で決めず、認証・特権操作を長めに、一般操作を短めにと使い分け、その根拠を書いておくのが現実的です。
自社の現在地を項目単位で確認したい場合は、SCS★3 セルフチェック（無料・登録不要） ↗で26要求事項・81評価基準への適合率を測れます。