Salesforce が Heroku の OAuth トークン管理を開発者プラットフォームの説明責任テストに

要約

• Heroku の2022年の GitHub 統合インシデントが重要なのは、OAuth トークンが通常のパスワードではなく、ソースリポジトリ、デプロイパイプライン、ビルドシステム、顧客アプリケーション、そして下流のソフトウェア利用者をつなぐことができる委任された権限であるからです。
• GitHub は、攻撃者が Heroku と Travis CI に発行された OAuth ユーザートークンを盗用したと公開警告しました。一方、Heroku のインシデントコミュニケーションでは、調査、失効、クレデンシャルリセットが進展するにつれて、顧客はローテーションのガイダンスに従う必要がありました。
• 説明責任の問題は、Heroku が最終的にキーをローテーションしたり統合を復元したりしたかどうかだけではありません。誰がトークン管理、顧客通知、GitHub アプリケーションの動作、ソースコードアクセスの証拠、CI/CD の信頼境界、そしてインシデント後の証明を管理していたかです。
• この記事は、Heroku、GitHub、Travis CI、Salesforce、IETF、NIST、CISA、MITRE の情報源を別々の証拠レーンとして扱います。公開情報源のいずれも、完全な内部フォレンジック記録としては扱いません。
• 永続的な教訓は、開発者プラットフォームの利便性には管理台帳が伴わなければならないということです。どの統合トークンが存在するか、なぜ存在するか、どのスコープを持つか、どこに保存されているか、誰がそれを失効させることができるか、そしてトークンが疑わしい場合に顧客がどのような証拠を受け取るかです。

この事例がリスクと説明責任ファイルに属する理由

Salesforce は、Heroku の OAuth トークン管理を開発者プラットフォームの説明責任テストとしたのは、Heroku が管理型開発者プラットフォームであり、その価値がコード、デプロイ、アイデンティティ、運用の境界における信頼に基づいているからです。顧客は Heroku を使用して、アプリケーションをソースリポジトリに接続し、コードをデプロイし、ビルドフローを自動化し、チームを管理し、アドオンを追加し、データサービスをアタッチし、本番ワークロードを運用します。したがって、Heroku と GitHub の統合は表面的な便利さではありません。顧客のソースコードシステムからデプロイプラットフォームへ、そしてデプロイプラットフォームから顧客の運用リスクへとつながる架け橋となり得ます。

2022年の公的な引き金は、GitHub がhttps://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/でセキュリティアラートを公開し、Heroku と Travis CI に発行された OAuth ユーザートークンが盗まれたことを説明したため、可視化されました。Heroku 自身のステータスインシデントページhttps://status.heroku.com/incidents/2413と Heroku の2022年4月のインシデントレビューhttps://blog.heroku.com/april-2022-incident-reviewは、プラットフォーム側から問題を提示しています。Travis CI のセキュリティ速報https://www.travis-ci.com/blog/2022-04-15-security-bulletin/は、別の影響を受けた統合レーンを提供します。これらの情報源は公の輪郭を確立しています。すなわち、開発者ワークフローに関連する OAuth トークン、顧客通知、調査の更新、そして一連の保護措置です。

この事例が重要なのは、OAuth が説明責任の形を変えるからです。盗まれたパスワードは多くの場合、単一のユーザーアカウントで説明できます。盗まれた OAuth トークンは、ユーザーが最後に同意を考えた瞬間を超えて存続する委任された権限を表す可能性があります。リポジトリへのアクセス、自動化ワークフローへのアクセス、API スコープ、メタデータへのアクセス、組織メンバーシップへの影響、またはデプロイ権限を含む場合があります。IETF OAuth 2.0の資料https://datatracker.ietf.org/doc/html/rfc6749と OAuth セキュリティのベストカレントプラクティスhttps://datatracker.ietf.org/doc/html/rfc9700は Heroku に関するインシデント報告ではありませんが、トークンの発行、スコープ、保存、ローテーション、失効、リプレイ耐性、クライアントの信頼がなぜ重要かを定義するのに役立ちます。

説明責任ファイルは、Heroku、Salesforce、GitHub、Travis CI、顧客を一つの主体に平坦化すべきではありません。Salesforce はビジネスおよびブランドとして Heroku を所有していました。Heroku はプラットフォーム統合の設計、顧客コミュニケーション、プラットフォーム内のクレデンシャル処理、公開できる証明を管理していました。GitHub は自身の調査、トークン失効、ソースホストの証拠、OAuth アプリケーション管理、顧客向けセキュリティアラートを管理していました。Travis CI は影響を受けた統合チャネルと顧客向けガイダンスを管理していました。顧客は自身のリポジトリ権限、デプロイの選択、シークレットのローテーション、監査レビュー、指示への対応を管理していました。下流のソフトウェア利用者は、ソースコードへのアクセスやデプロイの信頼が後に露出を引き起こした場合、リスクを負っていました。

