CloudSec JP #005 後締め ～ソフトウェアサプライチェーン攻撃から開発者のシークレットを守る～

Transcript

1. #005 CloudSecJP #cloudsecjp 後締め
2. 今後の活動計画 01 04 02 03 ソフトウェアサプライチェーン 登壇・会場提供募集 アンケートのご案内
3. 3 このコーナーについて • Tips や脅威情報を共有するコーナーです。 • 今後の活動計画についてもお話しします。
4. 4 ソフトウェアサプライチェーンのリスク • 概要 年初から著名なOSSやツールに悪意あるコードが混入するケースが相次いだ。正規の配信元 の侵害でなくとも、typosquatting等による偽ライブラリ／ツールの配布は昔からある。 攻撃者は端末上の資格情報や暗号資産を狙っていることが多い。つまり、クラウドのシーク レットキーやログイン情報も漏洩する可能性がある。 この資料では、「開発者のシークレット」を守るために出来ることを簡単に紹介します。 • 事例 • From CI/CD to cloud compromise: Real-world breach using OpenID Connect abuse • Trivy、LiteLLM、Axiosのソフトウェアサプライチェーン侵害事案を考察～CI/CD環境のソフトウ ェアサプライチェーン侵害と連鎖とは？
5. 5 入り口はどこか？ • ライブラリのインストール 年初から著名なOSSやツールに悪意あるコードが混入するケースが相次いだ。正規の配信元 の侵害でなくとも、typosquatting等による偽ライブラリ／ツールの配布は昔からある。 攻撃者は端末上の資格情報や暗号資産を狙っていることが多い。つまり、クラウドのシーク レットキーやログイン情報も漏洩する可能性がある。 • 拡張機能 VSCodeのようなエディタの拡張に汚染されたライブラリが混入したり、有名な拡張機能を 模した偽の拡張機能の配布が行われている。 • ソフトウェア 正規ソフトを装った InfoStealer が Google Ads で配布されるなどの事案が発生しています。 もちろん、ソフトウェアが利用しているライブラリ等が汚染されれば、それが購入するリス クがあります。 ※上記は主な「入り口」です。CI/CDパイプインの汚染や、コンテナイメージの汚染、悪意あるブラウザ拡張などもあります ※モダンな開発現場では大量のツールを駆使して効率化と品質向上を図りますが、攻撃者としてはいずれかを汚染できれば開発者の端末へ到達可能です
6. 6 対策が困難なSWサプライチェーンリスク • コントロールできない、やるとしてもコストが。。。 入り口はたくさんある。コントロールしたいが、OSSに関してはメンテナーでもない限り制 御できない。現代のソフトウェア開発は膨大な数のOSSに支えられている。アップデートの たびに全てチェックするのは不可能。 pip/npmなどのパッケージマネージャをラップして悪性ライブラリのインストールを防ぐツ ールや、依存関係ファイルをスキャンするソリューションも存在するが、提供側の発見能力 と速さに依存。パッケージマネージャーだけ意識しても不完全。 ※ パッケージマネージャのオプションでインストール時のスクリプトを無効化することも出来るが、パッケージ本体に悪意あるコードが挿入されるパターンには効力を発揮しない • 混入させないことも大事だが。。。 現状では、全ての「入り口」に対策を行うのは現実的ではない。観点を変えて、漏洩しても 悪用しにくい、または、早期に検知できる仕組み作りも重要。
7. 7 開発者のシークレットを守るために - 開発マシンで出来る事 • AV/EDR 開発機のパフォーマンスに影響を与えるが、検知には有効。開発者の労力を減らすために、 管理側でルールのアップデートやアラートの集約を行えるとベスト。 • コンテナ、サンドボックス Dockerコンテナや仮想マシン内で開発を行う。諸々の制約はあるが、情報漏洩やランサム等 の侵害の範囲をサンドボックス内に抑えることが出来る。 ※悪意を持って配布されている、または、汚染されたイメージファイルに注意しましょう • 業務端末との分離 業務端末は機密情報の宝庫。複数のSaaSサービスのパスワードや顧客情報も保持している。 監視の観点では、開発機で実行されるコマンドやコードノイズになり得る。 業務端末と開発端末を分離する（可能ならNWも）ことで感染時の被害の局所化や、シーン にあった監視を行える。
8. 8 開発者のシークレットを守るために - シークレットのセキュア化 • コンテキストの設定 アクセスキーを使用する際のアクセス元IPや、地域、デバイスなどの許可されたコンテキス ト外からの利用を拒否する。加えて、許可されたコンテキスト外からの利用を検知すること で資格情報の漏洩を検知できる可能性がある。 • 一時的な資格情報 シークレットの漏洩から悪用までタイムラグがある場合がある。定期的にシークレットの再 作成が必要となるが、有効な手段の一つ。 ※リフレッシュトークンが漏洩した場合は、その限りではない • 最小権限 シークレットに紐づく権限を最小とする事で、侵害の範囲を限定できる可能性がある。加え て、許可していないアクションの実行や、大量の失敗を検知することで漏洩を検知できる可 能性がある。 ※DBSC/DPop、もっと流行ってくれ。。。（切実）
9. 9 開発者のシークレットを守るために - クラウド側で出来る事 • リソースコンテナの分離 本番環境との接続が無く、機密情報の格納も行わない、開発のみに使用するリソースコンテ ナを用意することでシークレット悪用時の被害を軽減する。 通常の開発時は「開発用リソースコンテナ」のみ操作可能なシークレットを使用し、本番、 検証時は PIM/JIT を使用した昇格やアクセスポリシーを使用する。 • 組織ポリシー 多くのクラウドプラットフォームではリソースの階層化が可能。上位の階層でポリシーを実 装することで、下層のリソースコンテナに対して、許可していないリージョンや、サービス の使用を禁止することが出来る。 許可のないアクセスキーの発行を禁止したり、一律で国外からの利用を禁止するなど、現場 に委ねず、組織全体で統制を行いたい場合に有効。
10. 10 開発者のシークレットを守るために – 運用 • シークレット発行の管理 組織ポリシーを活用して管理者以外によるシークレット作成を禁止する。シークレットが必 要な場合は申請をもって作成。申請時に、アクセス元IP、権限、リソースコンテナ、利用期 限などの条件を伝えてセキュア化したシークレットを発行する。 • 共有の禁止 一つのシークレットを複数の開発者で共有すると漏洩した際の、漏洩元の特定が困難になる。 漏洩元が特定できなければ再発防止も困難。また、シークレットを使用していた全ての開発 者が影響を受ける為、シークレットの共有はおススメしない。
11. 11 登壇募集フォームについて • 常時開設しています。 • 特定の製品や企業を過度に持ち上げ るものでなければ何でもOK • 迷った場合は気軽にご相談ください。 • 例 • ツールを触ってみた • オレオレCSPM作ってみた • Entra IDのXXX機能について • AWS XXXXのリスクと対策
12. 12 今後の活動について（目標） ⚫ CloudSec JP #006 ⚫ 夏初旬を目標（６、７月） ⚫ SWサプライチェーンネタ ⚫ 発表者、会場提供ともにお待ちしております ⚫ CloudSec JP #007 ⚫ 秋頃を目標（9、10月） ⚫ CloudSec JP Workshop ⚫ DuckDBを使ったログ調査 ⚫ M365侵害調査 ⚫ ログ調査AIエージェント開発ハッカソン