公開日
シークレット漏洩の40.6%は"放置"されている！クラウド設定の実態調査
クラウドストレージは、現代のソフトウェア開発やデータ管理に不可欠な存在です。しかし、設定の不備が原因で、機密情報が意図せず外部に公開されてしまうリスクも潜んでいます。特に、APIキーやパスワードといった「シークレット」情報が漏洩すると、サービスへの不正アクセス、データ侵害、インフラの乗っ取りといった壊滅的な被害に繋がりかねません。
この記事では、Soufian El Yadmani氏らによる研究論文「The File That Contained the Keys Has Been Removed: An Empirical Analysis of Secret Leaks in Cloud Buckets and Responsible Disclosure Outcomes」（2025年）を基に、公開状態のクラウドバケット（Amazon S3、Google Cloud Storageなど）からシークレット情報がどれだけ漏洩しているのか、そして脆弱性を発見し報告する「責任ある開示」がどの程度機能しているのか、その実態を詳しく解説します。
危険な「シークレット」とは？ なぜ漏洩が深刻な問題なのか
まず、「シークレット」とは、システムやデータへのアクセスを制御するための機密情報を指します。具体的には以下のようなものです。
- APIキー: クラウドサービスや外部APIを利用するための認証鍵。
- 認証情報: データベースや各種サービスへのログインに使用するユーザー名とパスワード。
- トークン: 一時的なアクセス許可を与える文字列。
- 証明書: 通信の暗号化や認証に使われる電子的な証明書。
これらのシークレットが、設定ミスで誰でもアクセスできる状態のクラウドストレージ（公開バケット）に置かれてしまうと、攻撃者の標的となります。漏洩したシークレットが悪用されると、以下のような深刻な事態を招く可能性があります。
- 個人情報や企業秘密の窃取
- サービスの停止
- 不正なリソース利用（暗号資産マイニングなど）
- 他のシステムへの侵入（ラテラルムーブメント）
- インフラ全体の乗っ取り
このように、シークレットの漏洩は、単なる情報流出に留まらず、ビジネス継続に重大な影響を与えかねない深刻な問題なのです。
【調査の概要】公開クラウドバケットからシークレットを発見・報告・追跡
今回の研究では、シークレット漏洩の実態を明らかにするため、以下のステップで大規模な調査が行われました。
- データ収集: 公開クラウドバケットの情報を提供するプラットフォーム「GrayhatWarfare」を利用し、調査対象となる公開バケットのリストを取得。対象はAWS S3、Azure Blob Storage (ABS)、Google Cloud Platform (GCP)、DigitalOcean Spaces (DOS) の主要4プラットフォーム。
- ファイルスキャン: バケット内から、開発時によく使われシークレットが含まれやすい特定の拡張子（例:
.env,.yml,.json,.py,.sh）を持つファイルを特定。これらのファイルの内容を正規表現で検索し、シークレット候補を抽出。 - 有効性検証: 発見されたシークレット候補が実際に有効か、サービスに影響を与えない「非侵入的」な方法で検証。具体的には、各サービスのAPIに問い合わせてステータスコードを確認したり、公式SDKを使って認証を試したりしました。これにより、誤検知（False Positive）を排除し、実際にリスクのあるシークレットのみを特定。
- 責任ある開示: 有効と確認されたシークレットについて、バケットの所有者を特定。セキュリティ専門組織「CSIRT.global」と連携し、所有者またはクラウドプロバイダーに脆弱性情報を報告。
- 修正状況の追跡: 報告後、所有者が実際に問題を修正したか、どのような対策を講じたかを継続的に監視・記録。
調査時点の公開バケット数（2024年1月19日）
| クラウドプロバイダー | バケット数 |
|---|---|
| ABS | 55,846 |
| AWS | 316,180 |
| DOS | 7,138 |
| GCP | 74,132 |
| 合計 | 453,296 |
クラウドから漏洩したシークレットの実態データ
この調査により、シークレット漏洩に関する衝撃的な事実が明らかになりました。
発見された有効なシークレットは215件！どのプラットフォームにもリスクあり
スキャンと検証の結果、実際に有効で悪用可能なシークレットが合計215件も発見されました。これは調査対象の一部であり、氷山の一角に過ぎない可能性がありますが、設定ミスによる漏洩が決して稀ではないことを示しています。
プラットフォーム別では、バケット数が最も多いAWSでの発見数が最多（162件）でしたが、GCP（32件）、ABS（18件）、DOS（3件）でも有効なシークレットが見つかりました。バケット数に関わらず、どのプラットフォームでも設定ミスによるリスクは存在します。
クラウドプロバイダー別 シークレット漏洩の発見・報告・修正状況
| プロバイダー | 発見件数 | 報告件数 | 修正件数 |
|---|---|---|---|
| ABS | 18 | 8 | 6 |
| AWS | 162 | 129 | 82 |
| DOS | 3 | 2 | 0 |
| GCP | 32 | 21 | 7 |
| 合計 | 215 | 160 (71.42%) | 95 (59.37%) |
危険なシークレットはどんなファイルに？
これらのシークレットは、どのような種類のファイルに含まれていたのでしょうか？以下の表は、ファイル拡張子ごとの発見状況を示しています。
ファイル拡張子別 シークレット発見・報告状況
| 拡張子 | ユニークファイル中の発見率 | 発見件数 | 報告件数 |
|---|---|---|---|
| bat | 0.0062% | 3 | 3 |
| conf | 0.0019% | 4 | 2 |
| config | 0.0981% | 22 | 20 |
| env | 0.4384% | 24 | 22 |
| ini | 0.0016% | 4 | 2 |
| json | 0.0008% | 33 | 14 |
| ps1 | 0.0292% | 4 | 4 |
| py | 0.0187% | 40 | 26 |
| sh | 0.0859% | 37 | 29 |
| yml | 0.0099% | 44 | 38 |
| 合計 | 0.0036% | 215 | 160 |
環境設定ファイル（.env）、設定ファイル（.config）、シェルスクリプト（.sh）、YAMLファイル（.yml）、Pythonスクリプト（.py）、JSONファイル（.json）などで多くの漏洩が確認されました。これらは開発プロセスで頻繁に使われ、シークレット情報を直接書き込む「ハードコーディング」をしてしまいがちです。また、本来公開すべきでない設定ファイルが誤って公開バケットに置かれるケースも多いと考えられます。特に.envファイルは、発見されたユニークファイル数に対するシークレット発見率が他の拡張子より高い傾向にありました。
どんな種類のシークレットが漏洩していたのか？その危険性は？
漏洩していたシークレットの種類を見ると、その危険性の高さが分かります。
発見されたシークレットの種類別件数トップリスト
| シークレットの種類 | 発見件数 |
|---|---|
| AWS アクセストークン | 100 |
| GCP サービスアカウントキー | 32 |
| Slack Webhook | 15 |
| SendGrid API キー | 14 |
| AWS SES SMTP 認証情報 | 13 |
| OpenAI API キー, Facebook アクセストークン, Stripe API キー | 6 |
| Twitter(現X) API キー | 4 |
| GitHub パーソナルアクセストークン, GitLab Runner トークン | 3 |
| Dropbox, Telegram Bot, Twilio, Mailgun | 2 |
| その他（URL内パスワード, CrowdStrike, GitHub Client等） | 1 |
| 合計 | 215 |
最も多かったのはAWSアクセストークン（100件）、次いでGCPサービスアカウントキー（32件）です。これらはクラウドインフラ自体へのアクセス権限を与える非常に強力なシークレットであり、漏洩した場合の影響は甚大です。攻撃者はこれらを利用し、サーバー（EC2など）の不正起動、機密データ（S3など）へのアクセス、ユーザー権限の変更などが可能になります。
その他、メッセージングサービス（Slack）、メール配信（SendGrid, AWS SES）、AI（OpenAI）、決済（Stripe）などのAPIキーや認証情報も多数発見されました。これらが悪用されると、なりすましメッセージの送信、スパムメールの大量配信、不正決済などに繋がる恐れがあります。
漏洩ファイルの特性：古いファイルも危険、継続監視が重要
シークレットが含まれていたファイルには、どのような特徴があったのでしょうか。
漏洩ファイルの特性 - サイズ、最終更新日、拡張子、プロバイダー
ファイルサイズは比較的小さいものが多かった一方、最終更新日は非常に古いものから最近のものまで広範囲に分布していました。中には2014年や2016年に更新されたファイルから有効なシークレットが見つかるケースもあり、一度設定ミスで公開されると、長期間危険な状態が放置され続ける可能性があることを示唆しています。
さらに、以下は、報告後に修正されたファイルと未修正のファイル（2024年9月15日時点）の特性を比較したものです。
修正済み/未修正の漏洩ファイルの特性
修正されたファイル、されなかったファイル双方に、最終更新日が古いものが多数含まれています。これは、古いファイルだから安全とは言えず、継続的な監視と棚卸しの重要性を浮き彫りにしています。長年使われていたインフラに含まれるシークレットだった可能性もあり、修正の判断に時間がかかる、あるいは忘れ去られている可能性も考えられます。
「責任ある開示」は機能したか？組織の対応を分析
発見された有効なシークレットのうち、所有者を特定できた160件について、責任ある開示を通じて報告が行われました。その結果を見ていきましょう。
修正率は約6割、しかし約4割は未対応のまま
報告された160件のうち、調査期間中（報告開始から約5ヶ月）に 95件（59.4%） で何らかの修正措置が確認されました。これは、責任ある開示が問題解決に一定の効果を発揮していることを示しています。
特定・開示プロセスのサマリー（2024年9月15日時点）
| ステータス | 件数 |
|---|---|
| 報告済み | 160 |
| 報告前に所有者が解決 | 5 |
| 所有者不明 | 50 |
| 合計（発見数） | 215 |
しかし、逆に言えば、報告にも関わらず約4割（65件, 40.6%）は未修正のままという事実も見逃せません。報告が届いていない、問題を軽視している、修正方法が不明、修正による影響を懸念しているなど理由は様々考えられますが、依然として多くのリスクが見過ごされています。
組織の具体的な対応：トークン無効化が鍵だが実施は不十分なケースも
修正が確認された95件について、組織が講じた対策の内訳が以下の表です。主な対策は以下の3つ、およびその組み合わせでした。
- バケットへのアクセス制限: 公開設定を解除。
- ファイルへのアクセス制限: 特定ファイルへのアクセス権を変更。
- トークン（シークレット）の無効化: 漏洩したキーやパスワード自体を使えなくする。
所有者が講じたセキュリティ対策（修正済み95件の内訳）
| バケット制限 | ファイル制限 | トークン無効化 | 件数 |
|---|---|---|---|
| ✓ | ✓ | ✓ | 19 |
| ✓ | ✓ | 18 | |
| ✓ | 33 | ||
| ✓ | 19 | ||
| ✓ | ✓ | 6 | |
| 合計 | 95 |
理想的なのは3つ全てを実施すること（19件）ですが、実際にはトークン無効化のみ（33件）やファイル制限＋トークン無効化（18件）といった対応が多く見られました。ファイルやバケットへのアクセス制限だけでは、既に情報を取得されている場合に不十分であり、トークン自体の無効化が不可欠です。しかし、システムへの影響を考慮してか、トークン無効化を見送るケース（ファイル/バケット制限のみの合計25件）も存在しました。
対応速度の差：迅速な組織とそうでない組織
脆弱性報告からどのくらいの速さで対応したのでしょうか。以下は、修正された95件について、報告からの経過日数と、組織から研究チームへの連絡の有無を示しています。
インシデント対応速度（修正までの日数と連絡有無）
修正ケースの26件（報告全160件の16.3%）は報告から1日未満で対応が完了。さらにそのうち11件では組織からの連絡もあり、セキュリティ意識と対応体制が整っている組織の存在を示しています。
一方で、1日以上かかったケースでは組織からの連絡は急減。修正までに7日以上かかったケースも多く（28件）、中には数ヶ月を要したものもありました。全体として、報告に迅速に対応し、かつ報告者とコミュニケーションを取る組織は少数派であり、多くの組織では対応に時間がかかる、あるいは対応してもその旨を外部に伝えない傾向が見られました。
漏洩はどこで起きていた？国・業界別の傾向
シークレット漏洩が報告された160件の組織を、国別・業界別に見てみましょう。
報告された問題の国別件数（一部抜粋）
| 国 | 件数 |
|---|---|
| アメリカ | 52 |
| インド | 13 |
| オーストラリア, イギリス | 10 |
| ブラジル | 9 |
| 韓国 | 7 |
| … | … |
| 日本 | 1 |
| 合計160件 |
国別ではアメリカが突出（52件）していますが、インド、オーストラリア、イギリスなど、世界中の国で問題が確認されており、シークレット漏洩はグローバルな課題です。
報告された問題のセクター別件数（一部抜粋）
| セクター | 件数 |
|---|---|
| コンピュータ・情報技術 | 81 |
| 小売・卸売・Eコマース | 18 |
| 金融・保険 | 12 |
| 教育・研究 | 11 |
| メディア・出版・放送 | 8 |
| ヘルスケアサービス | 7 |
| 政府・公共機関 | 6 |
| 個人 | 5 |
| … | … |
| 合計160件 |
業界別では「コンピュータ・情報技術」セクターが圧倒的（81件）ですが、「小売」「金融」「教育」など、幅広い業界で漏洩が発生。これは、業界を問わず、クラウドを利用する全ての組織がシークレット管理に注意する必要があることを示しています。
【事例紹介】特に深刻だったシークレット漏洩ケース
調査では、特に影響が大きいと考えられる深刻な漏洩事例も発見されました。
ケース1: セキュリティ基盤を揺るがすAPIトークン漏洩 (CrowdStrike)
ある組織の公開バケットから、セキュリティ大手CrowdStrike社の統合セキュリティ基盤「Falcon Platform」の管理用APIトークンが発見されました。このトークンが悪用されれば、攻撃者は組織のセキュリティ設定（脅威検知ルール、ファイアウォール、ユーザー権限など）を自由に変更し、セキュリティ保護を完全に無効化したり、検知を回避して内部侵入したりできる、極めて危険な状態でした。幸い、報告後1日以内にファイル削除とキー無効化が行われ、迅速に対応されました。
ケース2: 230個のS3バケット情報が流出？AWS認証情報の漏洩
ある政府機関系のバケットから、多数のAWSサービス（DynamoDBや他の230個のS3バケットを含む）にアクセス可能なAWS認証情報が発見されました。これらのバケットにはログ、財務情報、インフラ関連データなどが含まれている可能性がありました。報告翌日にファイルはアクセス制限されましたが、数日後に再びアクセス可能になる事態が発生。再報告後、最終的にファイルは制限されましたが、キーの無効化までには至らなかった模様です（論文執筆時点）。これは、根本原因に対処しないと再発するリスクと、継続的な監視の重要性を示す事例です。
ケース3: なりすましメールに悪用？AWS SES SMTP認証情報の漏洩
Amazon Simple Email Service (SES)のSMTP認証情報が13件発見されました。これらが悪用されると、組織になりすましたフィッシングメール送信やマルウェア配布が可能になります。ある組織からは「本当にメールを送れるか証明してほしい」と要求があり、検証の結果、実際にテストメール送信が可能であることが確認されました。これは、漏洩した認証情報の実際の危険性と、報告内容の検証が必要となるケースがあることを示しています。最終的に、報告された13件中12件は認証情報が無効化されました。
クラウドからのシークレット漏洩を防ぐために
今回の調査結果は、クラウドからのシークレット漏洩が決して他人事ではなく、現実的な脅威であることを示しています。このリスクにどう立ち向かうべきでしょうか。
調査から見える課題
- 依然として高いリスク: クラウドプロバイダー側の対策が進んでも、設定ミスや開発プロセスの不備による漏洩は後を絶ちません。
- 組織間の対応格差: 報告への対応速度や質には大きなばらつきがあり、セキュリティ意識や体制の差がうかがえます。
- 修正の難しさ: 特に長年利用されているシークレットの無効化は、システムへの影響が大きく、対応が遅れたり不十分になったりする要因となり得ます。
今すぐできる！シークレット漏洩の予防策5選
これらの課題を踏まえ、推奨される具体的な対策を5つ挙げます。
- シークレット管理ツールの活用: AWS Secrets Manager や HashiCorp Vault 等を導入し、シークレットをコードに直接書き込む（ハードコーディング）のをやめ、動的に取得・管理します。
- 自動スキャンと監視の導入: 開発パイプラインやリポジトリ、クラウドストレージに対し、シークレット検知ツール（ TruffleHog , git-secrets , GitHub Secret Scanning など）を導入し、継続的に監視します。
- アクセス権限の最小化: 必要最小限の原則に従い、IAMポリシー等を適切に設定し、不要な権限を与えません。
- 安全な開発プラクティス:
.gitignore設定、Infrastructure as Code (IaC)の活用、コードレビューでの確認など、開発プロセス全体でセキュリティを意識します。 - 定期的なセキュリティ監査: 定期的にクラウド環境の設定やアクセス権限を見直し、意図しない公開設定や不要なシークレットがないかを確認します。
万が一、漏洩させてしまった場合の対応ステップ
もしシークレットを漏洩させた、あるいはその疑いがある場合は、迅速かつ冷静に対応します。
- 即時無効化: 漏洩した可能性のあるシークレットを直ちに無効化またはローテーション（変更）。
- 影響範囲調査: アクセスログ等を調査し、不正利用の有無や影響範囲を確認。
- 原因究明: なぜ漏洩したのか、根本原因を特定。
- 再発防止策の実施: 原因に基づき、設定の見直し、プロセスの改善、ツールの導入等の対策を実施。
まとめ：クラウドのシークレット管理は「自分事」
この記事では、研究論文に基づき、公開クラウドバケットからのシークレット漏洩の実態と責任ある開示の効果を解説しました。AWS、GCP、Azureなどの主要クラウドで、設定ミス等により機密情報（シークレット）が依然として多数漏洩しており、深刻なリスクとなっている現実が浮き彫りになりました。
責任ある開示によって約6割の漏洩は修正されるものの、組織の対応には大きなばらつきがあり、課題も残されています。クラウドを安全に利用するには、利用者一人ひとりがシークレット管理の重要性を認識し、適切な予防策とインシデント対応プロセスを確立することが不可欠です。この機会に、自社のクラウド設定や開発プラクティスを見直してみてはいかがでしょうか。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: