EC-CUBE 4系の.envの扱いについての話

「.env ファイルは（中略）本番環境での使用は推奨されません。 」についての話です。

EC-CUBE 4 系では環境ごとの設定を行うために .envというファイルが使われるようになりましたが、以前からこの .envの扱いについて個人的に疑問を感じていました。詳細は後述しますが、この .envは本番環境での使用が推奨されていないにも関わらずその注意喚起が「開発者向けドキュメント」でしかされていないのです。

先日、Twitterでこれに関するツイートが流れてきたので QT させていただきました。

これ前から疑問なんだけど使っちゃいけないのなら何でデフォルトで.env使うようにしてるんだろうって話だしベストプラクティスの説明も無かったと思う。DBのパスワードの扱いに関しては記事が山のようにあるけど.bashrcにも絶対に書かないかな https://t.co/G2lnoflaRL

— Y (@mattintosh4) 2021年3月31日

これに関して下記の返信をいただきました。

Apache2.4 の mod_access_compat が無効になっているサーバーで .env が公開されてしまった事例を知ってますし、https://t.co/5tJ6kuLLxe
.htaccessの修正をミスって不用意に公開されてしまうことを防ぐために、複数の対策をしておくのが良いかと

— 🍣大河内健太郎🕊💉 (@nanasess) 2021年3月31日

Apache2.4 の mod_access_compat が無効になっているサーバーで .env が公開されてしまった事例を知ってます

とのことで、なぜそれが .envを使ってはいけないということになるのか一瞬「？」となりましたが、なんとなく下記のようなことが起きたのだろうと思いました。以下は私の推測です。

EC-CUBE 4 系のシステム要件は Apacheは 2.4.x となっており、Apache 2.4 では Requireディレクティブに切り替わっていますが EC-CUBEのソースコードの .htaccessは 4.0.5 の段階でも Order、Allow、Denyディレクティブが使われています。これらは mod_access_compat 無効な環境では .htaccess内の Orderディレクティブが解釈できないため Apacheは 500 Internal Server Errorとなります。

Invalid command 'order', perhaps misspelled or defined by a module not included in the server configuration

このエラーに関しては EC-CUBEディレクトリ直下の .htaccessを書き換えれば動きます。直下の .htaccess以外にも下記の場所で Orderディレクティブが使われています。

• app/.htaccess
• bin/.htaccess
• dockerbuild/.htaccess
• src/.htaccess
• var/.htaccess

下記の差分は EC-CUBE 4.0.5 の .htaccessですが、正規表現が不要と思われる場所で Files ~が使われており index.phpの指定が index{任意の1文字}phpに一致するようになってしまっているのでこちらも修正しています。（初期段階から正規表現が正確ではなかったがその後も修正はされていないようです。また、Apacheでは Files ~ではなく FileMatchの使用を推奨しているため置き換えています）

--- .htaccess_   2021-04-03 22:55:56.000000000 +0900+++ .htaccess 2021-04-03 22:56:26.000000000 +0900@@ -1,13 +1,11 @@
 DirectoryIndex index.php index.html .ht
 
 <FilesMatch "^composer|^COPYING|^\.env|^\.maintenance|^Procfile|^app\.json|^gulpfile\.js|^package\.json|^package-lock\.json|web\.config|^Dockerfile|^\.editorconfig|\.(ini|lock|dist|git|sh|bak|swp|env|twig|yml|yaml|dockerignore|sample)$">
-    order allow,deny-    deny from all+    Require all denied</FilesMatch>
 
-<Files ~ "index.php">-    order deny,allow-    allow from all+<Files "index.php">+    Require all granted</Files>
 
 <IfModule mod_headers.c>

このことを知らない利用者がエラーの内容から「orderの行がエラーになってるのでコメントアウトしたら動いたので良しとした」という状態でアクセス制限が機能せず .envが漏洩してしまったのではないかと思われます。

ただ、事故の原因が推測通りの内容であったならば、

• EC-CUBEが .htaccessで mod_access_compat のディレクティブ（Order、Allow、Deny）を使用している
• mod_access_compat が必須であるにも関わらずシステム要件に記載が無い

という部分に問題があると思うので個人的には「.envを使ってはいけない」ことの事例としては微妙かなと感じました。

EC-CUBEに限らず .envは使われていて推測されやすいものです。データベース情報などの機密情報が含まれていて危険なのが予めわかっているはずなので特に気を使って下記のようなディレクティブを用意する方が利用者にとっては良いのではないかと思います。

