[Algoliaブログ翻訳] Saltインシデント: 2020年5月3日振り返りとアップデート

こちらのブログはAlgoliaのCo-Founder, CTOのJulien LemoineによるSaltStack Saltの脆弱性に関するAlgoliaへの影響とその対応に関するブログを日本語に翻訳したものになります。

まとめ & Key Takeaways
Waking up to the incident (インシデントによる叩き起こし)
The culprit: configuration management (犯人はコンフィギュレーション管理)
What was impacted (何が影響を受けたのか？)
How we responded: reclaiming the infrastructure (どのように対応したか？インフラストラクチャーの再生)
How did we get here? (これまでの経緯)
What we did so far: (やったこと)
What we plan to do over the coming days: (これから数日のうちに予定していること)
FAQs

まとめ & Key Takeaways

2020年5月3日、Algoliaのインフラストラクチャーは salt configuration management vulnerability CVE-2020-11651 の脆弱性によるアタックにより影響を受けました。2つの種類のマルウェアコードがAlgoliaのconfiguration managerに入り込みました – 1つは仮想通貨のマイニングをするもの、もう1つはバックドアサーバーとして動作するものでした。
マルウェアの性質からして、データのブリーチや、データの持ち出し、変更、消去、ダメージ等はありませんでしたが、5月3日においてはAlgoliaの検索サービスで2%未満のお客様において5分以上のダウンタイムが発生し、1%未満のお客様において10分以上のダウンタイムが発生しました。
2020年5月3日 17:33 UTC時点で、全ての9000以上のお客様のAlgoliaの検索サービスは通常通り稼働しているのを確認しています。
この経験から、Algoliaではセキュリティプロトコル、測定、モニタリングのレビューおよびアップデートを行い、サービスの更なる保護と強化を行っています。
Algoliaは、お客様からの信頼およびセキュリティとパフォーマンスを最優先に考えています。つきましては、今回のインシデントの詳細な経緯とFAQをお客様とAlgoliaコミュニティの為に公開いたします。

salt configuration management vulnerability (CVE-2020-11651 and CVE-2020-11652) のことをご存知の方もいらっしゃるかもしれませんが、これはいくつかの大企業においてもインパクトを与えたものになります。この脆弱性はsalt masterの通信プロトコルを含み、特に認証プロトコルに著しい欠陥があり、サニティチェックのバイパスを許可したり、通信のための鍵の不正利用を許可しセンシティブな内部機能を呼び出すことを可能にするものでした。

私たちはこの脆弱性を突く攻撃を2020年5月3日(UTC)の夜に受けました。

私たちAlgoliaでは、今まで常にこういった問題に関して、偽りのない透明性のある形での対応をしてきました。私たちはこれを公開post-mortemとして、このインシデントに関する全ての詳細な情報をAlgoliaのユーザーの皆さまにお伝えし、今後長期的に私たち自身を改善していきます。

Waking up to the incident (インシデントによる叩き起こし)

はじまりは5月3日(日)のパリ時間の午前3時12分に、Algoliaのコアエンジニアの1人の電話が突然鳴りだしたことでした。いくつかのお客様において検索のAPIが利用できなくなったことにより、複数のアラートが同時多発的に発生しました。インシデントの規模はAlgoliaのインフラチームを対応のために起こすのに十分なほど大きく、深夜時間帯に2人のエンジニアが追加で問題の調査に参加しました。

サーバーはfire(クリティカルな)アラートを上げ続け、次々とシャットダウンしていきました。そして、明確な原因も分からないまま、それらのサーバーへのリモートアクセスすらも出来ない状態になってしまいました。当初は大規模なネットワークアウテージを疑っていましたが、プロバイダの一つであるOVHが迅速に調査強力を行ってくれ、この仮説は否定されました。それと同時に、私たちのログの監査を行っている中で、不審なコマンドを発見しました。

The culprit: configuration management (犯人はコンフィギュレーション管理)

私たちはすぐにコンフィグレーションマネージャーがこのアタックの被害者であることを見出し、そして、ヨーロッパのクラスタにある多数のサーバーにマルウェアコマンドが広まっていることを確認しました。私たちのコードではない何かが私たちのインフラストラクチャーの一部で動作していました。

時に見落としがちなことですが、コンフィギュレーションマネージメントは、特に大規模なCloudでは非常に重要な役割を担います。数千台のサーバーにおいて、パッケージをデプロイしてインストールし、サービスをセットアップし、それらをメンテナンスしていくのを可能にするために、must-haveな機能と言えます。しかし、それらは膨大なサーバー群を司る特権的なアクセスを可能にするため、人間の身体で言えばアキレス腱のような存在になることもありえます。たった一つのミスで大きな痛みをもたらしてしまうこともあるといえるのです。

What was impacted (何が影響を受けたのか？)

500台以上のサーバーが影響を受け、それらのほとんどにおいてテンポラリにインデクシングが出来なくなりました。また、それらの中にはサーチ(検索)が出来なくなるものもありました。私たちのアーキテクチャデザインにおいて、アディショナルなサーバー群が検索トラフィックを引き継ぐようになっているため、それらは健全な状態を維持し、大部分のお客様に大きな影響を与えることはありませんでした。

