Oracleで監査ログを取得する

Oracleの監査ログを監視することになりそうなので、調査内容をメモしておく。

Oracleの監査ログはOracle 11g移行では標準で有効になっており、SYS.AUD$テーブルにデータベースへのログオン/ログオフとスキーマの変更が記録されている。Oracle運用経験の少ない管理者の場合、ログを削除する必要があることを知らずに、システム領域を圧迫することになるので注意。

監査ログを閲覧する場合にはSYS.AUD$を直接参照するのでは無く、DBA_COMMON_AUDIT_TRAILを参照する。以下のSQLで確認出来る。

SELECT * FROM DBA_COMMON_AUDIT_TRAIL

監査対象の追加

監査対象をログオン/ログオフ以外にも拡張するにはAUDIT文を使用する。以下のSQL文を実行するとテーブルに対する閲覧、変更が監査対象となる。

AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE BY ACCESS

AUDIT ALLとすれば全ての変更を監査対象とする事ができるが、無闇に監査対象を増やすことはサーバーの負荷や、監査ログを精査する業務の負荷を上げるので、必要最小限とする事が望ましい。情報の漏洩や改竄を目的とするのであれば、AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE BY ACCESSで十分と考えられる。

保存先の変更

標準設定では監査ログをテーブルに保存する。テーブルとして保存されていれば閲覧する分には便利だが、実際に運用する上ではシステム表領域のテーブルに大量のデータが保存される事はあまり好ましくない。
監査ログの保存先をXMLファイルに変更するには、次のSQL文を実行する。EXTENDEDは拡張情報まで収集する事を示す。標準ではSQL文等は保存されないため、どのような操作が為されたのか調査するためにも保存しておいた方が良い。

ALTER SYSTEM SET AUDIT_TRAIL=XML, EXTENDED SCOPE=SPFILE

OSのファイルとして出力する設定もあるが、OSに設定した場合は詳細なログを保存できないのでお勧めしない。

監査ログの削除

監査ログの削除はテーブルに対して直接DELETE文を発行するのではなく、DBMS_AUDIT_MGMT PL/SQLパッケージを使用する。

社内連絡にメールを使うのを止めよう

標的型攻撃で送られてくるメールへの対策はどうあるべきか、様々な話がされてます。その一つとして検討すべき事が、社内の連絡にはインターネットメールを使わないってことです。

情報漏洩の原因のひとつが、リスクの高い外部との通信と、リスクの低い内部との通信を同じ仕組みの中で取扱っていることです。インターネットメールを外部との通信以外で使わないようにすれば、特定の拡張子のファイルを全て削除するといった対策も取りやすくなりますし、部内者を装った標的型攻撃のメールに騙される可能性もなくなります。

他にも、インターネットメールを社内連絡に使う事には問題があります。インターネットメールは基本的にインターネット上のサーバーを介して送信します。常時インターネットとの通信を行っているために、自社のメールサーバーのメンテナンスに不手際があった場合、クラッカーに侵入されるリスクが高いのです。万が一侵入されればメールサーバーを経由した全ての通信内容が漏洩する事につながります。

そこでインターネットメールに変わって、グループウェアや社内SNSを使うようにします。インターネットメールにはセキュリティー上の問題以外にも、同報性や共有性が悪い、既読確認の仕組が使いにくい、大きな容量の写真などを送れない、過去データの保存性や一覧性が悪い…などなど様々な使い難い点があります。グループウェアを使えば、これらの問題も一挙に解決します。導入に躊躇していたり、活用できずにいるなら、セキュリティーの為にも活用を進めてください。

個人情報を扱うならインターネットから切断するのが常識・・・とはならないで欲しい

市町村にネット遮断要請へ 厚労省、年金情報流出で

個人情報を扱うなら、インターネットから切断するのが常識・・・とされそうで危惧してたんですが、案の定その方向に動いていて頭を抱えています。インターネットから切断するのは、案外難しく、実効性を持たせるのは大変なのです。

1.業務ができるのかということ。
端末入力業務程度しかしないのであれば、確かにネットから切断しても問題ないのだけれど、ほとんどの場合は情報を加工したり、あるいは別の形で利用したりしなければ意味のある業務になりません。業務をよほど詳細に分析し、場合によっては根本から見直さないと、結局のところ情報を外に持ち出すことになります。USBメモリで、CDで、あるいは印刷した紙媒体で隔離されたネットワークの外に持ち出して仕事をするわけです。実務担当者にとって、与えられた仕事を遂行することが優先しますから、例外として持ち出すことを認めれば当然持ち出します。最初は仕方なく持ち出すのだと緊張していても、それが常態化すれば感覚は麻痺していきます。

