透過型暗号化ではアプリケーションの変更なくデータを暗号化して利用できます。アプリケーション側に変更が必要ないということであれば非常に便利なのですが、障害のときには注意が必要です。透過型暗号化のシステムで障害が起きた場合、通常はデータが全く見えなくなりますので、管理者の適切な障害切り分けが重要になってきます。

１）サービスが止まっていると中身は見えない。
まず、疑わなければいけないのは正しくサービスがスタートしているかどうかです。暗号化サービスが止まっていればデータを見ることができませんので、サービスの状態を正しくチェックするようにしましょう。

２）リストアする前に暗号化サービスのチェックをする。
通常はデータをリストアした場合、単純に元に戻ると考えがちです。しかし、もし、暗号化サービスが起動していない状態でデータをリストアしてしまうとデータは暗号化されずに通常の領域に保存されます。そして、アプリケーションはそんなことは気にせずに動作しますので、本当に暗号化されているのか常に確認をすることが大切です。

３）暗号鍵に常にアクセス可能か確認する。
暗号化のサービス停止の理由はさまざまですが、たまたま暗号鍵を保存したサーバにアクセスできなくてサービスがスタートできないこともあります。このようなことがないように暗号鍵を保存するサーバの二重化など可用性の確保に努める必要があります。

このように透過型暗号化ではアプリケーション側から暗号化を意識することはないので、管理者が正しくサービスの動作を確認して運用するようにしましょう。

情報セキュリティの国際規格である情報セキュリティマネジメントシステム(ISMS・ISO27001)では、情報の機密性と完全性を保護するために暗号化の利用を推奨されるようになりました。この中で何が一番重要視されているかというと鍵管理に関してです。少ない暗号化の実施項目の中で鍵管理だけで特別に章が設けられており、その重要度を垣間見ることができます。

この中では「暗号鍵の利用、保護及び有効期限に関する方針を策定し、そのライフサイクル全体にわたって実施することが望ましい」と記述されています。このライフサイクルとは暗号鍵の生成、保管、保存、読み出し、配布、使用停止及び破壊のすべての項目を暗号鍵を管理するための要求事項とすることが望ましいとされています。こらの記述はクレジットカード情報のセキュリティ基準であるPCI-DSSの暗号化要件をかなり意識した記述となっているようですが、これらの暗号鍵の管理がセキュリティ基準にを満たすために重要であるということになります。

私たちは暗号化していれば安心と単純に考えがちですが、実際に暗号化する場合は暗号鍵の管理のほうが重要視されます。暗号鍵は紛失すればデータを元に戻せませんし、盗まれても大変なことになります。暗号鍵のライフサイクルをきちんと管理できるようにシステムを作成するのは大きな負担となりますので、それらの管理を簡単にできる暗号化システムの選定をしていただければと思います。

日本では個人情報を取り扱う事業者の多くがプライバシーマークを取得しています。これらの事業者は個人情報の厳格な運用を行うためにさまざまな厳しいルールを定めています。しかし、このルールは事業者ごとに独自に定められているので、よく似てはいるのですが、微妙な差があります。

プライバシーマーク取得事業者が外部サービスを利用する場合、ルールに基づいて利用するサービス事業者のセキュリティ監査が行われます。このとき問題になるのがデータとして個人情報を保存しているかどうかです。サービス事業者がデータを閲覧する可能性がある場合、それがどのように制限されているかを示さなければなりません。また、データの保存期間の明確化、データの削除証明の発行など、多くの対応が求められます。

しかし、ここで問題が発生します。厳密にこれらのルールを運用するのであれば、サービス事業者が利用している外部のサービス、または再委託先に至るまで監査が必要になります。つまり、厳しい運用の場合、パブリッククラウドを利用しているサービスではパブリッククラウドの監査が必要になります。ところが、一般的にパブリッククラウドでは内部の運用ルールを公開することはありませんし、データの削除証明なども出してくれません。つまりサービス規約を眺めて自己責任で利用するしかないのです。

このようなときに利便性のためにセキュリティ基準を下げてしまっては意味がありませんので、サービス事業者は独自にデータを暗号化して、パブリッククラウド利用によるデータ漏えいの可能性を限りなく０に近づけることが非常に重要になってきます。そしてそれがサービスの差別化に繋がり、新たな付加価値となります。そして顧客獲得につながることは言うまでもありません。

データを暗号化したとき、「本当に元に戻せるだろうか？」と心配になることがあります。このような慎重さはとても重要です。せっかく暗号化しても暗号鍵が壊れたり、または、紛失すると、データは元に戻せません。また、暗号化は1ビットでもデータが変わってしまうと、同様に元にもどせません。つまり、データの暗号化を実施すると情報漏えいのリスクが軽減されますが、同時にデータ紛失リスクが増加するということを覚えておかなければなりません。

例えばサーバ管理の都合上、同一の暗号鍵ですべて暗号化するという場合があります。この場合、もし、この暗号鍵が壊れたり、紛失してしまった場合、データを元に戻すことは事実上不可能になります。それくらい現在の暗号化は強力で解読不能です。暗号化されたデータをコピーする場合も同様です。コピー後にデータの中身が改ざんされたり、ビットロスなどを起こすと復元不可能になります。
これらのリスクに備えるためにはいくつかの解決策があります。まず、暗号鍵の紛失や破損に備えて、複数のバックアップを持ちます。また、複数の暗号鍵を利用してデータの破損や暗号鍵の破損に備えることも重要です。例えば、MySQLなどのデータベースではレプリケーションを使って複数のサーバにデータを複製することができますが、このような場合は同じ暗号鍵を複数のサーバで利用することはお勧めできません。この場合、暗号鍵の破損や紛失があるとすべてのサーバで元に戻せなくなる可能性があるからです。しかし、それぞれのサーバが別の暗号鍵で暗号化されていれば、例えそのサーバの暗号鍵の紛失や破損があっても、別のサーバ上の複製を利用することができます。

暗号化はデータ紛失のリスクを伴っているということに注意して運用してください。Linux暗号化ソリューション「Server-GENERAL」では複数の暗号鍵で複数のサーバを簡単に暗号化できます。特にデータベースのレプリケーションを利用する場合に威力を発揮し、データ紛失のリスクを軽減することができます。

システムのバックアップ先にクラウド上の安価なオブジェクトストレージを利用したいということがあります。オブジェクトストレージは大容量のファイルを長期に保存することに向いているので、バックアップ用途としては最適です。しかし、バックアップデータというのは重要な情報を含んでいることが多く、安全を確認せずに保存するわけにはいきません。

バックアップを暗号化するときに、オブジェクトストレージ側に暗号化機能があることがありますが、透過型暗号化では通常のAPI接続で中身が閲覧できてしまいます。しかも、暗号鍵がクラウド事業者の管理下にあり、強固な暗号化とは言えません。では、このような場合、どうすればいいのでしょうか？

オブジェクトストレージにバックアップデータを保存するのであれば、データを独自に暗号化した状態で保存すべきです。つまりクラウド側の暗号化機能を利用せず、ローカルで暗号化したデータを直接保存します。このようにすれば、たとえオブジェクトストレージのAPIを直接操作されたとしても問題は起こらないでしょう。

オブジェクトストレージに送信するバックアップを事前に暗号化するのは、Linux暗号化ソリューション「Server-GENERAL」では特別な操作は必要ありません。管理者が暗号化されたデータのみをオブジェクトストレージに送ることができます。この方法でバックアップするとオブジェクトストレージ側には暗号化された状態のファイルのみが送られるので、API経由で中を閲覧しても解読することはできません。これで安心してオブジェクトストレージを利用できますね。