Bitbucketでの機密情報の管理どうしてる？環境変数やVaultを使って安全に運用するセキュリティ対策

Bitbucketでソースコードを管理していると、APIキーやデータベースの認証情報、クラウドサービスのアクセスキーなど、機密情報をどのように扱うべきか悩む場面は少なくありません。
開発スピードを優先するあまり、設定ファイルに直接パスワードを書き込んだり、リポジトリに誤って認証情報をコミットしてしまったりすると、重大なセキュリティインシデントにつながる可能性があります。

特に近年は、ソフトウェアサプライチェーンを狙った攻撃や、Gitリポジトリ上の漏えい情報を自動収集する仕組みが広く存在しているため、「非公開リポジトリだから安全」という考え方は通用しません。
機密情報はソースコードとは分離し、適切なアクセス制御と監査が可能な形で管理することが重要です。

Bitbucketには環境変数を利用したシークレット管理機能が用意されており、CI/CDパイプラインと組み合わせることで、安全性を高めながら運用できます。
また、より高度な要件がある場合は、HashiCorp Vaultのようなシークレット管理基盤を導入することで、認証情報の集中管理や動的な資格情報の発行といった運用も実現できます。

本記事では、Bitbucketで機密情報を管理する際の基本的な考え方から、環境変数を利用した実践的な方法、Vaultとの連携によるセキュリティ強化までを体系的に解説します。

なぜ機密情報をGitに保存してはいけないのか
Bitbucketの環境変数を活用する方法
Vaultを利用した高度なシークレット管理
運用時に注意すべきセキュリティ上のポイント

これからBitbucketのセキュリティ対策を見直したい方や、チーム開発における認証情報の管理方法を改善したい方は、ぜひ参考にしてください。

Bitbucketで機密情報管理が重要になる理由
1. ソースコード管理とシークレット管理は分離すべき
2. 認証情報漏えいが引き起こすセキュリティリスク
Gitリポジトリに機密情報を保存してはいけない理由
1. コミット履歴に残る情報は完全削除が難しい
2. 非公開リポジトリでも安全とは限らない
Bitbucketで利用できる機密情報管理の方法
1. Repository Variablesとは
2. Workspace Variablesとの違い
環境変数を使った安全なシークレット管理の実践方法
Vaultを利用した高度なシークレット管理
BitbucketとVaultを連携する構成例
1. CI/CDパイプラインからVaultへアクセスする流れ
2. クラウド環境での運用パターン
機密情報管理で実践したいセキュリティ対策
Bitbucketの機密情報管理は環境変数とVaultの併用が鍵

Bitbucketで機密情報管理が重要になる理由

Bitbucketは多くの開発現場で利用されているGitベースのソースコード管理サービスですが、単にコードを保存する場所としてだけではなく、チーム開発やCI/CDの中核として利用されるケースも増えています。
そのため、ソースコードだけでなく、アプリケーションが利用するAPIキーやデータベースの認証情報、クラウドサービスのアクセスキーなどの機密情報をどのように扱うかが重要な課題になります。

特に現代のシステム開発では、外部サービスとの連携が一般的になっています。
決済サービス、メール配信サービス、クラウドストレージ、データベースなど、多くのサービスが認証情報によって保護されています。
そのため、認証情報が漏えいすると、単なるコード流出以上の被害につながる可能性があります。

安全な開発環境を構築するためには、「ソースコード」と「機密情報」を別物として管理する考え方が欠かせません。
これは個人開発だけでなく、チーム開発や企業システムの運用においても基本原則となっています。

ソースコード管理とシークレット管理は分離すべき

ソースコード管理システムの役割は、プログラムの変更履歴を管理し、開発者同士の共同作業を効率化することです。
一方で、シークレット管理の目的は、認証情報や秘密鍵などの機密データを安全に保管し、必要なタイミングでのみ利用できるようにすることです。

この2つは役割が根本的に異なるため、同じ場所で管理するべきではありません。

例えば、以下のような情報はシークレットとして扱うべき対象です。

APIキー
アクセストークン
データベース接続情報
SSH秘密鍵
クラウドサービスの認証情報
暗号化キー

開発初期には手軽さを優先して設定ファイルへ直接記述したくなることがあります。
しかし、この方法には大きな問題があります。
Gitではすべての変更履歴が保存されるため、一度コミットされた機密情報は後から削除しても履歴上に残る可能性があるからです。

例えば、以下のような設定ファイルを誤ってコミットしてしまうケースは珍しくありません。

database:
  host: production-db.example.com
  username: admin
  password: SuperSecretPassword

このような情報がリポジトリに含まれている状態では、アクセス権を持つメンバー全員が認証情報を閲覧できるだけでなく、将来的な権限管理も困難になります。

そのため、現在のベストプラクティスでは、ソースコードには機密情報を書かず、環境変数やシークレット管理ツールから取得する構成が推奨されています。

認証情報漏えいが引き起こすセキュリティリスク