この役割マップが重要なのは、開発者プラットフォームが共通の責任を生み出す一方で、必ずしも共通の証拠を提供しないからです。Heroku の顧客はクレデンシャルをローテーションしたりリポジトリを検査したりするように指示されるかもしれませんが、Heroku 側のトークン保存パスや GitHub 側の攻撃者の行動を独立して再構築することはできませんでした。GitHub ユーザーは OAuth アプリケーションを失効させることはできましたが、どの Heroku デプロイパイプライン、アプリケーション、チームが交換アクセスを必要としているか分からないかもしれません。調達責任者はプラットフォームが引き続き許容可能かどうかを尋ねることができますが、その判断は全てが公開されているわけではない技術的詳細に依存します。したがって、説明責任の問題は証拠の割り当てです。すなわち、各主体は何を知っていたか、何を証明できたか、不確実性が続く間に顧客は何をしなければならなかったかです。

公の記録はまた、開発者ツールのインシデントがなぜアカウントセキュリティの説明責任だけでなく、ソフトウェアサプライの説明責任に属するかを示しています。ソースコードへのアクセスは、アプリケーションセキュリティ、シークレット、CI/CD ジョブ、ビルド成果物、デプロイクレデンシャル、製品リリースの上流に位置します。MITRE ATT&CK のアプリケーションアクセストークン手法https://attack.mitre.org/techniques/T1528/と代替認証素材手法https://attack.mitre.org/techniques/T1550/は、トークンの悪用を通常のクレデンシャル推測と区別するための有用な語彙です。CISA のセキュアバイデザイン資料https://www.cisa.gov/securebydesignと NIST のセキュアソフトウェア開発フレームワークhttps://csrc.nist.gov/pubs/sp/800/218/finalは、ソースコード管理とビルドシステムの信頼がなぜ本番管理として扱われなければならないかを説明するのに役立ちます。

この記事は、Heroku のプライベートログ、GitHub のプライベートリポジトリ監査データ、Travis CI の内部記録、顧客ごとの通知、法執行機関との通信、または Salesforce の取締役会資料へのアクセスを主張するものではありません。公開ファイルを使用して、証拠が実用的な管理を可視化したかどうかを問います。強力な説明責任記録は、トークンが失効されたことだけでなく、不審な活動がいつ検出されたか、どのスコープが関与していたか、どの顧客が行動を必要としたか、どのリポジトリアクセスが確認または除外されたか、どのシークレットが露出した可能性があるか、クレデンシャルがいつローテーションされたか、そして同じトークン管理パスが黙って繰り返されないように何が変更されたかを示すでしょう。

OAuth 同意は最初のクリック後に管理となる

多くの OAuth レビューにおける最初の運用上の間違いは、同意を一度限りのユーザー判断として扱うことです。開発者プラットフォームでは、同意は管理になります。ユーザーがアプリケーションにリポジトリへのアクセスを許可すると、プラットフォーム、アイデンティティプロバイダー、ソースコードホスト、顧客管理者はすべて継続的な義務を負います。トークンにはライフサイクルがあります。発行され、保存され、更新され、使用され、ログに記録され、スコープされ、失効され、置き換えられ、最終的に忘れられるか廃止されます。Heroku のインシデントが重要なのは、公開記録が、信頼の判断がすでに開発ワークフローに組み込まれた後に顧客にそのライフサイクルについて考えさせたからです。

GitHub の現在の OAuth ドキュメントhttps://docs.github.com/en/apps/oauth-appsと OAuth アプリ管理ガイダンスhttps://docs.github.com/en/apps/oauth-apps/maintaining-oauth-appsは、OAuth アプリケーション、クライアントシークレット、コールバック URL、所有権、アプリケーション管理に関する管理語彙を示すので有用です。GitHub のエンタープライズ監査ログガイダンスhttps://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/about-the-audit-log-for-your-enterpriseは、疑わしい統合イベントの後に組織が活動証拠を必要とする理由を示しています。Heroku の GitHub 統合ドキュメントhttps://devcenter.heroku.com/articles/github-integrationは、顧客に表示される機能面を示しています。これらの文書のいずれも、2022年に何が起こったかを正確に証明するものではありません。それらは顧客が保護しなければならなかった運用面を確立します。

管理とは、プラットフォームが通常の稼働時間とは異なる一連の質問に答えなければならないことを意味します。OAuth トークンはどこに保存されていたか？リフレッシュトークンまたはアクセストークンが関与していたか？それらは暗号化され、分割され、テナントごとに分離されていたか？どのサービスまたはデータベースがそれらを読み取ることができたか？どの監視が異常な使用を示すか？誰がそれらを失効させることができたか？失効後に顧客のどのような行動が必要だったか？Heroku は顧客の更新された同意なしに GitHub からデプロイできたか？ビルド時のシークレット、設定変数、リポジトリ内容、デプロイキーがリスクにさらされていたか？これらの答えのうち、最初の通知時にどれがわかっていて、どれがまだ調査中だったか？

