クラウドネイティブ ランサムウェア – 可用性に対する攻撃がクラウド サービスをどのように利用するか

ランサムウェアがクラウドにホストされている企業データに与える影響

ランサムウェアは、ビジネスシステムを阻害し、身代金の支払いを得ることを目的とした金銭的動機に基づく犯罪です。歴史的に、従来のオンプレミスの企業ワークロードや政府システムに存在するデータの身代金は、ランサムウェア攻撃を使用する加害者にとって十分な金銭的利益をもたらしました。クラウド最新のデジタル・システムのフットプリントが拡大する中、組織は現在、ランサムウェアがクラウドベースのワークロードに同程度の影響を与えることができるかどうかを見極めようとしており、さらに「攻撃者に戦術の進化を迫る進化的な圧力がかかるかどうか」を考えている。

クラウドの導入とデータ移行における最近の傾向を観察すると、私の結論はこうだ：私は、ランサムウェアがグローバルビジネスにとってより大きな問題にならないとは思えない。

このテーマに関する私の意見を簡単にまとめると、次のようになる：重要なデータが存在するところなら、ランサムウェアはどこにでも侵入する。ビジネス・データが、例えばオンプレミスのデータベースではなく、クラウドに存在する場合、攻撃者がオンプレミス・システムと同じ目的でクラウドシステムをターゲットに戦術を進化させることは、経済的に理にかなっている。

本稿では、クラウドの悪意ある行為者が、クラウドサービス・プロバイダー（CSP）が提供するツールを使用して、データの可用性に影響を与えるために取り得る経路を概説する。攻撃者の行動に加えて、私は暗号サービスを提供するクラウドAPI をセキュアにするための事前対策、これらのシステムのセキュア化を容易にするためのアーキテクチャパターン、およびクラウドネイティブランサムウェアを検知するための方法を概説しました。

クラウドにおける可用性の攻撃

クラウド変革の最初の10年以上では、クラウドへの移行が加速し、ますます大規模なデータセットがクラウドに預けられるようになった。このような変化を目の当たりにしてもなお、私たちはランサムウェアをオンプレミス環境の文脈だけで考え続け、その概念をクラウドにまで拡大解釈してしまうことが多い。

クラウドでは、開発者や顧客が日常的なタスクを達成するために必要な利用可能なツールが組み込まれており、クラウドサービス・プロバイダーによって機能として提供されている。アクセスに伴い、同じツールや機能が、セキュリティ制御を克服し、検出を回避し、特定の目標を達成するために、悪意のある行為者によって使用されることがよくあります。悪意を持ってこれらの機能を使用することは、しばしば機能の乱用と呼ばれる。

APIを介したクラウド・ネイティブ・サービスのオープン性は、攻撃者が同じツールを悪用、いや悪用することを容易にしている。

各CSPが作成したAPIは非常に発見しやすく、すぐに理解され、意図しない形で活用される可能性がある。機能の悪用は、コードの脆弱性に加えてリスクをもたらす。脆弱性の悪用とは異なり、パターンマッチングによって検出されたり、パッチを適用することによって保護されたりするような、操作するコードの欠陥は存在しない。その代わりに、cybercriminels 、本番用ソフトウェアやインフラストラクチャのデプロイや保守に使用されるCSPが提供するツールを活用して、悪質なタスクを遂行する。

どのような環境に身を置こうとも、cybercriminels 、自由に利用できるツールを活用して邪悪な任務を遂行するだろう。ある意味、パブリックAPIを悪用することで、クラウド上のランサムウェアは、クラウドの「LOLバイナリ」がそのAPIであり、機能が豊富でパブリックであるという「Living off the Land」のトレンドを継続することになる。不要なソフトウェアとしてアンインストールできるWindowsの実行ファイルとは対照的に、AWSのクラウドAPIは常にオンになっている。公開、アクセス、可用性は、サービスが必要とするオープン性を提供し続け、壊滅的なランサムウェア攻撃の手段を与える。

クラウドデータはどこでホストされていますか？

ランサムウェアの悪用テクニックを理解するには、まずデータが保存されているシステムを理解する必要がある。オンプレミスのデータは、オラクル・データベースからMicrosoftSQLサーバーまで、さまざまなテクノロジーにまたがって保管されている可能性が高い。これらのシステムに共通しているのは、物理的なホストであり、完全にあなたの管理下にあるということだ。

オンプレミスのデータウェアハウスサーバは、一般的にフルスタック環境に実装された物理ホストであり、攻撃対象領域が広いため、malware 。しかし、フルスタック環境は堅牢なデータ保護戦略によって保護されており、ネットワークベースの脅威をモデル化してきた過去20年の間に進化したセキュリティ制御を採用しているため、メリットがあります。そのため、従来のオンプレミス・データベースは、何重ものネットワーク制御の背後に置かれ、企業ネットワークの奥深くに隔離され、エージェント・ベースの脅威検知で厳重に監視されています。

従来のデータストアを保護するためのオンプレミス・アプローチは、クラウドには適用できない。クラウドに移行されたデータは、悪意のあるアクターを含むすべてのエンドユーザーが、基礎となるシステムに限定的かつ限定的にアクセスできるシステムに存在する。つまり、クラウドデータストアの攻撃対象は劇的に異なるのだ。

主要なクラウドサービスプロバイダー（AWS、AZURE、GCPなど）はそれぞれ、分散型、高可用性、万能のデータストアを独自のバージョンで提供している：AWS S3、Azure Blob Storage、GCP Storage Bucketsだ。それぞれが非構造化データのコアリポジトリであり、ユビキタスで安定した、可用性の高いサービスであり、それぞれのプラットフォーム上の他の多くのサービスと統合され、ほぼすべての顧客のデータストレージのニーズを満たす。クラウドプロバイダーはパイプラインを構築するためにストレージサービスを利用し、ビッグデータプラットフォームのバックデータストアとして、あるいはウェブコンテンツのパブリックリポジトリとして機能する。

AWSの顧客であれば、S3を使わないのは難しい。そのため、クラウドネイティブのランサムウェア作者のターゲットになる可能性が高い。

従来のランサムウェア暗号化戦略

オンプレミス・システムを狙うランサムウェアは、対称型暗号と非対称型暗号の両方の長所を活用し、それぞれの制限を回避するハイブリッド暗号化方式を採用している¹。

という制限がある：

• 非対称暗号化操作が遅いのに対して、対称鍵によるデータ暗号化は速い！
• 対称暗号化では、暗号化と復号化の両方に同じ鍵を使う。純粋に対称的な戦略は、しばしば復号鍵をシステム上に残し、フォレンジック・チームによる復元を容易にする。

ランサムウェアの作者がこれらの制限を回避するために採用する戦略は、社内の暗号チームが使用するテクニックと同じである。善意であろうと悪意であろうと、鍵階層を使用して、ある鍵セットを別の鍵から導き出し、対称データ鍵を暗号化することができる。

対称暗号と非対称暗号を組み合わせることで、ランサムウェアの作者はより複雑な目標を達成することができる。

• 暗号化タスクを実行する際のスピードアップ
  > 共通鍵のデータをターゲットにすることで、ランサムウェアは防御機能が対応する前に悪用を完了できることが多い。
• 対称鍵の材料を難読化することは、盗用後の分析における復元を妨げる。
  > 対称データキーを非対称キーで暗号化することで、フォレンジックの専門家にとって、キーの復元は不可能ではないにせよ、困難なものとなる。

複雑な暗号化技術を実行するためのmalware の作成は、オンプレミスの暗号化装置には必要である。しかし、クラウド上のデータを標的にする場合、このような暗号化戦略は面倒であり、完全に不要である可能性が高い。本稿では、クラウド・サービス・プロバイダーが提供するツールを活用し、従来のランサムウェア技術を時代遅れにする攻撃者の手法を紹介する。

攻撃者が管理するKMSキーでS3オブジェクトを暗号化する

クラウド・サービス・プロバイダーは、その暗号化サービスを利用する顧客のために、安全な信頼の根を維持するために重労働をこなしてきた。攻撃者はこのような利便性を利用して、クラウドでホストされるデータの可用性に影響を与えることができる。

AWS Key Management Service (AWS KMS)は、顧客が鍵を生成し、その鍵へのアクセスを制御し、S3 Server-Side Encryption (SSE)に必要な署名、検証、暗号化プロセスの管理などの暗号処理を実行するために使用することを可能にする。

