【開発者必見】その「環境変数」、実は空き巣に合鍵を渡しているのと同じです。
こんにちは。セキュリティの世界で泥臭い現場を渡り歩いてきた者です。
今日は、開発現場でついやりがちな「秘密情報の管理」について、少し耳の痛い話をさせてください。皆さんのアプリケーションは、データベースのパスワードやAPIキーをどこで管理していますか？
もし、「.envファイルに書いているよ」「環境変数（Environment Variables）にセットしているよ」という方がいたら、一度立ち止まって考えてみましょう。それは、「自宅の鍵を、玄関のポストに貼り付けている」のと変わらない状態かもしれません。
今日は、なぜそれが危険なのか、そしてどうやって「本当に安全な鍵の管理」に移行するのかを、一緒に紐解いていきましょう。
—
1. なぜ「環境変数」は危険なのか？
「環境変数にパスワードを入れておけば、コードに直書きしないから安全じゃないの？」と思うかもしれません。確かに、GitHubにコードをうっかり公開してしまう「ハードコード」よりは一歩前進です。
しかし、攻撃者は「あなたのミス」を常に狙っています。
泥棒の侵入ルートは意外な場所に
サーバーに侵入されたり、あるいはWebアプリの脆弱性（OSコマンドインジェクションなど）を突かれたりしたとき、攻撃者はまず何をすると思いますか？彼らは真っ先にenvコマンドを叩いて環境変数の中身を覗き見ます。
環境変数は、そのプロセスが動くための「持ち物」です。一度プログラムを起動すると、そのメモリ領域やシステム設定の中に、機密情報がむき出しの状態でずっと居座り続けることになります。これは、泥棒が入ってきたときに、テーブルの上に財布を広げて置いているようなものです。
—
2. AWS Secrets Managerという「金庫」
そこで登場するのが、AWS Secrets Managerです。
これは、パスワードやAPIキーをアプリケーションの外にある「強固な金庫」に預け、必要なときだけ「鍵束」を一時的に借りてくる仕組みです。
なぜこれが安全なのか？
1. 動的な取得: アプリは起動時に金庫へ「パスワードを教えて」と聞きに行きます。メモリにずっと保持し続ける必要はありません。
2. 自動ローテーション: これが最強の武器です。「鍵を定期的に自動で交換する」仕組みを標準で備えています。万が一、鍵がどこかで漏洩しても、数日後にはその鍵は無効になっているのです。
3. アクセス制御: 「誰が（どのサーバーが）」その金庫を開けられるかを、AWSのIAMというガードマンが厳密にチェックします。
—
3. 実践：Secrets Managerからシークレットを取得する
難しい理屈はさておき、実際にどう書くのか見てみましょう。Pythonを使った例ですが、考え方はどの言語でも同じです。
import boto3
import json
from botocore.exceptions import ClientError
def get_secret():
secret_name = “prod/db/password” # 金庫の中の場所
region_name = “ap-northeast-1”
# セッションを作成（IAMロールで権限を与えるのが鉄則！）
session = boto3.session.Session()
client = session.client(service_name=’secretsmanager’, region_name=region_name)
try:
# 金庫に鍵を取りに行く
get_secret_value_response = client.get_secret_value(SecretId=secret_name)
except ClientError as e:
# 鍵が開かない（権限がない、場所が違う等）の例外処理
raise e
# 取得した文字列（JSON形式）を辞書型に変換
secret = json.loads(get_secret_value_response[‘SecretString’])
return secret[‘password’] # パスワードだけを取り出す
これで、ハードコードされたパスワードを使わずにDB接続が完了！
ポイントは、プログラムの中にパスワードを一切書かないことです。AWSの「IAMロール」という仕組みを使えば、プログラム側には「このプログラムはSecrets Managerを開けていいよ」という許可証を持たせるだけで済みます。
—
4. 今日からできる一歩
セキュリティ対策は、一気にすべてを完璧にする必要はありません。まずは以下のステップから始めてみてください。
1. まずは棚卸し: 今、自分のアプリのどこにパスワードが隠れているか、全部書き出してみましょう。
2. 開発環境から少しずつ: 本番環境でいきなりやるのが怖いなら、まずは検証環境で「Secrets Managerから値を取ってくる」コードに書き換えてみてください。
3. 環境変数を見直す: どうしても環境変数を使わざるを得ない場合でも、本番環境の環境変数は「暗号化された値」を保持するようにしましょう（AWS Systems Manager Parameter StoreのSecureString機能などが便利です）。
最後に
セキュリティは「これさえやれば絶対安全」という魔法はありません。でも、「鍵をどこに置くか」という意識を変えるだけで、攻撃者が侵入したときの被害を最小限に抑えることは可能です。
皆さんの書くコードが、より強固で、そして何より「守られる側にとっても安心なもの」になることを応援しています。一歩ずつ、着実に強くなっていきましょう！
もし分からないことがあれば、いつでもまた聞いてくださいね。一緒に泥臭く対策していきましょう。
コメント