これらの質問は敵対的ではありません。それらは信頼の基盤です。開発者プラットフォームはトークンを保存する正当な理由を持つことができますが、その理由は保護の証拠と対になっていなければなりません。プラットフォームはトークンを迅速に失効させることができますが、失効の証拠は顧客の指示と対になっていなければなりません。プラットフォームは Heroku ユーザーパスワードや API キーのローテーションを要求することができますが、顧客はなぜそのローテーションが必要で、リポジトリの検査も必要かどうかを知る必要があります。プラットフォームは一部のユーザーに対して顧客の行動は不要と言うことができますが、その声明は技術的な境界に結びつけられるべきです。

Heroku の公開記録には、進化する顧客指示が含まれていました。その進化は自動的に失敗ではありません。インシデント対応は多くの場合、疑念から確認へと段階を経ます。説明責任の問題は、顧客が推測することなく従えるように段階が十分に可視化されているかどうかです。顧客への最初のメッセージが一つのことを述べ、後のメッセージがより広範な行動を要求する場合、プラットフォームはどの証拠が変わったかを説明すべきです。顧客がクレデンシャルをローテーションするように指示された場合、指示はどのクレデンシャル、どの期限、どのアプリケーションコンテキスト、そして顧客が確認すべきログを特定すべきです。

経済的側面は現実的です。開発者チームは、手動デプロイとクレデンシャル管理がコストがかかるため、迅速な統合に最適化します。OAuth アプリは摩擦を減らします。しかし、プロバイダー側の管理パスが失敗すると、利便性のコストは緊急労働として再表面化します。すなわち、リポジトリのレビュー、シークレットのローテーション、統合の再構築、ログの検索、顧客への露出の説明、監査人への対応です。したがって、開発者ツールの経済学はこの記事のトピックリストに属します。容易な統合から利益を得るプラットフォームは、管理、失効、証拠に投資しなければなりません。

ソースコードへのアクセスは本番環境の侵害と同じではないが、無害でもない

公開記録は二つの悪い単純化に抵抗しなければなりません。一つ目は、盗まれた OAuth トークンは自動的に本番アプリケーションが侵害されたことを意味すると言うことです。二つ目は、本番停止が発生しなければソースコードへのアクセスは無害だと言うことです。どちらの声明も弱いものです。ソースコードには、アプリケーションロジック、依存関係情報、内部エンドポイント、デプロイスクリプト、設定パターン、テストフィクスチャ、コメント、古いシークレット、インフラストラクチャ名、セキュリティ前提が含まれる場合があります。同時に、ソースコードへのアクセスだけではランタイムアクセス、データ盗難、デプロイ操作を証明するものではありません。

GitHub のアラートと Heroku のインシデントコミュニケーションが重要なのは、ソースコードアクセスリスクを公開ファイルに置いたからです。接続されたリポジトリを持つ顧客は、攻撃者がプライベートリポジトリを読めるかどうか、リポジトリにコミットされたシークレットがあるかどうか、GitHub 外にデプロイクレデンシャルが存在するかどうか、GitHub Actions、Heroku パイプライン、レビューアプリ、CI ジョブが追加の素材を露出させたかどうか、リポジトレベルの監査ログに異常なアクセスが示されたかどうかを知る必要がありました。顧客が Travis CI を使用していた場合、同じ質問は CI 環境変数とビルドログに拡張される可能性があります。

NIST SP 800-218https://csrc.nist.gov/pubs/sp/800/218/finalは、セキュアソフトウェア開発をコード作成だけでなくライフサイクルとして扱うため有用です。NIST SP 800-204Dhttps://csrc.nist.gov/pubs/sp/800/204/d/finalは、クラウドネイティブアプリケーションセキュリティとサービスアイデンティティの質問を枠組みするのに役立ちます。NIST SP 800-53 Rev. 5https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/finalは、アクセス制御、監査、構成、インシデント対応、システム整合性のための管理語彙を提供します。これらの資料は Heroku 固有の調査結果ではありません。それらは、開発者プラットフォームのインシデントをソフトウェアサプライイベントとしてレビューすべきかどうかを判断するためのベンチマークです。

重要な境界は証明です。プラットフォームが OAuth トークンが特定のリポジトリまたは顧客セットにのみ使用されたと判断できる場合、その判断の根拠を説明すべきです。ログの制限により顧客ごとのアクセスを判断できない場合は、その旨を述べるべきです。GitHub がトークンの使用またはリポジトリアクセスに基づいて影響を受けるユーザーに通知できる場合、公開記録はその通知が何を意味し、何を意味しないかを特定すべきです。顧客が自身のログを検査する必要がある場合、プロバイダーはどのログソースが重要かを述べるべきです。

