Postman ワークスペース漏洩：公開ワークスペースがAPIキーを晒す危険性

30,000以上の公開ワークスペースが重要なビジネス情報を漏洩

2024年12月、サイバーセキュリティ界は近年最大級のAPIセキュリティ事故の一つを目撃しました。CloudSEKのTRIADチームは、Postmanプラットフォーム上の30,000以上の公開ワークスペースから、APIキーやアクセス・リフレッシュトークンなどの機密情報が漏洩していることを発見しました。この大規模な情報漏洩は、医療機関から決済処理業者まで多岐にわたる業界に影響を及ぼし、財務的・評判的リスクをもたらしました。

皮肉なことに、世界中で3,000万以上の組織にAPI開発とテストを効率化するために設計されたPostmanが、記憶に残る広範な資格情報漏洩の一因となったのです。この事件は、最も便利な開発ツールであっても、不適切な設定によりセキュリティリスクとなり得ることを改めて示しています。

事件の規模：注目すべき数字

このセキュリティ事故の規模は計り知れません。1年にわたる調査で、公開アクセス可能なワークスペースから、アクセス・リフレッシュトークンやサードパーティAPIキー、テスト・デモ用ユーザーデータまで、多数の機密情報が漏洩していることが判明しました。

最も影響を受けたプラットフォームは？

GitHub（5,924件）、Slack（5,552件）、Salesforce（4,206件）が特に被害が大きかったです。その他、MicrosoftオンラインサービスやFacebook Graph API、各種決済プラットフォームも含まれます。これらの事例は、現代のソフトウェアエコシステムがいかに相互に連結しているか、そして一つの誤設定が連鎖的なセキュリティリスクを生むことを示しています。

危険にさらされている業界

漏洩データは以下の重要なセクターに及びました：

• 医療：患者データや管理システム
• 金融サービス：決済APIや取引認証情報
• Eコマース：顧客情報や決済ゲートウェイ
• テクノロジー：内部システムや独自インフラ
• スポーツアパレル・小売：サプライチェーンや顧客データ

Eコマースや決済システムは全漏洩の3.9％を占め、顧客向けビジネスの脆弱性を浮き彫りにしています。

実世界の影響：理論から脅威へ

Postmanのワークスペース漏洩は単なる理論上の脆弱性ではなく、実際に被害をもたらしたセキュリティ侵害です。

ケーススタディ：医療機関の漏洩

大手医療企業が、公開されたPostmanワークスペースから、ZenDeskの管理者資格情報を含む非常に機密性の高い情報を漏洩させる事態に直面しました。これにより、悪意のある攻撃者が患者情報にアクセスしたり、サポート業務を操作したり、巧妙なフィッシング詐欺を仕掛けたりする可能性が生じました。

米国のHIPAA規制の下、こうした漏洩はデータ盗難だけでなく、巨額の規制罰や患者の信頼喪失につながる恐れがあります。

ケーススタディ：決済ゲートウェイの脆弱性

インドの決済プラットフォームRazorpayのAPIキーが誤って公開されたPostmanワークスペースから漏洩しました。Razorpayは毎日何百万もの取引を処理しており、漏洩したキーは不正な取引や金融詐欺、決済システムの改ざんに悪用される危険性があります。

この事例は、開発者の不注意が直接的に金融犯罪に結びつく例です。

ケーススタディ：スポーツアパレル企業

大手スポーツアパレル・フットウェア企業が、第三者ベンダーによるプライベートなPostmanワークスペースの漏洩により、OktaのID・アクセス管理システムへのリクエストや有効な認証情報、アクセストークンが露出しました。

この事件は、現代のセキュリティにおける重要な課題、すなわちサードパーティリスクを浮き彫りにしています。内部で堅牢なセキュリティを実施していても、脆弱なパートナーやベンダーを通じて侵害される可能性があるのです。

ケーススタディ：CRMプラットフォームの漏洩

あるCRMプラットフォームのワークスペースから、リフレッシュトークンやセッションシークレット、アクセストークン生成用エンドポイントが漏洩しました。この種の漏洩は、攻撃者が持続的にシステムにアクセスし続けることを可能にし、最初の認証情報が変更されても有効です。

なぜ開発者は秘密情報を誤って共有してしまうのか？

これらの漏洩がなぜ起きたのか理解することは、今後の防止に不可欠です。その根本原因は多面的で、技術的要因と人為的要因が絡み合っています。

1. ワークスペースの可視性設定の誤解

デフォルトでは、Postmanはワークスペースをインターネットに公開します。これはセキュリティ専門家を困惑させる設計です。多くの開発者は、「公開」が誰でもアクセスできることを十分理解せずに、公開ワークスペースを作成しています。

個人、チーム、プライベート、公開の区別は初心者にとって混乱を招きやすく、誤った設定により全世界にデータを晒す危険性があります。

2. 機密情報を平文で保存

Postmanは、デフォルトで機密情報を暗号化せず平文で保存します。これにより、アクセス権を持つ誰もが潜在的に機密情報を見ることが可能です。この慣行は、セキュリティの理解不足と相まって、データ漏洩のリスクを高めています。

APIキーやパスワード、トークンをリクエスト例や環境変数、コレクションのドキュメントに直接埋め込むケースが多く、便利さの反面、公開時には致命的な結果を招きます。

3. セキュリティ機能の未活用

多くのユーザーは、Postmanのシークレット管理ツールや暗号化された変数ストレージ、Postman Vaultの利用を避けています。これらの機能を適切に使えば、機密情報の漏洩リスクを大きく低減できます。

「シークレットマスキング」や暗号化された変数ストレージの未使用は、機密情報を平文で晒しやすくします。

4. APIキーのローテーション不足

漏洩した場合でも、迅速なキーのローテーションにより被害を最小限に抑えられますが、多くのキーは長期間有効のままでした。これにより、攻撃者は長期間にわたり不正アクセスを続けることが可能となりました。

5. 開発者の教育不足

多くのユーザーは、可視性設定や秘密情報の管理方法を理解しておらず、共有時のベストプラクティスを怠っています。組織も、Postmanのコラボレーションツールの正しい使い方やAPI開発のセキュリティについて教育できていません。

API開発プラットフォームの急速な普及により、知識ギャップが生まれ、攻撃者にとっては格好の標的となっています。

6. サードパーティ・ベンダーリスク

この事故では、主に自社の行動ではなく、外部ベンダーのアクセスによる侵害も多く見られました。外部パートナーのセキュリティ対策が不十分だと、企業全体のリスクが高まります。

攻撃者はどうやって公開ワークスペースを悪用するのか

攻撃者の視点を理解することで、組織はセキュリティ対策の優先順位をつけやすくなります。

アクセスと偵察

公開されたワークスペースURLを見つけた攻撃者は、資格情報を抽出し、不正APIリクエストや機密データへのアクセス、システムの操作を行います。公開設定のワークスペースは、検索クエリだけで簡単に見つかります。

資格情報の収集

公開されたワークスペース内では、次の情報を体系的に収集します： - クラウドサービス（AWS、Azure、Google Cloud）のAPIキー - 認証用アクセス・トークン - 持続的アクセス用リフレッシュトークン - データベース接続文字列 - サードパーティサービスの資格情報

横展開

Postmanは、同じ組織内の他チームも閲覧できる仕組みを持ち、攻撃者はこれを利用して横展開し、より多くの機密情報にアクセスします。1つの侵害資格情報が、組織全体のインフラ探索の足掛かりとなるのです。

データ流出

攻撃者は、漏洩したAPIキーを使って、顧客情報や財務記録、知的財産、企業のコアデータを抽出します。

金融詐欺

決済認証情報が漏洩した場合、攻撃者は: - 不正取引を行う - 支払いを不正な口座に振り替える - 顧客の支払い情報にアクセス - 取引記録を改ざん

セッション乗っ取り

攻撃者は、漏洩したトークンを使って自らAPIリクエストを送り、内部システムにアクセスしたり、認証を回避したりします。これにより、正規ユーザーになりすまし、迅速に問題を拡大できます。

Postmanの対応：遅きに失したのか？

これらの広範な漏洩が判明した後、Postmanは複数のセキュリティ対策を実施しました。

事前の秘密検出

Postmanは、公開ワークスペース内の機密情報を検出し、ユーザーに通知する仕組みを導入しています。APIキーやトークン、資格情報のパターンをスキャンし、公開前に警告を出します。

漏洩ワークスペースの削除

今月から、既知の漏洩情報を含む公開ワークスペースはPostmanのPublic API Networkから削除され、所有者には通知とともに削除の機会が提供されます。

警告の強化

公開設定を試みる際に、セキュリティリスクを警告する表示をより目立つ形に改善しています。

残る疑問

これらの対策は一歩前進ですが、批評家は最初から実施されるべきだったと指摘しています。デフォルトの公開設定が多くの漏洩を招いたことは、Postmanのセキュリティ設計思想に疑問を投げかけます。

ベストプラクティス：Postmanワークスペースのセキュリティ確保

組織や個人開発者は、積極的にセキュリティ対策を講じる必要があります。

1. 常にプライベートワークスペースから始める

ワークスペースは、Workspace Settingsからチームの可視性を「内部のみ」に設定してプライベートにできます。特に理由がない限り、公開設定は避け、機密情報は削除しましょう。

2. 環境変数の適切な利用

環境変数を使って、機密情報をハードコーディングしないようにします。Postman内で環境を作成し、シークレットは「Current Value」に保存し、「Initial Value」には共有しない設定にします。

