Software Supply Chain Attackからクラウド環境を守るためにできること

現代のソフトウェア開発において、Software Supply Chain Attack (SSCA) は見過ごせない脅威です。本資料では、SSCAによって窃取されたクレデンシャルが悪用され、クラウド環境が侵害されるリスクに焦点を当てます。

供給元や依存関係を完全に制御することは困難であるという前提に立ち、混入を最小限に防ぐための工夫と、万が一の侵入を想定した「環境の要塞化」という戦略的アプローチを解説します。

https://cloudsecjp.connpass.com/event/393141/
#cloudsecjp

Transcript

1. Protect Your Cloud From Software Supply Chain Attack — Software Supply Chain Attackからクラウド環境を守るためにできること 1
2. 諸注意 1. 本資料を許可なく営利目的で使用することを禁止します。 2. 出典を明示しない再配布を禁止します。 3. 本資料はSSCAから「クラウド環境を守る」事にフォーカスしています。 2
3. Ch. 01 SSCAからクラウド環境を守る為の 考え方 3
4. SSCAにおける主要リスク    1. ランサムウェア感染 2. 情報漏洩 3. クラウド環境の侵害 汚染されたパッケージやソフト ウェアの最終ペイロードとして、 ランサムウェアが実⾏され、事業 停⽌や重⼤なデータ損失を引き起 こす可能性。 バックドアなどの悪意あるコード を介して、顧客の個⼈情報、ソー スコード、機密データなどの重要 資産が外部の攻撃者サーバーに不 正送信されます。 開発環境やサーバー内から窃取さ れたトークンや認証情報を悪⽤さ れ、クラウド環境⾃体のフル制御 奪取やリソースの不正利⽤へと発 展します。 ※ ただし、現状で報告されているのは事例は、 ⼀部のソフトウェア改竄やtyposquattingのみ。 OSSに対するSSCAによって実⾏されるペイロードの殆どは、InfoStealer 的な挙動を⾏うものが多い。 4
5. このスライドのターゲット    1. ランサムウェア感染 2. 情報漏洩 3. クラウド環境の侵害 汚染されたパッケージやソフト ウェアの最終ペイロードとして、 ランサムウェアが実⾏され、事業 停⽌や重⼤なデータ損失を引き起 こす可能性。 バックドアなどの悪意あるコード を介して、顧客の個⼈情報、ソー スコード、機密データなどの重要 資産が外部の攻撃者サーバーに不 正送信されます。 開発環境やコンピューティングリ ソース内から窃取されたトークン や認証情報を悪⽤され、クラウド 環境の侵害が⾏われる。 ※ ただし、現状で報告されているのは事例は、 ⼀部のソフトウェア改竄やtyposquattingのみ。 OSSに対するSSCAによって実⾏されるペイロードの殆どは、InfoStealer 的な挙動を⾏うものがほとんど。 5
6. 漏洩したクレデンシャルを⽤いた、クラウド環境の侵害フロー Step 01 Step 02 Step 03 Step 04 SSCAによる汚染 クレデンシャルの漏洩 クレデンシャルの リストア 悪意ある操作 開発環境   開発環境 SSCAにより汚染された  ‧ライブラリ ‧ソフトウェア ‧拡張機能 ‧イメージ  コンピューティング リソース   連携システム   CI/CD環境 環境変数、既定のファイル、ブ ラウザのパスワード DB、パス ワードマネージャからクレデン シャルを窃取する。   攻撃者端末  データの持ち出し  暗号化  不正リソースの作成 ストレージやデータベース から機密データを持ち出す ⼊⼿したクレデンシャルを 設定 Proxyの悪⽤ プロキシや踏み台サーバ 経由でアクセス ストレージやデータベース の内容を暗号化 他環境への攻撃の踏み台や マイニングリソースの作成 6
7. 守る側から⾒たSSCAのポイント SSCAを防ぐことの困難さ 攻撃者の挙動 クレデンシャルはどこにでも存在する  攻撃者は⾃⾝の環境からアクセスしてくることが多いた  クラウド操作にはクレデンシャルが必須であり、それ故 に、開発環境、コンピューティングリソース、連携シス テム、CI/CD環境などあらゆる場所に存在する。社員の開 発端末ならまだしも、全ての環境を制御化において管理 するのは困難。 膨⼤な依存関係、管理の困難さ 普段と異なるアクセスコンテキスト め、通常と異なるIPアドレスや、普段とは違う国‧地 域、あるいはデバイスやエージェントが使⽤される。 普段と異なるサービス‧リージョン利⽤  現代のシステムは膨⼤な依存関係を持つ。その多くは、  侵害プロセスの過程において、攻撃者は通常と異なる操 外部の組織やOSSコミュニティによって開発‧メンテナ ンス‧配布されており、制御できるものではない。既知 の悪意あるパッケージを検知するソリューションを使っ ても、公開から検知までタイムラグがある。従って、悪 意あるコードの混⼊を完全に防ぐのは困難。※１ 作を⾏う。例えば、⾃社の開発業務やサービス稼働に必 要が無いサービスの操作や、普段利⽤していないリー ジョンへのリソース作成などがある。 ※１ 既知の悪性インフラ、ペイロードが使⽤されればAV/EDRに検知される可能性はあります。（または、不審な振る舞いとして検知） 7
8. 戦略⽴案のコンセプト 01. 混⼊防⽌ 02. 環境の要塞化  ⼿が届く範囲で汚染の混⼊を防ぐ 汚染の混⼊を防ぐには、SDLCへの介⼊が必要にな  汚染が混⼊する前提で環境を要塞化する 「汚染の混⼊を完全に防ぐことは困難である」とい るが、現代のソフトウェア開発では、外部組織や OSSコミュニティによって開発された、膨⼤なライ ブラリ、ツール、サービスを利⽤しており、全ての 構成物のライフサイクルに関わることはできない。 う前提に⽴ち、万が⼀の混⼊（インシデント発⽣） 時に被害を最⼩限に抑えるための「IDのセキュア 化」や「環境のセキュア化」を⾏う。※後述 そのため、⼿が届く範囲でコントロールを⾏い、可 能な限り汚染の混⼊を防ぐことが⼤事。 セキュア化に加えて監視も⾏うことで、いち早くク レデンシャルの漏洩を感知し、対応を⾏う体制を構 築する。 ※１ 既知の悪性インフラ、ペイロードが使⽤されればAV/EDRに検知される可能性はあります。（または、不審な振る舞いとして検知） 8
9. Ch. 02 クラウド環境のセキュア化 ーIDのセキュア化 9
10. IDのセキュア化の重要性 攻撃者にとって認証の突破は必要最低条件 クラウドの操作＝API操作であり、そのAPIは認証で保護されている。つまり認証をクリアしない限り、正規 ユーザーも攻撃者もクラウド操作を⾏えない。（だからこそ、攻撃者はクレデンシャルを狙う） つまり、攻撃者にとっては認証の突破が必須でり、逆に守る側としては認証要件を強化することで侵⼊の阻 ⽌や試みを検知することが可能となる。 Cloud Platform Cloud Resource I A M A P I VM Storage Function DB Mail Document Log Etc… 10
11. アクセス要件の明確化と実装 MFAの強制 ▪ 実装 • ポリシーによるMFAの強制 ▪ 解説 ID/PWのみ漏洩した場合は、組織ポリシーやIAMポリシーなど により、MFAを強制することで侵⼊を阻⽌できる。 アクセスコンテキスト ▪ 実装 • IPアドレス制限 • OS‧デバイスフィルター ▪ 解説 攻撃者は⾃⾝のデバイス、攻撃インフラ、またはプロキシか らアクセスすることが多いため、信頼できるIPアドレスから のみアクセスを許可することで侵⼊を阻⽌できる。 デバイスIDやOSによるフィルターを実装できる場合は、⾃社 デバイス‧OSのみ許可することも有効な策の⼀つ。 ※ただし、⼀部のプラットフォームではデバイス‧OSフィルターのバイパス ⼿法が存在します ※IPアドレス制限はコンピューティングリソースに対しても有効 11
12. 一時的なクレデンシャルの使用と限界 効果：悪⽤のタイムラグを突く 限界：繰り返し窃取される場合 ▪ 短命化による機会の剥奪 ▪ 根本原因が残る場合は効果が薄い クレデンシャル窃取から実際に悪⽤が始まるまでにはタイム ラグがある。有効期限の短いクレデンシャルを⽤いること で、悪⽤の機会を削ぐ事ができる。  タイムラグ   攻撃者がクレデンシャルを「繰り返し」窃取できる場合は、 ⼀時的なクレデンシャルによる対策効果は限定的。 例1: 脆弱な GitHub Actions の放置  ワークフロー起動のたびに攻撃者が⾃動でトークンを繰り返し 取得‧悪⽤可能。 例2: SCCA等の汚染（バックドア永続化） ① 窃取 ② 失効 (短命) ③ 悪⽤失敗  cronやサービス登録等で永続化を⾏うことで、定期的にクレデ ンシャルを外部送信できる。 12
13. リスクベース認証と制御 アクセスコンテキストからリスクレベルを判定し、レベルに応じた制御を行う。 リスク例 1: 悪性IPからのアクセス 1. ユーザログイン 2. リスク判定 (アセスメント)  • 既知の悪性 IPからのログ インリクエストを検知 • HIGH RISK 判定 アクセスのブロック HIGH RISK なためアクセスブロック • 物理的に不可能な地理 の移動 を検知 • MEDIUM RISK 判定 追加認証 (MFA)の要求 ▶ IT管理者・セキュリティ担当へ通知 IT管理者、セキュリティ管理者へ通知 リスク例 2: 急激な位置情報移動 1. ユーザログイン 2. リスク判定 (アセスメント)  ▶ 強度が高いMFAの要求 13
14. 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  14
15. 最⼩権限の原則 漏洩したクレデンシャルの悪⽤による侵害の範囲は、そのクレデンシャルに紐づく権限に左右される。「最⼩権限の原則」を 守り、「実⾏可能な操作と対象」を可能な限り限定することで、被害を最⼩化を⾒込める。 ✕ 過剰な権限（リスク⼤） ◯ 最⼩権限の適⽤（被害の限定化） 全サーバー  管理者権限 データベース 設定変更 クレデンシャルが漏洩した場合、 すべてのリソースが攻撃者の⽀配下に 全サーバー  制限付き権限 特定DBの閲覧 設定変更 漏洩しても特定のリソースに対する操作以外は遮断 される為、他のリソースへの影響を抑えられる 15
16. Ch. 03 クラウド環境のセキュア化 ー環境のセキュア化 16
17. リソースコンテナ (RC) による環境の分離 1. 同⼀RC上に本番‧開発環境や、複数のシステムを混在させると、⼀つの侵害が他システムへ波及するリスクがある。 2. 「最⼩権限の原則が守れていない」、「強い権限を持っている開発者のクレデンシャル」が漏洩した場合に、そのような 事態に陥ることが多い。 ※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内に、複数のサービス‧環境を混在させた場合のリスク 17
18. サービス制限、リージョン制限 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サービスのみ 18
19. 組織ポリシーによるセキュリティ統制 1. 多くのクラウドプラットフォームでディレクトリ機能が提供されている 2. 組織ポリシーを使うことで、ディレクトリの各階層へポリシーを適⽤できる 3. セキュリティ機能の有効化や、特定の危険な機能の利⽤を禁⽌するポリシーを、「root」に適⽤することで、全システム に対してセキュリティ統制を⾏うことも可能。 root 全社ポリシー • • • • • MFA必須 セキュリティ機能の無効化禁止 クラウドAPIログの無効化禁止 組織外へのVMイメージの公開を禁止 不特定多数が書き込み可能なストレージの公開を禁止 サービスA OU 本番 RC テスト RC 開発 RC サービスB OU 本番 RC テスト RC 開発 RC セキュリティOU ログ保管 監視基盤 RC RC 19
20. Ch. 04 監視 20
21. コンテキストを活かした監視 これまで説明してきた「認証時のアクセス要件」、「サービス‧リージョン制限」などは全て、特定のシステムが「正常に動 作する為の要件」であり、これらは、防御と同時に検知に活⽤できる。 1. 攻撃者は海外にいることが多いため、アクセス元が国外IPとなる 2. サービスの稼働に必要ないリソースが作成される 3. 発⾒を遅らせるために、通常とは異なるリージョンにリソースを作成する また、多くのクラウドプラットフォーム上で不審なAPIアクティビティを検知するソリューションが提供されいるため、そち らも併せて活⽤を検討する。※残念ながらデフォルトで通知機能がないことが多く、リソース課⾦のため、無邪気に有効化すると酷い⽬にあるケースがある root 検知ルール サービスA OU 本番 RC テスト RC 開発 RC サービスB OU 本番 RC テスト RC 開発 RC セキュリティOU ログ保管 監視基盤 RC RC • • • • • 社外IP外からの操作 大量の操作失敗を発生させているアカウント 普段とは異なるリージョンの操作 デバイス・OAuthアプリの登録 新規アカウント・APIキーの作成 21
22. 課金アラート 課⾦アラートはセキュリティインシデントの検知にも有効。 • 攻撃者は侵害したクラウド環境上で、巨⼤なインスタンスを作成してマイニングを⾏ったり、メール サーバーを⽴てて⼤量にスパムメールを送信などの悪⽤を⾏う。 • これらの攻撃者の⾏動は、システム構成の不備や直接の侵⼊検知ログよりも前に、「異常なコストの上 昇」や「⾒慣れない明細」として現れる。 • 各クラウドプラットフォームでは、設定した閾値に応じた通知設定だけでなく、機械学習を⽤いて普段 と異なる課⾦の急増を⾃動検知するソリューションが標準で⽤意されている。    攻撃者による悪⽤ コストの異常上昇 課⾦アラート検知 巨⼤インスタンス作成 マイニング‧スパム送信 ⾒慣れない明細 急激な課⾦の増加 閾値通知 / 機械学習 異常を⾃動検知して対処 22
23. Ch. 05 総まとめ 23
24. 総まとめ SSCAからクラウド環境を守るためのポイント SSCAを防ぐことは困難なため、認証情報の漏洩しても悪⽤が困難、または、悪⽤の試みを早期に検知できる環境づくり が重要。    1. クラウドから⾒たリスク 2. セキュア化による防御 3. 早期検知のための監視 クレデンシャルの漏洩が即座にクラ ウド全体の侵害に直結。情報漏洩や サービス停⽌、攻撃の踏み台として の不正利⽤などにつながるリスクが ある。 業務やシステム要件を元に、クラウ ド環境へのアクセス制御を⾏う。リ スクベースや、JIT、サービス‧リー ジョン制限なども導⼊し、特定の正 常動作のみを許可する堅牢なクルド 環境を構築する。 不審なAPIアクティビティ監視や、コ ンテキストを活かした監視により、 クレデンシャルの漏洩を早期に検 知。課⾦アラートも活⽤等も活⽤し て多⾓的な監視を⾏う。 24
25. Ch. 06 おまけ 25
26. 汚染の混⼊を防ぐために出来ること 分類 パッケージマネージャ 依存関係管理 具体的な対策‧⼿法 ‧パッケージインストール時のスクリプト実⾏を無効化するオプションを利⽤ ‧オプションで公開から指定した期間が過ぎたパッケージのみインストール ‧可能な限りバージョンを固定する ‧依存関係のセキュリティスキャン⾏うツール‧サービスを活⽤する アップデート対応 ‧⾃動アップデート機能を無効化 ‧緊急アップデートが必要な場合は、公式から案内されたバージョンにアップデートする ‧検証環境でアップデートを⾏い、セキュリティスキャンで安全性を確認する 安全なリポジトリ ‧ベンダーが安全性を証明するパッケージリポジトリを使う ‧パッケージマネージャのラッパーとして動作し、悪意あるパッケージのインストールを阻⽌するツー ルを使う 開発環境 ‧OA端末には基幹システムやチャットーサービス等の、クラウド以外の重要なシステムへのパスワード などが含まれるため、OA端末と開発端末を分離する ‧VMやDocker等の隔離された環境上で開発を⾏う CI/CD環境 ‧テストやビルドを実⾏する前に依存関係をスキャンする ‧イメージやツールのバージョンを固定し、更新を⾏えるメンバーを限定する ‧リリースを承認制とし、⼈の介⼊を⾏う ※「開発環境」に関しては混⼊を防ぐというより、開発端末の感染による⼆次被害を防⽌するための策です 26