# .htaccess 編集後は必ず .env が非公開になっているか確認してください<Files".env*">Requireall denied
</Files>

3 系ではデフォルトで EC-CUBEディレクトリ直下の htmlディレクトリをドキュメントルートとしていたためその上の階層にあるシステムに関するファイルには触れられないようになっていました。しかし、4 系では EC-CUBEディレクトリ直下をドキュメントルートにするようになったため .envのような機密情報が含まれたファイルが漏洩する危険性が高くなっています。

私はインフラ担当なのでアプリケーション担当者さんの作業にはあまり口を出したくないとは思っているのですが、4 系を扱っているアプリケーション担当者さんが非公開というかそこに置くべきではないファイル（例えば README.mdなど）を配置していたりするのでこれまでに指摘したことが何度かあります。

これは EC-CUBEにきちんとした利用者向けマニュアル（「"開発者向け"ドキュメント」の話ではありません）が用意されていないからではないかと感じることもあります。（OSSだしそこら辺は自己責任という意見もあるとは思いますが）

現行のソースでは FilesMatchの部分でアクセス拒否するパターンを徐々に追加していますが、これにも限界はあるので説明を設けた上で利用者自身に判断してもらった方がいいのではないかと思います。また、既存コードは長くなり読みづらくなりつつあるので「直下に配置されるファイル」と「それ以外のファイル」に分けてもらいたいところでしょうか。以下ざっくりとした例です。（※何らかの操作で追加作成されるようなファイルに関しては考慮していません）

<Files".env*">Requireall denied
</Files><Files".git*">Requireall denied
</Files># EC-CUBE ディレクトリ直下に配置されるファイルのうち非公開が推奨されるもの# https://httpd.apache.org/docs/2.4/ja/mod/core.html#filesmatch<FilesMatch"^(\.dockerignore|\.env(\.(dist|install))|COPYING|Dockerfile|composer\.json|composer\.lock|docker-compose\.yml|gulpfile\.js|package(|-lock)\.json|symfony\.lock|web\.config)$">Requireall denied
</FilesMatch># 非公開が推奨される拡張子# https://httpd.apache.org/docs/2.4/ja/mod/core.html#filesmatch<FilesMatch"\.(?i:bak|dist|ini|lock|sample|sh|sw[uwx][a-z]|twig|ya?ml)$">Requireall denied
</FilesMatch><Files"index.php">Requireall granted
</Files>

話を .envに戻して、私が最も気にしているのが「本番で .envを使ってはいけない」というのであれば「ではどうすればいいのか？」ということです。

現時点の EC-CUBEの「開発者向けドキュメント」では下記のように説明されています。

本番環境での .env ファイルの利用について

インストール完了後、インストールディレクトリにデータベースの接続情報等が設定された .envファイルが生成されます。 .envファイルは、開発用途での環境変数を設定するためのものであり、本番環境での使用は推奨されません。 本番環境では、環境変数をサーバ設定ファイルに設定することを推奨します。 サーバ設定ファイルに環境変数を設定することにより、環境変数が外部に暴露される危険性が減り、安全に運用できます。

https://doc4.ec-cube.net/quickstart_install/dotenv

この「本番環境での使用は推奨されません」という文言は EC-CUBEのサイトを一通り確認しましたが「開発者向けドキュメント」にしか記載されておらず、一般向けのページには記載がありませんでした。EC-CUBEデフォルトのインストール状態で .envが作成されるようになっており、その元となる .env.distにも注意文が無く、Symfonyデフォルトと思われる文言で「本番、ステージング、開発で使い分ける〜」のように書いてあります。

This file is a "template" of which env vars needs to be defined in your configuration or in an .env file
Set variables here that may be different on each deployment target of the app, e.g. development, staging, production.
https://symfony.com/doc/current/best_practices/configuration.html#infrastructure-related-configuration

実際、私が EC-CUBE関連のプロジェクトで関わったアプリケーションエンジニアさんに本番での .envの使用を禁止しているような人はいませんでした。

EC-CUBE社が公開しているセキュリティチェックシートも確認してみましたが .envの部分は「公開されているか否か」の確認だけであり、「.envファイルが存在しない」という確認方法ではありません。対応方法も現状の .htaccessでアクセス制限を行うだけで「.envの使用は推奨されていないためこちらをお読みいただきご対応ください」というような案内もありませんでした。

