Azureにおけるランサムウェアの対処法

本文の内容は、2022年11月8日にNigel Douglasが投稿したブログ（https://sysdig.com/blog/ransomware-azure-mitigations/)を元に日本語に翻訳・再構成した内容となっております。

攻撃者が使用する手法と、Azure のランサムウェアに感染した場合に実装する必要がある緩和策について詳しく見ていきましょう。

Ransomware on Azure
ランサムウェアの脅威については、ニュースなどで頻繁に取り上げられているため、ご存知の方も多いと思います。クラウド攻撃の解析で説明したように、ランサムウェアは、攻撃者がデータの暗号化によってアカウントを制御し、システムへのアクセスを制限することで金銭を得る方法です。

本ブログでは、攻撃者がAzure環境上でランサムウェアを拡散するために使用するアプローチを軽減する方法について説明します。

Azureの脅威調査マトリックス

Microsoft Azureのクラウドネイティブツールセットを使用して、クラウド環境にアクセスした可能性のあるユーザーの影響範囲を制限し、最終的にキルチェーンのできるだけ早い段階で攻撃を停止することを目的とする一連のベストプラクティスを確立していきましょう。

MITRE ATT&CKフレームワークに代わるAzure脅威調査マトリックスに精通している場合、マイクロソフトはもはや「初期アクセス」をAzure脅威検出ライフサイクルの最初のポイントとは考えていません。

Azureの脅威検知マトリックスでは、焦点を当てるべき偵察層からスタートします。これは、ペンテスト活動における古典的なアプローチです。攻撃者は、受動的または能動的に（IPディスカバリーやパブリックアクセス可能なリソースのポートスキャンなど）、できる限り多くの情報を得ようとします。公開されたPrometheusサーバーを利用したKubernetesクラスターへの攻撃方法についてでは、監視ツールを使ってKubernetesクラスター全体をフィンガープリント化し、それによって攻撃者へのドアを閉める方法を説明しました。

このブログ記事内では、Kubernetesのセキュリティに深く焦点を当てることはしません。Kubernetesの様々な攻撃ベクトルについてもっと学びたい場合は、あらゆるK8sクラスターを保護するために設計された実世界のラボであるKubernetes GOATをチェックアウトすることをお勧めします。Kubernetesセキュリティの入門書としては、Sysdigの「Learn Cloud Native」ブログが参考になります。

クラウドにおける暴露の観点から、攻撃者は様々な方法でアクセスすることができます。

侵害されたユーザー・アカウントがあるかもしれません。
不正なユーザーが、既存のフルパーミッションまたは共有パーミッションのまま組織を離れている可能性があります。
公衆向けのアプリケーションやサービスにおいて、単純な設定ミスが確認される可能性があります。

スクリーンショット: Azure Threat Detection Matrix

ランサムウェアは、クラウドにおける脅威検出の一連の失敗の結果として発生します。最初に抱えている問題ではないので、この種の攻撃を防ぐことができるように、それぞれの手法を評価し、検知することが必要です。今回の場合は、Azure上のランサムウェアです。

一連のAzureのベストプラクティスを適用して、実行時の異常な振る舞いの検出を実装するだけでなく、アプリケーションライフサイクルのパイプラインの早い段階で検出する必要があります。CI/CD パイプラインのイメージスキャンによって Infrastructure-as-Code (IaC) テンプレートに誤った設定が存在しないことを確認し、さらにユーザー単位で提供されるlimited-trustユーザー認証情報などのガードレールの構築も必要です。以下、これらのベストプラクティスをそれぞれ取り上げてみたいと思います。

Microsoft Defender や Azure Sentinel などの Azure 脅威検出ツールについて見ていく前に、優れた衛生管理の設定が重要です。

ユーザーに固有のクレデンシャルを持たせること（クレデンシャル共有ではない）。
多要素認証(MFA)を実施する。
最小特権の原則に従い、ユーザー権限を制限する。
Azure環境に出入りできる接続を制限する。

