質問: WordpressやPythonのDjango、RubyonRailsのECパッケージSpreeなど多くのアプリケーションでサービスサイトと管理機能を同じドメイン配下にしているケースを拝見します。 例)www.someservice.com・・・サービスサイト、www.someservice.com/admin・・・管理機能 当然同じサーバ上に機能を搭載している関係上セキュリティ的には不安があるのですが、この作りというのは世界共通なのでしょうか? 個人的には管理機能はサブドメインつけて別サーバに載せてアクセスするIPを限定 例)www.someservice.com / admin.someservice.com とかするのがドメイン設計上好ましいと思っているのですが、皆さんはどのようにお考えでしょうか?
回答: > > 個人的には管理機能はサブドメインつけて別サーバに載せてアクセスするIPを限定 > > > 例)www.someservice.com / admin.someservice.com > > > とかするのがドメイン設計上好ましいと思っているのですが、皆さんはどのようにお考えでしょうか? > > > ・別のサブドメインをつける ・別サーバに乗せる ・アクセス元のIPアドレスを限定する これはそれぞれ独立した話で、トータルではドメイン設計のはなしではないですね。 ・同じサーバでドメインが別 ・同じサーバで同じドメインだけど管理領域は接続できるIPアドレスを制限 ・ドメイン同じだけど実体は別サーバ という構成もあり得ます。 質問を読むと、ドメインではなく「サービスと管理が同じサーバに乗っている」ことが問題であると考えられているようです。上に書いたように、同一サーバで管理領域だけIPアドレスベースでアクセスを制限する、ということも考えられますがこれではNGという話になるので、サービス側は公開、管理側はFWの内側など非公開の領域に配置する構成を暗に想定されているのではなでしょうか。 確かに管理側を攻撃されるリスクは減りますが、設備を用意するコスト、データベースをどっちに置いてその通信をどう制御するのかとか、FWの運用はどうするんだとか考えないといけないこと、構成が複雑になったことで生じるリスクはそれ以上のものになることは容易に想像できます。 結局、ほとんどのユースケースではそんなことを強制する意味がない訳です。 となればWordPressやSpreeみたいなアプリケーション観点では「ミニマムな構成」が前提になるのでサーバ1台で動く構成になります。運用者がどうしても「サービスと管理を分離したい」というのであれば別にできないことはないと思います。 Django(やWAF全般)はそれ自体が「サービスと管理が一体」であることを強制してるわけではないでしょう。それ使ってアプリケーションを作る人がどう作るか次第です。 逆に、上に書いたようなサーバとネットワークを分離するコストが最初から見込まれている規模のアプリケーションであれば、サービスと管理が分離されていることはいろいろメリットになります。