お客様と暗号化のお話しをすると、さまざまな状況の中で暗号化を検討されていることが分かりますが、そこには常に必然性があります。つまり、暗号化を考えざるをけない環境に急に置かれているということです。

一番、多いのはエンドユーザからの強い要求です。これは事業者側が暗号化に対応していなければ、エンドユーザが別のサービスを利用してしまうということもあり、事業者側も積極的に取り組みます。例えば、医療関係の事業でのご利用がこのパターンが多いです。医療ITは、医療従事者が直接システムを設計したり運用したりすることがありませんので、患者情報や医療情報などが暗号化されていることを事業者側に強く望む傾向があります。

そして、次に多いのがコンプライアンス上の要求です。最近では法令やセキュリティ基準などで「暗号化することが望ましい」と書かれることが多くなり、それに対応するために暗号化に取り組みます。プライバシーマーク、ISMS、PC-DSSなどのセキュリティ基準を満たし、さらに強固にするためです。

また、一度、情報漏えい事故を起こした業界の関連団体も、取り組みが活発になります。特に政府系機関でセキュリティ関連の事故が起きたり、大きな企業グループで事故が起きたりすると、関連団体すべてにセキュリティ監査が行われ、暗号化の議論が活発になります。

このようなときに、慌てて対応してしまうと、とんでもないコストがかかったり、使いにくい暗号化システムを採用してしまったりすることがあるので注意が必要です。常にセキュリティを意識して大事なデータの暗号化の準備を進めておくことは、これらの環境に置かれたときに、慌てることなく対応が可能になります。

以前、このMLの中で、暗号化する場合のファイル名の長さに制限がかかることを述べましたが、それよりも、ファイルサイズを気にしている方が意外と多いようです。また、zip暗号のように圧縮されるのではないのかと思われる方もいます。実際はどうなのでしょうか？

ここで紹介させていただいている透過型暗号化というものは、ブロック暗号という方式を採用しています。アルゴリズム的にはデータをある固定サイズに分割してブロックごとに暗号化します。この場合、暗号化する前と後では全くサイズは変わりません。だから「サイズは変わらない」と言いたいところなのですが、実際にはサイズが少し増加してしまいます。というのは、サイズが増加する主な要因が二つあるのです。

それは「パディング処理」「暗号化情報の保存」です。

ブロック暗号では固定サイズでデータを分割すると言いましたが、割り切れない場合は、割り切れるようにダミーデータを付加します。これをパディングといいます。このパディングが起きるとその分だけサイズが増えることになります。

また、暗号化されたデータをどのように復号化するのかをどこかに書いておかないと元に戻せません。そのような暗号化情報をファイルのヘッダとして保存する場合もサイズが増加します。

両方ともそんなに大きなサイズではないのですが、ファイルサイズで動作が変わるようなアプリケーションでは気をつけていただければと思います。

データを暗号化することでシステムのセキュリティを高めるということは、一般的にそのデータの閲覧に制限がかかることを意味します。そしてこれは可用性の設計に大きな影響を与えます。可用性とは情報セキュリティにおいて、システムがダウンすることなく利用可能である度合いことを意味しますが、通常はシステムの二重化、アクティブスタンバイ、負荷分散、クラスタなどの機能を用いてシステムの可用性を高めることで対応しています。

しかし、データの暗号化において、もうすこし可用性について考えてみますと、「データを消失しない」ということに加えて、「データを確実に元に戻せる」ということが重要になってきます。暗号化において最も深刻なトラブルといのはデータが元に戻せないということだからです。

暗号化されたデータを確実に元に戻すためには、

１） データが壊れていないこと。
２） 暗号鍵が壊れていないこと。
３） 暗号鍵を使う権限があること。

という、３つの条件を満たさなくてはなりません。

１）と２）に関してはシステムの二重化やバックアップがあれば通常は可用性を保つことができます。しかし、３）に関しては、もし権限をもつ管理者が、利用するためのパスワードや手順を忘れた場合、大きく可用性が損なわれることになります。そういう意味では管理者の権限の運用体制が最後は重要になり、ほとんどのことはシステムに任せることはできても、管理者の権限や手順に関しては結局、運用マニュアル等が重要になってきます。

データを暗号化するときには暗号鍵が必要になります。それを理解されている方は多いのですが、誰が管理すべきかを、十分に考慮されていないことがあります。一般的にサーバ管理者はサーバ上のことは何でも任されてしまうことが多く、ある特定のサーバ管理者がすべての責任を負わされてしまうことは、あまり良いことではありません。

暗号化においては特にサーバ管理者への権限集中が起きやすいので、それを避けることが重要になってきます。
いわゆる、「権限分離」です。

特にOSやネットワークの管理者は、その管理業務においてデータを閲覧する必要性はほとんどありません。つまり。理想的にはOSの管理者とデータの管理者を分離するということができなくてはいけません。しかし、一般的なオープンソースの暗号化方式は、基本的にOSの管理者が、暗号鍵の管理者も兼ねており、理想とは程遠いものとなっています。また、暗号化領域のマウント後はデータの閲覧も簡単にできてしまいます。

では、商用サービスであれば、どんなものでも問題ないのかというと、そうとも限りません。確かに鍵の管理はOSの管理者と分離できるものは多くなってきましたが、暗号化領域のマウント後のデータ閲覧のアクセス制御までできる高度なものはまだ少なく、大変高価なものになります。

Server-GENERALでは、このような権限分離とアクセス制限を十分に考慮した暗号化がリーズナブルな価格で提供可能です。

暗号化を利用するとシステムが遅くなるのではないかと心配される方は多くいます。実際に暗号化をすると、どの程度パフォーマンスに影響するのかは気になるところです。

通常、暗号化のスピードはCPUの性能に依存します。透過型暗号化ではディスクへの読み書きのタイミングで暗号化が行われますので、その頻度が多い場合はCPUの利用率が高くなることになります。それはどの程度なのでしょうか？

我々が実際に行ったMySQLを利用したパフォーマンステストでは、CPUの負荷に余裕がある状態でのパフォーマンスの低下は5%未満です。しかし、ピーク時の高負荷状態では15%程度のパフォーマンス低下となりました。

これはテスト条件にもよると思いますが、通常の負荷テストツールではデフォルトで性能限界を測定しますので、その状態でテストをすると、かなりパフォーマンスが落ち込んだようなイメージを与えます。しかし、それを実際にグラフ化してみるとCPU性能の限界に達する直前までは、そんなにパフォーマンスが落ちていないことが分かります。

システムの運用において限界性能で運用することはないと思いますが、常にシステムのCPU負荷を監視していただくことが、暗号化システムの運用においては重要なポイントとなります。