公開リスクは顧客の成熟度によっても異なります。大企業は GitHub エンタープライズ監査ログ、集中シークレットスキャン、ソフトウェア構成分析、CI/CD 分離、インシデント対応スタッフを持っているかもしれません。小規模な Heroku 顧客は単純な GitHub 接続、1人または2人のメンテナー、限られたログ保存期間を持っているかもしれません。したがって、同じトークンイベントは異なる負担を生み出します。成熟した説明責任記録は、すべての顧客がプロバイダーの証拠ギャップを独立して埋められるとは想定しません。小規模チームには実用的な手順を、大規模チームにはレビューを自動化するのに十分な技術的詳細を提供します。

下流のオーディエンスは Heroku アカウント所有者よりも広いです。ソースコードへのアクセスが脆弱性やシークレットを明らかにした場合、顧客のソフトウェアの下流利用者は、元のプラットフォームインシデントが即座のダウンタイムを引き起こさなかったとしても、後で影響を受ける可能性があります。それはすべての下流利用者が害を受けたことを意味するわけではありません。それは、説明責任分析がリスクパスを追跡しなければならないことを意味します。すなわち、トークン盗難、可能性のあるリポジトリアクセス、可能性のあるソースまたはシークレットの露出、可能性のある CI/CD の悪用、可能性のある本番アクセス、可能性のある下流の害。各ステップは、それが主張になる前に証拠を必要とします。

通知のタイミングは管理面の一部である

インシデントコミュニケーションはしばしば法的または広報機能として扱われますが、開発者プラットフォームにとっては運用管理です。顧客は、何をすべきかを知るまで、トークンを失効させ、シークレットをローテーションし、統合を再構築し、リポジトリを検査することができません。遅延した、曖昧な、または変化する通知は、顧客が露出または不確実な状態にある期間を延長する可能性があります。迅速だが不完全な通知は不必要な作業を生み出す可能性があります。したがって、説明責任の基準は単に速度ではありません。それは各段階での意思決定の有用性です。

Heroku のインシデントページhttps://status.heroku.com/incidents/2413は、ステータス更新が単一の最終声明ではなくシーケンスを示すため有用です。GitHub のセキュリティアラートは別のタイムラインレーンを提供します。Travis CI の速報は3つ目のレーンを提供します。注意深い読者は、情報源がそれを支持しない限り、これらのタイムラインを1つの完全な年表にまとめるべきではありません。有用な質問は、各主体の通知が顧客の行動をどのように変えたかです。顧客はアプリ認証を失効させる必要がありましたか？Heroku API キーをローテーションする必要がありましたか？Heroku ユーザーパスワードをローテーションする必要がありましたか？GitHub リポジトリを検査する必要がありましたか？CI 環境変数を確認する必要がありましたか？デプロイフックを再構築する必要がありましたか？

答えは事実が明らかになるにつれて変わったかもしれません。変更が説明されている場合は許容されます。通知は「アクセスの可能性を調査中であり、追加の指示を提供します」と言うことができます。「トークンを失効させました。顧客は再認証する必要があります」と言うことができます。「ハッシュ化されたクレデンシャルへのアクセスを排除できないため、パスワードリセットが必要です」と言うことができます。「あるカテゴリの証拠は見つかりませんでしたが、顧客はこれらのインジケータについて自身のログを検査すべきです」と言うことができます。説明責任を弱めるのは不確実性ではありません。説明責任を弱めるのは、閉鎖として提示される不確実性です。

顧客通知にはセグメンテーションの義務もあります。すべての Heroku 顧客が GitHub 統合を使用していたわけではありません。すべての GitHub ユーザーが Heroku を認証していたわけではありません。すべての Travis CI ユーザーが同じスコープを持っていたわけではありません。すべてのリポジトリに機密素材が含まれていたわけではありません。有用な通知は、影響を受ける、影響を受ける可能性がある、影響を受けない、不明なグループを区別します。正確なセグメンテーションが不可能な場合、プロバイダーはその理由を説明すべきです。顧客は広範な見出しからメッセージが自分に適用されるかどうかを推測すべきではありません。

コミュニケーションの質は測定可能です。プロバイダーは耐久性のあるインシデントページを公開しましたか？メッセージには日付とタイムスタンプが含まれていましたか？影響を受けるサービスを特定しましたか？具体的な顧客行動を提供しましたか？変更された場合に以前のガイダンスを更新しましたか？直接顧客向けと公開記録を一貫して保ちましたか？悪用可能なプライベート詳細を開示せずに管理改善を命名したインシデント後レビューを公開しましたか？これらは、コミュニケーションの問題であると同時に説明責任の問題です。

開発者ツールの経済学では、不明瞭なコミュニケーションはコストを顧客に転嫁します。曖昧な文はすべて、下流で会議、チケット、ログ検索、顧客メール、監査例外になります。プラットフォームは法的に慎重かもしれませんが、開発者の信頼を販売するプラットフォームは、意思決定に有用な通知を製品の一部として扱うべきです。Heroku のインシデントは、インシデントコミュニケーションが製品エンジニアリングの規律を必要とする理由を示しています。すなわち、バージョン管理された指示、スコープされたオーディエンス、追跡可能な修正、完了の証拠です。

