月: 2020年12月

PaaSの請求額に愕然とした経験

たった1日の利用で750万円をGoogleから請求された企業

上記リンク先の企業は750万円の請求を受けたようだが、私自身も似た良いな経験はある。個人的に勉強がてらMicrosoftのAzule MLで遊んでいた。無料枠でリミットがかかるつもりで居たが、突き抜けて十数万円の請求金額が表示されていたのだ。あわててMicrosoftのサポート窓口に連絡して、請求を取り下げていただき事なきを得た。

IaaSやPaaSの使い方を試しながら学習する上で、この手のリスクは常に発生し、避けようがない。実験的に動かす場合にも、本番環境と同様に従量課金で料金が発生する。最初から完璧に習熟していて、絶対に間違えない人など居ない。いくら気をつけていたところで、見落としや設定ミスによる重課金が発生するリスクは常にあるのだ。

うっかり数百万円溶かしても「あほぅ」の一言で済ませてくれる組織でもない限り、実のところエンジニアは業務でPaaSを安心して使えない。「この機能を使えばこんなことが出来るはず・・・」と知識で知っていても、ミスを許容してくれる組織でない限り怖くて新しいことにチャレンジ出来なくなる。

クラウドへの移行を考えている・・あるいは既に実施している企業の役員の方には、この事を知っていて欲しいのだ。

ちなみに、色々と検索した限りでは、速やかに連絡すれば請求を取り下げてくれる事が少なくないようである。

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等のストレージサービスなりを経由して送るわけです。この時使用するサービスは、出来ればデータを受け取る側に用意して貰うことが重要です。アップロードする場所を指定するやりとりの中で、重要なデータを送る前に相互に認証を行う事ができます。