KMSを使用しない場合、S3上の暗号化されたオブジェクトはAmazonMasterキーで暗号化される。認可されたパーティがこのバケット内のオブジェクトへのアクセスを要求すると、AWSはバックグラウンドで透過的にデータを復号化する。AWSがSSEバッキングキーを生成し管理する代わりに、顧客はKMSキーを使用し、暗号化されたデータの周りのアクセス制御の別のレイヤーとしてキーに接続されたリソースベースのポリシーを活用することができます。ポリシーを適用して鍵へのアクセスを制限する機能は、攻撃者が鍵で暗号化されたデータの可用性に影響を与える隙を残す。

SSEにおけるKMSの役割を示すために、ランサムウェアの操作者がAWSアカウントのS3とKMSへの重要なアクセス権を獲得する以下のシナリオ1に注目してください。悪意のある行為者は、S3からオブジェクトを読み取り、コピーし、削除することができ、さらに新しいKMSキーを作成する権限を取得することができます。このシナリオではさらに、脅威行為者がアクセスを利用してデータの可用性に影響を与え、その復旧のために身代金を要求する方法を説明しています。

シナリオS3上のクラウドネイティブ・ランサムウェアのデモ

このシナリオでは、「victim-bucket（被害者バケット）」という適切な名前のバケット内のデータを標的とする脅威行為者を想定している。このバケットでは、Server-Side Encryption (SSE)が有効になっており、オブジェクトがAmazonが管理するマスターキー(SSE-S3)で透過的に暗号化されるように指定されています。このバケットからオブジェクトを取得する(s3:GetObjectアクション)アクセス権だけを与えられたエンドユーザは、保存されているオブジェクトの平文をダウンロードするのに十分なパーミッションを持っています。Amazon が管理するマスターキーで暗号化されたオブジェクトを復号化するために、追加のパーミッションは必要ありません。

このシナリオでは、悪意のあるアクターが身代金目的でデータを保持する目的でエンドユーザーを侵害したと考えます。悪意のある行為者は、'staging-bucket'と呼ぶ新しいS3バケットを作成し、標的のS3データのランディングゾーンとして使用します。新しく作成された'staging-bucket'も、アップロードされたオブジェクトを暗号化する必要があるが、KMSキーを使用する。我々はAWSでKMSキーを生成し、AWS HSM内に保存した。そして、そのキーに対するアクセス制御を実施するために、顧客が管理するポリシーに依存した。

データを「victim-bucket」から「staging-bucket」に移行する際、オブジェクトは新しく作成されたKMSキーで再暗号化される。S3オブジェクトとKMSキーに関連付けられたパーミッションが、オブジェクトへのアクセスを決定する。S3オブジェクトとKMSキーの両方にアクセスする明示的なパーミッションがない呼び出し元からのリクエストでは、アクセス拒否応答を期待する。エンドユーザーがS3オブジェクトかKMSキーのどちらかに明示的な'deny'パーミッションを持っている場合、アクセスリクエストも拒否されると思ってください。

この時点で、私たちの架空の脅威行為者は、S3オブジェクトを新しいデータストアに移行し、自分たちの管理下にある鍵でオブジェクトを再暗号化することで、ランサムウェア攻撃の舞台を整えた。このシナリオの次のステップは、復号化などの暗号化操作のためのキーへのアクセスに影響を与えることです。

キーポリシーのロックアウト - "DENY, except when; ALLOW, only when"

自分のアカウントにあるKMSキーからAWSの顧客をロックアウトするテクニックは、²⁰²⁰²年のDEFCONのCloud VillageでSpencer Geitzen氏によって初めて説明された。

キーポリシーの悪意ある更新がどのようなものか見てみよう。

• aws:sourceIp」条件キーが攻撃者が管理するIPと等しい場合を除く。
• ALLOW - KMSキーのすべてのアクション - 発信者が攻撃者の管理するアカウントの場合のみ。

このスタイルのリソースベースのポリシー専門用語は、次のように呼ぶことができる：「DENY(拒否する)、ALLOW(許可する)。

このパターンを採用しようとするランサムウェアのオペレーターが、他の条件を利用することも想像できる。発信元が特定のIPであることを要求することは、事実上、キー上のすべてのアクティビティを制限するメカニズムであるが、以下のAWSグローバルキー条件を使用することも同様に効果的である：

• aws:プリンシパル・アーン
• aws:PrincipalAccount（プリンシパルアカウント
• aws:sourceVPC
• aws:ソースVPCe

攻撃者が制御できるユニークな値が呼び出し元によって要求されるあらゆる条件は、AWS 顧客をリソースからロックアウトするために活用することができる。

