Webアプリを公開してしばらく経ったころ、身に覚えのない大量のスパムメールが、自分のAWSアカウントから送信されていることに気づきました。原因は、AWS Lightsail(手軽に立てられるサーバ)で動かしていたアプリの公開設定を誤り、.env ファイルが外部から読める状態になっていたこと。そこに書いていたAWSのアクセスキーを抜き取られ、メール送信サービス(Amazon SES)を悪用されていたのです。これは実際に起きた話で、筆者自身の失敗でもあります。
AIを使えばWebアプリやAPIサーバは手軽に作れます。ただ、作れることと、安全に公開できることは別です。この記事では、.env のような設定ファイルがなぜ外部に晒されるのか、見つかると何が起きるのか、どう防ぐのかを、実体験をふまえて整理します。
なぜ .env が外部から見えてしまうのか
.env は、APIキーやデータベースのパスワード、外部サービスの認証情報など、秘密の値をまとめて書いておくファイルです。本来はサーバの中だけで読まれるものですが、次のような理由で外から見える状態になることがあります。
- 公開フォルダ(Webサーバが外部へ配信する領域)の中に、
.envを置いてしまっている。 - Webサーバの設定ミスで、本来配信すべきでないファイルまで配信されている。
.gitフォルダやバックアップファイルごと公開してしまい、そこから設定や認証情報が読まれる。
一度でも公開領域に置かれると、URLを直接叩くだけで、ファイルの中身がそのままダウンロードできてしまいます。攻撃に高度な技術は要りません。
公開すると、すぐ自動探索の対象になる
やっかいなのは、こうしたファイルは「誰も知らないから見つからない」ものではない点です。世界中のボットが24時間、公開されているIPアドレスやドメインを機械的に巡回し、.env / .git / config / backup といった、機密情報が置かれやすいパスを自動で探し続けています。
公開サーバのアクセスログを見ると、身に覚えのないURLへのアクセスが記録されていることがあります。その中には、機密ファイルや既知の脆弱性を探す自動探索も含まれます。つまり、公開後は早い段階で自動スキャンの対象になり得る、という前提で考える必要があります。見つかっていないのではなく、まだ見つかっていないだけ、と考えておくくらいがちょうどよいです。
見つかると何が起きるか
.env が見つかり、中の認証情報が抜かれると、被害は一気に広がります。
- クラウド(AWSなど)の認証情報：冒頭で触れた、筆者が受けた被害がこれです。
.envに書いていたAWSのアクセスキーを抜き取られ、メール送信サービス(Amazon SES)を使って大量のスパムメールを送られました。送信元としての信頼を失い、ドメインが迷惑メール扱いでブロックされることもあります。さらに、その鍵に付与された権限によっては、勝手にリソースを作られる・削除される、データを持ち出される、高額な料金を請求される、といった取り返しのつかない被害にもつながります。 - 外部AIのAPIキー：第三者に使い放題にされ、身に覚えのない高額な利用料金が発生する。
- メール送信サービスやデータベースの認証情報：なりすまし送信や、保存しているデータの抜き取りにつながる。
鍵は隠す前提で扱う、という考え方はAPIキーをクライアント側に書いてはいけない理由とも共通します。
どう防ぐか
対策そのものは難しくありませんが、公開前に必ず押さえます。
優先順位で言うと、上から順に効きます。
- 公開フォルダの外に置く。Webサーバが配信する領域に、
.envやバックアップ、.gitを置かない。これが一番の基本です。 - 不要な機密ファイルをデプロイ対象から除外する。
.gitや開発用の.env、バックアップファイルを、公開用の成果物に含めない。本番で必要な秘密情報は、公開フォルダの外に置いた本番専用の設定ファイルや、環境変数・シークレット管理サービスから読み込ませる(サーバ本体が.envを読む構成自体は問題ありません。あくまで公開領域に置かない、という話です)。 - Webサーバ側でも配信を拒否する。
.envや.gitなどの機密性の高いドットファイル・設定ファイル・バックアップファイルを外部へ返さない設定にしておく(先頭が.のパスを一律で拒否すると/.well-known/など正当なものに影響することがあるため、対象は絞ります)。ファイル権限だけに頼らないための、もう一枚の壁です。 - ファイルの読み取り権限を絞る。必要なユーザーやプログラムだけが読める状態にする。ただし、Webサーバの実行ユーザーが読める場合は配信設定のミスで外へ出ることがあるため、上の配信拒否とセットで考えます。
- 鍵自体の権限を最小限にする。認証情報やAPIキーは、その用途に必要な最小限の権限で発行する。万一漏れても、被害の範囲を狭められます(最小権限の考え方に通じます)。
- そもそも長く使える鍵を置かない。AWS上で動くアプリなら、固定のアクセスキーを
.envに保存するより、可能な環境ではIAMロールなどの一時的な認証情報を使う方が安全です。漏らさない工夫だけでなく、長期間使える鍵を最初から置かない設計が効きます。 - 漏れた可能性があれば、侵害済みとして扱う。古い鍵をただちに無効化して新しい鍵へ切り替えるのはもちろん、それだけで終わりにしないこと。AWSなら操作履歴(CloudTrail)や利用料金、勝手に作られたリソース、メールの送信履歴などを確認し、すでに不正利用されていないかを調べます。コードや
.envから消すだけでは対処になりません。
AIで作れても、公開設定の勘は別
AIはコードを書くのは得意です。ですが、どのファイルを公開領域に置くか、サーバの配信設定をどうするか、といったインフラ周りは、AIに任せていても自動で安全になるわけではありません。とくにサーバ・インフラ回りは、勘が働かないまま、知らない間に危険な状態になりがちです。
公開時に確認すべきサーバ側の全体像はAIで作ったアプリのサーバは安全かに、環境変数そのものの扱いは環境変数の基本にまとめています。
今日やれる、設定ファイル流出の点検
公開しているサーバがあるなら、今すぐ確認できます。
- 自分のサイトのURLの末尾に
/.envを付けてブラウザで開いてみる。中身が表示・ダウンロードできたら、外部に晒されている状態。すぐ対処する。 - 同じように
/.git/configや、思い当たるバックアップファイル名でも試す。 - Webサーバのアクセスログを見て、
.envや.gitへの不審なアクセスが来ていないか確認する。 - 機密ファイルが公開フォルダの外にあるか、読み取り権限が絞れているかを確認する。
- 万一に備え、鍵をすぐ作り直せる(ローテーションできる)状態にしておく。
なお、/.env を開いて確認するとき、SPA(1枚のHTMLで画面を切り替える作り)などでは、存在しないURLでも同じHTMLが返り、通信上は正常(200)に見えることがあります。正常そうに見えただけで安心せず、実際に設定の中身が返っていないかを確かめてください。また、アクセスログに不審なアクセスが無くても安全とは限りません。ログの保存期間を過ぎていたり、CDNやプロキシ側にしか記録が残っていないこともあります。
まとめ
.envなどの設定ファイルは、公開フォルダに置く・配信設定のミス・.gitごと公開、などで外部から読める状態になる。- 公開後は早い段階から、ボットによる
.env/.git/configの自動探索の対象になり得る。「知られていないから安全」という前提は成り立たない。 - 抜かれると、大量スパムの踏み台、APIキー悪用による高額請求、クラウド認証情報の悪用など、致命的な被害につながる。
- 対策は、公開フォルダの外に置く・デプロイやWeb配信からも除外する・ファイル権限と鍵の権限を最小にする。漏れたら侵害済みとして無効化し、操作履歴や料金・不正リソースまで調べる。
- AIで作れても、公開設定やインフラの安全までは自動にならない。公開前の点検を習慣にする。
