SysdigでAWS RDSのセキュリティイベントをハンティングする

本文の内容は、2022年5月4日にBrett Wolmaransが投稿したブログHunting AWS RDS Security Events with Sysdig(https://sysdig.com/blog/aws-rds-security-events-sysdig/）を元に日本語に翻訳・再構成した内容となっております。

AWS RDSサービス自体の管理については、責任共有モデルのAWS側に該当しますが、RDSセキュリティインスタンスの日々の管理は、お客様側の管理責任に該当します。共有責任に関して、利用者の義務は利用者がデプロイするAWSサービスに依存し、また利用者のデータの機密性、利用者の所属する会社の要件、適用される法律や規制を含む（ただしこれらに限定されない）他の要因もあります。

デプロイミスやRDSの構成に加えられたその他の変更は、データの流出やその他の重大な結果を含む、重大なセキュリティリスクをもたらす可能性があります。しかし、リスクの高い事象を見つけることは、適切なツールなしでは、干し草の中から針を見つけるようなものです。

このブログでは、以下の内容を深く掘り下げていきます：

リスクの高いRDSイベントのサンプルと、初期設定がベストプラクティスに従っていたとしても、導入後にドリフトが発生する可能性の有無を確認。
攻撃者は、一般にアクセス可能なRDSインスタンスを悪用するために、どのように多くのスキャンサービスやツールを使用することができるのか？
RDSインスタンスが公開されたらすぐにアラートを出すことが重要な理由と、セキュリティギャップに対処するために必要な実用的なデータにフォーカス。
Sysdig Secureがどのようにこれらのリスクの高いセキュリティイベントを追跡し、報告しているかを比較。

AWS RDSとAWS Cloudtrailとは何なのか？

AWS Relational Database Service (RDS) は、2009年に初めて展開され、大きな成功を収めたAWSのサービスです。RDSは、リレーショナルデータベースの作成、スケーリング、管理、および運用を簡素化します。現在、RDSはPostgreSQL、MariaDB、SQL Server、Oracle Databaseなど、多くのリレーショナルデータベースエンジンをサポートしています。

AWS RDSのセキュリティ機能には、暗号化、ネットワーク分離、AWS Identity and Access Management (IAM) を使用したロールベースのアクセス制御などがあります（ただし、これらに限定されるものではありません）。

推奨される導入アーキテクチャーは、各RDSインスタンスをインターネットゲートウェイやパブリックドメイン名ではなく、プライベートサブネットに配置することです。これは、一般的なデータベースポートのAWSサブネット空間をスキャンしても見つからず、インターネットから直接アクセスできないことを保証します。

AWSのほとんどのサービスと同様に、実際のパブリック/プライベートデプロイメントの決定は、責任共有モデルの利用者側にあります。

RDSインスタンスを公開することは確かにハイリスクな出来事ですが、心配するのはそれだけではありません。

CloudTrailは、すばらしい監査ログの仕組みです。ユーザー、役割、またはAWSサービスによって行われたあらゆるアクションがイベントとして記録され、サービスはデフォルトで有効になっています。CloudTrailが正しく設定されていることを確認することは、まさにベストプラクティスです。

CloudTrailのベストプラクティスは以下の通りです（ただし、これらに限定されるものではありません）：

すべてのAWSアカウントとリージョンでCloudTrailを構成する。
異なるユースケースに別々のトレイルを指定する。
CloudTrailのログファイルの整合性検証を有効にする。
CloudTrailのインサイトで異常なAPIアクティビティを監視する

CloudTrailの1つの大きな考慮点は、AWSのフットプリントが大きくなると、膨大な数のログとイベントを管理できなくなる可能性があることです。このRedditの投稿にあるように、あるDevOps実践者は毎日約1000万件のログイベントを見ています。危険なイベントを見つけられなければ、それに対処することもできず、セキュリティ上の大きな問題を抱えることになります。

数百万件のイベント

どのRDS設定イベントが脅威となるのか？

かなりの数のイベントが高リスクに分類されます。このブログを書いている時点で、Sysdigのリサーチャーは、Sysdig Secureのルールに一致する、少なくとも12の危険なイベントを特定しました。この数は時間とともに増えていくと思われます。これらのルールは包括的にカバーしていますが、必要に応じて簡単に拡張することができます。

これらのイベントのいくつかは、以下のような有名な MITRE ATT&CK テクニックに対応する可能性があります。

T1190 – 公衆向けアプリケーションの搾取
T1596.005 – オープンなテクニカルデータベースを検索する：データベースのスキャン
T1210 – リモートサービスの搾取

これらの技術は、何らかの形で、公衆向けアプリケーションやデータベースのリモート搾取に焦点を当てています。

これらの MITRE ATT&CK テクニックに関する詳細情報は、https://attack.mitre.org/techniques/ でご覧いただけます。

セキュリティイベント	インパクト	説明
Make RDS Instance Public	High	RDSインスタンスは、ポート、IP、およびドメイン名のスキャンによって見つけることができます。
Make RDS Snapshot Public	High	RDS Snapshotsは公開されています。
Modify RDS Snapshot Attribute	Medium	スナップショットを公開する結果になる可能性があります。
Revoke DB Security Group Ingress	High	Security Groupはデプロイメント後に変更しないでください。
Authorize DB Security Group Ingress	High	インターネット接続を可能にするために必要です。
Create DB Security Group	High	セキュリティグループの変更は重要です。
Delete DB Security Group	High	Security Groupは通常、削除しないでください。
Create DB Cluster	Medium	DBクラスターは通常、長寿命です。
Delete DB Cluster	High	DBクラスターの削除は、実稼働環境における重要なイベントであり、綿密な追跡が必要です。これは、全データ喪失につながる可能性があります。
Stop DB Instance	Medium	本番でDBインスタンスが停止するのは一大事です。
Delete DB Snapshot	Medium	DBのデータが削除されるような事象があれば、追跡する必要がある。
Stop DB Cluster	Medium	本番でDBクラスターが停止するのは一大事です。

ポストデプロイメントドリフト

最初のデプロイがベストプラクティスに従っていても、デプロイ後に構成が変更されることがあります。これはポストデプロイメントドリフトと呼ばれ、様々な理由で発生する可能性があります。考えられるシナリオの1つを見てみましょう。

RDSは最初、ベストプラクティスに従って、インターネットにアクセスできないプライベートサブネットに導入されます。

しかし、ドリフトが発生し、この場合、人的要因がいくつかの最悪のプラクティスにつながる。この場合、RDSインスタンスは一般に公開された状態になります。

パブリックアクセスを設定する

インスタンスを公開することは、一般的なデータベースポートをスキャンすることで簡単に見つけることができるため、非常にリスクの高いAWS RDSのセキュリティイベントです。

ここでは、RDSインスタンスはポート3306でリッスンし、パブリックに設定され、インターネットゲートウェイは0.0.0.0のルートでRDSサブネットに追加されています。ワイドオープンなセキュリティグループによって、この絵が完成します。

注意：パブリックスナップショットは、パブリックスナップショットタブに表示されるので、さらに見つけやすくなっています。

パブリックRDSインスタンスの結果

パブリックインスタンスは、DNS名（既知の場合）またはデフォルトのデータベースポートや他のシグネチャーのためのAWSサブネット空間をスキャンすることによって見つけることができます。接続が行われた後、ログイン認証情報が要求され、理想的には最大の被害をもたらす特権アカウントの認証情報が要求されます。

残念なことに、多くの重大な違反があったため、攻撃者は認証情報リストを作成するための材料を手にしています。この場合、ターゲットはMySqlなので、MySQL管理者に適用されるクレデンシャルパターンを使って、クレデンシャルリストはそれに合わせて調整されるでしょう。

リストの作成がうまくいけば、比較的小さな時間と（ディスク）スペースで、これらのリストをブルートフォースで反復するツールがたくさん存在します。

注意：特権的なログイン資格の再利用は、残念ながら現実のものとなっています。そのため、この RDS インスタンスで見つかった認証情報は、クラウド内の他の場所、例えばサーバーのようなデータベース以外のエンティティでも使用される可能性があり、あらゆる種類の横移動の最悪のシナリオへの扉を開くことになります。もちろん、攻撃者はこのことをよく知っています。

これは2001年に開発された学習ツールを使ったブルートフォース攻撃*の例ですが、プロの攻撃者は遅すぎるため、おそらく実生活では使用しないでしょう。これは36回/秒を達成しましたが、もっと高速なツールもあります。攻撃者は、コンテナのファームやサーバーレス機能から並列に攻撃を仕掛け、IPアドレスを広く分散させて高い集計ログイン率を達成することもあります。つまり、ブルートフォースは本当に確率が高いのです。

注意：このブログで紹介されているテクニックは、いかなる場合でもテスト環境以外では使用しないでください。

注意：AWSクラウドのパワーがもたらす予期せぬ結果として、ブルートフォースによる試行回数が多くなることがあります。

一旦、攻撃者があるアカウントでログインすると、彼らはすべてのデータベースユーザーのハッシュ化されたパスワードを見つけることができ、それらを簡単にクラックすることができるかもしれません。これは、ミッションを完了するために、異なる認証情報のセットが必要な場合に便利です。ハッシュソルティングはこれを軽減するのに役立ちますが、決してそれだけに頼るべきではありません。

MySQL ユーザートラバーサル

このように、簡単に推測され、再利用されるパスワードはひどい習慣であることを思い出させるものですが、それはまったく重要ではありません。このブログの要点は、公開データベースインスタンスは、非常に重大なセキュリティ上の懸念事項であるということです。

公開されたRDSインスタンスは、出現と同時に探し出され、保護されなければなりません。脅威の緩和における他のすべてのことと同様に、時間が最も重要であるため、時間は刻々と過ぎていきます。

暴露が未解決のままであればあるほど、より多くの攻撃者が正面玄関を発見するため、脅威は急速に拡大します。そして、時間が経つにつれて、各攻撃者が成功する時間はどんどん長くなっていきます。

このようなことが現実に起こるのでしょうか？

残念ながら、このようなことは現実にはよくあることです。

この例では、RedditのメンバーがRDSがハッキングされたと投稿していますが、この場合、責任はどちらにあるのでしょうか？

注意：Redditはもともとパブリックドメインであり、ユーザー名や組織は通常匿名です。しかし、このブログではユーザー名を伏せています。

RedditのRDSハック

これはほんの一例です。RDSのインスタンスはいくつ公開されているのでしょうか？あなたはどのように予測しますか？

インターネットのプロービング

ネットワーク空間をスキャンするツールは、長い間存在してきました。最近の例では、Shodanがあります。Shodanツールは、サービスのシグネチャーをスキャンし、単純なポートスキャンよりも少し踏み込んでいます。このブログの研究として、私たちはMySQLとPostgreSQLのスキャンを行いました。その結果は、私たちが予測したよりも悪いものでした。

これは、デフォルトのポートを使用しているインスタンスの数だけです。

And that’s just the count of instances using default ports!

DB Engine	MySQL	PostgreSQL
公開されているインスタンス数	3,317,006	711,907

AWSでの公開状況

Shodanによると、MySQLの63K以上のインスタンスがAWSでホストされ、公に公開されていることが明らかになりました。PostgreSQLはさらに悪く、AWSで150K以上のインスタンスが公開されています。RDSの人気からすると、おそらくかなりの割合の人がRDSを使っていることになります。このデータは、RDSの露出が不幸な現実であることを証明しています。

AWSにおけるMySQLの普及率

AWSにおけるPostgreSQLの普及率

干し草の中の針探し

CloudTrailは干し草の山であり、脅威の可能性が高い設定イベントは針のようなものです。

CloudTrailにはすべてのイベントが含まれていますが、CloudTrailには良いイベントと悪いイベントの概念がありません。また、CloudTrail自体にはアラート機能はありません。これは、AWS RDSインスタンスのパブリック/プライベートのステータスに変更があった場合、すぐにアラートを出す必要がある場合の問題です。

CSPMはどうでしょうか？従来のCSPMは、AWSアカウント内の全サービスを繰り返しスキャンするプロセスですが、このプロセスには長い時間がかかります。私たちが調査した2つの主要なCSPMベンダーは、デフォルトのスキャン間隔をそれぞれ24時間と36時間としています。スキャン間隔が長いと、スキャンとスキャンの間にデータベースがプライベートからパブリックに切り替わった場合、CSPMツールはそれを知ることができないため、このケースではうまくいきません。

その代わりに、CloudTrailを全方位監視カメラのように継続的にスキャンするツールが必要です。そうすれば、危険なイベントが発生するとすぐにキャッチできるからです。

しかし、CloudTrailのログをAWS内の他の場所やAWSの外に完全にコピーするようなソリューションには注意が必要です。これらのイベントがセキュリティ上の懸念事項であるかどうかにかかわらず、毎日何百万ものログエントリがエクスポートされる可能性があるため、コストが高くなる可能性があります。

効果的なクラウドの検出と対応は、CloudTrailに脅威となるイベントが表示された瞬間に、コストや遅延を追加することなく、実行可能なアラートを投げる必要があります。

ネイティブツールでDIY

ネイティブツールを使用したDIYアプローチを試してみましょう。要件を満たすことができたと仮定して、これを実現するための労力と複雑さを測定する必要があります。

ここでは、RDS DBインスタンスの公開に焦点を当てます。これは、どのような基準で見ても非常に優先度の高いイベントだからです。

要求事項：

可能な限りリアルタイムで、公開されたRDSインスタンスに対して、最低限以下のようなアラートを生成する。

ユーザー名
DBインスタンス名

以下のネイティブツールを試してみる予定です。

CloudTrail
Athena
CloudWatch
GuardDuty
EventBridge
Security Hub

CloudTrail

CloudTrailへのログ記録は、間違いなくベストプラクティスです。CloudTrailには必要な情報が含まれており、情報はロックされていませんが、多少埋もれています。そこで、このデータをどのようにマイニングし、アラートし、アクションを起こすかを考えなければなりません。

まず、CloudTrailコンソールそのものを使って、この干し草の山の中の針を定義することから始めます：

(ステップ0は、CloudTrailとJSONログフォーマットを学ぶことです。）

原材料を入手する。仮定する。イベント名が「ModifyDBInstance」であるという予備知識がある。Trailでこのイベントをフィルタリングする必要がある。
Trailのログをエクスポートし、スプレッドシートツールにインポートする（下図）。
手動で解析する文字列を見つける（下図）。

何度か試行錯誤を繰り返した結果、以下のようにデータを見つけることに成功しました。「publiclyAccessible: true」という文字列が決定的な証拠となります。

生のTrailログからイベントをピンポイントで特定できることが証明されましたが、これは手作業になります。このプロセスは自動化されなければならないのです。ネイティブサービスを使用して構築するものは、これらのSuspicious EventをCloudTrailで継続的にスキャンし、実行可能なアラートを送信する必要があります。

これらの目標を達成するために、AWSのネイティブサービスを追加で試す予定です。

Athena

探すべき正しい文字列で武装し、SQLクエリーを構築します。動作はしますが、壊れやすいです。Trail名がハードコードされているので、他のTrailで使うと簡単に壊れます。前提 SQLの予備知識はある。

SQLが動作し、長いJSONの文字列として結果を受け取ることができます。要件を満たすには、少なくともRDSインスタンスと、このセキュリティインシデントを開始したIAMユーザーが必要です。

ユーザー名は、useridentityフィールドから解析することができます。

{type=IAMUser, principalid=xxxxxxxxx, arn=arn:aws:iam::xxxxxxx:user/brett+tmm
 , accountid=xxxxxxxxx, invokedby=null, accesskeyid=xxxxxxxxx, username=SOMEAWSUSER}

RDSインスタンスの名前は、responseelementsフィールドから解析することができます。

","masterUsername":"lamp","dBName":"lamp","endpoint":{"address":"xxxxxxxx.us-east-1.rds.amazonaws.com","port":3306,"hostedZoneId":"Z2R2ITUGPM61AM"},"allocatedStorage":5,"instanceCreateTime":"Mar 31, 2022 5:56:53"}

解析は手作業で骨が折れますが、それでもAthenaのおかげで正しい情報を見つけることができました。しかし、残念ながらAthenaはAlertsを送信してくれません。そこで、CloudWatchのメトリクスを使って、正しい情報と正しいアラートの両方を取得することを試みます。

CloudWatch

CloudWatchはCloudTrailのイベントに基づいてアラートを送信してくれます。これでようやく要件を満たせるのだろうか。

最初のステップは、CloudWatch Logsにイベントを送るためにTrailを構成することです。これは特別なIAMポリシーを含む多段階のプロセスであり、ここでカバーされています。
次に、Metric Filterを作成します。実際に使用したFilterは “\”publiclyAccessible\”: true” であり、すべての手順はここで説明されています。
これが終わると、Alarmを作成することができます。この複数のステップのプロセスは、こちらでカバーされています。残念ながら、この作業を行った後、IAMの情報もRDSインスタンスの情報も出てきません。そのため、アクションを起こすことができません。

またしても要件を満たすことができませんでした。アラートを受信しているのは良いニュースですが、ユーザー名とDBインスタンス名が含まれていないため、アラートがアクションに結びつかないという悪いニュースです。

主目的を達成するのに苦労しましたが、特筆すべきCloudWatchの素晴らしい機能を1つ見つけました。MySQL5.7エンジン自体に、失敗したログインを強制的に記録させることができるのです。少し難解ではありますが、比較的簡単なプロセスです。まず、カスタムパラメータグループを作成し、log_warningsを2に設定する必要があります。

その後、CloudWatchがこれらの失敗したログインを追跡していることがわかります。

注意：これはCloudWatchの徹底的な研究を意図したものではなく、十分な時間があれば、もっと多くのことが可能かもしれませんが、先に進まなければなりません。

Cloudwatchの労力は、この一件だけで数時間というレベルです。AWSには200以上のサービスがあり、それぞれが複数のイベントを抱えているため、その影響は後ほど見ていくことにします。

Guard Duty

次にAWS GuardDutyを試しますが、要件を満たせません。AWS GuardDutyのドキュメントを読んでみると、RDSスナップショットに対応した素晴らしいブログポストもあり、GuardDutyは設計上は非常に強力ですが、我々の目的に合うように設計されていないようです。

EventBridge

AWSのドキュメント（この素晴らしいブログポストを含む）によると、EventBridgeはRDSイベントを監視するようですが、キャッチがあります。

このキャッチは、乗り越えるべき高いハードルです。Node.JS 14.X Lambda関数のカスタムコードを書く必要があり、期待できそうですが、ドキュメントの手順に従い、数時間かけてテストしても、残念ながら成功には至りませんでした。私たちは間違いを犯したかもしれませんが、Node.JSの開発者ではありませんし、そうなりたいわけでもありません。全てのプロセスは困難なようで、またしても時間切れになりました。

Security Hub

Security Hubは、私たちが探している事象を見つけるために設計されているので、非常に有望です。RDSインスタンスの公開テストしてみると、Security Hubは約12時間後にこのイベントを検出することに成功しました。これは、インターネット上に公開されたデータベースを放置しておくには非常に長い時間のように思われます。

Security Hubのドキュメントには、次のような記述があります：

” 公開アクセスを許可するように設定が変更された場合、AWS Configルールは最大で12時間、その変更を検出できない可能性があることに注意してください。AWS Configルールが変更を検出するまでは、構成がルールに違反していてもチェックは通過します。”

Security HubのRDSルールはこちらに記載されていますが、残念ながらカスタマイズはできず、あまり包括的ではありません。例えば、海外のAWSアカウントとスナップショットを共有するというハイリスクな事象が抜け落ちているのが目立ちます。

DIYの結果：苦労したこと、失敗したこと

DIY Tool	所要時間	Public RDSのイベントを配置	アラートが作成されたか？	アクション可能か？	成功した？
Raw CloudTrail	1 hour	Yes	No	Yes, Username DB Nameは確認できたが、アラートは発生しない	No
Athena Query	1 hour	Yes	No	Yes, IAMユーザーとDB Instance Nameが見える	No
CloudWatch Metric Alerts	3 hours	Yes	Yes	No, UsernameもDB Instance Nameも分からない	No
EventBridge	2+ hours	No	No	No	No
GuardDuty	1 hour	No	No	No	No
Security Hub	12+ hours	Yes	Yes	部分的：DB Instance Nameは表示されるが、Usernameは表示されない	No

注意：自動化エンジン、可視化ダッシュボード、レポートシステムを構築していないため、Sysdigとの比較はまだできません。

DIYのアプローチでは、誰がどのデータベースを公開したかを即座にアラートで知らせるという要件を満たすことはできません。

しかし、仮にそうであったとしても、DIYのアプローチはどの程度スケールするのでしょうか？Athenaのアプローチを例にとると、その答えは「あまりよくない」ということになります。

どの程度の労力が必要なのかを検証してみましょう。

前提条件：

200のAWSサービスがあり、この数は今後3年間は増加しない。
各サービスに対して
1. CloudTrailで正確なJSONの詳細を見つけ、AthenaでSQLを書き、テストすると、先に試した内容から1.5時間かかります。
2. 1サービスあたり平均12件のリスクイベントがある（AWSサービスによっては0件の場合もあれば、12件以上ある場合もある）
1日8時間労働、プロジェクトに1人のヘッドカウント（リソース）がいる場合

[200 x 12 = 2400イベント ] x 各イベントのDIYに1.5時間 = 3600時間

これはベストケースですが、時間の見積もりは現実に基づかなければなりません。

経験則では、現実はベストケースの2倍に相当します。

[3600 x 2 = 7200 時間 ] / ( 8時間労働 x 5日/週 ) = > 3年

3年どころか、最終的にはSQLの山が空まで届くことになる。これは一生メンテナンスが必要で、それを助けてくれるオープンなコミュニティは存在しませんし、オープンソースではないので、持っていくこともできません。

Sysdigは不審なイベントを即座に捕捉する

CloudTrailを最初に見たときに説明したように、膨大な数のログとイベントを管理することは不可能になります。その結果、合理的な時間枠で対応することが不可能になります。

この課題を解決するのが、Sysdig Secureの出番です。Sysdig Secureをインフラに導入すると、CloudTrailのすべてのエントリーを柔軟なセキュリティルールに照らし合わせてリアルタイムに評価します。クラウド上の監視カメラのように、CloudTrailを常時監視し、アラートを発します。

Sysdig Secure Cloud Activity Insights

クラウド環境の全体像を把握するために、SysdigはInsightsビューを提供しています。

このビューはオブジェクト数が多くても拡張可能で、最初はハイレベルな概要が表示されますが、直感的なドリルダウンワークフローにより、特定の領域のトリアージを迅速に行うことができます。

ここでは、AWSアカウント、その中のRDSサービス、そしてその中の様々な疑わしいRDSイベントを見ることができます。

Sysdig SecureによるRDSイベントへのアラート通知

ネイティブサービスを使ったDIYと比較すると、Sysdig Secureははるかに簡単で効果的であることが約束されています。

Sysdig Cloud Connectorのインストールは、Terraformのplanを適用するだけで、15分程度で完了し、一度だけ行えばよいのです。

ポリシーとは、ルールを整理しておくための構造で、ニーズに応じて混在させることができます。SysdigにはすでにAWS用のアウトオブボックスポリシーが多数含まれていますが、このブログではRDS Suspicious Activitiesという名前の新しいRuntime Policyを作成します。

数回クリックするだけで、OOTB（すぐに使える）RDSルールがすべて新しいポリシーに添付されます。このルールのセットは包括的ですが、後で説明するように、独自のカスタムルールを追加することができます。

Sysdig Secureのテスト

RDSインスタンスを公開した後、Sysdig Secureはほぼ瞬時に要件を上回る警告を発します。

マイクロデモでSTARTをクリックすると、自分の目で確認することができます。

イベントタブをクリックすると、タイムスタンプ、ポリシー、ルールなどの重要な詳細が表示されます。もちろん、犯人（変更を行ったユーザー）、地域、RDSインスタンス名も表示されます。

これで、すぐに回避策を講じるための適切な情報を得ることができました。

データベースを直ちに非公開にする
ユーザーの権限を徹底的に制限する。
データベース内のログを調査し、予期せぬログインやデータ、スキーマの変更がないか確認する。
フォレンジック目的で現在の状態のスナップショットを取る。
そして、データベースが初めて公開される前に作成された有効なバックアップから復元することでしょう。

注意：この例は、適切なインシデントレスポンスに代わるものではありません。このブログ記事で説明されているような状況に陥った場合は、ご自身のインシデント対応計画に従ってください。

Sysdigの活用効果：簡単で効果的

Sysdig Secure for RDSを設定するのに必要な労力は少なく、複雑さもあまりありません。30分弱（インストールを含む）で、すべての要件を満たし、またそれ以上の結果となりました。

Sysdig Secureは、危険なイベントがCloudTrailに投稿された瞬間に警告を発しますが、このような状況で待っている余裕は誰にもありません。

重要なイベントを確認し、直感的なSysdig Insightsビューを使用して状況をトリアージしました。

ルールの拡張

ルールの裏側で何が起きているのか不思議に思ったことはありませんか？何かがどのように機能しているのか分からないと、フラストレーションが溜まります。幸いなことに、SysdigのルールはオープンソースのFalco形式を使用しています。

CloudTrailイベントを見ると、このイベントのキー値がどのようにFalcoルールに対応しているかが簡単に分かります。

Falcoのマッピング

Falcoは論理的

機能を拡張するために独自のルールを書くことも簡単です!

例えば、RDSスナップショットが外国のAWSアカウントと共有されているかどうか、データ流出の試みである可能性があるイベントを知りたい場合があります。

ゼロからルールを書く代わりに、既存のルールをコピー＆ペーストして、いくつかの簡単な変更を加えるだけです。ドキュメントを読む必要はありません。

私たちが行う唯一の変更は、次のとおりです。

ASCII文字を1つだけ挿入することです。(ゼロはCloudTrailのPublicを示す方法なので、ゼロの反対は特定のAWSアカウントを意味します！)
出力に対象のAWSアカウントを追加し、ログに記録します。

たった3文字のASCII文字

別のAWSアカウントでスナップショットを共有することでテストします。

この結果、以下のような不審なイベントがTrailに投稿されています：

Sysdigを確認すると、簡単にイベントが確認でき、動作していることが確認できました！

今すぐハンティングを開始しましょう

この投稿では、セキュリティ上の大きな問題につながる可能性のあるRDSの不審なイベントをいくつか発掘しました。初期設定がベストプラクティスに沿っていたとしても、デプロイ後のドリフトでリスクの高いイベントが発生することを確認しました。

データは、パブリックAWS RDSインスタンスがかなりの規模で存在することを示しています。これは、攻撃者がパブリックRDSインスタンスの場所を特定し、ブルートフォースする方法を見たことを考えると、悪いニュースです。

私たちはCloudTrailを深く掘り下げ、なぜ継続的なスキャンが重要なのかを明らかにし、できるだけ早く警告を受けることが緊急であることを発見しました。

DIYは可能ですが、この方法はあまり効果的ではないことがわかりました。200以上のAWSサービスすべてをDIYで処理するには、数年かかると計算されました。

幸いなことに、Sysdig Secureは数分ですぐに使えるソリューションを提供してくれますし、拡張やカスタムルールの追加も簡単にできることがわかりました。

最も重要なのは、Sysdig Secureによって、RDSだけでなく、環境内のすべてのAWSサービスを保護することができるということです。

あなたのAWS環境には、どんな脅威が潜んでいるかもしれません。今こそ、適切なツールを使って、リスクの高いAWSの事象を探し出す時なのです。Sysdig Secureを無料でお試しください。

AWS環境にはどのような脅威が潜んでいるのでしょうか？今こそ、適切なツールを使って、リスクの高いAWSの事象を探し出す時です。こちらでSysdig Secureを無料登録が可能です。
Sysdig Secureの簡単さを実感してください。こちらのAWSマーケットプレイスで購入いただくことも可能です。