クラウドセキュリティ入門 ～安全なクラウド利用のための基礎知識～

第03回shirosec しろおび夏祭り2026
https://shirosec.connpass.com/event/397254/

本セッションではクラウドを支える技術の解説から、実際の攻撃手法までを解説します。前半で攻撃手法の理解に必要な前提知識の提供を行い、後半では、実際に発生したインシデントや濫用されている手法の解説を行います。

#shirosec

Transcript

1. クラウドセキュリティ入門 安全なクラウド利用のための基礎知識
2. 諸注意 1. 2. 3. 本資料を許可なく営利目的で使用することを禁止します。 本資料ではクラウド特有の事項について話します。 一部、理解のために抽象化した説明を行います。そのため、実際の実装とは異な る場合があります。
3. 本資料の構成 1. クラウド入門編 2. 攻撃手法・侵害事例編 3. 防御手法・戦略 クラウドセキュリティを理解するために 必要な、クラウドの仕組みについて説 明します。 現実で悪用されている、具体的な攻撃 手法について解説を行います。 クラウドを守るための汎用的な手法と 戦略の紹介と解説を行います。 単発の攻撃手法だけでなく、複数の攻 撃手法を組み合わせた具体的な事例 についても紹介します。 特定のクラウドプラットフォームに依存 しない、汎用的な戦略を紹介すること で、自社にあったソリューションや実装 を選択できるように構成しています。 特定のクラウドプラットフォームに依存 しない汎用的なクラウドの仕組みを示 すことで、後続の攻撃手法や防御手法 を理解するために必要な土台を築きま す。
4. 持ち帰って欲しい事（ネタばれ） 1. クラウド = API + 認証 2. 認証の突破が必須 3. 様相は変わらない クラウドのあらゆる操作はAPIとして提 供されており、そのAPIは認証・認可で 保護されている。 クラウドAPIは認証によって保護されて いる為、攻撃者はあらゆる手段を持っ て、資格情報・トークンを狙ってくる。 “クラウド”セキュリティとはいえ、土台と なる技術やプラットフォームが変わった だけで、オンプレ時代と様相は変わら ない。 クラウドを操作するにはWebコンソー ル、CLI、SDK等の様々な手段がある が、いずれも内部ではクラウドAPIを呼 び出している。 クラウドセキュリティにおいて、認証の 保護は最も重要な課題の一つであり、 そのためにデジタルアイデンティティの 知識が必須となる。 組織ポリシーによるセキュリティ統制、 ログの保全、継続的な設定監査、正常 動作から逸脱するアクティビティの監 視。これらは、オンプレ時代から必要性 が説かれていた事で、それはクラウド においても変わらない。
5. 01 クラウド入門編 5
6. 本章の構成 1. オンプレ vs クラウド 2. 操作の裏側を知る 3. IAMについて知る サーバー構築を例にとり、オンプレミス 時代とクラウド時代のシステム構築の 違いを比較します。 クラウド操作を支える仕組みついて理 解を深めます。 クラウドセキュリティにおいて、最も重 要な役割を果たす、IAMについて理解 を深めます。 特に、クラウドではWebコンソールなど をインタフェースを通じて、即座にリソー ス調達とシステム構築が可能であるこ とを理解します。 Webコンソールを使ったVM作成を例 に、その裏側で起こっているAPI変換や 認証の意義について理解を深めます。 また、コンピューティングリソース間の 連携に必要なメタデータサービスにつ いても紹介を行います。
7. Step 01 オンプレミスとクラウドを 比較してみる
8. クラウド以前のサーバー構築の⼯程 STEP 01 STEP 02 STEP 03 STEP 04 STEP 05 サイジング ‧発注 納品‧ キッティング マウント‧ 配線 OS インストール ミドルウェア インストール 必要なスペックを試算 し、メーカーに⾒積も り‧発注を⾏う。 届いた機器の検品、メ モリやHDDなどの物 理部品を組み込む。 データセンター∕サー バールームに搬⼊し、 ラックへ固定。電源や LANを配線する。 各種メディア等を⽤い てOSをセットアップ し、初期設定を⾏う。 Webサーバー等の必 要なソフトを導⼊し、 動作確認を⾏う。 Webサーバーを1台構築するだけでも、これら⼀連の⼯程に 数週間〜1ヶ⽉ の時間を要した 周辺機器の調達リスク サーバー本体だけでなく、システムの安定稼働に不可⽋なUPS（無停電電源装置）や、スイッチ‧ルーターなどのネットワーク 機器をはじめとする周辺機器の調達‧設定が必要になる場合も多く、さらに⼯数と時間が積み重なる要因となっていた。 4
9. 必要な時に、必要なリソースを即座に調達出来ない クラウド以前の物理サーバー構築・運用におけるリソース調達の困難さ 01 03 即時の調達が困難 利用者の急増や、突発的なアクセススパイクが発生した 際、必要なサーバーやメモリ、HDDを即座に調達・拡張す ることができない。 物理的な予備機の常時確保 突発的なハードウェア故障によるサービス停止を防ぐため に、コールド／ホットスタンバイ等の物理的な予備機を常 に準備しておく必要があります。 02 04 サイジングによるコスト高 ピーク負荷を想定して余裕を持たせた過剰なサイジングを 行った結果、不要な稼働時間も含めて機材費や保守費用 が上がりがちになります。 電源・空調などの設備工事 システム規模の拡大に伴い、通常のビル電気設備では必 要な電力量や排熱を賄えず、専用の電源引き込み工事 や空調増設工事が必要になります。 その他、RAIDなどの管理も必要でした。予備機材や仮想化技術によりリソース調達‧配分の問題はある程度解決できます。
10. クラウドにおけるサーバー構築 STEP 01 STEP 02 STEP 03 STEP 04 アカウント作成 ログイン ネットワーク構築 サーバー起動 クラウドベンダーと契約し てアカウントを作成する。 管理画⾯（Webコンソー ル）にブラウザからログイ ンする。 Web管理画⾯を操作して仮 想ネットワークを構築す る。 必要なスペックや基本OSを 選択し、起動ボタンをク リックする。    物理的なリソースの調達は⼀切必要なく、すべてWeb管理画⾯の操作のみで完結 構築にかかる時間の⼤幅な短縮 物理サーバーのような発注‧納品待ち、配線作業などの物理処理が⼀切不要になるため、慣れていれば数分程度でWebサー バーの構築が完了する。 4
11. クラウドにおけるリソース調達の柔軟性 物理レイヤーからの解放とコスト最適化をもたらすクラウドの優位性 01 03 即時調達と迅速な起動 クラウドでは必要なリソースを即座に調達・起動可能。ビ ジネスの要求や突発的な負荷に合わせて数分でサー バー環境を構築できる。 従量課金によるコスト最適化 使用した時間やリソース量に応じた課金が行われるた め、初手での高額なサーバー購入や、ピーク時を想定し た過剰なサイジングが不要になる。 02 04 物理管理コストからの解放 キッティング、RAID構成、電源管理、ネットワーク配線と いった、物理サーバー特有の設計やハードウェア保守の 稼働を気にする必要がない。 高水準な可用性とSLA データベースやストレージなどのサービスにはSLA（サー ビス品質保証）が設定されており、可用性を担保するため のコストをクラウドに転嫁できる。 すべての場⾯でクラウドが優れているわけではなく、クラウド移⾏によりシステム費が増加するケースや、ベンダーが⾔うほど クラウド側に転嫁できないケースもある。
12. Step 02 汎用的なクラウドの アーキテクチャ
13. Web管理画面を使ったサーバー構築の裏側 ブラウザ Webコンソール （JavaScriptプログラム） クラウドプラットフォーム 1. サーバー情報の入力 ブラウザ上で必要な構 成情報を入力する。 2. HTTPリクエストへの変換 入力データが JSプロ グラムでAPI送信用の形式に変換されます。 3. リクエストの送信 HTTPリクエストがクラウドの APIエンドポイントへ送信される。 4. リソースの動的確保・デプロイ 仮想マシンなどの 各種リソースが、指示に従い自動構築される。 5. 構築結果の返却 APIから処理結果が HTTPレ スポンスとして返される。 6. 結果の画面表示 構築完了のステータスが管 理画面上に表示される。
14. ここで問題 Q. 立場の異なるチーム間で、適切なリソースアクセス制御をどう実現するか？ 誤操作によるシステム障害や、セキュリティインシデントを防ぐためにアクセス制御が必要。 フロントエンドチーム バックエンドチーム CDN・ストレージ サーバー 静的コンテンツホスティング API・アプリケーション実行環境 認証と認可の必要性 リソースへのアクセス制御を⾏うには、「操作主体の識別」と「権限への紐づけ」が必要です。クラウドでは「IAM」と呼ばれ る機構（またはサービス）がこの機能を提供する。
15. 未認証状態からの、 VM作成シーケンス ユーザー Webブラウザ Webコンソール VM作成画面へアクセス 未認証を検知 ログインへ画面遷移 認証情報の送信 (ID/PW・MFAコードなど ) 認証成功・資格情報 (トークン ) 発行 トークン付きで再アクセス、 IAMによる権限確認、 VM作成操作 IAM API
16. より汎用的なクラウドのアーキテクチャ Cloud Platform User (Resource Owner) Cloud Resource Client CLI Program Console SaaS Mobile Resource I A M A P I VM Storage Function DB Mail Document Log Etc… 用語 説明 主体 (プリンシパル） リソース操作を行う主体。 IAMによって識別される。 資格情報 認証に使用する情報。 トークン 認証・認可の結果として発行されるもの。 APIアクセス時の正当性証明に使用。 クライアント 操作主体の命令をクラウド APIに変換し、リクエストとレスポンスを処理する。 IAM 操作主体の識別と権限確認、コンテキスト確認を行い、操作の可否を判断する。 リソース クラウド上に存在する操作対象となる情報資産。 ※クラウドによって用語の使い方に差異があります
17. Step 03 IAMについて知る
18. IAMにおける 4つの制御要素 IAMで作成したユーザーやグループ、アプリケーションに対して操作できるリソースやアクション、コンテキストの制御が可 能。主な制御項目は下記。 IAMポリシー 主体 対象 プリンシパル リソース 操作を行う主体。ユーザーやク ライアント、後述するワーク ロードが該当する。 操作対象となるリソース。 アクション コンテキスト 操作内容 アクセス条件 リソースに対する操作。VMの 起動や、DBの更新、ファイル の削除など。 アクセス元IPアドレスや、MFA 実施の有無などのアクセス時 の環境情報。 ユーザ グループ スクリプト 計算リソース ポリシー割り当て その他リソース 5
19. IAMによるアクセス制御例１ データ分析の前処理を行うバッチサーバーへ、顧客データの取得と格納を許可する例 IAM { "Effect": "Allow", "Action": [ "storage:PutObject", "storage:GetObject" ], "Resource": “japan-tokyo-1:storeage:customer-data/*", "Context": { "SourceIpAddr": "{private address of batch server}" } } ファイル取得 ファイルアップロード ポリシー作成・割り当て 主体 バッチサーバー アクション PutObject, GetObject リソース 東京リージョンの”customer-data”ストレージ コンテキスト バッチサーバーのプライベートIPアドレスからの API呼び出し
20. IAMによるアクセス制御例２ フロントエンド開発者へ、リポジトリの操作時に、 MFAの実施とセキュリティ要件を満たしたデバイスの仕様を強制する例 IAM ファイル取得 ファイルアップロード ポリシー作成・割り当て ソースコード リポジトリ EC事業部 IT課 田中 太郎 { "Effect": "Allow", "Action": [ "code-repository: "Commit”, "code-repository": "CreateBranch" … ], "Resource": “japan-tokyo-1:code-repository:/ec-frontend", "Context": { "MFA": "passed", "DeviceCompliance": "passed" } } 主体 田中 太郎 アクション CreateBranch, Commit、Pull、... リソース ソースコードリポジトリ（ec-frontend） コンテキスト MFA実施済み セキュリティコンプライアンス準拠済みデバイス
21. リソース間連携を支える「メタデータサービス」 ➂ ① ロードバランサ FaaS・コンテナ・VM ストレージ ② メタデータサービス http://169.XXX.XXX.254/latest/api/token ① ロードバランサからAPIリクエストを受信 ② 内部からのみ到達可能なメタデータサービスへアクセスして、アクセストークンを取得 ※ この結果、リソースへ付与された権限に対応するトークンが得られる。 ③ 取得したアクセストークンを取得して、必要なサービスへアクセスする
22. まとめ１ クラウド = API + 認証 1. API化された操作 あらゆる操作がAPI化され、資格情報があれば「いつでも、誰でも、どこからでも」利⽤可能。 2. 認証とアクセス制御 認証で操作主体の識別と権限の紐づけを⾏い、複雑なアクセス制御を実現。 3. トークンによる操作 認証結果のトークンをAPIリクエストに乗せることで操作が可能に。 IAM 1. 4つの制御要素 「主体」「操作」「リソース」「コンテキスト」の4点を⽤いてアクセスを制御。 2. 多様な「主体」 ⼈だけでなく、スクリプトやクラウドリソース⾃体も主体になり得る。 3. ⼈以外への権限付与 IAMによる権限付与は、システムや各種リソースに対しても柔軟に設定可能。
23. まとめ２ トークンの⽤途と格納場所 1. API操作に必要なトークン 認証によって得られるトークンは、クライアントがAPIリクエスト送信時に必要 2. クライアントの実⾏環境に存在する クライアントはクラウド操作をAPIへ変換し、APIリクエストを送信するためにトークンが必要。 つまり、クライアントの動作環境、または、アクセス可能な環境に、トークンが格納されている。
24. 02 クラウドを取り巻く脅威と事例 24
25. 本章の構成 前半 1. 侵入口 2. 侵入手口 3. 侵入後の行動 攻撃者がクラウド侵入の際狙 うクラウドの入り口について学 びます。 攻撃者が実際に用いる侵入す るための具体的な手法につい て学びます。 侵入に成功した攻撃者がどの ようなことを行うのかについて 学びます。 4. 事例紹介 実際に発生した大規模なクラウド侵害の事例から、 1~3までの一連の流れについて理解を深めます。 後半    Phishing事例 M365事例 AWS事例
26. クラウド環境への主な侵⼊⼝ ⼈‧資格情報/トークン システム      ⼈ 資格情報/トークン クラウドの設定不備 システムの脆弱性 サプライチェーン ⼈を欺いて正規の操作 をさせる 資格情報/トークンを推 測、窃取する 公開されたシステム/ソ フトウェアの脆弱性を 悪⽤ 連携している他システ ムから侵⼊される © ITOCHU Cyber & Intelligence Inc. 設定不備を利⽤する
27. ⼈‧資格情報/トークンを狙った侵⼊⼿⼝ ⼈ 資格情報/トークン 利⽤者を欺いて正規操作をさせる 攻撃者が資格情報/トークンを推測、窃取する  パスワード攻撃  フィッシング  ソーシャルエンジニアリング  マルウェア感染 利⽤者の操作例 ‧ID/PWD⼊⼒ ‧MFA承認 ‧デバイスコードの⼊⼒ ‧アプリ権限の許可 © ITOCHU Cyber & Intelligence Inc.  誤公開された資格情報の取得 ‧PWDリセット ‧資格情報の変更 ‧遠隔操作機能の有効化 ‧ツールのインストール  ソフトウェアサプライチェーン
28. システムを狙った侵⼊⼿⼝ クラウド設定不備 システムの脆弱性 サプライチェーン クラウドの設定ミスを悪⽤してアクセス 公開されたシステムの脆弱性を悪⽤ 開発‧サプライチェーンを侵害 公開リソースへの直  既知の脆弱性の悪⽤ 認証認可の設定不備  設定を悪⽤ 管理画⾯‧APIの意  弱性悪⽤  接アクセス  を悪⽤  図しない公開の悪⽤ © ITOCHU Cyber & Intelligence Inc. サードパーティー  のシステム侵害 システムの脆弱な  ソフトウェアの使⽤ 汚染された VM‧コンテナの脆  OSSパッケージの使⽤ 汚染された
29. インシデント事例：⼈‧資格情報/トークンを狙った侵⼊⼿⼝ １）フィッシング https://www.microsoft.com/en-us/security/blog/threat-intelligence/social-engineering-phishing/ デバイスコードフィッシング： https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/ ２）ソーシャルエンジニアリング https://unit42.paloaltonetworks.com/ja/2025-unit-42-global-incident-response-report-social-engineering-edition/ ランサムウェアに発展する事例： https://www.sophos.com/en-us/blog/sophos-mdr-tracks-two-ransomware-campaigns-using-email-bombing-microsoft-teams-vishing ３）パスワード攻撃 パスワードスプレー攻撃： https://www.huntress.com/blog/lshiy-password-spray-attack ４）誤公開された資格情報の取得 https://www.trendmicro.com/ja_jp/research/26/c/from-misconfigured-spring-boot-actuator-to-sharepoint-exfiltrati.html ５）マルウェア感染 https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion © ITOCHU Cyber & Intelligence Inc.
30. インシデント事例：システムを狙った侵⼊⼿⼝ １）公開リソースへの直接アクセス https://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/ ２）認証‧認可の設定不備を悪⽤ https://www.aquasec.com/blog/kubernetes-exposed-one-yaml-away-from-disaster/ ３）管理画⾯‧APIの意図しない公開を悪⽤ https://www.aquasec.com/blog/threat-alert-teamtnts-docker-gatling-gun-campaign/ ４）既知の脆弱性の悪⽤ https://www.aquasec.com/blog/kinsing-malware-exploits-novel-openfire-vulnerability/ ５）サードパーティーのシステム侵害 https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift?hl=en https://sec.okta.com/articles/2023/11/unauthorized-access-oktas-support-case-management-system-root-cause/ ６）汚染されたソフトウェアの使⽤ https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backd oor?hl=en https://cloud.google.com/blog/topics/threat-intelligence/3cx-software-supply-chain-compromise?hl=en ７）汚染されたOSSパッケージの使⽤ https://unit42.paloaltonetworks.com/npm-supply-chain-attack/ © ITOCHU Cyber & Intelligence Inc.
31. 侵入後の攻撃者の行動と目的 内部探索 権限の悪用・昇格 侵入したネットワークやシステム内を調査し、 重要情報のありかを探る 侵害アカウントの権限を悪用してリソースを操 作する  アカウント情報の収集 権限、グループの確認  権限の昇格  資格情報の窃取  APIキー、シークレット取得  リソースの探索 アクセス可能なリソース(API含む)の特定 © ITOCHU Cyber & Intelligence Inc.  アプリ作成 検知の回避・永続化 長期間にわたり侵入状態を維持する  ログの消去・改ざん  バックドアの設置  データの持ち出し   システムの不正利用 アカウントの作成
32. 前半 1. 侵入口 2. 侵入手口 3. 侵入後の行動 攻撃者がクラウド侵入の際狙 うクラウドの入り口について学 びます。 攻撃者が実際に用いる侵入す るための具体的な手法につい て学びます。 侵入に成功した攻撃者がどの ようなことを行うのかについて 学びます。 4. 事例紹介 実際に発生した大規模なクラウド侵害の事例から、 1~3までの一連の流れについて理解を深めます。 後半    Phishing事例 M365事例 AWS事例
33. Phishing事例：AiTM（Adversary-in-the-Middle） MFAをバイパスするPhishing攻撃 攻撃者の行動 （フィッシングサーバー） 被害者の行動 1. フィッシングサイトへのアクセス 2. 資格情報を認証エンドポイントへ 転送 認証エンドポイント 攻撃者の行動 3. 資格情報の検証  メール閲覧 4. MFA要求の返送  MFA登録  5. MFA実行 6. MFAコードを認証エンドポイントへ 転送 10. 通常の操作 9. トークンの窃取 7. MFAの検証 8. トークンの発行 この事例の ポイント  メール送信 ‧フィッシングサイトにより資格情報やセッショントークンが窃取された。 ‧窃取したセッショントークンを悪⽤して、MFAを回避し正規ユーザーとしてクラウドにアクセスした。 ‧侵害されたアカウントを踏み台として、次の標的に対する不審メールが作成‧送信された。 © ITOCHU Cyber & Intelligence Inc. 検知回避 メール削除  メール作成 11. リソースへ不正アクセス 永続化 アプリ登録  Inboxルール作成  内部探索 情報窃取 リソース 不正利用
34. Phishing事例：AiTM（Adversary-in-the-Middle） AiTMを起点とした M365侵害 01 初期侵入 AiTM攻撃 侵害された取引先からのフィッシングメールを起点に、資格情報と トークンが窃取され、M365に不正アクセスされた。 02 永続化 侵害したアカウントでメールを操作するためのAPIキーを作成した。 APIキーの作成 ※実際には OAuthアプリを作成し、 APIを利用できるようにした。 03 内部探索 /窃取 ビジネスメール詐欺（BEC）を目的に、侵害したメールボックスから 「支払い」や「請求」に関するメールを探索した。 メールの閲覧 04 検知回避 Inboxルール作成 05 不正利用 大量メール送信 この事例の ポイント 受信したメールを既読にして迷惑フォルダへ転送する Inboxルールを作成し、 アカウント侵害を隠蔽した。 組織内外のユーザーへ大量のフィッシングメールを送信し、 さらなるアカウント侵害を図った。 ・APIキー(OAuthアプリ)はユーザーの無効化やセッションを削除しても残存するため、永続化の手法として使用される。 ・メール送信前にInboxルールを作成し、問い合わせ等のメールを隠蔽し侵害の発覚を回避。 ・侵害したアカウントを悪用して攻撃範囲を拡大。 出典：Microsoft Security Blog "Threat actors misuse OAuth applications to automate financially driven attacks" (December 12, 2023) https://www.microsoft.com/en-us/security/blog/2023/12/12/threat-actors-misuse-oauth-applications-to-automate-financially-driven-attacks/
35. M365事例：Storm-2949 Storm-2949による複数の社員アカウントを悪用した情報窃取 01 初期侵入 ソーシャルエンジニアリング 02 内部探索 APIによる調査 03 横展開 被害ユーザー拡大 04 権限悪用 Azure権限悪用 05 情報窃取 不正な操作 この事例の ポイント IT担当者を装って被害ユーザーに MFAを承認させ、パスワードリセットプロ セスを悪用して M365へ不正アクセスした。 組織内を探索し、高権限を持つ IT担当者や管理者を特定するとともに、使用 されているアプリケーションや権限設定を調査した。 特定したIT担当者や管理者に対してソーシャルエンジニアリングを行い、侵 害アカウントを拡大して Azureの高権限を取得した。 Webアプリやデータベースの接続情報や資格情報を取得し、 Azure SQLの 接続制限を変更して外部から直接アクセスできるようにした。 OneDriveやSharePoint、Azure SQLから機密情報や業務データを窃取し、 Azure VMに管理者アカウントを追加して遠隔操作を確立した。 ・1人のアカウント乗っ取りから、クラウド全体へ被害が拡大 ・APIによる内部探索で多数の資格情報、データが窃取された ・ユーザーに付与されていた権限を使用して M365やAzureのリソースに不正アクセス 出典：Microsoft Security Blog "Storm-2949 turned compromised identity into cloud-wide breach" (May 18, 2026) https://www.microsoft.com/en-us/security/blog/2026/05/18/storm-2949-turned-compromised-identity-into-cloud-wide-breach/
36. AWS侵害事例： SCARLETEEL 公開されたサービスから発生した複数の AWSアカウントの侵害 01 初期侵入 コンテナの侵害 02 AWSへ侵入 IAMロールの悪用 03 内部探索 リソースの探索 /窃取 公開サービスの脆弱性を悪用し、AWS上のコンテナを侵害して暗号資産マイナーを 起動した。 侵害したコンテナからEC2のメタデータサービスへアクセスし、取得したIAMロールの 一時的な資格情報でAWSリソースへ不正アクセスした。 LambdaやS3などのAWSリソースを探索し、設定情報や保存データから複数の AWS 資格情報を窃取した。 04 検知の回避 窃取したAWS資格情報を使用して、AWS CloudTrailのログ記録を停止し、検知を回 操作履歴の記録を停止 避した。 05 横展開 別アカウントへの侵害 この事例の ポイント 窃取したAWS資格情報で別AWSアカウントへ不正アクセスし、リソースの探索を試 み たが、権限不足によりほぼすべての操作が拒否された。 ・1つの脆弱性から、窃取したデータや情報を元に、別のAWS環境へ被害が拡大 ・内部探索で多数の資格情報、データが窃取された ・クラウドであっても操作履歴の記録を停止する 出典：Sysdig Blog https://www.sysdig.com/blog/cloud-breach-terraform-data-theft
37. まとめ • クラウドの侵害は、資格情報やトークンの窃取から始まる。 • 攻撃者はクラウド環境の内部探索、永続化、検知回避等のテクニックを既に習得している。 • APT、BEC、ランサムウェア等の様々なモチベーションを持つアクターが既にクラウド環境への攻撃手 法を獲得しており、被害が増加している。
38. 03 クラウドの護り方 38
39. 本章の構成 1. IDのセキュア化 2. 環境のセキュア化 3. 監視・監査・検知 クラウドにおいて、一番の侵入口となる 認証と認可のセキュア化について解説 します。 セキュリティでは、侵入されにくい環境 を作ることも大事ですが、侵入されても 「被害の拡大が難しい」、「悪用しづら い」環境を作ることも大切です。 セキュア化の先のステップである、監 視、監査、検知について解説します。 第一章で説明したように、クラウドの操 作には認証が必要であり、それは攻撃 者にとっても同じです。その為、認証と 認可のセキュア化はクラウドセキュリ ティにおいて最も重要な課題の一つで す。 攻撃者にとってやり辛い環境を作ること は、侵入や侵害の試みを検知しやすい 環境づくりにも繋がります。 追加の項目として、有事の際の調査に 必要なログの保全についても解説を行 います。
40. Step 01 IDのセキュア化
41. IDのセキュア化の重要性 認証の突破は必要最低条件 リソース(API) が認証で保護されている以上、攻撃者は何らかの⼿段で正当な「資格情報」か「トークン」 を得る必要があり、その為に「総当たり、フィッシング、SCCA」などのIDベースの攻撃を⾏う。 つまり、認証のセキュア化を⾏えば、侵⼊の難易度や、窃取した資格情報‧トークンの悪⽤難易度を上げる ことができる。 Cloud Platform Cloud Resource I A M A P I VM Storage Function DB Mail Document Log Etc…
42. 認証要件の強化 パスワードの強化、 MFAの強制、アクセス要件（ IP、地理、デバイス）により IDベースの攻撃を阻止する パスワードの複雑化 MFAの強制 IPアドレス制限 ※2 ▪ 対応できる攻撃 ▪ 対応できる攻撃 ▪ 対応できる攻撃 • 単純な総当たり攻撃 • 総当たり攻撃の対策 • 単純なフィッシング ▪ 注意点 • パスワードを使いまわしていた場 合、リスト型攻撃には効果がない ※1 ▪ 注意点 • 総当たり • フィッシング • ソーシャルエンジニアリング ▪ 注意点 • 多くのフィッシングはAiTM型で、 対応するには「フィッシング耐性 があるMFA」が必要 • 当該IPアドレスを持つインフラを 侵害しない限り、窃取した資格情 報やトークンを使⽤できない※3 • フィッシング耐性があるMFAを 使ったとしても、同意型やデバイ スコードフィッシングに無⼒ • RATをインストールさせて内部侵 ⼊するタイプのソーシャルエンジ ニアリングに対応できない • ⼀部はソーシャルエンジニアリン グによりバイパス可能 ※1 過去の侵害やマルウェア感染により漏洩した資格情報を使⽤し た総当たり、または、不正アクセスです。 ※2 IPアドレス制限は⼀例であり、デバイスフィルターなども有効 です。ただし、どの⽅法にも⽳があります。 ※3 ⼀部プラットフォームではトークン⽣成から1時間はコンテキ ストの再評価を⾏わない実装あり
43. リスクベース認証と制御 サインインのコンテキストからリスクレベルを判定し、レベルに応じた制御を行う。 リスク例 1: 悪性IPからのアクセス 1. ユーザログイン 2. リスク判定 (アセスメント)  • 既知の悪性 IPからのログ インリクエストを検知 • HIGH RISK 判定 アクセスのブロック HIGH RISK なためアクセスブロック • 物理的に不可能な地理 の移動 を検知 • MEDIUM RISK 判定 追加認証 (MFA)の要求 ▶ IT管理者・セキュリティ担当へ通知 IT管理者、セキュリティ管理者へ通知 リスク例 2: 急激な位置情報移動 1. ユーザログイン 2. リスク判定 (アセスメント)  ▶ 強度が高いMFAの要求
44. Just In Time Access 普段は低い権限のアカウントを使⽤、必要に応じて⼈による承認プロセスを経て、⼀時的な権限昇格を⾏う 01 02 03 04 05 常時（平時） 申請（起票） 承認（審査） 利⽤可能 剥奪 普段は必要な情報の み閲覧できる「制限 された最⼩アカウン ト」で運⽤。 「20XX/X/X 15:00〜17:00」の期 間で、VMへの⼀時的 なログイン権限をリ クエスト。 管理者が申請理由、 対象VM、時間帯の妥 当性を確認し、リク エストを承認。 VMログイン権限が有 効化。15:00から作 業を開始。 17:00を迎えると同時 に、VMログイン権限 がシステムによって ⾃動で即時剥奪。 ▪ 付与権限 • 閲覧のみ   有効期間  ▪• 15:00 ~ 17:00 
45. Step 02 環境のセキュア化
46. リソースコンテナによる環境の分離 1. リソースコンテナ(RC) とはリソースをグループ化して管理するための単位。※１ 2. RC内に複数のシステムを混在させた場合、⼀つのシステムの侵害が複数のシステム侵害につながる 3. RC内に、本番、検証、開発などの複数の環境を混在させた場合、開発‧検証から本番環境へ侵害が波及する可能性がある 4. 各環境によって、セキュリティポリシーが異なる為、環境を分離しておくと後々制御しやすい ※1 AWSであれば、AWSアカウント/OU、GCPであればプロジェクト/フォルダ、Azureであればリソースグループ/サブスクリプション/管理グループが該当する リソースコンテナ root サービスA サービスB サービスC 本番 サービスA OU サービスB OU セキュリティOU サービスC テスト サービスC 開発 ⼀つのRC内に、複数のサービス‧環境を混在させた場合のリスク 本番 RC テスト RC 開発 RC 本番 RC テスト RC 開発 RC ログ保管 監視基盤 RC RC 後述するディレクトリ機能によるリソースの管理例
47. サービス制限、リージョン制限 1. 侵⼊に成功した攻撃者は、より価値の⾼い情報や、悪⽤可能なリソース、権限昇格や多環境への横移動の⼿掛かりを得る ために、「リソースの列挙」や「権限の確認」を⾏う 2. この時に、⾃社の環境では「通常」使わないサービスのAPIを実⾏しようとする 3. マイニングやフィッシングの踏み台、永続化⽤リソースを作成する際に、攻撃者の活動地域にリソースを作ることもある 4. サービスとリージョンを制限しておけば、悪⽤の機会を削ぎ、試みを検知することができる。 root 日本からのみ操作可能 サービスA担当者のみ操作可能 MFA必須 本番運用機のIPからのみ 日本リージョンのみ VM、NW、DBサービスのみ サービスA OU 本番 RC テスト RC 開発 RC サービスB OU 本番 RC テスト RC 開発 RC セキュリティOU ログ保管 監視基盤 RC RC VM、NW、DB、CI/CDサービスのみ
48. 組織ポリシーによるセキュリティ統制 1. 多くのクラウドプラットフォームでディレクトリ機能が提供されている 2. 組織ポリシーを使うことで、ディレクトリの各階層へポリシーを適⽤できる 3. セキュリティ機能の有効化や、特定の危険な機能の利⽤を禁⽌するポリシーを、「root」に適⽤することで、全システム に対してセキュリティ統制を⾏うことも可能。 root 全社ポリシー • • • • • MFA必須 セキュリティ機能の無効化禁止 クラウドAPIログの無効化禁止 組織外へのVMイメージの公開を禁止 不特定多数が書き込み可能なストレージの公開を禁止 サービスA OU 本番 RC テスト RC 開発 RC サービスB OU 本番 RC テスト RC 開発 RC セキュリティOU ログ保管 監視基盤 RC RC
49. Step 03 監視・監査・検知
50. 監視のためのログ ー有効化、取得、保全ー 1. 「ログ」は有事の際の調査や、セキュリティ監視にも必要な重要なデータである 2. しかし、多くのクラウドプラットフォームでは課⾦の問題から、デフォルトで有効化されていないことが多い 3. クラウドには、⼤きく分けてAPIログを記録するアクティビティログと、データ操作を記録するデータログの２種類がある ※ ⼀般的にデータログはアクティビティログに⽐べて膨⼤な量になる為、有効化の際は注意が必要 4. セキュリティ監視では検索性、証拠保全では⻑期保管が要件となる為、それぞれに合ったストレージや世代管理を⾏う 5. 侵⼊に成功した攻撃者はログの無効化と削除を⾏うことがある為、保護が必要である root 全社ポリシー • アクティビティログの無効化禁止 • ログ保管RCへ、ログ転送を行うリソースの削除禁止 • ログ保管RCへ、ログ転送を行う設定の変更禁止 サービスA OU 本番 RC テスト RC 開発 RC 安価なストレージへログ転送 ３年間保存 セキュリティOU ログ保管 監視基盤 RC RC 直近180日分をSIEMへ転送
51. コンテキストを活かした監視 これまで説明してきた「認証時のアクセス要件」、「サービス‧テナント制限」などは全て、特定のシステムが「正常に動作 する為の要件」であり、これらは、防御と同時に検知に活⽤できる。 1. 攻撃者は海外にいることが多いため、アクセス元が国外IPとなる 2. サービスの稼働に必要ないリソースが作成される 3. 発⾒を遅らせるために、通常とは異なるリージョンにリソースを作成する また、多くのクラウドプラットフォーム上で不審なAPIアクティビティを検知するソリューションが提供されいるため、そち らも併せて活⽤を検討する。※残念ながらデフォルトで通知機能がないことが多く、リソース課⾦のため、無邪気に有効化すると酷い⽬にあるケースがある root 全社ポリシー • セキュリティ機能の無効化を禁止 サービスA OU 本番 RC テスト RC 開発 RC サービスB OU 本番 RC テスト RC 開発 RC アラートは監視基盤 RCへ集約 セキュリティOU ログ保管 監視基盤 RC RC
52. ベースラインを維持する為の設定監査 1. セキュア化が終わったら、それを維持することも重要である 2. 各クラウドに「理想とする設定値」をルール化し、定期的に監査を⾏うソリューションが⽤意されている。 3. 例えば、「ログが有効であること」「セキュリティ機能が有効化されていること」などをルール化し、そこ から逸脱した設定や構成が⾏われた際に、検知と通知を⾏う。 4. 設定監査の構成には「設定変更が⾏われるたびに監査を⾏う」ものと「⼀定間隔や⼿動で⾏う」モノがあ る。前者は⽐較的⾼額になることがあるが、即座に是正できる。後者はタイムラグはあるが安価に監視を実 現できる。 5. CI/CDに設定値の監査を組み込むことで脆弱性を予防することも可能。    クラウド設定情報 設定監査 可視化とアラート APIを介して各クラウド環境の構成‧設 定情報を継続的に取得 ポリシー違反のチェックやコンテキスト（接続 関係等）の分析を実⾏ セキュリティリスクや構成不備を管理 画⾯へ集約‧管理者へ通知
53. 課金アラート 課⾦アラートはセキュリティインシデントの検知にも有効。 • 攻撃者は侵害したクラウド環境上で、巨⼤なインスタンスを作成してマイニングを⾏ったり、メール サーバーを⽴てて⼤量にスパムメールを送信などの悪⽤を⾏う。 • これらの攻撃者の⾏動は、システム構成の不備や直接の侵⼊検知ログよりも前に、「異常なコストの上 昇」や「⾒慣れない明細」として現れる。 • 各クラウドプラットフォームでは、設定した閾値に応じた通知設定だけでなく、機械学習を⽤いて普段 と異なる課⾦の急増を⾃動検知するソリューションが標準で⽤意されている。    攻撃者による悪⽤ コストの異常上昇 課⾦アラート検知 巨⼤インスタンス作成 マイニング‧スパム送信 ⾒慣れない明細 急激な課⾦の増加 閾値通知 / 機械学習 異常を⾃動検知して対処
54. まとめ 認証要件と環境のセキュア化 1. 認証要件の強化 クラウドのあらゆる操作はAPIの実⾏であり、そのAPIは認証によって保護されている。認証時の要件を強化することで不 正アクセスのリスクを低減すると同時に、要件から逸脱したアクセスを検知することで不正の早期検知につなげる。 2. 環境のセキュア化 必要がないサービスやリージョンを閉じることで、悪⽤の難易度を上げると同時に、不要なサービスやリージョンを検知 することで不正の早期検知につなげる。 ログ、統制、検知、監視、監査 1. ログ ⽬的に沿ったログの収集と保管は、コスト効率が良い監視につながる 2. 組織ポリシーによる統制と監査 組織ポリシーを使⽤してセキュリティ事項を強制しつつ、設定監査にてセキュリティ体制を継続評価する。 3. 監視と検知 完璧なセキュリティはない。監視と検知を⾏うことで侵⼊を早期検知したり、セキュリティが弱い個所を発⾒できる。
55. クラウドセキュリティ人材になる為の、学習ステップ     0. 基礎知識 1. システムを作る 2. 脆弱性を体験 3. 収集‧実験‧熟考 事前習得を推奨する4分野 ⾃⼒で環境を構築する 攻撃と防御を肌で知る サイクルを回し続ける • Web技術 簡単なWebアプリの⾃作経験 • ネットワーク マスタリングTCP/IP⼊⾨レベル • ID/認証 はじめてのデジタルアイデンティ ティを読了 • セキュリティ 安全なWebアプリケーションの 作り⽅を読了 • IaaS構成のWeb 典型的な仮想サーバーを⽤いた インフラを構築 • サーバーレスSPA FaaSやマネージドサービスを組 み合わせた構成を構築 • やられアプリで実際の攻撃を体 験する • 仕組みとしての攻撃⼿法を正しく 理解する • どう防ぎ、どう検知するかを具体 的に考える ※ 専⽤リソースコンテナにデプロイすること ※ 信⽤できないやられアプリは使⽤しないこと • 攻撃を紐解く 仕組み‧成⽴条件‧影響を深く 分析する • 防御策を知る ガイドラインは膨⼤なため、AIを 積極的に活⽤ • ⾃社環境に適⽤ ⾃⾝の設定で守れているか、実装 ⽅法を熟考
56. 各学習ステップのためのリンク集 1. 基礎知識 クラウドは認証‧認可技術によって保護されている。クラウドを護る為には、認証認可技術への理解が必要不可⽋。 • Webを⽀える技術 | 技術評論社 • マスタリングTCP/IP ⼊⾨編（第6版） | オーム社 • 第02回shirosec デジタルアイデンティティ編 • OAuth徹底⼊⾨ セキュアな認可システムを適⽤するための原則と実践 | 翔泳社 • はじめてのデジタルアイデンティティ | 技術評論社 • 体系的に学ぶ 安全なWebアプリケーションの作り⽅ 第2版 | SBクリエイティブ • 実践 Webペネトレーションテスト - O'Reilly Japan 2. システムを作る 書くクラウドに⽤意されているチュートリアル、または、書籍を１冊読んで⼿を動かす。クラウドについては動きが早い ため、ここでは書籍等のリンクは記載しない。書くクラウドのコミュニティに参加して質問するのも⼀つのやり⽅。
57. 各学習ステップのためのリンク集 1. 脆弱性を体験する ◦ https://github.com/ine-labs/AWSGoat ◦ https://github.com/ine-labs/AzureGoat ◦ https://github.com/ine-labs/GCPGoat ◦ https://github.com/RhinoSecurityLabs/cloudgoat ◦ https://github.com/mandiant/Azure_Workshop 2. 収集‧実験‧熟考 ◦ https://hackingthe.cloud/ ◦ https://attack.mitre.org/matrices/enterprise/cloud/ ◦ パスキーのすべて | 技術評論社 ◦ デジタルアイデンティティのすべて - O'Reilly Japan