災害時のためにバックアップは暗号化してクラウドへ

先週から続く熊本地震では、ビジネスにも大きな影響が出ています。ビルや家屋の倒壊により、元の場所でのビジネスの継続が難しくなり、仮のオフィスでビジネスを再開させた方も多くいます。

ビジネスにおける災害対策においてはBCP(事業継続計画)と呼ばれる緊急事態における事業の継続と復旧を可能とするための計画を平常時に取り決めておくことが重要になります。今回のような災害においていち早く事業を再開できるかどうかは、平常時の準備の差が大きく影響します。

ビジネスでは常に最悪の事態を考えておくようにと言われますが、今回のように自然災害によってオフィスが使えなくなるというのは、その一例です。東日本大震災をきっかけに多くの会社がBCPを推進するようになりましたが、特に中小企業では災害が倒産のリスクと直結することが多いので十分に準備しておくことが求めれます。

そのときに求められるのがビジネス上のデータのバックアップですが、バックアップというとすべてのデータをバックアップしなければならないと思う方が多いようです。しかし、それをしてしまうと膨大なデータになり、復旧にも時間がかかってしまいます。災害時においてすぐに復旧すべき必要なデータというのは、ビジネスにおける中核事業の直近のデータのみです。これらのデータを事前に見極めておくことでビジネスの早期復旧を実現することができます。

クラウドへの重要なビジネスデータのバックアップには、まだ抵抗を感じる方もいます。しかし、クラウドは複数の分散されたコンピュータで構成されるので災害に強いというメリットもあります。その利点を最大限活かすために、バックアップデータを事前に暗号化してクラウド上に保存することを検討していただければと思います。

ランサムウエアが増え続ける理由

トレンドマイクロ社の最近のレポートによるとランサムウエアの被害の報告は既に昨年の16倍に達したそうです。被害に遭うとデータが暗号化されて元に戻せなくなるので、対策は定期的なバックアップを取ることだと以前にお伝えしましたが、ランサムウエアのやっかいなところは感染したPCだけでなくネットワーク共有されたディスクも暗号化しようとすることです。そうなると、もし、共有サーバにバックアップがあっても、そのバックアップ自体を暗号化されてしまう恐れがあります。このため、バックアップするときだけ保存媒体に接続するようにするべきだと情報処理推進機構(IPA)なども警告していました。

しかし、何故こんなにランサムウエアの被害が増えているのでしょうか?

それはサイバー犯罪のビジネスモデルとして利用可能なツールが充実してきたことが挙げられます。匿名で通信可能なTor、そして匿名で送金可能なビットコインなどです。これらの匿名ツールは元々はプライバシーを守り、第三者の検閲を避けるために作られたものですが、犯罪者にとってこれほど都合の良いツールはありません。

また、今ではランサムウエアがオープンソースで公開され、自動作成ツールやアフィリエイトサービスなど、そんなに技術に詳しくない人たちででも、この黒いビジネスモデルに参加できる仕組みが整っているのも大きな特徴です。

これらは、暗号化技術の発展の裏の側面と言えますが、それだけ暗号化技術が普及しているということでもあります。私たちは暗号化技術の正しく利用しこれらの攻撃者からシステムを守るためにも、暗号化技術の知識を深めていく必要があると思います。

ウェブサイトの常時SSL化で暗号化が新たな時代へ

先日、Yahoo! JAPANが全サービスの常時SSL化を進めると発表しました。SSLというのは主に通信の暗号化で利用される技術で、ウェブサイトで利用する場合はHTTPSというプロトコルが利用されます。インターネットで買物等をするときは、ブラウザ上に鍵のマークが現れたり、グリーンになったりしてSSLによって通信が暗号化されていることが分かるようになっています。

さて、この常時SSL化ですが、Googleでは2012年あたりから取り組んでおり、今はすべてのサービスが常時SSL化されています。また、今年に入ってから、Googleが常時SSL化しているサイトの検索結果のランキングを上位にするという発表をしたものですから、多くのウェブサイトが常時SSL化への対応を始めています。

