シークレット漏洩とは？
シークレット漏洩とは、システムやサービスの利用に必要な機密情報が外部に露出してしまうセキュリティ上の脅威です。「シークレット」とは、APIキー、パスワード、アクセストークン、データベース接続情報、暗号化キー、証明書などの認証情報を指します。これらの情報は本来、厳重に管理されるべき機密データですが、プログラムのコードやログファイル、設定ファイルなどに誤って含まれてしまい、それがGitHubなどの公開リポジトリにアップロードされたり、不適切な場所に保存されることで漏洩します。
シークレット漏洩は「認証情報の漏洩」「クレデンシャル漏洩」とも呼ばれ、クラウド・ソフトの供給リスクにおいて深刻なセキュリティ対策上の課題となっています。開発者が意図せずコードに認証情報を埋め込んでしまったり、設定ファイルを誤って公開してしまうケースが多く、一度インターネット上に公開されてしまうと、攻撃者が自動化されたツールで瞬時に発見し悪用する可能性があります。
特にクラウドサービスの普及に伴い、AWS、Azure、Google Cloud Platformなどのアクセスキーの漏洩が急増しており、これによる不正アクセスや情報漏洩が企業の経営を揺るがす重大なセキュリティインシデントに発展するケースが相次いでいます。
シークレット漏洩を簡単に言うと？
シークレット漏洩を身近な例えで説明すると、「家の鍵の置き場所を、誰でも見られる掲示板に書いてしまう」ようなものです。
たとえば、あなたが自宅の玄関マットの下に合鍵を隠しているとします。これは便利な方法ですが、もしこの情報を自分のブログやSNSに「万が一のために、うちの鍵は玄関マットの下にあります」と書いてしまったらどうでしょうか。誰でもその情報を見ることができ、悪意のある人があなたの家に侵入できてしまいます。
シークレット漏洩もこれと同じです。開発者は便利さを優先して、プログラムのコードの中に「このサービスにアクセスするためのパスワードは○○です」という情報を書き込んでしまうことがあります。そのコードをインターネット上の誰でも見られる場所（GitHubなどのコード共有サイト）に公開してしまうと、攻撃者がその情報を見つけて、あなたの会社のシステムやクラウドサービスに侵入できてしまうのです。
さらに悪いことに、インターネット上には「鍵を探す泥棒」が24時間365日、自動的に新しく公開されたコードを監視しており、漏洩した認証情報を数分以内に発見して悪用しようとしています。一度公開してしまった情報は、後から削除しても完全には消えず、様々な場所にコピーされている可能性があるため、被害を防ぐことが困難になります。
シークレット漏洩の現状
シークレット漏洩の現状は、極めて深刻な状況にあります。GitHubの公式発表によると、2024年だけで3,900万件以上のシークレットが同プラットフォーム上で漏洩していることが確認されました。これは1日あたり約10万件以上のペースで認証情報が露出していることを意味します。GitHubは毎分数件のシークレットをプッシュ保護機能でブロックしていますが、それでもなお大量の機密情報が漏洩し続けています。
日本国内でも、シークレット漏洩を含む情報漏洩事故が増加傾向にあります。東京商工リサーチの調査によると、2024年に上場企業とその子会社が公表した個人情報の漏洩・紛失事故は189件に達し、4年連続で過去最多を更新しました。このうち、ウイルス感染・不正アクセスによる事故が114件と6割以上を占めており、その多くにクラウドサービスのアクセスキー漏洩が関与していると考えられています。
具体的な事例として、2024年にはトヨタモビリティサービスがAWSのアクセスキーを悪用された不正アクセスにより、データ削除と個人情報流出の被害を受けました。また、2025年5月にはイーロン・マスク氏が率いるxAIの開発者が、SpaceXやTeslaの機密AIモデルにアクセス可能なAPIキーをGitHub上に誤って公開し、約60の非公開大規模言語モデルへのアクセス権限が露出する事態が発生しました。このAPIキーは3月に発見されたにもかかわらず、4月末まで有効な状態が続いていました。
特に注目すべきは、シークレット漏洩の検出と悪用のスピードです。攻撃者は自動化されたボットを使用してGitHubなどのコード共有プラットフォームを常時監視しており、新たに公開されたAPIキーやアクセストークンを数分から数時間以内に発見します。GitGuardianなどのセキュリティ企業の研究によれば、漏洩した認証情報の悪用は公開後24時間以内に開始されるケースが多く、被害の拡大を防ぐための時間的余裕がほとんどありません。
また、最近の傾向として、AI関連企業によるAPIキーの漏洩が増加しています。Hugging Face、Azure OpenAI、WeightsAndBiasesなどのAIプラットフォームのトークンやAPIキーが頻繁に露出しており、これにより企業の独自AIモデルや学習データへの不正アクセスのリスクが高まっています。これらの漏洩の多くは、Jupyter Notebookファイル（.ipynb）、Pythonファイル（.py）、環境設定ファイル（.env）に認証情報が記載されたまま公開されることが原因です。
2024年には、誤って非公開リポジトリを公開設定にしてしまうミスも過去最高水準に達しました。開発者は意図的にシークレットを公開しているわけではなく、むしろセキュリティ対策への理解不足や、開発スピードを優先するあまり認証情報の適切な管理を怠ってしまうケースが大半を占めています。
シークレット漏洩で発生する被害は？
シークレット漏洩が発生すると、企業や組織に深刻な被害がもたらされます。漏洩した認証情報を攻撃者が悪用することで、様々な形態の損害が発生します。被害は直接的なものと、間接的に波及するものの両方があり、その影響範囲は漏洩したシークレットの権限レベルによって大きく異なります。
シークレット漏洩で発生する直接的被害
不正アクセスとデータ侵害
漏洩したAPIキーやアクセストークンを使用して、攻撃者は正規のユーザーとして認証を通過し、クラウドサービスやデータベースに侵入します。トヨタモビリティサービスの事例では、AWSのアクセスキーが悪用され、クラウド上のデータが削除されるとともに個人情報が流出しました。東京ガスグループの子会社では、ネットワークへの不正アクセスにより416万人分の顧客情報が漏洩し、2024年最大の個人情報漏洩事故となりました。攻撃者は漏洩した認証情報を使って、顧客データ、財務情報、知的財産、従業員の個人情報など、企業が保有するあらゆる機密データにアクセスし、窃取または改ざんする可能性があります。
クラウドリソースの不正利用
クラウドサービスのアクセスキーが漏洩した場合、攻撃者は企業のクラウドアカウントを使用して大規模な計算リソースを消費します。特に多いのが、暗号通貨のマイニングに悪用されるケースです。攻撃者は漏洩したAWSやGCPのアクセスキーを使用して、高性能なコンピューティングインスタンスを大量に起動し、暗号通貨を採掘します。この結果、企業には数百万円から数千万円規模の予期せぬクラウド利用料金が請求されることになります。また、これらのリソースがDDoS攻撃やスパムメール送信などの犯罪行為に使用されることもあり、企業のIPアドレスがブラックリストに登録される二次被害も発生します。
サービスの停止と機能不全
攻撃者が漏洩した認証情報を悪用してシステムの設定を変更したり、データを削除することで、企業のサービスが停止する被害が発生します。トヨタモビリティサービスの「Booking Car」では、不正アクセスによりデータが削除され、サービスが利用不能になりました。KADOKAWAでは2024年6月にサイバー攻撃を受け、動画サイトが一時的にサービス停止に追い込まれ、25万5,241人分の個人情報が外部に漏洩しました。サービス停止は直接的な売上損失につながるだけでなく、ユーザーの信頼を失い、長期的なビジネスへの影響を及ぼします。
シークレット漏洩で発生する間接的被害
法的責任とコンプライアンス違反
シークレット漏洩により個人情報や機密情報が流出した場合、個人情報保護法、GDPR（EU一般データ保護規則）、業界固有の規制などに違反する可能性があります。企業には行政処分、罰金、損害賠償請求などの法的責任が発生します。2024年の調査では、漏洩事故により企業が負担した補償費用や法的対応コストは、平均で数千万円から億単位に達しています。また、規制当局への報告義務違反や適切なセキュリティ対策を怠った場合、さらなる制裁が科される可能性があります。
企業イメージの毀損と顧客離れ
シークレット漏洩とそれに伴う情報流出が公表されると、企業の信頼性とブランドイメージは大きく損なわれます。顧客は自分の個人情報やビジネス情報を適切に保護できない企業との取引を避けるようになります。特にBtoB企業の場合、セキュリティインシデントの発生により既存取引先との契約が打ち切られたり、新規顧客獲得が困難になるケースがあります。サイバーセキュリティクラウドの調査によると、2024年には約3日に1回の頻度で企業のセキュリティインシデントが公表されており、業界全体でセキュリティ管理への注目が高まっています。
サプライチェーン全体への影響拡大
シークレット漏洩は、被害を受けた企業だけでなく、そのビジネスパートナーや顧客企業にも波及します。東京ガスグループの不正アクセス事例では、連鎖的に京葉ガスも81万人分の個人情報漏洩の被害を受けました。製造業ではサプライチェーン全体のリスク増加により、2024年に最も多くのセキュリティインシデント（24.8%）を経験しました。一社のシークレット漏洩が取引先や協力会社のシステムへの侵入口となり、業界全体のセキュリティリスクを高める結果となります。企業は自社のセキュリティだけでなく、取引先のセキュリティ管理体制も含めた包括的なセキュリティ対策が求められています。
シークレット漏洩の対策方法
シークレット漏洩を防ぐためには、技術的な対策と組織的な取り組みの両方が必要です。以下では、非IT技術者でも理解できるよう、具体的なセキュリティ対策の方法を解説します。
シークレット管理専用ツールの活用
最も重要な対策は、認証情報をコードや設定ファイルに直接書き込まないことです。代わりに、AWS Secrets Manager、Azure Key Vault、Google Cloud Secret Managerなどの専用の管理ツールを使用します。これらのツールは、銀行の貸金庫のように認証情報を安全に保管し、必要なときだけアプリケーションが取り出せる仕組みを提供します。プログラムの中に「パスワードは12345」と書く代わりに、「貸金庫番号7の中身を使う」という指示だけを書くイメージです。これにより、コードが公開されても実際の認証情報は露出しません。
プッシュ保護機能の有効化
GitHubなどのコード管理プラットフォームが提供するプッシュ保護（Push Protection）機能を必ず有効にします。この機能は、開発者がコードをアップロードしようとした際に、その中にAPIキーやパスワードなどの機密情報が含まれていないか自動的にスキャンします。もし検出された場合、アップロードを自動的にブロックし、開発者に警告を表示します。GitHubは2024年2月から全ての公開リポジトリでこの機能をデフォルトで有効にしましたが、組織が管理する非公開リポジトリでも必ず有効化する必要があります。
定期的な認証情報のローテーション
APIキーやアクセストークンは、定期的に新しいものに交換（ローテーション）します。Google Cloud Platformのベストプラクティスでは、APIキーを90日以内にローテーションすることが推奨されています。これは、仮に認証情報が漏洩していても、定期的に無効化することで攻撃者が長期間悪用することを防ぐ効果があります。パスワードを定期的に変更するのと同じ考え方です。自動化ツールを使用すれば、手動で管理する負担を減らしながら、確実にローテーションを実施できます。
最小権限の原則の適用
各APIキーやアクセストークンには、その業務に必要な最小限の権限だけを付与します。たとえば、あるアプリケーションがデータを読み取るだけの機能しか必要としない場合、そのAPIキーには「読み取り専用」の権限だけを与え、「書き込み」や「削除」の権限は与えません。これにより、万が一そのAPIキーが漏洩しても、攻撃者ができることは限定されます。全ての部屋の鍵を渡す代わりに、必要な部屋の鍵だけを渡すイメージです。
シークレットスキャンとモニタリング
GitGuardianやTruffleHogなどのツールを使用して、既に公開されているコードやGitの履歴に認証情報が含まれていないか定期的にスキャンします。GitHub自体も無料のシークレットスキャン機能を提供しており、公開リポジトリだけでなく、組織の全リポジトリ（公開、非公開、内部、アーカイブ済み）を対象にスキャンできます。また、実際に認証情報が使用された際のログを監視し、通常とは異なるアクセスパターンを検出するモニタリング体制も重要です。
開発チームへのセキュリティ教育
技術的な対策と並行して、開発チームに対するセキュリティ教育が不可欠です。シークレット漏洩の多くは、開発者の認識不足や不注意によって発生します。「なぜシークレットをコードに書いてはいけないのか」「どのような情報がシークレットに該当するのか」「漏洩が発覚した場合の対応手順」などを定期的に教育します。また、セキュリティを優先する企業文化を醸成し、開発スピードとセキュリティのバランスを取ることが重要です。
環境変数と設定ファイルの分離
開発環境、テスト環境、本番環境で使用する認証情報は必ず別々のものにし、それぞれ適切に管理します。また、設定ファイル（.envファイルなど）をGitの管理対象から除外するため、.gitignoreファイルに必ず登録します。これにより、誤って認証情報を含むファイルがリポジトリにコミットされることを防ぎます。開発者全員がこのルールを遵守するよう、プロジェクトの初期段階で徹底することが重要です。
シークレット漏洩の対策を簡単に言うと？
シークレット漏洩の対策を身近な例えで説明すると、「貴重品の保管方法を工夫する」ことに似ています。
家に現金や貴金属を保管する場合、誰もが見られるテーブルの上に置きっぱなしにはしません。金庫に入れたり、隠し場所に保管したりします。そして、その金庫の場所や暗証番号を家族全員で共有する必要はなく、必要な人だけが知っていればよいのです。
シークレット漏洩の対策も同じ考え方です。認証情報という「デジタルの鍵」を、誰でも見られるコードの中に書くのではなく、専用の安全な「デジタル金庫」（シークレット管理ツール）に保管します。そして、アプリケーションが動く際には、必要なときだけその金庫から鍵を取り出して使い、使い終わったらまた金庫に戻します。
さらに、定期的に鍵そのものを新しいものに交換することで、万が一古い鍵が盗まれていても被害を最小限に抑えます。また、各鍵には「この鍵で開けられるのは寝室だけ」「この鍵では玄関しか開けられない」というように、必要最小限の権限だけを与えます。
そして最も重要なのは、家族全員が「鍵の管理方法」を理解し、適切に扱うことです。いくら高性能な金庫を買っても、その使い方を知らなければ意味がありません。開発チーム全員がシークレット管理の重要性を理解し、日々の業務で実践することが、シークレット漏洩を防ぐ最も確実な方法なのです。
シークレット漏洩に関連した攻撃手法
シークレット漏洩は単独で発生することもありますが、多くの場合、他のサイバー攻撃や脆弱性と連携して深刻な被害をもたらします。ここでは、シークレット漏洩と関連性の高い攻撃手法を3つ紹介します。
サプライチェーン攻撃との関連
シークレット漏洩は、サプライチェーン攻撃の重要な足がかりとなります。サプライチェーン攻撃とは、標的企業に直接攻撃するのではなく、その取引先やソフトウェア供給元を経由して侵入する手法です。攻撃者は、まず比較的セキュリティが弱い下請け企業や協力会社のコードリポジトリからAPIキーやアクセストークンを入手します。これらの漏洩したシークレットを使用して、下請け企業のシステムに侵入し、そこから本命である大企業のネットワークに横展開していきます。
東京ガスグループと京葉ガスの連鎖的な情報漏洩事例がこれに該当します。子会社のネットワークへの不正アクセスが、グループ全体の顧客情報漏洩につながりました。特にクラウド環境では、一つの企業のAWSアクセスキーが漏洩すると、そのアカウントと連携している他社のシステムへもアクセス可能になる場合があります。
シークレット漏洩を防ぐことは、サプライチェーン全体のセキュリティを守ることに直結します。企業は自社のシークレット管理だけでなく、取引先や協力会社のセキュリティ対策も評価し、サプライチェーン全体でのシークレット管理基準を確立する必要があります。製造業で特にセキュリティインシデントが多い（24.8%）のは、複雑なサプライチェーンを持つためであり、一社の漏洩が業界全体のリスクとなります。
CI/CD資格情報の流出との関連
CI/CD（継続的インテグレーション／継続的デリバリー）パイプラインは、ソフトウェア開発において自動的にコードをビルド、テスト、デプロイする仕組みです。この自動化プロセスでは、多数のシークレットが使用されます。クラウドへのデプロイに必要なアクセスキー、コンテナレジストリの認証情報、データベース接続文字列などが、CI/CDツール内に保管されています。
攻撃者がCI/CDパイプラインにアクセスできれば、そこに保存されている全てのシークレットを一度に入手できます。GitHubのワークフローログや、JenkinsなどのCI/CDツールの設定ファイルが誤って公開されることで、これらの資格情報が漏洩するケースが増えています。xAIの事例では、開発者がGitHub上に公開したコードからAPIキーが流出しましたが、このようなケースではCI/CDパイプラインに保存されていた他の認証情報も危険にさらされます。
シークレット漏洩を防ぐためには、CI/CDパイプライン専用のシークレット管理が必要です。GitHub ActionsのSecretsやGitLab CI/CDの変数暗号化機能を使用し、ワークフローログには認証情報が記録されないよう設定します。また、CI/CDで使用するアクセスキーには最小権限を与え、定期的にローテーションすることで、万が一の漏洩時の被害を限定します。
クラウド設定不備との関連
シークレット漏洩は、クラウド環境の設定不備と組み合わさることで、被害が拡大します。クラウド設定不備とは、クラウドサービスのセキュリティ設定が適切に行われていない状態を指します。例えば、AWSのS3バケットが誤って公開設定になっている、ファイアウォールルールが緩すぎる、多要素認証が有効化されていない、などのケースです。
漏洩したAPIキーやアクセストークンの権限が強すぎる場合、攻撃者はクラウド環境全体を掌握できます。トヨタモビリティサービスの事例では、AWSアクセスキーが悪用され、データ削除という深刻な被害につながりました。これは、漏洩したアクセスキーに強力な権限が付与されていたことと、クラウド環境の監視体制が不十分だったことが重なった結果です。
さらに問題なのは、多くのクラウド環境で「プロジェクト全体のSSHキー」や「管理者権限を持つサービスアカウントキー」が使用されていることです。これらが漏洩すると、攻撃者はクラウド内の全リソースにアクセスできてしまいます。Google Cloud Platformのベストプラクティスでは、プロジェクト全体のSSHキーをブロックし、特定のインスタンスのみにアクセスできるキーを使用することが推奨されています。
シークレット漏洩対策とクラウド設定の適切化は、両輪として実施する必要があります。強固なシークレット管理を行っても、クラウドの設定が不適切であれば攻撃者に悪用される可能性が残ります。逆に、完璧なクラウド設定を行っても、シークレットが漏洩すればその防御は無意味になります。両方の対策を組み合わせることで、初めて効果的なセキュリティ対策となります。
シークレット漏洩のよくある質問
Q1: シークレット漏洩はどのくらいの時間で攻撃者に発見されますか？
A1: 非常に短時間で発見される可能性が高いです。攻撃者は自動化されたボット（プログラム）を使用して、GitHubなどのコード共有サイトを24時間365日監視しています。新しくコードが公開されると、そのコード内にAPIキーやアクセストークンが含まれていないか自動的にスキャンされます。セキュリティ専門家の調査によると、漏洩した認証情報は公開後数分から数時間以内に発見され、24時間以内に悪用が開始されるケースが多いとされています。つまり、「後で削除すればいい」という考えは通用せず、一度公開してしまうと即座に危険な状態になると理解する必要があります。
Q2: 過去にGitHubに公開してしまった認証情報を削除すれば安全ですか？
A2: 残念ながら、単純に削除するだけでは不十分です。Gitの仕組み上、コミット履歴には削除前の情報が残り続けます。また、GitHubでは多くのユーザーがリポジトリをフォーク（複製）できるため、あなたが元のファイルを削除しても、誰かのフォークには漏洩した情報が残っている可能性があります。さらに、Wayback MachineなどのWebアーカイブサービスや、攻撃者が運営する自動収集システムによって、既にコピーが保存されている場合もあります。
もし過去に認証情報を誤って公開してしまった場合、以下の手順が必要です：（1）該当するAPIキーやアクセストークンを直ちに無効化する、（2）新しい認証情報を発行して差し替える、（3）Gitの履歴から完全に削除する（git filter-branchやBFG Repo-Cleanerなどのツールを使用）、（4）関連するシステムのログを確認し、不正利用の痕跡がないか調査する。最も重要なのは、漏洩した認証情報をできるだけ早く無効化することです。
Q3: 環境変数に保存すれば安全ですか？
A3: 環境変数の使用は、コードに直接書き込むよりは安全ですが、完全に安全とは言えません。環境変数も設定方法によっては漏洩のリスクがあります。例えば、環境変数を設定するための.envファイルをGitリポジトリにコミットしてしまう、CI/CDツールのログに環境変数の値が記録されてしまう、コンテナイメージに環境変数が埋め込まれたまま公開してしまう、などのケースで漏洩します。
より安全な方法は、AWS Secrets Manager、Azure Key Vault、Google Cloud Secret Managerなどの専用のシークレット管理サービスを使用することです。これらのサービスは、暗号化された状態で認証情報を保管し、アクセスログを記録し、定期的なローテーションをサポートします。アプリケーションは起動時や必要な時だけ、これらのサービスから認証情報を取得して使用します。環境変数を使う場合も、その値には「シークレット管理サービスの参照ID」だけを入れ、実際の認証情報は入れないという使い方が推奨されます。
Q4: 非公開リポジトリなら安全ですか？
A4: 非公開リポジトリであっても、シークレットをコードに含めることは避けるべきです。非公開リポジトリには複数のリスクが存在します。まず、アクセス権を持つ全ての開発者がその認証情報を見ることができるため、従業員の退職や契約終了時に情報が社外に持ち出される可能性があります。また、誤って非公開リポジトリを公開設定にしてしまうミスが、2024年には過去最高水準で発生しています。
さらに、GitHubのアカウントが乗っ取られた場合、非公開リポジトリの内容も攻撃者に閲覧されます。2024年には「GhostAction」と呼ばれる攻撃で、GitHubアカウントが侵害され3,325件の認証情報が盗まれる事件も発生しました。非公開リポジトリは「公開リポジトリよりは安全」ですが、「完全に安全」ではありません。認証情報は常にシークレット管理ツールで管理し、リポジトリには含めないことがベストプラクティスです。
Q5: シークレット漏洩を検知するツールは無料で使えますか？
A5: はい、多くの無料ツールが利用可能です。GitHubは無料で「Secret Scanning」機能を提供しており、公開リポジトリだけでなく、組織アカウントであれば全てのリポジトリ（非公開、内部、アーカイブ済みを含む）をスキャンできます。また、「Push Protection」機能も無料で利用でき、シークレットを含むコードのプッシュを自動的にブロックします。
その他にも、GitGuardian（個人利用は無料プランあり）、TruffleHog（オープンソース）、Gitleaks（オープンソース）などのツールがあります。これらのツールは、既存のリポジトリをスキャンして過去のコミット履歴からもシークレットを検出できます。無料ツールでも基本的なシークレット検出は可能ですが、大規模な組織で高度な管理機能が必要な場合は、有料版の導入を検討するとよいでしょう。重要なのは、これらのツールを導入するだけでなく、検出されたシークレットに対して適切に対応することです。
Q6: APIキーの代わりに使うべき認証方法はありますか？
A6: 状況に応じて、APIキーよりも安全な認証方法が複数あります。Webアプリケーションでユーザー認証が必要な場合は、OAuth 2.0やOpenID Connectを使用します。これらの方式では、パスワードやAPIキーを直接扱わず、一時的なアクセストークンを使用するため、より安全です。
クラウド環境では、「マネージドID」や「ワークロードアイデンティティ」と呼ばれる仕組みを使用することで、APIキーなしで認証できます。例えば、AWSの「IAM Role」、AzureのManaged Identity、GCPのWorkload Identityを使用すれば、アプリケーションやサービスに明示的なAPIキーを渡さなくても、クラウドリソースにアクセスできます。これは、運転免許証を持ち歩く代わりに、顔認証で身分を証明するようなイメージです。
ただし、外部のサードパーティAPIを使用する場合など、APIキーの使用が避けられない場合もあります。その場合は、APIキーの適切な管理（シークレット管理ツールの使用、定期的なローテーション、最小権限の付与）を徹底することが重要です。
更新履歴
- 初稿公開
