php.iniファイル設置をセキュアにしたい

Question

経緯

これまでレンタルサーバでの運用
AWS EC2での運用を経験してきました。
EC2では予め用意されたphp.iniファイルを編集する形で
運用してきていたためパーミッションや設置ディレクトリに関しては気にしておりませんでした。
しかし、今回yamlにてphp.iniファイルを設置することとなり
改めてパーミッション、ユーザー、グループ、配置ディレクトリをどうすべきかを調べております。

前提・実現したいこと

php.iniファイル設置をセキュアにしたいです。
php.ini設置の際のパーミッション、ユーザー、グループ、配置ディレクトリの
セキュアな設定のベストプラクティスを探してみたのですが見つからず質問させていただきます。

環境

AWS EC2

該当のソースコード

  /etc/php.d/wordpreessupfilesize.ini :
      mode: "000400"
      owner: ec2-user
      group: ec2-user
      content: |
        memory_limit = 50M
        post_max_size = 40M
        upload_max_filesize = 30M

上記のような設定ファイルで
パーミッション400
ec2-user:ec2-userのphp.iniが生成され
設定内容も反映されています。

質問したいこと

皆様の観測範囲、ご経験の範囲ではどのような設定（パーミッション、ユーザー、グループ、配置ディレクトリ）が多いかを伺いたいです。

一般的にphp.iniを自分で拡張する際にファイルのパーミッションで400は妥当でしょうか。
ec2-userというのはアプリケーションを動かすユーザーですがユーザー、グループ設定は妥当でしょうか。
配置ディレクトリは/etc/php.d/ですがこれは妥当でしょうか。

現在の設定よりセキュアにすることが可能でしたらこれらをどのように設定すべきかを
ご教授いただければ幸いです。

Comments

[m.ts10806]

なんのためにそこまでしたいのか、目的が良く分かりません。

[退会済みユーザー]

AWS EC2のインスタンスで動かすOSは何を選択しましたか？ Amazon Linux 2とかCentOS 7とかUbuntu 20.04とかそりゃ色々あるので。

[euicnvhf202105]

m.ts10806さんコメントありがとうございます。明確な目的がなく恐れ入ります。自分でも今までなんとなく気にしたこともなかったのですが、気になって色々書籍などを漁ってみたものの明確に書かれているものを見つけられず質問に至った次第です。

[euicnvhf202105]

m6uさんコメントありがとうございます。Amazon Linux 2を選択しました。情報の不足失礼いたしました。

[m.ts10806]

おそらくその「なぜ気になり始めたのか」が本文から伝わらないことに問題があると思います。
可能な限りで結構ですので前提や背景を追記いただけますか？

[euicnvhf202105]

m.ts10806さんコメントありがとうございます。情報の不足があり失礼いたしました。経緯を追記してみました。

[退会済みユーザー]

回答を得るには「セキュアな状態」を定義する必要があります。

例えば、「php.ini が ec2-user から読めてはダメ」とか「php.ini が ec2-user から変更できてはダメ」とか「php.ini が hoge-user から読めてはダメ」とか。
実際回答にするためには、上記に関連するユーザがどういった権限を持っているかも記述する必要があります。「php が実行可能なのか？」とか「web サーバと同一グループに所属しているのか？」とかとか。

ただ、「ec2-user」が「Amazon Linux」のデフォルトアカウントを指しているのであれば、「php.ini」のパーミッションは何でも良いような気がします。root への昇格可能アカウントなので、何にしてもあまり意味は無いかと。

[euicnvhf202105]

te2jiさんコメントありがとうございます。まずは細かくリスクの洗い出しが必要ですね。

＞「ec2-user」が「Amazon Linux」のデフォルトアカウントを

「ec2-user」は「Amazon Linux」のデフォルトアカウントのことです。
たしかにsudo su -でrootになれば何でもできてしまいそうですからパーミッションの設定はあまり関係なさそうですね。

[euicnvhf202105]

皆様、漠然とした質問にご指摘ありがとうございました。

設定ファイルについてはドキュメントルート以下に置くのは一つリスクが増す。
パーミッションの設定でセキュリティレベルを一つ上げるには
linuxユーザーの運用を考えチーム内の権限を設定する段階で検討するのがよさそう。

いただいたアドバイスで以上の理解が得られ
内部で対策するというよりはその前段階のセキュリティグループを
しっかり設定（https,http,sshはIP指定）し
外部から侵入されないようにすることが大事だと
現時点では納得しましたので質問を閉めさせていただきます。

Answer 1

Linuxのユーザーとグループって何だろう？：“応用力”をつけるためのLinux再入門（10）（1/2 ページ） - ＠IT
全体像がすぐにわかる！Linuxグループの設定方法まとめ ← 事例がわかりやすい

っていう話は理解しているものとして。

php.iniを他の環境に抜き出して、元の場所に戻すときに、
オーナーユーザー：グループが以前にものと変わってしまうことがあるので注意が必要です。

よりセキュアにすること

が、一体どのレベルの話をしているのかわかりかねますが、
少なくともwebサーバーのドキュメントルート以下に置くものではないため、
サーバーに直接ログインするユーザーしか目にすることはできません。

初期設定に使うユーザー ec2-user でログインするときに
公開鍵を使ったログインをするため、
ユーザー名、パスワード、公開鍵ファイルが揃っていないとログインできません。

別ユーザーを作成して、SSHログインを強制している限りは、
部外者が目にすることはないと考えられます。

ec2-user を他人と使い回しなどしないよう、
設定変更できるユーザーは自分ひとりに絞れば、
他人が使うときは都度ユーザー：グループを作り、
sudoできるユーザーも絞って、
FTP(SFTP, SCP)するときもrootから全部見せるようなことをせず、
webコンテンツの変更用であればそれを目的にしたグループを作ってユーザーを属させて管理する、
っていうのを丁寧にやれば、十分セキュアなのではないでしょうか。

php.iniを読めても書き換えできないでしょうから。

Comments

[euicnvhf202105]

参考URLありがとうございます。
このあたりの理解が少々甘いことに気付かされました。

よくよく考えると
ec2-user:ec2-user
とするよりは
root:rootとするほうが触れる人数を絞ることができるのでしょうか？

root:rootよりは更にオリジナルのユーザーグループを作成して
動かしたほうが触れる人数を絞ることができるのでしょうか？

自分でもテストしてみます。

＞php.iniを他の環境に抜き出して、元の場所に戻すときに、
オーナーユーザー：グループが以前にものと変わってしまうことがあるので注意が必要です。

貴重な情報ありがとうございます。
デプロイ方法やその挙動も決めておかないと思わぬ事故に繋がりそうですね。

＞よりセキュアにすること

曖昧な表現失礼いたしました。
これは現在の
パーミッション　400
ec2-user:ec2-user
/etc/php.d/
という状態が一般的に本番環境でも使われる設定なのかどうか
もし何か突っ込みどころがあればご指摘いただきたいという意味でした。

＞FTP(SFTP, SCP)するときもrootから全部見せるようなことをせず、
webコンテンツの変更用であればそれを目的にしたグループを作ってユーザーを属させて管理する、
っていうのを丁寧にやれば、十分セキュアなのではないでしょうか。

こちらも大変参考になりました。
将来的にチーム運用に発展した際にはこういったところも詰めなければなりませんね。