一時的なデータ露出をめぐる奇妙な事例

当社は通常、お客様のアカウントの検出結果やアラートを能動的に監視しているわけではありませんが、先日、自動修復への取り組みにおいてより積極的な役割を担ってほしいというご依頼をお客様からいただきました。お客様のご要望に応じていくつかの項目を注視していたところ、興味深い事象が発生しました。

当社のCTOが、AWS上で公開状態のRDSインスタンスが存在するというアラートを受け取りました。しかし、お客様に確認したところ、そのインスタンスはすでに存在していませんでした。さらに奇妙なことに、公開状態のRDSインスタンスが毎晩作成され、50分後には削除されていたのです。この種のアクティビティは、定期実行型の評価では容易に見逃されてしまいます。当社のCTOはただちにお客様へ連絡し、当社のインベントリから削除済みインスタンスのメタデータを取得しました。トリガーとなったイベントとインスタンス構成を徹底的に(そして数分で迅速に)調査した結果、別のデータベースの最新スナップショットバックアップをもとに、公開インスタンスが毎晩作成されていたことが判明しました。作成されたインスタンスは、既知の企業IPアドレスの短いリストに対してのみ公開され(これは良い知らせでした)、その後まもなく削除されていました。

調査
お客様も独自に調査を行い、これがデータセンターで実行されているETLの自動化プロセスの一部であることを突き止めました。クラウド側のスケジュールジョブが一時的なインスタンスを公開状態で作成し、アクセスを少数のIPアドレス(5件で、それでも多いように思われました)に制限したうえで、データセンター側が接続してデータを抽出する仕組みでした。実際のデータ変換がどこで行われていたのかは最後まで分かりませんでしたが、この状況においてはさほど重要ではありません。

これはセキュリティチームにとって興味深い課題を提示しました。アラート自体は正当なものでしたが、実際のセキュリティ上の問題は存在しなかったのです(もっとも、公開状態のRDSインスタンスよりも安全にこの状況を処理する方法は確かに存在します)。毎晩新しいインスタンスが作成されるため、当該インスタンスを例外登録するという選択肢はありません。アカウント全体をチェック対象から除外することもリスクを伴い、本当に露出しているRDSインスタンスを見落とす事態につながりかねません。タグに基づく例外設定でさえリスクがあります。誰かがプロセスを変更し、信頼できないIPアドレスに対してインスタンスを公開してしまう可能性があるためです。

得られた教訓
私の助言は、評価側を複雑にするのではなく、根本にあるプロセスの是正に注力することでした。実際のところ、このプロセスは手順の観点から理想的とは言えません。公開状態のRDSインスタンスを許容することは決して望ましい形ではないのです。必要になる場合もありますが、あくまで最後の手段とすべきです。本来はプライベートサブネットに配置し、必要な場所から専用接続またはVPNベースの接続を通じてアクセスすべきです。

今回はセキュリティ上の露出ではありませんでしたが、それでも学ぶべき興味深い点がいくつかあります。第一に、私はこれを「偽の誤検知」と呼んでいます。アラートは対処を要する実在の状態に対するものでしたが、この特定のシナリオにおいては必ずしもリスクをもたらすものではなかったからです。実際のデータ漏洩は発生していませんでしたが、お客様は調査を行い、当該リソースとプロセスを担当するチームとやり取りしなければ、それを知ることはできませんでした。

第二に、これはService Control Policiesで完全に防止しようとするのが難しい事例です。公開状態のRDSインスタンスを防ぐ条件キーは存在せず、セキュリティグループにおいてデータベースポート(あるいは任意のポート)の開放を防ぐ条件キーも存在しません。

第三に、インスタンスが一時的な性質を持つということは、リアルタイムまたは極めて短いサイクルで運用していない限り、その露出を見逃す可能性があるということです。私はこのテーマをインシデントレスポンスのトレーニングでも取り上げています。短い時間枠の中で何かが露出・抽出され、その後に証拠を消すために破棄されるという状況は数多く存在するからです。だからこそインシデント対応者は、常にデプロイメントへ直接踏み込める能力を持つ必要があり、過去にさかのぼって確認できるインベントリ(AWS Configや当社のようなサードパーティツールなど)へのアクセスを備えているべきです。APIコールだけでは文脈が欠けているため、何が起きているのかを十分に把握できない場合があります。今回のケースでは、露出そのものは検出できますが、どのポートがどこに対して公開されているかを確認するには、DBインスタンス(またはインベントリ)を直接見る必要があります。

第四に、予防的な選択肢が限られているため、発見的統制および是正的統制を活用しなければなりません。今回のケースでは、CreateDBInstance APIコールを直接検出し、PubliclyAccessible=Trueパラメータの有無を確認できます。さらに、公開状態のRDSインスタンスに対するCSPM(これもCSP提供のものか、当社のようなベンダー製のもの)による継続的な監視を強く推奨します。修復の面では、インスタンスの作成を検出した時点でそれを削除するという選択肢があります。ただし、より優れたアプローチはModifyDBInstanceを使用してPubliclyAccessibleパラメータを解除することかもしれません。その場合、公開状態のRDSインスタンスが許可されないと確信できるデプロイメントにおいてのみ、このような自動化を実装することが重要です。チームとの連携を怠ったために、3年間稼働してきた想定内かつ承認済みのデータベース接続を遮断してしまった日は、おそらく職務経歴書を引っ張り出すのにふさわしい日となるでしょう。

結果として、この事象はお客様にとってセキュリティリスクをもたらすものではありませんでした。しかし、より安全なプロセスの必要性を浮き彫りにし、お客様は現在、より安全な方法で対処するための選択肢を積極的に検討しています。この事例が特に興味深いのは、一時的なデータの露出、漏洩、持ち出しが現実の懸念事項であり、当初発見された内容が実際の攻撃と見分けがつかないものだったからです。掘り下げて初めて、当社とお客様のセキュリティチームは、それが想定されたプロセスの一部であると理解しました。各チームと緊密に連携して良い習慣を育てること、クラウドの極めて変動的な性質に対応できる監視体制を確保すること、そしてこのような異常な事象が発生した際には、当該デプロイメントの担当者と連携することが決定的に重要であると認識することが不可欠です。

クラウドにおいては、誤検知と本当に深刻な問題とを見分ける唯一の方法が、直接関与している担当者に確認することである場合もあります。シュレーディンガーの設定ミスに記したとおり、攻撃者はゼロデイ脆弱性に頼るのではなく、同じAPIコール、そして残念ながら同じアイデンティティを利用します。

ゲストスピーカー

Rich Mogull

FireMon クラウドセキュリティ担当SVP
RichはFireMonのクラウドセキュリティ担当SVPとして、最先端のクラウドセキュリティの研究と実装を牽引しています。RichがFireMonに加わったのは、Securosisのcあ CEO時代の研究をもとに立ち上げたクラウドセキュリティ自動化プラットフォーム、DisruptOpsの買収によるものです。25年以上のセキュリティ経験を持ち、現在はクラウドセキュリティとDevSecOpsを専門としており、約10年前からクラウドの実務に携わっています。SecurosisおよびDisruptOpsの創業以前は、Gartnerのセキュリティチームでリサーチ バイス プレジデントを務めていました。