情報漏えい事件が相次ぐ中、多くのシステム要件定義に暗号化というキーワードが入るようになってきました。しかし、まだまだ「何をどのように暗号化するのか」という視点ではなく、「とりあえず全部暗号化する」というものが多いようです。

その典型的なものがディスク暗号化です。ディスク暗号化はハードディスクそのもの、またはパーテション単位で暗号化するものです。通常はOSの起動時や、パーテションのマウント時にパスワードを求められ、そのあとは自由にデータを閲覧できます。

ディスク暗号化でシステム全体を暗号化するのは、管理は簡単ですが、リソースを無駄に消費します。暗号化はCPUのパワーを要し、ディスクIOに影響を与えます。また、ほんの一部の情報が機密情報であるのに全体を暗号化することは、ロッカーの中の重要でない書類も含めてすべてに「社外秘」などのスタンプを押すようなもので、管理する側が本当に重要なものを意識できなくなる可能性があります。

これに対してフォルダ暗号化を利用する場合、通常、情報システムで暗号化の対象となる重要なものは「データ」「ログ」「設定」の三つです。こららのフォルダを個別に暗号化することで重要な領域を明確にすることができ、システム全体の暗号化に対する無駄なリソースの消費を抑えることができます。また、顧客別にデータを別フォルダで保管しているような場合、顧客ごとに暗号化することができるメリットがあります。

さらに、弊社のLinux暗号化ソリューション「Server-GENERAL」ではフォルダ単位の暗号化に加えて、フォルダ単位で暗号鍵を変更できます。フォルダを公開するときも厳しいアクセス権を設定でき、root権限での閲覧も禁止できます。単に暗号化するだけでなく運用中のシステムにも高度なセキュリティを実現できます。

データベースを暗号化することの重要性を多くのSEは理解しています。技術をよく理解しているが上にその実装方法の設計には非常に慎重です。なぜなら、暗号化は単純な実装なら簡単ですが、高度なセキュリティを維持するのはとても難しいからです。

多くのプログラミング言語は暗号化のための関数が用意されています。またデータベース側にも独自のSQLによる暗号化関数があります。これらを利用すれば、誰でも暗号化を実現できます。しかし、実際に実現するとなると、どの暗号化関数で、どの暗号化のアルゴリズムを利用し、どのように暗号鍵の管理など実装しなければならないさまざまな問題が発生します。そして、選択した実装が本当に安全なのかを判断するのも時間を要する仕事です。

例えば商用版のMySQLでは独自のMySQL Enterprise Encryptionが用意されています。これは公開鍵暗号という高度な暗号化関数が利用できます。この場合でも公開鍵と秘密鍵の管理は十分に安全になるように考慮しなくてはなりません。

このように通常のシステム開発で暗号化を実装する場合、開発をする側に多大な労力が必要になります。しかし、弊社のLinux暗号化ソリューション「Server-GENERAL」ではアプリケーションの実装を変更することなく高度な暗号化を実現することができます。

前回、データベースの暗号化は可用性を考慮すると複数台の暗号化で、場合によっては暗号鍵の共通化などいくつか考慮すべきことがあるということでした。データベースは暗号化するにあたり、もう一つ暗号化を検討しなければいけない箇所があります。

それは、バイナリログ（トランザクションログ）です。

ログというと通常は単なるアプリケーションの動作の記録ファイルですが、データベースの場合はもっと重要な意味があります。それはデータの更新履歴がすべてその中に存在するということです。MySQLの場合、それはすなわちバイナリログと呼ばれるものであり、他のデータベースでも同様のファイルが存在します。このファイルを順番に辿ればデータを復元できてしまいます。つまり、データそのものがログファイルの中に含まれているので、これもセキュリティ上は重要な保護対象となります。

MySQLではレプリケーション時にはこのバイナリログを読むことでデータベースの複製を実現しますので、このバイナリログが安易に読み込まれてしまうことは情報セキュリティ上は避けなくてはいけません。しかし、以前にお伝えしたように単純な透過型暗号化では、バイナリログへの厳しいアクセス制限をかけることができませんし、もし、不正にコピーされたとしても記録が残りません。

弊社のLinux暗号化ソリューション「Server-GENERAL」はデータベースのバイナリログの保存フォルダを厳格なアクセス制限をかけたセキュリティポリシーで運用することが可能です。もし、管理者（root）がそのフォルダにアクセスしようとしても、閲覧できませんし、不正なアクセスとしてログに記録されます。

年金加入者の個人情報が流出し、改めてセキュリティ対策の重要性が浮き彫りになってきました。みなさんのビジネスでも大きな話題となっていることと思いますが、いかがでしょうか？　今回はかなり運用上の問題点が指摘されているようですが、システムを構築する側としては、お客様のセキュリティの意識を高めていくことがより重要になっていると再認識しました。本当に気をつけないといけないですね。

さて、今回はシステムの重要な要素であるデータベースのセキュリティについて考えてみたいと思います。データベースは重要なデータをすべて保存していますので、暗号化を考えるときに一番最初に対象となってくるものです。しかし、やはり安易に暗号化してしまうといろいろな問題が起きてきます。というのもデータベースは２４時間３６５日止まってはいけないというものが多く、セキュリティの中では可用性がもっとも重要視されてきました。このためクラスタやレプリケーションなど複数台を用いて可用性を高めることが通常は行なわれます。つまり、暗号化する場合、対象のサーバが複数になってしまうということです。

Amazon RDSも一応暗号化に対応していますが、使いやすいとは言えません。一番問題なのは現在利用中のRDSをそのまま暗号化できないということです。また、逆に一旦暗号化してしまうと元に戻すことができません。そもそもRDS自体がある程度ブラックボックス化しているので、カスタマイズの自由度が高いとは言えません。また、以前説明しました鍵管理、権限管理といった問題もEBS暗号化と同様ですので制約が多いと言えます。

実際、複数台のサーバを暗号化するとき、レプリケーションの場合はそんなに問題はありません。お互いが独立して暗号化しても通信プロトコルに変更はないので個別に暗号化すればよいということになります。しかし、DRBDなどのブロックデバイスの同期型のレプリケーションでは注意が必要です。なぜなら、この場合は暗号化された状態でデータのレプリケーションが行なわれるので、複数のサーバで同一の暗号鍵を使用する必要があります。いわゆる共有ディスク型のHAシステムも同様です。フェールオーバーして別のマシンが起動したときに同じ暗号鍵を使わないと復号化ができないからです。

弊社のLinux暗号化ソリューション「Server-GENERAL」は現在運用中のデータベースでも暗号化可能です。また、暗号化の停止もコマンド一つで簡単に運用できます。同期型のレプリケーションでも暗号鍵の共通化を指定できますので、柔軟なシステム構成に対応できます。