それでは、Azureの脅威検知マトリクスを見ていきましょう。

偵察（Reconnaissance）

Nmap、Metasploit、SQLMap、その他多くのツールは、Azureインフラストラクチャーレベルでスキャンする能力を持ち合わせていません。ScoutSuiteやaws-extended-cliのような他のツールは、クラウド環境に焦点を当てており、セキュリティ姿勢の評価を可能にするのに役立つ可能性があります。

では、具体的にどのホストが公開用アプリケーションを実行しているのか、あるいは既存の脆弱性をどのように特定するのでしょうか。

IPディスカバリー

パブリックIPアドレスは、インターネットリソースがAzureリソースに対してインバウンド通信を行うことを可能にします。リソース上のIPアドレスを確認するには、Virtual Network Interfaceを表示することで簡単に行うことができます。
Azure CLIでaz network public-ip show を実行するだけです。

パブリックIPアドレスは、Microsoft Azureの特定のPricing Units（SKU）で作成されます。Basicサービスでは、パブリックIPアドレスのセキュリティはデフォルトでオープンになっています。ネットワークセキュリティグループ（NSG）は、インバウンドまたはアウトバウンドのトラフィックを制限するために推奨されますが、オプションです。このNSGを設定しないと、ランサムウェアの拡散を目論む潜在的な敵対者にクラスターが開放されることになります。

Azure の NSG は、ルールまたはアクセスコントロールリスト (ACL) をアクティブにする標準的な方法で、仮想ネットワーク内の仮想マシンインスタンスへのネットワークトラフィックを許可または拒否します。NSGは、サブネットまたはそのサブネット内の個々の仮想マシン・インスタンスに関連付けることができます。

標準のSKUは、フロントエンドとして使用する場合、インバウンドトラフィックに対してクローズすることを意味する、「デフォルトでセキュア」モデルを提供しています。これは改善されましたが、アプリケーションの動作に必要なインバウンド・アウトバウンドのトラフィックは許可し、それ以外のトラフィックはNSGで制限するという「最小特権」の概念を考慮する必要があります。

ポートマッピング

仮想ネットワークインターフェイスに割り当てられた NSG を表示することで、仮想マシンのオープンポートを表示することができます。これは、Azure CLI から ‘az network nsg show‘を実行するのと同じようなプロセスです。

ホストノードの仮想IPについて考えると、DHCP、DNS、IMDS、ヘルスモニタリングなどの基本的なインフラストラクチャーサービスは、仮想化されたホストIPアドレス168.63.129.16と169.254.169.254を通して提供されます。これらのIPアドレスは、すべてのリージョンで使用される唯一の仮想化IPアドレスです。実際には、リンクローカルアドレス「169.254.169.254」はAWS、GCP、Azureで使用されています。

デフォルトでは、これらのサービスは、各サービスに固有のサービスタグによってターゲットにされない限り、設定されたNSGの対象にはなりません。この基本的なインフラストラクチャー通信を上書きするには、NSGルールで次のサービスタグを使用して、トラフィックを拒否するセキュリティルールを作成します。

AzurePlatformDNS
AzurePlatformIMDS
AzurePlatformLKM

NSG ルールのプロパティは、以下のとおりです：

例：すべての受信ネットワーク接続を拒否する

また、ホスト仮想マシン（VM）上で特定のポートが開いているアップタイム（合計時間）を制限することで、攻撃に関連する露出を減らす必要があります。現実的には、ポートスキャン攻撃の場合、ポートはごく短時間だけ開いていればよく、基本的なメンテナンス作業を行うには十分な時間です。ジャストインタイム VM アクセスは、Azure VM 上でこれらのポートが開いている時間を制限するために使用することができます。

NSGルールを活用して、セキュアな設定とアクセスパターンを強制します。

初期アクセス

