データセキュリティライフサイクルと暗号化

ライフサイクルとは、一般的にはある商品を生命に例えて、「導入」「成長」「成熟」「衰退」という4段階をたどるとするものです。期間の長短はあると思いますが、ほとんどこのライフサイクルに当てはめて考えることができます。

データに関しても同様のライフサイクルがあります。CSA(クラウドセキュリティアライアンス)の作成したガイダンスによると
「作成」「保存」「利用」「共有」「アーカイブ」「破棄」
の6段階となります。このライフサイクルは必ずこの順番になるという意味ではなく、これらの状態を行き来するとされています。そして、これらのあらゆる段階で暗号化を利用することが推奨されています。

最近はストレージの単価が安価になったことにより、データを破棄するということが、ほとんどありません。データを破棄するためには将来的にデータを再利用することがないことを十分に検討しなければなりませんが、そのような合意形成をすることは難しいので、「アーカイブされたあと最終アクセスから○年以上経過後に強制的に破棄する」というようなルールを決める場合も多いようです。

データを長期に渡って保存する場合、従来はどのようなメディアに保存するかが重要でした。保存したメディアが将来において読み出せるかどうかわからないからです。テープやフロッピーディスクもほとんど使われなくなり、バックアップもUSBメディア、外付けHDDやNASに置き換わっていきました。そして、今ではクラウド上でオブジェクトストレージが容量制限なしで利用できます。これらも10年後、20年後に利用可能か誰が予測できるのでしょうか?

そうなると、長期保存で一番重要なのは、実はデータを複数の方法で保存することなのです。あらゆる商品やサービスにライフサイクルがあるのであれば、将来何が生き残るかは予測はできません。複数の方法でデータを保存してあれば、すべてが読めなくなるリスクは減らすことができます。

暗号化も同様です。過去に暗号化したファイルが必ず復元できる保証はありません。共有ディスクに保存された暗号化ZIPファイルを開けようとしてパスワードを忘れてしまったことはありませんか? ZIP程度なら解析可能ですが、これが高度な暗号化ソフトを使っていたらどうでしょう?

データセキュリティライフサイクルにおいて「破棄」をしないということは、逆に破棄しない限り、安全にデータを取り出せなくてはいけません。つまり、データが「破棄」されない世界では、さらに暗号化の重要度は増していくことになるでしょう。

暗号化とバックドア

バックドアというと「裏口」という意味ですが、暗号化の分野でのバックドアは、暗号化した本人以外の者が復号化できることを表します。例えとして、マンションの住居の鍵をマンションの管理人も鍵を持っていて、住人でなくても自由に出入りできるというようなイメージになります。この場合、管理人が善良な第三者であれば、緊急時の解錠に対応できますが、もし管理人が悪意を持っていればプライバシー侵害や盗難の被害に遭う可能性があります。

暗号化にバックドアが必要かどうかは常に議論の対象です。暗号化の仕組みに詳しくない人が暗号化サービスを利用すると、暗号鍵を紛失したり、解除のパスワードを忘れたりするので、サービス事業者は顧客サービスの一環として直接又は間接的な方法で暗号鍵を復活したり、パスワードを解除できる方法を提供することがあります。しかし、通常はこのようなバックドアが無いので、暗号鍵の紛失やパスワード失念すると二度とデータを復元できません。

厳しい目で見ればバックドアは常に悪意ある攻撃の対象となる可能性があります。バックドアがあると分かれば、攻撃による情報漏えいのリスクは高まるので、理想を言えばバックドアが無いことが望ましいのですが、データ紛失の危険や、利便性を考えて、何重にもセキュリティロックがかかった状態でバックドアを利用するというのが現実的かもしれません。

さて、それとは別に米国FBIは犯罪捜査のために暗号化にバックドアの設置を義務付けるように法整備を求めています。米議会の暗号化ワーキンググループが昨年末にこれを議論した報告書では、暗号化のバックドアは利点よりも害のほうが多いとしています。それは通常のプライベート環境の暗号化のバックドアと違い、影響範囲が大きく、暗号化の本来の目的が薄れていくことになります。また、これは先に述べたようなユーザの利便性のためのバックドアではないですので、公的な機関による安易なバックドアの設置は格好の攻撃者の餌食となり、プライバシー侵害や機密情報の漏洩といった被害に直結する可能性が高くなります。

暗号化では常に機密性と利便性を考慮しながら利用を検討しなければなりません。利便性を重視しすぎてそれがバックドアとなり、悪意ある攻撃者に利用されないように注意していただければと思います。

報道の自由と暗号化

先週、「Freedom of the Press Foundation(報道の自由基金)」は世界の主要なカメラメーカーに対して、カメラ機器に暗号化機能を搭載するように要望しました。これは現在のカメラにまったく暗号化機能がないので、ジャーナリストやカメラマンが機材を押収されたり、発表をしないように脅されたりする危険があるため、暗号化やロックができればジャーナリストや機材の安全性が高まるとしています。

この要望書に署名した人たちの中には映画「シチズンフォー スノーデンの暴露」の監督など、国家権力と対立することを厭わない人たちですので、彼らにとって、データの安全と身の安全は切っても切り離せない事案なのです。

さて、技術的な面から考察すると、カメラ内のデータを暗号化することは、そんなに難しいことではないでしょう。しかし、それでデータが安全かと言われると、iPhoneのロックがFBIに解析されてしまったように、適切な暗号化をしないと簡単に解読されてしまいます。

では、例えばこのような秘密を保持したいジャーナリスト向けのカメラの暗号化はどのようなものが理想でしょうか?
具体的には次のようなものになればよいのではないかと思います。

1)秘密鍵と公開鍵を作成する。
2)秘密鍵は自宅又はオフィスで保管する。
3)公開鍵をカメラに持たせて撮った瞬間に画像を暗号化する。
(この場合撮ったらその場での画像確認は不可能)
4)自宅又はオフィスの戻った時に秘密鍵でデータを復号化する。

このように公開鍵暗号方式を用いれば、公開鍵は暗号化するときだけに、秘密鍵は復号化するときだけにと使い分けができるので安全なカメラ機器が作れることになります。

しかし、これでは撮ったその場では確認できないような「デジカメ」になるので、一般には全く売れないような気がします(笑)。
ジャーナリストのための暗号化カメラを作るメーカが現れたら、その実装方式が本当に安全かに注目しましょう。

今年はこれで最後の記事です。来年もよろしくお願いいたします。

暗号化で個人情報漏えいの報告義務が変わる?

個人情報漏えいの事件や事故が起きた場合、事業者は関係機関への報告が義務付けられていますが、その義務が少し緩和されようとしています。

先週、内閣総理大臣の所轄する行政委員会である個人情報保護委員会は「個人データの漏えい等の事案が発生した場合等の対応について(案)」に関する意見募集を開始しました。この中で個人情報の漏えい事故の起きた場合の報告義務に関して新たな指針を示しています。

それは、「実質的に個人データ又は加工方法等報が外部に漏えいしていないと判断される場合」には報告しなくてよいということです。

報告の必要のない例のひとつとして、
・漏えい等事案に係る個人データ又は加工方法等情報について高度な暗号化等の秘匿化がされている場合
というのが記載されています。

簡単に言えば、「暗号化されて解読が困難であれば個人情報の漏えいは報告しなくてよい」とするつもりのようです。
その他にも、実質的に第三者の閲覧がないと見なせる場合もいくつか例として挙げられており、今までのすべてを報告しなければならない状態から緩和されるようです。

しかし、事故の報告が必要がないとされる「高度な暗号化」とは、いったいどのようなものなのでしょうか?

それはまだ、具体的には示されておらず、今後どのようなガイドラインが示されるのかに注目です。厳密に言えば暗号化されていても、情報の漏えいには違いはないと思うのですが、この暗号化による報告義務の緩和により、暗号化の採用が進むのであれば、それはセキュリティの向上に寄与するものになるかもしれません。

自動運転車のガイドラインと暗号化

世界中で自動運転車の開発が活発に行なわれるようになり、実用化が目の前に迫っています。特に安全性の議論が活発に行なわれていて、自動運転車へのサイバー攻撃に対して、システムとデータの保護が不可欠であるとして、日本とドイツが中心となって国連の分科会で自動運転車の基本的な考え方のガイドラインがまとめられました。

このなかでもデータと通信の暗号化は世界標準のものを用いることが推奨されており、今後の自動車産業にも大きな影響を与えるものと思われます。今でも、自動車は十分に電子化されていますが、あくまでもドライバーの運転を補助するため機能でしたので、暗号化の必要性というのはありませんでした。しかし、外部の情報と連携して自律的に動作する自動運転者は常にハッキングと戦わなければなりませんので暗号化が必須とされたのです。

また、それだけが問題ではありません。