2.持ち出された情報は追跡できない。
持ち出された情報がどうなったのか、追跡するのは非常に困難です。紙であろうと、USBメモリであろうと、容易に複製出来ます。他の媒体に持ち出された時点から、誰によって閲覧され、複製が何処にあるのか追跡することが著しく困難になります。
全てオンラインシステム内で扱っていれば、何時誰が作成し、閲覧あるいは複製したか追跡することも可能です。あるいはファイルサーバー内のファイルを精査して、個人情報が含まれてないか調べることも出来ます。インターネットから切断したことで、頻繁に個人情報をシステム外に持ち出して業務をするのでは、むしろ全体的なリスクが増える事になるのです。

3.メンテナンスも困難になる。
インターネットから切断したからと言って、メンテナンスをしなくてよいというわけではありません。業務用に作成したプログラムの更新やセキュリティ更新プログラムのインストールなどは常に発生します。
インターネットに繋がっているのであれば、セキュリティ更新プログラムのインストールなどは半自動で実行されるのですが、インターネットから切断されるとそうはいきません。セキュリティ更新プログラムをダウンロードし、それが確かにベンダーが提供しているものなのかを確認し、隔離したシステムに導入する必要があります。隔離しているのだから更新プログラムを当てなくても良いのではと思うかもしれませんが、そうはいきません。業務用に作成したプログラムの更新など、何らかの形で外部からファイルやデータを持ち込む可能性があるなら脆弱性を放置するわけにはいかないのです。

このあたりを無視して切断した結果、個人情報を隔離したシステムから持ち出すのが常態化して、情報漏えいにつながったのがまさしく今回の年金情報流出事件でしょう。さらに別の組織にまでインターネットからの切断を求めるなんて、今回の事件からいったい何を学んだんでしょう?

ではどうすれば良いのかというと、セキュリティーの基本となる、アクセス権の管理と、ログによる監視をしっかりと行うことです。基本ができていないのに、インターネット接続だけ遮断しても、絶対にうまくはいきません。

Azure上のUbuntuにスワップファイルを追加する

gem updateの途中でメモリ不足によりアップデートを継続出来ないことがあったので、Ubuntuにメモリスワップを追加することにしました。Azure上のUbuntuは標準設定では仮想メモリを使用しないので、仮想マシンのサイズをA0とか小さいサイズにしていると、容易にメモリ不足に陥ります。

Microsoft Azure上のLinux仮想マシンにスワップファイルを追加するには/etc/waagent.confの次の3ヶ所をを変更します。

# Format if unformatted. If 'n', resource disk will not be mounted.
ResourceDisk.Format=y

# Create and use swapfile on resource disk.
ResourceDisk.EnableSwap=y

# Size of the swapfile.
ResourceDisk.SwapSizeMB=2048

この後、仮想マシンを再起動すると自動的にスワップ領域が確保されて、仮想メモリが有効になります。sudo swapon -sとかfreeコマンドを叩いて確認してください。

ちなみにResourceDisk.SwapSizeMBは無暗に大きくしないでください。私は最初に4096MBを指定して再起動したのですが、エラーになってしまいスワップ領域が作られませんでした。

waagentは/var/log/waagent.logにログを出力しているので見てみます。

$ more /var/log/waagent.log
2015/06/06 07:39:11 Finished processing ExtensionsConfig.xml
2015/06/06 07:55:02 ERROR:CalledProcessError. Error Code is 1
2015/06/06 07:55:02 ERROR:CalledProcessError. Command string was mkswap /mnt/swapfile
2015/06/06 07:55:02 ERROR:CalledProcessError. Command result was mkswap: error: /mnt/swapfile is mounted; will not make swapspace
2015/06/06 07:55:03 ERROR:CalledProcessError. Error Code is 255
2015/06/06 07:55:03 ERROR:CalledProcessError. Command string was swapon /mnt/swapfile
2015/06/06 07:55:03 ERROR:CalledProcessError. Command result was swapon: /mnt/swapfile: swapon failed: Device or resource busy
2015/06/06 07:55:03 ERROR:ActivateResourceDisk: Failed to activate swap at /mnt/swapfile

mkswapコマンドで失敗したために、以降の処理が全部エラーになってしまったようです。仕方ないので手動でマウント操作を実施します。

sudo chmod 600 /mnt/swapfile
sudo mkswap /mnt/swapfile
sudo swapon /mnt/swapfile

以上の操作で仮想メモリが有効になります。試しに次のコマンドを実行してみます。

$swapon -s
Filename Type Size Used Priority
/mnt/swapfile file 3000208 2068 -1

$ free
total used free shared buffers cached
Mem: 684468 552240 132228 3412 24496 243612
-/+ buffers/cache: 284132 400336
Swap: 3000208 2004 2998204

・・・が、swapsizeが約3GBほどになっています。もしかして・・・というわけで、ResourceDisk.SwapSizeMBを2048に変更して再起動すると、今度は正常にスワップファイルが作られました。