認証情報の漏えいは、単なる設定ミスでは済まない場合があります。
攻撃者が有効な認証情報を取得すると、正規ユーザーとしてシステムへアクセスできるためです。

特に危険性が高いのは、クラウドサービスのアクセスキーや本番データベースの認証情報です。
これらが漏えいした場合、以下のような被害が発生する可能性があります。

リスク	発生する被害	影響範囲
不正アクセス	システムへの侵入	サービス全体
情報漏えい	顧客データの流出	利用者全体
データ改ざん	レコードの変更・削除	データベース
不正利用	クラウドリソースの悪用	インフラ全体

近年では、公開されたGitリポジトリを自動的に巡回し、認証情報を収集するボットも存在します。
そのため、誤って公開してしまった情報は短時間で第三者に発見される可能性があります。

また、プライベートリポジトリだから安全という考え方も危険です。
内部関係者による情報持ち出しや、アカウントの乗っ取り、権限設定の不備などによって、機密情報が外部へ流出するケースもあります。

セキュリティの観点では、「認証情報はいずれ漏れる可能性がある」という前提で設計することが重要です。
そのためには、認証情報をリポジトリに保存しないことに加え、定期的なローテーション、最小権限の原則、アクセス監査などを組み合わせた多層防御を実践する必要があります。

Bitbucketを安全に運用するためには、単にソースコードを管理するだけではなく、機密情報を適切に分離・保護する仕組みを導入することが不可欠です。
環境変数やVaultなどのシークレット管理手法を活用することで、漏えいリスクを大幅に低減できるようになります。

Gitリポジトリに機密情報を保存してはいけない理由

Gitは優れたバージョン管理システムですが、その設計思想を理解せずに運用すると、機密情報の漏えいリスクを高める原因になることがあります。
特にAPIキーやパスワード、クラウドサービスのアクセスキーなどをリポジトリ内に保存してしまう行為は、セキュリティ上の大きな問題につながります。

開発現場では、「一時的に設定ファイルへ書いただけ」「あとで削除するつもりだった」といった理由で認証情報がコミットされるケースがあります。
しかし、Gitの仕組み上、一度記録された情報は想像以上に長期間残り続けます。

また、非公開リポジトリを利用している場合でも、機密情報の保護が保証されるわけではありません。
安全なシステム運用を実現するためには、Gitリポジトリの役割と限界を正しく理解することが重要です。

コミット履歴に残る情報は完全削除が難しい

Gitでは、ファイルの現在の状態だけでなく、過去の変更履歴も含めて管理されます。
そのため、機密情報を含むファイルをコミットした後に内容を修正したとしても、過去のコミットには元の情報が残っています。

例えば、以下のような流れを考えてみます。

APIキーを設定ファイルへ記述する
Gitへコミットする
誤りに気付きAPIキーを削除する
再度コミットする

一見すると機密情報は削除されたように見えます。
しかし実際には最初のコミットに情報が保存されているため、履歴を辿れば閲覧できてしまいます。

Gitでは次のようなコマンドによって過去の履歴を参照できます。

git log
git show <commit-hash>

つまり、現在のファイルに機密情報が存在しなくても、過去のコミットから取得できる可能性があるのです。

さらに問題なのは、履歴の書き換えを行った場合でも完全な削除が保証されない点です。

履歴を修正する方法としては以下のような手段があります。

git filter-repo
git filter-branch
BFG Repo-Cleaner

しかし、これらを実施しても既に他の開発者がリポジトリをクローンしていた場合、そのコピーには古い履歴が残っています。
また、CI/CD環境やバックアップサーバー、ミラーリポジトリなどにも情報が残存している可能性があります。

そのため、認証情報を誤ってコミットした場合は単純に履歴を削除するだけでなく、以下の対応が必要になります。

対応内容	目的	優先度
認証情報の無効化	不正利用防止	高
新しい認証情報の発行	サービス継続	高
Git履歴の修正	再発防止	中
アクセスログの確認	被害調査	中

重要なのは、「削除すれば大丈夫」ではなく、「一度漏えいしたものとして扱う」という考え方です。

非公開リポジトリでも安全とは限らない

機密情報をリポジトリへ保存してしまう理由として、「プライベートリポジトリだから問題ない」という認識を持つケースがあります。
しかし、これは非常に危険な考え方です。

確かに公開リポジトリと比較すると、プライベートリポジトリはアクセス制限が施されています。
しかし、アクセス権を持つユーザーが増えるほど、情報漏えいの可能性も高まります。

例えば、以下のような経路で機密情報が流出することがあります。

開発者アカウントの乗っ取り
不適切な権限付与
退職者アカウントの管理漏れ
CI/CDシステムの設定ミス
誤ったリポジトリ共有
内部不正

セキュリティの世界では、「内部は安全」という前提で設計することは推奨されていません。
これをゼロトラストの考え方と呼びます。

特にクラウドサービスと連携している環境では、一つのアクセスキーが漏えいしただけで大規模な被害につながることがあります。

