ハードコードされた埋め込みパスワードとは？

English -> Visit BeyondTrust Original Page

⚠️ まず確認すべき3つの事実

1. 2024年、GitHubで2,380万件のシークレットが漏洩（前年比25%増）
2. 漏洩したシークレットの70%は”数年後も有効なまま”放置されている
3. AIコード生成ツール（Copilot等）がハードコードパスワードを自動生成するリスクが急増

ハードコードされたパスワードは、現代のサイバー攻撃の起点として最も悪用されている脆弱性の一つです。本記事では、危険性・攻撃例・検出方法・日本企業が取るべき対策を包括的に解説します。

目次

1. ハードコードされたパスワードとは
2. どこに埋め込まれているのか
3. なぜ危険なのか（3つの理由）
4. AIコード生成ツールが生む新たなリスク
5. GitHub誤コミットが起きるプロセス
6. 企業が直面する管理上の課題
7. 実際に起きた重大インシデント
8. 日本企業が知るべき法規制・ガイドライン
9. ベストプラクティス：どう防ぐべきか
10. 検出ツール一覧
11. BeyondTrustによる根本解決

1. ハードコードされたパスワードとは？

ハードコードされたパスワードとは、ソースコード・スクリプト・設定ファイルに直接書き込まれた認証情報のことです。「埋め込みパスワード」「埋め込み認証情報」とも呼ばれます。

java

// ❌ ハードコードの例（絶対に避けるべき）
String dbPassword = "Admin123!";
String apiKey = "sk-xxxxxxxxxxxxxxxx";

対象となるシークレットには以下が含まれます。

• パスワード
• APIキー
• SSHキー
• データベース接続情報
• クラウド認証トークン
• DevOps用シークレット

デフォルトのハードコードパスワードは、多くの同一デバイス・アプリケーション・システムで共通して使用されるため、大規模なセットアップを簡素化できる反面、発覚した瞬間にすべての機器が一括して侵害されるという致命的なリスクを抱えています。

MITRE CWEによる重大欠陥の分類：

これらはセキュリティ審査・ペネトレーションテストで必ず確認される最優先チェック項目です。

2. どこに埋め込まれているのか？

ハードコードパスワードは、組織の広範な場所に潜んでいます。

保存されがちな場所

• アプリケーションのソースコード
• CI/CDパイプライン設定（GitHub Actions / Jenkins など）
• Dockerfile / Kubernetes YAML / Ansible Playbook
• IoTデバイスのファームウェア
• ネットワーク機器（ルーター・スイッチ）のBIOS・設定ファイル
• PowerShell / Bashスクリプト
• GitHubなどのリポジトリ（誤公開されたもの）
• 医療機器・産業制御システム（SCADA）

なぜ発生するのか

• 開発スピード優先でセキュリティレビューが省略される
• Secretsの管理ツールが未導入・未整備
• 外部委託先との認証情報共有が手作業で行われている
• AIツールが生成したコードをそのまま採用してしまう

3. なぜ危険なのか（3つの理由）

① GitHub誤公開 → 履歴に永遠に残る

コードからシークレットを削除しても、Gitの履歴には残り続けます。攻撃者はGit履歴を遡ってシークレットを発見できるため、削除だけでは対策として不十分です。

② 一つの漏洩で”全システム”が侵害される

IoT機器やアプリケーションで同一のデフォルトパスワードが使われている場合、1つのパスワードが世界中の同型機器すべての侵害につながります。後述するMirai攻撃がその典型例です。

③ 内部不正・退職者リスクの温床

退職した従業員や外部委託先がパスワードを知り続けることで、内部不正や悪意ある情報持ち出しのリスクが長期間にわたって継続します。パスワードがローテーションされないほど、このリスクは蓄積されます。

4. AIコード生成ツールが生む新たなリスク

GitHub Copilot、ChatGPT、Amazon CodeWhispererなどのAIコード生成ツールの普及により、ハードコードパスワードの問題は新たな局面を迎えています。

AI時代の具体的な対策

• Pre-commitフックにシークレット検出ツールを組み込み、コミット前に自動検査する
• CIパイプラインにGitGuardian / TruffleHogを組み込み、マージ時にも自動スキャンする
• AI生成コードのセキュリティレビューをプロセスとして必須化する

5. GitHub誤コミットが起きるプロセス

「コードからシークレットを削除すれば大丈夫」は誤りです。正しいプロセスを理解してください。

① 開発者がシークレットを含むコードを誤ってコミット・プッシュ
         ↓
② Gitの履歴にシークレットが永続的に記録される
         ↓
③ 攻撃者がスキャンツールで発見・悪用
         ↓
    ❌ 間違った対処：コードからシークレットを削除してコミット
           → Git履歴にはまだ残っている
         ↓
    ✅ 正しい対処（この3ステップが必須）：
         1. シークレットを即座に無効化・ローテーション
            （新しいAPIキー・パスワードを発行）
         2. BFG Repo Cleaner または git filter-branch で
            Git履歴からも完全削除
         3. 依存するすべてのサービスのシークレットも更新

重要： 一度でもシークレットがコミットされた場合、削除の有無にかかわらず「侵害された可能性がある」と見なし、必ずシークレット自体をローテーションしてください。

6. 企業が直面する管理上の課題

可視性と認識の欠如

組織内のどのシステム・アプリケーションにハードコードパスワードが存在するかを把握すること自体が、大きな課題です。ハードコードパスワードが存在しうるすべてのデバイス・アプリケーションを網羅的に監査・検出する必要があります。

業務継続性へのリスク

多くのハードコードパスワードは「変更しないこと」を前提に設計されており、管理者が「変更するとシステムが止まるかもしれない」という懸念から、既知のリスクがあっても変更に踏み切れないケースが多くあります。

外部委託先・退職者が認証情報を持ち続ける

プロジェクト終了後も外部委託先がパスワードを知り続けていたり、退職した従業員の知識を回収する手段がなかったりと、組織の境界を越えたリスクのコントロールが困難です。

適切なツールの欠如

アプリケーションやスクリプト内に保存されているパスワードを手動で検出・集中管理する実用的な方法はありません。根本的な解決には、パスワードをコードから分離し、集中管理されたSecrets管理ツールに保存する仕組みが必要です。

7. 実際に起きた重大インシデント

Mirai攻撃（2016年〜）

LinuxベースのIoT機器（DVR・WebカメラなどのTelnetサービス）をスキャンし、既知のデフォルトハードコードパスワード61種類を使ったブルートフォース攻撃でログインを試みました。最大約40万台のデバイスがボットネット化され、French Telecom・Krebs on Security・Dynなどに対してこれまでにないほど大規模なDDoS攻撃を引き起こしました。

Uber（2014年・2022年）

2014年の侵害では、Uber従業員がプレーンテキストの認証情報をGitHubに誤公開。攻撃者がそれを発見し、Amazon AWSインスタンスへの特権アクセスを取得、5,700万人の顧客情報と約60万人のドライバー情報が漏洩しました。2022年の侵害でも同様に、イントラネット内のPowerShellスクリプトにハードコードされた特権認証情報が発見され、ラテラルムーブメントによる攻撃拡大につながりました。

メルセデス・ベンツ（2024年1月）

社員の認証トークンが公開GitHubリポジトリで発見され、社内GitHubエンタープライズサーバーのソースコードへ無制限アクセスが可能な状態になっていました。設計情報・APIキー・内部ドキュメントが外部から閲覧できる状態でした。

米国財務省（2024年）

認証プラットフォームのAPIキーがハードコードされていたことを悪用され、政府機関のシステムが侵害されました。国家レベルのセキュリティ環境でも、ハードコードパスワードが重大インシデントの起点になることを示した事例です。

8. 日本企業が知るべき法規制・ガイドライン

ハードコードパスワードへの対処は、日本企業においてコンプライアンス上の義務にもなりつつあります。

特に個人情報保護法においては、ハードコードパスワードを原因とする情報漏洩が発生した場合、「安全管理措置」の不備として指摘される可能性があります。MDM（モバイルデバイス管理）ポリシーとあわせて、組織内のSecrets管理ポリシーの整備が急務です。

9. ベストプラクティス：どう防ぐべきか

① シークレットスキャンの自動化

コミット前・CI実行時の両段階でスキャンを自動化し、人的ミスに依存しない仕組みを構築します。

• Pre-commitフックへのGitGuardian / TruffleHog組み込み
• CIパイプラインでの自動スキャン必須化
• GitHubのSecret Scanning機能（無料）の有効化

② パスワードをコードに書かない（ソフトコーディングへの移行）

# ❌ ハードコード（絶対NG）
DB_PASSWORD="Admin123!"

# ✅ 環境変数から取得
DB_PASSWORD="${DB_PASSWORD}"

# ✅✅ Secrets管理ツールから動的取得（最善）
DB_PASSWORD=$(vault kv get -field=password secret/db)

③ 特権アクセス管理（PAM）による自動化

• パスワードの自動ローテーション
• アプリケーションIDの集中管理
• 人がパスワードを”知る必要がない”ゼロトラスト運用の実現

④ ハードコード認証情報を使うベンダー製品を選ばない

ベンダー製品の選定時にハードコードパスワードの有無を確認し、使用しているベンダーには改善を要求することが、ITエコシステム全体のリスクを長期的に低減する最善策です。

⑤ 脆弱性管理とパッチ適用の徹底

ソフトウェア・ハードウェアベンダーはハードコードパスワードを含む脆弱性へのパッチを定期リリースします。徹底した脆弱性スキャンとパッチ管理プロセスを整備し、公開されたパッチに即座に対応できる体制を構築しましょう。

10. 検出ツール一覧

目的に応じたツールの組み合わせが、最も効果的な防御策となります。

シークレットスキャンツール（コード内の漏洩検出）

SAST（静的アプリケーションセキュリティテスト）

Secrets管理ツール（安全な保管・動的取得）

11. BeyondTrustによる根本解決

BeyondTrust Password Safe を導入することで、ハードコードパスワード問題を”構造的に”解決できます。

コードからパスワードを完全に排除し、漏洩リスクをゼロに近づけることが可能です。

→ BeyondTrust Password Safe についてお問い合わせはこちら

まとめ

ハードコードされたパスワードは、最も発見されやすく、最も悪用されやすい脆弱性です。

• GitHub誤公開による情報漏洩
• IoT機器を標的にした大規模ボットネット攻撃
• 退職者・外部委託先による内部不正
• 法規制・監査への未対応

これらのリスクを避けるためには、「パスワードをコードに持たせない設計」と「自動化されたSecrets管理」 の両輪が不可欠です。

BeyondTrust Password Safeは、その実現に最も適したエンタープライズ向けソリューションです。

関連情報

• 特権アカウント管理（PAM）とは
• アプリケーションパスワード管理とは
• BeyondTrust Password Safe 製品ページ
• BeyondTrustについて