Multifactor Authentication Is Not Enough to Protect Cloud Data
2024/06/22 DarkReading — UNC5537 として知られるサイバー犯罪者グループが、大暴れしている。この1ヶ月の間に、ShinyHunters または Scattered Spider に関連すると思われる身代金要求グループが、Ticketmaster から5億6000万件以上の顧客記録を盗み出し、5月28日に再構成されたリークサイト BreachForums に掲載し、$500,000 を要求した。その2日後に、このグループはスペインを拠点とする Santander Bank から 3,000万件の口座記録を盗んだと主張し、$2 million を要求している。そして、両社とも、このポストの後に情報漏えいを認めた。

6月10日に公表された Google 傘下の Mandiant の分析によると、一連のデータ流出の原因は、脆弱性の悪用に起因するものではなく、盗み出された認証情報の悪用と、多要素認証 (MFA) の管理不備にあるようだ。
Mandiant は、「当社の調査では、Snowflake 顧客アカウントへの不正アクセスが、Snowflake のエンタープライズ環境の侵害に起因することを示唆する証拠は見つかっていない。その代わりに、このキャンペーンに関連するものとして、Mandiant が対応した全てのインシデントは、漏洩した顧客の認証情報にまで遡ることができた」と述べている。
ReliaQuest の Senior Cyber Threat Intelligence Analyst である Chris Morgan は、「Snowflake システムからのデータ盗難は、MFA により防ぐことが可能だったかもしれないが、同社の失敗は、この単一のコントロールの欠如に留まらない。クラウド・サービスを利用している企業は、攻撃対象領域を可視化し、元従業員や請負業者のアカウントを迅速に削除し、日和見的な攻撃者がシステム/ネットワーク/サービスを侵害する手段を減らす必要がある。今回のことで学んだ最大の教訓は、脅威アクターは洗練されたテクニックを用いる必要はないということだ。つまり、安全ではない認証情報という、直ぐに手の届く場所にある果実が標的にされていた。したがって、脅威アクターたちは、ほとんど労力を必要とせずに、十分なチャンスを手にできている」と述べている。
以下は、このところ相次いているクラウド侵害から得た、5つの教訓である。
- MFAから始めて、その先へ
MFA の採用には、まだまだ伸びしろがある。1年前に発表された Okta レポートによると、作業者の 64% が、そして、管理者の 90% が MFA を使用しているとされている。その一方で、Orca Security の “2024 State of Cloud report“によると、ユーザー組織の 10社中 6社以上で、アカウントで MFA が有効化されていない root/admin が、少なくとも1人はいるという。
クラウド・セキュリティ企業 Mitiga の CTO である Ofer Maor は、「企業は一貫したかたちで、そして検証可能なかたちで、100% を達成する必要がある。MFA の実施を必須とし、SSO [single sign-on] を使用している場合には、非 SSO ログインが無効化されていることを確認する必要がある。従来からの MFA に留まらず、機密性の高いインフラにはデバイスやハードウェアをベースとする認証などの、さらなるセキュリティ対策を講じる必要がある」と述べている。
- アクセス制御リストを使用して、許可されたIPアドレスを制限する
さらにユーザー組織は、ACL [access control lists] を導入し、ユーザーがクラウド・サービスにアクセスできる場所を制限すべきである。そして、少なくとも日ごとにアクセスログをレビューして異常を発見できるようにすべきである。
IANS Research の faculty analyst and cybersecurity practitioner である Jake Williams は、「そうすることで、サイバー攻撃者の能力を、さらに制限することができる。どのようなクラウド・インフラであっても、アクセスできる IP アドレスを制限するのがベストプラクティスである。それが不可能な場合には、アクセス・レビューがより重要になる」と指摘している。
- クラウド・サービスの可視性を最大化する
ユーザー企業として必要なものには、アプリケーションを継続的に監視するための、有意義な方式の確立がある。ログ・データ/アクセス・アクティビティ/データ・ソースなどを全体像に集約するサービスは、たとえば Snowflake 攻撃などの、検出と防止に役立つ。
さらに、組織は特定の動作や脅威の検出に対して、アラートを出せるよう準備する必要がある。このアプローチにより、サイバー犯罪者が自社のクラウド・データにアクセスしようとしたことを検知できる。
SaaS Security Posture Management 企業 AppOmni の CTO である Brian Soby は、「セキュリティ・オペレーション・チームは手薄であり、一般的な企業で使用されている各種のアプリケーションについて、深い専門知識を身につける機会を持てないだろう。しかし、彼らのツールやセキュリティ・プラットフォームは、これらの問題を迅速に特定できる。このシナリオで明らかになるものには、通常とは異なる場所からの異常なログインや、非常に疑わしい攻撃者のアプリケーションと、顧客の Snowflake インスタンスとの接続などがあるはずだ」と指摘している。
- クラウド・プロバイダーのデフォルトに頼らない
クラウド・サービス・プロバイダーは、セキュリティは責任共有モデルであると強調したがるが、攻撃者がクラウド・プロバイダーのインフラやソフトウェアに侵入しない限り、その責任は大半は常に顧客の側にある。具体的な事例としては、昨年の Progress Software MoveIT の脆弱性などが挙げられる。
しかし、多くの場合において、クラウド・プロバイダーが優先するのは、セキュリティよりも使い易さである。したがって、ユーザー企業は、プロバイダーのデフォルトの安全性に依存すべきではない。たとえば Snowflake の場合においても、デフォルトでセキュリティ・コントロールを ON にするなどの、MFA の管理を容易にするために出来ることがたくさんあったはずだ。
Mitiga の Maor は、「この攻撃が成功し、この規模になったのは、Snowflake のアカウントのデフォルト設定が、MFA を必要としていないからだ。通常、気密性の高いプラットフォームであれば、ユーザーは MFA を有効にする必要がある。Snowflake は MFA を必要としないだけではなく、管理者による実施が、きわめて難しくなっている」と指摘している。
- サードパーティのチェック
最後になるが、たとえユーザーが Snowflake などのクラウド・サービスを使用していなくても、サードパーティ・プロバイダーがバックエンドに Snowflake を使用している可能性がある。したがって、ユーザー企業のデータが、リスクにさらされていることに注意する必要がある。
IANS Research の Williams は、「たとえ使っていなくても、あなたのデータは Snowflake 上にあるかもしれない。サードパーティのサービス・プロバイダーにデータを渡し、そのサービス・プロバイダーが Snowflake 使用していても、ベスト・プラクティスが採用されているかどうかは分からない。ユーザー組織は、データにアクセスできる全サービス・プロバイダーと連絡を取り、彼らが情報を保護するために適切な措置をとっていることを確認する必要がある」と述べている。
Snowflake 侵害とクラウドの保護について、しっかりと整理してくれるマトメ記事です。こういうときに頼りにする DarkReading ですが、さすがという感じです。タイトルにあるように、MFA が有効化されていなかったことが大きな要因ですが、考えるべきことは、それだけではありませんね。よろしければ、以下のリストも、ご利用ください。
2024/06/21:Santander 報告:情報漏えいと Snowflake の関係は?
2024/06/14:Snowflake 侵害をトリアージ:YetiHunter ハンティング・ツール
2024/06/13:Truist Bank から盗まれたデータが $1 M で販売されている
2024/06/10:BlackBerry Cylance のデータがダークウェブで販売されている
2024/06/01:Apache Log4J2 脆弱性の悪用:Sisense/Snowflake への侵害
2024/05/31:Snowflake のデータ侵害:Santander/Ticketmaster
You must be logged in to post a comment.