オープン ソース ツール リリース: EBS direct APIでAWSへの新しいアクセス方法を実現

  • 3,021
    people reacted
  • 1
  • < 1 min. read

By

Category: Cloud, Unit 42

Tags: , ,

This conceptual image illustrates the concept of cloud providers.

This post is also available in: English (英語)

概要

2019年12月に、Amazon Web Services (AWS)は、Amazon Elastic Block Store (EBS) direct APIの提供開始を発表しました。これにより、AWSの顧客は、以前は不透明なEBS形式とみなされていたスナップショット(増分バックアップ)に細かく(ブロックレベルで)アクセスできるようになりました。

これらの新しいAPIは災害復旧(DR)シナリオで役立ちます。災害復旧をする企業は、AWSの地域的機能停止や特定の顧客のAWS環境の機能停止時に、会社のオペレーションを復元するためにデータにアクセスする必要が生じます。そのための最も効率的な方法は、AWSからデータを直接コピーし、時間の経過に従って変更されたデータのみをコピーすることですが、これらのAPIの提供で、災害復旧を行う企業がこの効率のよい方法を取れるようになりました。

これらのAPIを利用するツールは急速に進化しています。AWSは、GitHubで顧客向けにサポーティングツールを積極的にリリースしています。特に、災害復旧ソフトウェアプロバイダであるVeeamは、7月にこの新しいAPIをそのテクノロジに統合しました。それ以降、このAPIのアプリケーションに関してあまり語られることはありませんでしたが、それらのリリース時に公開されたブログ「Programmatic Access to EBS Snapshot Content (新機能 – EBS Direct API – EBSスナップショットコンテンツへのプログラムによるアクセス)」によれば、これらのAPIは、バックアップ/リカバリ、災害復旧、データ管理製品およびサービスの開発者向けに設計されており、これによりそうした開発者からの提供内容を高速化・高コスト効率化できるようになります。

ただし、このリリースのEBS direct APIは、見込まれるDRアプリケーションに限定されたものではありません。Crypsis (パロアルトネットワークスの子会社であり、Digital Forensics and Incident Response (デジタルフォレンジックとインシデント対応。以降「DFIR」と表す)、攻撃的セキュリティ、プロアクティブな作業などサイバーセキュリティの専門的サービスを提供する)の作業に関連して、EBS direct APIを使用すると、以前とは異なる方法でAWSと対話できます。大規模なイノベーションがあれば、そこにはたいてい最適化や侵害、防御を試みる人々が出てくるものです。本稿では、EBS direct APIを防御やDFIR分析にどう活かせそうかについて検討するとともに、追加的なセキュリティ考慮事項についても取り上げます。

前述のように、EBS direct APIを使用するためのサポーティングツールは、AWSによるリリースが始まったばかりで、このブログで取り上げるさまざまなアプリケーションには対応していません。これらのAPIとそれがセキュリティ分野に与える影響は重大であるため、弊社もツールを作成し、このブログの最後で提供して、他のユーザーがEBS direct APIのセキュリティ上の可能性を活用できるように支援します。

EBS direct APIの背景

EBS direct APIのリリース以前は、EBSスナップショットは、特定の時点でのボリューム増分バックアップでした(ハードドライブに似ています)。お客様の会社が、AWSにサーバーのAmazon Machine Image (AMI)を作成した場合、それによって複数のスナップショットのコレクションが生成されます。これらのスナップショットは、Amazon S3に保存されますが、通常のS3オブジェクトのようにフェッチしたり使用したりはできません。これは、弊社のお客様との会話でよく耳にしたことです。AWSは、別のやりかたでEBSボリュームを操作したいという顧客からのフィードバックに基づき、EBS direct APIをリリースしてアクセシビリティを高めました。

EBS direct APIによって以前の問題が解消され、承認されたAPIユーザーがこのブロック データ コンテンツ(実際のバイト)を直接使用できるようになります。それらは、顧客がセキュリティモニタリングを実行しているときのスナップショットの扱い方に関する既存の想定にも影響を及ぼす可能性があります。

これらの操作機能のいくつかは、これまでのツールのイノベーション推進における中心的テーマである「簡潔さ」に沿ったものです。これまでは、スナップショットのデータを読み取るには、Amazon Elastic Compute Cloud (EC2)インスタンス、およびスナップショットからボリュームへの変換(または同様のワークフロー)が必要でした。つまり、これまでインスタンスが必要であった操作を、今はAPI呼び出しで行えるようになりました。

防御での使用

セキュリティ業界全体で、主要なセキュリティおよびフォレンジックソフトウェアは、バージョン管理されたAMIによってリリースされてきました。その場合、開発者は、意図的、または多くの場合は偶発的に、パスワードやキーなどのハードコーディングされたシークレットファイルをリリースに挿入できます。そのようなバージョンがリリースされると、そのデータは公開され、セキュリティインシデント、コンプライアンス違反、またはビジネスクリティカルなワークフローの中断を招く可能性があります。効率的な環境では、コード/設定が自動的に監査されるのを避けるためにこれらのAMIは人手を解さずに構築される場合があります (例: packer.io)。EBS direct APIでは、ハードコーディングされたキー、パスワードなどについて以前のバージョンのリリースと比較できるようになりました。これにより、開発者および組織は、更新のリリース前に、このバージョン内にシークレットや機密情報がハードコーディングされていないことを確信できます。増分データに限定されるため、テラバイト規模のトランザクションではなく、ギガバイト規模(ディスク上で変更が特に少ない場合はそれ以下)のトランザクションになります。