自動車はマイクロ秒単位で制御が求められるリアルタイムコンピューティングという特殊な世界です。Windows、Mac、iOSやAndroidといった私たちが考えている一般的なコンピュータのように、すこし反応が遅くても気にしないというわけにはいかないのです。このような世界で処理に負荷のかかる暗号化に求められる性能はとても厳しいものになります。

暗号化のICチップも多く発表されるようになりましたし、この自動運転車の暗号化のガイドラインが今後どのように具体化されていくのか注目していきたいと思います。

無料の暗号化システムを活用するポイント

クラウド上でのシステム構築にあたって、大事なデータを暗号化したいという要望は非常に増えてきました。そのとき、できるだけコストを抑えて実現したいということはあると思います。最近ではオープンソースソフトウエアのデータベースであるMySQLが標準で透過的暗号化をサポートし、無料で利用できるようになったということで、大きく注目されています。

しかしながら無料のシステムには、常に不安がつきまといます。特に暗号化というものは、暗号鍵を盗まれないようにすることが大事であり、無料のシステムはその配慮が欠けているからです。例えば一般的な暗号化のアプリケーションは以下のような動作をしています。

1)アプリケーションの起動
2)暗号鍵を指定場所からメモリ内へ読み込み
3)暗号鍵を使ってデータ処理

これが一般的な動作ですが、この動作で問題なのは2)の部分です。暗号化の処理をするためには暗号鍵が必要になりますが、無料のアプリケーションでは暗号鍵を認証なしで読み込み、保存場所も保護されていません。これでは簡単に暗号鍵が盗まれてしまいセキュリティ上問題があります。

単純にこれを解決する方法として、アプリケーション起動後に暗号鍵を削除するという方法があります。この場合、アプリケーションが起動後に暗号鍵をメモリ上に取り込みキャッシュするような作りであれば、問題なく動作します。もちろん、次回起動時には暗号鍵が必要になりますので、バックアップから暗号鍵を元に戻さなくてはなりません。

つまり、暗号鍵の場所が明確であり、暗号鍵が起動後にメモリ上にキャッシュされるようなアプリケーションであれば、自分で暗号鍵管理をすることで簡単にセキュリティを向上させることができるということになります。また、暗号鍵の保存フォルダの部分に別途商用のフォルダ暗号化ソフトウエアを使って暗号化することで、無料のアプリケーションの暗号化機能をより安全にコストを抑えて使うことができます。

いずれにせよ、無料の暗号化システムはご使用前にその構造を詳しく理解して、暗号鍵の安全性を確かめていただければと思います

クラウド上のシステムの脆弱性対応を考える

今週、LUKSと呼ばれるLinuxの暗号化の仕組みに脆弱性が発見されました。今回の問題は暗号化そのものに脆弱性があったわけではなく起動時のスクリプトに管理者権限を取得できる脆弱性があったようです。

このような脆弱性の報告はシステムの専門外の方とって、自社のシステムでの影響度をどのように判断すればよいのかは大変難しいことだと思います。しかし、システムが脆弱性にさらされているのであれば、一刻も速く対応をしなければなりません。

最近のOSにはほとんどシステムの自動更新機能がありますので、可能な限り活用したいところなのですが、自動更新は危険も伴います。更新のあとにいままでと違う動きをしてしまう場合があるからです。昔に比べるとそのような危険は少なくなりましたし、クラウドシステムの場合、定期的なスナップショットを取ることで更新前の状態に戻すことも簡単になりましたので、自動更新をする場合はそのような機能と組み合わせる必要もあるでしょう。

また、安定性を求められるシステムのほとんどは複数台サーバでシステムが構成されます。これはセキュリティ的な観点からすると一つのサーバに多くの機能を詰め込むより、多くのサーバに機能を分散させたほうが、一つのサーバの機能も少なくでき、サービス停止のリスクも少なくできます。

脆弱性の対応も一台しかないと再起動が必要なときにサービスを止めなくてはなりませんが、複数台で冗長構成が取られていればサービスを止めることなく脆弱性の対応が可能になります。また、自動更新もサーバ単位で隔日などで設定できるので、何か遭った時の対応が可能になります。

クラウドによってバックアップやスナップショットそして複数台構成も安価に簡単にできるようになりました。これらを上手に活用して脆弱性対策をしていただければと思います。

グーグルPixelはハードウエア暗号が標準に

