今では企業でもITスキルを習得して業務を遂行することが増えています。効率的に仕事をするためにはIT技術を駆使することが大事ですが、同時にセキュリティの強化も行わなくては情報漏洩してしまい会社の信用を損なうこともあります。
今では、サイバー攻撃なども危険を察知する必要があるので、セキュリティ対策も様々行われています。いろいろなセキュリティ対策の中でも注目されているのは監査ログです。ただ、監査ログについ詳しく知らない人もいるでしょう。監査ログについて内容を解説していきます。
監査ログとはどのような対策?
結論から言うと監査ログはデータベースに対するアクセスの記録のことです。データベースの記録を残しておくことで「誰がどんなやり方で処理をしたのか」「どこからアクセスをして結果どうなったのか」と言う点を確認することができます。
会社のデータベースに知らない第三者が不正ログインして情報を抜き取ろうとしても、監査ログに記録が残れば、情報漏洩のリスクを極力軽減させることが可能です。また、監査ログを定期的に監視しておけば誰が行ったのかを追跡することができ、犯人を捕まえることもでき、セキュリティのハッキング被害なども防止することができます。
会社や企業には機密情報も多く、万が一漏洩してしまったなら会社は大きな被害を被ることになります。情報漏洩の被害を無くすためにも監査ログを設定してセキュリティの強化をしておく必要があります。監査対応、内部統制の観点から重要な機能となっています。
監査ログの必要性とは?
監査ログは取得しておくこはどのような必要性があるのか知っておくことが大事です。どのような必要性があるのか以下の点をご覧ください。
監査ログ案件 | 必要性 |
コンプライアンス案件 | ・監査ログによりデータ内部に関わる不正や改ざんがないことを証明できる・クライアントからトランザクションの有無やデータ改ざんの防止の要求に応えることができる・内部の統制をしっかり行うことができる |
事件や事故発生の事実確認 | ・監査ログによりデータ内部で何が起きたのかをしっかり把握することができる・個人情報の漏洩など、何の情報が漏れた可能性があるのか被害の確認を行うことが可能・不正アクセスの結果から、誰がどこでアクセスしたのか情報を確認することができる |
取引先や会員などの説明責任 | ・監査ログによりどんな情報が漏洩したのか明確であり、事故内容を説明できる・事実を元にしてどのような行動を取ることができるのか論理的に説明できる・漏洩した情報の追跡を行えるので対応策について責任説明することが可能 |
再発防止の策定 | ・監査ログにより流出経路や情報が漏洩した過程について確認を取ることができる・ピンポイントに情報漏洩の部分がわかるので、再発防止のコストを浪費しなくて済む・セキュリティの甘さを実感でき、強化対策を適切に行える |
事件や事故の兆候の収集 | ・監査ログにより不正アクセスや情報漏洩の場所が分かり事件や事故の兆候を分析できる・事前に不正の兆候を察知できるので手口についての情報収集が行える・兆候の確認により防止策をさらに強化することが可能 |
監査ログの種類とは
データベース内のセキュリティ強化で利用できる監査ログですが、監査ログにもいろいろな種類があります。どのような種類があるのか表によって特徴をまとめているので確認してみましょう。
監査ログ種類 | 特徴 |
標準監査 | 文や権限スキーマオブジェクトに対して監査を行う機能です。一般的に使用されている種類です。 |
ファイングレイン監査 | Oracle9i以降のEnterprise Editionで使用可能です。特定の列に対するSelect文が発行されたときのロギングすることができるなど、標準監査よりも細かく監査することができます。より綿密な監査をしたいならおすすめです。 |
必須監査 | 管理者権限でログインしたユーザーのインスタンスへの接続と起動、停止操作が記録されます。Oracleのインストール時にデフォルトでログ取得を行うこともできます。 |
DBA監査 | SYS、SYSDBA、SYSOPER権限でログインしたユーザーに対して全ての操作をOSファイル上にログ取得します。DBA監査のログ出力先はイベントログになっており、変更は行えません。 |
監査ログはこのように、種類によりいろいろな特徴があります。使用しているデータベースの内容と合わせて、最適な監査ログを選択するようにしましょう。
Postgre SQLにおいての監査ログの取得方法
Postgre SQLの監査ログを取得したいなら方法について知っておく必要があります。どのような方法で監査ログの取得が行えるのか2つの方法があるので、それぞれ把握するようにしておきましょう。
log statementパラメータによる取得方法
監査ログを取得する際はPostgresql.confにログの出力を制御するlog_statementパラメーターを設定することで、監査ログの取得を行うことが可能です。パラメータの取得ができれば実行したSQLをサーバーログとすることができるためです。ただ、取得したログには収集内容が不足しており、またメッセージや運用ログが混在もしているため、監査を行い難いという課題もあります。
監査ログとしては役割を十分に行うことが難しいので、Enterprise Postgresの拡張モジュールのfileーfdwを利用できます。この方法で、監査ログをアプリケーションからSQLで参照することができ、またAlogやEVAなどと連携してGUIベースでの監査を行い、課題を克服して監査ログとして使用しやすくできます。
拡張モジュールpqauditによる取得
監査ログを出力するための拡張モジュールpgauditで取得することも可能です。操作レベルによる出力や詳細なログ設定、log_statementパラメーターによる取得で不足しているスキーマ名などを取得することができます。ただ、出力先はサーバーログであるため監査を行いにくい点があります。
ただpqauditにはいろいろな派生版があります。機能強化されたEnterprise Postgresの「pqaudit refactored版」を利用することにより、課題の克服も可能です。この利用により監査ログを専用ログファイルに出力することが可能なので、ログの解析を行いやすいです。ログ出力量を抑えることもできるので、データベースの性能劣化も抑止することができ、監査ログを安心して利用することができます。
Enterprise Postgresで監査ログを取得する手順とは
Enterprise Postgresはデータベースを監査する際に、必要な情報をしっかり取得することが可能です。そのため、監査ログとして取得するならEnterprise Postgresを利用することも可能です。もし、Enterprise Postgresの監査ログを取得するなら以下の手順で行いましょう。
出力モードを選択
Enterprise Postgresには「Session Audit Logging」と「Object Audit Logging」の2種類の出力モードがあります。それぞれの特徴は以下の表のようになっています。
出力 | 特徴 |
Session Audit Logging | ルール指定をして合致する監査ログだけを出力できるSQLの更新系や参照系、参照系のみの実行などに指定できる |
Object Audit Logging | 監査ログ対象のObjectに対して権限を付与されているロール指定をして、実行された操作の監査ログを出力できる |
どれが使用目的に応じているのか確認して出力を選択するようにしましょう。
監査ログ機能の動作条件を設定
監査ログ機能を使用するために動作条件を設定する必要があります。動作条件はpqaudit設定ファイルに指定して専用ログファイルの使用としておきましょう。パラメータ設定をするときは
- outputセクション
- ruleセクション
- optionセクション
の3つに分けておきます。outputセクションは監査ログの出力先の情報を指定、ruleセクションは監査ログを絞り込むためのルールの指定、optionセクションは使用するロールや監査ログの出力に関する指定を行います。
動作条件をそれぞれ設定することができれば続いての操作に移ります。
セットアップを行う
監査ログの取得のためにセットアップを行うことが大事です。セットアップの流れとしては
- Postgresql.comの編集
- 拡張機能のインストール
- pqaudit設定ファイルの編集
となっています。
Postgresql.comの編集にはpqaudit設定ファイル名を指定してインスタンスを起動します。
拡張機能のインストールはCREATE EXTENSIONを使用して拡張機能であるpqauditを読み込みます。
pqaudit設定ファイルの編集では、必要に応じて条件追加を行います。編集内容を有効にするためにインスタンスの再起動を行います。
監査ログの管理の方法とは
監査ログによるセキュリティ強化を行うなら、しっかりと管理できるようにすることが大事です。監査ログの管理方法は4つの方法で行うことができます。それぞれの管理方法のポイントを解説していきましょう。
取得対象の選定
監査ログを収集するときは必要なログのみを取得するようにしましょう。セキュリティ強化のためにたくさんのログを取得すればいいわけではありません。余分なログを取得するとストレージが多くなり動作に悪影響が生じることもあるためです。
取得するログの選定は事件や事故の事例や、対策したいセキュリティの課題を分析することで必要なログ取得が見えてきます。外部からの不正アクセスのログインを強化したいのか、それとも内部からの流出を抑えたいのかにより、取得する監査ログには違いがあります。
また、覚えておきたい点としては、ログの選択が多過ぎることは良くないですが、単一のシステムから得られるログだけでは事実確認がほとんど行えません。そのため、ネットワークやWebサーバーでのセキュリティ強化をしたい場合は、ログの特徴を確認して組み合わせの選定を行いましょう。
保管期間と分析
保管期間と分析も確認しておくことが大事です。基本的には分析頻度の多いログは異常検知は発生時点から近いタイミングで行うことができ、保管期間が短くて済みます。ただ、不正会計処理を防ぐリスクを目的とするなら、問題発見に時間がかかることが多いのでログ保管期間は長く設定することが必要です。
また、ログの保管期間は監査ログのレベルによって変化することも多いです。低位影響レベルのシステムであれば、セキュリティの分析は少なくていいので保管期間は短くて済み、1〜2週間で終えることが可能です。しかし、高位基準になるにつれてログの分析はしっかり行わなくてはいけないので、期間は長くなり最低3ヶ月、最長だと1年以上は保管する必要があります。
分析レベルに応じて保管期間が長くなることも覚えておきましょう。
問題発生時を想定した訓練
監査ログの設定の際には、事実確認を行うことができるように訓練しておくことも大事です。必要なログを定義しても、取得対象から漏れていたり設定に不備があったりするなら、目的通りとはならないからです。
そのため、情報漏洩が起きたことを仮定して監査ログがどのような反応を起こすのか試してみましょう。訓練の際には
- 取得設定のチューニング材料となるか
- 業務中断レベルの確認と情報セキュリティの意義の認識共有
- 情報漏洩の際の監査ログの必要性の確認
を重視しましょう。
ログの訓練をしておくことで予想できるサイバー攻撃に対しての対策を確認でき、セキュリティ強化のための支援を上層部から得やすくもなるので、準備しておきましょう。
ログの一元化
監査ログを管理するときは一元化しておくことがおすすめです。監査ログを一元化することでログ管理は全て最小限の手順で行うことができ、把握がしやすいので分析も楽に行うことができます。監査ログの変更も一元化することでスピーディーに行えるので、ツールを駆使して効率も求めるようにしましょう。
まとめ
監査ログを取得することにより、会社のデータベースや内部の情報を安全に保管することができます。情報漏洩による被害対策として監査ログは大きく役に立つので、導入をしてセキュリティ強化を行うようにしてください。