• ファイル名: security_checklist.xlsx
• 作成日: 2020/06/25, 07:39:47
• 更新日: 2020/12/10, 05:48:30

確認方法

EC-CUBEのURL直下(例: https://example.com/path/to/ec-cube/.env など)に .env ファイルが公開されていないか、ファイルの中身が表示されないことをご確認ください。

対応方法

EC-CUBE をインストールしたフォルダの .htaccess ファイルに以下の内容を追加し、保存してください。
<FilesMatch "^composer|^COPYING|^\.env|^\.maintenance|^Procfile|^app\.json|^gulpfile\.js|^package\.json|^package-lock\.json|web\.config|^Dockerfile|\.(ini|lock|dist|git|sh|bak|swp|env|twig|yml|yaml|dockerignore)$">
    order allow,deny
    deny from all
</FilesMatch>

このことについて「あくまで推奨であり、設定方法については自己責任」という方針なのかもしれませんが、普通に考えれば「本番」というものは「主」や「正」であり、その「本番」で推奨されないのであればその他の環境も合わせるべきではないかと個人的には思います。

.env の扱いについて考えてみる

あまり時間が取れないので少々雑ですがこちらに自分の見解をまとめておきます。

Symfonyではどう考えているのか？

EC-CUBE 4.0.x では Symfony 3.4 を使っているので Symfony 3.4 のドキュメントを見ればいいと思うのですが、どうも EC-CUBEの構造の所々が Symfony 4.x になっていると思われたため Symfony 4.0 と 4.4 のドキュメントも確認してみました。（結局 Symfonyの考えはよくわからなかったのですが）

Symfony 3.4 でも 4.x でも環境変数の設定は Web サーバレベル（httpd.conf、.htaccess）で設定することが推奨されていました。

（翻訳は DeepL におまかせしています）

Symfony 3.4

Setting environment variables is generally done at the web server level or in the terminal. If you’re using Apache, nginx or just the console, you can use e.g. one of the following:

https://symfony.com/doc/3.4/configuration/external_parameters.html#environment-variables

環境変数の設定は、一般的にウェブサーバーレベルかターミナルで行います。Apacheやnginxを使用している場合や、コンソールだけの場合は、例えば以下のいずれかを使用します。

Symfony 4.0

During development, you’ll use the .env file to configure your environment variables. On your production server, it is recommended to configure these at the web server level. If you’re using Apache or Nginx, you can use e.g. one of the following:

https://symfony.com/doc/4.0/configuration/external_parameters.html#configuring-environment-variables-in-production

開発段階では、.envファイルを使って環境変数を設定します。本番サーバーでは、Webサーバーレベルでこれらを設定することをお勧めします。ApacheやNginxを使用している場合は、例えば以下のようなものがあります。

Symfony 3.4 と 4.0 の説明で大きく違うのは「コンソール」の文言がなくなっていること。上記の説明の通り DATABASE_URLを Web サーバ側に設定すると、例えば console doctrine:migrations:statusを実行しようとしたときに $_SERVER["DATABASE_URL"]を参照しないためデータベースに接続できない問題が起きます。Symfony 3.4 のドキュメントが書かれていた時期に consoleコマンドで Doctrine 関連の処理が問題なくできたのかどうかはわかりませんが、少なくとも EC-CUBE 4.0.5 では DATABASE_URLを Web サーバレベルで設定すると consoleコマンドからはデータベースに接続できなくなります。

さらに、Web サーバレベルで設定する際の注意文が記載されています。

Beware that dumping the contents of the $SERVER and $ENV variables or outputting the phpinfo() contents will display the values of the environment variables, exposing sensitive information such as the database credentials.

The values of the env vars are also exposed in the web interface of the Symfony profiler. In practice this shouldn’t be a problem because the web profiler must never be enabled in production.

変数 $SERVER と $ENV の内容をダンプしたり、phpinfo() の内容を出力したりすると、環境変数の値が表示され、データベースの認証情報などの機密情報が公開されてしまうことに注意してください。

環境変数の値は、Symfonyプロファイラーの Web インターフェースでも公開されます。本番環境では Web プロファイラーを有効にしてはならないので、実際には問題にならないはずです。

動作として当然そうなるわけですが「注意して」とだけ言われても正直なところどうしていいかわかりません。

「では consoleコマンドを使う場合はどうするのか？」に関する説明は Symfonyのドキュメントからは見つけられませんでした。EC-CUBEではこの問題への対応として「開発者向けドキュメント」でシェル変数を使用する方法を紹介しているようです。

テキストファイルにデータベースのパスワードを平文で書くことは世間的に推奨されていないものですが、EC-CUBEに限らず PHPファイルや YAMLファイルに DB のパスワードを平文で書いているので .bashrcや .bash_profileに書いたところで何を今更…という感じはあります。海外の記事では「 /etc/environmentに書けばいいよ！」みたいなものもありました（それは流石にどうなんだ）。

なお、新しい Symfonyのバージョンでは暗号化する機能が追加されているようですが EC-CUBE 4.0.5 は対応していません。

EC-CUBEで紹介されている方法でもいいとは思うのですが、個人的には複数の場所にデータベースの情報持たせるのはやや抵抗があります。というのは実際の運用ではデータベースの切り替えやメールサーバの切り替えというものが発生します。これによって Web サーバレベルの DATABASE_URLとシェルの DATABASE_URLが異なり、consoleコマンドによって間違ったマイグレーションやメール配信が行われてしまう可能性が考えられます。

また、VirtualHost を使って Web サーバを共用している場合でも同じようなことが起こり得ます。例えば VirtualHost を使って本番環境と開発環境を分けている場合、アプリケーションはディレクトリや Web サーバレベルで分離していますが、シェルにはそのような機能はありません^*1。.envはシェルの文法を用いているため「開発環境では . .envや source .envで .bashrcで設定された環境変数をオーバーライドする」というような運用で環境を切り替えることは可能ですが、そこから本番環境の設定値に戻すには変数の解除か再ログインが推奨されます^*2。

*1: 環境毎にログインユーザを分ける場合は除く。
*2: 再読み込みではどちらかでしか定義されていない変数を明確に解除できないため。

このようなことから consoleコマンドのためにシェルに変数を設定することは利用するサービスによって各々の対応が必要になるため私は良い選択だとは思いません。

シェルに関してはアプリケーションエンジニアさんがあまり詳しくないこともあるため、アプリケーション側だけでなんとかならないものだろうかと思っています。

.env が危険なのは本番に限った話ではない場合もある

「本番で推奨されないものを他の環境で使用しても問題ないのか？」という疑問があったので考えてみました。

まず、環境ごとに DATABASE_URLなどが含まれる .envの危険性を考えてみます。

ステージング環境と開発環境を「低〜高」としているのは、ステージング環境や開発環境に適切なアクセス制限が設けられている場合は「低」となりますが、アクセス制限が設けられていない場合や設定が不適切な場合は「高」にもなる可能性があるからです。

利用しているサービスやコストに制限があり、環境ごとにデータベースサーバが分離できない場合は全環境でデータベースサーバを共用してデータベースのみ分けている場合もあると思います。この状態で各環境の DATABSE_URLが下記のように設定されていたとします。

この場合、ステージングや開発から .envが漏洩した場合は本番から漏洩したことと同等になります。

Symfonyの「本番サーバでは Web サーバレベルで設定することを推奨」という説明は「本番（パブリック）」と「ローカル（プライベート）」の場合は適切な説明かもしれませんが、ステージングや開発からも漏洩の可能性があることを考えると「外部に公開されている環境での.envの使用は推奨されない」というのが適切な説明ではないかと思います。

アプリケーション側だけでうまく運用できないのか？

Symfonyのドキュメントでは .env以外に環境（prodや dev）を設定する方法として、3.4 では config_<env>.yml、4.0 では config/packages/<env>/*.yaml等があると説明されています。それぞれ「How to Master and Create new Environments」で説明されています。

• https://symfony.com/doc/3.4/configuration/environments.html
• https://symfony.com/doc/4.0/configuration/environments.html

「The Symfony Framework Best Practices」では現時点では Symfony 4.3 以降のドキュメントしか存在しないようですが、services_<env>.yamlについても説明されています。

• https://symfony.com/doc/4.4/best_practices.html

「Configuring Symfony」では Symfony 4.4 で config/packages/<env>や services_<env>.yamlについてもう少し詳しく説明されています。

• https://symfony.com/doc/4.4/configuration.html

他にも記載されているページはあるかもしれませんが、Symfonyのドキュメント自体がメンテナンスされていたりされていなかったりで探すのが非常に面倒なため上記のページに絞ります。（EC-CUBEで使われていると言われる Symfonyのバージョンもよくわからない）

https://symfony.com/doc/4.4/configuration.html#configuration-environmentsによると Symfonyには dev、prod、testという風に環境を分類して読み込まれるファイルの順番が決まっており、順に値を上書きできるとのこと。

A typical Symfony application begins with three environments: dev (for local development), prod (for production servers) and test (for automated tests). When running the application, Symfony loads the configuration files in this order (the last files can override the values set in the previous ones):

読み込まれる順については下記の通り。

1. config/packages/*.yaml (and *.xml and *.php files too);
2. config/packages/<environment-name>/*.yaml (and *.xml and *.php files too);
3. config/services.yaml (and services.xml and services.php files too);
4. config/services_<environment-name>.yaml (and services_<environment-name>.xml and services_<environment-name>.php files too).

この動作を信じれば環境毎に異なる値については .envを使わずとも config/packages/<env>や config/services_<env>.yamlで持たせることができるはずです。実際、EC-CUBE 4.0.5 ではデフォルトで app/config/services_dev.yamlが配置されていて dev時固有の設定が書かれています。

EC-CUBE 4.0.5 インストール直後の .envは下記のようになっています。（ホスト名とかは適当です）

APP_ENV=prod
APP_DEBUG=0DATABASE_URL=mysql://eccube:password@db/eccube
DATABASE_SERVER_VERSION=5.7.32-log
MAILER_URL=smtp://mail:25
ECCUBE_AUTH_MAGIC=MGZkOTIzY2EwNDkyNjM0YWM3NzVmNWY5
ECCUBE_ADMIN_ALLOW_HOSTS=[]ECCUBE_FORCE_SSL=falseECCUBE_ADMIN_ROUTE=adm1n
ECCUBE_COOKIE_PATH=/
ECCUBE_TEMPLATE_CODE=default
ECCUBE_LOCALE=ja

各項目を「環境毎に異なるか共通しているか」「漏洩した際に影響があるか」について考えてみます。（これについてはざっくりとした見解です）

とりあえず漏洩すると特に影響があるのは下記の 3 つです。ECCUBE_AUTH_MAGICに関してはデータベースの情報と組み合わせたときに問題になるため影響ありとしています。ECCUBE_ADMIN_ALLOW_HOSTSや ECCUBE_ADMIN_ROUTEに関しては仮に漏洩したとしても認証で守られているのでここでは除外します。

• DATABASE_URL
• MAILER_URL
• ECCUBE_AUTH_MAGIC

以下、対象を DATABASE_URLに絞ります。

ECCUBE 4.0.5 インストール直後で DATABASE_URLが使われているファイルは下記の 2 箇所です。

1  parameters:2 # Adds a fallback DATABASE_URL if the env var is not set.3 # This allows you to run cache:warmup even if your4 # environment variables are not available yet.5 # You should not need to change this value.6      env(DATABASE_URL):''7      env(DATABASE_SERVER_VERSION):~

17 # EC-CUBE parameter18      eccube_database_url:'%env(DATABASE_URL)%'19      eccube_mailer_url:'%env(MAILER_URL)%'20      eccube_admin_route:'%env(ECCUBE_ADMIN_ROUTE)%'21      eccube_user_data_route:'%env(ECCUBE_USER_DATA_ROUTE)%'22      eccube_admin_allow_hosts:'%env(json:ECCUBE_ADMIN_ALLOW_HOSTS)%'23      eccube_force_ssl:'%env(bool:ECCUBE_FORCE_SSL)%'

doctrine.yamlでは「フォールバック用として設定する」と説明されており、デフォルトでは DATABASE_URLは空に設定されています。eccube.yamlでは %env(DATABASE_URL)%によって環境変数から取得するようになっています。

上記の 2 箇所以外で DATABASE_URLは使われておらず、定義もされていないため動作としては .envや Web サーバの環境変数などから DATABASE_URLを取得することになります。

doctrine.yamlや https://symfony.com/doc/4.0/configuration/external_parameters.html#environment-variablesを見ればわかりますが、env()は参照しかできないわけではなく、YAML内で環境変数のデフォルト値を設定することができるようになっています。

parameters:env(DATABASE_HOST): localhost

EC-CUBE 4.0.5 でも eccube.yaml内で env()を使って環境変数のデフォルト値を定義しています。

1  parameters:2 # EC-CUBE default env parameters3      env(ECCUBE_ADMIN_ROUTE):'admin'4      env(ECCUBE_USER_DATA_ROUTE):'user_data'5      env(ECCUBE_ADMIN_ALLOW_HOSTS):'[]'6      env(ECCUBE_FORCE_SSL):false7      env(ECCUBE_TEMPLATE_CODE):'default'8      env(ECCUBE_AUTH_MAGIC):'<change.me>'9      env(ECCUBE_COOKIE_NAME):'eccube'10      env(ECCUBE_COOKIE_PATH):'/'11      env(ECCUBE_COOKIE_LIFETIME):012      env(ECCUBE_GC_MAXLIFETIME):144013      env(ECCUBE_PACKAGE_API_URL):'https://package-api.ec-cube.net'14      env(ECCUBE_OWNERS_STORE_URL):'https://www.ec-cube.net'15      env(ECCUBE_MAINTENANCE_FILE_PATH):'%kernel.project_dir%/.maintenance'

長くなってきたのでここからは若干端折って書きますが、先の Symfonyの説明の通り packages/*.yamlの情報は services.yamlや services_<env>.yamlで上書きができるので、.envに書いたり Web サーバの環境変数に設定する必要は無いと考えられます。

ただし、consoleコマンドはまず環境変数からチェックし、環境変数が設定されていないければ .envを参照するようになっています。APP_ENVの値は外部に漏れても特に問題ないので export APP_ENV=prodや APP_ENV=prod php bin/consoleと叩かなくて済むように APP_ENVは .envに書いておいていいと思います。

<?php:中略
:if(!isset($_SERVER['APP_ENV'])){if(file_exists(__DIR__.'/../.env')){(new Dotenv())->load(__DIR__.'/../.env');
    }else{(new Dotenv())->load(__DIR__.'/../.env.install');
    }}$input=new ArgvInput();
$env=$input->getParameterOption(['--env', '-e'], $_SERVER['APP_ENV']??'dev');

これらのことをまとめると機密情報は YAMLで管理し、それ以外の項目は .envで管理できそうです。

仮に「ECCUBE_AUTH_MAGICは全環境で共通」、「services_<env>.yamlは Git で管理されていない」という条件で環境別の構成例を考えると下記のようになります。本番とステージングで services_prod.yamlの名前は同じですが中の値は異なります。DATABASE_SERVER_VERSIONは DATABASE_URLとセットということにしています。同一の変数がある場合は右から順（services.yaml→ services_<env>.yaml→ .env）にオーバーライドされていきます。

services_<env>.yamlの設定についての話なので ECCUBE_AUTH_MAGICをどこに書くかはここではあまり深く考える必要はありません。

各 YAMLファイル例は下記の通りです。

parameters:env(DATABASE_URL): mysql://eccube:password@db_prod/eccube_prod
    env(DATABASE_SERVER_VERSION): 5.7.32-log
    env(MAILER_URL): smtp://mail_prod:25

parameters:env(DATABASE_URL): mysql://eccube:password@db_stg/eccube_stg
    env(DATABASE_SERVER_VERSION): 5.7.32-log
    env(MAILER_URL): smtp://mail_stg:25

parameters:env(DATABASE_URL): mysql://eccube:password@db_dev/eccube_dev
    env(DATABASE_SERVER_VERSION): 5.7.32-log
    env(MAILER_URL): smtp://mail_dev:25
services: # 開発時はエラーページを表示しないEccube\EventListener\ExceptionListener:autoconfigure:false

services: # 開発時はエラーページを表示しないEccube\EventListener\ExceptionListener:autoconfigure:false

この構成であれば

• .envに機密情報を書く必要が無い
• phpinfo()に情報が出ない
• Symfonyのプロファイラーに情報が出ない
• consoleコマンドがそのまま実行できる
• .envの APP_ENVで誤った環境（本番で dev等）を設定していてもエラーで止まる
• テンプレートの指定、IP 制限も管理画面から設定できる

というのは一応手元の環境で確認できました。（MAILER_URLも同様に設定しましたが特に問題はありませんでした）

.envを使用しているのは phpunitで必要になるからという情報も見かけたのですが phpunitでのテストはしていません。

長くなったのでこの辺で。