KMSキーにアタッチされたリソースベースのポリシーを "DENY, except when; ALLOW, only when "パターンに更新すると、被害者アカウントは新しく暗号化されたデータから事実上ロックアウトされる。ルートユーザーでさえ、暗号化されたS3データにアクセスできない。

攻撃者が管理するIPから攻撃者が管理するAWSアカウントを発信元とする発信者だけが、KMS Keyにアクセスし、S3データを復号化できる。

クラウドネイティブのランサムウェア攻撃による最終的な後始末には、元の「被害者バケット」を削除し、暗号化されていない新しいバケットに身代金請求書をアップロードすることが含まれる。

既存のKMSキー

KMSキーから被害者を締め出すことは、S3の可用性に影響を与える唯一の方法ではない。しかし、セキュリティ研究者がモデル化するには、より興味深いメカニズムの1つです。

このテクニックは新しいKMS鍵に限ったものではない。既存のKMS鍵に影響を与えることで可用性に影響を与えるには、脅威行為者のパーミッションがさらに疎かになる。既存のKMS鍵のポリシーを更新し、暗号化操作のためのアクセスを制限することは、攻撃者が作成した新しい鍵でS3データを再暗号化するのと同じように、データの可用性に大きな影響を与える。

先の2つのシナリオでは、サーバーサイド暗号化（SSE-KMS）で使用される共通鍵へのアクセスが、鍵ポリシーの操作によって悪意のあるアクターによって人質に取られている。

被害者が支払う場合

クラウドネイティブのランサムウェアのギャングが、従来のオンプレミスのランサムウェアに基づくデータ復号化キーのコントロールを放棄することがどのようなものかを知ることはできない。クラウドでは、暗号化されたデータの「鍵を引き渡す」プロセスは、ランサムウェアのライフサイクルに必要な要素であることに変わりはないが、その様相は異なるだろう。結局のところ、ランサムウェアが消費者に提供する製品は、暗号化されたデータを復元するメカニズムなのだ。他のビジネスと同様、ランサムウェアの運営者は、「顧客」に製品を届けるための信頼できる手段を必要としている。

シナリオ1では、ビジネスクリティカルなデータを復号化するために必要な KMS鍵にアクセスできるのは、攻撃者アカウントからの発信者のみである。そのため、被害者に制御を戻すためのリアルタイムで信頼性の高いメカニズムには、キー・ポリシーの更新は含まれない。むしろ、ランサムウェアの一団は、暗号操作の権限を委譲するために使用されるKMS鍵の代替アクセス制御メカニズムであるキー・グラントに目を向けるかもしれない。

KMSのキー・グラント³は、被授権者への権限委譲であり、そのキーに対する暗号化操作の実行に使用されるトークンを返す。キー・グラントを作成し、被害者アカウントに乗っ取られたキーの復号化を許可することで、ランサムウェア・ギャングは、制約されたキー・ポリシーによる制限を回避して、お金を払う「顧客」に事実上可用性を返すことができる。KMSキー・グラントによって、被害者はKSMキーにアクセスし、暗号化されたデータを復元するプロセスを開始することができる。

クラウドネイティブのランサムウェア攻撃からAWSがあなたを救う？

これまでの考察を踏まえると、クラウドネイティブな環境でランサムウェア攻撃に直面した場合、「責任共有モデル」がどのような要素になるのかを考えるのは妥当なことである。以下は、検討に値するいくつかの考慮事項である。

AWSが介入する最初のシナリオは、AWSがAWSのHSMからKMSの鍵マテリアルにアクセスできる、という仮説である。この推測は非常にあり得ないもので、完全に可能性の範疇を逸脱している。AWSが自社のデータセンターにあるHSMからKMSキーを取り出すことは考えられない。AWSは、キー・マテリアルを取り出すことができる人間がいないことを保証するために多大な労力を費やしており、その旨を真摯に公言している。

AWSの介入における残りの2つのシナリオは、より未解決の問題である。最初の支援の手段は、AWS が被害者の環境を変更することである。AWSが被害者のアカウントに悪意を持って適用されたキーポリシーを元に戻し、KMSキーへのアクセスを回復できるという証拠はない。AWSがリソースベースのポリシーに対して「神の手」のような能力を持っているという兆候もない。また、もしそうであったとしても、その能力を公に認める動機もあまりない。

