暗号ファイルを使った正しい秘密情報の守り方

年金機構の情報漏えい事件に関して、暗号化して保存するルールになってたなんて発言もあり、暗号ファイルの正しい秘密情報の守り方を確認しておきたいと思う。

1.暗号鍵の管理

大事なのは暗号鍵の管理となる。鍵が漏えいすれば、暗号にして保存しておいても何も意味がない。これが意外に難しい。
たとえばファイルサーバーに暗号化したファイルを置いておいたとして、その鍵をチーム内で共有していたとする。鍵がチーム外に漏れては意味がないので、チームメンバーの入れ替えが発生するたびに既存の暗号ファイルの鍵を全部変更する作業が発生する。
また暗号ファイルをメールなどで遠隔地に送る場合、鍵はメールとは異なる安全な媒体で送る必要がある。よくメールで送った添付ファイルの鍵を、別のメールで送ってくるが、これは殆ど意味がない。最低でも封書などで送る必要がある。

2.暗号鍵の長さ

鍵の長さも大事な要素となる。技術の進歩とコストの低下の恩恵を受けているのはクラッカーも同じで、ランダムな英数字記号による8文字程度の鍵なら、総当たりで試行錯誤を繰り返せば解くことができるようになってきた。AES暗号を使ったZIPファイルでも、ハイエンドパソコンなら毎秒40万通りの試行錯誤を実施できるので、英数大小文字に数字と記号までを使ったパスワードでも36年で全ての組み合わせを試せる。本気で暗号を破ろうとするなら、この1/10,000時間で解析することも出来る。最低でも英数字記号による12文字程度の鍵を設定しないと安心は出来ない。。

3.暗号方式の選択

暗号方式には設計レベルでの脆弱性が見つかっているものが多数ある。例えば圧縮ファイルのZIPで使われているPKZIP暗号とか、古いWordやExcelのファイルには、容易に鍵を類推出来るという脆弱性があります。設計レベルでの脆弱性なので、使わない以外の対策はありません。
したがってZIP形式の場合にはAES暗号を使うようにする必要があります。ただしWindowsの標準機能では複合出来なくなる。ExcelやWordではxlsxやdocx形式を選択すると良い。

4.内容を読めない

暗号ファイルにしてるので内容を読めません。何故これが問題なのかというと、例えばウィルス対策ソフトもファイルの内容をチェック出来ないので、ウィルスが含まれていても検出出来ません。また本来は持ち出しの許されていない情報が含まれてないか調べることも出来ません。これを防ぐためにはファイルに使用されている暗号鍵を全て提出させて日々更新し、しかるべき立場の者以外が閲覧できないように厳重に保管しておく必要が生まれます。
これを実現するには、暗号鍵を24桁にして前半12桁と後半12桁とを全く別々の担当者通知して管理させるといったことになる。

ファイルの暗号化によって秘密を守ろうとするとここまでの事が必要になりますが、到底実施不可能だと感じたのでは無いかと思います。それは当然のことです。そもそも共通鍵暗号でファイルを暗号化して秘密を守ろうというのは20年前の発想で、ネットワークに接続された機器が増え、殆ど全ての情報が電子化されている時代に通用する物では無いのですから。

チーム内で安全にファイルを共有するためには、IRM【Information Rights Management】という仕組みを使います。これ自体は単体のシステムとして販売されているのではなく、グループウェアや文書管理システムの一機能として提供されている事が多いです。実は、MicrosoftのOffice製品は10年以上も前から標準でIRMに対応していて、サーバーを1台用意すればIRMを使ったファイルの暗号化をできます。

秘密情報をファイルサーバーに保存する事に関して、まともなSEに少しでも相談していたなら、複雑な運用ルールにあれこれ悩む必要など無かったのに・・・と思わずには居られません。

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

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

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

続:Brandoo WordPressで¥を入力できない。

以前に「Brandoo WordPressで¥を入力できない。」で書いた、/(半角バックスラッシュ)や¥(半角円マーク)を入力していると、更新ボタンを押しても変更内容が保存されない問題について、パッチが提供されていたので適用方法など。