強制ローテーションは、顧客が何が変わったかを知っている場合にのみ救済策となる

強制クレデンシャルローテーションは必要でありながら、信頼修復としては不完全であり得ます。顧客は API キーをローテーションしたり、パスワードをリセットしたり、OAuth アプリを再認証したりするかもしれませんが、顧客はまたプラットフォームの管理モデルで何が変わったかを理解する必要があります。同じ保存パス、スコープ設計、監視ギャップ、顧客証拠ギャップが残っている場合、ローテーションはアクセスを復元しても信頼を復元しないかもしれません。Heroku の2022年インシデントに関する公開記録は、ローテーションと再認証を顧客行動の中心に置きました。説明責任の問題は、これらの行動が耐久性のある管理証拠と一致したかどうかです。

Heroku Dev Center のページ、例えばhttps://devcenter.heroku.com/articles/oauth、https://devcenter.heroku.com/articles/platform-api-reference、https://devcenter.heroku.com/articles/heroku-cli、https://devcenter.heroku.com/articles/account-securityは、Heroku プラットフォーム使用におけるより広範なアクセス管理環境を示しています。Heroku の二要素認証ページhttps://devcenter.heroku.com/articles/heroku-2faは、顧客側のアカウント強化コンテキストを提供します。繰り返しますが、現在のドキュメントは2022年の内部状態の証明ではありません。読者が Heroku アカウント周りに存在し得るクレデンシャルとユーザーアクションの種類を理解するのに役立ちます。

ローテーションには3つの異なる層があります。第一に、侵害された OAuth トークンの失効により、攻撃者が委任された認証を引き続き使用できないようにすること。第二に、正当なワークフローが新しいトークンで再開できるようにする顧客側の交換または再認証。第三に、API キー、パスワード、デプロイキー、CI 変数、リポジトリシークレット、個人アクセストークン、クラウドクレデンシャルを含む隣接クレデンシャルのレビュー。プラットフォームの通知は、どの層が必要でその理由を明確にすべきです。

最も難しい層はソースコードシークレットの露出です。攻撃者がリポジトリを読めた場合、OAuth トークンのみをローテーションするだけでは十分でないかもしれません。顧客はリポジトリ内のコミットされたシークレットを検索し、露出した値をすべてローテーションする必要があるかもしれません。GitHub のシークレットスキャンドキュメントhttps://docs.github.com/en/code-security/secret-scanning/about-secret-scanningは、その顧客側レビューの現在の語彙を提供します。CISA のソフトウェアサプライチェーンガイダンスhttps://www.cisa.gov/resources-tools/resources/software-supply-chain-risk-management-sscrmとセキュアバイデザイン資料は、コード内のシークレットがリポジトリイベントをより広範な運用リスクに変える理由を説明するのに役立ちます。

強制ローテーションには完了シグナルも必要です。顧客は、古いトークンが無効になっているか、再認証が必要か、無効にされた統合が行動まで無効のままか、パスワードリセットの完了が追跡されているか、期限切れのクレデンシャルがどこでもまだ受け入れられているかを知るべきです。完了シグナルがなければ、すべての顧客が独自の調整を実行しなければなりません。それは高価でエラーが発生しやすいです。

プラットフォームにも内部完了証拠が必要です。どの顧客アカウントが必要な手順を完了しましたか？どのアカウントが例外状態のままですか？どの顧客に連絡が取れませんでしたか？どの統合が放棄されましたか？どのトークンを現在の所有者にマッピングできませんでしたか？無言の長期トークン保持を防ぐためにどの管理が追加されましたか？公開ポストモーテムは顧客名を開示しないかもしれませんが、クリーンアップの形状を開示することはできます。それが「ローテーションしました」と「リスク状態はもはや存在しません」の違いです。

GitHub、Heroku、Travis CI、Salesforce、顧客はそれぞれ異なる証拠を所有していた

インシデントの説明責任マップはマルチパーティです。GitHub はソースホストの証拠、OAuth アプリケーションの可視性、公開したセキュリティアラートを所有していました。Heroku はプラットフォーム統合、顧客コミュニケーション、トークン管理、強制クレデンシャルプログラムを所有していました。Travis CI は影響を受けた CI/CD 統合レーンと顧客ガイダンスを所有していました。Salesforce は Heroku のガバナンス、リソース配分、リスクエスカレーション、プラットフォーム修復を信頼できるものにする義務を所有していました。顧客はリポジトリ衛生、シークレットローテーション、組織 OAuth 承認、デプロイレビューを所有していました。これらの役割のいずれも他を打ち消すものではありません。

これは、役割間のギャップから顧客への害が生じる可能性があるため重要です。GitHub がトークンが使用されたことを知っていても、顧客がどの Heroku アプリケーションにマッピングされているかわからない場合、顧客の対応は遅くなります。Heroku がどのアカウントが GitHub 統合を使用したかを知っていても、リポジトリ内容にアクセスされたかどうかを伝えられない場合、顧客はより広範にレビューしなければなりません。Travis CI と Heroku が GitHub アラートを共有していても、異なる顧客指示を持つ場合、両方を使用する組織は矛盾または重複する行動を調整しなければなりません。Salesforce が Heroku を子会社ブランドとして扱う一方、顧客が Heroku を本番プラットフォームとして扱う場合、ガバナンスはブランド境界を橋渡ししなければなりません。

