DEV Community

Cover image for セルフホストAPIツール：クラウドから離れるべきか？
Akira
Akira

Posted on • Originally published at apidog.com

セルフホストAPIツール：クラウドから離れるべきか？

GitHubが、自社の約3,800の内部リポジトリから攻撃者によってデータが盗まれたことを認めた週、セルフホスト型APIツールは「一部のコンプライアンス要件」から「APIデータの置き場所をどう設計するか」という経営・セキュリティ上の課題に変わりました。クラウドAPIツールは便利ですが、OpenAPI仕様、共有コレクション、テストデータ、環境シークレットがどこに保存され、誰の管理下にあるのかは、今すぐ確認すべきです。

今すぐApidogを試す

多くのチームでは、その答えは「ベンダーのクラウド上。正確な場所や処理経路までは把握していない」かもしれません。それが常に悪いわけではありません。クラウド同期型APIツールは導入が速く、分散チームのコラボレーションに強いからです。ただし、GitHubの事件は、APIの信頼できる情報源（source-of-truth）を自社のセキュリティ境界内に置くべきか、外部クラウドに委ねるべきかを判断する良いタイミングです。

要約

セルフホスト型APIツール、またはオンプレミスAPIプラットフォームは、OpenAPI仕様、リクエストコレクション、テストデータ、認証情報を、ベンダーのマルチテナントクラウドではなく、自社で管理するインフラ内に保持します。

2026年5月のGitHub侵害事件では、攻撃者がトロイの木馬化されたVS Code拡張機能を通じて約3,800の内部リポジトリからデータを抜き取りました。このような開発環境起点の攻撃を前提にすると、APIチームは次を決める必要があります。

  • API仕様はどこに保存するか
  • リクエストコレクションに実データを含めるか
  • 環境変数やトークンをクラウド同期するか
  • 規制対象データをAPIツールに入れてよいか
  • セルフホスト、オフライン、クラウドをどう使い分けるか

規制産業、機密性の高い認証情報の保存、エアギャップネットワークでは、セルフホスト型またはオフラインAPIツールが現実的です。一方、運用負荷を下げたい分散チームや、低リスクなAPIコラボレーションでは、クラウド同期が有利な場合もあります。Apidogはクラウド製品に加えて、セルフホスト型オンプレミスデプロイメントとオフラインモードを提供します。

GitHubで何が起こったのか、APIチームが見るべきポイント

2026年5月20日、GitHubは攻撃者が約3,800の内部コードリポジトリからデータを盗んだことを確認しました。侵入経路はGitHubのコアプラットフォームのゼロデイ脆弱性ではなく、GitHub従業員のデバイスにインストールされた改ざん済みVS Code拡張機能でした。

その拡張機能が従業員の権限で実行され、攻撃者はGitHub内部ネットワークへの足がかりを得ました。TeamPCPとして追跡されている脅威グループは、npm、PyPI、PHPパッケージエコシステムにおけるサプライチェーン攻撃で知られています。セキュリティ報告によると、盗まれたデータセットはアンダーグラウンドフォーラムで5万ドル以上で販売されました。GitHubは、内部リポジトリ外に保存された顧客データが影響を受けた証拠は見つかっていないと述べています。

同じ時期に、別の重大な問題もありました。2026年4月、クラウドセキュリティ企業WizはCVE-2026-3854を開示しました。これはGitHubの内部Gitインフラにおける重大なリモートコード実行脆弱性で、パッチ適用前には数百万のリポジトリを危険にさらしていました。SecurityWeekは、この脆弱性とその範囲を詳細に記録しています。

APIチームにとって重要なのは、GitHubが単なるコードホストではない点です。多くの組織では、GitHubはAPIの信頼できる情報源でもあります。

典型的には、以下が同じ場所に集まります。

repo/
├── openapi.yaml
├── postman_collection.json
├── apidog_collection.json
├── .env.example
├── terraform/
├── .github/workflows/
├── test-fixtures/
└── mocks/
Enter fullscreen mode Exit fullscreen mode

ここには次の情報が含まれがちです。

  • OpenAPI / Swagger仕様
  • APIリクエストコレクション
  • テスト用ペイロード
  • .env.example
  • APIゲートウェイ設定
  • CI/CD用トークン参照
  • 統合テストフィクスチャ
  • モックサーバー定義

GitHubのインシデントで盗まれたのはGitHub自身の内部コードであり、顧客リポジトリではありません。この区別は重要です。ただし、攻撃パターンは一般化できます。悪意あるVS Code拡張機能、サプライチェーン攻撃、従業員端末からの横展開は、どの開発ツールベンダーにも起こり得ます。