3. Postman Vaultの活用

Postman Vaultは、APIキーやパスワードなどの機密情報をローカルに安全に保存できる機能です。これらはクラウドに同期されず、あなたのみがアクセス可能です。

4. APIキーの定期ローテーション

定期的にAPIキーやアクセス・トークンを更新するポリシーを設定しましょう。漏洩していなくても、定期的な更新はリスクを低減します。

5. 二要素認証の有効化

強力なパスワードを設定し、メール認証や二要素認証を有効にしましょう。Googleやシングルサインオンを利用してください。

6. 定期的なセキュリティ監査

定期的にワークスペースやコレクション、環境設定を見直し、脆弱性を早期に発見します。セキュリティ担当者を配置し、監査を実施しましょう。

7. 役割ベースアクセス制御

閲覧者（Viewer）から編集者（Editor）、管理者（Admin）へ適切に権限を付与し、不要な変更を防ぎます。最小権限の原則を徹底しましょう。

8. 開発チームの教育

API管理プラットフォームの機能やセキュリティの重要性について、開発者に教育を行います。共有コレクションや環境ファイルに秘密情報を埋め込まないことを徹底させましょう。

9. 機密情報漏洩の監視

Assetnote Surface MonitoringやCybelAngelなどのツールを使い、漏洩の兆候を検知し、早期に通知します。自動監視でミスを未然に防ぎます。

10. チーム探索の無効化

Team SettingsやTeam Discoveryの設定を見直し、攻撃者による横展開を防止します。

11. 共有前の精査

コレクションを共有する前に、実APIキーや本番用資格情報、内部URLやIP、顧客データなどを削除・置換します。

12. ピアレビューの導入

重要なコレクションは、ピアレビューを経てマージし、セキュリティ上の問題を見逃さない仕組みを作ります。

APIセキュリティの広範な課題

Postmanのワークスペース漏洩は、単なる一つのプラットフォームの問題にとどまらず、現代ソフトウェア開発の構造的課題を映し出しています。

コラボレーションとセキュリティのジレンマ

協力と迅速な開発を重視する現代では、ツールの便利さとセキュリティのバランスが重要です。セキュリティ対策は手間を伴いますが、そのコストは漏洩の損害に比べれば微々たるものです。

人間の要素

技術だけでは解決できない問題もあります。締め切りに追われる開発者は、APIキーを「とりあえず今だけ」とハードコーディングし、そのまま忘れてしまうことも。教育と文化、責任感が重要です。

サプライチェーンのリスク

この事故で明らかになったのは、外部ベンダーのセキュリティも重要だということです。パートナーやベンダーのセキュリティ基準も厳格に管理すべきです。

デフォルトのセキュリティ優先

ツールは、最大限のセキュリティをデフォルトにすべきか、それとも利便性を優先すべきかという議論があります。今後は「セキュア・バイ・デフォルト」の考え方が進むでしょう。

今後の展望：行動を促す呼びかけ

30,000以上のPostmanワークスペース漏洩は、ソフトウェア開発業界全体への警鐘です。APIのセキュリティは後回しにできません。開発の各段階にセキュリティを組み込む必要があります。

組織向け

• すべてのPostmanワークスペースの即時監査
• 全開発者へのセキュリティ教育の義務化
• APIキー管理とローテーションのポリシー策定
• シークレット管理ソリューションの導入検討
• サードパーティベンダーのセキュリティ要件の見直し

個人開発者向け

• すべてのワークスペースをプライベートに設定
• 露出した資格情報は即座に削除・ローテーション
• Postman Vaultの利用を習慣化
• セキュリティのベストプラクティスを学習
• 公開前に必ず見直し、公開情報を最小化

プラットフォーム提供者向け

• セキュリティをデフォルトに設計
• 警告や通知を明確に表示
• 機密情報検出とアラートの自動化
• ユーザ教育とドキュメント整備
• プラットフォーム設計における責任を自覚

結論：利便性の代償

Postmanのワークスペース漏洩は、便利さがいかに危険に変わり得るかを示す例です。これらの脆弱性は、データ漏洩や不正取引、評判・財務の損失につながる可能性があります。

APIは現代ソフトウェアの基盤です。セキュリティは、すべての開発者の基本的な責任です。セキュリティを他人任せにせず、自分の責任で守る意識が必要です。

幸い、多くのAPIセキュリティ問題は、意識と教育、適切なセキュリティ機能の利用で防げます。Postmanの漏洩も、単純な設定ミスや見落としによるもので、誰でも避けられるものです。

今後も、この事件を教訓に、API開発において何を共有し、何を守るべきかを常に意識しましょう。公開されたワークスペースや漏洩した資格情報は、セキュリティと安全の境界線です。責任を持ってツールを使い、デジタル世界の安全を守りましょう。