クラウドおよび SaaS の共有責任文書は、プロバイダーと顧客の義務が異なると言うことがよくあります。Heroku のインシデントは、共有責任には共有証拠も必要であることを示しています。顧客は、プロバイダーがその保証がカバーするチェーンの部分を開示しない場合、責任を持ってプロバイダーの保証を受け入れることができません。プロバイダーは、顧客が行動するために必要なログや製品機能を顧客が欠いている場合、責任を持ってすべての行動を顧客に移すことはできません。ソースホストは、下流ツールがそのアラートを完全に変換するとは想定できません。各主体は、その証拠をチェーンの次の主体にとって有用にしなければなりません。

IETF、NIST、MITRE、CISA、GitHub、Heroku、Travis CI の情報源は一緒に境界のある公開ファイルを形成します。それらはすべてのプライベート事実を明らかにするわけではありませんが、明確な説明責任モデルを可能にします。OAuth トークンは狭くスコープされ、防御可能に保存され、迅速に失効可能で、継続的に監視され、現在のビジネス目的にマッピングされるべきです。開発者プラットフォームは、顧客が行動できるのに十分な具体性を持ってインシデントをコミュニケーションすべきです。顧客は統合を恒久的なものとして扱うのではなく定期的にレビューすべきです。ソースホストは、顧客が可能性のある露出と確認されたアクセスを区別できるように監査証拠を十分に利用可能にすべきです。

役割マップはまた、単純な非難に対して警告します。攻撃者がトークンを盗んだ場合、攻撃者は悪用に対して責任があります。しかし、説明責任は、誰が機会、爆発半径、不確実性を減らすことができるかを問います。トークン保存設計は機会を減らすことができます。スコープ最小化は爆発半径を減らすことができます。迅速な失効は期間を減らすことができます。良いログは不確実性を減らすことができます。明確な顧客指示は無駄な労働を減らすことができます。インシデント後の管理証拠は再発を減らすことができます。これらは設計上の選択であり、事後の声明だけではありません。

顧客検証可能な証拠は共有責任の欠けている半分である

Heroku のインシデントは、証拠が非対称である場合の共有責任言語の限界も示しています。プラットフォームは顧客にリポジトリ衛生、シークレットローテーション、OAuth アプリレビューの責任があると言うことができますが、顧客はどこを調べるかを決定するために依然としてプロバイダーの証拠に依存します。プロバイダーがトークンがリポジトリ読み取りスコープを持っていたか、特定の日付以降に使用されたか、特定のアプリケーションに結びついていたか、顧客固有のログが存在するかを言えない場合、顧客の責任は推測ゲームになります。公平な共有責任モデルは、顧客に義務と使用可能な証拠の両方を与えます。

顧客検証可能な証拠はインベントリから始まります。各顧客は、どの Heroku アプリケーションがどの GitHub 組織、リポジトリ、ユーザー、デプロイフローに接続されているかを見ることができるべきです。インベントリは、現在のステータス、最終認証、スコープ、所有者、再認証要件、接続がプロバイダーによって無効にされたかどうかを示すべきです。そのマップがなければ、セキュリティチームは古いチケット、リポジトリウェブフック、デプロイ履歴、個人の開発者アカウントから統合を再構築しなければなりません。それはまさに、プロバイダー側のトークンイベント後にプラットフォームが減らすべき緊急労働の種類です。

第二の証拠層は活動です。顧客は、リポジトリアクセス、OAuth 認証使用、API キー使用、Heroku アカウント活動、デプロイイベント、ビルドイベント、構成変更を示すログを知る必要があります。関連証拠が GitHub にのみ存在する場合、プロバイダーは顧客を GitHub 監査記録に誘導すべきです。関連証拠が Heroku にのみ存在する場合、プロバイダーは顧客固有のビューまたはサポートパスを公開すべきです。一部の証拠がログが保持されなかったか収集されなかったために利用できない場合、プロバイダーはそれを明確に述べるべきです。「悪用の証拠はない」は、顧客がどの証拠がレビューされたかを知っている場合にのみ意思決定に有用です。

第三の層はシークレット露出です。リポジトリアクセスリスクは、知的財産としてのソースコードに限定されません。コミットされたシークレット、過去の構成、テストクレデンシャル、デプロイトークン、クラウドキー、データベース接続文字列、アーキテクチャを明らかにするコメントも含まれます。顧客は、トークンインシデントをシークレットスキャンとローテーションにリンクするガイダンスを必要とします。強力なプラットフォーム対応は、どのカテゴリが可能性が高く、どのカテゴリが可能性があり、どのカテゴリが既知のパスの外にあるかを言うべきです。また、トークン失効だけでリポジトリ内容リスクが閉じることを示唆することも避けるべきです。