今月、グーグルから発表された新製品のPixelは、iPhoneをかなり意識して作られたグーグルブランドのスマートフォンです。この製品では、ハードウエア暗号が標準で搭載されており、システムの性能を落とすことなく暗号化機能が利用できるようになっています。

iPhoneではハードウエア暗号はかなり前からサポートしていましたが、Androidの場合、コストやパフォーマンスの問題もあってなかなか搭載が進みませんでした。グーグルはAndroid6.0から端末の暗号化を義務化していますが、暗号化をソフトウエアで行うとCPUに負担がかかり、パフォーマンスに影響を与えます。最近になってCPUの性能が良くなって、ようやくAndroid6.0の端末が標準になりつつあります。

しかし、CPUの性能に依存した暗号化は、OSやアプリケーションのパフォーマンスに影響を与えますので、今回のPixelのようなハードウエア暗号機能を搭載した端末が増えてくれば、そのうような問題も解消していくことになります。

さらに、Android端末のハードウエア暗号が普及すれば、製造コストも安くなり、他の情報家電や、IoT端末等に一気に暗号化が普及するきっかけになっていくことでしょう。

テレワークの鍵を握るクラウドセキュリティ

数年前から、政府の「働き方改革」により、テレワークの推進が盛んになってます。テレワークとは情報通信技術を利用して、時間と空間に束縛されずに仕事ができるようにすることです。昔から在宅勤務という言葉はありましたが、それはテレワークの中では一部分を表しているにすぎません。在宅に限らず、いつでも、どこでも自分の職場にすることができるのがテレワークの特徴です。

これは多くのクラウドサービスが充実してきたことにより、IT関係に限って言えば、ほとんどオフィスにいなくても仕事ができるようになってきたということがあると思います。最近では、多くの大手企業のテレワーク導入がニュースになり、つい先日も高市総務大臣がテレワーク推進企業としてヤフージャパンを視察したことも報道されています。

このようにテレワークを重要課題として推進する政府ですが、総務省からテレワークのセキュリティガイドラインを出していて、職場外での社内資料の閲覧や情報漏えい対策は、「インターネットの高速化や、暗号化等の情報セキュリティ技術の活用」により、解決できるとなっていて、女性の活躍できる社会、子育て世代の支援、労働人口の減少などの対策を急ぐ政府の切り札としての積極性が良く分かります。

テレワークを実現するために重要なのは社内でのルール作りとセキュリティ教育、そして、技術的な課題としては、重要情報の暗号化と安全な通信経路の確保がポイントとなります。

テレワークに限らず、社外でスマートフォン、タブレット、または、ノートPCなどでクラウドサービスを利用する機会は増えていると思いますので、もういちど情報セキュリティ対策を見直していただければと思います。

クラウドの暗号化で何から守るのか?

最近、クラウド事業者がさまざまな暗号化サービスの提供を始めていますが、暗号化という言葉の響きは、その分野に詳しくない人からすると、きっと暗号化するとデータが守られて安全なのだろうなと考えてしまいます。しかし、暗号化したからといってすべての攻撃からデータを守ることができるわけではありません。セキュリティ担当者は暗号化することによってどのような攻撃からデータを守ろうとしているのかを常に意識していなければなりません。そうでないと、想定した攻撃から正しくデータを守ることができなくなってしまいます。

通信の暗号化は、最近は当たり前になっています。この場合、通信データの盗聴という攻撃から守ることになります。しかし、今は暗号化通信を前提としたなりすましなどの攻撃が多いので、通信データを暗号化しただけでは安心できません。

多くのクラウドサービスではサーバのデータディスク全体の暗号化ができるようになってきました。これはどのような攻撃からデータを守ろうとしているのでしょうか?

いわゆるディスク暗号はOSからみると暗号化しているようには見えません。このような暗号化ではOSにログインできればすべてのデータが見えることになります。ということはOSが攻撃を受ければ、すべてのデータが盗まれる可能性があるのです。

つまり、この暗号化では、その上位層であるクラウドサービス全体の攻撃からの情報漏えいを防ぐことを前提としています。例えば仮想マシン全体やデータディスク自体をコピーされて盗まれてしまうとか、他には、利用しているクラウド事業者が間違って利用者のデータを見ることができないようにするという意味もあります。

このように現在クラウド事業者が提供しているデータディスクの暗号化サービスは本質的にOSの攻撃に対しては無防備です。ですからそれだけで安心することなくOSやアプリケーションレベルでの攻撃にも耐えられる暗号化サービスも検討する必要があります。