PPAP問題はパスワードをメールで送るのを止めても解決しない

PPAP(パスワード付きZIPファイルと、そのパスワードを別送する)が無意味どころか、むしろ危険を増している事がようやく認識されるにいたった。だが、もう一つの問題、そもそもZIP2.0暗号方式を使って暗号化することの無意味さが知れ渡っていないようだ。

ZIP2.0暗号方式には計算量的脆弱性があり、比較的少ない計算量で総当たり攻撃をおこなえることが知られています。ハイエンドGPU(RTX 2080Ti 価格20万円程度)を4枚搭載したパソコンを使用すれば、15桁のパスワードでも15時間程度で解読できてしまう事が報告されています。ということは文字数を増やして16文字にすれば56日となるかというと、これ以上パスワードの文字数を増やしても解読に変わる時間は延びません。内部的に96bit(15文字程度)の状態しか持てないため、これ以上パスワードを長くしても意味が無いのです。

ZIP形式のファイルはこの問題を解決するために、今ではAES方式暗号に対応しています。ですが、Windowsが標準ではAES方式のZIPファイルに対応していないために、利便性を優先してZIP2.0を使用する事が常態化しています。セキュリティは利便性とのトレードオフになる事が度々ありますが、利便性を優先して実効性のない暗号方式を採用し、そのために無駄な作業や別の危険を増やすのは本末転倒でしょう。

暗号化したファイルのパスワードをメール以外・・・例えば電話で伝えるのは進歩です。でもZIP2.0形式を使い続けるなら、そこに実効性はありません。利便性と実効性を考えたなら、素直に暗号化などせずに添付して送るのが一番良いでしょう。

ではどうすれば良いのでしょうか?私がお勧めするのはメールを使用しない事です。メールの根本的なセキュリティ問題は認証機能が無い事にあります。そこで認証機能のしっかりしているSNSなり、Google Drive等のストレージサービスなりを経由して送るわけです。この時使用するサービスは、出来ればデータを受け取る側に用意して貰うことが重要です。アップロードする場所を指定するやりとりの中で、重要なデータを送る前に相互に認証を行う事ができます。

セキュリティ上、メールサーバーはどんなサービスを利用すべきか。

業務上使用しているメールサーバーのセキュリティについて考慮したことがあるだろうか?実態として問題なく利用できるメールサービスは限られている。

セキュリティ上、パスワード漏洩等のインシデント発生時に被害の程度や範囲を特定する必要がある。このためには最低限でもPOP/IMAP/SMTP/WebMailの認証ログを閲覧し不正な接続の有無や接続元を特定する必要がある。だが実態として認証ログを閲覧出来る事が明記されているメールサービスは少ない。

サービスを提供する事業者は第三者間の電気通信を中継している都合、電気通信事業者とてし法律の制約を受ける。そこには通信の秘密を守る義務が含まれており、通信相手の接続元などの情報を提供することが出来ないためだ。

自社でメールサーバーを運用するのであれば、電気通信事業法上の制約を受けることなくログを閲覧出来る。かといってメールサーバーの運用には多くのノウハウがあり、中小企業でメールサーバーを運用できる技術者を確保する事は難しい。

以下にセキュリティ上の認証ログを閲覧出来るメールサービスを例示しておく。色々と探したのだが、三つしか見つけることが出来なかった。

Google Workspace
Microsoft 365
カゴヤ・ジャパン株式会社 メール専用サーバ

番外として下記も紹介しておく。認証ログを閲覧する事は出来ないが、代わりに接続元IPアドレスを制限する事が出来る。境界型セキュリティで安全を担保する前提であれば、接続元IPアドレスを制限したり、代理サーバーを介在させたりすることで、同様の要件を満たす事はできる。
WebArenaメールホスティング

Excelのパスワードを解除する方法

Excelのパスワードを解除する裏技を求めて、当WEBに来る方が少なくない。 「ブックの保護を強制的に解除する」は保護をすることで安全に隠せている気になっている記事への警告の意味で書いたので、パスワードが分からなくて困っている人へと補足情報を載せておこうと思う。

避けては通れない法律的な話し

まず法律的なことを覚えておいて欲しい。

何らかの方法でパスワードを調べたり、調べたパスワードを保管したりする行為は「不正アクセス行為の禁止等に関する法律」に抵触し、刑事罰の対象となる。例えファイルの中味を閲覧しなかったとしても、パスワードを調べたり、保管しているだけで処罰の対象となる。

