ハクソク

世界を動かす技術を、日本語で。

Rubygems.org AWSルートアクセスイベント – 2025年9月

2025年10月10日原文(rubycentral.org)

概要

  • 2025年9月に発生した AWS rootアクセスインシデント の詳細な経緯と対応策の公開
  • 元管理者による RubyGems.org本番環境へのアクセス問題 の発覚と調査
  • ユーザーデータや運用への影響なし と確認済み
  • インシデントの原因分析と 再発防止策の導入
  • Ruby Centralによる 透明性確保と信頼回復への取り組み

2025年9月AWS rootアクセスインシデントの事後レビュー

  • 2025年9月30日、元管理者の André Arko氏 がRubyGems.org本番環境へのアクセスが可能であることをRuby Centralに報告
  • 同日、 Joel Drapper氏 がrootアカウントアクセスの証拠を含むブログ記事を公開
  • Ruby Centralは即座に インシデント対応チームを結成、全サービスと認証情報の調査・確認を実施
  • AWS rootアカウントのパスワードが 2025年9月19日に不正に変更 されていたことを発見
  • AWS CloudTrailやDataDogアラート、IAM設定の調査 により、不正アクセス経路と影響範囲を特定
  • すべてのroot/IAM認証情報の 無効化と再発行、MFA強化、監査ログ付きの安全な保管 を実施
  • 外部専門家を交えたセキュリティ監査 を開始

インシデントの経緯と分析

  • Ruby Centralのインフラは AWS上で運用、root認証情報はエンタープライズパスワードマネージャーで共有管理
  • 2025年9月18日、 André Arko氏のアクセス権削除 を通知し、個別AWS認証情報は削除したが rootパスワードの変更を失念
  • 9月19日以降、 米国・日本・ロサンゼルスからの不正rootアクセス を複数回検知
  • 不正アクセス者による ユーザーグループからの削除や権限剥奪、IAM情報の列挙 を確認
  • 9月30日、Ruby Centralが rootアカウントを緊急復旧 し、以後は正規管理下に移行

インシデントの影響範囲

  • ユーザーデータ、アカウント、gems、インフラ稼働状況に影響なし
  • RubyGems.orgは 終始稼働を維持
  • PIIや財務データへのアクセス・流出なし
  • 本番DB、S3、CI/CDパイプラインへの影響なし
  • 認証情報の未ローテーションと情報公開の遅れ が重大な手順上の失敗

インシデント解決のための対応

  • すべての root/IAM認証情報の無効化・再発行・MFA化・厳格な保管
  • DataDogやGitHub Actionsなど 関連シークレット・トークンのローテーション
  • AWS CloudTrail・GuardDuty・DataDogアラート によるroot操作の監視強化
  • 全IAMロールとポリシーの 最小権限化とレガシー権限の削除
  • 外部監査人によるフルセキュリティ監査 の実施
  • セキュリティ運用手順書の 即時パスワード・鍵ローテーション、四半期ごとの認証情報レビュー、連絡体制の明文化

根本原因の分析

  • エンタープライズパスワードマネージャーからのアクセス削除後も、認証情報が外部にコピーされていた可能性 を考慮せず
  • rootアカウントのパスワード・MFA未ローテーション
  • これらにより不正アクセス者が 本番インフラに侵入し、正規管理者の排除や復旧妨害を試行

再発防止策

  • アクセス権剥奪時の手順・チェックリストの見直し、パスワードマネージャーへのアクセスも即時停止
  • 非連携型の認証情報（特に共有認証情報）の即時ローテーション
  • 外部専門家による独立したセキュリティ監査の実施
  • 正式なOperator/Contributor Agreementの策定、本番アクセス権限の範囲と条件の明確化

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

  • 多数のRubyGems.orgシステムが 単一個人の管理下 にあったことを問題視
  • 運用アクセス権の正式な合意書による管理体制への移行 を決定
  • 2025年8月、 Ruby Centralが約$762,000のオープンソース契約予算を見直し
    • RubyGems.orgの二次オンコール業務を 有償からボランティア運用へ移行 方針
    • Arko氏のコンサルタントから PII含むHTTPアクセスログと引き換えに無償で継続 の提案
    • これが プライバシー・利益相反・ガバナンス上の懸念 となり却下、運用体制の抜本的見直しへ
  • Arko氏が PII含む本番システムへのアクセスを保持していた事実 が発覚し、即時セキュリティインシデントとして対応

まとめと今後の方針

  • 現時点でユーザーデータの不正取得や流出の証拠はなし
  • コミュニティの 信頼回復と透明性向上 に向け、詳細な情報公開と再発防止策の徹底
  • Ruby Centralは 運用・データ・プライバシーの安全性担保 と プロフェッショナルな管理体制の維持 を最優先

上記の内容は、Ruby Centralが インシデント対応の透明性 と コミュニティへの説明責任 を果たすためにまとめたものです。

Hackerたちの意見

