先週１３日(日本時間では14日の朝)、フランスのパリで同時多発テロが発生し、IS（Islamic State）が犯行声明を出しました。メディアでも大きく報道されていますが、今年に入ってテロを十分に警戒していたはずのフランスで起きたことで、テロ対策の新たな影響がいろいろと懸念されています。

フランス当局はISがロシアの無料の暗号化通信サービスを利用してやりとりをしていた証拠が見つかったと発表しましたが、テロ組織や反社会的な勢力にとっては暗号化技術というのは組織の活動を秘匿するために欠かせないものとなっています。

アメリカは暗号化技術に対して輸出規制をしており、日本も基本的にそれに追随していますが、いくら輸出規制をかかけても、世界中がインターネットでつながる現状では、第三国での利用に規制をかけることは難しく、犯罪者に悪用されると捜査が困難になり、さらに問題が悪化してしまいます。

このため、暗号化技術の規制はさらに強化される可能性があります。現在はアルゴリズムが公開されていて暗号鍵長が短いものは、ある程度自由に利用できます。しかし、強度の高い暗号化方式を用いる場合に対して、公権力が新たな規制をかけるかもしれません。

私たち善良な利用者からすると、これらの規制は利用時の制約となるので、好ましいとは言えませんが、犯罪の抑止の観点からはある程度の制約は受け入れざる得ない状況になるのではないかと思います。

先日、Linuxのランサムウエアの暗号鍵の設計不備が話題になりました。ランサムウエアというのを聞き慣れない方もいると思いますが、ランサムウエアとはシステムを勝手に暗号化して、復号化に金銭を要求する悪質なマルウエア（ウイルス）です。

このランサムウエアは復旧に１ビットコイン（ちなみに今日の価格は約320ドル）を要求するものでした。ところが、セキュリティベンダーに、暗号鍵の生成と保存の方法が安全な方法でないと逆に分析されてしまい無料で復号化ツールを提供されてしまうというお粗末な結果に終わりました。

お気づきの方も多いと思いますが、なぜ復号化ツールを提供できたかというと、暗号化鍵が同じシステム内に存在したからです。もし、これが暗号鍵が別サーバに転送される仕組みなっていたらと思うととても恐ろしいことで、このランサムウエアの作者が安易な方法を選んだことで助かったとも言えます。

暗号化したデータを安全に保つには、暗号鍵を別サーバで管理することが重要だということは、いつも述べていますが、このような事例をみることでさらに認識を深めていただけれと思います。

「データを暗号化したいのだけれど、元に戻らなくなったら困る」というのは誰もが思うところです。
実際、私も何度か経験があります。

ただ、その一番の原因は「暗号化したときのパスワードを忘れる」です。忘れなければいいのですけれど管理がいい加減だと手順をすべて忘れているときもあります。そこで、パスワードを再発行したいところなのですが、通常の暗号化ではパスワードの再発行はできない仕組みになっています。これは、以前にも書きましたが、それくらい暗号化は強力なのです。

そのようなとき、考えるのがバックアップからのリカバリです。バックアップさえあれば安心なのですが、その大事なバックアップが暗号化されていないことも多いです。

でもこれは、気持ちは非常に分かります。もし、バックアップも暗号化してしまって、元に戻せなければ悲惨なことになるからです。しかし、それでも、バックアップファイルの暗号化は推奨されます。というのは、バックアップはやはり盗難のリスクが高いからです。それらは通常の管理から離れることが多いので、時におおきな情報漏えいの被害をもたらすからです。

バックアップの暗号化もServer-GENERALではバックアップフォルダを指定するだけで暗号化できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

普段、Linuxシステムを運用するときにファイル名の長さというのはあまり意識しないかもしれません。一般的なファイルシステム（例えばLinuxならext4など）では利用できるファイル名の最大長は255バイトです。その他のファイルシステムもほぼ同じです。それだけの長さがあればほとんど問題が起こることはないでしょう。ですから、ほとんどのシステムはファイル名の長さは255バイトまで使えることを前提に開発されています。

しかし、これは暗号化してない場合ということを念頭に置かなければなりません。

透過型の暗号化システムでは、いままでと同じように普通に読み書きできるのですが、ファイル名の最大長は短くなります。
例えばeCryptfsでの暗号化ではファイル名は以下のように暗号化されます。

ECRYPTFS_FNEK_ENCRYPTED.FYYc2.DBV1LG…(略)…peF72R6.eb2EY1
（eCryptfsのファイル名の暗号化の例）

この中には暗号化のメタ情報などが含まれるので実際に利用できるファイル名の長さは144バイトしかありません。これは割合にして暗号化する前の56%となり、システムによっては深刻な減少となります。もし、それ以上の長さのファイル名を持つファイルを作成しようとすると「File name too long（ファイル名が長すぎます）」というエラーになります。

これは長いファイル名を利用するシステムにおいては致命的です。LinuxではUTF-8で漢字のファイル名を扱いますので、極端に４バイト文字だけを使用した場合は３６文字しか利用できません。また、システムによっては自動的に長いファイル名を作成する場合もあるでしょうから注意が必要です。

もし、システムの暗号化を検討される場合は、ファイル名の最大長を事前に十分に確認していただければと思います。

先週の豪雨では栃木県小山市の一部地域でも浸水被害があり、ニュースでも大きく報道されました。弊社の本社も小山市内ですが浸水した地域よりは高く離れた地域でしたので被害はありませんでした。多くの方からご心配のお電話をいただき、ありがとうございます。

今回のような自然災害に備えてシステムのバックアップを取ることは非常に重要ですが、バックアップを暗号化している方はまだまだ少ないようです。システムやソフトウエアごとにバックアップの方法は違いますから、それぞれについて安全なバックアップについて考えるのは容易なことではありません。

このような時に透過型暗号化でフォルダごと暗号化できるのは非常に便利です。単純にバックアップ先のフォルダを暗号化指定してそこにバックアップしたデータを保存すればよく、バックアップの手法を問いません。

バックアップというのは、すぐに取り出せなくては意味が無いので、盗まれやすい非常に危険な状態にあることがあります。運用中のシステムの安全性も大事ですが、バックアップの安全性も十分に考慮していただければと思います。

Server-GENERALであればバックアップフォルダも簡単に暗号化可能です。