サーバーを1台1台復旧させていく中で、私たちの最大の関心事は、この攻撃のスケールを正確に把握することになりました。そして、最初のクエスチョンはいつでも “データブリーチはあったのか？” です。マルウェアが実行したペイロードを分析したところ、この攻撃の目的は暗号通貨のマイニングのみであり、データを集めたり、更新したり、破壊したり、ダメージを与えるようなものではありませんでした。私たちは幸運であったとは言い難いですが、これは忘れることのない教訓となりました。

また、この障害によってネットワークのモニタリングがオーバーロード状態になってしまったものの、私たちのステータスページは全てがグリーン(正常であることを示す)となっていました。これは混乱と誤解を招くものでした。私たちは現在この修正作業を行っていて、検出した問題を反映させるためのステータスインディケーターを随時更新して参ります。

以下が、インデクシング(一部は検索サービスも含む)のダウンタイムのまとめになります。

約700あるクラスタのうちの15(全体の2%未満)で5分以上のダウンタイムのインパクト
6クラスタ(全体の1%未満)で10分以上のダウンタイム

How we responded: reclaiming the infrastructure (どのように対応したか？インフラストラクチャーの再生)

私たちはまずインシデントに関連のある全てのコンフィギュレーションマネージャーをシャットダウンし、後からフォレンジック分析を行うため、ファイルは保持しておきました。それから、プロバイダーたちとチームを組んで影響を受けた全てのサーバーを1台1台再起動し、その状態を調査しました。その結果、2つのマルウェアによる侵入が明らかになりました。1つは暗号通貨をマイニングするもので、もう一つはバックドアサーバーとして動作するものでした。これらの全てのマルウェアの排除を行い、ファイルを元の状態にリストアしてから、影響を受けた全てのサーバーに再インストールを行う計画を立てました。

私たちのスタンダードなプロトコルの一環として、定期的に https://status.algolia.com/ を更新し、サポートチームにご連絡いただいたお客様に状況をお伝えしました。

最初のアラートが発火してから7時間後に、全てのマルウェアを排除し、サーバーを再起動後、コンフィギュレーションマネージメントの作業に着手しました。復旧作業には多数のエンジニアが参加し、ダメージを受けたサービスのリビルドに不断の働きをしました。

How did we get here? (これまでの経緯)

影響を受けたコンポーネントは古いツールであり、これまでは問題なく動作をしていたものの、私たちは次の2つの四半期でこれへの対応を予定をしていました。現在はテンポラリな対応を行いサーバーの環境を守れるようになっていますが、この対応タスクを予定より前倒しして行おうとしています

What we did so far: (やったこと)

SaltStackサービスのアップデートを行い、私たちのサーバーからだけ接続を行えるようにするIPアドレスによるフィルタリングの設定を追加しました
SaltStackサーバーをスクラッチからインストールし直しました
アプリケーションサーバーとSaltStackサーバー両方で、SaltStackサービスとの通信に用いるセキュリティ鍵をローテーションさせました
全てのサーバーのsecretsをローテーションさせています
コントロールプレーンサービスのアクセスキーにおいて、IPアドレスの制限をアクセスが想定される特定のサーバーのみとしています

What we plan to do over the coming days: (これから数日のうちに予定していること)

コントロールプレーンサービスの全てを見直し、アクセス制御用のレイヤーを追加することで、単一コントロール障害がサービスの漏洩につながらないようにします
追加のセキュリティ対応として、SaltStackと接続したことのある全てのサーバーで西院ストールを行い、全てのサーバーに予期しない変更が無いことを確認します
Common Vulnerabilities and Exposures (CVEs)の監視とレビューを行うプロセスを確立します(例えば、祝日と週末が続くことでCVEが発見されてからパッチが適用されることに時間ががかからないように)
もし、SLAを守ることが出来ないインパクトが発生した場合、サービスレベル契約に基づいて適切なサービスクレジットをご提供します

セキュリティとサービスの稼働はAlgoliaにおける最優先事項です。したがって、このアウテージに対する言い訳はございません。このようなことが二度と起こらぬように努めて参りますので、今後とも引き続きよろしくお願い致します。

FAQs

このアタックによってエンドユーザーの検索体験にどんな影響がありましたか？
- 1%未満のお客様がデグレードな検索体験もしくは、検索のアウテージの影響を受けました
このアタックの間に私のサイトに影響があったかどうかをどのようにしることが出来ますか？
- もし、あなたが何も問題を認識していないのであれば、影響を特に受けていない可能性が高く、全てのセーフティメカニズムが動作としたと考えられますが、該当期間のステータスを確認したい場合はダッシュボードのMonitoringセクションのStatusタブをご覧ください。
一部のインフラストラクチャで動作していたAlgolia以外のコードは具体的に何をしていたのですか？
- 該当コードは仮想通貨のマイニングのために使えるだけのCPUを使おうとし、また、サーバーの再起動を防ごうとしていました。

どの程度の割合のAlgoliaのサーバーがこのアタックによって影響を受けましたか？
- 20%未満です。
全てのサーバーを再起動するまでに7時間かかったとのことですが、実際の検索のダウンタイムは10分程度のみというのはどういうことでしょうか？
- Algoliaのアーキテクチャにおきましては、クラスタにハイレベルの冗長性をもたせており、大部分のケースにおいてはクラスタ全体に影響はありませんでした。私たちは、データセンターのアウテージにも耐えうるアーキテクチャのデザインをしておりますが、今回はそれと似ているような状況でした。サーバーの中には自動再起動が成功しなかったものがあり、これらの特定のケースへの対応に何時間も要しました。

参考リンク