「コードに秘密を刻むな」― AzureマネージドIDで実現する、漏洩リスクゼロの認証設計
現場でインシデント対応をしていると、決まって遭遇する光景がある。「急いでいたから」「開発環境だし」という甘い言葉と共に、ソースコードの中に鎮座するデータベースの接続文字列や、GitHubに誤ってプッシュされたAPIキーだ。
いいか、エンジニア諸君。「認証情報をコードに含める」ことは、自宅の鍵を玄関先に吊るしておくのと同じだ。 今日は、Azure App Serviceを舞台に、マネージドIDとKey Vaultを組み合わせてこの「負債」を根本から断ち切る方法を伝授する。
—
なぜ「ハードコード」が死を招くのか（PoC的視点）
攻撃者が狙うのは、高度なゼロデイ攻撃だけじゃない。彼らが最も好むのは、公開リポジトリの検索だ。
例えば、git grep "DB_PASSWORD" と叩くだけで、数千のプロジェクトから認証情報が溢れ出してくる。もし君のアプリがGitHubにシークレットを紛れ込ませたら、数分後には自動化されたボットがそのキーを吸い上げ、データベースを暗号化するか、踏み台として悪用するだろう。
「環境変数に置けば安全だ」と思っているなら、それも甘い。 サーバの不適切な設定（phpinfoの露出や、特権昇格による環境変数のダンプ）で、環境変数はいとも簡単に引き抜かれる。だからこそ、物理的なシークレットを「持たない」設計が必要なのだ。
—
実装戦略：マネージドIDという「魔法の鍵」
AzureマネージドIDを使えば、アプリ自体がAzureのサービスとして認証される。つまり、パスワードを一切管理せずに、Key Vaultへアクセスできる。
手順の全体像
1. App ServiceにマネージドIDを割り当てる（Azure側でスイッチをONにするだけ）。
2. Key Vaultのアクセスポリシーを設定する（マネージドIDに「取得」権限のみを与える）。
3. コードからSDK経由でシークレットを動的に取得する（メモリ上にのみ展開する）。
—
実践：Pythonによるセキュアな実装例
まずは、Azure SDKを使った最も安全なアクセス方法を紹介する。これならシークレットはファイルにも環境変数にも存在しない。
必要なライブラリ: azure-identity, azure-keyvault-secrets
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
1. マネージドIDを使って認証を確立
ローカル環境ならAzure CLIのログイン情報、App Service上ならマネージドIDを自動判別する
credential = DefaultAzureCredential()
2. Key VaultのURLを指定（これはコードに書いてもOKな公開情報）
vault_url = “https://your-vault-name.vault.azure.net/”
client = SecretClient(vault_url=vault_url, credential=credential)
def get_db_connection_string():
try:
# 3. メモリ上にのみシークレットを取得
secret = client.get_secret(“DB-CONNECTION-STRING”)
return secret.value
except Exception as e:
# ここで適切にログを出す。認証エラーは直ちに検知せよ
print(f”Key Vaultアクセス失敗: {e}”)
raise
利用例
connection_string = get_db_connection_string()
これでDB接続を行う（変数の中身をprintしてはいけない！）
—
運用時の鉄則：インフラの防御層
コードをセキュアにしても、インフラがガバガバでは意味がない。以下の設定を必ず確認してほしい。
1. Key Vaultのネットワーク制限
Key Vaultの設定で「パブリックアクセスを無効」にし、App Serviceからの仮想ネットワーク（VNet）経由のアクセスのみを許可せよ。これで、外部からの直接攻撃は不可能になる。
2. マネージドIDの「最小権限」
マネージドIDには「秘密鍵の取得(Get)」権限だけを与えること。「リスト(List)」や「更新(Update)」権限は不要だ。もしアプリが乗っ取られても、Key Vault内の全シークレットが抜かれるリスクを最小化できる。
—
最後に：セキュリティは「諦めない」ことの積み重ね
「面倒だ」という感情は、脆弱性の最大の温床だ。マネージドIDへの移行は最初の手間こそかかるが、一度構築してしまえば、シークレットのローテーションもKey Vault側で完結し、コードを触る必要すらなくなる。
「コードには、秘密を書かない」。
この原則をチームのDNAに刻み込んでほしい。君たちが書く一行のコードが、何千人ものユーザーの個人情報を守っているという自覚を持って、明日からの開発に臨んでくれ。
何か不明点があればいつでも質問してきていい。セキュリティの現場は、常に「疑うこと」から始まるのだから。
コメント