GitHubのBrandoo-WordPress-MSSQLにBugFixが提供されています。バックスラッシュ(円マーク)を含むコンテンツを保存できない不具合に対するパッチ(https://github.com/Brandoo/Brandoo-WordPress-MSSQL/issues/4)です。

FTPなどでサーバーにログインして直接編集します。

JhottMasterさんのGitHubに書かれている修正内容(https://github.com/Brandoo/Brandoo-WordPress-MSSQL/pull/7/files)に従ってwp-content/mu-plugins/wp-db-abstraction/translations/sqlsrv/translations.phpの内容を書き換えます。

Windows 2003 Server 延命策の海外との温度差

「Deadline Extension 2003 Server」で検索した結果を見ると、そこには「延命策など無い」と移行を促す記事がならんでいる。対して「2003 Server 延命」で検索すると、延命ソリューションの解説記事が並ぶ。このあたりに日米のリスク感覚の違いを感じる。まるで延命という処方箋があるかのような記事が国内には多いが、延命策は所詮延命でしかない。恒久的に延命できるわけでもないので、移行策を平行して実施する必要があり、移行にかかるコストををさらに増やすことになる。

とわ言え、移行が間に合わないなら、間に合わないなりの対策が必要なのは事実。「サポート終了までに移行が間に合わない場合」の延命策に過ぎないこと、延命できる期限があることを明示している点でトレンドマイクロの延命策はまだ好感を持てる。他のデベロッパーはもう少し見習ったほうがよい。

元々WindowsOSのサポート期間は最短で発売から10年間とされている。次期バージョンの大幅な開発遅延など、よほどの事情がない限りこの期間は延長されない。10年の猶予があっても移行すらままならないというのは異常事態だ。

異常事態に陥る本当の問題は保有するIT資産の総量に比較して、IT予算が少なすぎたり、IT部門の人員が不足している事にある。抜本的な対策はIT資産を減らすか、IT部門を増強するしかない。IT資産を減らすなら社内のITシステムの内、市販のパッケージソフトやSaaSに置換え可能な物は既存システムを破棄して移行をすすめ、身の丈にあったサイズまでIT資産を減らさなければならない。逆にIT部門を増強するとなるとかなり難しい。3年前ならいざ知らず、今はITエンジニアを募集しても簡単には集まらない。短期的には外部のコンサルタントに頼りながら、人材を育てていくしか無いだろう。

Windows XPというベストセラーOSのサポート終了から間もないこともあって注目を受けたが、サポート終了というのは毎年のように発生するありふれた話に過ぎない。今後もサポート終了にまつわる話は間断なく続く。

例えば.Net Framework 2.0の延長サポートは2016年4月12日で終了する。.Net Frameworkとは聞き慣れないかもしれないが、Windows用アプリケーションを作るための製品、Visual Studio 2005で開発したアプリケーションが使用するフレームワーク(ミドルウェア)だ。Visual Studio 2005の後継となるVisual Studio 2008が発売されたのは2008年2月だから、2008年以前にMicrosoftの開発ツールを作って作られたアプリケーションの大多数が対象となる。単にOSを更新するだけで良いWindows 2003 Serverに比較して遙かに難易度が高い。

SQL Server 2005の延長サポートも2016年4月12日で終了する。SQL Serverは後方互換性が高いので移行にあたって技術的な問題が発生する可能性は低いが、機器更新費用やライセンス費用が発生するのは避けられない。

Office 2007の延長サポートも2017年10月10日で終了する。単純にOffice 2007を使わなければ良いという話では無い。Office 2007のサポートが終了すれば、早晩旧Officeのファイル形式(拡張子XLSやDOC)との後方互換性も提供されなくなる可能性が高い。旧Officeのファイル形式は20年以上にわたって使われており、大量に蓄積されているはずだ。これらのコンバートを検討しなければならないということになる。

先進的な技術をキャッチアップして移行もスムーズに乗り越えているような企業であるなら、今頃はWindows Server 2014やSQL Server 2014、Windows 10への移行を何時ごろ進めるのか、新機能をどのように活かすのかといった話を進めているところである。日本はホワイトカラーの労働生産性が低いといわれるが、その原因のひとつがIT資産の維持管理がままならず、先進的な技術をキャッチアップできていないことにあると思う。もしWindows 2003 Serverの移行で頭を抱えているなら、この機会に本質的な問題に向き合って、先進的な技術をキャッチアップできる体制を考えてほしい。

Brandoo WordPressを更新したところ「データベースの更新が必要です」が繰り返し表示される

Brandoo WordPressを4.2.2に更新したところ「データベースの更新が必要です(Required Update Database)」が繰り返し表示されて管理者ダッシュボードにログインする事が出来なくなりました。「データベースの更新が必要です」画面で「データベースを更新」を選択して更新が完了しても、続行をクリックすると再び「データベースの更新が必要です」の画面に戻ります。

よくプラグインを無効にするといった対策が紹介されていますが、今回はプラグインを無効にしても解決しません。原因はBrandooのSQL文をMSSQL用に変換する処理に係わる部分でした。

実はGitHubのBrandoo-WordPress-MSSQLにBugFixが提供されています。バックスラッシュ(円マーク)を含むコンテンツを保存できない不具合に対するパッチ(https://github.com/Brandoo/Brandoo-WordPress-MSSQL/issues/4)ですが、データベースの更新に失敗するのも同じ原因によるようで、このパッチを適用する事でデータベースの更新が正常に完了するようになります。

JhottMasterさんのGitHubに書かれている修正内容(https://github.com/Brandoo/Brandoo-WordPress-MSSQL/pull/7/files)に従ってwp-content/mu-plugins/wp-db-abstraction/translations/sqlsrv/translations.phpの内容を書き換えます。

その後、WEBを再起動して再び管理コンソールに接続すると「データベースの更新が必要です」と表示されるので「データベースを更新」を選択します。無事データベースの更新が完了して、管理コンソールにログイン出来るようになります。

私的データのバックアップにMicrosoft Azure Backupを使うことを思案中

インターネット上にバックアップしている私的なデータがおよそ500GBある。ほとんどは写真データ(RAW含む)と音楽データ。現在はこれらのデータをBunBackupというフリーソフトを使用して、WebDavでマウントしたOneDriveにバックアップしている。実はOneDriveへのアックアップにはいくつか欠点があって、XML形式のファイルをアップロードできなかったり、ローカルのファイル名で使用できる文字や拡張子がいくつかつかえなかったりする。実はプログラミングで作成されたようなファイルが制限にひっかることが多く、ちょっと問題視していた。もうひとつはBunBackupの機能的な問題で、世代管理したバックアップがちょっと難しいのだ。

実は来月(2015年4月1日)からWindows Azure Backupの料金が大幅に値下げされる。私の使い方だと毎月1万円以上かかっていたのが、毎月3千円台で収まるようになりそうなのだ。それに加えてMicrosoft Community Chanpionに参加したことで頂いたBizSpakによるWindows Azure無料利用枠が1.5万円ほどあるので、実質負担なしで使うことが出来る。Azure Backupなら、もともとがバックアップ用途に設計されているのでファイルの種類による変な制限もないし、世代管理も問題なく行えるようになる。・・・と言うわけで良いことずくめだ。

とりあえずお試し感覚でOneDriveでうまくバックアップすることが出来ずにいたプログラミング関係のファイルを対象にバックアップを試し始めた。リカバリの使い勝手なども確認しておきたい。

万が一の時にデータを失わないために

今データ保存用に使っていたHDDが壊れたので、参考までに書き綴ってみる。

もちろんデータを失うような失態は犯していない。Windows 7.0以降で提供されている記憶域プールの機能を使い、手元のUSBドライブを組み合わせて双方向ミラーを構成していたからだ。ただし万が一もう一台HDDが壊れればデータを失う事になった。薄氷を踏む思いで、いくつかの対策を済ませ、ひと心地つけているところだ。

良くある勘違いに、パソコンが壊れてデータが失われた原因を、パソコンが古くなった事にする人が居る。でもこれは本質から外れている。確かにパソコンに限らず古くなれば壊れる確率が上がるのは真理だ。でも新品だから壊れないという保証があるわけでもない。

次に良くある勘違いに、DVDやCD、時にはUSBメモリにバックアップしてあるから大丈夫という人が居る。DVDやCD、USBメモリといった記憶メディアだって壊れる事があるのだ。バックアップした記憶メディアを頻繁に読み込んでチェックしているならともかく、バックアップして何年もそのままなら、いざという時に読み込めるかなんて分かりやしない。

データが壊れることを防ぐ唯一の方法は、複数の方法で同じデータを保存しておき、それらが破損していないことを定期的に確認することだ。最初の例では複数の方法での保存すらしていないし、2番目の方法では破損していないか定期的に確認できていいなかったりする。実は「破損していないことを定期的に確認する」というのは凄く難しい。

そこでお勧めするのが記憶域プールの活用だ。USB HDDを二台以上用意して記憶域プールを作成し双方向ミラーかパリティに設定しておけば、何も意識しなくとも常に複数のディスクにデータが保存される上に破損していないか常時チェックしてくれる。ディスクの空き容量が少なくなったら三台目を追加すれば、簡単に容量も増やせる。記憶域プールの作り方は説明しない。そんなのググればすぐに見つかるからね。

記憶域プールは双方向ミラーで作るのがお勧めだ。HDD 2台でも構成できる。パリティは容量を大きく使えてお得に思えるかもしれないが、実は速度低下というデメリットもあるし、最低3台のHDDが必要なのでお勧めしない。

でも記憶域プールも完璧じゃない。誤操作で削除した場合は、複数のHDDに保存されている両方のデータが削除されてしまう。そこで、僕の場合はその上でさらにMicrosoftの提供するOneDrive上に1TBほどの容量を借りて、定期的にデータをコピーしている。最近は無料でも借りれる容量が増えてきているので、無料枠で収まるように厳選してコピーしても良いだろう。One DriveをWebDAVと言う機能をつかって、普通のドライブと同じように使うことも出来るので、コピー操作は簡単だ。

わざわざインターネット上にOneDriveとかGoogleDrive借りてまで・・・と思うかもしれないが、自宅が災害に遭う可能性だってある事を忘れてはならない。別の場所に置いておかないと、パソコンが被災したときに全部一緒に失われてしまう。これを防ぐためには、まったく別の場所に複製をおいておく必要がある。またOneDriveやGoogleDriveなどは、DVDなどの記憶メディアに較べて極めて信頼性が高いのでデータが破損する可能性が低い。だからデータが破損していないかチェックする手間を省くことが出来るのもメリットだ。

信頼性が高いならOneDriveやGoogleDriveにデータを預けておくだけでよいのではないかって?MicrosoftやGoogleが倒産して、突然サービスが利用できなくなるかもしれないでしょ?

情報セキュリティに関するアンケートの信頼性

CSIRT構築済み企業は4割以上に、ただしセキュリティ人材不足の企業が依然8割以上

そもそも、自社の情報セキュリティの状況についてアンケートに答えるという行為自体が、重大な情報漏洩に繋がりかねない件について・・・

自社の情報セキュリティに関する情報というのはとても重要な機密事項になる。CSIRTを組織しているか否か程度なら組織図や役員構成などの公開情報を見ればわかるのであえて秘密にする意味はないが、社内でセキュリティ問題を抱えているシステムに関する情報などは本来絶対に外に出せないものだ。もし「Windows XPを使ったシステムがあります」などといえば、攻撃者にWindows XPの脆弱性を利用すると成功率をあげられることを教えているようなものになる。人材不足などについても同様のことが言える。

この手のアンケートをどう読み解くかは難しい。解答した660社(22%)は自社のセキュリティ情報を無警戒に流出させた間抜けかもしれない。もちろん相手の信頼性や公開できる情報の範囲を熟慮して回答した企業もあるだろうが・・・。この手のアンケートは著しくサンプルが偏っている可能性が高い。集計結果は眉に唾をつけて読み解くしかないだろう。唯一信じられるのは22%が回答したということだけだ。

実は企業のセキュリティ対策の実態というのは非常にセンシティブな情報で簡単には外に出てこない。他社がどうしているのか気になるのは日本人の性かもしれないが、セキュリティに関しては自身の知識と技術、そして良心を頼って進むしかないのである。