最も一般的な攻撃方法の1つは、Windowsホストにアクセスするためのリモート・デスクトップ・プロトコル（RDP）、またはLinuxシステムのためのセキュア・シェル（SSH）プロトコルを介して行われています。以前、AWSのEC2インスタンスに対するSSH接続の保護に関するブログ記事を書きましたが、これらの検討事項の多くは、Microsoft Azure VMにも適用できるはずです。

ホストエンドポイントにリモートアクセスする方法として、両者は類似していますが、両者には明確な設計上の違いがあります。デザインに関しては、SSHはアクセスするためにVPNやMFAなどの追加ツールを必要としませんが、RDPはその両方を必要とします。いずれの場合も、これらのアクセス方法の主な問題は、クレデンシャルの管理方法、エンドポイントの公開方法、そしてユーザーエクスペリエンスに影響を与えるとしても、何層ものセキュリティを追加できるかに基づいていることです。

有効なクレデンシャル

上記のように、敵対者や不満を持つ元従業員は、有効なクレデンシャルを使用して組織外からAzure ADにログインすることができます。アカウントやサービスプリンシパルに有効な認証情報でログインすることで、敵対者はそのアカウントやサービスプリンシパルのすべての特権を引き受けることになります。そのアカウントに特権がある場合、永続化または特権の拡大といった他の戦術につながる可能性があります。

Active Directoryのプロトコルは広く知られています。また、Active Directoryがランサムウェア攻撃の主要な標的であり続けていることも特筆に値します。セキュリティとデータ管理の必要性が高まる中、Azure ADのような先進的なクラウドアプリケーションへの移行が進む一方で、注目すべきギャップがいくつか存在します。

RDPインスタンスに対するブルートフォース攻撃の防御

RDPインスタンスを保護するために、アカウントロックアウトの閾値を設定することを強くお勧めします。閾値が設定されていない場合、攻撃者はアカウントの乗っ取りが成功するまでインスタンスを「ブルートフォース」することができます。攻撃者は現実的に、正しいパスワードが「推測」されるまで、自動化ツールの一種を使用して、多くのパスワードを連続して送信する必要があります。これは、個々のユーザーでは不可能です。

ログイン失敗回数を10分間に10回などの閾値に設定することで、この種の攻撃ベクトルを防ぐことができるはずです。Microsoft Azureは、Azure AD内にIdentity Protectionというツールをネイティブで実装しており、認証イベントに関する潜在的なリスクの高い動作を特定するように設計されています。Azure AD Premium P2 ライセンスを持つユーザーは、是正措置に従って疑わしい行動をチェックし、悪意のあるアカウントの乗っ取りを防ぐための措置を取ることができます。

シングルサインオン(SSO)に対するパスワードスプレー攻撃

パスワードスプレーは、ブルートフォース攻撃の一種です。この攻撃では、悪意のある行為者は、アプリケーション上のデフォルトのパスワードを持つユーザ名のリストに基づいて、総当り的にログインします。

例えば、攻撃者は一つのパスワード（例えば、Sysdig@123）をアプリケーション上の多くの異なるアカウントに対して使用し、多くのパスワードで一つのアカウントをブルートフォースする際に通常発生するアカウントロックを回避します。

SSOユーザーの場合、パスワードを入力せずに自動的にAzure ADにサインインすることができます。これは、弱いパスワードを手動で再利用することから解放されるため、素晴らしいことです。しかし、SSOに使用されているプロトコルには欠陥があり、攻撃者はシングルファクターのブルートフォース攻撃を実行することができます。この欠陥はSSOに限ったことではありませんが、パスワードは強力である必要があります。

マイクロソフトは、ログイン時の高度な防御策として、多要素認証（MFA）の利用を推奨しています。MFAは、パスワードの漏洩を完全に防止することはできませんが、出発点としては有効です。例えば、MFAをデプロイすると、企業のサポート・プロバイダーはリモートPowerShell（RPS）を通じてコンタクトを取ることができなくなります。そのため、社員は通常、Office 365で作成された管理者アカウントを使用して簡単にアクセスすることになります。このようなアカウントは、悪者が探しているものであり、MFAセキュリティのないものです。

