WordpressやPythonのDjango、RubyonRailsのECパッケージSpreeなど多くのアプリケーションでサービスサイトと管理機能を同じドメイン配下にしているケースを拝見します。

例）www.someservice.com・・・サービスサイト、www.someservice.com/admin・・・管理機能

当然同じサーバ上に機能を搭載している関係上セキュリティ的には不安があるのですが、この作りというのは世界共通なのでしょうか？  
個人的には管理機能はサブドメインつけて別サーバに載せてアクセスするIPを限定

例）www.someservice.com / admin.someservice.com

とかするのがドメイン設計上好ましいと思っているのですが、皆さんはどのようにお考えでしょうか？
CC BY-SA 4.0
2021-05-02T10:02:43.720
75631
2021-05-04T08:35:35.957
4784
question
http
Webアプリケーションのサービス側と管理機能のあり方について
正解のない質問はアンケート扱いで SO 的には非推奨ですが  
ドメイン名を複数維持管理するには（提示例では `wwww.example.com` と `admin.example.com` の両者)
１つだけ取得するより余計にコストがかかります。セキュリティもコストを無視しては語れません。その辺、立場の違いで話は違ってくるでしょう

  * 既存のフレームワーク類を一切使用せずに独自プログラムで独自ドメインを維持するサイト管理者なら  
そういうところはたいてい自鯖を立てているでしょう。なら維持管理はコンソールから行えばよいのでサブドメインにコストは払いたくないです。

  * Web フレームワークの作者なら  
フレームワークのユーザーつまりはサイト管理者に対してサブドメインを維持するコストを負担させるか否かってことになりそう。サイト管理者に追加の維持コストを強いる分、フレームワークのユーザーは増えないかもしれません（フレームワーク間の競争面で不利）。仮にこのフレームワークの出来が良いなどの理由によりユーザーが増えたとして、サンプルないしはドキュメントに「管理用に
`admin.example.com`
を作れ」と記載したらそのまま真似るユーザーは一定数居ますし、当然ながら攻撃者もその辺の状況を真似るでしょう。その意味でセキュリティが向上するとは思えません。

  * 普通に既存の web フレームワークを使うサイト作者なら  
わざわざサブドメインを作り `admin.example.com` にログインできる IP アドレスを制限するなら、そりゃ
`www.example.com`
で行ってもセキュリティ的に大差はないはずなのでサブドメインを立てる根拠にならんです（オイラがスポンサーとして金出す側ならそんなことは却下）

ってことでオイラの意見としては「セキュリティが増すか減るかだけ考えるなら、サブドメインを作るほうがセキュリティが増すかもしれないが、同じ程度に終わる可能性のほうが高い」です。根拠は「攻撃者もそんなことは百も承知なので本気で攻撃したいようなクラッカーには通じないだろう」「カジュアルな攻撃者やスクリプトキディ避けにはなるかもしれない」ってとこで。まとめると「金をかけるべき場所が間違っていないか要検討」ってとこでしょう。
CC BY-SA 4.0
2021-05-02T11:19:38.310
75632
2021-05-02T11:19:38.310
8589
75631
answer
> 個人的には管理機能はサブドメインつけて別サーバに載せてアクセスするIPを限定
>
> 例）www.someservice.com / admin.someservice.com
>
> とかするのがドメイン設計上好ましいと思っているのですが、皆さんはどのようにお考えでしょうか？

・別のサブドメインをつける  
・別サーバに乗せる  
・アクセス元のIPアドレスを限定する

これはそれぞれ独立した話で、トータルではドメイン設計のはなしではないですね。

・同じサーバでドメインが別  
・同じサーバで同じドメインだけど管理領域は接続できるIPアドレスを制限  
・ドメイン同じだけど実体は別サーバ

という構成もあり得ます。

質問を読むと、ドメインではなく「サービスと管理が同じサーバに乗っている」ことが問題であると考えられているようです。上に書いたように、同一サーバで管理領域だけIPアドレスベースでアクセスを制限する、ということも考えられますがこれではNGという話になるので、サービス側は公開、管理側はFWの内側など非公開の領域に配置する構成を暗に想定されているのではなでしょうか。

確かに管理側を攻撃されるリスクは減りますが、設備を用意するコスト、データベースをどっちに置いてその通信をどう制御するのかとか、FWの運用はどうするんだとか考えないといけないこと、構成が複雑になったことで生じるリスクはそれ以上のものになることは容易に想像できます。

結局、ほとんどのユースケースではそんなことを強制する意味がない訳です。

となればWordPressやSpreeみたいなアプリケーション観点では「ミニマムな構成」が前提になるのでサーバ１台で動く構成になります。運用者がどうしても「サービスと管理を分離したい」というのであれば別にできないことはないと思います。

Django(やWAF全般)はそれ自体が「サービスと管理が一体」であることを強制してるわけではないでしょう。それ使ってアプリケーションを作る人がどう作るか次第です。

逆に、上に書いたようなサーバとネットワークを分離するコストが最初から見込まれている規模のアプリケーションであれば、サービスと管理が分離されていることはいろいろメリットになります。
CC BY-SA 4.0
2021-05-04T04:27:50.333
75661
2021-05-04T04:27:50.333
5793
75631
answer
サブディレクトリに見えてもリバースプロキシを使って別サーバに振り分けているかもしれないし、反対に別ドメインに見えてもヴァーチャルホストの機能を使って実は同一サーバな場合もあり得ますので、ドメイン名やURLだけで安全性を判断するのは早計かと。

同一サーバ上でもディレクトリごとで適切なアクセス制限をかける運用も考えられますし(管理用のURLには特定のネットワークからしか許可しない等)、例えサーバを分けたとしてもネットワーク的に繋がっているならリスクがゼロになるわけでもないと思います。
CC BY-SA 4.0
2021-05-04T08:35:35.957
75667
2021-05-04T08:35:35.957
3060
75631
answer