2019年08月30日

AWSの大規模障害について思うこと

最初に記載するが、これは個人の見解であり、会社は一切関係がない。
ただ少し思ったことをメモっておきたい、そう思っただけなのです。


■ことの発端

AWS大障害の真相、不具合が連鎖して冗長構成の「安全神話」が崩壊
https://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020600011/082900038/


この記事に対して、私は非常に危機感を覚えてしまった。
この記事を読むと、まるで「AWSは安全ではない」と記載されているように感じてしまう。
まず、それは正しくはない。
そもそも「安全神話」などなかった。
これは飛行機が落ちないと言っているようなもので、飛行機事故というのは今でも起きている。

そして次に、この一覧に掲載された企業は危機感を持った方が良い。
何故なら、掲載されていない企業のサービスの方が、圧倒的に多いからだ。

AWSを採用しているサービスが明かされているわけではないが、このくらいのリストに掲載しきれるような数では最早無いだろう。
そうなってくると、この一覧の見方が変わってくる。
この一覧から見える裏側というのはこうである。
これらのサービスは、

・AZ障害に耐えきれないアーキテクチャもしくはアプリケーションを採用している
・AZ障害を即時に復旧できない体制である

ということがわかる。

そして、凡その場合、このようにアーキテクチャがAWSのベストプラクティスに沿え切れていないサービスは脆いと考えられてしまう。
ようは「アタックしやすい」と、思われてしまう危険性が潜んでいる。

1つのAZ障害でサービスダウンまで追い込まれるということは、冗長構成がとられていない。
そうなると、DDoSには弱いと考えられる。
加えて、新しいアーキテクチャが採用されないと想定されると、セキュリティリスクの多いシステム構成になっているのでは?と思われてしまう危険性もある。

結論を記載すると、闇雲に攻撃対象を選定するくらいなら、このリストのサービスにセキュリティ攻撃を仕掛けた方が「攻撃が成功しやすいのでは」と思わせてしまうリストになっている危険性があるわけだ。

私はこれを強く懸念し、警鐘を鳴らしたい。
今回このリストに「載せられてしまったこと」を直ちに振り返り、リスクを解消しないと、次の攻撃はAWSの障害ではなく悪意のある第三者になってしまうのではと心配をしてしまうのである。


■自家製の飛行機に乗るのか?

先ほど、飛行機事故に例えたが、AWSはもはや大手航空会社の飛行機のように、誰もが落ちないと思って搭乗するようなサービスになってしまったと思う。

ごく稀に、飛行機は墜落する。事故が起きる。
しかし、凡そは想定通りに動き、飛ぶ。

飛行機事故を聞くと、怖くなるのは当然だ。
しかし、だからと言って「自分で飛行機を作って飛ばそう」と思うだろうか。
私はその方が怖い。

自分らだけが飛ぶ飛行機を開発して飛ばしておけば落ちないのだろうか。


これは「オンプレミスサーバに戻る」という意味合いで話をしている。
オンプレミスに戻るということは、飛行機を自家製にするということである。
今から自分で作った飛行機に乗ることは、費用対効果も悪く、間違いなくリスクは大きいと考えている。

今回の事故によってAWSはさらに学びを得、反省し、事故を振り返り、再発を防止して未来へ進む。
結果もオープンにしている。
飛行機事故も、詳細な報告を行っている。それは社会的な責任があるからで、それは多くのユーザがいるサービスなら何でもそのようであるべきだ。

たった1つの事故で、飛行機が怖くなり、自家製の飛行機に戻るユーザは一定数いるだろう。
ただそれは、非常に高コストであるため、お金持ちにしかまずなしえない。
多くのユーザはAWSに残存する。

そしてAWSのユーザができることは、真摯に現状を把握し、「今回問題なくサービスが継続できたサービスら」から学びを得て、それに自社のサービスを近づけていく、それしかない。
そのためには、起きたことを誤魔化さず向き合い、また同じことが起きた場合を想定して対策を練っていくしかない。
AWSは利用者も多く、ユーザ同士の繋がりも強い。
目を背けず、再発防止に取り掛からないと、先に書いたように攻撃の標的となりえてしまう。
そのようなことが起きないよう、すぐにでも対策を始めてほしい。

AWSに説明責任を果たさせるために待っている時間よりも、すぐに対策を始めてほしいと願う。


以上です。
posted by hinata_hisa at 21:38 | 東京 ☀ | Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする