データを暗号化するシステムを運用している場合、「暗号化しているから安心」と普通は思うかもしれませんが、そんなに簡単に安心してはいけません。実際に重要なのは誰がそのデータにアクセスできるのかということです。

一般的なディスク暗号やフォルダ暗号の仕組みでは、データのアクセス権はOSに任せています。つまり、一旦データを復元してしまうと、OSの管理になるので、OSの管理者であれば簡単にデータを見ることができてしまいます。単純な暗号化システムのほとんどはそのような実装ですから、いくら暗号鍵を厳重に管理していても、システムの運用中のデータは管理者(root)から丸見えなのです。

このような実装では暗号化の効果を疑問視する方も多いのではないかと思います。ですからここで大事なのは

「管理者(root)からのデータアクセスを制限できるか」

ということです。

高度な暗号化システムでは、暗号化と同時にアクセス権も制御します。簡単にいうと許可されたユーザ以外はデータを見ることができません。たとえそれが管理者（root)であったとしてもです。Linuxのroot権限は通常は非常に強力で、別のユーザに簡単になりすますことができます。そのようななりすましも検知してデータを守ります。

一般的な暗号化ではこような高度なアクセス制御はできません。暗号化してデータを守ることを考えている場合、データへのアクセス権の制御も重要だということを覚えておいていただければと思います。

Server-GENERALであればこのような高度な暗号化システムの提供が可能になります。

最近ではシステムで利用するパスワード増えて管理するのが大変になってきています。もちろん暗号化サービスでもパスワードは必須です。しかもかなり長いパスワードを要求されます。長い場合はパスフレーズと呼ぶこともあります。このとき、パスワードを忘れたら単純に再発行すればよいと考えているかもしれません。しかし、実は簡単なことではありません。というのも、

「暗号化サービスではパスワードの再発行はできない」

のです。

なぜなら、もし、簡単に再発行ができたらそこを攻撃されデータを奪われるかもしれません。通常、高度な暗号化システムでは、サービスを複数人で利用する共通パスワードというものは存在せず、必ず責任者に対して一対一でパスワードを割り当てることが要求されます。暗号化サービスのスタート時は、データ管理者の認証をもってサービスがスタートします。このデータ管理者がパスワードを忘れてしまった場合、当然、サービスは利用できなくなります。このような場合、パスワードを再発行するというようなことはなく、このデータ管理者の権限を無効化し、新しいデータ管理者への権限の移譲が行なわれます。

このとき、「データ管理者」を統括するのが情報セキュリティ責任者である「セキュリティオフィサー」です。セキュリティオフィサーはデータ管理者の作成と権限の付与のみを行う役割を持ち、暗号化サービスを直接操作することはありません。

このように、高度な暗号化サービスでは、パスワードの再発行という処理はなく、データ管理者の取消、権限移譲をもって、パスワードの紛失に備えています。

暗号化のシステムを構築のお手伝いをしているといつも聞かれることがあります。

「再起動したとき自動で暗号化サービスをスタートできますか？」

システム運用の効率化の観点からすると再起動のあとにすべてのサービスが自動で起動するのはあたりまえのように感じるかもしれません。しかし、機密性を重要視するシステムではそうではありません。

特にシステムがクラウド運用されることが多くなった昨今では、システムを丸ごとコピーするのはワンクリックでできてしまいます。重要なデータの入ったシステムのコピーが簡単に別の場所で起動してしまうのはデータセキュリティ上は非常に問題があります。

セキュリティの高いシステムでは、サービスの起動前にOSのユーザとは別のデータ管理者の認証を求めるようになっています。データは暗号化サービスの起動さえしなければ、データを閲覧することは、ほぼ不可能ですので、この起動時の認証というのはセキュリティを確保する上で、非常に重要な機能となります。それを自動スタートするとなると起動時の認証パスワードをサーバ内に保存することになり、セキュリティ上の脅威となってしまいます。

このようなことから、暗号化サービスは自動スタートさせてはいけないのです。

セキュリティを高めるといのは、一定の不便さを担当者が許容する必要があります。すべてが自動化されてブラックボックス化されるとセキュリティに対する危機意識がなくなります。不便すぎるのは困りますが、セキュリティシステムの構築はそのバランスが大事になってくることを意識していただければと思います。

セキュリティ対策というのは非常にコストがかかるイメージがあるため、どうしても対策が後手になりがちです。特にデータ暗号化はエンドユーザから見えない部分なので考慮されないことが多くなります。

しかし、それは大きな視点を見過ごしています。データの暗号化はサービスの差別化のチャンスと捉えることができます。つまり、コスト以外の営業的メリットが非常に大きいのです。
例えば
「我社のサービスはお客様のデータの安全を第一と考え暗号化して保存しています。」
と宣言した場合、そのサービスに対するブランドイメージやお客様の安心感は格段に向上します。

また、これだけではありません。セキュリティを意識したサービスの構築を心がけることで従業員のセキュリティ意識も同時に向上します。自社のサービスへの信頼を心から持つことで、その溢れ出る自信がお客様にも伝わり営業的な効果も上がっていきます。

「暗号化の必要性を感じない」と思う方は、「お客様に安心を提供する」「ブランドイメージ向上」「従業員のセキュリティ意識向上」という新たな付加価値が生まれることに注目していただきたいと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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