常時SSL化でインターネットはさらに安心して使えるようになると思われるかもしれませんが、では、実際にはどんな効果があるのでしょうか?。常時SSL化によって何がもたらされるのかというと基本的には通信の暗号化です。つまり、通信が傍受された場合に効果があります。具体的には無線LAN環境などでは、そのような危険にさされることが多く、プライバシーの保護などには大きく寄与するとになるでしょう。

それで全てが安心かというとそうではありません。今の情報漏えいの事件では通信の傍受によるものは大変少なくなっています。つまり、通信の暗号化は当たり前という前提での攻撃になっているのです。それは脆弱性への攻撃であったり、ウイルスによる攻撃であったりさまざまですが、通信の暗号化だけでは対応できないものが増えてきています。その対応のために保持するデータの暗号化するというシステムが増えているのです。

世の中が通信の常時暗号化の世界へ移っていきます。そして、その次は保持するデータの常時暗号化へ向かうのではないかと思います。

ランサムウエア被害の急増で注目される定期バックアップの重要性

先日、知人がランサムウエアの被害に会いました。彼はITに詳しくなかったので単にコンピュータが故障したと思ったようです。私にPCの状態の確認の依頼があったので診てみると、見事にすべてのファイルが暗号化されて開くことができず、デスクトップの壁紙に解除方法が日本語で書かれていました。まさしくランサムウエア「ROCKY」の仕業でした。彼にとってみるとデスクトップの説明もゴチャゴチャしてよく分からなかったようですが、確かにこの説明を読んで実際に解除を試みるには、それなりに詳しくないと無理かもしれません。

私は、彼にランサムウエアの被害であることを伝えて、PCの完全な初期化を薦めました。幸いなことに彼はPCを二台もっていて完全な同期ではないけれども、もう一台にもデータがほとんど残っていたので、被害のあったPCは完全に初期化をして復旧をさせました。

ランサムウエアの被害というのは、暗号化の観点から見れば、暗号化されたデータが元に戻せないということになります。もちろん、攻撃者から要求された金額を支払えば元に戻る可能性もありますが、元に戻る保証がされているわけではありません。、企業での被害の場合はコンプライアンス上の問題で、匿名の第三者(しかもこの場合は犯罪者)にお金を払うことなど決して許されることではありません。

今回のランサムウエアの被害の急増に伴い、情報処理推進機構(IPA)は今年の1月に「ランサムウェア感染被害に備えて定期的なバックアップを」と呼びかけています。その中で二次被害を避けるためにバックアップする媒体とはバックアップするときだけ接続することが重要だとしています。

ランサムウエアは攻撃者に勝手に暗号化されてしまう被害ですが、たとえそれが自分で暗号化したものであったとしても、不運が重なると「データが元に戻らない」可能性はゼロではありません。そのような場合に備えてバックアップとその復元方法を確実なものにしていただければと思います。

iMessageのセキュリティホールに見る暗号解読の典型的攻撃手法

iMessageはAppleのiPhoneなどで標準で使われているメッセージ交換アプリケーションです。ショートメッセージなども利用できるので利用しているかたも多いのではないかと思います。さてこのiMessageですが標準で暗号化されており、解読することはできないというのがAppleの主張でした。ところが、最近、ある大学の研究者たちが暗号解読実験を試みiMeesage経由で送られた写真やビデオの解読に成功したと発表しました。

今回、利用されたセキュリティホールは、つい先日発表されたiOS9.3で既に修正されています。一般的に脆弱性の発表は二次被害を防ぐために修正が行なわれてから細かな発表されますが、研究発表が伴うとさらに詳細な内容を同時に知ることができます。

さて本題ですが、なぜ解読可能だったのかということですが、大きく2つの理由があります。
1) 他人のデータを第三者が取得可能だった。(ただしデータは暗号化されている)
2) 暗号鍵を無制限にテスト可能な状態にあった。
という2つの理由によります。

