カオスエンジニアリングでセキュリティを強化するための議論

緊迫した状況で頼りにするツールには、極限の条件下でテスト済みであるという安心感がほしいものです。たとえば、スカイダイビングに臨むなら、背中に装着したパラシュートが厳格なテストを受け、必要なときに確実に機能することを知っておきたいでしょう。

セキュリティ対策を支えるシステムも同じです。緊急時にシステムへ大きな負荷がかかったら、どうなるでしょうか？

カオスエンジニアリングは、制御された体系的な方法でシステムを限界までテストし、この問いに答えます。的を絞った実験を行うことで、チームはシステムが高負荷の状況に耐えられるか、あるいはそのために修正が必要かを判断できます。

カオスエンジニアリングとは？

カオスエンジニアリングの基盤にあるのは、カオス理論です。これは、一見ランダムで予測不能な出来事にもパターンを見いだせるという考え方です。こうした事象にシステムがどの程度対応できるかを戦略的な実験で検証すれば、同様の非常事態が現実に起きたときに、チームはより適切に備えられます。

セキュリティカオスエンジニアリングは、データ侵害や攻撃などの緊急事態で「最初に対応する」サイバーセキュリティシステムのテストに特化しています。チームは、起こりうる事象をシステムに注入し、その挙動を観察します。

VericaのCTO兼共同創業者であるAaron Rinehart氏は、The Secure Developerポッドキャストの第67回で、Snykの創業者兼社長であるGuy Podjarnyとカオスエンジニアリングについて語りました。Aaron氏は、セキュリティカオスエンジニアリングを「セキュリティが作動または発動すると予想される条件を、あらかじめ積極的に注入すること」と要約しました。

Capsule8のプロダクト戦略担当VPであるKelly Shortridge氏も、第63回でGuyと対談しました。セキュリティカオスエンジニアリングはシステムの限界をテストし、現実のセキュリティプログラムは決して真空状態に存在しないことを思い出させてくれる、と二人は話しました。Kelly氏は次のように述べています。「セキュリティカオスエンジニアリングの基本的な考え方は、『いや、現実はそういうものではない。失敗から得られる情報をすべて受け入れ、それを学びの機会と捉える、知的に誠実なモデルを持つ必要がある』ということです。」

セキュリティにカオスエンジニアリングが必要な理由

カオスエンジニアリングがセキュリティに不可欠なのは、予期せぬ事態や予測不能な事態に対して、セキュリティ対策が耐えられることを実証できるからです。最終的に、こうした実験はよりレジリエントな製品につながります。

Aaron氏は、セキュリティカオスエンジニアリングが開発チームとセキュリティチームにとって非常に有益である理由をいくつか挙げました。まず、予期せぬ事態に備えてシステムを事前に強化し、どんな状況でもシステムが意図どおりに動くという信頼を築けます。また、カオスエンジニアリングを活用すれば、セキュリティチームは問題が表面化する前にシステムの不具合を見つけられます。

Aaron氏はこれを、計画的な野焼きにたとえています。「私はミズーリ州の農場で育ったので、畑の計画的な野焼きのようなものだと思います。ただマッチに火をつけて燃やすわけではありません。郡に知らせ、救急隊や消防署を呼び、何かあったときのためにみんなに待機してもらいますよね。カオスエンジニアリングも同じです……本当の障害が起きると、人はパニックになります。認知的な余裕がなくなり、『これは侵害かもしれない。CEOから電話で、システムを今すぐ復旧させろと言われている。誰かがこの件で職を失うかもしれない』と考えてしまうのです。」

組織でセキュリティカオスエンジニアリングを始める方法

セキュリティチームがカオスエンジニアリングの実験を検討しているなら、Aaron氏とKelly氏からいくつかアドバイスがあります。

エンジニアリング上のミスに焦点を当てる

まずは、手作業によるエンジニアリング上のミスを明らかにする、的を絞った実験から始めましょう。たとえば、セキュリティカオスエンジニアリングの実験では、設定ミスのあるポートや過剰な権限を持つアカウントの悪用に焦点を当てられます。どちらも人為的ミスによってよく発生する問題です。

ただしAaron氏は、こうした人為的ミスについて次のように注意を促しています。「[人為的なミスは]エンジニア個人の責任ではありません。今日、私たちがものを作る際の規模、スケール、複雑さ、スピードを、人間が頭の中だけでモデル化するのは非常に難しいということなのです。」

「大きなことを一度にやろう」としない

Aaron氏は、1つの実験で多くを達成しようとすること（いわゆる「海を沸かす」こと）にも警鐘を鳴らしています。カオスエンジニアリングの実験では、的を絞った体系的な方法で、単一の障害を注入することに集中する必要があります。こうした戦略的な障害の注入は、一度に1つの問題をテストする点で、攻撃シミュレーションとは異なります。

Aaron氏はこう話します。「複数の攻撃ポイントを順に試し、システムに大量のデータを送ると、そのデータから何が壊れたのか、何が壊れなかったのか、何が機能したのかを見分けるのが非常に難しくなります……ノイズが多すぎて、可視性が損なわれてしまうのです。」

失敗を想定する

実験を始めると、システムが課題に耐えられなかったときに落胆しないことも大切です。失敗は、カオスエンジニアリングにおける最も重要な手段の1つです。Kelly氏はこう述べています。「セキュリティに必要なのは、失敗は避けられず、そこから大きな力を得られると受け入れる考え方への転換です。」

カオスエンジニアリングの未来

企業がクラウドへの移行を進め、システムが複雑さを増すにつれて、チームがカオスエンジニアリングを活用する重要性はこれまで以上に高まります。Aaron氏は、クラウドへの移行はカオスエンジニアリングを始める前提条件ではないと説明します。むしろその逆で、カオスエンジニアリングによって組織はクラウドへの移行に備えられます。新たなクラウド機能の有効性を導入当初からテストすることで、チームは今後もそれらを維持しやすくなります。Aaron氏の言葉を借りれば、「複雑なシステムを理解する唯一の方法は、実際に働きかけることです。」

セキュリティカオスエンジニアリングについてさらに深く知り、自社でどのように活用できるかを学びませんか？Aaron氏とKelly氏が出演するポッドキャストをお聴きください。

• 第63回：コンテナセキュリティ、マイクロサービス、カオスエンジニアリング：Kelly Shortridge氏

• 第67回：セキュリティカオスエンジニアリングとは？なぜ注目すべきなのか？：Aaron Rinehart氏

開発者セキュリティ、AppSec、DevSecOpsに関するコンテンツをもっと知りたい方は、今すぐThe Secure Developerを購読しましょう！