開発現場のシークレット管理を情シスはどこまで把握すべき？
左近の情報漏洩のインシデントから、「自社に開発チームがあり、開発環境の管理は任せているものの、どのように管理されているのかまでは把握していない。情報セキュリティを担当する部署として、どこまで情シスが介入すべきか？」というご相談を受けけることも多くなってきました。
この記事では、シークレット管理を切り口に、情シスが開発チームと共有しておきたい管理上のポイントを整理します。
シークレットは、人のIDとは別に管理が必要
APIキー、アクセストークン、秘密鍵、データベースのパスワードなど、システムへの認証に使う秘密情報を「シークレット」と呼びます。人がログインするためのアカウントだけでなく、アプリケーションや自動処理がサービス間で通信するためにも使われます。
ここで大切なのは、人のIDのライフサイクルと、シークレットのライフサイクルは一致しないということです。
従業員のアカウントを停止しても、その従業員が発行したAPIキーが別のサービスで有効なまま残ることがあります。反対に、個人アカウントに紐づいた認証情報を業務で使っていると、アカウント停止によって自動処理まで止まるかもしれません。
従業員のアカウントを停止したり管理したりするだけでは、開発環境のアクセス権限が適切に引き継がれたか、または、不要な認証情報が失効できるとは限りません。
このため、シークレット管理は、安全な保管場所を用意するだけでなく、人やNHI（Non-Human Identity）が、どのシステムに、どのような権限でアクセスできるのかを把握する必要があります。
開発のシークレットはどこでどう使われるのか
シークレットは、開発者が直接扱うものだけではありません。ツールや自動処理が、作業の裏側で利用していることもあります。
場面 | 利用例 | 情シスが知っておきたいリスク |
|---|---|---|
開発端末 | APIキー、SSH秘密鍵、ログイン済みセッション | 端末の侵害をきっかけに、接続先まで不正に操作される可能性がある |
ソースコード管理 | リポジトリや設定ファイル内の認証情報 | 誤ってコミットしてしまった秘匿情報を含む変更がレポジトリに存在することがある |
CI/CD | テスト・ビルド・デプロイで使うクラウド認証情報 | ワークフローの設定や権限によって、想定外の処理に使われる可能性がある |
アプリケーション・ライブラリの配布 | 配布アプリ、公開パッケージ、コンテナイメージ | 配布物に秘密情報が混入すると、第三者に取得される可能性がある |
クラウド・本番環境 | アプリケーションやサービスアカウントの認証情報 | 権限が広すぎたり、長期間有効なキーが存在する可能性がある |
SaaS・API連携 | OAuthトークン、APIキー | 連携元の問題が、連携先のデータや別のサービスに波及することがある |
運用・保守 | 定期ジョブ、バックアップ、監視の認証情報 | 担当者や利用目的が分からなくなり、失効できないことがある |
情シスがすべての技術を理解する必要はありません。まずは、どの業務やシステムで、どのような認証情報が使われているのかを知ることが重要です。
漏えいは「キーが見られる」だけでは終わらない
シークレットが漏えいした場合、影響はその値が保存されていた場所だけにとどまりません。権限が強ければ、本番環境の変更やデータへのアクセスにつながることがあります。外部サービスとの連携に使われていれば、被害が別のサービスや組織に広がる可能性もあります。
例えば、2025年に発生した開発ツールNxのサプライチェーン攻撃では、GitHub Actionsのワークフローに存在した脆弱性を悪用され、npmへのパッケージ公開に使うトークンが窃取されました。攻撃者はそのトークンを使って不正なパッケージを公開し、インストールした利用者の開発環境から認証情報などを収集・流出させました。
この事例は、CI/CDの認証情報が侵害されることで、配布物を経由して開発者の端末にまで被害が広がることを示しています。
また、2025年にGoogleの脅威インテリジェンスチームが報告したSalesloft Driftの事例では、外部サービスとの連携に使われるOAuthトークンが悪用され、Salesforce環境からデータが窃取されました。
自社が直接管理するアカウントだけでなく、外部サービスに許可したアクセス権限も管理対象であることが分かります。
このため、シークレット対策では「安全な保管場所を用意したか」だけでなく、どのユーザーやシステムが、何のために、どの権限でアクセスできるのかを確認する必要があります。
対策は、保管・検出・権限・失効を組み合わせる
開発チームが中心となって技術的な対策を実装し、情シスは組織全体で管理状況を把握できるよう支援する、という分担が現実的です。
代表的な対策は次のとおりです。
1. 専用の仕組みで保管する
シークレット管理サービスやクラウドの標準機能を使い、ソースコードや共有ファイルに認証情報を直接書かないようにします。保管先を用意するだけでなく、誰が取得できるかも制御します。
代表的なものに、AWS Secrets ManagerやAzure Key Vaultなどのクラウド標準サービス、Keeper Secrets ManagerやHashiCorp Vaultなど、複数のクラウドやオンプレミス環境を横断して利用できるサービスがあります。
クラウド標準サービスは各クラウドの認証・権限管理との連携がしやすく、マルチクラウド対応製品は異なる環境で共通の管理方式を採用しやすいという特徴があります。
2. コードや配布物への混入を防ぎ、検出する
リポジトリへのプッシュ前やCI/CDでシークレットを検査します。GitHub Secret ScanningやPush Protectionのほか、Gitleaks、TruffleHog、GitGuardianなどが選択肢になります。
配布アプリケーションやコンテナイメージなども検査対象になります。ただし、こうした検出ツールだけですべての漏えいを防げるわけではありません。
3. 長期間有効な認証情報を減らす
可能な場面では、固定のアクセスキーではなく、短期間だけ有効な認証情報を利用します。
例えば、アプリケーションのデプロイなどの自動処理では、OIDCによるID連携を使い、実行時に都度必要な認証情報を取得する方法があります。これにより、長期間有効なアクセスキーをあらかじめ保存しておく必要がなくなり、漏えい時のリスクを減らせます。
4. 権限とライフサイクルを管理する
認証情報には必要最小限の権限を付与し、用途、管理責任者、更新・失効の手順を明確にします。
また、シークレットの露出やアクセス権限のリスクを把握するため、WizやMicrosoft Defender for Cloud、Google Security Command Centerなどのクラウドセキュリティ管理サービスを活用する方法もあります。
製品や実装方法は、利用するクラウド、開発環境、運用体制によって異なります。重要なのは、特定の製品を導入すること自体ではなく、発行から利用、更新、失効までのライフサイクルを管理できる状態にすることです。
情シスが把握するのは「値」ではなく「管理状況」
シークレット管理の実務は、開発チームが担うことがほとんどですが、人のID管理やセキュリティ対策、インシデント対応などは、開発チームだけでは完結しません。
情シスが関わることで、退職・異動時のアクセス管理を組織全体で統一したり、共通のID基盤や管理の仕組みを活用して開発チームの負担を減らすこともできます。また、属人化を防ぎ、システムを安全に運用し続けることにもつながります。
もちろん、情シスがすべてのシークレットを集めて閲覧したり、技術的な管理を引き受けたりする必要はありません。開発チームとの役割分担を明確にしたうえで、管理の仕組みと責任者を把握することが大切です。
開発チームとの会話では、個々の対策の実装方法よりも、次の4点から管理状況を確認しましょう。
- 利用範囲：本番環境や重要なデータへのアクセス、外部SaaSとの連携など、どの業務やシステムでシークレットを使っているか。
- 責任の所在：管理責任者は誰か。退職・異動の際にも、引き継ぎ先が分かる状態になっているか。
- 監査・追跡：認証情報がいつ、どこから、どのように使われたかを確認できるログが取得・保管されているか。
- 対応体制：不要になったときや漏えいが疑われたとき、誰に連絡すれば、影響を確認して更新・失効を進められるか。
情シスが把握したいのは、シークレットの値や細かな設定ではなく、どこで使われ、誰が責任を持ち、利用状況を追跡でき、必要なときに対応できるかという全体像です。
漏えい時に対応できる体制を整えよう
認証情報の漏えいが疑われた場合は、セキュリティインシデントとして、影響の調査から封じ込め、復旧、再発防止まで対応する必要があります。開発チーム、情シス、セキュリティ担当者が連携し、次のような対応を進めます。
- 対象と影響範囲を確認する：漏えいした可能性のある認証情報と、アクセス可能なシステム・データを特定し、不正利用の有無を調査します。
- 被害を封じ込める：認証情報の失効やアクセス制限などにより、不正利用を防ぎます。
- 安全に復旧する：認証情報を再発行し、利用中のアプリや自動処理を更新して、正常な稼働を確認します。
- 原因と対策を見直す：漏えいの原因を調査し、権限設定や運用を改善して再発を防ぎます。
実際には、調査と封じ込めを並行して進めることもあります。また、認証情報の失効が業務システムの停止につながる場合もあるため、サービスへの影響を考慮した判断が必要です。
だからこそ、平時から「誰が失効できるか」「どのシステムに影響するか」「誰が対応を判断するか」を明確にしておくことが重要です。
まずは開発チームと管理状況を共有しよう
開発環境のセキュリティは、シークレット管理だけで完結するものではありません。しかし、シークレットの管理状況を確認することは、システムの構成や外部サービスとの連携、アクセス権限の実態を知るきっかけにもなります。
まずは本番環境や重要なデータに関わるシークレットから、開発チームと確認してみましょう。
シークレットの管理主体は、企業の規模や開発体制によって異なります。しかし、開発環境のアクセス管理は、人のID管理や組織のセキュリティとも密接に関わります。情シスも開発チームと管理状況を共有し、必要なときに連携できる関係を築いておくことが大切です。
ID・アクセス管理をお任せください。
ZUNDAでは、Keeper Secrets Managerによるシークレット管理をはじめ、OktaやMicrosoft Entra IDによるID管理、GitHub Enterprise やその他クラウド環境のセキュリティ対策など、開発環境を含むIT環境の整備を支援しています。
個別製品の導入だけでなく、現在の管理状況の整理から、開発チームと情シスの役割分担、認証情報のライフサイクル管理や運用体制の整備まで、お気軽にご相談ください。