スイーツ（笑）と呼ばないで!!

最近、サクッと短いブログを書いています。

弊社では基本的にroot権限は弊社で管理していますし、
相当な事情がない限り、クライアントにサーバーへのアクセスを開放することはございません。

しかしながら、いろいろ大人の事情ですとか、
テンプレートと画像、cssなどについては自分たちで変更したい、
とかおっしゃるクライアントのために、開放せざるを得ないことは結構あったりします。

例えばクライアントがアクセスしたいディレクトリ構成が

/var/www/project_name/private/client/template
/var/www/project_name/public/client/css
/var/www/project_name/public/client/image

このような場合どうするでしょうか?

【レベル0】

「私たちがソースアップしているlinuxユーザーをクライアントに教えて使い回せば良いじゃん」

→ダメです。そんなことしたら、事故が起きた時の責任の所在も原因の追跡も困難になりますし、そもそも事故が起きる可能性がたかまります。

【レベル1】

「じゃ、プロジェクトのルートである/var/www/project_name/をホームディレクトリとする別ユーザーを作れば良いじゃん。その上で/var/www/project_name/private/client/と/var/www/project_name/public/client/にのみアクセスできるようにすれば良いよね。」

→ダメです。そもそもそれでは内部構造も丸見えですし、プロジェクトのルートにlinuxのユーザー管理に使うゴミファイル(SFTPを想定)がたくさん置かれることになります」

【レベル2】

「わかったよ。そこまでセキュリティとかうるさいなら、
/var/www/project_name/private/client/をホームディレクトリとするclient_privateと
/var/www/project_name/public/client/をホームディレクトリとするclinet_publicという二つのユーザーを作れば良いよね」

→それなら必要なアクセス権はなくなるけど、管理が煩雑だよね。それにFTPでなくSFTPでいくなら上記のようなゴミファイルの問題もあるし。

【レベル3】

「じゃ、どうすればいいの?」

→clientというlinuxユーザーを普通に作成します。ホームディレクトリは/home/clientです。で、/home/clientの下に、/var/www/project_name/private/client/へのシンボリックリンクのprivateと/var/www/project_name/public/client/へのシンボリックリンクのpublicをはれば良い。SFTPでそれでアクセスすればセキュリティの問題も特にないし最小限でかつ必要なものについてのアクセス権はある。


ということで個人的にはこのレベル3の方法が良いのではないかと思っています。

たまに、クライアント用に複数のファイルアップ用のユーザーを作っているプロジェクト(特にクライアント内部での権限の区別はない)を見かけます。

まぁ、いろいろと事情があるんだとは思いますが、特に深い理由がなければ、このような管理も良いのではないでしょうか。

[0回]

• 技術系の話題
• COMMENT：0