弊社のテストでは、Crypsisで通常のUbuntu 20.04 LTSイメージを取り、複数の変更を行いました(AWS資格情報ファイルをデプロイし、それらをディスク上で移動し、ユーザーを作成し、ユーザーパスワードを変更)。設計上、パブリックイメージの基礎となっているスナップショットは、EBS direct APIに応答しないため、独自のプライベート ベース イメージを作成しました。次に、ログインし、ディスク上のハードコーディングされたシークレットファイルを移動し、それのスナップショットを再度作成しました。2つのスナップショットを比較し、9秒以内にハードコーディングされたシークレットを自動的に見つけました。スキャン可能な最後のブロックで行った場合、全体のスキャンは、34MBでした。バックドアLinuxユーザーでの時刻が異なる2つのスナップショットであったスナップショットからも同じ結果を得ることができました。テスト環境で弊社が生成したLinuxパスワード「shadow」エントリが検出されました。

DFIR での使用

このAPIのリリース前は、Crypsisで、クライアントの準備が十分に整い、侵害の直前および直後のサーバーのスナップショットを取れる場合(クラウドの内外でフォレンジック比較に役立つ状況)に、AWSの侵害を調査してきました。これらのスナップショットは、ボリュームに変換され、さまざまなソフトウェアを通して有益な差分結果を導き出すことができました。ただし、それには以下のような制約がありました。

  • EC2インスタンスが必要でした。
  • スナップショットからボリュームを作成する必要がありました。
  • その後、「直前および直後」の状態のビット単位の2つのボリュームを得て、その時点でそれらの比較が可能になりました。
  • 多くの同様の取り組みと同じく、実際に2つを比較するソリューションが必要でした。

多くのDFIRオプションでは(特に大規模に実装した場合に)時間とリソースが必要で、上記の4つの状況も例外ではありません。EBS direct APIのリリースにより、最新のスナップショットの増分バイトをダウンロードできるだけでなく、1回のAPI呼び出しで、変更されたブロックのリストを表示し、調査担当者が、侵害の実行中に変更されたバイトを直ちに特定できます。それらは、単に同じサーバーに属しているか、相互に類似して関連している必要があります。

理論上、承認されたリサーチャーは、フォレンジックイメージを復元してマウントする代わりに、それをEBS direct APIから直接取得できます。ただし、(1) CrypsisはスナップショットIDに基づいているため、スナップショットの「親」を特定する信頼できる方法を認識していません。(2) 開発作業では、それらがディスク上で適切につなぎ合わされていることを確認する必要があります。このため、現状のように、多くの企業は、EC2イメージングサーバーを購入するほうを好む可能性があります。

EBS Direct APIでのセキュリティに関する考察

EBS direct APIではスナップショットをブロック単位で探索できるので、これらのIDやアクセス管理（IAM）権限は、それを必要とするIAMユーザーやロールにのみ割り当てるようにしてください。たとえば ebs:GetSnapshotBlock 権限を持つ IAM ユーザーが侵害されてしまえば、攻撃者はスナップショットをローカルシステムに直接ダウンロードできますので、データ表示のために対象アカウントでインスタンスを起動する必要もありません。

上記「防御での使用」で説明したように、EBS direct APIのインクリメンタル スナップショットをスキャンしたり、スナップショットを比較したりする機能により、攻撃者はバージョン間のスナップショットに追加された機密ファイルがあるか、容易に識別できるようになる可能性があります。

EBS direct APIや任意のIAM権限を使用したいとお考えの場合は、漏洩した資格情報からの影響を制限するため、最小特権の原則に従うべきです。EBS direct APIのドキュメントには、特定の時間の間に作成されたスナップショットへのアクセスや、特定のタグを持つスナップショットのみへのアクセスを制限する方法の例が記載されています。

なお、EBS direct APIの使用状況はすべてユーザーのCloudTrailレコードに記録されることには留意しておくべきでしょう。また、AWSユーザーには、管理者の資格情報が漏洩した場合にも任意のAPI利用を防げるサービスコントロールポリシー設定オプションが用意されています。このほかAWS Configルールを作成し、組織のセキュリティオペレーションセンターにEBS direct APIの利用を警告することもできます。

ツール

EBS direct APIに関するリサーチと開発はまだ始まったばかりで、このブログで取り上げたアプリケーションの大多数にはそれらをサポートするツールがありません。弊社は、イノベーションの精神で、これらの新しいアプリケーションに貢献できることをうれしく思います。このGitHubリンクに弊社がこれまでに開発したものをまとめました。これらのツールの1つは、顧客とのインシデント対応の取り組みで使用され、攻撃期間中のディスク上のイベント ログ エントリを分離し、これが直ちに攻撃者のIPアドレスにつながりました。

結論

EBS direct APIは、初期マーケティングでは災害復旧に的が絞られていますが、その他の分野でも役立つ可能性があります。この新しいテクノロジには、1つの業界にとどまらず多数のアプリケーションがあります。本稿で、防御やDFIRにこれらAPIをどのように活かせそうか、またセキュリティ上の考慮事項や新たなツールを共有することで、ユーザーがこれらのAPIの可能性を探れるようにしました。ツールは提供され始めたばかりなので、弊社はこれらのAPIに関するリサーチのトレンドの予測や動機付けを試みてきました。クラウドテクノロジの進化に伴い、これらのAPIがセキュリティに及ぼす影響を考慮しなければなりません。

参考資料: