ホーム / セキュアコーディング /

コードに秘密を書くな！コンフィグとシークレット管理の第一歩

2025年4月30日水曜日

セキュアコーディング

「コンフィグ シークレット 管理」、なんだか難しそう？ 

でも、APIキーやパスワードをうっかりコードに書いてコミット…なんて経験、プログラミング初心者さんならドキッとするかもしれませんね。実はそれ、めちゃくちゃ危ないんです！

この記事では、設定情報（コンフィグ）と秘密の情報（シークレット）の安全な扱い方を、セキュアコーディングの基本として噛み砕いて説明します。

この記事でわかること

  • コンフィグとシークレットの違いがスッキリわかる
  • なぜ秘密情報をコードに書いちゃダメなのかが骨身にしみる
  • 初心者でもできる安全な管理方法の基本が身につく
  • もっと安全にするための次のステップが見えてくる

コンフィグとシークレット管理の超基本

まず最初に、「コンフィグ」と「シークレット」って言葉の意味、そしてなぜそれらをちゃんと「管理」しないといけないのか、そこからお話ししましょう。これを理解するのが、安全なアプリを作るためのスタートラインですよ！

そもそもコンフィグとシークレットって何が違うの

簡単に言うと、こんな感じです。

  • コンフィグ（設定情報）
    アプリが動くための設定値。例えば、接続するデータベースサーバーの名前とか、外部APIのエンドポイントURLとか。見られてもまあ、そこまで致命的ではないことが多い情報です。
  • シークレット（機密情報）
    絶対に秘密にしておかなければいけない情報。データベースのパスワード、APIキー、暗号化に使う秘密鍵など。これが漏れたら大変なことになる！という情報ですね。

この二つをごちゃ混ぜにせず、特にシークレットは厳重に扱う必要がある、という点をまず押さえてくださいね。

コードに秘密を書くのが絶対ダメな理由

じゃあ、なんでAPIキーとかパスワードをコードの中に直接書いちゃダメなの？ 動くんだからいいじゃん！…って思う気持ちも、まあわからなくもない。でも、ダメ、絶対！

一番怖いのは、うっかりGitリポジトリに含めて公開しちゃうこと。GitHubとかに公開リポジトリでコードを置いている場合、そこにAPIキーが書いてあったら…世界中の誰でもそのキーを使えてしまうんです！ 悪用されたら目も当てられません。

それに、設定を変えたいとき、いちいちコードを書き換えてデプロイし直すなんて、面倒くさいでしょう？ 管理の手間も増えるし、良いことなんて一つもないんですよ。

コンフィグシークレット管理を怠ると起こる悲劇

もし、シークレット情報の管理が甘くて漏洩してしまったら、どうなると思いますか？

  • 不正アクセスされて、個人情報が抜き取られる
  • 勝手にサービスを使われて、高額な請求が来る
  • 会社の信用がガタ落ちして、サービス停止に追い込まれる

…などなど、本当に笑えない事態になりかねません。過去には、ちょっとした油断から大きなインシデントに発展した例がたくさんあります。

これは他人事じゃなく、誰にでも起こりうるリスクなんです。だからこそ、セキュアコーディングの意識、特にコンフィグ・シークレット管理が欠かせません。

絶対避けたいコンフィグシークレット管理のNG例

ここでは、初心者の頃についやってしまいがちな、危ないコンフィグ・シークレット管理の例を見ていきましょう。もし心当たりがあったら、今日から改めてくださいね！

ハードコーディングという名の時限爆弾

さっきも触れましたが、コードの中に直接シークレットを書き込む「ハードコーディング」は、最も避けるべき行為です。

# Python の例 (ダメな書き方！)
api_key = "ここにあなたの本物のAPIキーを書いちゃう" # 絶対ダメ！
database_password = "password123" # こんな簡単なのも論外！

# ... このキーやパスワードを使って処理 ...

一見、これで動くから大丈夫と思いがち。でも、これはセキュリティの観点から見ると、いつ爆発するかわからない時限爆弾を抱えているようなものです。絶対にやめましょう。

バージョン管理に秘密を含める危険性

「コードには書かないけど、設定ファイルに書いて、それをGitで管理すればいいや！」…これも危ない！

設定ファイル自体をGit管理するのは良いのですが、そのファイルにシークレット情報（APIキー、パスワードなど）を含めてコミットしてしまうと、結局ハードコーディングと同じリスクがあります。特に`.env`ファイルのような機密情報を含むファイルは、必ず`.gitignore`に書いて、Gitの管理対象から外す必要があります。

# .gitignore ファイルの例
# このファイルに書かれたファイルやフォルダはGitの管理対象外になる

# 環境変数を定義する.envファイルは含めない
.env

# その他、OSが生成するファイルなど
.DS_Store
node_modules/

これを忘れると、`git push`した瞬間に秘密がリポジトリの履歴に残ってしまいます。一度履歴に残ると、後から消すのは結構大変ですよ！

安易なファイル共有が生む情報漏洩リスク

開発チーム内で設定情報を共有するとき、どうしていますか？ SlackのDMやメールに、設定ファイルやパスワードをそのままペタッと貼り付けて送ったりしていませんか？

これも実は危険な行為です。誤送信のリスクもあるし、退職した人がアクセス可能なまま残ってしまう可能性もあります。

USBメモリでの手渡しなんかも、紛失のリスクが伴います。手軽だから、と安易な方法でシークレット情報をやり取りするのは避け、より安全な共有方法を考えるべきです。

初心者向けコンフィグシークレット管理の始め方

「じゃあ、どうすればいいのさ！」って声が聞こえてきそうですね。

大丈夫、ここからは初心者さんでも始めやすい、基本的なコンフィグ・シークレットの管理方法を紹介します。まずはここからスタートしましょう！

まずはこれだけ環境変数を使った基本管理

ハードコーディングを避ける最も基本的な方法の一つが「環境変数」を使うことです。

環境変数というのは、OS（Windows, macOS, Linuxなど）レベルで設定しておける変数（名前付きの値）のこと。プログラムの中からその値を読み込んで使うようにすれば、コード自体に秘密情報を書かなくて済みます。

例えば、プログラム側では「`API_KEY`という名前の環境変数から値を取得する」という処理だけを書いておきます。実際のAPIキーの値は、プログラムを実行するサーバーや開発環境のOSで設定しておく、という流れです。

サーバーごとに違う設定値（開発用DBパスワード、本番用DBパスワードなど）を持たせやすいのも利点ですね。

どうやって設定するの？ (macOS/Linux の例)

ターミナルで `export` コマンドを使います。

export API_KEY="あなたの実際のAPIキー"
export DATABASE_URL="postgresql://user:password@host:port/dbname"

どうやってプログラムから読むの？ (Python の例)

import os

# 環境変数 'API_KEY' の値を取得
api_key = os.environ.get('API_KEY')
# 環境変数 'DATABASE_URL' の値を取得
database_url = os.environ.get('DATABASE_URL')

if api_key is None:
  print("エラー: 環境変数 'API_KEY' が設定されていません。")
else:
  # api_key を使った処理...
  print(f"APIキー: {api_key[:5]}...") # 全部表示しないように注意

if database_url:
  print(f"データベースURLが設定されています。")
  # database_url を使った処理...
else:
  print("データベースURLは設定されていません。")

これで、コードには実際のキーやパスワードを書かずに済みますね！

.envファイルとgitignoreで手軽に管理する方法

環境変数は便利だけど、設定する変数が多くなると管理が少し面倒になったり、設定方法がOSによって微妙に違ったりします。そこで便利なのが `.env` (ドットエンブ) ファイルを使う方法です。

これは、プロジェクトのルートディレクトリに `.env` という名前のファイルを作り、そこに `キー=値` の形式で環境変数を書いておく、というやり方。そして、プログラム側では専用のライブラリ（例えばPythonなら `python-dotenv`、Node.jsなら `dotenv`）を使って、そのファイルから環境変数を読み込ませます。

`.env` ファイルの例

# これはコメントです
API_KEY="あなたの実際のAPIキー"
DATABASE_URL="postgresql://user:password@host:port/dbname"
DEBUG=True

Python (`python-dotenv`) での読み込み例

まずライブラリをインストール

pip install python-dotenv

そしてコード

import os
from dotenv import load_dotenv

# .env ファイルから環境変数を読み込む
load_dotenv()

# あとは os.environ.get() で普通に取得できる
api_key = os.environ.get('API_KEY')
database_url = os.environ.get('DATABASE_URL')
is_debug = os.environ.get('DEBUG') == 'True' # 文字列なので比較する

print(f"APIキー: {api_key[:5]}...")
print(f"データベースURLあり: {bool(database_url)}")
print(f"デバッグモード: {is_debug}")

この方法の最大のポイントは、`.env` ファイル自体は絶対にGitで管理しないこと！ 必ず `.gitignore` ファイルに `.env` と書いて、コミット対象から除外してくださいね。これで、開発メンバーそれぞれが自分の環境用の `.env` ファイルを用意しつつ、コード自体は安全に保てます。

環境変数や.env管理の注意点と限界

環境変数や `.env` ファイルは、手軽で多くの場面で有効な方法です。でも、これらが万能というわけでもありません。

  • 管理するシークレットの数が増えると、設定や管理が煩雑になることがある。
  • 本番サーバーにどうやって安全に環境変数を設定するか、という課題は残る。（サーバーの設定ファイルに書く？ デプロイツールを使う？）
  • チーム内で `.env` ファイルのテンプレート（どのキーが必要か）を共有したり、値を安全に共有する方法を考えたりする必要がある。

特に、より多くのメンバーで開発したり、セキュリティ要件が厳しくなってきたりすると、これらの方法だけでは少し心許なくなる場面も出てきます。

そんなときのために、もっと進んだ管理方法があることも知っておきましょう。

安全性を高めるシークレット管理ツール

環境変数や `.env` よりも、もっと安全で効率的にシークレットを管理するための仕組みがあります。

それが「シークレット管理ツール」や「シークレットマネージャー」と呼ばれるものです。プロの開発現場では、こういった仕組みを使うのが一般的になってきていますよ。

シークレットマネージャーとはどんな仕組み

シークレットマネージャーは、一言でいうと「機密情報専用の超安全な金庫番」みたいなものです。

APIキーやパスワードなどのシークレットを、暗号化された安全な場所に保管してくれます。そして、アプリケーションが必要なときに、決められた権限に基づいて、安全な方法でシークレット情報だけを取り出せるようにしてくれます。

アスキーアートでイメージ図:

+-------------------+      +-----------------------+      +-----------------+
| アプリケーション  | ----> | シークレットマネージャー | ----> |  機密情報ストア |
| (App)             | <---- | (金庫番)              | <---- |  (金庫)         |
+-------------------+      +-------+---------------+      +-------+---------+
                             | アクセス制御 (誰がOK?)     | 暗号化 (中身は秘密)
                             | ログ記録 (誰がいつ取った?) | 保管 (安全な場所)
                             | ローテーション (定期交換) |
                             +---------------------------+

主な機能としては、

  • 安全な保管
    シークレットを暗号化して保管する。
  • アクセス制御
    どのアプリやユーザーがどのシークレットにアクセスできるか細かく設定できる。
  • 監査ログ
    いつ誰がどのシークレットにアクセスしたかの記録が残る。
  • ローテーション
    パスワードなどを定期的に自動で変更してくれる機能を持つものもある。

これらによって、シークレット情報が漏洩するリスクを大幅に減らすことができます。

代表的なシークレット管理ツールの紹介

世の中には色々なシークレット管理ツールやサービスがあります。いくつか代表的なものを挙げてみましょう。

  • AWS Secrets Manager
    Amazon Web Services (AWS) が提供するマネージドサービス。AWSの他のサービスとの連携がしやすい。
  • Google Secret Manager
    Google Cloud Platform (GCP) が提供するマネージドサービス。GCP環境との親和性が高い。
  • Azure Key Vault
    Microsoft Azure が提供するサービス。シークレットだけでなく、証明書や暗号化キーも管理できる。
  • HashiCorp Vault
    オープンソースとしても、エンタープライズ版としても提供されている人気のツール。オンプレミスでもクラウドでも使える柔軟性がある。
  • Doppler
    開発者向けの使いやすさに重点を置いた比較的新しいサービス。様々なプラットフォームとの連携が豊富。

どれを選べばいいかは、使っているクラウド環境やプロジェクトの規模、チームのスキルなどによって変わってきます。 

最初は、今使っているクラウドサービスが提供しているものから見てみるのが良いかもしれませんね。

ツール選定で考慮すべきポイント

シークレット管理の仕組みを導入しよう！と思ったとき、どんな点に気をつけて選べばいいでしょうか？

  • コスト
    無料で使える範囲は？ 有料プランの料金体系は？
  • 学習コスト
    使いこなすためにどれくらいの知識や時間が必要か？ ドキュメントは充実しているか？
  • 連携性
    使っているプログラミング言語やフレームワーク、CI/CDツール、クラウド環境などとスムーズに連携できるか？
  • 必要な機能
    アクセス制御、監査ログ、ローテーションなど、自分たちのプロジェクトで必要となる機能は揃っているか？
  • 運用体制
    自分たちでサーバーを立てて運用する必要があるか（VaultのOSS版など）、それともサービス提供側が管理してくれるか（マネージドサービス）。

いきなり全部入りで高機能なものを目指す必要はありません。

まずは無料で試せるプランや、シンプルな機能のものから触ってみて、自分たちのニーズに合うかを確認するのがおすすめです。

【まとめ】コンフィグシークレット管理で安全な開発を

さて、今回はコンフィグとシークレットの管理について、基本のキから少し進んだ話まで見てきました。もう一度ポイントをおさらいしましょう。

  • コンフィグは設定情報、シークレットは機密情報。区別して扱おう！
  • コードにシークレットを直接書く（ハードコーディング）のは絶対ダメ！
  • `.env`ファイルを使うときは、必ず`.gitignore`で除外しよう！
  • 環境変数や`.env`は手軽だけど限界もある。
  • より安全性を高めるならシークレットマネージャーの導入を検討しよう！

難しく感じた部分もあったかもしれませんが、一番ダメなのは「まあいっか」とハードコーディングを続けてしまうことです。今日からできることとして、まずは自分の書いたコードにシークレットが直接書かれていないかチェックしてみてください。

もしあったら、環境変数や`.env`ファイルを使う方法に置き換えてみましょう！

セキュアコーディングは一日にしてならず。でも、こうやって一つ一つ知識を身につけて実践していくことが、安全なアプリケーション開発への確実な一歩になります。

このブログを検索
  • ()

自己紹介

自分の写真
リモートワークでエンジニア兼Webディレクターとして活動しています。プログラミングやAIなど、日々の業務や学びの中で得た知識や気づきをわかりやすく発信し、これからITスキルを身につけたい人にも役立つ情報をお届けします。 note → https://note.com/yurufuri X → https://x.com/mnao111

QooQ