第四の層はソフトウェアリリース保証です。顧客が GitHub からの自動デプロイに Heroku を使用している場合、顧客は不正なリポジトリアクセスがデプロイされたコード、ビルド成果物、レビューアプリ、パイプライン、リリース履歴に影響を与えた可能性があるかどうかを知る必要があります。それはそのような影響が発生したことを意味するわけではありません。それは、顧客がそれを証明または反証するのに十分な情報を受け取るべきであることを意味します。リリース履歴、ビルド来歴、デプロイタイムスタンプ、リポジトリコミット署名、ブランチ保護、CI ログはすべて説明責任ファイルの一部になります。

第五の層は耐久性のあるクリーンアップです。顧客はいつ疑わしい状態が終了したかを知ることができるべきです。古い OAuth トークンは失効されましたか？統合は新しいトークンで再認証されましたか？パスワードまたは API キーのローテーションは完了しましたか？放棄されたアプリケーションは無効にされましたか？孤立した個人認証は削除されましたか？プラットフォームは古いトークンクラスがバックグラウンドジョブやレガシーパスでアクティブのままであることを防止しましたか？プロバイダーの保証は、顧客が自身のテナント状態をプロバイダーの完了証拠と照合できる場合に最も強力です。

この顧客証拠モデルは、プロバイダーが機密のプライベートログを公開ウェブ上で公開することを要求するものではありません。アカウントダッシュボード、直接通知、サポートエクスポート、エンタープライズインシデントブリーフィング、契約上の証拠パッケージを通じて提供できます。形式は顧客層と機密性によって異なります。原則は変わるべきではありません。プロバイダーが顧客に行動を求める場合、顧客が比例して行動するために必要な証拠も提供すべきです。

調達とガバナンスは統合を恒久的なアクセスとして扱うべきである

調達の教訓は、OAuth 統合は恒久的なアクセスであり、一度限りのセットアップタスクではないということです。暗号化、多要素認証、または稼働時間目標をサポートするかどうかのみを尋ねるベンダーリスク質問票は、Heroku の教訓を見逃すでしょう。より鋭い質問は、統合インベントリ、トークン保存、スコープ最小化、顧客ログ、緊急失効、テナントレベル通知、ビルドシステム分離、インシデント後証拠に関するものです。開発者プラットフォームは、その製品が意図的にソフトウェアデリバリーに近い位置にあるため、これらの質問を期待すべきです。

契約言語も曖昧な責任移転を避けるべきです。プロバイダーは顧客にリポジトリとクレデンシャルを保護することを要求できますが、プロバイダー側の統合インシデントがどのように扱われるかを述べるべきです。プロバイダーは影響を受ける統合を使用するすべての顧客に通知しますか？影響を受ける時間枠を提供しますか？ソースコードへのアクセスが確認されたか、可能性があるか、観察されなかったかを特定しますか？再認証を要求しますか？監査イベントを公開しますか？インシデント後の概要を提供しますか？独自の通知を必要とする規制対象顧客をサポートしますか？これらは大企業向けの贅沢な条件ではありません。これらは、ソフトウェアサプライチェーンがプラットフォームに依存するすべての顧客にとって基本的な運用上の質問です。

Salesforce と Heroku 内部のガバナンスも重要です。子会社ブランドが開発者向けであるからといって説明責任が低いと公衆は想定すべきではありません。Heroku アプリケーションは、本番アプリケーション、内部ツール、公開 API、クリティカルになったプロトタイプ、機密ワークフローを扱うバックオフィスシステムである可能性があります。所有構造は、ガバナンスがログ、トークン管理、インシデント対応、顧客サポート、セキュリティエンジニアリングへの投資を決定するため重要です。親会社は開発者プラットフォームのインシデントが真剣な管理注意を受けたことを示すために、すべての取締役会の議論を開示する必要はありません。

同じガバナンスの質問は製品管理にも適用されます。製品チームは摩擦を減らし顧客が迅速にデプロイできるようにシームレスな GitHub 統合を望むかもしれません。セキュリティチームは短命トークン、狭いスコープ、顧客可視ログ、定期的な再認証を望むかもしれません。サポートチームは小規模顧客にも十分シンプルなメッセージを望むかもしれません。エンタープライズ販売チームは契約証拠を望むかもしれません。説明責任は、これらのインセンティブがインシデント前ではなく、インシデント後に調整される場所に現れます。プラットフォームが通常運用でトークン管理リスクを誰が所有するかを説明できない場合、危機時に誰がそれを所有するかを説明するのに苦労するでしょう。

顧客にとって、実用的なガバナンス対応は結果によって統合を分類することです。個人の生産性向上統合は、本番ソースコードを読み取り可能なデプロイ統合とは異なります。読み取り専用リポジトリアプリは、デプロイを作成したりウェブフックを管理できるアプリとは異なります。トライアル Heroku アプリは、顧客向け本番アプリケーションとは異なります。組織は、本番コードやシークレットに影響を与える可能性のある統合により強力なレビュー、ログ、再認定を割り当てるべきです。Heroku のインシデントは、「接続アプリ」が利便性機能だけでなくガバナンスオブジェクトであることを思い出させます。

結果として、より成熟した説明責任基準が生まれます。開発者プラットフォームは、顧客が自身のリスク判断を完了できるのに十分なインシデント証拠を公開すべきです。顧客は、プロバイダーの証拠に迅速に行動できるように十分な統合インベントリを維持すべきです。ソースコードホストは OAuth と監査管理を使用可能に保つべきです。CI/CD ベンダーはビルドシークレットを広範なリポジトリ信頼から分離すべきです。親会社は開発者信頼を本番信頼として扱うべきです。2022年の Heroku インシデントは、このように読まれると、単なる歴史的なセキュリティアラート以上のものになります。ソフトウェアデリバリーチェーンが、攻撃者に誰もが見るよう強制される前に恒久的なアクセスを特定できるかどうかのテストになります。

OAuth 管理インシデント後の耐久性のある修復はどのようにあるべきか

開発者プラットフォームの OAuth インシデントに対する耐久性のある修復基準には、少なくとも8つの部分があります。第一に、プロバイダーは明確なタイムラインを公開すべきです。検出、GitHub 通知、Heroku 調査、顧客通知、トークン失効、クレデンシャルローテーション、再認証利用可能性、ポストモーテム。第二に、すべての顧客やリポジトリが等しく影響を受けたと示唆することなく、影響を受ける統合面を特定すべきです。第三に、盗まれた OAuth トークン、顧客パスワード、API キー、デプロイキー、リポジトリシークレット、CI 変数の違いを説明すべきです。

第四に、プロバイダーは必須、推奨、条件付きのステップを区別する顧客行動のチェックリストを公開すべきです。第五に、顧客が見ることができる証拠と、プロバイダーまたはソースホストのみが見ることができる証拠を述べるべきです。第六に、どの管理が変更されたかを特定すべきです。トークン保存、暗号化、シークレット管理、スコープレビュー、監視、異常検出、顧客監査アクセス、統合非推奨。第七に、強制リセット完了、トークン失効完了、再認証施行などの完了シグナルを提供すべきです。第八に、残りの未知を明確に述べるべきです。

Heroku の公開ファイルには意味のある証拠が含まれていますが、説明責任の教訓は一つのインシデントよりも広いです。開発者プラットフォームは、不審なトークンの日が発生する前に設計すべきです。つまり、OAuth アプリケーションインベントリ、所有者マッピング、スコープ最小化、トークン経過時間追跡、自動化された失効ワークフロー、顧客通知テンプレート、顧客固有のアクションページ、監査ログエクスポート、定期的な統合再認定です。また、危機の前に強制再認証の顧客体験をテストすることを意味します。顧客が平穏な日に修復パスを理解できない場合、インシデント中に理解することはできません。

顧客も耐久性のある習慣を必要とします。OAuth アプリをインベントリし、未使用の統合を削除し、組織全体の承認を制限し、高スコープアプリにレビューを要求し、シークレットスキャンを使用し、クレデンシャルをコミットせず、長期シークレットをローテーションし、監査ログを保存し、デプロイフローをマッピングすべきです。GitHub と Heroku のドキュメントは多くの構成要素を提供しますが、ガバナンス作業は各組織に属します。顧客がどのアプリがどのリポジトリと本番システムに接続されているかをすでに知っている場合、ベンダーインシデントはより管理しやすくなります。

最終的な説明責任テストは、プラットフォームがインシデントが閉じたと言えるかどうかではありません。閉鎖が証拠に追跡できるかどうかです。疑惑のトークンは無効化されましたか？影響を受けた顧客は通知されましたか？必要なリセットは完了しましたか？ソースコードアクセスの質問は証拠が許すレベルで回答されましたか？シークレットとデプロイクレデンシャルはレビューされましたか？製品管理は変更されましたか？残りの未知は保存されましたか？これらの質問への「はい」は、顧客に何が変わったかを伝えるため、一般的な信頼の声明よりも強力です。

したがって、Heroku の2022年 OAuth インシデントは、Daniel Kade のリスクと説明責任シリーズに属します。なぜなら、開発者の信頼を可視化するからです。このインシデントは、おなじみの統合ボタンを管理の問題に変えます。ソースコードプラットフォーム、デプロイプラットフォーム、CI/CD ベンダー、顧客が、ユーザーのクリックを超えて存続する委任された権限によって接続されていることを示します。その権限が盗まれたとき、説明責任はトークンに従います。誰が発行したか、誰が保存したか、誰が見ることができたか、誰が失効させたか、誰がユーザーに警告したか、誰が修復を証明したか、そして証明がまだ不完全な間に誰がコストを支払ったかです。