例えば、クラウド環境の管理権限を持つキーが漏えいした場合、攻撃者は以下のような操作を実行できる可能性があります。

仮想サーバーの作成
ストレージ内データの取得
データベースの閲覧
ネットワーク設定の変更
ログの削除

これらはすべて正規の認証情報を利用して行われるため、不正アクセスの検知が難しくなる場合があります。

また、近年はサプライチェーン攻撃への対策も重要視されています。
攻撃者はアプリケーションそのものではなく、開発基盤やCI/CDパイプラインを狙うケースが増えています。
そのため、Bitbucketのようなソースコード管理サービスに保存された機密情報は、攻撃対象として非常に価値が高い存在になっています。

安全な運用を実現するためには、Gitリポジトリを機密情報の保管場所として利用しないことが基本です。
認証情報は環境変数やシークレット管理サービスへ分離し、リポジトリには機密データを含めない運用を徹底することが、長期的なセキュリティ向上につながります。

Bitbucketで利用できる機密情報管理の方法

Bitbucketでは、機密情報をソースコードから分離して管理するための仕組みが提供されています。
特にCI/CD環境であるBitbucket Pipelinesを利用する場合、APIキーやデータベース接続情報、クラウドサービスの認証情報などを安全に扱うことが重要になります。

もし認証情報をソースコードへ直接記述してしまうと、誤ってGitへコミットされるリスクが発生します。
そのため、現代的な開発環境では、機密情報を専用の管理機能へ保存し、実行時にのみ参照する運用が一般的になっています。

Bitbucketでは主に以下の方法で機密情報を管理できます。

Repository Variables
Workspace Variables
Deployment Variables
外部シークレット管理サービスとの連携

小規模なプロジェクトではRepository Variablesだけでも十分なケースがありますが、複数のリポジトリや複数環境を運用する場合はWorkspace Variablesや外部のシークレット管理基盤との組み合わせが効果的です。

まずはBitbucket標準機能として最も利用されるRepository Variablesについて理解しておきましょう。

Repository Variablesとは

Repository Variablesは、特定のリポジトリに対して環境変数を設定できる機能です。

登録した値はBitbucketの管理画面上で保持され、Bitbucket Pipelinesの実行時に環境変数として利用できます。
そのため、パスワードやAPIキーをソースコードへ埋め込む必要がなくなります。

例えば、外部APIを利用するアプリケーションを開発している場合、次のような情報をRepository Variablesへ登録できます。

変数名	用途	機密性
API_KEY	API認証	高
DB_HOST	データベース接続先	中
DB_PASSWORD	データベース認証	高
ACCESS_TOKEN	サービス連携認証	高

アプリケーション側では環境変数を参照するだけで済みます。

例えばシェルスクリプトであれば次のように利用できます。

echo "$API_KEY"

この仕組みによって、ソースコード内へ認証情報を記述する必要がなくなります。

また、Bitbucketでは変数を「Secured」として登録できます。
Secured属性を有効化すると、値がログへ出力される際にマスク処理が行われるため、CI/CDログから機密情報が漏えいするリスクを低減できます。

Repository Variablesには以下の特徴があります。

特定のリポジトリだけで利用できる
Pipelinesから簡単に参照できる
ソースコードと分離して管理できる
ログマスキング機能を利用できる

一方で、同じ認証情報を複数リポジトリで利用する場合には管理が煩雑になるという課題があります。

例えば10個のリポジトリで同じAPIキーを利用している場合、キーを変更するたびに10箇所の設定を更新しなければなりません。

このような問題を解決するために用意されているのがWorkspace Variablesです。

Workspace Variablesとの違い

Workspace Variablesは、Bitbucketのワークスペース全体で共有できる環境変数です。

Repository Variablesが「リポジトリ単位」の設定であるのに対し、Workspace Variablesは「組織単位」の設定と考えると理解しやすいでしょう。

両者の違いを整理すると次のようになります。

項目	Repository Variables	Workspace Variables
適用範囲	単一リポジトリ	ワークスペース全体
管理対象	プロジェクト固有情報	共通認証情報
変更時の影響	対象リポジトリのみ	全リポジトリ
運用規模	小〜中規模	中〜大規模

例えば、社内で共通利用するクラウド認証情報や監視サービスのトークンなどはWorkspace Variablesで管理すると効率的です。

一方で、プロジェクトごとに異なる設定値はRepository Variablesで管理する方が適しています。

実際の運用では、次のような使い分けが推奨されます。

共通APIキー → Workspace Variables
共通通知サービスのトークン → Workspace Variables
プロジェクト固有のDB接続情報 → Repository Variables
プロジェクト固有の外部サービス認証情報 → Repository Variables

ただし、Workspace Variablesは影響範囲が広いため、変更時には十分な注意が必要です。

例えば共通認証情報を更新した場合、その値を利用しているすべてのリポジトリに影響が及びます。
そのため、変更管理や権限管理を適切に行うことが重要です。

