RubyGems.org AWSルートアクセス事案 – 2025年9月

• 2025年9月、Rubygems.orgのAWSルートアカウントに対する不正アクセス事案が発生
• 公開調査の結果、ユーザーデータや運用環境に毀損や露出の証拠はないことを確認
• 主な原因は、退職者の権限剥奪後もAWSルートアカウントのパスワードを即時変更しなかったことと、共有認証情報の管理不備
• 事案後、すべての認証情報とパスワードをローテーションし、セキュリティ監査を強化するとともに、外部監査と権限変更プロセスを改善
• 企業倫理、データプライバシー、透明なコミュニケーションを繰り返し強調し、コミュニティの信頼回復に向けた取り組みを明確化

---

概要と背景

Ruby Centralは2025年9月、Rubygems.orgのAWSルートアクセス侵害事案に関する公式ポストモーテム報告書を公開した。この文書では、事案の発生経緯、調査結果、不適切だった対応、そして今後のセキュリティ強化に向けた措置を透明性をもって整理している。

事案は、元管理者のAndré Arkoが、権限剥奪後もRubygems.orgの本番環境および監視ツールにアクセス可能であることが公開ブログで明らかにされたことから始まった。Ruby Centralは直ちにサービスの完全性とユーザーデータ保護に注力し、公に謝罪の意を表明した。

事案対応タイムライン

2025年9月30日の主な流れ

• 17:23 UTC: André Arkoが、自身にルートアクセスが可能である事実をメールで通知
• 17:30 UTC: 外部者のブログ投稿により、ルートアカウントアクセスとスクリーンショットが一般公開
• 17:51 UTC: Ruby Centralがインシデント調査チームを編成し、全サービスと認証情報の点検を開始
• 18:20 UTC: 既存パスワードが無効化されていた事実を確認
• 18:24 UTC: AWSルートアカウントのパスワードをリセットし、MFA認証でアカウントを回復
• 18:30 UTC: 「Credentials Report」の確認により、9月19日に非認可者がルートパスワードを変更していたことを確認
• 20:45 UTC: すべてのサブアカウントおよびレガシー認証情報を廃止し、MFAを再発行、新しい認証情報を独立した金庫に保管する措置を実施

事案の詳細な経過

Ruby Centralの全インフラはAWS上で運用されており、ルートアカウントの認証情報は、3名（現職2名、元職1名）のみがアクセス可能な共有金庫に保存されていた。

2025年9月18日

• 18:40 UTC: Arkoが、本番環境アクセスおよびオンコールサービス権限の剥奪通知をメールで受領
• Arkoが使用していたAWS認証情報は削除されたが、ルートアカウントのパスワードはローテーションされなかった

2025年9月19日 攻撃開始

• 04:34~04:39 UTC: サンフランシスコのIPから非認可者がルートログインし、パスワード変更、権限者グループ/ポリシーからの離脱、IAM全数調査を実施

2025年9月28日

• 05:49 UTC: 東京のIPから非認可セッションが発生し、IAMイントロスペクションAPIでユーザーメタデータを点検
• （Kaigi on Railsカンファレンスと時期が重なっており、同一人物と推定）

2025年9月30日

• 15:25~15:35 UTC: ロサンゼルスのIPからルートアクセスがあり、ユーザー認証情報取得コマンドを実行（ブログで共有されたスクリーンショットと一致）
• 18:24 UTC: Ruby Centralがルート制御を回復

影響と被害範囲

• 綿密なレビューの結果、ユーザーデータ、アカウント、gem、サービス可用性のいずれにも毀損の証拠はなし
• Rubygems.orgは事案の全期間を通じて正常稼働していた
• PIIや財務データなどの機微情報へのアクセスや流出はなかった
• 本番DB、S3、CI/CDに変更はなかった
• ただし、共有認証情報の未ローテーションと継続的なアクセス露出は重大な運用手続き上の欠陥だった

事案解決の過程

• すべてのルートおよびIAM認証情報を廃棄し、新しいMFAを適用
• 関連する外部連携（Datadog、GitHub Actionsなど）のトークンを全面ローテーション
• AWS CloudTrail、GuardDuty、DataDogを通じて重要な変更のリアルタイム監視を強化
• IAM権限構造を再検討し、不要権限を剥奪
• 外部専門家を含む包括的なセキュリティ監査を開始
• 新たなセキュリティ運用手順書を作成（人事異動時の即時パスワードローテーション、四半期ごとの点検、事案時のコミュニケーションプロセスを含む）

根本原因分析

• 共有パスワード管理が外部に複製されうる点を認識していなかった
• 退職者発生時にAWSルートパスワードとMFAをローテーションしなかった
• この2点により、非認可者がRubyGemsの本番インフラへアクセスし、アクセス権を巡る対立を試みる可能性が生じた

再発防止策

• アクセス剥奪手順とチェックリストを共有金庫管理まで拡張
• 非連動の認証情報（特に共有認証情報）は人事異動時に即時ローテーション
• 独立したセキュリティ監査を外部委託
• 誰に、どの条件で本番権限を付与するのかを明確にする運用者/貢献者合意を導入

セキュリティインシデントとして扱った理由

• 重要システムが単一人物の統制問題に起因していたため
• Mr. Arkoは二次オンコールサービスを年5万ドルの有償コンサルティングとして提供していたが、予算構造変更後、オンコールの無償提供と引き換えに本番HTTPログ（PIIを含む）へのアクセスおよび収益化機会を提案
• この提案はガバナンス・プライバシー・利益相反など本質的な問題を内包しており、Ruby Centralは受け入れられないと判断して、運用者構造およびガバナンス改革を進めた
• ArkoによるPIIを含むシステムへのアクセス継続が、決定的にセキュリティインシデントに分類される根拠となった
• 現時点でRubyGemsのデータが外部へ持ち出し・保管された証拠はなく、コミュニティの信頼回復と透明性向上を約束

結論

• コミュニティの支援と健全な牽制に感謝
• Ruby Centralは透明な運営、責任感、強固なセキュリティ体制によってRubygems.orgの安定性と信頼を今後も保証していく

Shan Cureton
Executive Director