開発者側の対策については、VS Code拡張機能のAPIキーセキュリティで扱っています。リポジトリ側のリスクについては、GitリポジトリにおけるAPIドキュメントのセキュリティを維持する方法を参照してください。この記事では、プラットフォームレイヤー、つまり「API設計とAPIデータをベンダーのクラウドに置くべきか」を扱います。

APIクライアントがクラウドに同期するデータを棚卸しする

セルフホストを検討する前に、まずAPIクライアントが何を同期しているかを確認します。クラウド同期型APIツールにログインし、チームワークスペースに参加すると、通常は以下のデータがベンダーのインフラに保存されます。

1. API仕様書

OpenAPI仕様には、サービスが公開するエンドポイント、パラメータ、スキーマ、認証フローが含まれます。

例：

paths:
  /admin/users/{id}:
    get:
      security:
        - bearerAuth: []
      parameters:
        - name: id
          in: path
          schema:
            type: string
Enter fullscreen mode Exit fullscreen mode

仕様書はパスワードではありません。しかし、攻撃者にとっては偵察用の地図です。どのエンドポイントが存在するか、どのIDが列挙可能か、どこに認証境界があるかを短時間で把握できます。

2. リクエストコレクションと保存済みサンプル

保存済みリクエストには、実データに近いペイロードが含まれがちです。

{
  "email": "customer@example.com",
  "accountId": "acct_123456",
  "plan": "enterprise",
  "internalNote": "migrated from legacy billing"
}
Enter fullscreen mode Exit fullscreen mode

保存済みレスポンス例には、さらに多くの情報が含まれることがあります。

  • 顧客メールアドレス
  • アカウントID
  • 内部ホスト名
  • ステージング環境の実データ
  • ユーザーオブジェクト全体
  • レコード一覧

3. 環境変数とシークレット

最も注意すべきなのはここです。多くのチームは、APIクライアント内に以下を保存します。

BASE_URL=https://api.example.com
API_KEY=prod_xxxxxxxxx
BEARER_TOKEN=eyJhbGciOi...
OAUTH_CLIENT_SECRET=...
DB_CONNECTION_STRING=...
Enter fullscreen mode Exit fullscreen mode

これらをチームで共有するためにクラウド同期すると、本番環境の認証情報がサードパーティのマルチテナントデータベースに保存される可能性があります。

環境同期の問題については、Postmanの環境同期問題に関する完全な診断で詳しく解説しています。

4. テストデータとモック定義

モックサーバーや自動テストには、業務ルールや実データに近い構造が含まれます。

{
  "eligibility": {
    "country": "JP",
    "riskScore": 42,
    "manualReviewRequired": false
  }
}
Enter fullscreen mode Exit fullscreen mode

これは単なるテストデータではなく、ビジネスロジックの断片です。

5. ワークスペースのメタデータ

次のような情報も、全体としては機密性を持ちます。

  • コメント
  • サービス名
  • チームメンバー一覧
  • フォルダー構造
  • 変更履歴
  • プロジェクト名
  • 内部ロードマップに関する記述

個別には小さな情報でも、組み合わせると組織図やシステム構成が見えてきます。

この表面をさらに詳しく確認したい場合は、Postmanは安全かという分析でクラウド同期データモデルを分解しています。

クラウド同期型APIツールの攻撃対象領域

クラウド同期型APIツールは便利ですが、ローカル完結型ツールにはない攻撃対象領域を追加します。

ベンダー自体が標的になる

数千社のAPI仕様、コレクション、認証情報を保持するSaaSは、攻撃者にとって価値の高い標的です。マルチテナント環境で単一の侵害が起きると、複数テナントに影響が及ぶ可能性があります。

ユーザー側は、ベンダーの以下に依存します。

  • セキュリティ体制
  • パッチ適用速度
  • インシデント対応
  • 従業員端末の管理
  • サブプロセッサー管理
  • ログ・テレメトリーの取り扱い

GitHubの事件では、弱いリンクは一人の従業員の端末でした。

アカウント乗っ取りの影響が大きい

クラウドツールはアカウントで認証します。アカウントは以下のリスクを持ちます。

  • パスワード再利用
  • フィッシング
  • セッションハイジャック
  • OAuthトークン窃取
  • 退職者・請負業者アカウントの放置

攻撃者がチームメンバーとしてログインできると、共有ワークスペース、同期済み環境、保存済みシークレットへアクセスできる可能性があります。