このケースは、有名なDeloitteの情報漏えい事件でも起こりました。悪者は、「二段階認証」のない昇格した管理者アカウントを使用して、同社のグローバルメールサーバーに侵入しました。

実行

マイクロソフトは、Azure ADソリューションを、悪者が横方向に移動したり、データを盗んだりすることを防ぐ方法で構築しています。

攻撃者は、Azureプラットフォーム上でランサムウェアを成功させるために、データがどこにあるかを探しながら、クラウドアカウントの中を移りたいと考えているため、これは素晴らしいことです。

マイクロソフトは、デフォルトのセキュリティソリューションでAzure AD内にきめ細かいセキュリティコントロールが実装されていることを保証しますが、攻撃経路には、Microsoft ADの設計にはなかった弱点があります。

Organizational Unit(OU)のサポート不足

Azure ADは、ADとは異なり、Organizational Unitをサポートしていません。グループを通じてユーザーやデバイスを管理することは、大規模な組織内でアクセスを監視する最も簡単な方法です。したがって、OUのサポート不足は、ITチームの管理負荷の増大につながる。ITチームは冗長な活動を見落としがちで、セキュリティが損なわれてしまうのです。

Group Policy Object(GPO)の未対応

また、ネットワークに接続するデバイスの管理が不十分であることも注目すべき点です。従来のMicrosoft ADとは異なり、Azure ADではグループポリシーもサポートされていません。これらは、管理者がネットワーク上のすべてのデバイスを管理するのに役立ちます。大規模な組織では、GPOなしでデバイスの設定を管理することはほとんど不可能です。

マルウェアがダウンロードされると、ローカルシステムとネットワークシステムをスキャンして、暗号化するファイルを探します。グループポリシーがなければ、ランサムウェアのような横方向の動きを阻止するためのネットワーク制御が制限された攻撃を目にする危険性があります。

認証情報の漏洩がなければ、サイバー攻撃者が標的の組織に入り込み、悪意のあるペイロードを投下する最も簡単な方法は、単にログインすることである可能性があります。次に、このような特権の昇格の試みがどのように行われるかを見ていきます。

特権昇格

敵対者は、現在のアカウントがPrivileged Identity Management（PIM）経由でロールをアクティブ化する資格がある場合、特権を昇格させる可能性があります。PIM サービスは Azure AD 用に設計されており、組織内の重要なリソースへのアクセスを管理、制御、および監視することができます。また、RBAC（Role Based Access Controls）を使って、特定のサービスへのアクセスや、そのサービス内での権限昇格を防止する方法にも注目したいところです。

特権ID管理(PIM)

安全な情報やリソースにアクセスできる人の数を最小限にすることで、最終的には悪意ある人物が我々の環境にアクセスする機会を減らし、正規ユーザーがMS Azureの機密リソースに不用意に影響を与えることを防ぎます。

PIMは、Azure ADの特権アクセス管理（PAM）ソリューションの一種として機能します。PIMは、特権ユーザーの活動、セッションの記録、頻繁なパスワードの変更などの完全な監査証跡を提供します。PIMは、指定されたユーザーに標準的なユーザー以上の特別なアクセスを提供するため、特権アカウントの不正使用を保護する必要があります。

ロールベースアクセスコントロール(RBAC)

Azure RBACは、Azure固有のリソースへのアクセスを管理するための認可システムです。例えばAzure ADでは、RBACユーザーは自分の役割に必要な特定のアプリケーション/サービスに対する権限を持ちます。例えば、SQL DBAは必ずしもAzure Kubernetes Service（AKS）へのアクセスを必要とせず、確かにAKSでクラスターを作成したり削除したりするためのフルアクセスは必要ありません。異なるロールアカウントを作成することで、攻撃者がそのユーザーアカウントにアクセスした場合の影響範囲に対して明確な影響を与えることができます。

スクリーンショット： Azure RBACは、管理グループ全体、アカウントサブスクリプション、カスタムリソースグループ、またはそれらのリソースグループ内で実行される個々のリソースに範囲を設定できます[画像出典：learn.microsoft.com]

ここでは、Azure ADの一般的な4つのロールを紹介し、その仕組みについて理解を深めます。

読み取り専用アクセスの役割
これは、「限定的な信頼」権限を実装しようとしているチームに強く推奨されるユーザーアクセス制御です。攻撃者がAzure ADのこのロールを侵害した場合、機密情報にアクセスすることはできますが、基本的な読み取り専用の特定のアクションに制限されます。
攻撃者は、Azureで変更を加えるための昇格した権限を持たなくなりました。彼らは、vNetsを通じて新しいターゲットとアドレス空間を追跡することはできますが、所有者アクセスロールを介して達成することができるアプリケーションの権限を昇格することはできません。

オーナーアクセスロール
このロールは、あまり使用しないでください。この場合のオーナーは、リソースを編集し、あらゆるリソースにパーミッションを付与する権限を持ちます。したがって、このロールは、Microsoft Azure内の他のサービスに対する許可/アクセスを自分に与えたいと考える脅威行為者にとって、非常に興味深いものです。これは、Azure上のランサムウェアの最悪のシナリオです。

コントリビューターロール
このロールは、他のユーザーへのアクセス許可を許可しません。これは、Azure ADリソースを管理するために特別に設計されています。ヘルプデスクチームは、新しいフォルダーとファイルのアップロードを許可するために、このロールを制限された状態で使用することができます。このロールのユーザーは、ファイルの削除、移動、またはコピーすることができません。これは、エンドユーザーのミスによって引き起こされる可能性のあるデータ損失を防止しながら、「ゼロトラスト」周辺のコンプライアンスを確保することを意味します。

az role assignment create --assignee "[email protected]" \
--role "Reader" \
--resource-group "technical-marketing"

リソースグループ「technical-marketing」のスコープで、[email protected] のユーザーに Reader のロールを割り当てます。

永続化

攻撃者がすでにブルートフォース/パスワードスプレー攻撃として前述した技術の1つによってアクセス権を獲得し、その権限をエスカレートすることに成功したと仮定すると、敵は今、NSGのルールを変更して追加のポート上でアクセスを確立し、その横移動を実行することができます。

Microsoft Defender for Cloudは、Extended Detection and Response（XDR）とも呼ばれる高品質の脅威検知および応答機能を提供します。Microsoft Defender for Cloudは、パスワードスプレーのようなブルートフォースの試みを監視するだけでなく、セキュリティを無効にする敵対者を監視するためにも使用できます。これは、Human Operated Ransomware（HumOR）攻撃チェーンの一部であることが多いためです。

従来のオンプレミス環境では、ディスクの暗号化を防ぐために、エンドポイントを隔離することが重要です。エンドポイントの隔離とは、基本的にリスクのあるコンピュータやその他のエンドポイントデバイスを、ネットワークの他の部分から分離することを意味します。隔離されれば、セキュリティ・チームは脅威を積極的に除去し、修復や調査プロセスを実行することができます。セキュリティ上の問題がすべて解決されたら、感染したエンドポイントをネットワークに再接続し、感染したデバイスがネットワーク上にある間に起こりうる横方向の動きやあらゆる形態のデータ漏洩を軽減することができます。

クラウドVMは簡単に起動・終了できるため、永続性の観点からは、これは最大の関心事ではありません。その代わりに、イベントログの消去など、敵が防御回避を試みるシナリオを優先する必要があります。特に、侵入検知やインシデント対応のフォレンジックに必要なセキュリティイベントログやPowerShellオペレーションログを破壊しようとする場合は、そのようなシナリオに注目する必要があります。

