現実の障害対応から生まれたカオスエンジニアリング
カオスエンジニアリングというと、Netflixの取り組みが有名だ。2008年に、システム障害によりサービスが3日間停止したことがあった。Netflixはこのときに身をもってカオスエンジニアリングを実践したわけだ。
復旧のため総動員で対処にあたったその経験から、システム障害の影響範囲を把握し、実際の対応プロセスを考えるためには、実際にシステムに障害を発生させることに効果、意義があると認識した。結果として、同社の業務フローにカオスエンジニアリングが正式に組み込まれることになった。
Netflixはその後、動画ストリーミングサービスにビジネスをシフトさせる際、業務システムをオンプレミスからクラウドシステムに全面移行している。現在3億人以上とされる全世界の会員に対して、安定したサービスを提供し続けられているのは、同社のカオスエンジニアリングのおかげとも言われている。
ちなみに、Netflixは、Chaos Monkeyと呼ばれる自社開発のカオスエンジニアリングツールを持っている。サーバーをランダムに停止させたりすることができる。Chaos Monkeyはオープンソースとして公開されている。
本番環境や実環境で行うテスト
カオスエンジニアリングでは、意図的に障害を発生させる。本番環境に対して実施する場合もあれば、本番前のテストとして実施される場合もある。シミュレーターやツールを使って本番環境とは隔離したシステム環境で行う方法もある。
ただし、カオスエンジニアリングの主旨にもっとも近いのは、本番環境を使ったテスト・演習ということになる。だが、本番環境に無計画に障害を発生させるわけにはいかない。サブシステム単位で行うなど調整された実施が重要だ。
この点は、セキュリティ対策のペネトレーションテストにも似ている。ペネトレーションテストは、専門家が企業の依頼（契約）によって、稼働中にシステムやサービスに対して、脆弱性を突いた攻撃を仕掛けたり、ハッキングを試みたりする。これによって、脆弱性の発見、対策の有効性を明らかにする。このとき、テストする対象や手法、テストの通知範囲などを明確にしておかないと、トラブルになる。
ペネトレーションテストでは、実際のハッキングやマルウェアの実行が伴うので、制御された状態で行われないと、不正アクセスやサイバー攻撃と区別がつかないからだ。
インシデント対応訓練の側面を持つ
カオスエンジニアリングは、障害対応の訓練・演習という側面もある。ツールによって引き起こされた障害に、実際にエンジニアは手を動かす必要がある。訓練マニュアルだけ整備していても、いざというときに実践できるかどうかはわからない。
現実のシステムで障害が発生するので、机上訓練よりもスタッフの対応フローの習得効果が期待できる。マイクロサービスや外部API連携が複雑化しているサーバーシステムでは、ある障害がどこまで波及するかの予想、予測は困難だ。こういった見落としを洗い出すことができれば、対応プロセスの改善につなげることができる。
サイバー演習のひとつに「レッドチーム・ブルーチーム演習」がある。社内の専門家が攻撃者役（レッドチーム）を演じ、演習環境システムや時として実システムにサイバー攻撃をしかける。これをセキュリティ担当者や企業内CSIRTが防御にあたる（ブルーチーム）。攻撃シナリオはあらかじめ決められることもあれば、どんな攻撃がどこからくるのかわからない状態で行うこともある。
レッドチームは攻撃者視点で、ソーシャルエンジニアリングやフィッシング、脆弱性攻撃を行う。ブルーチームはこれをいち早く検知し、侵入を阻止したりマルウェアの排除、あるいはしかるべき機関への通報や連携などを行う。この演習は、セキュリティ対応チームの対応力を強化する訓練と、防御策や対応プロセスの改善という目的がある。
走りながら直すことで稼働率を下げない
理想的（？）なカオスエンジニアリングでは、むしろマイナーな障害が散発的に発生しても、DevOpsチームやSREが通常業務としてそれらに対処する状態となる。結果として、大規模なシステム停止やサービス停止が起きずに全体の稼働率、信頼性を底上げする。
システムを完全な状態で維持できても、障害時に全システムが1日、3日とダウンしてしまうなら、小さい障害対応をこなしながらシステムを維持したほうがよいという考え方が成立する。ならば、障害が、カオスエンジニアリングツールで引き起こされたものでも、実際に起きた障害でもどちらでもよい。
理屈ではこのようになるが、これを業務フローとして実装するのは簡単ではない。まず、システムの異常検知とその対応はできるだけ自動化する必要がある。そして、異常を検知するためには、正常な状態を客観的に把握する必要がある。つまり、システムの状態はデジタル化され、可視化されている必要がある。そのうえで、なにが異常なのか、アノマリーの判定を行う。
現代のサイバーセキュリティは境界防衛とマルウェア検知に加え、SIEMやXDR、あるいはSOCといった手法でサーバーやネットワークトラフィックのログ監視、イベント監視が不可欠とされている。異常検知の自動化も進んでいる。そのため、上記と同様に、システム可視化、検知や対応の自動化が求められている。そして、これを実現するには、やはり正常状態の把握が不可欠だ。正常な状態を認識できないとなにが異常なのか、攻撃なのかを判定できない。
カオスエンジニアリングとサイバーセキュリティの違い
以上のように、カオスエンジニアリングとサイバーセキュリティにはいくつかの共通点が見られる。システムの安定性、信頼性の向上は、システムの安心・安全にもつながるので、両者ともに目指すゴールは同じだからだ。
しかし、各論部分では相違点もある。まず、カオスエンジニアリングで実践する障害は、本番環境に実害を与えるリスクが避けられない。しかし、ペネトレーションテストやレッドチームの攻撃は、システムに被害が及んでもデータが外部に流出したり、本当の攻撃者の手に渡ることはない。この点に留意は必要だろう。
カオスエンジニアリングの障害は、意図的かつリアルなものだ。直接的な狙いは、障害時のシステムの挙動の把握、スタッフの対応力、回復力の向上にある。対して、ペネトレーションテストや演習では障害や攻撃は疑似的であり、あくまでテストだ。狙いは脆弱性の発見と防御力の評価となる。また、カオスエンジニアリングは、DevOpsスタッフ、SREが担当するが、ペネトレーションテストや脆弱性診断は通常、外部の専門家が行う。レッドチームは内部のセキュリティエンジニアが担当する場合もあるが、外部の専門家に依頼して、内部エンジニアやCSIRTスタッフがブルーチームとなる場合もある。
参考として、カオスエンジニアリングとペネトレーションテストの違いを簡単な表にしてみた。
参考：カオス・エンジニアリングとは（IBM）
https://www.ibm.com/jp-ja/think/topics/chaos-engineering