また、大規模環境ではWorkspace Variablesだけでは管理が難しくなる場合があります。
認証情報の有効期限管理やアクセス監査、動的な認証情報発行などが求められる場合は、Vaultのような専用シークレット管理基盤の導入も検討する価値があります。

Bitbucket標準機能だけでも一定レベルのセキュリティを確保できますが、Repository VariablesとWorkspace Variablesの違いを理解し、用途に応じて適切に使い分けることが、安全な機密情報管理の第一歩になります。

環境変数を使った安全なシークレット管理の実践方法

機密情報を安全に管理する方法として、現在最も広く採用されているのが環境変数の活用です。
環境変数を利用することで、APIキーやデータベースの認証情報をソースコードから分離できるため、Gitリポジトリへの誤コミットを防ぎやすくなります。

特にBitbucket Pipelinesを利用したCI/CD環境では、ビルドやデプロイ時に認証情報が必要になる場面が多くあります。
しかし、その情報を設定ファイルへ直接記述すると、セキュリティリスクが大幅に高まります。

環境変数を利用したシークレット管理には以下のメリットがあります。

ソースコードと機密情報を分離できる
認証情報の更新が容易になる
環境ごとの設定変更が簡単になる
Git履歴へ機密情報が残らない
CI/CDとの親和性が高い

ただし、環境変数を利用すれば自動的に安全になるわけではありません。
設定方法や運用方法を誤ると、ログやデバッグ出力から機密情報が漏えいする可能性もあります。
そのため、正しい設定手順と運用ルールを理解しておくことが重要です。

Bitbucket Pipelinesで環境変数を設定する手順

Bitbucket Pipelinesでは、管理画面から環境変数を登録できます。

基本的な流れは以下のとおりです。

対象リポジトリを開く
Repository Settingsを選択する
Pipelines設定画面へ移動する
Repository Variablesを開く
変数名と値を登録する
必要に応じてSecuredを有効化する

例えば、外部APIを利用するアプリケーションの場合は以下のような変数を登録できます。

変数名	用途	推奨設定
API_TOKEN	API認証	Secured
DB_PASSWORD	DB認証	Secured
DB_HOST	接続先ホスト	通常
REGION	実行リージョン	通常

Securedを有効にすると、ビルドログへ値がそのまま出力されることを防止できます。

また、Bitbucket Pipelinesでは登録済みの環境変数をそのまま利用できます。

例えばデプロイ処理では次のような形で参照できます。

pipelines:
  default:
    - step:
        script:
          - deploy-tool --token "$API_TOKEN"

この構成であれば、認証情報をYAMLファイルへ直接記述する必要がありません。

重要なのは、パイプライン設定ファイルそのものには機密情報を書かないことです。
変数名だけを記述し、実際の値はBitbucket側で管理するという原則を徹底することが安全な運用につながります。

アプリケーションから環境変数を参照する方法

環境変数を登録したら、次はアプリケーション側で利用する必要があります。

一般的な設計では、設定ファイルへ認証情報を書き込むのではなく、起動時に環境変数から読み込みます。

例えばNode.js環境では以下のように取得できます。

const apiToken = process.env.API_TOKEN;
if (!apiToken) {
  throw new Error("API_TOKEN is not configured");
}

PythonやGo、Javaなど多くの言語でも同様の仕組みが用意されています。

ここで重要なのは、環境変数が存在しない場合の例外処理を実装することです。

認証情報が取得できない状態で処理を続行すると、予期しないエラーやセキュリティ上の問題につながる可能性があります。

また、環境変数の値をログへ出力しないことも重要です。

以下のような実装は避けるべきです。

認証情報をデバッグログへ出力する
エラー発生時に認証情報を表示する
設定内容をそのまま画面表示する

環境変数を利用していても、ログ経由で漏えいしてしまえば意味がありません。

そのため、機密情報を扱う箇所では常に「ログへ出力されないか」という観点でコードレビューを行うことが推奨されます。

環境ごとに認証情報を分離するベストプラクティス

実運用では、開発環境と本番環境で同じ認証情報を使うべきではありません。

環境ごとに認証情報を分離することで、万が一情報が漏えいした場合でも影響範囲を限定できます。

代表的な環境区分は以下のとおりです。

環境	用途	認証情報
Development	開発作業	開発用
Staging	検証環境	検証用
Production	本番運用	本番用

例えば開発環境で使用しているAPIキーが漏えいした場合でも、本番環境のキーが分離されていれば本番サービスへの影響を防げます。

また、データベースについても同様です。

開発環境から本番データベースへ接続できる構成は避けるべきです。
誤操作によるデータ破壊や情報漏えいのリスクが高まるためです。

環境分離を実践する際には次の原則を意識するとよいでしょう。

環境ごとに認証情報を発行する
環境ごとにアクセス権限を分離する
本番用シークレットへのアクセスを制限する
定期的に認証情報をローテーションする
利用状況を監査ログで確認する

さらに組織規模が大きくなると、環境変数だけでは管理が難しくなる場合があります。
その場合はVaultのようなシークレット管理基盤を導入し、認証情報の集中管理や動的発行を行うことが有効です。

とはいえ、多くのプロジェクトでは環境変数を適切に利用するだけでも大幅なセキュリティ向上が期待できます。
まずは「認証情報をコードに書かない」「環境ごとに分離する」という基本原則を徹底することが、安全なBitbucket運用への第一歩になります。

Vaultを利用した高度なシークレット管理

環境変数はシークレット管理の基本的な手法として非常に有効ですが、システム規模が大きくなるにつれて限界も見えてきます。
例えば、複数のクラウドサービスやデータベースを利用している環境では、管理対象となる認証情報が数十から数百に及ぶことも珍しくありません。

また、複数の開発チームや運用チームが存在する組織では、誰がどの認証情報へアクセスできるのかを厳密に管理する必要があります。
環境変数だけでは認証情報の配布や更新作業が煩雑になり、運用負荷やセキュリティリスクが増大する可能性があります。

こうした課題を解決するために利用されるのが、専用のシークレット管理基盤です。
その中でも特に広く採用されているのがHashiCorp Vaultです。

Vaultは単なるパスワード保管庫ではなく、認証情報の集中管理、アクセス制御、監査、動的な資格情報発行などを実現する包括的なセキュリティプラットフォームとして設計されています。

HashiCorp Vaultとは何か

HashiCorp Vaultは、HashiCorp社が開発しているシークレット管理ソフトウェアです。

APIキーやデータベース認証情報、クラウドサービスのアクセスキー、証明書、暗号鍵などを一元管理できることが特徴です。

従来の環境では、認証情報が以下のように分散して管理されるケースが少なくありません。

CI/CDツールの環境変数
サーバー上の設定ファイル
個人のPC内の設定
クラウドサービスごとの設定画面
ドキュメント管理ツール

このような状態では、認証情報の管理場所が増え、更新漏れやアクセス権限の不整合が発生しやすくなります。

Vaultを導入すると、認証情報の保管場所を一箇所へ集約できます。

Vaultの主な機能を整理すると次のようになります。

機能	概要	用途
Secret Storage	シークレット保管	APIキー管理
Authentication	認証機能	利用者識別
Authorization	権限制御	アクセス管理
Audit Log	監査ログ	利用履歴確認
Dynamic Secrets	動的資格情報発行	DB認証情報生成

特に企業システムでは、誰がどの認証情報へアクセスしたかを追跡できる監査機能が重要視されています。

単に秘密情報を保存するだけではなく、利用状況まで管理できる点がVaultの大きな特徴です。

環境変数管理との違いとメリット

環境変数による管理とVaultによる管理は、目的が似ているようで実際には大きく異なります。

環境変数は「認証情報を安全に渡す仕組み」であるのに対し、Vaultは「認証情報を統合的に管理する仕組み」と考えると理解しやすいでしょう。

両者を比較すると以下のようになります。

項目	環境変数	Vault
管理場所	各サービスごと	一元管理
アクセス制御	限定的	詳細設定可能
監査ログ	基本的に無し	標準搭載
資格情報更新	手動	自動化可能
動的発行	不可	可能

小規模な開発環境では環境変数だけでも十分です。
しかし、以下のような状況ではVaultの導入効果が高くなります。

複数クラウドを利用している
マイクロサービス構成を採用している
数十以上の認証情報を管理している
厳格な監査要件がある
定期的な資格情報更新が必要

例えば、環境変数だけで管理している場合、データベースのパスワード変更時には各サーバーやCI/CD環境の設定を個別に更新しなければなりません。

一方でVaultを利用すれば、アプリケーションは常にVaultから最新の認証情報を取得できるため、運用負荷を大幅に軽減できます。

また、認証情報を利用するアプリケーション側から見ると、「どこに保存されているか」を意識する必要がなくなる点も大きなメリットです。

動的シークレットとアクセス制御の仕組み

Vaultが特に評価されている理由の一つが、動的シークレット（Dynamic Secrets）の仕組みです。

通常の環境変数管理では、あらかじめ発行された固定の認証情報を保存します。

しかし、この方法には次のような問題があります。

長期間同じ認証情報を利用する
漏えい時の影響が大きい
更新作業が手動になる
利用者ごとの追跡が難しい

Vaultでは必要なタイミングで一時的な認証情報を生成できます。

例えば、アプリケーションがデータベースへ接続する際、Vaultへ認証を行うと短期間だけ有効なデータベースユーザーが自動生成されます。

利用イメージは以下の流れになります。

アプリケーションがVaultへ認証する
Vaultが一時的な認証情報を生成する
アプリケーションがDBへ接続する
有効期限が切れると自動失効する

この方式では、認証情報が漏えいした場合でも利用可能な期間が限定されるため、被害を最小限に抑えられます。

さらにVaultでは細かなアクセス制御も可能です。

例えば以下のようなポリシー設計が行えます。

開発チームは開発環境のみアクセス可能
運用チームは本番環境を管理可能
CI/CDはデプロイ時のみ認証可能
監査担当者はログ閲覧のみ可能

このような権限管理は、最小権限の原則を実現するうえで非常に重要です。

また、すべてのアクセスは監査ログへ記録されるため、認証情報の利用履歴を追跡できます。
万が一不正利用が発生した場合でも、誰がいつアクセスしたのかを調査しやすくなります。

環境変数はシークレット管理の第一歩として有効ですが、組織規模やシステム規模が拡大すると限界が生じます。
Vaultはその先にある高度なシークレット管理基盤として、認証情報の一元管理、動的発行、監査、アクセス制御を実現し、より強固なセキュリティ体制の構築を支援してくれます。

BitbucketとVaultを連携する構成例

Bitbucketの環境変数機能は非常に便利ですが、大規模なシステムや厳格なセキュリティ要件を持つ環境では、それだけでは十分でない場合があります。
特に複数のアプリケーションやクラウドサービスを運用している場合、認証情報の管理数が増加し、更新や監査の負荷も高くなります。

そこで有効になるのが、BitbucketとHashiCorp Vaultを連携させる構成です。

この構成では、認証情報そのものをBitbucketへ保存するのではなく、Vault側で一元管理します。
Bitbucket Pipelinesは必要なタイミングでVaultへアクセスし、一時的な認証情報や最新のシークレットを取得して利用します。

この方式には次のようなメリットがあります。

シークレットの集中管理が可能
認証情報のローテーションを容易に実施できる
利用履歴を監査ログで追跡できる
最小権限の原則を実装しやすい
認証情報の長期保存を回避できる

特にクラウドネイティブな環境やマイクロサービス構成では、BitbucketとVaultの連携は非常に相性の良い設計といえます。

CI/CDパイプラインからVaultへアクセスする流れ

Bitbucket PipelinesとVaultを連携する場合、基本的な考え方は「パイプラインが直接シークレットを保持しない」という点にあります。

従来の環境変数運用では、認証情報をBitbucket側へ保存しておき、ビルドやデプロイ時に利用します。

一方でVault連携では、パイプラインはVaultへ認証を行い、その結果として必要な認証情報を取得します。

処理の流れを整理すると以下のようになります。

Bitbucket Pipelinesが開始される
Vaultへ認証を行う
Vaultが認証結果を検証する
必要なシークレットを取得する
ビルドやデプロイを実行する
利用後はシークレットを破棄する

この構成では、認証情報を長期間保持する必要がありません。

概念的な構成は次のようになります。

Bitbucket Pipelines
        │
        ▼
     Vault
        │
 ┌──────┼──────┐
 ▼      ▼      ▼
DB    AWS    API

パイプラインは中央のVaultだけと通信し、データベースやクラウドサービスの認証情報を直接管理しません。

また、Vaultではトークンベース認証やJWT認証など複数の認証方式を利用できます。

近年ではOIDC（OpenID Connect）を利用した認証方式も広く採用されています。

この方式では固定の認証情報を保存する必要がなくなるため、漏えいリスクを大幅に低減できます。

さらに、認証後に取得するシークレットには有効期限を設定できます。

項目	固定認証情報	Vault利用時
有効期限	長期間	短期間
更新作業	手動	自動化可能
漏えい時の影響	大きい	限定的
利用履歴	追跡困難	監査可能

このように、CI/CD環境とVaultを連携することで、セキュリティレベルを大きく向上させることができます。

クラウド環境での運用パターン

Vaultはオンプレミス環境でも利用できますが、現在はクラウド環境で運用されるケースが増えています。

特にAWSやGoogle Cloud、Microsoft Azureなどを利用している場合は、各クラウドサービスの認証基盤とVaultを統合できます。

代表的な運用パターンを整理すると以下のようになります。

構成パターン	特徴	適用規模
単一Vault構成	シンプル	小〜中規模
高可用性構成	冗長化対応	中〜大規模
マルチリージョン構成	災害対策	大規模
マルチクラウド構成	複数クラウド対応	エンタープライズ

小規模な環境では単一インスタンスのVaultでも十分です。

しかし本番システムではVault自体が停止すると認証情報を取得できなくなるため、高可用性構成が推奨されます。

一般的には複数ノードでクラスタを構成し、障害発生時にもサービスを継続できるようにします。

また、クラウド環境ではIAMとVaultを連携するケースも多く見られます。

例えばAWS環境では以下のような構成が実現できます。

EC2がIAMロールで認証
VaultがIAM情報を検証
Vaultが一時的な認証情報を発行
アプリケーションがクラウドサービスへ接続

この仕組みにより、アクセスキーをサーバーへ保存する必要がなくなります。

さらにKubernetes環境では、PodごとにVault認証を行う構成も一般的です。

アプリケーション起動時にVaultからシークレットを取得し、必要な設定だけをメモリ上へ展開することで、設定ファイルへの保存を回避できます。

クラウド環境でVaultを運用する際には、以下のポイントを意識すると効果的です。

Vault自体の高可用性を確保する
OIDCやIAMによる認証を活用する
固定認証情報を極力排除する
監査ログを長期保存する
シークレットの有効期限を短く設定する

BitbucketとVaultを組み合わせることで、CI/CDパイプラインから本番環境まで一貫したシークレット管理を実現できます。
特にクラウドネイティブなシステムでは、認証情報をコードや設定ファイルから排除し、必要なときだけ安全に取得する仕組みが、これからの標準的なアーキテクチャになりつつあります。

機密情報管理で実践したいセキュリティ対策

BitbucketやVaultを導入したとしても、それだけで機密情報管理が完全に安全になるわけではありません。
セキュリティはツールだけで実現されるものではなく、適切な運用ルールと継続的な管理によって初めて効果を発揮します。

実際のセキュリティインシデントを分析すると、多くの場合はシステムの脆弱性そのものではなく、権限管理の不備や認証情報の使い回し、監視不足といった運用上の問題が原因になっています。

そのため、機密情報管理では「どこに保存するか」だけでなく、「誰が利用できるか」「どのくらいの期間利用できるか」「利用状況を把握できるか」という観点が重要になります。

特にBitbucketとVaultを組み合わせた環境では、以下の3つの対策がセキュリティ強化に大きく貢献します。

最小権限の原則を徹底する
定期的に認証情報を更新する
利用状況を監査する

これらはゼロトラストセキュリティの考え方とも密接に関係しており、企業システムだけでなく個人開発や小規模チームでも実践する価値があります。

最小権限の原則を徹底する

最小権限の原則（Principle of Least Privilege）は、セキュリティ設計の基本原則の一つです。

考え方は非常にシンプルで、「必要最小限の権限だけを付与する」というものです。

例えば、開発者が本番環境のデータベース管理権限を持っている必要は通常ありません。
また、CI/CDパイプラインもデプロイに必要な権限だけを持つべきです。

しかし実際の運用では、設定の簡略化を目的として過剰な権限が付与されるケースが少なくありません。

例えば以下のような状態は避けるべきです。

全開発者へ管理者権限を付与する
本番環境へのフルアクセスを許可する
CI/CDに過剰なクラウド権限を与える
共通アカウントを複数人で利用する

権限を設計する際は、利用目的ごとに役割を分離することが重要です。

利用者	必要な権限	不要な権限
開発者	開発環境操作	本番管理権限
運用担当者	本番環境管理	ソースコード変更
CI/CD	デプロイ実行	管理者権限
監査担当者	ログ閲覧	システム変更

このように役割ごとにアクセス範囲を限定することで、認証情報が漏えいした場合の被害を最小限に抑えることができます。

また、Vaultを利用している場合はポリシー機能を活用し、シークレット単位でアクセス制御を実施することが推奨されます。

定期的なシークレットローテーションを実施する

認証情報は一度設定したら終わりではありません。

長期間同じ認証情報を利用し続けると、漏えいに気付かないまま不正利用されるリスクが高まります。
そのため、定期的に認証情報を更新するシークレットローテーションが重要になります。

例えば以下のような情報は定期的な更新対象になります。

APIキー
データベースパスワード
クラウドアクセスキー
SSH鍵
アクセストークン

理想的には認証情報ごとに有効期限を設定し、期限到来前に自動更新できる仕組みを構築することです。

ローテーションの考え方を整理すると次のようになります。

項目	推奨方針
APIキー	定期更新
DBパスワード	自動更新推奨
アクセストークン	短寿命化
SSH鍵	定期再発行
管理者認証情報	厳格管理

Vaultを利用している場合は、動的シークレットによってローテーションを自動化できます。

例えばデータベース接続情報を固定値ではなく一時的な認証情報として発行することで、更新作業そのものを不要にすることが可能です。

また、認証情報を更新した際には不要になった古い資格情報を速やかに無効化することも重要です。

古い認証情報が有効なまま残っている状態は、攻撃対象を増やす原因になります。

監査ログを活用して不正利用を検知する

どれだけ厳格な権限管理を実施していても、不正利用の可能性を完全に排除することはできません。

そのため、機密情報へのアクセス状況を継続的に監視し、異常を検知できる仕組みが必要になります。

ここで重要になるのが監査ログです。

監査ログには以下のような情報が記録されます。

誰がアクセスしたか
いつアクセスしたか
どの認証情報を利用したか
どのIPアドレスからアクセスしたか
認証成功か失敗か

これらの情報を分析することで、不審なアクセスを早期に発見できます。

例えば次のような状況は調査対象になります。

深夜帯の異常なアクセス
海外IPからの接続
大量の認証失敗
通常利用しないシークレットへのアクセス
退職済みアカウントによる認証

特にVaultは監査ログ機能が充実しており、シークレットの取得履歴を詳細に追跡できます。

また、クラウドサービス側のログとも組み合わせることで、より精度の高い監視が可能になります。

