DevOps の「Build to Fail」哲学はセキュリティ上のリスクとなるか?
ベタリッジの見出しの法則に反して、簡単に答えると、答えは「イエス」です。 しかし、今日のテクノロジーに関わるすべての事柄と同様に、長い答えはそれよりも少し複雑です。
DevOps は、あらゆる業界でかなり普及していると思います。 すべての組織がこのアプローチのあらゆる側面を採用しているわけではなく、Netflix のようにその原則に熱心に忠実に従っているわけでもないが、これは間違いなく「起こっていること」だ。
直接的な証拠ではありませんが、2018 年のapplication配信の現状について、3,000 人を超える回答者にデジタル トランスフォーメーションがapplicationの決定にどのような影響を与えているかを尋ねたところ、上位 3 つの回答のうち 2 つが「IT システムとプロセスに自動化とオーケストレーションを導入する」と「applicationsの開発方法を変更する (アジャイルに移行するなど)」でした。 私にとって、これらはどちらも、最新のアーキテクチャでapplicationsを開発および提供するための DevOps アプローチの少なくとも一部を採用したことに対する推測される反応です。
したがって、組織が DevOps に関連するツールやテクニックの一部を採用している場合、他のツールやテクニックも採用していると推測できます。 その 1 つは、(ドラマチックな音楽を流しながら)「失敗するように建てる」ことかもしれません。
さて、この表現はいくぶん不正確です。なぜなら、故障するシステムを設計している人は誰もいないからです。 しかし、彼らが実際に行っているのは、障害に強いシステムを設計することです。 つまり、たとえばインスタンス (サーバー) がクラッシュした場合、システムは、停止したインスタンスを削除し、その代わりに新しいインスタンスを起動することで、状況を自動的に処理できる必要があります。
出来上がり！ 失敗するように作られています。
これは確かに望ましい反応ですが、特にシステムの負荷と需要が大きい場合には、このアプローチには考慮する必要があり、その後対処する必要があるリスクがあります。
2017 年初頭の Cloudflare の脆弱性について考えてみましょう。 Cloudflare は、この問題に関する自社の報告において見事な透明性を示しており、基本的に、この問題は HTTP パーサーの拡張機能の欠陥によって引き起こされたメモリ リーク (潜在的なデータ漏洩につながる) であると指摘しています。 簡単に言うと、バグによってメモリ リークが発生し、インスタンスがクラッシュしました。 これらのインスタンスは、失敗するように構築されているため、強制終了され、再起動されました。
念のために言っておきますが、これは「バグについて Cloudflare を非難する」ための投稿ではありません。 開発者として、自分の欠陥がこのように公にさらされることに私は非常に同情します。 何かがクラッシュしたり、メモリがリークしたり、あるいは完全に失敗したりする理由を発見することにほとんど関心がない状況では、私はあまり同情しません。
それが今日の投稿のポイントです。 なぜなら、DevOps 哲学では、障害後の調査に対して自由放任主義的なアプローチを採用する傾向があるからです。
サービス/アプリの障害に対して、可用性を確保するためにサービスを強制終了して再起動することは、クラッシュを調査して原因を突き止める限り、完全に合理的です。 アプリは理由もなくクラッシュすることはありません。 倒れた場合は何かが押したことになります。 10 回中 9 回は、悪用できないエラーのようです。 ブログ記事を書くような内容はありません。 しかし、悪用されるのを待っている深刻な脆弱性が 1 つあるだけで、他の 9 つの脆弱性に対する一見無駄な労力をかける価値があるのです。 なぜなら、それはブログ記事を書く内容だからです。
それを無視するのは合理的ではありません。
障害やその他の問題の監視とアラートも、包括的な DevOps プログラムの重要な要素です。 これが、総合的な DevOps アプローチを構成する CAMS の「S」です。 文化、自動化、測定、共有。 DamonとJohn (2010 年にこの頭字語を作った人) は、単にピザとビールについて話していたわけではありません (ただし、それは DevOps の文化の「C」を奨励する良い方法です)。 それはデータとシステムの状態に関するものでもあります。 知ることで利益を得られる人々が確実に知ることが重要です。 これにはシステムの障害も含まれます。
障害、特にクラッシュは放置すべきではありません。 パイプライン内のシステムがクラッシュした場合、誰かがそれを認識し、誰かがそれをチェックする必要があります。 無視するとセキュリティ上のリスクとなります。 さらに悪いことに、それはあなたの環境、あなたのシステム、そしてあなたのコードなので、回避可能なリスクです。 あなたには完全な制御権があるので、それを無視する言い訳はありません。
つまり、一言で言えば、「Build to Fail」はアプリ、そしてビジネスにセキュリティ リスクをもたらす可能性があるということです。 幸いなことに、哲学が書面上では「失敗するように構築されている」のではなく、実際には「失敗を無視するように構築されている」ことを保証すれば、これらのリスクは完全に管理可能です。
可用性を高く保つために再起動する場合でも、クラッシュしたものには注意してください。 間違った理由で Twitter でトレンドになることから自分自身 (およびビジネス) を守ることができるかもしれません。