パブリッククラウド特有の脅威の向き合い方

近年急速に活用が進むパブリッククラウドですが、同時にパブリッククラウド特有のセキュリティ事故も多発しています。
本スライドでは、パブリッククラウド特有のセキュリティ脅威や事例について紹介し、それらに対する防御の考え方を示すことで
より安全にパブリッククラウドを活用いただくことを目的としています。

Transcript

1. Cloud Security for Enterprise パブリッククラウド特有の脅威の向き合い方
2. 本発表について 2 本スライドの目的 想定する読者 免責 謝辞 近年急速に活用が進むパブリッククラウドですが、同時にパブリッククラウド特有のセキュリティ事故も多発しています。 本スライドでは、パブリッククラウド特有のセキュリティ脅威や事例について紹介し、それらに対する防御の考え方を示すことで より安全にパブリッククラウドを活用いただくことを目的としています。 主な想定読者は次のとおりです。 • パブリッククラウド特有のセキュリティについて知りたい企業 • パブリッククラウドの利用を開始して日が浅い企業 本資料の作成に先駆けて技術検証および調査で大変な助力を賜った、株式会社ラック様および伊藤忠テクノソリューションズ株式会社様、そしてご協力 頂きました全ての方々にこの場を借りて心より感謝申し上げます。 本スライドの中でご紹介する実際に発生したセキュリティインシデントの内容については全て公開されている範囲としています。また、本発表 で紹介する防御の考え方は特定のパブリッククラウドサービスによらない汎用的な考え方のため自社に適用する場合は細心の注意を頂き、 それにより発生したいかなる損害も責任も追いかねます。 本スライドの使用について 本スライドについて営利目的の利用や、筆者に許可のない複製・改変による再配布を禁止します。
3. 目次 3 • パブリッククラウドの特性 ◦ 利便性 ◦ 認証・認可とAPI ◦ IAM ◦ リソースごとの設定 • パブリッククラウドへの攻撃と侵害事例 ◦ 脆弱性悪用 ◦ Supply Chain ◦ Phishing ◦ 設定ミス ◦ etc • パブリッククラウドの防衛戦略 ◦ アクティビティ監視 ◦ ログ保全 ◦ 設定監査 ◦ 要塞化 ◦ 組織管理機能の活用 ◦ 最小権限の幻想 ◦ etc • 小ネタ ◦ ServerlessではWAFは不要？ ◦ パブリッククラウド純正のWAFってどうなの？ ◦ etc
4. icon Hayate Hazuru @kawada_syogo225 Company 伊藤忠商事株式会社 IT・デジタル戦略部 技術統括室 Work インシデントレスポンス・ハンドリング クラウドセキュリティ Webセキュリティ OSINT セキュリティ製品検証 セキュリティポリシー策定 Private 長崎出身で魚とお酒が好きです。元は開発畑の人間で SPAやServlerss、WAFの開発をやっていました。 休日はロングライドに出かけたり、カメラを持って散歩して ます。たまにダーツをやっていますがスランプ中です。 icon icon Introduction Company 株式会社アカツキゲームス 研究開発部 株式会社ステラセキュリティ Work プロダクトセキュリティ 脆弱性診断 セキュリティ製品検証 Private うどんが好きで毎年香川にうどんを食べにいきます。主に プロダクトセキュリティや社内 ITインフラのセキュリティに興 味があります。 Daisuke Miyashita @_sumisaka Norihide Saito @a_zara_n Company 株式会社Flatt Security プロフェッショナルサービス事業部 Work 脆弱性診断 • Webアプリケーション • プラットフォーム • パブリッククラウド Private 静岡出身でビールと中華と食が好きな海洋生物もどき。最 近の趣味はマイクロサービスやサーバレスなアプリケー ションにおけるアプリケーション内部におけるコンテキスト の差異やマルチクラウド環境下でのアプリケーションレベ ルでの脅威について調査をしたり、より良いビールを探し に散歩をしています。
5. PART 1
 
 パブリッククラウドの
 メリット
 パブリッククラウドの台頭によって安価かつ迅速な価 値の提供が可能となりました。 セキュリティばかり気にしてパブリッククラウドの利用 を妨げるのは本意では無いため、主題に入る前にパ ブリッククラウドそのものの利便性について簡単に触 れようと思います。