リードを埋めちゃったね… アルコは、彼のコンサルタント会社がデータをマネタイズできるように、rubygems.orgのHTTPアクセスログのコピーが欲しかったんだ。RCが二次的なオンコールの予算がないって判断した後にね。それから、彼がメンテイナーを外された後にログインしてAWSのルートパスワードを変更したんだ。

└

本当にすごい状況だね。ある意味、この投稿はRCがなぜそんなに所有権を持ちたがったのかを正当化してると思う。つまり、ユーザーデータを売ってお金を稼ごうとしてるメンテナがいるわけで。でも、アクセス権を取り消す際のひどいコミュニケーションと初心者のミスが、今後のサービスのセキュリティに対する信頼を損なってる。法律的に「rubygemsリポジトリ」を誰が所有してるのか（インフラだけじゃなく）や、なぜそれを主張する権利があると思ったのかの説明もないし、「他の」側と争ってることなんだよね。全体的にめちゃくちゃで、誰も良い印象を持てないよ！

AWSルートアカウントの認証情報を回転させるのに失敗した… 共有の企業パスワードマネージャーに保存されている 残念ながら、多くの企業は、以前アクセスしていた従業員が退職した際に、共有のパスワードマネージャーに保存された認証情報を回転させずにそのままにしておくという悪い習慣を続けている。

アルコが不正アクセスの犯人でなかったとしても、これで彼のキャリアはずっと傷つくことになるね。メールの件は別としても。コンサルタントを運営するには最悪のタイミングだよ。彼の他の顧客は今、何を考えているんだろうね。

言語パッケージレジストリのAWSアカウントルートアクセスが11日間もあったんだ。EC2のルートじゃなくて、AWSアカウントのルートだよ。IAM、S3、CloudTrail、すべてを完全にコントロールできる。彼らは「侵害の証拠はない」と主張してるけど、CloudTrailのログはAWSルートが削除したり変更したりできるものだよ。しかも、彼らは「制御を取り戻した後にAWS CloudTrailを有効にした」と認めてるから、侵害の間はCloudTrailが動いてなかったってことだ。ルートが侵害されたシステムのログからサプライチェーンの整合性を確認することはできないし、ログが存在しなかったときにはさらに確認できない（彼らは修復中に有効にしたの？）。だから、もし間違ってたら誰か訂正してほしいけど… 9月19日から30日に公開されたすべてのgemは疑わしいよ。その期間に動いている本番のRubyアプリケーションは、バックドアが仕掛けられていないことを確認する手段がない。正しい対応は、公開を凍結して、ゼロから再構築すること（当時公開されたパッケージも再公開する必要があるのかな？うーん、どうやってやるのかも分からない！）で、オフラインバックアップと照合することだよ。でも、彼らはパスワードを回転させただけで終わらせたんだ。

└

個人的には、完全な再構築を避ける唯一の方法は、アンドレ・アルコに次のことを認めさせることだと思う：1. 彼が不正な行為者だったことを認める（つまり、犯罪を認めることになる？） 2. 犯罪を犯している間にサービスの整合性を外部に流出させたり変更したりしていないと証言させる。もし私がRuby Centralなら、#1については寛大に対応して、#2を条件にすると思うし、#2はアンドレ・アルコにとっても助けになると思う。

└

もう少し考えてみると… 競合プロジェクトの立ち上げのタイミングで、何かが起こって前の incumbents に対する信頼が完全に損なわれる可能性があるって、確かに面白いよね？おかしい！

└

投稿の文脈を考えると、「AWS CloudTrail、GuardDuty、DataDogのアラートを有効にした」というのは、「CloudTrail、GuardDuty、Datadogを通じてアラートを有効にした」という意味で、「CloudTrailのログを有効にした」というわけではないみたい。そうじゃなきゃ、CloudTrailを見直すっていうコメントが意味不明になっちゃうよね。

└

確かにその通りだね、前は考えたことなかったよ。他の誰も改ざんしてないってどうやって確認するの？RubyCentralはこれを完全に考え抜いてなかったみたいだね。

└

確か、AWS CloudTrailを有効にしたり無効にしたりはできないよね？トレイルの永続的な保存を有効にすることはできるけど、それが有効になっていても、90日間のイベントには常にアクセスできるよ。

└

CloudTrailのログはデフォルトで過去90日間が有効になっていて、オフにすることはできず、ルートでも変更できないよ。もしこの「イベント」をArkoのアクセスが終了するはずだった時から始まると考えるなら、それは90日間のウィンドウ内にあって、その期間のログは確かに信頼できるよ。

└

記事を読む気はないけど、AWSの推奨は、組織内にCloudTrailログだけを保持する別のセキュリティアカウントを持つことだよ。これだとコストが倍になる可能性があるけど、無料のCloudTrailは一つだけだし、デバッグ目的でアカウント内のトレイルを持つのはすごく便利なんだ。組織を使うと、ルートユーザーに対しても広範囲な活動を拒否するSCPをアカウントに付けられるから便利だよ。

Hacker Newsで議論の続きを見る