×
何を監視するのか?
ログの管理は、まず何を監視するのかを決定することから始まります。
何を監視して、どんなログが必要なのかも決定せず、無計画にログ管理を進めることは結果的に時間と労力の無駄になりかねません。
(1) 管理対象の洗い出し
管理すべきログは、多種多様で、取得目的によってログのタイプも異なりますが、まずはIT部門で管理対象となりそうな機器や、それに導入されているアプリなど、IT関連のハードウェア、ソフトウェアをすべて洗い出し調査してみることが必要です。つまり、ログ管理が必要かもしれない対象物の現状把握をします。
もちろん、明らかに監視が不必要なものに時間をかけることは避けた方がいいですが、一度は、すべてを包括的に確認しておかないと、何か問題があってから、ログがないことが判明しても後からではリカバリーができないリスクも想定されます。
環境の規模や、ヒューマンリソースの問題で、管理対象の洗い出しをする余裕がない場合は、事業継続の観点より、本当に必要と思われる業務に限定して管理対象を選びだす方法もありますが、それは、洗い出す対象の範囲を当初は少なくするということであって、管理対象の選別を行うことは進め方として有効であり、その場合は運用に乗せてからでも対象範囲がそれだけでよいのかどうか適宜見直しが必要となります。
ログ管理対象物の洗い出しには、ハードウェアやソフトウェアのIT資産管理台帳があると便利です。
というのも、ITに関わる機器や使用するアプリケーションなど、すべての要素に関する情報が一元的に把握できなければ、障害時などに必要となるログの取得漏れが生じ、原因究明や対処ができないという最悪の事態も起こりえるからです。
台帳管理には、IT資産管理のツールなどがあると、洗い出しがし易くなります。
洗い出した機器やソフトウェアなどのIT資産について、使用者や管理者、使用目的などが台帳管理できていれば、ログ管理対象かどうかの選定が効率的に行なえます。
洗い出す対象は、業務やビジネスに必要なIT関連のハードウェアやソフトウェアについて、マシン室はもちろん、オフィスや、クラウド、企業の各拠点、テレワークで持ちだすIT機器なども当然含まれます。
IT関連の資産が洗い出せれば、その中に、監視すべき対象があります。
最初の仕分け作業では、まず、大雑把でいいので、監視が必要と思われるもの、つまりログ取得すべき対象のみを選別しておく方が、個々のログ管理方法を検討し易くなります。
やり方はいろいろありますが、IT資産台帳等をもとに、洗い出したすべてのIT関連機器やソフトウェアから、ログを取得すべき対象物をピックアップします。たとえば、IT資産管理台帳がエクセルファイル等で、編集できる場合、ログ取得が必要なさそうな対象のレコードは、どんどん削除または、別ファイルに移動してしまうと効率的です。
(2) 監視すべき内容の明確化
ログ管理を効率的に実施するためには、ログ管理が必要と思われる対象物に対して、何を監視し、何を監視しないかを明確にすることが重要です。
システムの中には、重要な業務に直結しているためプロセスの実行記録が必須のものから、いつ使用されてもリスクがないものまであり、ログ取得対象のすべてが、ログによる監視が必要というわけではありません。
ここで意図するログは、各システムについて、タイムスタンプがある時系列に記録された情報です。多くのログを監視対象にすれば、それだけ収集や分析にも時間がかかり、保管スペースにも影響があります。
とはいえ、必要とするログを収集しておかなければ、問題分析も、監査対応にも支障が生じます。
この段階では、すでにログが取得できる仕組みができているかどうかは関係ありません。俯瞰的にシステム全体を通して見て、個別にどのような監視が必要かどうかを判断して監視対象を選別します。
監視が必要だと判断した対象物には、処理結果の情報が欲しいのか、使用された時の操作内容が欲しいのかなど、なぜ、何を監視したいのかを明確にします。それによって、操作ログやアクセスログなど、場合によっては同一の対象物についても複数の監視目的に応じたログが必要になります。
この場合、監視対象にも拘わらず、諸事情により当初はログ取得をしないという判断が出る場合もありますが、監視が必要な理由、必要でない理由を明確にすることで、他とのバランスでそれぞれの時点でログ取得の可否を判断するためにも有効な作業となります。
同様に、ログを取得すべきか迷うようなケースは、とりあえず取得すべき対象として残し、その時の判断理由を残しておくと、後になって見直しが入った時に役に立ちます。
(3) ログの重要度確認
監視すべきと判断された対象となる機器やソフトウェアについて、それぞれの監視目的ごとに重要度を確認します。
その際、障害対応やシステム監査上において絶対に必要と判断される必須ログは、重要度が高く、その一方、業務内容、使用目的などの重要度が低くなるにつれ、監視対象ごとにログの重要度は低くなります。
この段階では、ログの取得をしているかどうかに関わらず、すべての監視対象の目的の重要度を確認します。その重要度で、ログ取得が本当に必要なのか、可能なら取得しておきたいぐらいレベルなのかなどが分かるようにします。
この時、ログ取得後に保管だけしておいて必要になった時に確認できればよいレベルなのか、それとも、他のログと統合して管理者による一元管理が必要なのか、もわかるように重要度をクラス分けできると、ログ管理対象の選別がし易くなります。そして、当然ながら、重要度があまりに低いと、この段階で、対象外に変更されるケースもあります。
(4) ログ取得状況の確認
重要度が高い監視目的から、ログの取得すべき項目、取得間隔、ログのデータ量など必要とされるログの詳細を確認し、その内容が十分満足できる状態で取得できているかどうか、それぞれのログの取得状況を把握します。
該当システムが標準的にログを出力している場合、デフォルト設定のままで使用しているユーザが多いです。
それが適正である場合が多いのですが、多くのシステムが出力するログは、どのログをどの間隔で取得するかなど、比較的柔軟に取得内容を指定できるようになっているため、環境に合わせた取得内容の設定を見直すことも必要です。
ただ、重要度は高く、監視が必要なのにも拘わらず、システムが出力する標準的なログだけでは欲しい情報が取得できていない場合もあり、こうした場合は、ログを収集する仕組みを新たに作成するか、ログ管理のツールなどで別のログ取得方法を組み入れる必要があります。
パッケージソフトのログ管理ツールには、システムの監査や、トラブル対応上必要だと思われるログは、多くの場合簡単な設定で標準的に出力できるように提供されています。
但し、企業独自のアプリケーションは、開発時に、必要なログが記録されるようプロセスのフローに組み込んでもらうことが必須です。
重要度が高く、管理者による一元管理が必要なログについては、各機器やソフトウェアで出力されたログを一ヵ所に集めるためのログ収集方法も、ログ取得方法を決定する時に意識しておく方がよいです。
これは、管理者の権限によって、取得されたログにアクセスできない場合もあるため、ログ保管場所の権限等にも注意が必要だからです。
重要ではあるものの、万が一必要な場合のみ確認できればよいという程度のログは、中央管理対象外とし、その機器やソフトウェアの使用者が把握している場所に、ログが出力されていればよいです。但し、ログにより、ディスク容量が足らなくなるといけないので、ログの保管期限の設定、ローテンションによるログの上書きの設定は必要です。
監視が必須ではなくログ取得をしておくことが望ましいレベルの重要度のログは、ログ取得すべきかどうかは、システムへのCPU負荷、保管のためのハードディスクの空状況など、リソースや運用負荷などの観点で、ログ取得すべきかどうかを判断します。
つまり、監視が必要だと思われる対象物であっても、政策的には必ずしもログ管理対象にしなくてよいということです。
たとえば、クラウド上のアプリなどは、業者に任せて管理対象から外すものがあったとしても、特段問題はない場合が多いですし、テスト環境なども、運用管理者に負荷を与えないようにするために、管理対象外にしてよいと思われます。
ログ取得対象から外す理由は、コンプライアンスの観点から、プライバシー保護のために特定のログをあえて取得しない場合もあります。
すべてのログ取得対象目的の取得状況が確認できた段階で、ログ取得が不要と思われるものは、暫定的にでもすべて対象から外してしまうことが望ましいです。
ログの取得方法
監視目的の重要度が高い対象物は、継続的な運用を効率的に行うためにも、できる限り自動的にログ取得できる仕組みを、分析が実施しやすい形で構築することがポイントになります。
そして、重要度の低い対象物は、負荷やリソースなどを考慮して目的に応じて、適切なログ取得方法を選択します。
(1) アプリケーションのログ
PCやサーバは、多くのアプリケーションで動いています。
ここではアプリケーションとは、コンピュータに仕事をさせるためにOS上で動作するソフトウェアを指すため、正式には「アプリケーションソフトウェア」のことです。
アプリケーションは、プログラム開発されたソフトウェアなので、膨大な種類が存在し、それぞれの目的に応じて、ログが生成されます。
その多くは、いつ、誰が、どこで、何を、なぜ、どのように行ったのか、その動きを履歴としてログに残します。それによって、そのアプリケーションは正常に実行されたのか、あるいは異常終了したのかとか、その他サービスの利用状況を把握するなどの目的で、様々なログを利用します。
アプリケーションは、メールや、データベースなどを中心に、パッケージソフトや、オープンソース、独自開発された業務アプリなど多種多様です。単一目的ではなく、ERPやCRMなどのように、統合的に業務支援を行うアプリケーションもあります。
多くの商用アプリなどは、監査も考慮された内容で、標準的なログの取得設定だけで通常は必要十分な内容が含まれておりますが、目的とする必要と考えていた情報が取得できていない場合は、システムによっては、どのログをどの程度の頻度で取得するのかなどを個別に設定できるので、必要な情報のログの出力を許可する設定が別途必要です。
但し、無計画に取得できるログをすべて設定してしまっては、膨大な量となってしまうため注意が必要です。
たとえば、エラーログなどは、ロギングするエラーの重要度のレベルを限定したり、開発検証時のみ設定しておけば良い場合などがあります。
本番で使用する際も、障害時などは、メモリーダンプがないとメーカーに調査依頼できないなど、障害対応に必要なログは、スタックトレース等、運用に合わせ設定が必要で、場合によっては、障害時対応のみ、マニュアル設定するケースもあります。
こうしたチューニングは、特殊な環境下では必須となるため、監視の重要度によっては、ログ出力内容のチューニングに時間をかけることも必要でしょう。
アプリケーションによっては、自らログを出力するものと、導入先のOSの機能を利用してログを残すものがあります。
クライアントの要求に対して、どのようにサーバが応答したかや、認証の成功や失敗の記録、トランザクションの件数やサイズなど、そのアプリケーション独自の内容をログとして残すことにより、セキュリティの確保や、迅速な障害対応が可能になります。
広い意味では、セキュリティソフトも、アプリケーションです。多くのセキュリティソフトで、かなり詳細なログ取得設定が可能です。
設定により、どのログ項目をどの間隔で取得するかなど、比較的柔軟にログの取得内容を指定できるようになっているため、ログ対象によっては、環境に合わせた適切な取得方法の設定が必要です。
(2) オペレーティングシステムのログ
クライアントデバイスや、サーバ、ルータなどのネットワーク機器には、それを動かすためのオペレーティングシステム（OS)が存在し、OSは主にセキュリティなどの目的で、多くのログを生成します。
OS内部の動作を記録するシステムイベントや、セキュリティを目的にする監査記録などがあります。
Windowsのイベントログ、Linuxのsyslogなどがこれにあたり、自分でログ出力のためのプログラムを作成しなくても、OSが取得してくれるログは多いです。
OSのログには、システム上で動作するセキュリティソフトや、アプリケーションなどの情報が含まれることがあり、それが監視対象物の場合、設定可能なログをすべて取得してしまうと、容量が膨大になってしまったり、種類や項目が多すぎて分析が難しくなってしまうケースがあります。
通常であれば、失敗イベントや、重要な成功イベントはログとして記録されますが、管理者は記録されるイベントの種類を指定できるようになっています。
OSのログは、セキュリティソフトによって発見された脅威やリスクに対して、その調査を助けるために使用されることがあります。そうした意図を考慮して、どのログを取得するかの設定も必要です。
(3) ログ管理ツールで取得するログ
対象システム側で、標準的に取得できるログでは、欲しい情報にが不足している場合でも、ログ管理用のツールによって取得できるケースがあります。
また、たとえばWindowsのイベントログ自体はテキストエディタ等で確認することができないバイナリで保存されているのため、Windows標準の「イベント ビューアー」を使わずに複数のPCのWindowsログの一元管理をしたい場合など、ログ管理ツールによりログ収集することが有効な場合があります。
ログ管理ツールで、ログを収集する場合、Windows環境に特化したツールなど、環境と使用目的を限定しているツールが多いため、多種の複数ログを一元的に集中管理する目的であれば、別途追加で統合ログ管理ツールを導入することも有効です。管理目的に応じて、ログ管理ツールも、複数導入されることは決して珍しくないです。
ログ管理ツールのログ取得には、取得のために対象機器にエージェントの導入が必要な場合と、エージェントレスの場合があります。
どちらの取得方法であっても、元となるログデータは、対象機器やアプリケーションが生成しているので、ログ管理用のサーバ側だけでなく、ログ取得対象側にも設定が必要な場合があります。
ログ管理ツールの多くは、ログフォーマットの変換機能を備えているため、syslogなどの標準的なフォーマットでないデータについても、アプリケーションが作成するcsvやテキストデータを基に、分析可能なログとして保管することが可能な場合もあります。
(4) ユーザが取得するログ
システム開発によって作成される業務アプリケーションなどは、ユーザが責任を持ってログを取得する必要があります。
アプリケーション側の機能では必要な情報をログとして取得できない場合や、新規の業務アプリケーションを開発する場合などでは、新たにログ取得のための仕組みづくりが必要となりますが、メジャーなシステムや業務アプリ、セキュリティソフトなどは、自身でログ取得の仕組みを作成してしまうと、バージョンアップでログフォーマットが変更された場合などでメンテナンスが問題になります。この問題を軽減するためにも、ログ管理専用ツールなどで対応できないかを調べ検討すると良いでしょう。
独自開発で作成される業務アプリケーションなどは、ジョブスケジューラーやシステムから受け取るジョブの実行ログや、エラーログ等とは別に、アプリケーションにロギング機能をプログラム開発でコーディングして加えることが一般的です。
作成される環境や使用するプログラム開発ツール、プログラム言語によって、エラーログ等の出力設定ができますが、場合によっては、各プロセスの実行結果の履歴やエラーなどが出力されるように、ロジックへ組み込みます。
処理が正常終了できない時に、適宜処理ステップごとに中間ワークデータの内容や、件数をログとして残すことによって、途中で異常終了しても、状況把握や原因追及、対象方法の検討に大いに役立ちます。逆をいえば、プロセスの進行状況を、障害時まで想定して必要な情報をロギングすることが有効です。
そのためには、システムの詳細設計の段階で、エラー処理などにログ出力を組み入れることが肝心です。
その際、もちろん任意ですが、正常終了した場合のメッセージと、異常終了した場合のメッセージの内容は変えておくことになります。
メッセージは、ログ管理ツールが、無用なエラーをトリガーに通知してしまわないよう、エラーコードを体系的に標準化しておくほうがよいです。
システムで、自動的にデータとしてログを出力できない場合は、手書きなどの非デジタルデータの記録もログとして重要になる場合があります。その際、キーボード入力、あるいはスキャナー等でその記録をデータとして取り込む仕組みができれば、分析処理が楽になります。
セキュリティソフトのログ
多くの組織でオンプレ、クラウドを問わず、様々なセキュリティソフトが使用されています。
強固なセキュリティ対策を実施するためには、そのセキュリティログを取得して、活用することが必須です。
(1) ウイルス対策
シグネチャの更新や、スキャン実施状況などももちろんログとして重要です。
OSのメーカー以外でも、多数の
(2) 不正アクセス対策
定期的に稼働するソフトがほとんどなので、ログもバッチ処理で生成されるものが多いです。
ルータや、
(3) 脆弱性対策
脆弱性診断や、パッチ管理ソフトウェアは、脆弱性の内容や、パッチの適用履歴などをログとして記録しますが、常にロギングするものではないため、バッチ処理で大量なログを生成することを前提に、運用に即した取得方法の設定が必要です。
(4) 認証管理
クライアントデバイス、
誰が、いつ、何に対して認証要求をしたのかは、ログとしてかなり重要です。
ログのセキュリティ
取得したログが、万が一にも削除されたり、改ざんされてしまうようなことになっては、証跡として機能しないばかりか、原因究明や、トラブル対処にも支障をきたします。
ログデータそのものについて、強固なセキュリティを確保することが重要です。
(1) ログのセキュリティポリシー
記録されたログに対するセキュリティ対策は、監視対象の重要度に連動して、ログの種類に応じて対応策が変わります。
そのため、ログ全体に対する基本的なセキュリティポリシーとは別に、重要なログについては、個別にセキュリティポリシーを定義しておくことが必要です。
機密性、完全性、可用性を維持するために組織で定められた情報セキュリティポリシーに組み入れ、ログが改ざんされない状態で保全されることや、個々に保管期間を設定するなどをセキュリティポリシーとして定めます。
ログによっては、不正アクセスから守る処置や、バックアップや冗長化が必要なものもあります。
他の情報資産のポリシーとの違いは、ログのライフサイクルを考慮して、ログの取得目的が満たされるポリシー作成が必要です。
万が一の漏洩に備え、どの部分で暗号化しておくかも重要です。
コンプライアンスの問題で、個人情報などが入ってしまいそうなログは、取得内容についてもポリシーに明記しておくべきです。
(2) 改ざんされない仕組み
標的型のサイバー攻撃を受けた場合、攻撃者は自分の動きを分からないようにするため、ログの改ざんや消去を実施してくる場合があります。
オペレーションミスも含め、不正にログを改ざんができないようにする仕組みがないと、ログの信頼性は失われ、エビデンスとしての価値を失ってしまいます。
ファイルの完全性の保護手法として，ヒステリシス署名を用いたものや、インフラ側でライトワンスのディスクを使うなど、手法は様々ですが、マルウェアはカーネルレベルでの改変を行ってきますので、かなり高度なセキュリティ対策が必要です。
たとえば、syslogのケースでは、カーネル内でログを生成して、カーネルログバッファに蓄積されるまでの間、カーネルログデーモンからsyslogへログが送られsyslogがファイルへ書き出すまで、そしてファイルへ書き出された後のどのタイミングでも、改ざんされる危険があり、それを検知し、防止する必要があります。
既存のsyslog管理では、ルートキットなどによりカーネルが攻撃された場合、どのタイミングでログを攻撃されても対処できません。
とはいえ、完璧な対処を目指すと、オーバーヘッドが気になるため、ログの重要度に応じて、どんな攻撃をしてくるかのあらゆる可能性を想定して、対応策を考え対処するのが現実的です。
(3) アクセス権限
重要なログについては、アクセス制限を設けることが必要です。
逆に現場のクライアントデバイスなど、必要に応じでユーザにもイベントログなどを閲覧できるように、読み取り権限を許可する設定が必要な場合もあります。
通常は、管理者しか追加、変更、消去ができないように、ログ出力先のフォルダに対して、アクセス権を設定したり、ログ出力先が、データベースになっているような商用アプリなどは、そのデータベースに個別に権限設定をします。
この時、アクセス権の管理基準や、管理者が明確になっていないと、管理者のIDを不正使用されるリスクが高まります。
管理者IDを誰が使用したかのログが残るよう特権ID管理のツールなどを使用し、管理者のID管理を徹底することも重要です。
また、アクセス権の管理を的確に行なわないと、運用管理者が、ログを見るために他部門の機密データにアクセスできてまうようなリスクが内在するリスクも考えられます。
(4) セキュアなログ転送
ログ管理ツールなどを活用して、監視すべき対象で重要なログをログ管理用サーバへ転送し、ログを一元管理することは、セキュリティ上でも有効な手段です。
重要なログデータを一元管理できれば、運用もしやすく、セキュリティ対策や権限管理も楽になります。
その際、ログ出力元の対象機器から、ログ管理システムまでのデータの転送を保護することが、重要です。個々のログデータについて、ログ転送時にどのように機密性、完全性、可用性を保つ仕組みがとれるかを対策しなければいけませんが、これは他の重要データ転送時と同様な仕組みで検討し、転送するデータ量や頻度などを考慮することが必要です。
具体的には、ネットワーク上を暗号化して通信し、データの送信、受信が正確に行なわれたことを検証できるようなデータ転送の仕組みです。
ログの保管
管理すべきログは、電子データにしておくと分析がしやすいです。
多くのシステムでは、電子データでログを出力しますが、それを蓄積し保管するためにも、期間や保存方法など考慮すべき点が多くあります。
(1) ログの保管期間
ログの保管期間を決定するのは容易ではないです。
業務内容によっても、ログの性質によっても、個々のログで変わってきます。
保管期間を長くすれば、当然、漏れは少なくなりますが、それだけ保管デバイスの容量も必要であるし、分析範囲が多くなり処理時間にも影響がでます。
ポイントは、重要なログは、監査証跡として保管が必要な期間をどのように設定するかになります。
たとえば、不正アクセス禁止法の時効は、3年間なので、それ以上は消去して問題ないということなのですが、ログによっては、内部統制関連文書や、有価証券報告書等は5年なので、その関連業務は5年間は保存しておいた方が安心です。
そして、PCIDSSでは、監査証跡のログは少なくとも1年間は保持し、少なくとも3ヵ月はすぐに分析できる状態にしておくことが必要です。内閣サイバーセキュリティセンター(NISC)も、サイバー攻撃対応のためログの保管期間として1年以上を推奨しています。
こうしたことから、保管期間の設定は、ログ毎に基準を作り、分析し易い状態からの保管と、アーカイブした状態での長期保管を分けて管理した方が費用的には効果的です。
まずは、その企業の監督官庁が基準としているガイドライン等を確認の上、ログの重要度や目的に応じて、ログの保管期間を決定することが必要です。
たとえば、セキュリティ関連ログの一般的なパターンとしては、
■ サーバの内部ストレージ 90日
■ アーカイブ用ストレージ 3年間
ここで、クリティカルと認められるログは、アーカイブ5年保存としたり、そうでもないものは、内部ストレージを30日して、アーカイブを1年保存するような設定をします。
(2) ログの容量見積
ログ保管期間の方針が決まれば、それぞれのログの保管する容量を見積もります。
見積もる目的は、保管デバイスのスペースの確保以外にも、ログのローテーションの設定や、バックアップ時間に合わせた運用方法を決定する必要があるからです。
基本的にはログの1レコードのサイズから、おおよそのログの容量が見積もれますが、ログが固定長とは限らず、可変長であったり、取得する条件が定期的でなく、エラー時など何かトリガーに連動している場合など、ログの種類によっては簡単に見積もることができません。
このため、暫定的なログの量を推測し、ログ取得開始後に定期的に容量の計測を継続して蓄積し、ある程度経験値が得られた後に統計的なデータを基に、容量を確定していくことになります。
これにより、確保すべきログ保管のためのデバイスのスペースは、ログ取得実施後に適宜見直されることになります。よって、最初の見積もりは、ログスペースが容量オーバーとならないように余裕を持った容量の見積りが必要となります。
(3) 保管ストレージデバイスの選定
ログを取得すれば、それを保管するストレージデバイスが必要となります。
近年では、ハードディスクの高密度化と低価格化により、ノートパソコンでさえ、500GBを超える容量のハードディスクが搭載されているケースが多くなったため、比較的ログのリソース確保がシビヤな問題ではなくなってきました。
例えば、サーバで運用する業務のログなど、一昔前であれば、ハードディスクにあるログデータは、テープやDVDなどのリムーバルデバイスに保管するのが一般的でしたが、ハードディスクの低価格化により、共有ファイルサーバで十分保管できるケースも増えてきました。共有サーバにあれば、権限設定によって、許可された者が、オンラインで必要な時にいつでも簡単にログを参照できます。
但し、ハードディスクは故障の耐性の問題もあり、フォルダに対する権限設定だけであれば、ログの破損や消滅のリスクが心配です。それに対し、リムーバルデバイスであれば、オフラインのため、リムーバルデバイスの所在管理をしっかりしておけば、ログ改ざん等リスクがかなり軽減されます。たとえば、DVD-RやBD-Rのように、1回しか記録できない形での保管をしておけばなお安心です。
ハードディスクでオンランの場合でも、NASのメーカーなどが、ハードディスクのシステムとして書き換え不能な機能を提供している場合もあります。
これは、NASがファイルサーバとして、サーバ内に先にその機能を組み込んでいるため、ユーザ側で改ざん防止のためのソフトウェアの導入や管理を軽減することが可能になります。オンラインであるため、障害時など急なログ分析にも対応でき、費用対効果が合えば運用は楽になります。
ログの保管期間は、ローテンションの設定で十分考慮する必要があります。運用ポリシーをどのように定めるかによりますが、中央で集中管理するログの保存期間とは別に、対象物側でもログを残し、一定期間のログ保管期間を定める場合は、ローテーションによって削除されるタイミングを考慮しなければいけません。
一般的にローテーションは、例えば1日ごとや、1週間ごとのように、設定するスケジュールによって、書き出し先のログファイルをスイッチしていきます。よって、保管期限が過ぎたログファイルから削除している設定にすればよいのですが、中には蓄積されたログの量があるサイズに達したときに実行されるケースもあるため、その際は保管期間内のログが削除されないように運用設計が必要になります。
ローテーションのタイミングで、定期的に圧縮して別のデバイスへアーカイブすることで、ログの保管期間を守る方法は現実的です。
ログの保管期間によって保存場所のティアに分けて検討する方法もあります。
■ オンライン --- ハードディスク、メモリーディスク等
■ ニアライン --- 低価格のハードディスク、テープライブラリー、光ディスクライブラリー等
■ オフライン --- テープ、光ディスク（ブルーレイ、DVD等）
ログの種類によって重要度が変わるため、予算が許す限り初期のログ出力は、高性能で信頼性の高いハードディスクでオンライン接続し、アーカイブ後は低速で安いストレージで保管するイメージです。
オンラインは、内部ストレージや、SANなどの外部専用ストレージで、高速でログを保管できるストレージを採用します。
ニアラインは、オンラインとオフラインの中間に位置するもので、安価なハードディスクや、テープ、光ディスクのライブラリーなどを使用して、アクセスのパフォーマンスが遅くてもオンラインで保管したい場合が該当します。
オフラインは、安価で大容量のアーカイブができるLTOテープなどを使用して、保管後のメディアを切り離して移動できるので、災害対策目的の遠隔地など別場所での長期保管に向きます。
(4) ログの圧縮・暗号化
長期保管用などログをアーカイブする場合、ログファイルの圧縮を行います。
単純には、zip圧縮などが多いですが、セキュリティのため暗号化して保存することがお勧めです。
どんな圧縮や暗号技術を使用するかは、汎用的なものでなければ、いざというときに解凍方法が分からず使用できないようではリスクとなるため、使用するログ管理ツールに搭載されている圧縮・暗号の方式に依存する方が運用が楽で安心です。
ローテーションの仕組みによっては、ローテーションによって既に書き込みが終わっているファイルを圧縮する設定ができたり、スクリプトを組み込むことができる場合があります。
ログの機密性、完全性を保護するためのアーカイブポリシーを明確にし、圧縮や暗号化によって安心して運用できる仕組みが必要です。
ログの集約
管理対象のログは、目的によっては、他のログと集約して一元管理すべきものがあります。障害時の分析で、複数ログの関連を調査する目的であったり、ローカルにある機器のログを中央で一括して集計したりする場合などに、ログの集約作業が必要です。
この時、ログを集約する際に、集めた異なる種類のログについて、前提条件としてタイムスタンプのズレがない環境にしておくことが必要です。具体的には、NTPサーバ（Network Time Protocol server）等を使用して各システムの時刻同期を行うことを推奨します。
(1) 安全なログ転送
ログとして生成されたデータを、集約するためにログの管理用サーバへ転送する際には、セキュリティの確保が重要です。
暗号化はもちろん、転送時のデータの欠落等が生じない対策が必要です。
遠距離の場合、VPN回線等があれば安心ですが、環境によっては、通常のインターネット回線に頼らざるおえないケースもあります。
こうした場合、暗号化通信可能なファイル転送ソフトや、通信傍受を防ぐセキュリティツールを採用することが有効です。
(2) ログ収集のタイミング
ログ生成のタイミングと、集約のためのログを収集するタイミングは、ログ毎に違います。
ログ生成時にログの書込み先を集約しているファイルサーバに直接指定しておく場合もありますが、通常は、それぞれの該当するシステム内に溜まったログを、一定期間で別のログ管理用サーバへコピーして転送します。
これにより、ローテーション期間が過ぎても、ログ管理用サーバにはログが蓄積され、該当システム内のログは古いものから上書きされ消えていきます。
よって、ローテーションのタイミングなどで保管期間内にコピーし、転送すればよいのですが、どのタイミングで収集するかは、中央での障害時対応などのログ分析の必要性を考えると可能な限り、緊急リカバリーを要するような重要なログほど転送する間隔は短い方が望ましいです。
とはいえ、ログの量によっては、該当システムやネットワークに負荷を与える影響があるため、そんなに緊急性を求められない通常のログであれば、転送間隔を長めにして、場合によっては、ローテーションも1日1回として、ネットワークの負荷が少ない夜間に1日1回の転送で十分な場合も多いです。
中央で集中管理すべき重要なログについては、こうした転送のタイミングも、ログ取得のポリシーに組み込む必要があります。
(3) ログのフィルタリング
中央管理へログの収集のためのデータ転送時には、同じ内容のレコードをそのまま送る場合もありますが、通常各ログの構文解析を行います。
その際、ここでも、中央管理としてログ分析に必要ない項目については、フィルタ処理を実施して除外し、転送時間や中央での管理の効率化を図ります。
つまり、ここでの意味は、該当システム上に出力され保管されているログの取得項目は、必ずしもすべて転送対象にする必要はなく、可能な限り中央でのログ分析等に不要なデータ項目は構文解析後の編集により削除して、必要最小限にコンパクトなデータ量にすることを考慮すべきだということです。
これは、スペースに余裕があれば、いざというときのために、関係しそうな項目はすべてログ取得しておいて、普段の管理に必要な項目は転送時に選別することが有効だということです。
(4) ログのフォーマット変換
転送時には、フィルタリングによる項目の取捨選択の他に、ログのフォーマット変換を行うケースもあります。
これは、ログを集中管理するときに、ログの種類がバラバラでは関連分析等を行うのが難しいからです。
転送時の構文解析を行う際に、ログ項目のフィルタ処理に加えて、分析し易いフォーマット変換のロジックを加え実行することができれば、１つの実行プログラムで処理できるので当然ながら効率的です。
但し、環境によっては、この変換作業にも少なからず負荷がかかるため、中央に集めてログデータを受信してから、ログ管理用のサーバでフォーマット変換を行うケースも多いです。その際には、当然正規化の作業も組み入れます。
(5) ログ管理ツールの選択
ログを中央に集め、集中管理する手法は、手作りで仕組みを作るのはあまり得策ではありません。
なぜなら、広範囲のログの知識や経験が必要なため、作成できても別の担当者に変わった場合の維持などがたいへんだからです。
ログの集約というテーマだけみても、統合ログ管理ができるツールを採用した方が、必要とされる機能がすでに備わっているため、ログ転送の仕組みを構築する上で、費用や作業負荷などを比較しても圧倒的に有利です。
統合ログ管理のツールの選定には、導入・設定のし易さ、運用のし易さ、拡張性、信頼性、堅牢であることなどを考慮して、導入先の環境に合わせてベストな選択をすることがポイントとなります。