MENU

ランサムウェア騒動と情報漏えいに思う事

イラストAC/asakuracさん

アイキャッチ・画像:asakuracさん

目次

はじめに

ニコニコ動画に発生したサイバー攻撃がシャレにならない事態になりました。身代金が安すぎる、身代金のオカワリ、そもそも情報を不正に盗まれた被害者なのに加害者みたいな扱い、等々。情報はそもそも形がないので、事件の規模も事態の終結もあいまいで後始末が大変なのです。絶対当事者にはなりたくないと、心より思います。
この事例でもはっきりと傾向が読めるのですが、現在のサイバーセキュリティは侵入を防ぐ事に注力しています。ですから、一度侵入を許してしまったら最後は無力な様をさらしてしまいます。”いや、ちゃんと暗号処理を施しているから大丈夫だ!”と、専門家はコメントしますが、そもそも大丈夫である事を証明する術がないのです。言っている傍から漏えいしているのかもしれません。

情報を人質(ランサム:ransom)に取る攻撃

そもそも、情報が人質になってしまうとは、どういう状態なのでしょうか。侵入した攻撃者は、手にいる情報を片っ端から暗号化してしまいます。するとそのデータは攻撃者が所有している鍵でしか復号できなくなってしまいます。攻撃者はこの鍵に法外な値を吹っかけてくるのがランサム攻撃のおよそのストーリーです。
つまり、ランサム攻撃自体は情報漏えいを意味しているわけではありません。ですが、暗号処理の結果と接続記録があれば、なにを、どれだけ、漏えいしてしまったかを、犯人が証明できてしまいます。この事実が強力な脅威となり、被害者はお金を払ってでも対処せざるを得ない状態に陥るのです。

”秘密”の管理に限界がある

ITテクノロジーが発達した現在は、情報のほとんどはデジタルデータである事がいうまでもありません。だからこそランサムウェアがせっせと暗号化して人質にできるのです。このデジタルデータを守るため、企業はさまざまな取り組みを行い対策を練っています。例えばISO27001(ISMS認証)などが有名です。過去からの知見を整理統合し、基準を設け監査する事で情報資産を守る組織を作ります。

