情報漏洩のしょうもない原因を防ごう

テクノロジーが発達した現代でも、本当にくだらないミスで情報漏洩しています。ということで、自分が他人の案件でサポート入った時に、遭遇したパターンについてまとめてみます。

1. 公開領域に、拡張子を変える形でバックアップファイルを置いている

残念ながら頻繁にあります。 バックアップファイルを作成するだけならまだ良いのですが、元の拡張子を変えて保存してしまったファイルは超危険です。

例えば、公開領域に wp-config.php というファイルがあると仮定します。このファイルのバックアップとして wp-config.php_20230429 というファイルを複製した場合、拡張子が .php_20230429 と認識されるため、PHPとしては処理されません。

PHPとして処理されないテキストファイルは、ただのプレーンテキストとして認識されてしまい、ブラウザ上で wp-config.php_20230424 にアクセスすると、ファイルの中身がそのまま表示されてしまいます。

2. 作業メモや、データが公開領域にアップロードされている

これもいまだ頻繁に遭遇します。

これまた、サポートで入ったプロジェクトで本番環境の確認を行っていると、公開領域に作業用のExcelやらメモ.txtがアップロードされていて、ヒヤッとすることが多々あります。 で、そういったプロジェクトでGitで管理されているリソースを確認してみると、 公開領域に相当するフォルダに、メモ書きや作業用のファイルがコミットされていたりします。

そういったプロジェクトで、VCSでどのようにリソースが管理されているのかを見ると、本番にアップするソースと、本番にアップしてはいけないものも含めて一緒くたにコミットされていることが多々あります。

例えば、下記構成でリソースがVCSで管理されていると仮定します。

• プロジェクトのルートフォルダ
  • public ... ここにhtmlなどのリソースが置かれている

この場合に、public に作業メモや、非公開にすべきデータをコミットしているケースが多々ありました。この場合、その手のファイルをVCSで管理するなら、せめて下記のようにするのが正しいと思います。

• プロジェクトのルートフォルダ
  • data ... ここに本番にはアップしないファイルなどを置く
  • public

些細なことかもしれませんが、この程度の整理を行うだけで、本番に余計なファイルをアップロードするリスクは軽減できます。

まとめ

デプロイがいくら自動化されても、公開領域と非公開領域を意識せずにファイルを取り扱っていると、公開されては困るものがうっかり本番にアップロードされてしまうトラブルが防げないので気をつけましょう。