CircleCIでサプライチェーンセキュリティインシデント発生：シークレットをローテーションしましょう

1月4日、自動CI/CDパイプライン構築ツールのCircleCIが、アドバイザリーを公開し、製品で発生したセキュリティインシデントを報告しました。

CircleCIのインシデントの背景

12月27日、セキュリティエンジニアのDaniel Hückmann氏は、自身が設置したAWS CanaryTokenのおかげで、CircleCIアカウントへの不正侵入の可能性を知らせるメール通知を受け取りました。AWSキーの形をしたこのおとりは、攻撃者によって起動された可能性が高いと考えられます。ハニートークンとも呼ばれるおとりは、侵入を調査・検知するためにシステムに設置でき、攻撃者が起動すると、セキュリティ侵害の可能性を知らせます。

2022年1月4日、CircleCIはセキュリティインシデントへの対応として、顧客にシークレットをローテーションするよう呼びかけました。

透明性を確保するためにお伝えすると、SnykはCircleCIのパートナーであり、顧客でもあります。

CircleCIがユーザーに推奨する対応

CircleCIは、プロジェクトの環境変数やコンテキストなど、プラットフォームに保存されているすべてのシークレットを直ちにローテーションするよう、全ユーザーに推奨しています。また、2020年12月21日から2023年1月4日までの期間、またはシークレットのローテーション完了後に、不正アクセスがなかったかどうか、内部ログを確認するよう呼びかけています。CircleCIは、個人用およびプロジェクト用のAPIトークンを無効化し、GitHubとBitbucketのすべてのOAuthトークンをローテーションしました。

ソフトウェア開発やインフラ環境に携わっている方は、シークレットのローテーションが難しく、CI/CDワークフローに支障をきたす可能性があることを理解しておく必要があります。次の対応を検討してください。

• コンテキストレベルとプロジェクトレベルの両方に保存されているものを含め、すべてのプロジェクトとパイプラインで使用している環境変数を一覧にまとめます。

• CircleCIからシークレットを削除せず、失効させて、悪意のある第三者によるアクセスを防ぎましょう。

• 環境変数とSSHキーを必ずローテーションしましょう。

シークレットの散在がソフトウェアサプライチェーンに及ぼす影響

パスワードやAPIキーなどのシークレットを複数の場所に保存することは「シークレットの散在」と呼ばれ、効果的な管理や保護を難しくします。これは組織内だけでなく、ソフトウェアサプライチェーンでも起こり得ます。シークレットがさまざまな場所に散在していると、追跡や更新が難しくなり、不正アクセスのリスクが高まります。また、定期的にローテーションされない長期間有効な権限、いわゆる静的シークレットの使用も問題です。

シークレット管理プラットフォームを使えばシークレットを効果的に保存・暗号化できますが、静的シークレットには依然として脆弱性があります。アプリケーションのソースコードに平文で含まれていたり、アプリケーションログに記録されたり、設定ファイルに保存されたりすると、漏えいする可能性があります。シークレットを使う頻度が高いほど、侵害されるリスクも高まります。さらに、静的シークレットは複数のシステムにわたって永続的な権限を付与し、攻撃者にインフラへの継続的なアクセスを許してしまう可能性があります。

共有され、広く使われている静的な認証情報には、いくつかの問題が伴います。明確な所有者がいないこと、サービス廃止後も古い認証情報が削除されずに残ること、定期的なローテーションの仕組みがないこと、有効期限やTTLが設定されていないこと、そして、有効期間の短い動的トークンなど、より安全なアクセス制御方式が利用できるにもかかわらず、静的な認証情報が不必要に使われていることなどです。

サプライチェーン攻撃では、攻撃者が企業のサプライチェーンに侵入し、システムやデータへのアクセスを試みます。セキュリティ対策を回避して機密情報にアクセスできるため、特に危険です。攻撃者は多くの場合、ソースコードやビルドプロセスを侵害したり、悪意のある活動を実行したり、サプライチェーンの下流でさらなる侵害を引き起こしたりします。

組織はシークレットの散在に伴うリスクを認識し、サプライチェーン攻撃を防ぐための対策を講じることが重要です。ソフトウェア製品は、多くの場合、さまざまなベンダーから調達され、別々のリポジトリに保存された複数のコンポーネントで構成されています。攻撃者がアクセスできれば、マルウェアを埋め込み、サブコンポーネントに署名することで、サプライチェーンを流通する際に信頼できるものとして扱われるようにする可能性があります。

こうした問題に対処するには、暗号化された保管庫を備えたシークレット管理ソリューションを使い、認証情報やキーを保護できます。このソリューションは、セキュリティチームが承認したポリシーに従って、必要なシークレットに開発者が簡単にアクセスできるワークフローも提供する必要があります。さらに、キーや認証情報を保護するため、シークレットを簡単にローテーションできることも重要です。

動的シークレットとは、必要に応じて生成され、限られた期間、限られた権限でリソースへの一時的なアクセスを提供する認証情報です。保存されないため、攻撃を受けにくくなります。動的シークレットが侵害されたとしても、サイバー犯罪者が利用する前に無効になります。動的シークレットは、ゼロ・スタンディング・プリビレッジ（ZSP）と組み合わせて使われることがよくあります。これは、特定のタスクを完了するために必要な最小限の権限のみを、必要最小限の期間だけクライアントに付与する仕組みです。このアプローチは、不正アクセスのリスクを低減し、必要なときにのみ権限が付与されるようにします。

シークレットをローテーションする方法

シークレットのローテーションとは、侵害されるリスクを低減するため、既存のシークレット（パスワード、APIキー、SSHキーなど）を新しいものに置き換えることです。使用するシステムに応じて、手動または自動で実施できます。

シークレットのローテーションには、いくつかの方法があります。

• 定期的に実施：一定の間隔でシークレットをローテーションするスケジュールを設定できます。攻撃者が悪用を試みられる時間が限られるため、シークレットが侵害されるリスクを低減できます。

• 必要に応じて実施：シークレットが侵害された可能性があると疑われる場合や、侵害のリスクを事前に低減したい場合にも、シークレットをローテーションできます。

• 自動化：ツールやスクリプトを使って、シークレットのローテーションを自動化できます。これにより、シークレットを一貫して迅速にローテーションできます。

シークレットをローテーションする際は、新しいシークレットが適切に保護され、正しく実装・設定されていることを確認することが重要です。また、システム管理者やユーザーなど、関係者に変更を伝える必要があります。

シークレット管理戦略を見直す

これまでシークレットは安全だと考えていたかもしれません。しかし、プラットフォームが侵害された過去の事例を受け、組織はシークレットの保存戦略を見直し、最も安全な方法を検討するようになりました。シークレットは一度使用してコミットすると、もはやシークレットではありません。このため、シークレットを管理する最善の方法は何でしょうか。そもそも使用しないべきでしょうか。それとも一度だけ使用して失効させるべきでしょうか。

新たな情報が判明した場合は、この記事を更新します。