ワークスペース共有が広がりすぎる

共有ワークスペースは便利ですが、権限が広がりやすい設計でもあります。

確認すべき項目は次の通りです。

[ ] 請負業者アカウントは削除済みか
[ ] 退職者は全ワークスペースから削除済みか
[ ] 新入社員が全プロジェクトに自動追加されていないか
[ ] 本番環境の変数が不要なメンバーに見えていないか
[ ] 古い環境が残っていないか
Enter fullscreen mode Exit fullscreen mode

統合・拡張機能レイヤーが増える

GitHubの事件で使われたベクトルは、まさに開発環境の拡張機能でした。APIクライアント、IDE、CI/CD、ブラウザ拡張、プラグインは、あなたの権限で動くサードパーティコードです。

改ざんされた拡張機能は、以下にアクセスできる場合があります。

  • ローカルファイル
  • APIトークン
  • 同期済みデータ
  • 環境変数
  • クリップボード
  • IDE内のワークスペース

TeamPCPは、GitHubの事件以前からnpmやPyPIで同様のサプライチェーン攻撃を行っていました。

テレメトリー、ログ、サブプロセッサー

クラウドツールは多くの場合、次のデータフローを持ちます。

API Client
  -> Vendor API
  -> Vendor DB
  -> Logs
  -> Analytics
  -> Crash reporting
  -> Support tools
  -> Cloud provider
Enter fullscreen mode Exit fullscreen mode

クラッシュレポートやサーバーログにリクエストボディやAuthorizationヘッダーが残る可能性もあります。

関連する比較として、Vercelの侵害とそれがAPIチームに教えたことも参考になります。

もちろん、成熟したクラウドベンダーは保存時・転送時の暗号化、SOC 2、ISO 27001、専任セキュリティチームなどを備えている場合があります。小規模チームが未管理のサーバーでセルフホストするより、安全な場合もあります。重要なのは、クラウドを盲目的に使うのではなく、意図的に選ぶことです。

コンプライアンスとデータレジデンシー

規制産業では、クラウドかセルフホストかは好みではなく、監査証跡を伴う要件になることがあります。

データレジデンシーと主権

EUのGDPRや各国のデータローカライゼーション法では、人に関するデータが物理的にどこに存在できるかが制限されます。

たとえば、APIテストデータにEU居住者の個人データが含まれ、それが米国リージョンのマルチテナントDBに保存される場合、コンプライアンス上の問題になり得ます。

セルフホスト型APIプラットフォームなら、配置先を次のように制御できます。

- 自社データセンター
- 指定クラウドリージョン
- 専用VPC
- ハイブリッド環境
- エアギャップネットワーク
Enter fullscreen mode Exit fullscreen mode

越境データ転送については、欧州データ保護委員会（EDPB）のガイダンスが参照点になります。

業界固有のフレームワーク

次のような領域では、APIツール内のデータ保存先も監査対象になります。

  • HIPAA対象の医療情報（PHI）
  • PCI DSS対象の決済データ
  • FedRAMP対象の米連邦政府システム
  • CMMC対象の防衛関連データ

機密性の高い環境では、オンプレミスやエアギャップ環境が事実上必須になることがあります。このシナリオについては、セキュアな環境のためのエアギャップAPIテストツールで詳しく解説しています。

契約上のデータ取り扱い義務

規制対象でなくても、企業顧客との契約で以下が求められる場合があります。

  • 未承認サブプロセッサーで処理しない
  • 特定地域外に保存しない
  • 顧客データをテスト目的で外部送信しない
  • アクセスログを保持する
  • 顧客監査に対応する

APIクライアントがテストペイロードをベンダークラウドに同期している場合、意図せず契約違反になる可能性があります。

監査と管理の連鎖

監査人はシンプルに聞きます。

誰がこのデータにアクセスでき、どうやってそれを証明できますか？

セルフホスト型デプロイメントなら、答えは具体的です。

データ所在地: 自社VPC
アクセス制御: 自社IdP + RBAC
ログ: 自社SIEM
バックアップ: 自社管理
ネットワーク: VPN / private subnet
Enter fullscreen mode Exit fullscreen mode

マルチテナントクラウドでは、答えの一部が「ベンダーを信頼している」になります。それ自体は問題ではありませんが、監査で説明・証明する負荷は高くなります。

セルフホストとクラウド同期の使い分け

セルフホストは常に優れているわけではありません。運用コストがあります。重要なのは、データの機密性とチームの運用能力に合わせて選ぶことです。

要素 クラウド同期型APIツール セルフホスト / オンプレミス / オフライン
セットアップとメンテナンス 数分。ベンダーが実行。 自社でプロビジョニング、パッチ適用、バックアップ、監視。
リアルタイムコラボレーション 強力。分散チーム向け。 可能。ただし自社ネットワークまたはVPN内。
データレジデンシー制御 ベンダーのリージョンとポリシーに依存。 自社で保存場所を指定可能。
攻撃対象領域 ベンダークラウド、アカウント認証、サブプロセッサー。 主に自社境界内。
コンプライアンス適合性（HIPAA、PCI、FedRAMP） ベンダーの認証と契約に依存。 データを自社管理下に保持しやすい。
コストモデル シート課金中心。 ライセンスに加えてインフラと運用時間。
エアギャップ / オフライン 不可。 可能。
災害復旧 ベンダー責任。 自社で設計・テスト。

セルフホストまたはオフラインを選ぶべきケース

以下に当てはまる場合、セルフホストやオフライン運用を検討すべきです。

[ ] 規制産業に属している
[ ] APIツールに本番認証情報を保存している
[ ] 顧客データを含むテストペイロードを扱う
[ ] エアギャップまたは制限ネットワークで開発している
[ ] 法務・セキュリティチームが管理の連鎖を求めている
[ ] 重要データが単一ベンダーに集中しすぎている
Enter fullscreen mode Exit fullscreen mode

この場合、運用コストは無駄ではありません。必要な制御を得るためのコストです。

クラウド同期が向いているケース

以下の場合、クラウド同期は合理的です。

[ ] チームが複数タイムゾーンに分散している
[ ] リアルタイム共同編集が主要ワークフロー
[ ] セルフホストを安全に運用する人員がいない
[ ] APIデータに規制対象情報や機密情報がない
[ ] 初期開発でスピードを優先する必要がある
Enter fullscreen mode Exit fullscreen mode

半端に管理されたセルフホストサーバーは、適切に運用されたクラウドより危険です。

実用的な判断パターン

全社で一律に決めるのではなく、データクラスごとに分けます。

機密度: 高
- 本番トークン
- 顧客データ
- 規制対象データ
=> セルフホスト / オフライン

機密度: 中
- ステージング環境
- 内部API仕様
- テストシナリオ
=> セルフホストまたは制限付きクラウド

機密度: 低
- 公開APIドキュメント
- サンプルリクエスト
- ダミーデータ
=> クラウド同期でも可
Enter fullscreen mode Exit fullscreen mode

この分類は、チーム規模、規制要件、プロダクト成熟度に合わせて定期的に見直します。

ApidogでAPIの信頼できる情報源を自社境界内に保持する

GitHubの侵害を受けてAPIデータの置き場所を見直すなら、実用的な対策は「ツールに決めさせる」のではなく「自分たちで保存場所を選べるツールを使う」ことです。

Apidogは、API設計、デバッグ、テスト、モック、ドキュメント作成を扱うオールインワンAPIプラットフォームです。クラウド製品に加えて、セルフホスト型オンプレミスデプロイメントとオフラインモードを提供します。

Apidogもクラウド製品を提供しており、多くのチームにはそれが最適です。ただし、API仕様、テストデータ、認証情報を自社インフラ内に保持したいチームには、別の選択肢があります。

オンプレミスおよびセルフホスト型デプロイメント

Apidogは、企業向けに完全にセルフホスト型のオンプレミスデプロイメントを提供しています。

Apidogのセルフホストドキュメントによると、主なデプロイ形態は次の通りです。

1. スタンドアロンDocker
   - アプリケーション
   - MySQL
   - Redis
   を自社ホスト上で実行

2. ハイブリッドモデル
   - アプリケーションは自社環境
   - DB / キャッシュは自社管理のマネージドサービス

3. Kubernetes
   - エンタープライズ規模の展開向け
Enter fullscreen mode Exit fullscreen mode

この構成では、以下を自社管理下に置けます。

  • OpenAPI仕様
  • APIコレクション
  • テストデータ
  • 環境変数
  • モック定義
  • アクセスログ
  • ユーザー権限

監査人に「誰がこのデータへアクセスできますか」と聞かれた場合、ベンダークラウド任せではなく、自社のネットワーク制御、ログ、アクセスポリシーで説明できます。

セルフホスト版では、セルフホスト型テストランナーも利用できます。これにより、自動APIテストを社内ネットワーク内で実行できます。実トークンを使うテストや、社内専用サービスへアクセスするテストでは、仕様だけでなくテストトラフィックも自社境界内に保てます。