1)はAppleのサーバになりすまして写真や動画を横取りするという手法が取られました。この段階では暗号鍵が存在しないので解読は容易ではありません。2)はAppleの鍵管理サーバ利用されており、研究者たちは復号化時の暗号鍵を手当り次第にテストしました。Appleは失敗の回数を制限していなかったので、時間をかければ解読可能になったということです。

これは先日お伝えした、FBIがAppleに要求したロック解除の再試行の回数制限撤廃の要求の話と元は同じで、暗号鍵と暗号化されたデータが両方とも存在すれば、あとは回数をこなせばいつか解読できてしまうということです。

つまり、暗号化システムの管理においては、暗号化データと暗号鍵のペアを確実に分離し、第三者が同時に両方を取得できないように対策をすることが重要になってくるのです。

暗号化することで、どんな攻撃に備えるのか?

ある会社が情報漏えいを一度経験すると、その会社の情報システムに詳しくない多くの人々もセキュリティを意識し始めます。それは悪いことではありませんが、多くのセキュリティに関する誤解を生む危険性があります。特に「データを暗号化していればよかった」とみなさん単純に思ってしまうようで、暗号化神話とまでは言わないものの暗号化に対する一般の方のセキュリティへの単純な信頼というものは意外と高いものもと感じられます。

しかし、暗号化ですべての攻撃を防げるわけではないので、そのような誤解を生まないためにも、暗号化することで、どのような攻撃を防ぐことが可能になるのか理解しておくことはとても重要です。

暗号化することで、一番セキュリティ効果が現れるのはローレベルコピー対策です。物理的ハードウエアの場合は、ディスクの内容をまるごとコピーされてしまうようなことは少なかったのですが、クラウドによるシステムの仮想化が多い現在では、スナップショット機能や、テンプレート機能など、簡単にディスクのコピーを作ることが可能ですから、暗号化が非常に効果があります。また、高度なアクセス権を設定可能な暗号化では、許可ユーザ以外からの暗号化領域へのアクセスを拒否しますから、OSレベルでのセキュリティに関しては非常に強度になります。

しかし、そのようなローレベルの攻撃でなくアプリケーションレベルでの攻撃の場合、暗号化の効果は低くなります。この場合、アプリケーションが暗号化領域へのアクセス権を既に持っているので、そのようなアプリケーションの脆弱性を利用した攻撃には弱くなります。

つまり、暗号化することで、いくつかのセキュリティの問題が解決しますが、それだけではすべてを解決することはできません。暗号化で何を解決することができるのか理解して上でご利用をしていただければと思います。

データベースの暗号化とSQLインジェクション対策

「データベースを暗号化して保護する」と表現すると、安心してしまうかもしれませんが、それで完璧というわけではありません。暗号化していても正当な手続きを経ていれば、どんなデータへのアクセスも可能だからです。

特にSQLインジェクションは非常に厄介な攻撃です。アプリケーション側の不備を利用して正式なデータベースへの問い合わせを発行するのでデータベース側で対策をとるのが難しくなります。このため多くのベンダーがWAF(ウェブアプリケーションファイアウォール)と呼ばれる商品を販売しています。

また、商用データベースに関していえばオラクルDBでは「Oracle Audit Vault and Database Firewall」、MySQLでは商用版に「MySQL Enterprise firewall」などの商品が存在し、SQLの攻撃パターンを認識してSQLインジェクションを自動的にブロックします。

データベースの暗号化はセキュリティ対策の有効な手段ですが、接続してくるアプリケーション側の潜在的な不備への対応は大変難しいものです。このようなことに備えて専用の製品を利用するなど適切な対策を講じていただければと思います。

ハードウエア保守サービスの落とし穴と暗号化の必要性

先日、あるお客様でデータベースサーバのハードディスクに障害が発生しました。メーカのハードウエア保守サービスに入っているので4時間以内に故障したディスクと交換してくれます。そこで実際に起きた出来事です。

