サーバーには日々、ログイン記録やファイルへのアクセス、通信の記録といったログが出力されています。しかし「各サーバーにログは溜まっているものの、集約も監視もできていない」「監査や取引先から『サーバーのログをきちんと取って保管しているか』と問われて困った」という企業は少なくありません。
サーバーログは、不正アクセスや内部不正が起きたときに「誰が・いつ・何をしたか」を追う手がかりになり、障害の原因調査や監査対応にも欠かせません。ただし、ただ出力させているだけでは役に立たず、セキュリティのためには「集める・保管する・監視する」という流れを設計しておく必要があります。
本記事では、セキュリティ目的でのサーバーログ管理を「集める→保管する→監視する」の3ステップに分け、取得すべきログの種類、保管期間の目安とその根拠になる法令・業界基準、監視の方法までを解説します。あわせて、手作業で始められる範囲とツールが必要になる部分の切り分け、役立つサービスも紹介します。
目次
一括ダウンロードする
サーバーログ管理とは｜「集める→保管する→監視する」の3ステップ
セキュリティ目的でのサーバーログ管理とは、サーバーが出力するログを計画的に「集める・保管する・監視する」ことで、不正アクセスや内部不正、障害の兆候を把握できる状態をつくる取り組みです。総務省も、不正アクセスやウイルス感染が起きた際の事後調査に監査ログが役立つとして、その取得・管理の考え方を示しています。
セキュリティ目的でサーバーログを管理する3ステップ
サーバーログ管理は、次の3つのステップで考えると全体像をつかみやすくなります。各ステップで何をするのかを先に押さえておきましょう。
- 集める: どのサーバーの、どのログを取得するかを決め、各サーバーから収集します。OSの標準機能やアプリケーションの出力、ログ管理製品を使って集めます。
- 保管する: 収集したログを、出力元のサーバーとは別の場所に集約し、改ざん防止・時刻の同期・適切な保管期間を設計して安全に保ちます。
- 監視する: 集めたログを定期的に確認・分析し、不正アクセスや内部不正、異常の兆候を検知します。件数が増えると手作業では限界があり、ツールによる自動化が必要になります。
この記事では、以降でそれぞれのステップを具体的に解説していきます。
サーバーログを管理する目的
サーバーログをセキュリティの観点から管理する目的は、大きく次の4つに整理できます。
- 不正アクセス・サイバー攻撃の調査: 侵入の有無や経路、被害範囲を事後に追跡する。
- 内部不正・情報漏えいの検知: 従業員や委託先による不正なファイル操作・持ち出しを把握する。
- 障害の原因特定と復旧: システムのエラーや異常終了の記録から原因を切り分ける。
- 監査・コンプライアンス対応: 監査や取引先から求められたとき、ログで運用の証跡を示す。特権IDや委託先作業の可視化もここに含まれます。
とくに社内のセキュリティ対策では、「誰が・いつ・何をしたか」を後から追えることが、内部不正の抑止と早期発見の両面で重要になります。
【集める】取得すべきサーバーログの種類と取り方
ここからは、最初のステップである「集める」について解説します。セキュリティのためには、どのログを取るかを目的から逆算して決めることが出発点になります。
取得すべきサーバーログ一覧（何の検知・調査に役立つか）
総務省は、事後調査に役立つ監査ログとして、ファイアウォールの通信記録・IDS/IPS（不正侵入検知・防御システム）の監視記録・ファイルサーバへのアクセス・認証の成否・Webサーバへのアクセス・データベースへのアクセス・アプリケーションの処理結果など、具体的な取得対象を挙げています。これを踏まえ、セキュリティの観点で押さえておきたい主なログと、それぞれが何の検知・調査に役立つかを整理しました。
| ログ種別 | 認証ログ | アクセスログ（Web・ファイルサーバ） | ファイル操作ログ | システム（イベント）ログ | 通信ログ（ファイアウォール・IDS/IPS・プロキシ） | データベース・アプリケーションログ | 操作ログ（端末・特権ID） |
|---|---|---|---|---|---|---|---|
| 記録される内容 | ログイン・ログアウト、認証の成功/失敗 | どの利用者がどのページ・ファイルにアクセスしたか | ファイルの参照・編集・削除・コピーの成否 | OS・サービスの起動停止、エラー、設定変更 | 通過/拒否した通信、検知した不審な通信 | DBへのアクセス、アプリの処理結果（正常/異常終了） | 端末での操作、特権IDや委託先の作業内容 |
| 何の検知・調査に役立つか | 不正ログイン、総当たり攻撃、退職者アカウントの悪用 | 不正アクセス、情報の持ち出し経路の調査 | 内部不正による情報持ち出し・改ざんの追跡 | 障害原因の特定、不審な設定変更の検知 | 外部からの侵入、マルウェアの外部通信の検知 | 不正なデータ抽出、アプリ異常の調査 | 特権の悪用、委託先作業の可視化 |
※取得すべきログは、自社のシステム構成や守りたい対象によって異なります。上表は代表的な例です。
認証とアクセスだけを取得して安心してしまうケースがありますが、通信ログやファイル操作ログ、特権IDの操作ログまで含めて初めて、侵入から内部での動き、情報の持ち出しまでを一連で追えるようになります。
出典・参考資料（1件）
サーバーログの取り方（OS標準・アプリ出力・製品で集約）
サーバーログを取得する方法は、大きく3通りあります。手作業で始めるならまずOSやアプリケーションの標準機能から、集約や監視まで考えるなら製品の利用が選択肢になります。
- OSの標準機能で取得する: Windowsサーバーはイベントログ、Linuxサーバーはsyslog（rsyslog）やsystemdのjournaldで、認証やシステムの記録を取得できます。
- アプリケーション・Webサーバーの出力を取得する: ApacheやNginxはアクセスログを、データベースは監査ログを出力できます。アプリケーションが独自に出力するログもここに含まれます。
- ログ管理製品で取得・集約する: 複数のサーバーのログを1か所に集めて検索・監視できるようにします。サーバーの台数が増えると、この方式が現実的になります。
OSやアプリの標準機能だけでは、各サーバーにログが分散したままで、横断的な調査や改ざん対策が難しくなります。どこまでを標準機能でまかない、どこから製品に任せるかは、後述の「自社でどう進めるか」で切り分けます。
出典・参考資料（2件）
【保管する】保存期間の目安と安全な保管の実務
次のステップは「保管する」です。集めたログをどれくらいの期間、どのように保つかを設計します。読者の多くが悩む保存期間から見ていきましょう。
ログの保管期間の目安と根拠（法令・業界基準）
まず前提として、日本には「サーバーログを一律に何年保存しなさい」という一般的な法令はありません。保存期間は、総務省も「組織が扱うデータの性質や、システムの処理能力、ネットワーク構成などに大きく関係します」としており、自社のリスクに応じて決めるものです。そのうえで、関連する法令・業界基準が定める期間が判断の参照点になります。それぞれ対象と趣旨が異なる点に注意して整理しました。
| 根拠（法令・業界基準） | 刑事訴訟法 第250条＋不正アクセス禁止法 第11条 | 刑事訴訟法 第197条第3項・第4項 | PCI DSS v4.0.1 要件10.5.1 | 労働基準法 第109条（＋附則第143条） | 個人情報保護法 第23条 |
|---|---|---|---|---|---|
| 対象・趣旨（誰に・何に） | 不正アクセス事案の立件可能期間（公訴時効）を踏まえたインシデント対応上の目安 | 捜査機関が通信事業者等に通信履歴の保全を求める制度（一般企業への保存義務ではない） | カード会員データを扱う事業者の監査ログ（法令ではなく業界基準） | 労働者名簿・賃金台帳など労働関係の重要書類。PC操作ログを勤怠の記録として使う場合に関係 | ログに個人情報が含まれる場合の安全管理措置（保存年数の定めはなし） |
| 期間の目安 | 不正アクセス行為（3年以下の拘禁刑）は公訴時効3年 | 30日（第3項）。特に必要なときは延長して合計60日まで（第4項） | 少なくとも12か月保持。うち直近3か月は分析のためすぐ利用可能 | 条文は5年。附則の経過措置で当分の間は3年 | —（安全管理措置の対象。保存年数の定めなし） |
※各根拠は対象・趣旨が異なります。自社に適用されるものを確認したうえで、保管期間を設計してください。
自社に直接当てはまる基準が特に無い場合でも、PCI DSSが監査ログに求める12か月や、不正アクセス事案の公訴時効である3年は目安になります。まずは1年以上を一つの下限に置き、扱うデータの重要性や調査で遡りたい期間に応じて延ばすのが現実的です。
また、上場企業などは、財務報告の内部統制（J-SOX）の証跡としてログの整備・保持が求められますが、保存年数そのものは法令で定められていません。
保存期間の核心は法令・基準の文言そのものにあるため、主な根拠の原文を示します。労働基準法第109条は書類の保存年数を次のように定めており、附則第143条の経過措置で当分の間は3年とされています。
使用者は、労働者名簿、賃金台帳及び雇入れ、解雇、災害補償、賃金その他労働関係に関する重要な書類を五年間保存しなければならない。
（附則第143条第1項）第百九条の規定の適用については、当分の間、同条中「五年間」とあるのは、「三年間」とする。
出典：労働基準法 第109条・附則第143条第1項｜e-Gov法令検索
クレジットカード情報を扱う事業者が従う業界基準のPCI DSS（v4.0.1）は、監査ログの保持について要件10.5.1で次のように定めています（公式の日本語版は許諾が必要なため、原文の英語で示します）。
Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.
出典：PCI DSS v4.0.1 Requirement 10.5.1｜PCI Security Standards Council
日本語に要約すると、監査ログを最低12か月保持し、うち直近3か月は分析のためすぐ利用できる状態にしておくことを求める内容です。
出典・参考資料（6件）
安全に保管するための実務（集約・改ざん防止・時刻同期）
ログは取得して終わりではなく、調査に使える状態で安全に保つ必要があります。総務省は、ログを収集元の機器内ではなく別の場所に保管することを推奨しています。
ログは、収集した機器の本体内ではなく、ログ取得のために別途ログ管理システムなどを設計し、そこで保管を行うことが推奨されます。そうすることで、ログの改ざんなどの不正行為からの保護だけでなく、ログ解析プログラムによる可視化処理を行ったり、保存期間の制御なども行いやすくなったりします。
出典：監査ログの管理｜国民のためのサイバーセキュリティサイト（総務省）
さらに、複数のサーバーのログを突き合わせて分析するには、サーバー間の時刻が合っていることが前提になります。総務省も時刻同期の重要性を指摘しています。
ログを取得する場合、各コンピュータ間でシステムの時刻を一致させておく必要があります。この時刻の同期が不適切であると、ログに記録された時刻がずれてしまい、各システム間でログを相関的に分析することが困難になります。システムの時刻を同期させる手段として、一般的にNTP（Network Time Protocol）が広く利用されています。
出典：監査ログの管理｜国民のためのサイバーセキュリティサイト（総務省）
これらを踏まえると、安全な保管のための実務は次のように整理できます。
- 収集元と別の場所に集約する: サーバー本体ではなく、独立したログ管理の仕組みに集める。Linuxサーバーはrsyslog・syslog-ngの転送設定で集約先サーバーへ送り、WindowsサーバーはWindowsイベント転送やログ管理製品のエージェントで集める。
- 改ざんを防ぐ: 書き込み後に変更できない形で保存し、ハッシュ値などで改ざんを検知できるようにする。
- 時刻を同期する: NTPで各サーバーの時刻を合わせ、ログを相関的に分析できるようにする。
- アクセスを制限しバックアップする: ログ自体にアクセスできる人を絞り、消失に備えてバックアップを取る。
また、ログには利用者が入力した個人情報が含まれることがあり、総務省も「ログは機密情報である」として取り扱いに注意を促しています。個人情報を含むログは、個人情報保護法第23条の安全管理措置の対象として適切に保護する必要があります。
出典・参考資料（2件）
【監視する】検知の仕方と手作業の限界
3つ目のステップは「監視する」です。集めて保管したログも、見て異常に気づける状態にしておかなければ、攻撃や不正の兆候を見逃してしまいます。
何を監視するか（アラートと相関分析）
監視では、あらかじめ決めた条件に合致したログを知らせる「アラート」と、複数のログを突き合わせて異常を見つける「相関分析」が基本になります。
- アラート: 「管理者アカウントで深夜にログインがあった」「認証失敗が短時間に多発した」といった条件を設定し、該当したら通知する仕組み。
- 相関分析: 単体では問題なく見えるログ同士を組み合わせ、「不審な通信の直後に大量のファイルがコピーされた」といった一連の動きから異常を見つける分析。
社内セキュリティの観点では、特権IDの普段と違う操作や、委託先による想定外のアクセスを検知できるように監視対象を設計しておくと、内部不正の早期発見につながります。
手作業でのログ監視の限界
ログの監視は、サーバーの台数が少ないうちは担当者が目視で確認することもできます。しかし、サーバーやログの種類が増えると、1日に出力されるログは膨大になり、人の目で異常を見つけ続けるのは現実的ではなくなります。
また、ログは各サーバーに分散しているため、横断的に突き合わせる相関分析を手作業で行うのは困難です。見落としや確認漏れが起きやすく、インシデントの発見が遅れる原因になります。こうした限界を補うのが、次に説明するツールです。
SIEM・NDRとは｜ログ管理との違い
監視・検知を自動化するツールとして、SIEMとNDRがあります。いずれもログ管理と関わりますが、役割が異なります。
- SIEM（Security Information and Event Management）: 各種サーバー・機器のログを集約し、相関分析やアラートで脅威を検知する仕組み。ログを「集める・保管する・監視する」を一体で担う統合ログ管理の発展形といえます。
- NDR（Network Detection and Response）: ネットワークを流れる通信（パケット）そのものを監視・分析し、侵入や不審な通信を検知する仕組み。サーバーのログに記録されない通信の中身まで追える点が特徴です。
一般的なログ管理が「サーバーが出力したログを集めて保管・監視する」のに対し、SIEMは分析・検知を自動化し、NDRは通信そのものを対象にします。どこまで手作業で行い、どこからこれらのツールに任せるかは、次の章で切り分けます。
一括ダウンロードする
自社でどう進めるか：手作業で始める範囲とツールのタイプ・選び方
ここからは、自社でサーバーログ管理を進めるための現実的な進め方を解説します。すべてを一度にツールで揃える必要はなく、手作業で始められる部分と、ツールに任せたい部分を切り分けるのが出発点です。
手作業で始められる範囲と、ツールが必要になる部分
サーバーの台数が少なく、ログの種類も限られているうちは、次の範囲は手作業（OSやアプリの標準機能）で始められます。
- 取得すべきログの決定と、OS・アプリの標準機能でのログ出力の有効化
- NTPによる時刻同期の設定
- 重要なサーバーのログを別の場所へ定期的にコピーする運用
一方、次のような段階になると、手作業では追いつかず、ツールの導入が現実的になります。
- 複数サーバーのログを横断して検索・相関分析したい
- ログの改ざん防止や長期保管を確実に行いたい
- 異常を見逃さないよう、アラートで自動的に気づける状態にしたい
ツールのタイプと選び方
サーバーログ管理に関わるツールは、何を守りたいかによってタイプが分かれます。自社の目的に近いものから検討するとよいでしょう。
- 統合ログ管理・SIEM型: 各種サーバー・機器のログを集約し、保管から検索・相関分析・アラートまでを一体で行う。サーバーログ管理の中心になるタイプです。
- NDR型: ネットワークを流れる通信そのものを記録・分析する。サーバーのログに残らない通信の中身や、エージェントを入れられない機器もカバーしたい場合に向きます。
- PC操作ログ型: サーバーではなく利用者の端末の操作を記録する。内部不正・情報漏えい対策や、特権ID・委託先作業の可視化に向きます。
選ぶ際は、取得したいログの種類に対応しているか、必要な保管期間と容量をまかなえるか、相関分析やアラートなどの監視機能が自社の運用に合うか、導入・運用のサポート体制が十分かを確認することが重要です。
統合ログ管理・SIEMをはじめ、どのタイプのどの製品が自社の目的に合うかを具体的に比較検討したい場合は、以下の記事でログ管理システムをタイプ別に整理し、代表的な製品の違いと選び方を解説しています。
タイプ別のサーバーログ管理に役立つサービスの比較
以下は、この記事で紹介するサーバーログ管理に役立つサービスの比較表です。サーバーログ管理の中心は統合ログ管理・SIEM型で、NDR型やPC操作ログ型は、サーバーログだけでは追えない通信や端末の操作を補う選択肢です。タイプの違いと対応範囲を確認してください。
| サービス名 | Network Blackbox | Eye"247" Work Smart Cloud | Logstorage | ALog |
|---|---|---|---|---|
| タイプ | NDR（ネットワーク検知・対応） | PC操作ログ | 統合ログ管理・SIEM | 統合ログ管理・SIEM |
| 対応するログ・対象 | ネットワークを流れる全パケット（通信そのもの） | PCの操作ログ（Web閲覧・ファイル操作・印刷・USB使用など） | 各種サーバー・機器のテキスト形式のログ（400種以上の収集実績） | サーバー・ファイルサーバー・AD・DB・クラウドなどのログ |
| 保管・改ざん対策 | 全パケットを分散ストレージに保存（保存期間は構成次第） | クラウドに保管（標準1年／延長オプションで3年） | 圧縮・暗号化とハッシュ値による改ざん検知 | クラウド版は1年保管＋期限超過分をAWS S3へ自動移行 |
| 監視・検知 | シグネチャ＋ユーザー行為の異常検知＋コンテンツ分析／MITRE ATT&CKベースの脅威ハンティング | 禁止ソフト起動・個人情報ファイルの検知、勤怠乖離チェック | 検索・集計・リアルタイム検知・レポート（X/SIEMで相関分析） | AIによる異常検知（件数・値・新規出現）、相関分析・アラート |
| 提供形態 | 公表なし（ミラーリング方式で導入） | クラウド（SaaS） | ソフトウェア（オンプレミス・仮想環境）＋クラウド連携 | クラウド版／オンプレミス版 |
| 料金 | 要問い合わせ | 初期費用0円＋月額400〜1,100円/台（従量制・税別） | 要問い合わせ | 要問い合わせ |
| 無料トライアル | 公表なし（デモ申請あり） | 14日間 | 約1か月（試用版） | 30日間 |
| 詳細情報 | 公式資料を見る | 公式資料を見る | 公式サイト | 公式サイト |
※2026年11月時点の各社公式情報・カタログ掲載情報による。最新の仕様・料金は各社の公式情報をご確認ください。
サーバーログ管理に役立つサービス
ここからは、サーバーログ管理に役立つサービスを紹介します。「集める→保管する→監視する」の中心を担う統合ログ管理・SIEM型に加え、通信そのものを記録するNDR型、端末の操作を記録するPC操作ログ型を、目的に応じて組み合わせられます。
サーバーログ管理は、社内のセキュリティ対策全体の一部です。アクセス管理や端末・ネットワークの対策なども含め、守る対象ごとにどのようなソリューションがあるかを広く比較検討したい方は、以下の記事もあわせてご覧ください。
社内セキュリティソリューション比較｜守る対象別のタイプ・代表サービスと選び方
社内のセキュリティを強化したいものの、端末の保護から不正アクセス対策、情報漏えいの防止まで課題が広く、何から手をつければよいか判断がつかないという声は少なくありません。テレワークやクラウド利用が定着し、社外に持ち出される端末やIDが増えたこ…
1. Network Blackbox（株式会社クワッドマイナージャパン）
Network Blackboxは、ネットワークを流れる全パケットを収集・分析するNDR（Network Detection and Response）製品です。株式会社クワッドマイナージャパンが提供し、国内では株式会社フーバーブレインが総代理店を務めています。
フルパケットキャプチャを基盤に、収集・検知・ハンティング・フォレンジック（侵入後の遡及調査）・対応の5つの機能を備えます。ミラーリング方式で導入するためサーバーへのエージェント導入が不要で、EDR（端末上の不審な挙動を検知・対応する仕組み）などのエージェントを入れられない機器の通信もカバーできます。
検知後はパケット単位で遡って調査でき、Syslog・REST APIを通じてSIEMやEDRと連携します。
サーバーが出力するイベントログそのものではなく、通信ログ（パケット）側を全量記録する点が特徴で、事後の通信調査や証跡提示に強みがあります。料金は要問い合わせです。
2. Eye”247″ Work Smart Cloud（株式会社フーバーブレイン）
株式会社フーバーブレインが提供するEye”247″ Work Smart Cloudは、PCの操作ログから「誰が・いつ・どこで・何を操作したか」を記録・可視化するクラウド型サービスです。
1分間隔での作業ログに加え、Webアクセス・ファイル操作・印刷・USB使用・禁止ソフトの起動などのログを取得し、個人情報を含むファイルの検知やIT資産管理まで行えます。PC操作時間と勤怠打刻の乖離チェックなど、労務管理に使える機能も備えます。サーバー側ではなく利用者の端末側のログを押さえることで、内部不正・情報漏えい対策や、特権ID・委託先作業の可視化に役立ちます。
料金は初期費用無料で、月額は契約台数に応じた従量制です（100台以上で1台あたり月額400円、最低5台から）。14日間の無料トライアルが用意されています。
3. Logstorage（インフォサイエンス株式会社）
インフォサイエンス株式会社のLogstorageは、2002年の提供開始から続く国産の統合ログ管理・SIEMです。各種サーバー・機器のログを集めて保管・監視する、サーバーログ管理の中心となるタイプにあたります。
Syslog・SNMP・FTP・エージェントなど複数の方式に対応し、テキスト形式で出力されるログを幅広く収集できます。保管では圧縮・暗号化に加え、ハッシュ値による改ざん検知や自動アーカイブを備え、検索・集計・リアルタイム検知・レポートで監視まで一体で行えます。クラウドサービス向けの連携パックも継続的に提供されています。
第三者調査（デロイト トーマツ ミック経済研究所調べ）の統合ログ管理ツール部門で、出荷本数ベースのシェア17年連続No.1と公表されています。「集める→保管する→監視する」の中心を担うタイプで、料金は要問い合わせ、約1か月の試用版があります。
出典・参考資料（1件）
4. ALog（株式会社網屋）
複雑なログを「いつ・誰が・どのファイルに・何をしたか」の形に変換して扱えるのが、株式会社網屋が開発・提供する国産のログ管理・SIEM「ALog」です。
Windowsサーバー・ファイルサーバー・Active Directory・データベース・クラウドサービスなど各種システムのログを自動収集し、独自の変換技術で人が読みやすい形に整えます。2026年7月提供開始の新バージョンでは、AIによる異常検知（件数・値・新規出現の変化を検知）と可視化を強化しました。
クラウド版は1年間のログ保管が基本料金に含まれ、保管期限を過ぎたログはAWSのS3へ自動移行して長期保管コストを抑えられます。
契約数は6,500以上と公表されています。ファイルサーバーやActive Directoryのログを「誰が・どのファイルに・何をしたか」の形に整えて追える点が特徴です。料金は要問い合わせで、30日間の無料トライアルがあります。
出典・参考資料（1件）
まとめ
セキュリティのためのサーバーログ管理は、「集める→保管する→監視する」の3ステップで考えると全体像をつかめます。それぞれで押さえるべき要点は次のとおりです。
- 集める: 認証・アクセス・ファイル操作・通信・特権IDの操作など、検知したい脅威から逆算して取得対象を決める。
- 保管する: 日本に一律の保存義務はないため、関連する法令・業界基準を参照点に自社のリスクで期間を決め、収集元と別の場所に改ざん防止・時刻同期を施して保管する。
- 監視する: アラートと相関分析で異常に気づける状態にする。手作業で限界が来たら、統合ログ管理・SIEM・NDR・PC操作ログ型のツールで補う。
まずは取得すべきログの決定と時刻同期など手作業で始められる部分から着手し、横断的な分析や改ざん防止、監視の自動化が必要になった段階で、自社の目的に合うツールを検討してください。
一括ダウンロードする
よくある質問（FAQ）
Q. サーバーログ管理とは何ですか？
A. サーバーログ管理とは、サーバーが出力するログを計画的に「集める・保管する・監視する」ことで、不正アクセスや内部不正、障害の兆候を把握できる状態をつくる取り組みです。ログをただ出力させているだけでは役に立たず、どのログを取得するかを決めて収集し、改ざん防止・時刻同期を施して別の場所に保管し、アラートや相関分析で異常を検知する、という一連の流れを設計して初めてセキュリティ対策として機能します。
Q. サーバーログとアクセスログは同じものですか？
A. サーバーログはサーバーが出力するログ全般を指す総称で、アクセスログはその中の一種類です。サーバーログには、アクセスログのほかに認証ログ、ファイル操作ログ、システム（イベント）ログ、通信ログ、データベース・アプリケーションログ、特権IDの操作ログなどが含まれます。アクセスログだけを取得して安心せず、検知したい脅威から逆算して必要な種類を揃えることが重要です。
Q. サーバーログはどのくらいの期間保管すべきですか？
A. サーバーログの保管期間は、日本に「一律で何年保存しなさい」という一般的な法令はなく、自社のリスクと、関連する法令・業界基準を参照点に決めます。総務省も、保存期間は組織が扱うデータの性質やシステムの処理能力などに大きく関係するとしています。
参照点になる主な基準には、労働基準法第109条（条文5年・附則の経過措置で当分の間3年）や、カード会員データを扱う事業者向けのPCI DSS要件10.5.1（監査ログを12か月以上保持）があります。不正アクセス行為の公訴時効（3年）も、どこまで遡れるログを残すかの目安になります。自社に適用されるものを確認し、調査で遡りたい期間も踏まえて設計してください。
出典・参考資料（3件）
Q. OS標準のログ機能だけでサーバーログ管理は十分ですか？
A. OSやアプリの標準機能だけでは不十分になりやすく、サーバー台数が増えるほど集約と監視の仕組みが必要です。WindowsのイベントログやLinuxのsyslogでも認証やシステムの記録は取得できますが、各サーバーに分散したままでは横断的な調査や相関分析、改ざん対策が難しくなります。横断分析や改ざん防止・長期保管を確実にしたい段階では、統合ログ管理やSIEMが現実的です。
Q. サーバーログの取得（収集）と監視は何が違いますか？
A. 取得（収集）はログを集めて保管する工程、監視は集めたログを確認・分析して異常の兆候を検知する工程です。両方そろって初めてセキュリティ対策になります。取得・保管していても、見て異常に気づける状態でなければ兆候を見逃します。監視では、条件に合致したログを知らせる「アラート」と、複数のログを突き合わせて不審な動きを見つける「相関分析」が基本です。
Q. 中小企業でもサーバーログ管理は運用できますか？
A. 専任のセキュリティ担当がいない中小企業でも、手作業で始められる範囲から着手すれば運用できます。まずは取得すべきログの決定、OS・アプリ標準機能でのログ出力、NTPによる時刻同期、重要なサーバーのログを別の場所へ定期コピーする運用から始めます。横断分析・改ざん防止・長期保管・自動検知が必要になった段階でツールを検討すると、無理なく段階的に進められます。
Q. サーバーログに個人情報が含まれる場合、どう扱えばよいですか？
A. 個人情報を含むログは、個人情報保護法第23条の安全管理措置の対象として、アクセス制限・暗号化・改ざん防止などを施して保護する必要があります。総務省も「ログは機密情報である」として取り扱いに注意を促しています。アクセスできる人を絞り、収集元とは別の安全な場所に保管することで、漏えいリスクを下げられます。
出典・参考資料（2件）
Q. クラウドサービスを利用している場合もサーバーログ管理は必要ですか？
A. クラウドサービスを利用している場合も、そのサービスが出力するアクセスログや操作ログは管理の対象になります。不正アクセスや内部不正、情報の持ち出しを追うには、クラウド上の認証・操作・アクセスの記録も取得・保管・監視が必要です。統合ログ管理・SIEM型には、クラウドのログを自社サーバーのログと一元的に分析できるものもあります。
サーバーログ管理に役立つサービスの料金・資料を一括チェック
MCB FinTechカタログでは、統合ログ管理・SIEM・NDRなどサーバーログ管理に役立つサービスの最新資料を無料で一括請求できます。対応するログの種類・保管期間・改ざん防止・監視機能などを比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