また、セルフホスト型Apidogにはエンタープライズ向けのユーザー管理とアクセス管理が含まれます。プロジェクトごとにアクセス範囲を制御し、デフォルトで広く共有される状態を避けられます。

ローカルファーストなオフラインモード

完全なオンプレミス展開を行わなくても、機密性の高い作業をローカルに閉じる方法があります。Apidogのオフラインスペースを使うと、単一の開発者または小規模チームがデバイス上で完結して作業できます。

Apidogオフラインスペースのドキュメントによると、すべてのデータはローカルマシンに残り、クラウドにはアップロードされません。バックグラウンド同期もありません。

つまり、次の作業を完全にローカルで実行できます。

- エンドポイント設計
- APIデバッグ
- リクエスト実行
- テスト作成
- 環境変数管理
- グローバル変数管理
Enter fullscreen mode Exit fullscreen mode

オフラインスペースは、シークレット管理で特に有効です。環境変数やグローバル変数はローカルに保存され、クラウド同期されず、チームメンバーにも共有されません。

BEARER_TOKEN=local_only
API_KEY=local_only
DB_CONNECTION_STRING=local_only
Enter fullscreen mode Exit fullscreen mode

ベアラートークン、アカウント認証情報、接続文字列を、ラップトップから外へ出さずにAPIクライアント内で扱えます。エアギャップ環境や制限ネットワークでは、この違いがツール選定の決定要因になります。

実装時の進め方

Apidogで安全な運用を始める場合は、次の順で進めると実装しやすくなります。

1. 現在のAPIツールが同期しているデータを棚卸しする
2. API仕様、コレクション、環境変数、テストデータを分類する
3. 本番シークレットと顧客データをクラウド同期から外す
4. 機密度の高い作業をApidogオフラインスペースに移す
5. チーム共有が必要な高機密データはオンプレミス展開を検討する
6. 低リスクな公開APIドキュメントやサンプルはクラウドで運用する
7. 四半期ごとにアクセス権と同期データをレビューする
Enter fullscreen mode Exit fullscreen mode

開始するには、Apidogをダウンロードし、デスクトップアプリでオフラインスペースを有効化します。エンタープライズ向けにオンプレミス展開を検討する場合は、セルフホストのドキュメントを確認してください。

ApidogがGitHubの侵害を防げたわけではありません。どのAPIツールもそれはできません。Apidogが提供するのは、他社のインシデントが起きてから慌てて調べるのではなく、自社のAPIデータをどこに置くかを意図的に決められる選択肢です。

結論

GitHubの侵害は、クラウドが壊れている証拠ではありません。APIチームにとっては、APIデータの保存場所と同期範囲を見直すきっかけです。

要点は次の通りです。

  • GitHubは、改ざんされたVS Code拡張機能を通じて侵害され、約3,800の内部リポジトリからデータを盗まれました。
  • 多くのチームでは、コードホストがAPIの信頼できる情報源も兼ねています。
  • OpenAPI仕様、コレクション、テストデータ、環境シークレットは、攻撃者にとって価値があります。
  • クラウド同期型APIツールは、ベンダークラウド、アカウント乗っ取り、過度な共有、拡張機能、サブプロセッサーという攻撃対象領域を追加します。
  • 一方で、成熟したクラウドベンダーは社内運用より安全な場合もあります。
  • 規制産業、機密シークレット、エアギャップ環境では、セルフホストまたはオフライン運用が必要になります。
  • 分散チームや低リスクデータでは、クラウド同期が合理的です。
  • 最適な運用は、データクラスごとにクラウド、セルフホスト、オフラインを使い分けることです。

今週やるべき実務タスクはシンプルです。

[ ] APIクライアントが同期しているデータを一覧化する
[ ] API仕様、コレクション、環境変数、テストデータを分類する
[ ] 本番シークレットがクラウド同期されていないか確認する
[ ] 顧客データを含む保存済みリクエスト・レスポンスを削除する
[ ] 高機密データはセルフホストまたはオフラインへ移す
[ ] ワークスペースのメンバーと権限をレビューする
Enter fullscreen mode Exit fullscreen mode

もし答えの一部が「APIデータを自社境界内に置くべき」なら、Apidogはオンプレミスのセルフホストデプロイメントとオフラインモードでそれを実現できます。Apidogをダウンロードして始めるか、エンタープライズ展開を検討している場合はセルフホストのドキュメントを確認してください。

Top comments (0)