検討すべき最後の支援による修復オプションは、AWSが悪意のあるアクターが操作しているアカウントを徴用することです。AWSのTrust and Safetyチームは、ボットネットキャンペーンで使用されているような利用規約に違反していると判断した不正なアカウントを隔離して閉鎖します。しかし、アカウントの隔離と閉鎖は、ハイジャックされたKMSキーの制御を取り戻すために必要となるリソースの制御権の掌握とは大きく異なる。AWSがアカウントを乗っ取るプロセスを持っているかどうかは定かではないが、AWSがアカウントを持っていることを示唆するいくつかの証拠がある。

AWSには、アカウントのRootメールアドレスを変更する仕組みがある。ルートユーザーのパスワードを忘れたり、ルートユーザーに関連付けられているメールにアクセスできなくなったりした場合に、この機能を利用することができます。AWSサポートは、ルートメールアカウントの変更を行う前に、アカウント所有者の公証を要求します。この内部プロセスは、AWSが単にアカウントを閉じるだけでなく、そのアカウントに含まれるリソースに管理者権限でアクセスする権限を持つことを示唆している。

神の手」理論のように、AWSはアカウントを没収する能力を公表するインセンティブはほとんどない。防御側の観点からは、保証されたServiceLevel Agreementsを伴うAWSからの復旧支援プロセスが明確に文書化されていなければ、AWSからの理論的な復旧支援は役に立たない。レスポンス 、ランサムウェアイベントからの回復のための計画は、AWSからの支援を中心に据えるべきでなく、期待すべきではない。

クラウドネイティブ・ランサムウェアへの予防、検出、レスポンス

AWSがランサムウェアのイベント中に役立つ可能性は低いという理解に基づき、私たちはすべてのセキュリティプログラム、予防的コントロール、検出およびレスポンス 機能の基本に目を向ける。

SCPによるKMSキーの制限

サービス・コントロール・ポリシー（SCP）による緩和には、クラウド・セキュリティ・プログラムにある程度の成熟度が必要だが、だからといって、その利用を運用上の目標にすべきではない。KMS鍵の特注ポリシーを作成するには、データに対する暗号操作の実行を許可する鍵と、その鍵へのアクセス権を誰が持つべきかを理解する必要がある。

オブジェクトを暗号化するために許可される特定のKMSキーを指定するサービスコントロールポリシー（SCP）は、本稿で説明したタイプのクラウドネイティブランサムウェア攻撃を防ぐための良い手始めになるだろう。暗号化操作を特定の鍵に制限することで、攻撃者が悪意を持ってS3オブジェクトを新しく作成された鍵または自分のコントロールする外部鍵で暗号化することを防ぐことができるが、既存の承認された鍵のポリシーを乗っ取ることはできない。

多くの場合、この種のSCPは、すべてのKMS鍵を単一のアカウントに集約するアーキテクチャー・パターンと組み合わされる。これは、ランサムウェアへの耐性のためだけでなく、監査可能性やキー・ローテーションの簡素化など、一元化がもたらすあらゆる利点のためにも、望ましい設計パターンである。

鍵管理にこのような一元的な「フォートノックス」アプローチを使うことで、「すべての卵を一つのカゴに入れる」設計が可能になる。また、「すべてのセキュリティ管理を一つのカゴに入れる」アプローチも可能になる。中央鍵管理アカウントにより、セキュリティ組織は、最も厳密な意味での最小特権の原則を実施し、通常の鍵使用パターンの基準線を確立し、異常なトランザクションを監視することができる。

S3バケットの構成

すべてのS3バケットを要塞に設定できるわけではないが、ランサムウェアの全体的な耐障害性戦略に追加できるS3のコントロールは注目に値する。

• オブジェクトロック：オブジェクトやそのバージョンの削除を防止するためにS3バケットに適用される設定。
• オブジェクトのバージョン管理：この設定は、以前にアップロードされたオブジェクトを上書きする代わりに、新しいオブジェクトを強制的に作成します。オブジェクトロック」と組み合わせることで、オブジェクトが悪意を持って暗号化されたバージョンで上書きされるのを防ぐことができます。バージョニングを有効にする場合は必ず、バージョン管理されたオブジェクトのライフサイクルを管理するポリシーを設定してください。
• MFA削除：S3からオブジェクトを削除しようとするとき、呼び出し元のセッショントークンにMFAビットがセットされるようにする。繰り返しになるが、これらのコントロールは高度にトランザクション化されたデータとは相容れない可能性が高いが、機密性の高いバックアップを保護したい場合には実現可能かもしれない。どのようなデータがあり、どこに保存されているかを知ることは、これらのバケットレベルの緩和策を実施するための前提条件です。