運用面では以下の流れを構築すると効果的です。

ログを収集する
異常パターンを定義する
自動アラートを設定する
定期的にレビューする
問題発生時に調査する

セキュリティ対策は導入して終わりではなく、継続的な監視と改善が必要です。

Bitbucketの環境変数やVaultによるシークレット管理は非常に有効な仕組みですが、その効果を最大化するためには、最小権限の原則、定期的なシークレットローテーション、監査ログによる継続的な監視を組み合わせることが重要です。
これらを実践することで、認証情報漏えいのリスクを大幅に低減し、より安全な開発・運用環境を構築できるようになります。

Bitbucketの機密情報管理は環境変数とVaultの併用が鍵

ここまで解説してきたように、Bitbucketで機密情報を安全に管理するためには、単にGitリポジトリへ認証情報を書かないだけでは不十分です。
ソースコードと機密情報を分離し、適切なアクセス制御と監査を実施しながら運用することが重要になります。

特に近年のシステム開発では、クラウドサービスや外部APIとの連携が当たり前になっています。
その結果、管理すべき認証情報の種類や数は増加し続けています。

例えば、1つのWebサービスを運用するだけでも以下のような認証情報が存在します。

データベース接続情報
クラウドサービスのアクセスキー
外部APIの認証トークン
メール配信サービスの認証情報
オブジェクトストレージのアクセスキー
CI/CD用の認証情報
監視サービスのAPIキー

これらをすべてソースコードや設定ファイルで管理してしまうと、漏えいリスクが高まるだけでなく、運用そのものが複雑になります。

そのため、現在のベストプラクティスでは「ソースコード管理」と「シークレット管理」を明確に分離することが推奨されています。

BitbucketにはRepository VariablesやWorkspace Variablesといった環境変数管理機能が用意されており、小規模から中規模のプロジェクトであれば十分に実用的です。

例えば、プロジェクト単位で利用するAPIキーやデータベース接続情報をRepository Variablesへ保存することで、Git履歴へ機密情報を残さずに運用できます。

また、複数プロジェクトで共通利用する認証情報についてはWorkspace Variablesを活用することで、管理の一元化も可能です。

この段階だけでも、認証情報をソースコードへ直接記述する運用と比較すると、セキュリティレベルは大幅に向上します。

しかし、システム規模が拡大すると環境変数だけでは対応しきれない課題が現れます。

例えば以下のようなケースです。

課題	環境変数のみ	Vault併用
シークレット数の増加	管理負荷増大	一元管理可能
権限制御	限定的	詳細設定可能
利用履歴確認	困難	監査可能
自動ローテーション	手動対応	自動化可能
動的資格情報発行	不可	可能

特に企業システムや大規模なクラウド環境では、「誰がどの認証情報へアクセスしたのか」を追跡できることが重要になります。

環境変数は機密情報を渡す仕組みとして優れていますが、アクセス管理や監査の観点では限界があります。

そこで有効になるのがHashiCorp Vaultです。

Vaultを導入すると、認証情報を一箇所へ集約し、アクセス制御や監査ログ、動的シークレット発行などの高度な機能を利用できます。

例えば、Bitbucket PipelinesからVaultへ認証し、その都度必要なシークレットだけを取得する構成にすれば、認証情報を長期間保持する必要がなくなります。

さらに、データベース接続情報を動的に発行する仕組みを利用すれば、固定パスワードを運用する必要すらなくなります。

これはセキュリティの観点から非常に大きなメリットです。

認証情報の漏えいリスクを考える場合、重要なのは「漏えいを完全に防ぐこと」ではなく、「漏えいしても被害を最小化できること」です。

そのためには以下の考え方が重要になります。

機密情報をコードへ保存しない
必要最小限の権限のみ付与する
認証情報を定期的に更新する
利用履歴を監査する
長寿命な認証情報を減らす

これらの要件を満たすうえで、Bitbucketの環境変数とVaultは互いを補完する関係にあります。

環境変数はシンプルで導入しやすく、多くのプロジェクトで即座に利用できます。
一方のVaultは、より高度なシークレット管理や大規模運用に対応できる強力なプラットフォームです。

したがって、実践的な運用としては次のような段階的なアプローチが現実的です。

Gitへ機密情報を保存しない運用を徹底する
Bitbucketの環境変数機能を活用する
権限管理と監査体制を整備する
シークレット数の増加に応じてVaultを導入する
動的シークレットや自動ローテーションを活用する

この流れで進めることで、開発効率を維持しながらセキュリティレベルを継続的に向上させることができます。

Bitbucketの機密情報管理において最も重要なのは、「認証情報をソースコードから分離する」という基本原則です。
そして、その実現手段として環境変数を活用し、さらに高度な要件にはVaultを組み合わせることで、セキュリティと運用性を両立した堅牢な開発基盤を構築できます。
現在の開発環境では、環境変数とVaultの併用こそが、安全なシークレット管理を実現するための最も実践的なアプローチといえるでしょう。