裏技などを使ってパスワード(技術的利用制限手段)を迂回したりする行為は「著作権法」に抵触し、これまた刑事罰の対象となる。 著作権侵害の多くは親告罪だが、技術的利用制限手段の回避は非親告罪となる。

また裏技をつかってパスワード (技術的利用制限手段) を迂回するためのツールを提供する行為は「不正競争防止法」に抵触する。平成30年からはツールを提供するだけではなく、依頼を受けて役務を提供する事も処罰の対象となる。

以上のような法律があるので、いくら探しても「パスワードを解除して欲しい」という依頼を受けてくれる人は見つからない。Excelのファイルを解析してパスワードを解除するようなツールも見つからない。仮に技術的かつ予算的に可能であっても、家族や親友からの依頼でも無い限り、リスクが大きすぎて受けられないのだ。

とはいえ、パスワードが分からなくて途方に暮れている様もよく分かる。解決方法はただひとつしかない。技術的な知識と、法律的な知識を自ら身につけ、自らの手で作業するしかないのだ。

裏技による迂回方法

ブックやシートの保護パスワードや、VBAのソースコード閲覧パスワードなどは裏技的な方法で解除できる。実際に解除する方法は「Excel の各種パスワードを突破する方法まとめ」に良くまとまっている。新たに追記することはしない。

読み取りパスワードの解除

読み取りパスワードだけは総当たりで解除するしかない。だが、辞書に載っているような単語だけであるとか、あるいは6~7文字程度のパスワードであれば、解除できなくもない。

パスワードの解析によく使われるのは「John the Ripper password cracker」と言うツールだ。

私の使っている20万程度のパソコンでもGPUを使うと3,000パスフレーズ/秒程度のスピードで解析を進めてくれる。英数だけで構成される5文字程度のパスワードなら、最悪でも60時間程度で解析が終わる計算になる。辞書に載っているような単語、十万語程度を対象とするならば、数分で終わってしまう。

最高スペックのGPUを使うなら1桁程度は早くなる。IaaSで高速なサーバを複数台レンタルするなら2桁程度は早くなる 。6文字程度のパスワードなら総当たりでも 数日程度で 割り出すことが出来るし、そのために発生する費用は10万円にもみたない。

Postscript #1

そんな分けだからパスワードの分からなくなったファイルのことはキッパリと諦めて、ファイルをゼロから作り直すことを第一選択肢として考えたほうが良い。

Postscript #2

いまどき7文字程度のパスワードしか設定していないのは、実効性が無いので止めておいたほうが良い。無駄な仕事を増やしているだけに過ぎない。

DELLのセキュリティー事件簿

元記事:実態調査が示すセキュリティー事故の最新動向

DELLのもうちょっと良い事例は無かったのだろうか?
インシデント(セキュリティー事故)が発生するのは仕方ないにしても、あまりにも稚拙な対策が混じっていて失笑を禁じ得ない。

CASE1、CASE2・倫理観低下が招いた事故

論理感等という曖昧なものに原因を求めてはならない。分からない言語のメールだからそれを無視したり、業務効率向上の為のチャットソフト利用を拒絶する事が、論理感の高い行動とは言わないだろう。

根本的な原因は、恐らくはリスクのある外部サービス利用に対する過度な制限や、外部サービス利用承認プロセスの不備、ネットワーク利用状況の監視体制の不備にあると推測する。下手な利用制限がかかっていなければメジャーな翻訳サイトを避けて稚拙な翻訳サイトを使ったり、適切な監視がなされていればチャットソフトの利用に気がつかないと言うことはないからだ。

制限、許可、監視のバランスがとれていないことが根本の原因にあるなかで、制限だけを増やすのは問題の解決には至らない。制限を回避する新たな方法を編み出すようになり、従業員との信頼関係が損なわれる結果が目に見える。

CASE3・CASE4・ランサムウェアに感染

そもそもバックアップを取れていないことが致命的に問題だ。バックアップがとれていればデータが失われても1日分程度の話しであり、データを失うと言う致命的事態には陥らない。バックアップは一般ユーザーの権限ではアクセス出来ない(最低限で書き込めない)場所に、過去4~5日分(気がついたときには上書きされていたら意味が無いので、夏期休業などの最長休業期間より長い日数分)をバックアップしていれば良い。