クラウドネイティブ・ランサムウェアの検出

本稿では、脅威行為者がS3上でホストされているデータの可用性に影響を与えるために使用する2つの可能性について概説する。我々の架空の脅威行為者は、新しいKMSキーの可用性に影響を与えるためにキーポリシーのロックアウト手法を使用した。また、既存の鍵に同じ手口を使用する可能性も認識されている。あるいは、攻撃者が管理するアカウントにある外部KMSキーでS3データを悪意を持って暗号化することもできる。各シナリオを見て、CloudTrailのどのようなイベントが対応者の調査を正当化するかも議論してみよう。

新しいキーによるキーポリシーのロックアウト

脅威行為者がこのテクニックを使用する場合、新しいKMSキーの使用を観察し、キー・ポリシーの更新に関連するイベントをインジェストする際に、悪用段階で警告を発し、対応することができる2つの重要なポイントがある。どの鍵を暗号化に使用すべきかについて組織が明確な見解を持っている場合、 認可されていないKMS鍵の使用はアラームを発するべきである。さらに、本稿で言及したグローバル条件キーのいずれかを含むようにキー・ ポリシーを更新した場合も、フォロースルーが必要である。

既存キーによるキーポリシーのロックアウト

脅威者は、既存のKMSキーに影響を与えることに集中することを選択するかもしれない。このため、悪用の段階で検知する機会は限られる。それでも、カスタムアラートを作成することで、キーポリシーが更新され、クラウドネイティブなランサムウェア攻撃が発生したことを示す可能性のある、本稿で言及したグローバル条件キーのいずれかが含まれるようになったときに通知することができる。

外部KMSキーによる暗号化

このシナリオは本稿では詳述しないが、悪意あるデータ暗号化のメカニズムとしては有効である。セキュリティ・オペレーション・チームは、自分たちの管理下にないKMS鍵で暗号化 操作が実行された場合、通知を受けたいと思うだろう。

結論として

クラウド・サービス・プロバイダーが提供する暗号化ツールは、適切に保護されていない場合、ランサムウェア集団に利用され、クラウド上のデータの可用性に影響を及ぼす可能性がある。クラウドで成功するランサムウェア・キャンペーンは、クラウド・ネイティブ・サービスを利用してデータを高速に暗号化し、組み込みのアクセス制御メカニズムによって被害者を重要なビジネス・データから締め出す。

鍵管理のアーキテクチャ・パターンを一元化することは、クラウド・ネイティブなランサムウェアを防止するための第一歩である。鍵管理を一元化することで、ランサムウェアをより効果的に防止することができるとともに、クラウド不動産における通常の暗号化パターンがどのようなものかをより一貫した形で把握することができる。

予防的な態勢は理想的ではあるが、大多数の組織が初日からこのようなアーキテクチュアルな管理体制を整えているとは考えにくい。さらに、高度に制限された環境を持つ組織であっても、ガードレールが機能しなくなった場合に備えて計画を立てることは、すべての組織に課せられた責務である。そのため、クラウドホスティングされたデータがランサムウェアの影響を受けているかどうかを検知することは、最優先事項であるべきだ。これらの検知戦略は、脅威者が使用する手法によって微妙に異なるが、外部アクセス許可、外部キーの使用、ポリシーの条件文の監視など、クラウド資産にとっての外部とは何かを知るというコンセプトに根ざしている。

---

参考文献

¹ランサムウェアの暗号化技術： https://medium.com/@tarcisioma/ransomware-encryption-techniques696531d07bb9

²クラウドの身代金 - Spencer Gietzen (DEF CON Cloud Village):https://www.youtube.com/watch?v=8QdZ2- sAQFs&list=PL5944c_fOMYn2cQQuQe23gtqZfHWzyrPn&index=3

³AWS KMSにおけるグラント: https://docs.aws.amazon.com/kms/latest/developerguide/grants.html S3 Ransomware Part 1：攻撃ベクトル: https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ S3 Ransomware Part 2: 予防と防御: https://rhinosecuritylabs.com/aws/s3-ransomware-part-2- prevention-and-defense/