1760062550
2025-10-09 17:48:00
標準的なインシデント対応業務の一環として、Ruby Central は次のインシデント後のレビューを一般公開しています。この文書は、2025 年 9 月の AWS ルートアクセス イベント、何が起こったのか、私たちが検証したこと、そしてセキュリティ プロセスを強化するために私たちが講じた措置を要約しています。。
9月30日には、 ブログ投稿 同月初めに複数のアカウントから管理アクセスが削除された後も、元メンテナーが RubyGems.org 運用環境にアクセスし続けているという懸念を提起した。私たちは、何が起こったのか、検証した範囲、何が間違っていたのか、今後のセキュリティ プロセスを強化するために講じた措置を含む、調査の結果を共有したいと考えています。
この状況が明らかになったとき、私たちが当面懸念したのは、RubyGems.org サービスとそのデータの完全性と安全性でした。私たちは、何百万もの開発者が毎日依存しているオープンソース インフラストラクチャを管理する責任を真剣に受け止めています。ユーザー データや本番運用が被害を受けたという証拠は見つかりませんでしたが、取り消されていない共有資格情報の存在と不明確なコミュニケーションが当然の懸念と不満を引き起こしたことを認識しています。誠に申し訳ございません。
インシデント対応タイムライン
2025 年 9 月 30 日
- 17:23 UTC: 元メンテナの André Arko は、Ruby Central のオープンソース ディレクターに電子メールを送信し、RubyGems.org 運用環境と関連する監視ツールにまだアクセスできると述べました。
注記： これは、Arko 氏によるこのアクセスに関する Ruby Central への最初で唯一の開示です。 - 17:30 UTC: Joel Drapper (Ruby Central とは無関係) が、 公開ブログ投稿 数分以内に、root アカウントへのアクセスを示すその日の初めに撮影されたスクリーンショットを使用して、このアクセスについて説明しました。
- 17:51 UTC: Ruby Central は、取締役会メンバーと OSS スタッフを巻き込んでレポートの真実性を検証し、インシデント チームを編成し、すべてのサービスと資格情報を列挙して、暴露範囲を評価し、完全な修復を保証します。
- 18:20 UTC: Ruby Central は緊急レビューを開始し、パスワード保管庫にある AWS ルート アカウントの既存の認証情報が無効であることを知りました。
- 18:24 UTC: Ruby Central は AWS パスワード リセット手順を開始し、多要素認証を検証し、AWS ルート アカウントの制御を取り戻します。
- 18:30 UTC: Ruby Central は、root アカウントにアクセスできなかった理由を理解するために AWS コンソールから「認証情報レポート」をダウンロードし、root アカウントのパスワードが 9 月 19 日 04:35 UTC に権限のない者によって変更されたことを知ります。
- 20:45 UTC: AWS CloudTrail ログ、DataDog アラート、および IAM 設定を検査した後、Ruby Central は、関連するすべてのサブアカウントとレガシー認証情報を特定して取り消し、残りのアカウントに新しい MFA トークンを発行し、新しいルート アクセス認証情報を Ruby Central の唯一の制御下にある安全なボールトに移行します。
イベントの分析
背景として、Ruby Central のインフラストラクチャはアマゾン ウェブ サービス (AWS) 上で実行されます。本質的に最高レベルの管理制御である root アカウントの資格情報は、共有保管庫内の共有エンタープライズ パスワード マネージャーに保存されており、そのアクセス権を持っていたのは 3 人 (現在の Ruby Central スタッフ メンバー 2 名と元メンテナーの André Arko 1 名) のみでした。
2025 年 9 月 18 日
- 18:40 UTC: Ruby Central は、Arko 氏に電子メールで、RubyGems.org の運用アクセスを削除するという委員会の決定と、オンコール サービスの終了を通知します。その移行中に、私たちのチームは本番システムにアクセスするために Arko 氏に属する AWS セキュリティ認証情報を削除しましたが、AWS ルート アカウントのパスワードを並行してローテーションすることに失敗しました。
2025 年 9 月 19 日
- 04:34 UTC: カリフォルニア州サンフランシスコの IP アドレスから発信された無許可の攻撃者が、AWS Rubygems.org AWS アカウントでルート アカウント セッションを開始します。
- 04:35 UTC: 権限のない攻撃者が root アカウントのパスワードを変更します。
注記： この時点以降、9 月 30 日に AWS ルート認証情報が Ruby Central によってリセットされるまで、AWS ルート アカウントに対して実行されるその後のアクションはすべて、無許可の攻撃者によって行われます。 - 04:37 UTC: 権限のない攻撃者は、権限のあるユーザーをグループから削除し、権限のある Rubygems.org AWS アカウント所有者の権限を削減するアクセス ポリシーを切り離します。
- 04:39 UTC: 権限のない攻撃者は、AWS アカウント全体の IAM 状態を迅速に列挙します。
2025 年 9 月 28 日
- 05:49 UTC: 日本の東京の IP アドレスから発信された無許可の攻撃者が、ルート アカウント セッションを開始し、IAM イントロスペクション API 呼び出しを使用して、ユーザーのグループ メンバーシップ、最終使用日、関連するアクセス トークンとポリシーの最終使用日を確認します。
注記： この不正アクセスは、 Kaigi on Rails カンファレンス 9月26日から27日まで東京でも開催されます。その結果、このアクセスは同じ不正行為者によるものであると考えられます。
2025 年 9 月 30 日
- 15:25 UTC: カリフォルニア州ロサンゼルスの IP アドレスから発信された無許可の攻撃者が、ルート アカウント セッションを開始します。
- 15:35:24 UTC: 権限のないアクターが発行した
PutCredentialsコマンドを使用してユーザー認証情報を取得します。これは、セキュリティの脆弱性を発表するブログ投稿で共有されたスクリーンショットと一致します。の ブログ投稿の主張 この行動はアルコ氏が行ったものだと。
- 18:24 UTC: 前に述べたように、Ruby Central は AWS パスワード リセット操作を実行して、root アカウントの制御を取り戻します。
注記： この時点以降、AWS ルート アカウントで実行されたすべてのアクションは、承認されたアクターによるものであると考えられます。
事件の規模
慎重な検討の結果、Ruby Central は安心して報告することができます。 証拠が見当たりません このセキュリティインシデントは エンドユーザーのデータ、アカウント、Gem、またはインフラストラクチャの可用性が侵害される。加えて：
- RubyGems.org は、全体を通じて完全に機能し続けました。
- RubyGems.org ユーザーの個人情報 (PII) や Ruby Central の財務データへのアクセスや転送は行われていません。
- 本番データベース、S3 バケット、CI/CD パイプラインは影響を受けませんでした。
それにもかかわらず、ローテーションされていない資格情報の存在と継続的なアクセスの一般公開は重大な手続き上の失敗であり、当社はそれをそのように扱っています。
事件はどのように解決されましたか?
AWS アカウントの制御を取り戻した後、Ruby Central は次のことを行います。
- 既存のルートおよび IAM 認証情報をすべて取り消しました、新しい MFA で保護されたアクセスを作成し、ユーザーごとの監査ログが含まれる制限されたコンテナーに移動しました。
- 関連するすべてのシークレットとトークンをローテーションしました、DataDog、GitHub Actions、その他の外部システム統合を含みます。
- AWS CloudTrail、GuardDuty、および DataDog アラートを有効にしました root ログイン、パスワード変更、または IAM 変更の場合。
- すべての IAM ロールとポリシーを確認しました 最小限の特権アクセスを確保し、従来の権限を削除します。
- 完全なエンドツーエンドのセキュリティ監査を開始 外部アドバイザーと連携し、インフラストラクチャ、認証情報の保管、インシデント対応手順をカバーします。
- Ruby Central Security Runbook を更新しました 人事や役割の変更時のパスワードとキーの即時ローテーション、四半期ごとの認証情報のレビュー、将来のインシデントに備えた調整されたコミュニケーション手順を含めます。
根本原因の分析
事後検証の結果、セキュリティ インシデントの根本原因は次の 2 つであることがわかりました。
- Ruby Central は、インシデントが発生する前にエンタープライズ パスワード マネージャーを通じて共有資格情報へのアクセスを正しく削除していましたが、当社のスタッフは、この資格情報が Ruby Central の可視性や制御の範囲外にある他のパスワード マネージャーにコピーまたは流出した可能性を考慮していませんでした。
- Ruby Central は、共有コンテナーにアクセスできる担当者が退職した後、AWS ルート アカウントの認証情報 (パスワードと MFA) をローテーションできませんでした。
これらの両方のイベントにより、権限のない攻撃者が RubyGems.org の運用インフラストラクチャにアクセスできるようになり、権限のある担当者をロックアウトして復旧作業を挫折させようとしましたが失敗しました。
将来のインシデントを防ぐために私たちは何をしていますか?
RubyGems.org は Ruby コミュニティ全体が依存する重要なサービスであり、私たちはその責任を真剣に受け止めています。 RubyGems.org が成功するには、ほぼ完璧な運用稼働時間を維持するだけでなく、専門的に運営されていること、運営者が世界中の何百万もの Ruby アプリケーションに提供するデータとコードの両方の整合性を証明できること、そして当社が保持するデータのプライバシーが損なわれていないことについてコミュニティの信頼を獲得する必要があります。
そのために、私たちは次の改善に取り組んでいます。
- アクセス取り消し手順とチェックリストを更新して、Ruby Central エンタープライズ パスワード マネージャーへのアクセスも確実に取り消されるようにします。
- アクセス取り消し手順を更新して、人事異動後に非フェデレーション資格情報 (特に共有資格情報) が迅速にローテーションされるようにします。
- 手数料 独立したセキュリティ監査 Ruby Central のシステムとアクセスの詳細。
- 正式なオペレーターおよびコントリビューター契約を最終決定して、誰がどのような条件で本番アクセスを保持できるかを明確に定義します
Ruby Central はなぜこのイベントをセキュリティ インシデントとして扱ったのでしょうか?
最近の取り組みの一環として私たちは、多くの RubyGems.org システムが 1 人の個人によって制御されていると判断しました。これほど重要なサービスにとっては耐え難い状況です。
オペレーターおよびコントリビューター契約を通じて本番環境へのアクセスを正式にするという決定についてコミュニティに追加のコンテキストを提供し、このインシデントを本物のセキュリティ イベントとして扱った理由を説明するために、9 月 18 日のアクセス変更に至るまでの Arko 氏と Ruby Central 担当者の会話のコンテキストを共有します。
2025 年 8 月初旬、Ruby Central はオープンソース請負業者の予算の見直しを開始し、2024 年には総額約 762,000 ドルになりました。オンコール対応は RubyGems.org のようなサービスにとって非常に重要であり、運用の継続性と運用インシデントへの迅速な対応を確保することができます。すべてのオンコール シフトには、インシデントへの対応に直接責任を負うプライマリと、必要に応じてバックアップおよびエスカレーション ポイントとして機能するセカンダリがいます。
RubyGems.org の場合、バックアップ層として機能する 2 番目のオンコール ローテーションがアクティブになることはほとんどありませんでした。 Ruby Central の長期的な目標は、この限られた有料機能を、追加コストなしで責任を分担できるボランティア オペレーターの分散ネットワークに移行し、運用の継続性と財務上の持続可能性の両方を確保することでした。
これらの予算調整を受けて、二次オンコール サービスの提供に対して年間約 50,000 ドルを受け取っていたアルコ氏のコンサルタント会社は、IP アドレスやその他の個人識別情報 (PII) を含む実稼働 HTTP アクセス ログへのアクセスと引き換えに、二次オンコール サービスを無料で提供するという提案を提出しました。この申し出により、アルコ氏のコンサルタント会社はそのデータにアクセスできるようになり、アクセスパターンを分析し、無関係な第三者と共有することで収益化できるようになる。
取締役会とリーダーシップチームは、この提案は重要な倫理的および法的境界を越えており、エコシステムの管理者としての Ruby Central の責任に矛盾するプライバシー、利益相反、ガバナンス上の懸念を導入していると判断しました。これらの懸念が動き出し、新しい運用モデルとガバナンス構造を採用するという Ruby Central の決定について詳しく説明しました。 このブログ投稿で。このような状況を念頭に置き、Arko 氏が PII を含む実稼働システムへのアクセスを保持していたことを発見したとき、私たちはそれをセキュリティ インシデントとして考慮し、直ちに対応する必要がありました。
私たちの予備調査に基づくと、この投稿の公開時点では、RubyGems.org のデータが Arko 氏を含む無許可の当事者によってコピーまたは保持されたことを示す証拠はありません。
私たちは、これらの出来事がコミュニティ内で正当な疑問を引き起こし、Ruby Central が管理者としての役割をどのように果たすかについての信頼を試されたことを認識しています。このレベルの詳細を共有する私たちの目的は、何が起こったのか、何を学んだのか、再発を防ぐために何をしているのかを透明にすることです。このオープン性が、当社の管理責任に対する信頼を再構築し、当社が Ruby エコシステムにサービスを提供する方法の中心であり続けることを実証するための有意義な一歩となることを期待しています。
私たちは、私たちに責任を負わせ、このプロセス中に示された忍耐とプロフェッショナリズムに対してコミュニティに深く感謝しています。 Ruby Central は、RubyGems インフラストラクチャの透明性と責任ある管理、および Ruby エコシステムが依存するセキュリティと信頼の維持に引き続き取り組んでいます。
心から、
シャン・キュアトン
常務取締役
#Rubygems.org #AWS #ルート #アクセス #イベント #年 #月