ITに携わる企業であれば、とにもかくにも実践し認証を取得すべきです。(詳細は専門家にお任せします)このブログでは、むしろISMS認証の検査項目の枝葉を切り落とす事が目的です。ですが、もちろん切り落とす事の効果を理解するためにはISMS認証を理解する事も重要です。うーん、だから情報セキュリティは幅広くて面倒なんですよね…(^^;

秘密(形のないモノ)を管理する難しさ

私も、現役時代には、自らが指揮をとってISMS認証取得に注力した事もあります。アセスメントすればするほど膨れ上がる情報資産に嫌気がさしました。運用が破綻しないよう、情報の取捨選択にはかなり注意して対応した事を思い出します。
特に廃棄は重要な選択でした。廃棄すれば管理は不要ですからね。運用に差し支えない情報はできる限り廃棄して、残ったデータには適切な保管場所をあてがいアクセス管理を施します。大変でしたけど、まぁ経験できたことは自分の知見になったので、本当に経験できて良かったです。

さて、整理を進めていると、本当に守るべき情報資産が洗い出せます。まさしく事業に必要な「秘密」です。この秘密を管理すために厳格な運用体制や罰則などを制定し管理していくのです。
当然、常に秘密は増えていくので、常にISISのアセスメントは必須で、これが結構大変なのです。その時は漠然と”この秘密がなくなってしまえば、物事は簡単になるのに…”と考えていました。

(最新のセキュリティ技術でも)秘密の流出を予見は困難です

実際、どれだけ情報セキュリティに注力しても完璧はありえません。だって、情報システムを扱う人々は、ほぼ間違いなく失敗してしまいます。残念ながら。
ですから情報セキュリティは、失敗後のリカバリにも注力して運用設計を行います。予防においては、情報資産の物理的持ち出しの禁止、アンチウイルスソフトの導入、セキュリティ教育、社員とのNDA契約…事後においては、連絡網の徹底、迅速な対策本部の設営、迅速な現場復帰、市場への情報発信等ができないとなりません。怖いです、本当に…
このように、情報セキュリティは過去より蓄積された経験をもとにした技術で運用する「予防と対処」だと私は理解しています。
様々な叡智を活用して、常によりよい運用をしていくのITには必須です。守るべき情報資産の価値に見合ったコストを用意し、粛々と推し進めるべきです。

ランサム攻撃に「知らない」で対抗

さて、改めてランサム攻撃の対策に立ち戻りましょう。
ランサム攻撃は秘密を暗号化するとともに認識した事実を武器にしてきます。そして、今の情報セキュリティは、この秘密をいかに守るか、もしもの場合はどうするかが中心です。守るものがある情報セキュリティの方が分が悪いのは明白です。ちょっとの隙も見せられないのですから…
そこで、私は、この守るべき秘密をなくす事が新たな対策方法ではないかと考えてました。秘密がなければ、人質にはならないですし読まれても問題はありません。問題ないから漏えいもないという理屈です。このように秘密を無くしていけば無くした分だけ、情報セキュリティの負担が削減できます。私はその秘密を捨て去るために、AKIを考案しました。

AKIは相互押印という特許技術を用いて情報に真正性を与える技術です。真正性を作成する際に、ついでに「パスワードレス暗号」も行える様に設計しました。つまり、AKIを使って「人質にされる前に自ら暗号化してしまう」のです。(^^;
暗号化されていれば、ランサムウェアに攻撃されたとしても「情報漏えいはしていない」と言い切る事ができます。相互押印を使うことで、復号するには相互押印の認証を行うしかありません。その認証は非対称鍵暗号を使ったゼロ知識証明で行われるので、利用者はパスワードなどの復号情報は知らされません。パスワードがなければ漏えいしても論理的には「安全と言い切る」事ができます。この言い切れるという事実を作り出す事が、これからの情報セキュリティに必要だと私は考えています。

AKIでランサム攻撃に対応する

新しい仕組みが普及するには、既存システムとの親和性も必要です。大変な思いをしないとシステムに組み込めなければ、せっかくのアイデアも普及しないです。
ご安心ください、大丈夫です。(^^)
そのような状況を十分に吟味しました。AKIは既存システムへの組み込みもさほど困難ではありません。

AKI Archiverによる情報の保護

AKIを使って情報を「鍵付き書庫にアーカイブ」として構築するのが簡単です。
サービスが「作り手」としてアーカイブを作成したのち「読み手」として都度利用します。サービスが作り手と読み手を兼ねるので、AKIの利用者認証がサービスになるので、情報セキュリティの視点では一般的なモデルです。
サービスで一つの認証情報を共有するイメージとなり、現状のITサービスのセキュリティモデルもほとんどがこの形式であり十分にセキュアです。

SignatureFormat+Encryption
AKIの特徴:
図 5  AKI署名フォーマット+暗号オプション

AKI TLSによる情報の保護

AKI TLSはネットワークペイロードごとに暗号オプション付きAKI Archiver処理を行う仕組みです。つまり、このAKI TLSのペイロードをそのまま保存する事で、情報のパスワードレス暗号処理も同時に処理ができます。
また「クライアントが作り手」と「サービスが読み手」となるので、利用者ごとのE2Eな処理と相まり非常にセキュアです。
しかしながらAKI TLSはAKI専用の認証機構を既存のWeb-APIに組み込む必要があり、実装作業が必要です。PoC検証ではWeb-APIへの実装難度も検証し問題ないことを確認しています。

ホットライン・AKI TLS・Web3.0時代の暗号基盤:
図 1 メッセージ交換

まとめ

ランサム攻撃の時事ニュースから、ちょっと視点を変えてAKIの特徴を説明しました。最初の実証実験から既に2年を迎えましたが、なかなか前には進まないです。組織人であったころの発信力と、ただのブロガーに過ぎない今の発信力の差には、改めて認識している次第です。半分趣味としての活動ですが、凶悪なセキュリティ犯罪のニュースを知るたびに、もどかしくも感じてしまいます。
そもそも、私に開発力があればもっと話は簡単なのでしょう。改めて、AKIのオープンソース化を推し進めて行ければと考えている毎日です。引き続き、どうぞよろしくお願いいたします。

イラストAC/asakuracさん

この記事が気に入ったら
いいね または フォローしてね!

よかったらシェアしてね!
目次