セキュリティコントロールの無効化

特権昇格で述べたように、攻撃者は、特定の NSG に関連するセキュリティツール/コントロールを無効化し、検出を回避することもできます。

一般的に、Azure Defender のマルウェア対策は、既知のランサムウェアを軽減するように設計されているため、エンドポイント、メールサーバー、およびネットワークを自動的に保護するはずです。しかし、新しいランサムウェアの亜種は、そのような保護を回避して、ターゲットシステムへの感染に成功するケースがあるかもしれません。Falcoは、攻撃者がこれらのセキュリティ制御を無効にする前に、ホストVMやコンテナ化されたワークロード内での権限昇格の試みに警告を出すのに役立ちます。

Linuxでは、SUID（Set User ID）とSGID（Set Group ID）ビットが有効な場合、非ルートユーザがルートアクセス権限を昇格させるためにいくつかのバイナリやコマンドを使用することが可能です。特権の昇格を可能にする実行可能なコマンドは多数存在します。

GTFOBins は、設定ミスのあるシステムでローカルのセキュリティ制限を回避するために使用できる Unix バイナリの精選リストです。この具体的な使用例では、SUID および GUID ビットの変更を検出できる Falcoルールに焦点を当てます (しかし、ベストプラクティスとして、それらの他の実行コマンドに関するルールの作成も検討する必要があります)。

- rule: Set Setuid or Setgid bit
  desc: >
    When the setuid or setgid bits are set for an application,
    this means that the application will run with the privileges of the owning user or group respectively.
    Detect setuid or setgid bits set via chmod
  condition: >
    consider_all_chmods and chmod and (evt.arg.mode contains "S_ISUID" or evt.arg.mode contains "S_ISGID")
    and not proc.name in (user_known_chmod_applications)
    and not exe_running_docker_save
    and not user_known_set_setuid_or_setgid_bit_conditions
  output: >
    Setuid or setgid bit is set via chmod (fd=%evt.arg.fd filename=%evt.arg.filename mode=%evt.arg.mode user=%user.name user_loginuid=%user.loginuid process=%proc.name
    command=%proc.cmdline container_id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag)
  Priority:
    NOTICE
  tags: [process, mitre_persistence]

このような動作は、ファイルとディレクトリの両方に存在します。ファイルやディレクトリの SUID や SGID ビットを変更することで、他のユーザがファイルの所有者（つまり root）と同じアクセス権限で実行できるようになり、一般ユーザがシステム管理者が所有するパスワードファイルを編集できるようになります。

その結果、MFA、強力なパスワード、限定的な信頼ルール、Falcoのような追加のフォレンジックツールなど、優れたユーザーアクセス衛生を実装し、ユーザーが異常な強制ログインを実行したり、特権の昇格を試みているケースを特定することが非常に重要になります。

目標は、これらのアクションがエスカレートし、最終的にAzure上のランサムウェアに至る前に、最も早い段階で防御することです。

ルートキットを介したランサムウェアの拡散

ルートキットは、ターゲットコンピュータにアクセスするために作成された悪意のあるコンピュータソフトウェアの集合体であり、多くの場合、その存在や他のソフトウェアの存在を隠すことができます。ルートキットという言葉は、「root」（Unix系OSの特権アカウント）と「kit」（ツールを実装するソフトウェア部品を指す）を連結したものです。

多くのユーザーは、ワークロードやサービスをルートとして実行しようとする試みを検出するために、オープンソースのFalcoを使用することに既に慣れていると思われます。しかし、このブログでは、よりランサムウェアに特化した動作に焦点を当てることが最善だと思います。多くの場合、ルートキットは、検出を回避し、永続性を確保するために、/devディレクトリ内に非デバイスファイルを書き込みます。

このような挙動を検出するためのFalcoのルールを構築することは、本当に役に立ちます：