標的型メールを模倣する訓練において開封率の低下を目指すことに意味は無い。本来なら開封した場合のエスカレーションが確実に行われることや、開封によって感染したことをセキュリティ監視チームが発見できる事が重要になる。なぜなら100人中1人でも開封すれば被害に繋がるし、またどんなに訓練を重ねたところで、文面などから完璧に不正なメールを判断するのは不可能に近いからだ。

CASE6・CASE7・基本的な対策を怠った

CASE6のすべてのPCのOSを最新に するのは確かに必要な処置だろう。だが起こった問題「商談情報を撮影して個人のPCにメールで送ったりしていた」に対する対策としては「機密情報の撮影を禁止」と言うルールを設けただけである。いかにルールを作っても、ルールが守られていることを監視監督する等の運用面が苫なわなければ、仕事のためにルールを無視する事が必ず起こる。

CASE6の根本的な原因は、メールの送信先や送信元に対する監視が機能していない事にある。個人で取得していると思われるメールに対する送信だけでも監視していたなら、問題が発生する前に警告する事が出来たはずだ。

CASE7についてはログが無い以上、今後調査が進展する可能性もない。「漏洩した情報を特定できない」という報告をする以外にない。

セキュリティ上、クラウドサービスを業務に使ってはならないとき・・・

「オンプレミスに比較して、クラウドはセキュリティが心配・・・」と言うユーザーに対して「クラウドベンダーと御社とどっちのセキュリティが上だと思ってるの?」というのは昔から良く話しとして見かける。実はクラウドサービスのセキュリティで気をつけるべき視点がひとつある。インシデント発生時に速やかな対応が可能か否かだ。

一流のクラウドベンダーならユーザー側に起因するインシデント発生時の対応も考慮されている。だが、二流三流のクラウドベンダーとなるとかなり怪しい。ユーザー側の原因でインシデントが発生した時に、影響範囲特定に必要なログ等の提供を受けられない可能性がかなり高い。例えば以下のシナリオのような状況が考えられる。

インシデントシナリオ#1
自社のWEBサービスがSQLインジェクション攻撃を受けた。この場合は影響範囲の調査にデータベースサーバの監査ログが重要な役割を果たす。もしこの時、ベンダーの提供するデータベースが他のユーザー企業とインスタンスを共有している場合、監査ログには他のユーザー企業の発行するSQL文まで含まれてしまう。ベンダー企業が監査ログをユーザー企業ごとに分割するような対策を事前に取ってない限り、迅速な対応は期待できない。

インシデントシナリオ#2
メールアカウントのユーザーIDとパスワードが漏洩して第三者が閲覧した可能性がある。この場合にはメールサーバーの認証ログを閲覧して、不自然なな時間帯や接続元からの認証、認証エラーの有無を確認したい。もしこの時、ベンダーの提供するデータベースが他のユーザー企業とインスタンスを共有している場合、そこには他のユーザー企業のログも含まれている。さらには通信事業者には通信の秘密を守る義務が課せられている。通信時間帯や接続元IPアドレスは通信の秘密に含まれるため、頑なに開示してもらえない可能性がある。こうなると被害届をだして事件化しないと、影響範囲の特定も出来なくなってしまう。

無論、きちんとしたベンダーは回答を用意している。AWS AuroraDBやSQL Azureには監査ログの機能がある。オブジェクトストレージのS3はアクセスログを提供している。GSuiteやOffice365も認証ログを提供している。

対して国内ベンダーに目を向けると、大手ベンダーでもその辺りがかなり弱い。

例えばさくらインターネットがS3互換としているオブジェクトストレージにはアクセスログの機能が無い。

あるいはNTT Communicationのメールホスティングサービスにはメールの送信ログに対する検索機能はあるが、認証ログの提供はない。法的な問題もあるので提供が難しいのは分かるが、せめて認証成功のログ程度はないとインシデント発生時に対応出来ない。

ベンダーの多くは電気通信事業者として「通信の秘密」に関する義務をおっている。何時何処と通信をおこなったかは「通信の秘密」に含まれるため、電気通信事業者としては安易にログを開示する事は出来ない。ユーザー企業に公開できるのは、ユーザー企業の管理下にあるシステムのログだけになるが、事前に準備を整えていない限り共有部分のログ提供には時間がかかる。

クラウドサービスを採用するにあたっては、セキュリティ監査に耐えるだけのログ出力機能があるか否かは確認した方が良い。もしそれらのログ出力機能が無く、インシデント発生時に相応の対応が必要なら、契約に調査対応への協力義務を盛り込む程度のことは検討しなてくはならない。

※クラウドベンダーの対応状況は2019年9月時点のもの