6. パブリッククラウドのメリット３選 PART1. パブリッククラウドのメリット 6 　　　　 　　　　 １．スピード パブリッククラウドでは機器の調達やキッティングなどの前工程なしに即座にリソースの確保とアプリケーションのデプ ロイが可能なため、サービス提供までの時間を短縮できます。 ２．コスト パブリッククラウドを使用することでハードウェアの調達コストや運用・保守費の削減が期待できます。用途ごとにリ ザーブドやスポットなどのリソース種別を活用することでよりインフラコストを削減できます。 ３．責任共有モデル パブリッククラウドを使用することでH/Wの冗長化や災対など多く煩わしい問題から開放されます。IaaS > PaaS > SaaSの順で利用者の責任範囲が減少し、サービス開発に集中することができます。
7. パブリッククラウドのメリット　ー スピード ー PART1. パブリッククラウドのメリット サイジング 調達コスト キッティング On- Premise 基本的にどちらも変わらない。 パブリッククラウドの場合は料金計算 ツールを使うことで、ベンダとやり取り することなく何度でも見積を作成でき る。 ベンダとの発注手続き、配送等の複数 のやり取りが発生し、数週間から一ヶ月 程度を要する。 ラックへのマウントや配線が必要。その 後、ネットワーク設定、OSやRAIDの構 成を行う。 Cloud WebコンソールやCLIを使うことで 数分から一時間程度でOSの起動まで 完了。 ラッキングなどの物理作業は不要。事前 作成した独自イメージ等を使用すること でさらに短縮できる。 パブリッククラウドの代表的なメリットとして「スピード」が上げられます。従来の計算資源の調達には社内稟 議を除いたとしても、ベンダとの見積もりや発注等の調達プロセスだけで数週間から一か月程度を要しまし たが、パブリッククラウドでは料金計算ツールやWebコンソールなどで即座に見積と資源の調達が可能で す。 7
8. PART1. パブリッククラウドのメリット 8 パブリッククラウドのメリット　ー スピード ー ステップ On-Premis IaaS PaaS（FaaS含む） SaaS サイジング 〇 〇 〇 × 見積／発注／配送 〇 × × × ハードウェアの設置／配線 〇 × × × ネットワーク設定 〇 〇 △ × OSインストール 〇 △ × × アプリケーションのデプロイ ※MySQLのような既製品と自社開発のソフトウェア含む 〇 〇 〇 × テスト 〇 〇 〇 〇 監視・運用 〇 〇 〇 △ 所 要 時 間 1. 基本的に物理的な作業は不要となる。 2. IaaS → PaaS → SaaSと行くにつれて利用者のマネジメント範囲が減る。 3. リソース確保とデプロイ時間の短縮により、迅速なサービス提供・改善が可能となる。 ユーザー側で作業が　〇：必要　△：一部必要　 ×：不要
9. パブリッククラウドのメリット　ー HW管理からの解放 ー PART1. パブリッククラウドのメリット 9 UPSに余裕あるかな... LANカードとRAIDカードの予備も必要だ... 配線表作って... OSのライセンス余ってたっけ... 納品は２週間後... HW保守もつけて... サイジング終わったし今日からでも構築開始！ スケーリングもクラウドにお任せ！ HWの冗長化はクラウドにお任せ！ ライセンス込みだから楽！
10. パブリッククラウドのメリット３選 PART1. パブリッククラウドのメリット 10 　　　　 　　　　 １．スピード パブリッククラウドでは機器の調達やキッティングなどの前工程なしに即座にリソースの確保とアプリケーションのデプ ロイが可能なため、サービス提供までの時間を短縮できます。 ２．コスト パブリッククラウドを使用することでハードウェアの調達コストや運用・保守費の削減が期待できます。用途ごとにリ ザーブドやスポットなどのリソース種別を活用することでよりインフラコストを削減できます。 ３．責任共有モデル パブリッククラウドを使用することでH/Wの冗長化や災対など多く煩わしい問題から開放されます。IaaS > PaaS > SaaSの順で利用者の責任範囲が減少し、サービス開発に集中することができます。
11. パブリッククラウドのメリット　ー コスト ー PART1. パブリッククラウドのメリット 11 アクティブユーザー 10,000人／月 ビュー数 30,000回／日 API呼び出し 100,000回／日 その他 データベースは常に 50GB のデータを保持 静的ファイルの転送は 893.55 GB／月 12回／月のビルド＆デプロイ 全てSaaS系サービスを使用して構築 合計 ￥299,040 / 年（1USD = 140円） 会員制 Web サイトをサーバーレスに構築する場合のクラウド構成と料金試算例 | AWS AWS公式の試算例を流用したものですが、 ECサイトのような会員制 WebサイトをServerlessで構築した場合の料金例です。 想定される利用量は閲覧数が一日あたり 3万PV、API呼び出しは10万 回となっていますが、それでも年間のクラウド利用料は 30万程度です。 加えて、全てPaaSで構成していますので、非常に可用性が高くスケー ラブルな構成となっています。 会員制WebサイトをServerlessで構築した場合
12. パブリッククラウドのメリット３選 PART1. パブリッククラウドのメリット 12 　　　　 　　　　 １．スピード パブリッククラウドでは機器の調達やキッティングなどの前工程なしに即座にリソースの確保とアプリケーションのデプ ロイが可能なため、サービス提供までの時間を短縮できます。 ２．コスト パブリッククラウドを使用することでハードウェアの調達コストや運用・保守費の削減が期待できます。用途ごとにリ ザーブドやスポットなどのリソース種別を活用することでよりインフラコストを削減できます。 ３．責任共有モデル パブリッククラウドを使用することでH/Wの冗長化や災対など多く煩わしい問題から開放されます。IaaS > PaaS > SaaSの順で利用者の責任範囲が減少し、サービス開発に集中することができます。
13. パブリッククラウドのメリット　ー 責任共有モデル ー PART1. パブリッククラウドのメリット 13 パブリッククラウドでは各サービスごとに「クラウドベンダー」と 「利用者」間の責任分界点が定められています。 右図はAzureにおける責任共有モデルですがどのクラウドも概ね同じような モデルとなります。 IaaS > SaaS > PaaS と進むにつれて利用者の責任範囲が減り、災害対策 や高負荷時のスケーリング、データの整合性担保などの煩わしい問題から 開放されます。 FaaS・PaaSに関しては基本的に負荷に応じて自動でスケーリングするた め、流量の多いECサイトなどを楽に運用できます。 パブリッククラウドを利用することで即座にリソースを調達し、ワークロードを デプロイする事が可能となります。 クラウドにおける共同責任 - Microsoft Azure | Microsoft Learn
14. PART 2 パブリッククラウドにおける 認証とAPI パブリッククラウド特有のセキュリティを理解するに は、パブリッククラウドを支えるAPIシステムと認証・認 可の仕組みを理解することが非常に重要となります。 後続の事例や対策の理解に必要なため、このパート では概念的な仕組みを解説します。
15. パブリッククラウドの認証・認可とAPI PART2. パブリッククラウドにおける認証と API 15 パブリッククラウドはWebコンソールやCLI、プログラムなど様々な方法で操作可能ですが、どの方法にしろ何らかの情報を提示することで認証を行い、クラ ウドの操作権限を得ることになります。本発表では「パブリッククラウド利用時の認証に使用できる各種の情報」と「認証により払い出された情報」をクレデン シャルと定義します。 どの手段をとったとしても「VMの作成」や「VM一覧の取得」の様な操作は「CreateVM」や「ListVMs」のようなAPIの呼び出しに変換され、 認証基盤にて実行許可が判断されます。 普段、Webコンソールを操作している場合は気づきにくいかもしれませんが実は裏でAPI呼び出しが行われています。 その為、有効なクレデンシャルが攻撃者の手に渡れば仮想マシンやデータベースの操作を許すことになり非常に危険です。
16. 上図はWebコンソールを使用した場合の認証の流れです。Webコンソールを使用するにはWebブラウザからID/PWやワンタイムトークンの入力 などの二要素認証を行います。 その為、このパターンのクレデンシャルはログインするためのID/PW+二要素と認証後に払いだされるCookieとなります。 主な脅威は下記となりますが、InforStealerの場合、Webブラウザやパスワードマネージャなどの様々なソースからクレデンシャルが漏洩します。 また、近年のPhishingではMitMやMFA疲労攻撃などテクニックが使用されるため、追加の対策が必要となります。 • 過去に漏洩したID/PWによる総当たり攻撃 • PhishingによるID/PWの漏洩 • InforStealerなどのマルウェア感染によるCookieやローカルからのID/PWの漏洩 ※Cookieを盗んだ攻撃者は自身のブラウザにリストアすることで 再利用が可能です。 PART2. パブリッククラウドにおける認証と API Webコンソールを使用した場合の流れ 16
17. CLI／プログラムを使用した場合の流れ PART2. パブリッククラウドにおける認証と API 17 Webコンソールによる操作は効率が悪いため、多くのパブリッククラウドではAPIキーによるクラウドの操作手段やライブラリが提供されています。基本的 にはWebコンソールで払い出しAPIキーを所定のファイルやプログラムに組み込むことで利用します。 このパターンのクレデンシャルはAPIキーです。 脅威としては下記のように多岐にわたり、APIキーは開発やシステム連携に使用する特性上、様々な箇所に格納され、格納先のセキュリティ強度に依存 することになります。 • 開発者端末やクラウド連携を行うサーバーのマルウェア感染 • VPN機器等の外部システム侵害による内部侵入 • 不用意な公開 • ソーシャルエンジニアリング • 連携システムからの漏洩
18. クラウドサービスを組み合わせた場合の流れ PART2. パブリッククラウドにおける認証と API 18 パブリッククラウドでは様々なサービスを組み合わせることでサービスを実現します。上図はユーザーがアップロードした画像から地理情報などの削除を 行いストレージにアップロードするWebアプリをAWSで実装した際の流れです。 この場合のクレデンシャルはIMDSにより発行されるトークンや、トークンを得るための情報が格納されている環境変数です。 このケースでは権限が付与されたリソース上で任意のコードを実行したり、IMDSや環境変数にアクセスできれば、有効なトークンを窃取することが出来ま す。主な脅威は下記の二点ですが、イマドキの開発では様々なOSSやツールが使用されるため、技術スタックのどこかに脆弱性や汚染があればトークン 窃取の機会が生まれる事になります。 • 脆弱性の悪用 • Software Supply Chainの汚染
19. PART2　まとめ PART2. パブリッククラウドにおける認証と API 19 1. パブリッククラウドには複数の操作手段がある 2. パブリッククラウドの操作はAPIに変換され、基本的には共通の認証基盤を通る 3. 「認証に使用できる各種情報」と「認証により払い出された情報」をクレデンシャルと定義 4. クレデンシャルを窃取することで攻撃者によるクラウド環境の操作が可能となる 5. 操作手段によってクレデンシャルが格納される場所が異なり、クレデンシャルの安全性は 格納先のセキュリティ強度に依存する。
20. PART 3 IAM入門 ここまでは、パブリッククラウドの認証・認可の仕組み について話してきました。 最後にもう一つ、パブリッククラウドのセキュリティの 理解に不可欠な「IAM」について概要をお話しします。 IAMはクラウドの操作権限を制御する仕組みで、繰り 返し登場した「認証基盤」とも密接に関係しています。
21. ID + IAM Cloud IAMとは PART3. IAM入門 21 前章で説明したように認証を行う事でパブリッククラウドの操作（API実行）が可能となりますが、とはいえ、何でも操作できてしまうと セキュリティ上よろしくありません。その為、API操作の権限の制御を行う「IAM」と呼ばれる仕組みが各パブリッククラウドで提供され ています。 例えば、IAMを使うことでWebシステムの管理者に対して「 名前がwebから始まる仮想マシンのみ起動・停止」を許可するような細か な制御も可能となります。 認証によりIAMで設定された操作権限を得ることになりますので、クレデンシャルの保護と付与する権限の最小化が重要となりま す。 開発者 運用者 セキュリティ担当 VM Detection IAM Code Repository Logging リソース
22. IAMの基本的な考え方 PART3. IAM入門 22 IAMは主に下記の4つの条件の重ね合わせによりAPIの実行許可を記述します。 • 主体（プリンシパル） ◦ 操作を行う主体です。APIを呼び出す元と考えても問題ありません。 ◦ 権限を付与される人やリソース、APIキーが組み込まれたプログラムなどです。 • 内容 ◦ 具体的に許可する操作内容です。 ◦ VMの起動のみ許可することもできれば、VMに対するあらゆる操作を許可することも可能です。 • 対象 ◦ API操作の対象となるリソースです。 ◦ webで始まる名前を持つリソースのみ操作可能など、細かい指定が可能です。 ◦ 省略可能なことも多く、その場合は全てのリソースに対して「内容」で許可したAPIを実行できます。 • コンテキスト ◦ APIを実行する際のアクセス元IPやMFA認証済みなどの、APIを実行する際の条件を指定します。 以降でいくつか、具体的なIAMの例を紹介します。
23. IAMの例　ー リソース間の連携を行うための権限割り当て ー PART3. IAM入門 23 IAM VM Storage { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "storage:PutObject", "storage:GetObject" ], "Resource": "ap-norteast-1:storeage:user-images/*" } ] } ユーザーがアップロードした画像を処理し、ストレージにアップロードするようなWebシステムの場合、上記の（四角で囲まれた部分）の ようなIAMロールを作成しVMに付与します。IAMロールの意味としては以下です。 ①　Actionに記載されているAPIを、Resourceに記載されているリソースに対して許可する。 ②　PutObject（ファイルアップロード）、GetObject（ファイル取得）のみ許可 ➂　ap-norteast-1リージョン（日本）にデプロイされた「user-images」というストレージに対する操作を許可する。 ① ➁ ➂
24. IAMの例　ー ユーザーに権限を付与する場合 ー PART3. IAM入門 24 { "Version": "2012-10-17", "Statement" : [ { "Effect" : "Allow", "Action" : [ "coderepository:CreateBranch", "coderepository:Commit, … ], "Resource" : "ap-norteast-1:coderepository:ec-front/*" } ] } IAM Code Repository taro 上記はECサイトの開発者にフロントエンドのソースコードリポジトリのみ操作を許可するIAMロールです。この開発者がAPIキー を作成した場合、そのAPIキーは開発者と同様の権限を持つことになります。意味は以下となります。 ①　Actionに記載されているAPIを、Resourceに記載されているリソースに対して許可する ②　CreateBranch（ブランチの作成）、Commit（変更のコミット）、etc ➂　ap-norteast-1リージョン（日本）にデプロイされた「ec-front」というリポジトリのみ操作可能 ① ➁ ➂
25. 複雑なIAMの仕様 PART3. IAM入門 25 このように、パブリッククラウドではIAMでロールを作成し、主体（プリンシパル）に付与することで、人による操作やリソース 間の連携を可能としています。 今回は各クラウドのIAMを抽象化して簡素に説明しましたが、実際のIAMはもっと複雑で直感的でない仕様も多々存在す るため、必ず仕様を熟読することを推奨します。 以上でクラウドの特性と仕組みの解説を終了し、以降はこれまでの話を踏まえたうえで「パブリッククラウド特有のセキュリ ティ脅威と事例」についてご紹介します。 ポリシーの評価論理 - AWS Identity and Access Management
26. PART 4 ここからはパブリッククラウドへの攻撃および、侵害 事例についてお話しします。 クレデンシャル漏洩による被害や、設定ミス、 クラウド機能の悪用など様々な事例を紹介し 後半の「防御戦略」の章に繋げます。
27. クラウド特有のセキュリティインシデント PART4. パブリッククラウドへの攻撃・侵害事例 27 実事例で学ぶクラウドコンピュートのクレデンシャル侵害 Uniqlo and The Guardian among thousands of sites loading malicious code from S3 個別の説明に入る前にいくつかのクラウド特有のセキュリティインシデントを紹介します。 一つ目は左図の海外のコードホスティングサービスの事例です。このケースでは何らかの方法で被害企業のAWS環境のアクセス権を得た攻 撃者により、顧客のコードを補完しているサーバーなどがバックアップを含めて削除されています。これにより、被害企業は事業継続が困難とな り廃業に追い込まれまれました。 右図のアパレル系企業の事例です。このケースではストレージサービスの設定ミスにより、ECサイトの決済フォームにクレジットカード情報を盗 むスクリプトが埋め込まれました。※ 幸いにもスクリプトの実装ミスにより実害は発生していないようです 三つ目は、脆弱性の悪用などによりコンピューティングリソースから窃取したトークンを利用してフィッシングメールのばら撒きを行っています。 ※中央の図の記事内の一例 以降は、ここ数年で我々が観測した特徴的な脅威・事例について取り上げます。 Hacker Puts Hosting Service Code Spaces Out of Business | Threatpost
28. クレデンシャルが漏洩すると一気呵成にシステムを掌握されるリスクがある PART4. パブリッククラウドへの攻撃・侵害事例 28 前章でCookie、APIキー、ID/PW、トークンなどのクレデンシャルと共にクラウドの操作を呼び出すと説明しました。つまり、攻撃者としては クレデンシャルさえ盗むことが出来れば、クレデンシャルの所有者と同等の権限を得ることになります。 たとえば、Webシステムの管理者は諸々の運用を行うために、全てのVMの起動・停止、データベースの読み書き、バックアップの作成・破 棄などの権限を持つことが多いと思います。 従来であれば、一台のサーバーや端末を起点として地道に Lateral Movement を行うことでシステム全体の掌握を行っていましたが、パ ブリッククラウドの場合は、漏洩したクレデンシャルによっては一気呵成にシステム全体を掌握されるリスクがあり、そのインパクトは計り知 れません。
29. クレデンシャルはあらゆる場所に存在し、漏洩の可能性も無数に存在する PART4. パブリッククラウドへの攻撃・侵害事例 29 仮想マシンやFaaSへロールを付与した場合、デプロイされたアプリやミドル ウェアの脆弱性の悪用、依存するライブラリの汚染などによりクレデンシャ ルを窃取される可能性があります。 クラウドと連携するSaaSサービスの場合、そのサービスにクレデンシャルを 預けることになります。サービスが侵害を受けた場合は預けたクレデンシャ ルが漏洩する可能性があります。 クラウド操作を行う各端末にWebコンソールのセッション情報やAPIキーが 存在します。クラウドと連携するサーバーにもクレデンシャルが存在します。 Phishing、マルウェア感染、Lateral Movement等のオンプレのインシデント が漏洩に繋がる可能性があります。 ツール開発元の侵害による汚染や、悪意あるコンテナイメージ、偽ライブラ リ、依存関係の汚染、開発ツール・拡張の汚染、偽パッケージの配布等、 Software Supply Chainを取り巻く様々な脅威によりクレデンシャルが漏洩 する可能性があります。
30. パブリッククラウド上のリソースからのトークン漏洩 PART4. パブリッククラウドへの攻撃・侵害事例 30 前章でサービス間で連携をする場合はリソースに権限を付与し、IMDSや環境変数等からクレデンシャルを取得することで他のサービス を操作可能になると説明しました。 もし、仮想マシンやFunction、コンテナにデプロイされたアプリやライブラリに脆弱性が存在し、IMDSや環境変数にアクセス出来た場 合、クレデンシャルの漏洩に繋がります。 また、近年のソフトウェア開発はOSSの活用が当たり前となっていますが、もし依存関係のどこかに悪意あるコードを忍ばせることが出 来れば、同様にクレデンシャルを盗むことが可能です。 以降では、クラウド上のシステムからクレデンシャルが漏洩するパターンや、それにつながる脅威事例を紹介します。
31. パブリッククラウド上のリソースからの漏洩　ーライブラリの汚染ー PART4. パブリッククラウドへの攻撃・侵害事例 31 Popular Python and PHP libraries hijacked to steal AWS keys まずはライブラリの汚染パターンです。上記は 2022/5 に観測された事案で、公開されているPHPのライブラリにAWSのトークンを窃取するコードが混入 していました。このコードが AWS Lambda 等にデプロイされた場合、トークンが漏洩し Lambdaに付与されていた権限の範囲でAWSを操作されかねま せん。 モダンな開発ではOSSの活用が当たり前ですが、そのOSSもまた他のOSSの組み合わせで出来ていることが殆どです。例えば、AWS S3 のクライアン ト用ライブラリである @aws-sdk/client-s3 は 103 のライブラリに依存し、AWS Amplify + React.js で開発を行う場合は 2623 のライブラリに依存しま す。攻撃者は依存関係のどれか一つでも侵害できればクレデンシャルを手に入れることが出来ます。 ここ数年でメンテされていないライブラリの乗っ取りや、開発者アカウントの不正アクセスを通じた悪性あるコードの混入が相次いでいるため注意が必要 です。
32. パブリッククラウド上のリソースからの漏洩　ー脆弱性の悪用ー PART4. パブリッククラウドへの攻撃・侵害事例 32 次は脆弱性の悪用を契機としたクレデンシャルの漏洩です。このパターンは脆弱性の悪用によりIMDSや環境変数、設定ファイル等にアクセスされる事 でクレデンシャルの漏洩が発生します。 実際にOSSの脆弱性を利用してIMDSから取り出したトークンの悪用事例が観測されており、このパターンはクレデンシャルの提供元にアクセスできれ ば何でもいいので、利用できる脆弱性は多岐にわたります。（SSRF、LFI、OS Command Injection等のRCE） 前のスライドでも触れたように、モダンなシステムは多数のライブラリやフレームワーク、ミドルウェアなどで構成されているため、スタックのどこかにそれ らの脆弱性が存在すれば悪用される可能性があります。 古いサービス、新しい手法： UNC2903によるクラウドメタデータサービスの悪用 | Mandiant
33. オンプレ・人からの漏洩 PART4. パブリッククラウドへの攻撃・侵害事例 33 次はオンプレ環境や人からの漏洩について取り上げます。オンプレ環境ではクラウド環境と連携するサーバーや、クラウドを使ったシステムの開発・運 用者がいます。クラウド連携を行うサーバーであればAPIキーなどを使用し、開発・運用者であればWebコンパネやCLIツールでクラウド操作を行いま す。 いずれにしろ、クレデンシャルは各端末のファイル上に保存されるため、攻撃者はそのファイルを盗むことで被害者のクラウド環境へアクセスが可能とな ります。他にもフィッシングやソーシャルエンジニアリングによってID/PWなどのクレデンシャルを盗むことも可能です。 ここからは、オンプレ環境を契機としたクレデンシャル漏洩のリスクについて解説します。
34. オンプレ・人からの漏洩　ー フィッシング ー PART4. パブリッククラウドへの攻撃・侵害事例 34 Cloud Credentials Phishing | Malicious Google Ads Target AWS Logins - SentinelOne Microsoft Warns of Latest “Consent Phishing” Attack Intent on Reading Your Email まず始めにフィッシングについてお話しします。パブリッククラウドのアカウントを標的としたフィッシングは増加傾向にあり、特にAzure・GCP はクラウド 環境へのログインにMicrosoftアカウントやGoogleアカウントを使用するため、フィッシング被害にあった場合はM365やGoogle Workspaceも侵害され る可能性があります。 上の左図はM365を狙ったConsent Phishingの記事です。攻撃者は利用規約改定の偽メールを送信し、受け取った被害者はメール内のリンクより Azureアプリ連携の画面に誘導されます。同意を押した場合、悪意あるアプリ権限が付与され、メールボックスの閲覧が許可されることになります。 右図は 2023/2 の上旬に観測された、Google Ads を悪用したAWSコンソールのフィッシングです。直近で、Google Ads を介した InfoStealer の配布な ども活発に行われているため、注意が必要です。
35. オンプレ・人からの漏洩　ー マルウェア感染 ー PART4. パブリッククラウドへの攻撃・侵害事例 35 Hackers push malware via Google search ads for VLC, 7-Zip, CCleaner VSCode Marketplace can be abused to host malicious extensions 次はマルウェア感染によるクレデンシャル漏洩です。マルウェア感染の経路はフィッシング、偽ソフトのインストールなど多岐にわたりますが、InfoStealer の場合はCookieやWebブラウザ／パスワードマネージャに保存しているログイン情報が漏洩します。その他のマルウェアでも Lateral Movement により 他の端末より漏洩したケースもあります。 特に、直近ではGoogle検索結果の上位に表示される Google Ads を介した InforStealer や RAT の配布や、開発者に人気があるVSCode Extension を装った悪意ある拡張の配布など、至る所に感染の可能性が存在します。 攻撃者は盗んだCookieを自身のブラウザにリストしたり、パスワードを使用してMFA疲労攻撃を仕掛けることも可能です。 直近のLastPassのパスワード漏洩も従業員のMFA認証済みCookieの窃取によりAWS環境へアクセスされたことが原因です。
36. オンプレ・人からの漏洩　ー 偽ライブラリ ・ツールー PART4. パブリッククラウドへの攻撃・侵害事例 36 PyPi python packages caught sending stolen AWS keys to unsecured sites Docker Hub repositories hide over 1,650 malicious containers 開発者やセキュリティリサーチャーは新しいライブラリやツールが大好きです。日々、新しい技術のキャッチアップと実験を繰り返すことでスキル アップや既存製品の改善を行います。 しかしながら、typosquatting や攻撃者の興味を引くようなキーワードを含む悪意あるライブラリ・ツールの公開が大量に発見されており、直近で はBotによる 288個のAzureに関する偽ライブラリの公開が発見されています。 前のスライドとネタが被りますが、.NETアセンブリのデコンパイルツールである dnSpy の偽サイトを作成し、SEOで上位に表示することでマル ウェアのダウンロードに誘導するケースも観測されています。 このため、無警戒にライブラリやツールの導入を行うとセキュリティインシデントに繋がる可能性があります。
37. オンプレ・人からの漏洩　ー不用意な公開ー PART4. パブリッククラウドへの攻撃・侵害事例 37 DXC spills AWS private keys on public GitHub • The Register Over 1,000 iOS apps found exposing hardcoded AWS credentials 不用意な公開による悪用も多数発生しています。Symantec’s Threat Hunting Teamによると、公開されているiOS/Androidを調査したところ、 1859個のアプリでAWSのAPIキーがハードコードされていたとのことです。 国内でも、誤ってGithubなどのプラットフォームに公開したAPIキーを悪用されて仮想通貨のマイニングを目的とした高額なインスタンスを作成さ れるなどの被害が発生しています。 他にも、開発者が個人のGithubアカウントで作成したパブリックリポジトリ上で企業のAWS APIキーを公開したことによる悪用も発生しているた め開発者の教育も不可欠となります。
38. SaaSプラットフォーム・連携サービスからの漏洩 PART4. パブリッククラウドへの攻撃・侵害事例 38 ここ10年程度で CI/CD や DevSecOps の普及が進み、クラウド環境においてもサービスやツールと連携した開発が当たり前になっ てきました。 しかしながら、それらのサービスもまた「人」が開発していますし、構成するOSSやサービスインフラが侵害された場合、サービスと連 携するために渡したクレデンシャルが漏洩することになります。 その他にも、ITベンダーにクラウドの運用を委託している場合、ベンダー側のセキュリティインシデントがクラウド環境の侵害に繋がる 可能性があり、過去にCSPやMSPを標的とした攻撃についてUS-CERTより注意喚起が出ています。
39. SaaSプラットフォーム・連携サービスからの漏洩　ー CI/CDサービスのセキュリティ事故 ー PART4. パブリッククラウドへの攻撃・侵害事例 39 Thousands of GitHub, AWS, Docker tokens exposed in Travis CI logs CircleCI security alert: Rotate any secrets stored in CircleCI (Updated Jan 13) SaaS型のCI/CDサービスやCSPMと連携する場合は、サービス側にクラウドのクレデンシャルを渡す必要があります。しかしながら、 サービス側のセキュリティインシデントによるクレデンシャルの漏洩や悪用が発生しています。 左図のCircleCIのケースでは従業員の端末がマルウェア感染し2要素認証済みのCookieが漏洩したことから、攻撃者により本番環 境へアクセスされた結果、顧客のAWSキーなどの漏洩が発生しています。 右図のTravis CIのケースでは、セキュリティ研究者の調査によりTravis CIのAPIの不備により任意のログデータ閲覧できることが判 明し、サンプルで800万のログデータを調査したところ、AWSのAPIキーを含む約73,000件のクレデンシャルが発見されています。
40. 相乗りによる共倒れのリスク PART4. パブリッククラウドへの攻撃・侵害事例 40 最後に相乗りによる共倒れのリスクを説明します。前述したようにシステム管理者の場合、仮想マシンやデータベースへの権限など比較的、高い 権限を持つことが多いと思います。 上図のケースを考えると、SystemAとBが相乗りしているクラウド環境において、SystemAの管理者に全ての仮想マシンやデータベースを操作可 能な権限がついている場合、SystemAの管理者のクレデンシャルが漏洩する事でSystemBも侵害される可能性があります。 これは、過剰な権限が付与されたリソースからのクレデンシャル漏洩に関しても同じことが言えますし、開発環境と本番環境が同居しているケース にも当てはまります。 これまで説明してきたように、クレデンシャルの漏洩経路は無数にあるため、相乗りにより無関係なシステムのセキュリティインシデントが波及する 可能性があります。 各クラウドにはシステムを分離する管理単位（AWSアカウント、Azureリソースグループ、GCPプロジェクトなど）が用意されており、それらの機能を 活用することで他のシステムへの影響を抑えることが出来ます。
41. パブリッククラウドへの攻撃手法の高度化 PART4. パブリッククラウドへの攻撃・侵害事例 41 これまで紹介したようにAzure開発者を狙った大量の偽ライブラリの作成や、既知の脆弱性の悪用によるIMDSからのトークン窃取など、攻撃者も徐々に パブリッククラウドへ目を向けつつあります。 上の左図は攻撃者がAWSの「sts:GetFederationToken」というAPIを悪用しているという記事です。当該APIを使用することで、漏洩したAPIキーを無効 化してもフェデレーションのサインインセッションは切れないため、攻撃者は活動を継続できるとのことです。 また、右図の記事では攻撃者がクラウド環境への足掛かりを得た後、M365の監査機能を無効化していたとの報告があります。 以前のようなとりあえずマイニングインスタンスを立てるような攻撃に比べ、攻撃者側もパブリッククラウドの仕様を熟知した上で侵害を行っているため、 今後は標準的なセキュリティ機能の有効化だけでなくクラウド特有のThreat Huntingなどの追加の対策が必要になることが予想されます。 APT29、Microsoft 365を標的とした攻撃を継続 | Mandiant AWS CloudTrail vulnerability: Undocumented API allows CloudTrail bypass | Datadog Security Labs How Adversaries Can Persist with AWS User Federation
42. 攻撃者もクラウドに慣れ始めている 42 SCARLETEEL: Operation leveraging Terraform, Kubernetes, and AWS for data theft – Sysdig 実例として、直近で観測されたパブリッククラウドならではの Lateral Movement の事例をご 紹介します。 1. AWS上に構築されたKubernetesクラスターにデプロイされたWebシステムを侵害 2. Podにアクセスしマルウェア実行 a. IMDSにアクセスしAWSリソースを列挙 b. AWS Lambdaの環境変数にハードコードされたクレデンシャルを検索 3. 2で取得したクレデンシャルを使用して検知の無効化と探索を実行 a. CloudTrailの無効化 b. ユーザーの列挙 c. S3上に存在したTerraformの状態ファイルから別のアカウントのクレデンシャルを取 得 4. 3で取得したクレデンシャルを使用してさらなる環境の探索と横移動の試み この様に、AWSの仕様と機能を考慮した上での侵害事例が発生しているため、 後述するクラウドの操作ログやセキュリティ機能の無効化を検知・防止する必要があります。
43. まとめ PART4. パブリッククラウドへの攻撃・侵害事例 43
44. 手軽で多機能なクラウドサービスだか らこそおこる設定不備や設計/実装上 のセキュリティ的課題は多々存在しま す。 この章ではそれらの課題と対策につ いて触れていきます。 Part 5 クラウドにおける 実装や 設定ミスによる脅威 44
45. 設定ミス・実装の考慮漏れとは？ クラウドと設定や利用によるミスと脅威 45 本稿における設定ミス・実装の考慮漏れとは？ クラウドサービスを利用する際に、設定されている値が構築しているサービスの仕様と、なんらかの理由で相反したり、考慮事 項から抜け漏れている状態 なぜ、このような事象が発生するのか？ 1. セキュリティにおける要件を定めていない 2. 利用するクラウドサービスについてのサービス仕様や機能に関する 理解不足による要件漏れ 3. 複数のクラウドサービスを組み合わせた際や構築しているサービスにおける 全体の要件の考慮漏れ
46. クラウドと設定や利用によるミスと脅威 - 1.セキュリティにおける要件を定めていない 46 1. セキュリティにおける要件を定めていない • 要件定義時や設計の段階でセキュリティにおける考慮事項を定めていない • 設計を行うメンバーにおけるセキュリティにおける要件に関する知識の不足 設定の例: • [環境の分離] ◦ アカウント内で複数の環境が同居してしまう ▪ 開発環境や本番環境、本来は分離することが望ましい環境などがアカウント内に同居する • [アクセスの制御] ◦ オブジェクトストレージへのアクセスをパブリックにしてしまう ▪ サービスのアクセス要件を整理しておらず、意図しない経路でアクセスできてしまう 図. 同じアカウント内に開発環境と本番環境が同居する状態 図. 意図しない経路でのアクセス
47. クラウドと設定や利用によるミスと脅威 - 1.セキュリティにおける要件を定めていない 47 1. セキュリティにおける要件を定めていない 脅威: • [環境の分離] ◦ 開発環境や本番環境、本来は分離することが望ましい環境などがアカウント内に同居 ▪ 開発環境のサービスやアカウントが侵害されることによる環境内の横移動(lateral movement)によって本番環境の侵 害が発生しやすくなる • [アクセスの制御] ◦ サービスのアクセス要件を整理しておらず、意図しない経路でアクセスできてしまう ▪ 意図せずセンシティブな情報(顧客情報等)が公開される 図. 同じアカウント内に開発環境と本番環境が同居する状態 図. 意図しない経路でのアクセス
48. 図: バケットから意図しないファイルの取得 クラウドと設定や利用によるミスと脅威 - 1.セキュリティにおける要件を定めていない 48 オブジェクトストレージにおけるアクセス制御の不備によるデータの不正取得 設定ミス / 実装ミスの例 • バケットポリシーの設定ミス • 署名付きURLの設定時の実装ミスによるIDOR(安全ではないデータ参照) 脅威の例 • 機密情報や個人情報等の情報漏洩 参考 https://blog.flatt.tech/entry/s3_security
49. 1. セキュリティにおける要件を定めていない 具体:日本国内のオンライ医療系サービスにおける症例画像の公開(S3) クラウドと設定や利用によるミスと脅威 - 1.セキュリティにおける要件を定めていない 49 出典: https://www.databreaches.net/japanese-medical-online-consultation-site-leaking-consumer-submitted-images-of-symptoms/ https://www3.nhk.or.jp/news/html/20220329/k10013558361000.html
50. クラウドと設定や利用によるミスと脅威 - 1.セキュリティにおける要件を定めていない 50 図. 意図しないアクセスが発生しないように、 接続経路を明確化しそれ以外の通信を拒否する 図. 本番環境と開発環境を切り離 1. セキュリティにおける要件を定めていない 環境の分離に関する対策の要点 1. 開発の段階や情報取り扱いなどのコンテキストに合わせアカウント等の管理単位を定義する 2. 定義をもとに分離された環境下で開発や運用を行う 3. コンテキストを跨いだ通信は最小限にする アクセスに関連する対策の要点 1. アクセス可能な範囲や実施可能な行動を定義する 2. それ以外の操作を拒否する前提で実装や設定を行う 3. 権限やアクセス可能なリソース、そして持続時間は最小限に設定 ※認証情報やアクセス情報の持続時間を最小化した場合でも、アプリケーションの脆弱性等を用いて持続的に認証情報等を取得される可能性は残りますので、多層防御的 対策は必要になります。
51. クラウドと設定や利用によるミスと脅威 - 2.クラウドサービスの仕様や機能に関する理解不足による要件漏れ 51 図. 本来許可されていないユーザーからのアカウント作成 User IDaaS アカウントの作成 アカウントの発行 2. クラウドサービスの仕様や機能に関する理解不足による要件漏れ • クラウドサービスが有している機能について深く調べておらず、要件定義時に漏れてしまう • 新規の機能追加時に機能が有効の状態で追加されてしまう 設定の例: • IDaaSを用いたユーザー管理/認証を行っている際の新規登録の設定 • デフォルト Allowのサービスにおいて、Denyのルールを書かないことによるアクセス制御の不備 • ルール記述への知見不足 実装の例: • 本来は特定のユーザーのみがアカウント追加が可能なサービスで、IDaaSの設定がデフォルトになっており、新規登録ができ る状態にある ◦ 侵害: 意図しないアカウントが作成できてしまう
52. クラウドと設定や利用によるミスと脅威 - 2.クラウドサービスの仕様や機能に関する理解不足による要件漏れ 52 本来はSignup(新規登録)を拒否すべきアプリケーションの 認証フローで設計していた しかし、設定値について考慮しておらず、 意図せずSignup(新規登録)が許可されている 2. クラウドサービスの仕様や機能に関する理解不足による要件漏れ 意図しないアカウントの新規登録 Signinは許可 Signupは拒否 SignupはAdminのみ 属性変更はアプリから Signinは許可 Signupが意図せず許可 SignupはAdminのみ 属性変更はアプリから
53. 2. クラウドサービスの仕様や機能に関する理解不足による要件漏れ 具体:Amazon Cognitoの設定ミスによる自己サインアップや クラウドと設定や利用によるミスと脅威 - 2.クラウドサービスの仕様や機能に関する理解不足による要件漏れ 53 出典 https://notsosecure.com/hacking-aws-cognito-misconfigurations
54. 2. クラウドサービスの仕様や機能に関する理解不足による要件漏れ 実装の例: • FirebaseのDBであるFirestoreやストレージであるCloud Storage for Firebaseはセキュリティルールと呼ばれるDSLの実装 不備により、適切なアクセス制御を行わずにそのまま公開してしまうと、誰しもがデータやストレージの表示、編集、削除が可 能になってしまう。 クラウドと設定や利用によるミスと脅威 - 2.クラウドサービスの仕様や機能に関する理解不足による要件漏れ 54 図. Firebase Cloud Storageにセキュリティルールを テストモードのまま後悔してしまう
55. 2. クラウドサービスの仕様や機能に関する理解不足による要件漏れ 具体:「推定2万4千のAndroidアプリにおいてFirebaseの設定ミスにより 個人情報が公開されている可能性」という調査結果 クラウドと設定や利用によるミスと脅威 - 2.クラウドサービスの仕様や機能に関する理解不足による要件漏れ 55 参考資料 https://decoded.avast.io/vladimirmartyanov/research-shows-over-10-of-sampled-firebase-instances-open/ 出典 https://www.comparitech.com/blog/information-security/firebase-misconfiguration-report/
56. 2. クラウドサービスの仕様や機能に関する理解不足による要件漏れ オブジェクトストレージへの悪意のあるファイルのアップロード 設定ミス / 実装ミスの例 • アップロード時にContent-Typeを検証していない署名付きURLのPOST policyを設定していない等 脅威の例 • マルウェア等で利用されるファイルの配信 • Content Security Policy等の制限を回避可能なJavaScriptファイルの配置 注意事項 • 全ての悪意のあるファイルを防ぐことは難しいので、ログ等をとることで、マルウェア等の配置について検証できるようにしてく ださい 図: マルウェアやXSSを含んだHTMLファイル等の悪意のあるファイルのアップロード クラウドと設定や利用によるミスと脅威 - 2.クラウドサービスの仕様や機能に関する理解不足による要件漏れ 56 参考 https://blog.flatt.tech/entry/s3_security
57. 図: ファイルのアップロードによるデータの改ざん 57 2. クラウドサービスの仕様や機能に関する理解不足による要件漏れ データの改ざん 設定ミス / 実装ミスの例 • ACL等のアクセス制御の不備による改ざん • 署名付きURLを生成する際のPathの不適切な指定 脅威の例 • HTMLやJavaScriptの書き換えによる悪意のあるコンテンツの配信 ◦ 攻撃例: スキミングやキーロガーなどの設置 • 請求書等の重要書類の意図しない改ざん 参考 https://blog.flatt.tech/entry/s3_security クラウドと設定や利用によるミスと脅威 - 2.クラウドサービスの仕様や機能に関する理解不足による要件漏れ
58. クラウドと設定や利用によるミスと脅威 - 2.クラウドサービスの仕様や機能に関する理解不足による要件漏れ 58 データの改ざん 出典 Uniqlo and The Guardian among thousands of sites loading malicious code from S3
59. クラウドと設定や利用によるミスと脅威 - 2.クラウドサービスの仕様や機能に関する理解不足による要件漏れ 59 データの改ざん 出典 https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/
60. 2. クラウドサービスの仕様や機能に関する理解不足による要件漏れ 対策: • クラウドサービスがどのような機能を有しているか確認をする • クラウドサービスの機能において、どのような仕様なのかなど、ドキュメントや動作を確認する • クラウドサービスのデフォルトの設定値を理解し、必要に応じて設定を変更する。 • 設定に対して、設計段階で精査を行い、テストケースに組み込む • 不明点がある場合、一人で抱えずに社内の知識を有するメンバーや各クラウドプロバイダー所属のソ リューションアーキテクト、各専門ベンダーのメンバーに相談 クラウドと設定や利用によるミスと脅威 - 2.クラウドサービスの仕様や機能に関する理解不足による要件漏れ 60
61. クラウドと設定や利用によるミスと脅威 - 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 61 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ • サービスからサービスに渡る値のコンテキストを理解せずに利用し、取得したサービス上で副作用が発生する 実装の例: • キューサービスから取得した値を安全なものとし、SQL文にその値を差し込んでしまう • イベントから渡された値を安全なものとして、コマンドに引き渡してしまう • オブジェクトストレージに保管されるファイル名を安全なものとし、保管時にその名前を利用しファイルを保存した /upload/image/test.png” UNION SELECT …. 図. ストレージに保存されたFilePathを そのまま利用してしまうことによる脆弱性の発生
62. 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 具体:AWS Lambdaのクレデンシャル侵害からフィッシング攻撃 クラウドと設定や利用によるミスと脅威 - 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 62 出典: 実事例で学ぶクラウドコンピュートのクレデンシャル侵害 https://unit42.paloaltonetworks.jp/compromised-cloud-compute-credentials/
63. クラウドと設定や利用によるミスと脅威 - 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 63 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 具体:AWS Lambdaのクレデンシャル侵害からフィッシング攻撃 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 具体:AWS Lambdaのクレデンシャル侵害からフィッシング攻撃 AWS Lambdaの認証情報取得に関する1考察
64. クラウドと設定や利用によるミスと脅威 - 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 64 攻撃者が悪意のある属性値を自らの値に設定する 1 IDaaSの実装ミスの図解: IDaaSの値をそのまま利用したことによる副作用 悪意のある値
65. クラウドと設定や利用によるミスと脅威 - 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 65 アプリケーションがユーザーの情報をIDaaS上で 管理をしており、その情報をIDaaSから取得する 2 IDaaSから取得した値をそのまま利用することにより アプリケーション上や、ユーザーの画面で副作用 (脆弱性の発生やサービスの停止等)が発生する 3 IDaaSの実装ミスの図解: IDaaSの値をそのまま利用したことによる副作用
66. クラウドと設定や利用によるミスと脅威 - 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 66 IDaaSの実装ミスの図解: IDaaSの値をそのまま利用したことによる副作用 出典: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/
67. クラウドと設定や利用によるミスと脅威 - 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 67 IDaaSの実装ミスの図解: IDaaSの値をそのまま利用したことによる副作用 出典: https://medium.com/@_deshine_/account-take-over-due-to-aws-cognito-misconfiguration-7b092c667ee3
68. 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 対策 通常のアプリケーション同様に、別のアプリケーションから入力される値は安全なものとして扱わない で、サニタイズを行うなど利用する機能において無害な状態にし、利用してください。 • クラウドサービスから取得される値について ◦ ユーザーから操作可能な値を信用しない ◦ 他のサービスからやってくるものは、安全性を担保可能な状態で利用する • クラウドサービスから返される値について ◦ callbackなどでやってくる値などを扱う場合、その値が安全なものなのか その他 • クラウドを守るためには、クラウドの設定だけではなく、その上で動作するアプリケーションが安全である必要があります • 設定値をある程度CIS benchmark等で確認していても、アプリケーションに脆弱性が存在する場合、意図しない経路で攻撃者 に認証情報が渡ってしまう可能性もあるので意識してください クラウドと設定や利用によるミスと脅威 - 3. 複数のクラウドサービスを組み合わせにおける全体の要件の考慮漏れ 68
69. Part 6 クラウドにおける課 金と脅威 69
70. クラウドにおける課金の特性と脅威 - 特性 70 クラウドサービスにおいて、一つの特徴として挙げられるのが”従量課金”と呼ばれる課金体系です。これら課金体系は、従来の サーバー等の調達に比べると、利用した分の料金を支払うだけなので、需要に対して必要最小限の出費になるケースが多くありま す。 クラウド従量課金の特性と恩恵 1. サービスを利用した分だけ課金 a. 課金の指標として”使用量課金”, ”ユーザー課金”, ”アクティブユーザー課金”とがある b. 利用しない場合は基本的にコストがかからない 2. 初期投資や物理サーバー維持におけるコストを抑えることができる(例外もある) a. コストを抑えられることにより、容易にサービスの提供や個人での利用が可能になる 3. 減価償却等の帳簿上の管理が容易になる 例外 一部サービスや特定条件下では、コストが物理での設備の方が抑えられるケースがあります。 例えば、ネットワークトラフィックが膨大な場合、クラウドサービスだとトラフィックに対しての従量課金が発生するため、金額が跳ね 上がってしまうケースがあります。 参考: logmi.jp - DMMはAWS“から”オンプレミス“に”切り替えるサーバーとネットワークのコストから見直す適切な環境選び - https://logmi.jp/tech/articles/325309
71. クラウドにおける課金の特性と脅威 - 脅威 71 このように、クラウドにおいては従量課金による恩恵を受ける一方で、誤った設定や考慮ミスをすること で、サービスの提供者(事業者)が意図しない課金が発生することがあります。そして、この意図しない課 金を攻撃者が意図的に引き起こす攻撃を”EDoS”といいます。 図. EDoS攻撃の例 出典: https://blog.flatt.tech/entry/edos_aws
72. 左図では、月に150TBとありますが、月30日と仮定した場合、1日あたりダウンロードする容量は 約5TBになります。 仮に、S3からJSファイルや画像等で合計5MBの複数ファイルをDLした場合、1時間あたり4万4千 回の送信になります。攻撃者が、750台以上のマシンを用意した場合、回数的には実施可能なレ ベルにはなります。しかし、仮のケースでは通信回数が多いので検知することは可能になります。 ただし、PDFや動画ファイル等のサイズの大きなファイルが存在する場合、より通信回数を減らし アップロードをすることが可能になるでしょう。 クラウドにおける課金の特性と脅威 - 脅威 72 現実的な可能性 現実的な可能性 左図では、月に500TBとありますが、月30日と仮定した場合、1日あたりアップロードする容量は 約16TBになります。 仮にアプリケーションへのアップロードサイズの上限が2GBだった場合、一時間あたり約350回の 送信になります。たとえば攻撃者が6台以上から継続的にアップロードをした場合、500TBの容量 を満たすリクエスト回数を現実的に実施することが可能になります。 左図では、月に500TBとありますが、月30日と仮定した場合、1日あたりアップロードする容量は 約16TBになります。 仮にアプリケーションへのアップロードサイズの上限が2GBだった場合、一時間あたり約350回の 送信になります。たとえば攻撃者が6台以上から継続的にアップロードをした場合、500TBの容量 を満たすリクエスト回数を現実的に実施することが可能になります。
73. 脅威におけるまとめ • 従量課金という特性において、恩恵を受ける部分もあるが、構成次第では意図しない課金が発生す ることがある。 • 今後、サービスを停止させようとする攻撃者はこれら課金の特性を用いて、意図的に過金額を増加さ せる可能性が存在する。 ◦ このような攻撃をEDoS攻撃と呼ぶ • このような攻撃には継続的や反復的、特定のリソースへのアクセスなどの特性が発生しやすいので、 クラウドサービスのログを有効化して、検知することが可能。 クラウドにおける課金の特性と脅威 - 脅威 73
74. PART 7 パブリッククラウドの 防衛戦略 ここからは、これまで解説してきたパブリッククラウド 特有の脅威に対する防御方法を紹介します。 クラウド純正の機能や追加の堅牢化により、被害を 未然に防ぐ方法や、被害を軽減する方法をご紹介し ます。
75. PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 75 ここまでの話で、クラウド特有のセキュリティインシデントの原因として、クレデンシャルの漏洩、盗用や設定ミス、従量制 の料金などを説明しました。 では、どのようにしてこれらのリスクや脅威からクラウドを守り、安全に運用していくのでしょうか？ クラウドの保護には「攻撃者の戦略の分析」と「クラウドの仕組みの活用と応用」が肝です。 クラウドを安全に使うために
76. PART. 7 パブリッククラウドの防衛戦略 脅威の大別と大まかな防衛戦略 76 設定誤りへの対策 設定監査サービスを利用し、情報漏洩や権限昇格に 繋がる弱い設定の検知と通知を行う。 また、セキュリティ機能やログが有効になっていないな どの環境そのものの堅牢度も監視する。 証跡の記録 パブリッククラウドではAPIの実行履歴や、サービス ごとのログが存在するが、その多くが課金などの理 由からデフォルトで無効となっている。 また、攻撃者に削除される可能性もあるため、別環 境に転送するなどして保全を行う。 組織管理によるベースラインの確保 各パブリッククラウドに用意されているActive Directoryの ような階層管理機能を利用し、セキュリティ機能の強制有 効化やMFAの強制などポリシーを配布し、セキュリティの ベースラインを確保する。 また、上位階層でセキュリティ機能の無効化を禁止するこ とで攻撃者による隠ぺい活動の防止・検知を行う。 クレデンシャル漏洩への対策 クレデンシャルの漏洩経路は多岐にわたるため、漏 洩そのものを防ぐことは困難。 そのため、不審なAPIの呼び出しの検知や、呼び出 し元IPの制限などの条件を設定することで漏洩の検 知と盗用の防止を行う。 これまでの話をまとめると、パブリッククラウド特有の主な脅威は「クレデンシャルの漏洩」と「弱い設定」の２つに大別さ れます。 本章では２つの脅威に対する検知と予防の観点から対策方針を紹介すると共に、組織管理機能を活用したセキュリティ のベースラインの確保や、有事の際の被害調査に必要なログについても解説します。
77. PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 77 クラウドのセキュリティサービス クラウドにはマネージドなセキュリティサービスが用意されています。このセキュリティサービスを活用することにより自動 的な予防と検知の仕組みを構築することが可能です。各クラウドごとに用意されているセキュリティサービスの性能やコ スト等に差はありますが、セキュリティのベースラインの確保には有用なサービスです。
78. セキュリティサービスの有効化が必要 セキュリティサービスは標準で有効化されているサービスと有効化されていないサービスに分かれます。ログの保存など 有効化すべきサービスの有効化します。 他のサービスと同じくサービスの利用量に応じて費用が発生する セキュリティサービス以外のサービスと同じく、サービスの利用量に応じて料金が発生するものが多くを占めます。高額と もいえる料金が発生するサービスもあることから事前に料金の目安を把握します。 セキュリティサービスの設定やサービスに付随する設定の変更権限を適切な構成にする クラウドへの侵害発生時に証跡の保存や証跡自体の削除などセキュリティサービスの停止を回避します。 PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 78 クラウドのセキュリティサービス利用の留意点
79. IAM / ルートユーザーの保護 PART. 7 パブリッククラウドの防衛戦略 Part.3他で説明した通り、IAMはクラウドのアクセス制御の根幹を成すものであり保護を行います。 主な対応 • MFAの設定 • 最小権限の設定 • アクセスキーのローテーション • 棚卸し • (接続元IPアドレス等の)条件設定 • ルートユーザーや組織の管理権限を持つIAMの日常利用の停止と監視 • PIMによる通常時の権限の抑制と、高権限を要する作業の承認制 パブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 79
80. PART. 7 パブリッククラウドの防衛戦略 最小権限の限界 80 パブリッククラウドのセキュリティについて解説した記事を読むと、頻繁に「IAMによる最小権限による対策を」という結論を見かけます。 しかしながら、IAMによる最小権限はあくまでもクラウドのAPI単位や設定可能な条件までであり、その条件を超える制御は提供しません。 例えば、左図のようなログイン機能の実現するために必要な最小の権限は「ログイン情報が格納されたテーブルのみ操作可能」ですが、関数にデプロイした コードやライブラリに脆弱性があればログイン情報にアクセス可能なクレデンシャルが漏洩することになります。 もう一つ、右図の様にWebサイトの運用の為にシステム管理者に「Webサイトに関連するVMとDBのみ操作可能」な権限を付与したとしても、 管理者のクレデンシャルが漏洩すればWebサイトのVMとDB全台が攻撃者により操作可能となります。 このように、IAMによる最小権限の設定はIAM悪用時の被害範囲を狭めることには有効ですが最小権限の設定のみでは全てが解決するものではりません、 クレデンシャル漏洩に備えて本章で説明するようなクラウドの操作元IP制限などの追加対策を講じる必要があります。
81. ログの保全 PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 81 クラウドにはアクティビティログやデータアクセスログなど複数の証跡が存在します。そのうちアクティビティログはいつ、 誰が、どのリソースに対して、どのような操作をしたかを記録します。セキュリティインシデントの検知や影響範囲の特定、 原因の調査など証跡は重要な役割を果たします。 ログの保存期間 ログの保存期間のデフォルト値は各クラウドでログの種別ごとに定められています。標準で有効となっているアクティビ ティログも保存期間が定められているため、短期間でログが削除されないように設定します。 ログの削除や改ざんへの対応 攻撃者がクラウド環境を侵害した場合にログの削除や改ざんを試みることがあります。ログの削除や改ざんにより攻撃 の発覚や対処が遅れることから、ログを保存しているストレージを保護したり、別のログ専用環境にログを送出しログに 対する攻撃に備えます。
82. ログサービスの利用例 PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 82 AWS CloudTrail(アクティビティログ)
83. ログサービスの利用例 PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 83 Azure サインインイベント(Azure ADへのサインインログ)
84. 脅威検知 PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 84 クラウドへの各種操作の証跡から悪意ある操作や盗用したクレデンシャルでの操作などのクラウドに対する脅威を自動 的に検知します。 脅威検知の内容は各クラウドごとに異なりますが、コンピューティングリソースへのSSHのブルートフォースなどの攻撃や TorのIPアドレスからのクラウドの操作など特定のパターンにマッチした時に検出される項目と、通常と異なる場所からの クラウドの操作などの通常と異なる挙動を検知するアノマリ検知を組み合わせて行われます。
85. PART. 7 パブリッククラウドの防衛戦略 Amazon GuardDutyによる検出例 85 上記はAWS GuardDutyによる脅威検知の例です。上記の例ではEC2上にデプロイされた脆弱性を悪用し、IMDSから窃取したトークンをローカルにリ ストアしAPI呼び出しを行ったため検知されています。 原理としては、EC2に割り当てられたロールはEC2のIPレンジから操作されるため、レンジ外からの使用があればトークンの漏洩として検知するように なっています。 その他にも通常ではありえないTorからのクラウド操作や既知の悪性IPからの操作などの検知を行います。同様の検知を行うサービスが各クラウドより 提供されています。 検出結果タイプ - Amazon GuardDuty 脅威検知サービスの利用例 AWS GuardDuty
86. 利用料金の監視 PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 クラウドの利用料金は、およそクラウドの各サービスの利用量に応じた従量課金の形態をとります。攻撃者にEDoSやク レデンシャルを盗用され、マイニングなどで高性能かつ高単価なコンピューティングリソースのインスタンスを立ち上げら れると短時間の間に高額な利用料金が発生します。また、攻撃以外にもサーバーレスサービスの無限ループなどサービ スの構成ミスで発生する巨額な請求。いわゆるクラウド破産と呼ばれるような想定していないクラウドの利用料金発生も ありえます。 想定外の利用料金の発生を検知するために、利用料の請求やクラウドの利用料金があらかじめ設定した予算を超えた 時に通知させる仕組みを設定します。 86
87. PART. 7 パブリッククラウドの防衛戦略 クレデンシャル漏洩に備えたクラウド環境の要塞化 87 これまでクレデンシャルの漏洩経路は無数にあり、漏洩による影響も 大きいと説明をしてきました。 とはいえ、前半で説明したクラウドの認証の仕組みや、攻撃者が窃取 したクレデンシャルを自身の環境にリストアして使用することを考える と下記のようなクラウドの要塞化と検知を行うことで、クレデンシャル 盗用の抑制と漏洩の検知が可能となります。 • IAMによる操作元IPの制限 • サービスの稼働に不要なリージョン、サービスの無効化 • PIMによる作業の承認制 • 上記に違反するAPI呼び出し、作業承認の検知 ただし、必須で必要となるリージョンが存在したり、サービス制限によ りWebコンソールの一部のページが表示できなくなるケースがあるた め必ずテストが必要です。
88. 利用するリージョンの制限 PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 88 クラウドには数多くのリージョンが存在します。クレデンシャルが盗用されたときに攻撃者は自身に地理的に近いリージョ ンでAPI実行やマイニングインスタンスの起動を行うことが多いため、普段利用しないリージョンの無効化と使用の監視を 行うことで侵害を感知できる可能性があります。ただし、AWSではバージニア北部など一部必須となるリージョンがある ため、必ず確認をテストを行うことを推奨します。
89. 通知設定 PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 クラウドに備わっているセキュリティソリューションは単体では通知機能を備えていないサービスがあります。セキュリティ ソリューションから発されるアラートを見逃さないためにチャットツールやメールなどに通知されるように設定するととも に、通知への対応方法を定めます。 89
90. PART. 7 パブリッククラウドの防衛戦略 オブジェクトストレージが 全世界に公開されている データベースが 全世界に公開されている ルートユーザーに MFAが設定されていない 設定監査サービスによって検知される違反の例 パブリッククラウドの防衛戦略 - セキュリティ機能の利用と設定 90 クラウドの仕様理解不足や不注意による設定ミスや構成の不備は必ず発生します。セキュリティ機能の有効化や各サー ビスにおいてセキュリティの指標となる文書で求められている設定がなされているかを継続的に監査する機能を活用す ることで自動的に設定ミスや構成不備を検知し、是正につなげる状態を作り出します。 継続的な設定の監査
91. 設定監査サービスの利用例 PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - セキュリティ機能の利用と設定 91 GCP Security Command Center 上記はGCPのSecurity Command Centerでの設定監査での検知例です。 GCSのバケットが全世界に公開されており、誰でもバケットにアクセスできることを設定ミスの可能性として検知しています。仮にバケットに個人情報など 機密にすべき情報が含まれるとその情報の漏洩に繋がります。設定監査で検知した内容に対しては修正方法の提示がなされています。設定監査サー ビスはこのような設定ミスの可能性を継続的に検知します。
92. PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - 組織機能による統制 92 複数環境の管理の課題 クラウドの環境を新たに作成することは容易であるため、部署やサービスごとに環境が生まれることもありえます。 時が経つごとに増加する環境を全て把握し、全てのリソースに適切な統制を行うことは困難が伴うため、統制が行き届か なくなることも発生します。
93. PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - 組織機能による統制 93 組織機能による複数環境の統制 複数の環境を統制するために組織機能を用います。組織機能を利用することで全ての環境を組織内に配置し、セキュリ ティサービスの利用や設定の強制をすることで組織的なセキュリティの統制を実現します。今後新たに作成する環境に 対しても環境作成当初から統制を実現します。
94. PART. 7 パブリッククラウドの防衛戦略 セパブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 94 セキュリティの指標となる文書の紹介 https://aws.amazon.com/jp/architecture/well-architected/ AWS AWS Well-Architected Framework https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_detect_inves tigate_events_app_service_logging.html
95. PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - セキュリティサービスの利用と設定 95 セキュリティの指標となる文書の紹介 https://cloud.google.com/architecture/framework?hl=js https://learn.microsoft.com/ja-jp/azure/architecture/framework/ GCP Google Cloudアーキテクチャフレームワーク Azure Microsoft Azure Well-Architected Framework
96. PART. 7 パブリッククラウドの防衛戦略 パブリッククラウドの防衛戦略 - パブリッククラウド特有のリスクと対策のマッピング 96 リスクカテゴリ 原因 予防 検知 被害の軽減 クレデンシャル漏洩 脆弱性の悪用によるトークン漏洩 脆弱性検査 FW・IDS・IPS導入 VMS導入 不審なアクティビティの検知 ログイン元IP、OS、デバイスの制限 クラウドAPIの操作元IP制限と検知 利用可能なリージョン制限と検知 利用可能なサービス制限と検知 最小権限を心がける PIM（特権管理・承認制の導入） Phishingやリスト型攻撃による認証の突破 パスワード要件の設定 MFAの強制 条件付きアクセス 不審なログインの検知（ログイン元地域の極端な 移動、不審なUA、Tor経由のログインなど） サプライチェーンの汚染 VMS導入 バージョンの固定 ハッシュチェック 不審なアクティビティの検知 アンチウイルス・EDRによる検知 サンドボックス＋ハニートークンでの挙動観察 端末・連携システムからの漏洩 端末のセキュリティ確保 連携システムのセキュリティ審査 不審なアクティビティの検知 アンチウイルス・EDRによる検知 連携システムのセキュリティ機能と通知の有効化 不用意な公開・共有による漏洩 （Github、アプリへのハードコード、 APIキーの 共有、社内Wikiへの記載など） 社員教育の徹底 開発サイクル内でのハードコードチェック DLPの導入 ソースコードのスキャン 相乗りによる共倒れ 別システムの侵害からの波及 システムとステージ（開発、本番、テスト） による分離 ー 最小権限を心がける 弱い設定による情報漏洩 仕様への理解不足による設定ミス デフォルトの弱い設定 設定監査の実施と通知 定期的、または、リアルタイムな設定監査の実行 DLPの導入 保存データの暗号化 侵害の不検知 セキュリティ機能の有効化忘れ 攻撃者によるセキュリティ機能の無効化 組織管理機能による強制有効化および、 無効化の拒否設定 設定監査ツール、アクティビティ監視による無効化の試み の検知と通知 ー パブリッククラウドの脆弱性・ 仕様の悪用 従量課金の悪用によるEDoS 仕様の把握不足による自爆 パブリッククラウドの脆弱性 不要なサービスの停止 クラウドベンダーからのセキュリティ通知設定 課金アラーム設定 Threat Hunting 証跡の不足による被害調査の難航 アクティビティログの有効化忘れ 各サービスのログの有効化忘れ 攻撃者によるログの削除 ログの有効期限の未考慮 組織管理機能による強制有効化 ログの退避と保全 ログ保持期間の変更 アクティビティ監視によるログ無効化の検知と通知 設定監査による設定状況の監視と通知 ー ※一部、予防と検知が重複する部分もあります。
97. 小ネタ ーよくある質問集ー 97 Q1.　サーバーレスだからWAFは不要？ A1.　サーバーレスであってもユーザーの入力をもとにデータベースの検索や処理を行っている上、SQLインジェクションやコードインジェクションの脆弱性が 　　 存在します。また、ライブラリに脆弱性があれば同様に攻撃が可能となるためサーバーレスであってもWAFは必要です。 Q2.　パブリッククラウド標準のWAFってどうなの？ A2.　下図は直近で実施した各パブリッククラウドで標準のWAFの検知精度の調査結果です。 　　 筆者の周囲でも標準のWAFを利用しているとの声が増えていますが、実際に検証してみると過検知や攻撃検知率が低いものが存在するのが実情です。 　　 また、仕様により8KB以降のチェックを行わない、または、問答無用でブロックするWAFも存在することも判明しました。 　　 他にも簡単に誰でも試せる、ベースがOSSなWAFルールなどの特性により、日々バイパス手法が公開されています。 　　 とはいえ、Bot検知や地理情報に基づくアクセス元制限など有益な防御機能も存在するため、これらの特性を理解したうえで機密情報の取扱有無などを 　　 基準に使い分ける必要があると考えています。 Q3.　トークンの有効期間が短ければ漏洩しても大丈夫？ A3.　攻撃者は攻撃の初期段階で足場の確保のために、APIキーやバックドアアカウントを作成します。また、脆弱性の悪用によるトークン窃取の場合、 　　 脆弱性が解消されない限り再度トークンを窃取可能です。 ルール設定 A社 B社 C社 D社 誤検知率 0.23% 0.05% 49.64% 2.57% 誤検知チューニング後の 攻撃検知率 29.68% 13.98% 38.20% 46.66%
98. 小ネタ　ーSoftware Supply Chain汚染を検知するための一案ー • サンドボックス環境で一定期間動作させて様子を見る ◦ ハニートークン（悪用されても困らないAPIキーやロール）をデプロイしたVMでツールを実行 ◦ 可能であればSeleniumなどで継続的にハニーアカウントにログインさせる ◦ EDR、AV、クラウド純正の不審なアクティビティ検知、NW/DNSログを有効化する ◦ クラウド利用のアクセス元IPや使用できる機能を制限 ◦ ハニートークンを使ったアクティビティやセキュリティ機能による検知があれば汚染の可能性ありと判断 • 一通りのファイルをそろえた状態で検証する ◦ アップデートや拡張機能などで自動で追加のバイナリを落とす場合は、それ込みで調査 • 以上をクリアできたツールセットのみを配布し使用する。 ◦ ファイルが大量にある場合は一通りそろえたうえで固めてHashを控えて置く SaaSサービスの場合、普段使いのクレデンシャルとは別にハニートークンを登録することで、SaaS側の侵害を検知できる 可能性があります。 98
99. 参考リンク 99 • 侵害・攻撃事例 ◦ 事案 ▪ GitHub - ramimac/aws-customer-security-incidents ▪ MITRE ATT&CK -Cloud Matrix- ◦ オンプレ・人からの侵害 ▪ Uber hacked, internal systems breached and vulnerability reports stolen ◦ 脆弱性を悪用したクレデンシャルの取得 ▪ Threat Actors Target AWS EC2 Workloads to Steal Credentials ▪ 古いサービス、新しい手法：UNC2903によるクラウドメタデータサービスの悪用 | Mandiant ▪ TeamTNT Continues Attack on the Cloud, Targets AWS Credentials ▪ SCARLETEEL: Operation leveraging Terraform, Kubernetes, and AWS for data theft – Sysdig • 偽ソフト・ライブラリ・ツール ◦ VSCode Marketplace can be abused to host malicious extensions ◦ Hackers abuse Google Ads to spread malware in legit software ◦ Over 1,300 fake AnyDesk sites push Vidar info-stealing malware ◦ Trojanized dnSpy app drops malware cocktail on researchers, devs ◦ This Week in Malware: 400+ npm Packages Target Azure, Uber, Airbnb Developers ◦ New 'pymafka' Malicious Package Drops Cobalt Strike on macOS, Windows, Linux • Supply Chain ◦ HashiCorp is the latest victim of Codecov supply-chain attack • 設定ミスによるセキュリティインシデント ◦ https://www.hackread.com/american-online-ed-platform-22tb-data-leak/