- rule: create_files_below_dev
  desc: creating any files below /dev other than known programs that manage devices. Some rootkits hide files in /dev.
  condition: (evt.type = creat or evt.arg.flags contains O_CREAT) and proc.name != blkid and fd.directory = /dev and fd.name != /dev/null
  output: "File created below /dev by untrusted program (user=%user.name command=%proc.cmdline file=%fd.name)"
  priority: WARNING

持ち出し(Exfiltration)

攻撃者は、企業の機密データを Command & Control (C2) サーバーに送信することで、盗み出し/盗もうとします。

ブラックリストに登録されたC2サーバーに関連する既知の悪質なIP/ドメイン名への接続を防止すれば、これらの宛先へのデータ流出を具体的に防止することができます。

脅威フィード

Falcoは、既知の悪質なIPへの異常なアウトバウンド接続を検出するために使用できるオープンソースのソリューションです。このステップを完了するために、このルールを /etc/falco/malicious_ips_rule.yaml の下にあるファイルに書き込みます。

以下のコマンドでは、5つ以上のソースに出現するIPの圧縮リストをcURLで取得し、そこからFalcoのリストマクロを生成し、任意のフィードを使用することができます。ここでは、Abuse.chのセキュリティアナリストによって管理されているFeodoTrackerという無料の例を使用しています。

生成されたFalcoリストをmalicous_ips_list.yamlという名前のファイルに保存します。

curl --compressed https://feodotracker.abuse.ch/downloads/ipblocklist.txt 
2>/dev/null | grep -v "#" | grep -v -E "s[1-5]$" |  cut -f 1  | sed "s/.*/'"&"',/g" 
| tr 'n' ' ' | sed "s/, $//" | sed 's/.*/- list: malicous_ip_list'$'n  items: [&]/'
  > /etc/falco/malicious_ips_list.yaml

悪意のあるIPリストを‘malicous_ips_list.yaml’に書き込んだら、提供されたIPアドレスのリストへの接続とそこからの接続を検出するFalcoのルールを作成することができます。

– rule: Malicious IPs
 desc: Detect connections to/from a malicious IP
 condition: (inbound_outbound) and fd.sip in (malicous_ip_list) or fd.cip in (malicious_ip_list)   
 output: >
   Suspicious connection to/from a malicious IP detected (command=%proc.cmdline connection=%fd.name user=%user.name container_id=%container.id)
 priority: WARNING
 tags: [network]

このトピックにご興味のある方は、FalcoによるTORネットワーク接続の検出について、にてより詳しくご覧いただけます。

ネットワークポリシー

インフラストラクチャーレベルで NSG を使用することについて説明しました。重要なことですが、AKSのようなAzureサービスにもゼロトラストの同じ概念を適用することが重要です。

Kubernetes 内では、以前のポリシーで明示的に許可されていないすべてのトラフィックをドロップするdefault-deny ポリシーを使用できます。そうすれば、脅威のフィードで明示的にフラグを立てて落としたトラフィックであろうとなかろうと、余分なトラフィックはすべて落とすようにします。これは、NSG にも適用すべき素晴らしいプラクティスです。

以下は、NetworkPolicies の例です：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
Metadata:
  name: default-deny-all
Spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

機密性の高いユーザーデータのバックアップ

ランサムウェアの攻撃は、機密性の高いデータやシステムを暗号化するか破壊することを意図して設計されています。もしデータがエンドユーザーにとって価値のないものであれば、企業が身代金解放料を支払うインセンティブはないでしょう。

サードパーティのC2サーバーに機密データを漏洩させる以外に、敵は、身代金の支払いによって機密データを確実に回収するために、お客様のデータのバックアップをターゲットにします。バックアップが暗号化されたり破壊されたりした場合、組織にはデータのコピーが存在しなくなります。