保守員「交換したディスクは持ち帰りますね。」
お客様「念のため、ハードディスクの廃棄証明を出していただけますか?」
保守員「できません。そのような規約になっています。また過去に情報漏えいの事故はありませんのでご安心ください。」
お客様「では、事故が起きたときに追跡可能ですか?」
保守員「できません。ご心配な場合は交換ディスク買取か交換時の電磁的消去サービスご利用ください。」
お客様「それは今日できるのですか?」
保守員「いいえ。事前にご契約が必要です。」
お客様「・・・・」

メーカのハードウエア保守の中でハードディスクの故障による交換はもっとも頻度の多いものです。上記の例でもわかるように、廃棄証明を出してくれない保守サービスもあることにご注意ください。仮にハードディスクがRAID1(ミラーリング)などで構成されている場合は、交換したディスク内のデータは丸見えになり、非常に危険な状態です。

この場合、一つの解決策としてデータの暗号化は非常に有効です。データが暗号化してあればハードディスク交換による漏えい事故の防止に大きく寄与します。特にこのような契約上の問題に加えて、保守員のミスなども重なれば、いつ情報が漏えいしてもおかしくありません。機密情報を扱うデータを保存するサーバに関しては、もう一度ハードウエア保守の内容を確認すると同時にデータ領域の暗号化を検討していただければと思います。

FBIがAppleに求めた暗号化解除の捜査協力の中身とは?

今、米国内を騒がせている犯罪者に使用されたiPhoneの暗号化の解除問題ですが、ようやくFBIがAppleに求めた操作協力の裁判所命令の内容が明らかになってきました。FBIはAppleに対して暗号化解除そのものを求めたわけではなく、電子的にハッキング可能な特別なiOSの提供するように求めているようです。具体的には二つあります。

1)ロック解除の失敗後の再試行までの待ち時間の解除
2)ロック解除の失敗後のデータ自動消去の無効化

iPhoneではロック解除に失敗すると、再試行のための待ち時間が長くなり、さらに自動消去が有効あれば、10回解除に失敗するとデータを消去する機能があります。この二つを解除したiOSがあればFBI自身で電子的にロック解除の試行を繰り返すことができるので、暗号化の解除も簡単にできるということでしょう。Appleはその特別なiOSが今後のセキュリティの脅威になるとして作成を拒否しています。

このことからもデータ暗号化の有効性というのは、暗号鍵へのアクセス方法がどのように提供されているかというのが重要なポイントであることが分かります。暗号鍵へのアクセス方法が安易になれば、それだけ解析も容易になりますので、暗号化されたデータと暗号鍵を物理的に分離して管理することが、業務システムでは求められます。

暗号鍵の管理は誰の責任なのか?

先週、オープンソースデータベースMySQLの最新バージョン5.7.11の新機能としてInnoDB Tablespace Encryptionが追加されたとお伝えしました。これは透過型のブロック暗号を採用したもので、利用者が暗号化を意識することなく利用できるものです。しかし、マニュアルの注意書きには「セキュリティ基準を満たすには鍵管理システムの利用が必須」と書かれており、そのままで利用するのは問題があることが示されています。

また、今週に入ってAppleがFBIからのiOS9のデータ保護の解除依頼を拒否したというニュースが流れましたが、Appleの公式見解としては「ユーザー本人以外の解読は不可能」としています。AppleはiOS8以降はユーザの暗号鍵を自社で保存していないとしていますので、当然といえば当然なのですが、Appleが当局の犯罪捜査に非協力的であるような印象操作が行なわれているようにも見えます。

MySQLもAppleも立場として共通していることは、暗号鍵の管理はユーザ側の責任でということです。iOSでは暗号鍵は同一端末内に保存されており、暗号の解除はユーザ以外はできないことになっています。これはiPhoneのパスコードを忘れると初期化するしかないということからもかなり強力です。

しかし、データベースの暗号化となると鍵管理システムは必須です。特にMySQLのような複数のユーザで使用することが前提となっているようなものは、同一サーバ内に暗号鍵を保存することは危険な行為となり、セキュリティ基準を満たすことができなくなります。

システムのデータ暗号化を検討をするときは、暗号化そのものよりも、暗号鍵の管理をどうするかをしっかりと検討していただければと思います。