Azure Backupは、データが転送中および保管中に、バックアップ環境にセキュリティを提供します。この場合、バックアップはAzureストレージ内に保存されるため、攻撃者は機密性の高いバックアップストレージに直接アクセスすることができません。VMと同様に、AzureはストレージのバックアップスナップショットをAzure fabricと呼ばれるサービス内に作成し、ゲストや攻撃者はアプリケーションの一貫したバックアップのためにワークロードをquiescingする以外、関与することはありません。

az backup protection backup-now \
    --resource-group testRG \
    --vault-name testRecoveryServicesVault \
    --container-name nigelsVM \
    --item-name nigelsVM \
    --backup-management-type AzureIaaSVM
    --retain-until 11-12-2022

例：仮想マシン「nigelsVM」をバックアップし、リカバリーポイントの有効期限を2022年12月11日に設定する場合

バックアップ管理は、上記のステップのすべてが失敗した場合の最後の保護ラインとして考慮されるべきです。組織がランサムウェアの攻撃を受けたと仮定すると、最初の攻撃を受ける前に、最も重要なシステムを特定し、キルチェーン全体でベストプラクティスを適用することは、企業の発生時対応に役立ち、インシデント発生前のスナップショットに迅速にロールバックすることができます。

バックアップ管理は、ランサムウェアAzureの攻撃を防御するものではありませんが、組織への影響を軽減するものです。実際、CISAは、個人および企業が機密データをバックアップする際に、3-2-1戦略と呼ばれるものを使用することを推奨しています。

3-2-1バックアップルールの内容は以下の通りです：

3 – 重要なファイルは、プライマリファイルとバックアップの2つの合計3つのコピーを保存する。
2 – 異なる種類の危険から保護するために、2つの異なる種類のメディアにファイルを保管する。
1 – コピーをオフサイトに保管する（例：感染の可能性があるクラウド環境に置いてはならない）。

まとめ

組織は、最小特権の原則を適用することで、（ほとんどの場合）最初のアクセスだけでなく、横方向の移動も防止することができます。最小特権の原則は、すべての人、すべてのデバイス、すべてのアプリケーションなどは、組織にとって潜在的な脅威であり、特定の職務を遂行するために必要なアクセス権限のみを付与すべきであるという前提に基づいています。

最小特権は、スキャンしてクラスターにデプロイできるイメージ、NetworkPolicies で許可/拒否するネットワークトラフィック、NSG で許可/拒否する接続に適用することができます。上記の最小特権の原則を実施するのは簡単なように聞こえるかもしれませんが、以下のように責任の所在を明確にすることで、チームが Azure 環境のセキュリティポスチャーを積極的に管理するようにすることが必要です。

セキュリティ状況の監視
アセットに対するリスクの軽減

これらのタスクを自動化して簡素化することで、Azure 脅威調査マトリクスのさまざまな段階における Azure 上のランサムウェアの攻撃を防御する能力が高まります。これらのタスクを手動で行うと、エンドユーザーのエラーのリスクが高まり、組織の変更に対応できなくなる可能性があります。

Sysdig Secureは、Microsoft Azure環境と、AKS内部で実行されるコンテナ化されたワークロードに対して、エンドツーエンドのセキュリティを提供します。Sysdig Secureは、マルチクラウドやハイブリッドクラウド環境のセキュリティ姿勢も監視するため、管理者は将来、新しい管理者に責任を簡単に引き継ぐことができ、複雑な再設定やトレーニングをしなくても、同じルールや監視を継承することができるのです。

このブログではAzureのランサムウェアについてのみ説明しましたが、AWSやGCPでは方法が異なりますので、1つのソリューションでそれぞれの環境に対して標準的なセキュリティ制御と監視を実施できれば、セキュリティ運用の頭痛の種が減ることは間違いないでしょう。

Azure MarketplaceでSysdig Secure DevOps Platformをご購入ください！

Sysdigは、Azure Marketplaceで簡単にご購入いただくことができます。