ユーザーサイトと管理サイトのドメインは分けるべき？

Question

ユーザーサイトと管理サイトのドメインは分けるべき？

解決済

回答 3

投稿 2016/06/08 17:41 ・編集 2016/06/08 18:03

評価
クリップ 0
VIEW 3,587

skyopen

score 24

ある企業に下記のサイトを提供予定です。
・ユーザー向けWEBサイト（例：www.hoge.com)
・ユーザーWEBサイトの管理サイト（例：www.hoge.com/admin/)

下記のような状況で、ユーザーサイトと管理サイトのドメインは分けるべきでしょうか？

ユーザー向けWEBサイトには企業のお客様が訪問して、商品を買ったりします。

ユーザーWEBサイトの管理サイトは、企業の管理者が利用し、
商品ページの公開・非公開、価格の変更などの制御や
ユーザーのアクセス数の確認などレポーティングに利用します。

URLは例のとおりで、管理者サイト（例：www.hoge.com/admin/）で
ユーザーサイト（例：www.hoge.com)と同じドメインです。

セキュリティーを考慮して、管理者サイトのベーシック認証を付けたりしようと思っています。

上記のような状況ですが、ユーザーサイトと管理サイトをドメイン下に設置することで
セキュリティーなどデメリットやアドバイスがあれば教えていただけないでしょうか？

思い付きですが、
・管理サイト（たとえば、/admin/以下）に企業からしかアクセスできないような
IPアドレス制限をかける。（技術的に可能かどうか教えていただきたいです。）

・ＵＲＬはたとえば、www.hoge.com/admin/と分かりやすいものでなく、
外部に推測されにくいURL （たとえば、www.hoge.com/ireie2343/などにした方がいい

などが適切かどうか、それ以前にドメインが同じなのは言語同断なのかも含め、
アドバイスいただければ幸いです。

私も提供先の企業側も知識があまりないため、お知恵を借りれればありがたいです。
よろしくお願いいたします。

気になる質問をクリップする

クリップした質問は、後からいつでもマイページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

クリップを取り消します
良い質問の評価を上げる

以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します

評価を下げられる数の上限に達しました

評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる

teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します

この機能は開放されていません

評価を下げる条件を満たしてません

評価を下げる理由を選択してください
プログラミングに関係のない質問やってほしいことだけを記載した丸投げの質問問題・課題が含まれていない質問意図的に内容が抹消された質問過去に投稿した質問と同じ内容の質問広告と受け取られるような投稿
詳細な説明はこちら

上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。
質問の評価を下げる機能の利用条件

この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
- メールアドレスの認証
  メールアドレスの認証
- 質問評価に関するヘルプページの閲覧
  質問評価に関するヘルプページの閲覧

回答 3 件

評価が高い順
新着順
古い順

+2

セキュリティー・ポリシーを決定するのはどなたでしょうか？
責任の所在をはっきりさせたほうが良いです。
今のままだと、提言をしたあなた（orあなたの会社）に責任が発生しそうですが、大丈夫ですか？

セキュリティ対応はやろうと思えば、いくらでもやることがあります。
基準となるポリシーを定め、コストと期間からどこまでやるかを決定する必要があります。

今の知識レベルで、納品可能なモノを作成できるとは思えませんので、できれば外部のコンサルタントに責任を押し付けることを検討されてはいかがでしょうか。

投稿 2016/06/08 18:04

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

2016/06/08 19:22

質問者がteratailらしく技術的な回答を求めているのに対し、この回答は技術的な回答ではない。さらにこの回答には質問者に対してとても失礼な表現が含まれている。

質問者がteratailらしく技術的な回答を求めているのに対し、この回答は技術的な回答ではない。さらにこの回答には質問者に対してとても失礼な表現が含まれている。

キャンセル
2016/06/08 19:51

技術的な回答をしなかったのは、skyopen さんが、提供先の企業へ回答してしまうことで、責任をかぶってしまうことを回避するためです。

プロジェクトを進行する上で、責任分界点を明確にしていない場合、請け負ったと思っている範囲外の責任を押し付けられることはよくあります。
質問内容を読む限り、セキュリティに関しての知識が十分でないにもかかわらず、提供先の企業から頼られ、責任を押し付けられそうになっている図が浮かびます。
この場合、必要なのは、適切なポリシーが決定できる決定者であり、それを skyopen さんが請け負うのであれば、外部のコンサルタントを雇い、責任を押し付けておくことで、skyopen さんサイドがちゃんと責任が取れる体制を取ることです。
＊一般的なゼネコン型ITプロジェクトのリスク回避のやり方です。

適当なアドバイスをするのは、非常に誠実ではないので、わざわざこのような回答をしています。特に失礼だとも思いませんが、いかがでしょうか？

技術的な回答をしなかったのは、skyopen さんが、提供先の企業へ回答してしまうことで、責任をかぶってしまうことを回避するためです。プロジェクトを進行する上で、責任分界点を明確にしていない場合、請け負ったと思っている範囲外の責任を押し付けられることはよくあります。質問内容を読む限り、セキュリティに関しての知識が十分でないにもかかわらず、提供先の企業から頼られ、責任を押し付けられそうになっている図が浮かびます。この場合、必要なのは、適切なポリシーが決定できる決定者であり、それを skyopen さんが請け負うのであれば、外部のコンサルタントを雇い、責任を押し付けておくことで、skyopen さんサイドがちゃんと責任が取れる体制を取ることです。＊一般的なゼネコン型ITプロジェクトのリスク回避のやり方です。適当なアドバイスをするのは、非常に誠実ではないので、わざわざこのような回答をしています。特に失礼だとも思いませんが、いかがでしょうか？

キャンセル
2016/06/09 02:47

te2ji様、回答ありがとうございます。

恐らく豊富なプロジェクト現場のご経験を反映して、
そもそものアプローチについてご指摘いただいたと感謝しております。

十分でない知識がない私が関与する場合、ご回答を参考にすると下記の流れをイメージしましたが、もし、お時間があれば、間違っていないか、またはアドバイスがあればご指摘いただければ大変助かります。

1.企業がセキュリティーポリシー（セキュリティー対策すべき項目とその優先順位）を持っていなければ、企業に了承を得て、外部コンサルタントにセキュリティポリシー案を出してもらうことにする。

2.企業には、そのセキュリティーポリシー案を採用してもらい、同時にセキュリティーポリシーの責任者はその企業であることを確認する。

3.策定されたセキュリティーポリシーに対して、私がサイトの見積もりを出す。
（たとえば、フルスペックの見積もりと、優先順位の高い項目だけに対応した見積もりなど松竹梅で見積もりを出す）

4.企業がコストを勘案し、見積もりを選択する。

5.選んだ見積もりに応じたセキュリティーのサイトを構築する

↓
結果
もし、セキュリティー上、問題が発生した場合、その責任は企業となるため
私に問題が及ばない。

te2ji様、回答ありがとうございます。恐らく豊富なプロジェクト現場のご経験を反映して、そもそものアプローチについてご指摘いただいたと感謝しております。十分でない知識がない私が関与する場合、ご回答を参考にすると下記の流れをイメージしましたが、もし、お時間があれば、間違っていないか、またはアドバイスがあればご指摘いただければ大変助かります。 1.企業がセキュリティーポリシー（セキュリティー対策すべき項目とその優先順位）を持っていなければ、企業に了承を得て、外部コンサルタントにセキュリティポリシー案を出してもらうことにする。 2.企業には、そのセキュリティーポリシー案を採用してもらい、同時にセキュリティーポリシーの責任者はその企業であることを確認する。 3.策定されたセキュリティーポリシーに対して、私がサイトの見積もりを出す。（たとえば、フルスペックの見積もりと、優先順位の高い項目だけに対応した見積もりなど松竹梅で見積もりを出す） 4.企業がコストを勘案し、見積もりを選択する。 5.選んだ見積もりに応じたセキュリティーのサイトを構築する ↓ 結果もし、セキュリティー上、問題が発生した場合、その責任は企業となるため私に問題が及ばない。

キャンセル
2016/06/09 03:55

現在、企業側の予算/スケジュールがどうなっているのかわかりませんが、予算/スケジュールが確保していただけるのであれば、ぜひセキュリティポリシーの策定は切り出したいところです。
＊本プロジェクトとの関係を無くしたい。

ただ、ポリシーが出てきた（または既存のものがあった）としても、実装方法に関しては skyopen さん側で検討する必要が出るため、状況はあまり変わりません。3の時点で、今回と同じようにどこまでやるのか課題が残ります。

進め方として、私なら以下のいずれかの方法を取ると思います。
1，可能であれば、実装方法まで、企業側に仕様決定してもらい、エビデンスを残す。最低でも、ポリシーに対しての実装方法を記述したドキュメントを用意し、企業側の承認を取る。
2,まるっと請け負う契約とし、契約上の上限を限定的とした上で、同じ条件でセキュリティ対策に十分な実績のあるベンダーと協業する。

今回、セキュリティ対策に十分な実績がない skyopen さんがセキュリティ対策を実施しなければならないので、２の方法のほうがリスクが低く、ノウハウの吸収も可能かと思います。

正直、今回の質問は対策の枝葉です。どちらかと言うと、思い付きで書かれた
・管理サイト（たとえば、/admin/以下）に企業からしかアクセスできないような
IPアドレス制限をかける。
と言った事のほうが重要なのですが、そのような優先順位を判断することに関しても実績が足りないように思います。この判断を実績の十分にあるベンダーにヘッジすることでプロジェクトを安全に進めてはいかがでしょうか？

あと、方針を決めるまで、この件に関して企業側にコメントするのは待ったほうが良いです。前述したとおり、この件は枝葉です。先に枝葉の仕様が決定し、本当に対策しなければならないことに対して変更ができなくなる可能性が発生します。

現在、企業側の予算/スケジュールがどうなっているのかわかりませんが、予算/スケジュールが確保していただけるのであれば、ぜひセキュリティポリシーの策定は切り出したいところです。＊本プロジェクトとの関係を無くしたい。ただ、ポリシーが出てきた（または既存のものがあった）としても、実装方法に関しては skyopen さん側で検討する必要が出るため、状況はあまり変わりません。3の時点で、今回と同じようにどこまでやるのか課題が残ります。進め方として、私なら以下のいずれかの方法を取ると思います。 1，可能であれば、実装方法まで、企業側に仕様決定してもらい、エビデンスを残す。最低でも、ポリシーに対しての実装方法を記述したドキュメントを用意し、企業側の承認を取る。 2,まるっと請け負う契約とし、契約上の上限を限定的とした上で、同じ条件でセキュリティ対策に十分な実績のあるベンダーと協業する。今回、セキュリティ対策に十分な実績がない skyopen さんがセキュリティ対策を実施しなければならないので、２の方法のほうがリスクが低く、ノウハウの吸収も可能かと思います。正直、今回の質問は対策の枝葉です。どちらかと言うと、思い付きで書かれた・管理サイト（たとえば、/admin/以下）に企業からしかアクセスできないような IPアドレス制限をかける。と言った事のほうが重要なのですが、そのような優先順位を判断することに関しても実績が足りないように思います。この判断を実績の十分にあるベンダーにヘッジすることでプロジェクトを安全に進めてはいかがでしょうか？あと、方針を決めるまで、この件に関して企業側にコメントするのは待ったほうが良いです。前述したとおり、この件は枝葉です。先に枝葉の仕様が決定し、本当に対策しなければならないことに対して変更ができなくなる可能性が発生します。

キャンセル
2016/06/09 08:53

ありがとうございます。te2ji様の豊富なプロジェクト経験から生まれたリスクマネージメントのアドバイスに感謝しております。
具体的なアクションまで、見える形で教えていただき、とても分かりやすかったです。
本質は今回のご回答かと思いますが、技術的な質問をした背景がございますので、ベストアンサーとさせていただけず、大変恐縮ですが、大変役立つ知見であり、重ねて感謝いたします。どうもありがとうございます。

ありがとうございます。te2ji様の豊富なプロジェクト経験から生まれたリスクマネージメントのアドバイスに感謝しております。具体的なアクションまで、見える形で教えていただき、とても分かりやすかったです。本質は今回のご回答かと思いますが、技術的な質問をした背景がございますので、ベストアンサーとさせていただけず、大変恐縮ですが、大変役立つ知見であり、重ねて感謝いたします。どうもありがとうございます。

キャンセル
2016/06/09 08:56

oskbt様、　はじめのte2ji様の回答に対して、コメントいただき、ありがとうございます。私が本来、te2ji様の回答の意図や掘り下げた質問をすべきでしたが、oskbt様のコメントによってte2ji様がその意図などを結果として詳しくコメントいただきました。
ありがとうございます。
私も技術的な質問をしたつもりでしたが、それ以前に重要な観点をte2ji様より意見いただけたことは大変役に立ちました。

oskbt様、　はじめのte2ji様の回答に対して、コメントいただき、ありがとうございます。私が本来、te2ji様の回答の意図や掘り下げた質問をすべきでしたが、oskbt様のコメントによってte2ji様がその意図などを結果として詳しくコメントいただきました。ありがとうございます。私も技術的な質問をしたつもりでしたが、それ以前に重要な観点をte2ji様より意見いただけたことは大変役に立ちました。

キャンセル
2016/06/09 12:14

ここからの回答は蛇足であり、失礼なコメントを含みます。
不快にする可能性も高いので、読み飛ばしていただいて結構です。
---
今回の件、営業やPMを経験したものであれば、最初の回答を見れば、すぐにリスクに気が付き、プロジェクトを修正する方向に動きます。なぜなら、基準のないプロジェクトをすすめることで、余計な工数がかかり、顧客、自社の双方に損害を与えることが明確だからです。
非常に初歩的なことなので、私もそれほど経験が豊富なわけではありませんが、まずリスクを感じました。多分、経験２年目の子でも先輩から言われれば気がつくレベルです。

ただ、ここにいつまでも気がつけない方もいます。本筋を理解せず、刹那的にプロジェクトを進めてしまうため、プロジェクトを炎上させてしまいますし、隠れた火種を埋め込む事にもなります。もちろん本人に自覚はなく、なぜ炎上や火種となったのか理解しません。

以下は、私がプロジェクトの管理者であった場合の対応です。
まず、 skyopen さんは監視対象者になります。
以下の点で問題を起こす予兆が見受けられるからです。
・最初の回答で、リスクに対しての認識が生まれていない。（oskbtさんへのコメントを読むまで理解していない）
・【3.策定されたセキュリティーポリシーに対して、私がサイトの見積もりを出す。】のコメントから、できること、できないことが把握できていない。
・枝葉の部分と本筋の切り分けができていない。

放置すると、「ユーザーサイトと管理サイトのドメインは分けるべき？」という問いに回答し、今後のプロジェクトの自由度を制限する発言をする可能性が高いので、一度同席し
まずは、基準となるポリシーを提示させるか、こちらで請け負って提示するので、費用を捻出するかの判断を企業側と詰めます。skyopen さんにこの交渉は多分出来ないと判断しています。

次に、基準となるポリシーは出てこないので、こちらで請け負う体制を整えます。次とは書きましたが、費用面の話もあるので、打ち合わせ同席より先に体制確保に動きます。
協業できるベンダーを探すのがポイントですが、セキュリティに関してはほぼ丸投げ、かつ契約条件もかなりハードルは高いと思うため、自分で動くと思います。

日々の進捗確認として、課題管理表とガントで skyopen さんが枝葉と本筋の取り違いをしていないかの確認を欠かさないようにします。

交渉をしてもらわないと、プロジェクトに影響が出る立場なので、抜本的な対策として、PM研修に早期に参加してもらい、リスク/コストの管理方法を学んでもらうと思います。

多分ですが、体系的なプロジェクト管理を学んでいないことが原因だと思います。
意識改革が必要なので、セミナー等でさくっと考え方を切り替え、その後、書籍や実務で事例を積んでいただければと。

頑張ってください。

ここからの回答は蛇足であり、失礼なコメントを含みます。不快にする可能性も高いので、読み飛ばしていただいて結構です。 --- 今回の件、営業やPMを経験したものであれば、最初の回答を見れば、すぐにリスクに気が付き、プロジェクトを修正する方向に動きます。なぜなら、基準のないプロジェクトをすすめることで、余計な工数がかかり、顧客、自社の双方に損害を与えることが明確だからです。非常に初歩的なことなので、私もそれほど経験が豊富なわけではありませんが、まずリスクを感じました。多分、経験２年目の子でも先輩から言われれば気がつくレベルです。ただ、ここにいつまでも気がつけない方もいます。本筋を理解せず、刹那的にプロジェクトを進めてしまうため、プロジェクトを炎上させてしまいますし、隠れた火種を埋め込む事にもなります。もちろん本人に自覚はなく、なぜ炎上や火種となったのか理解しません。以下は、私がプロジェクトの管理者であった場合の対応です。まず、 skyopen さんは監視対象者になります。以下の点で問題を起こす予兆が見受けられるからです。・最初の回答で、リスクに対しての認識が生まれていない。（oskbtさんへのコメントを読むまで理解していない）・【3.策定されたセキュリティーポリシーに対して、私がサイトの見積もりを出す。】のコメントから、できること、できないことが把握できていない。・枝葉の部分と本筋の切り分けができていない。放置すると、「ユーザーサイトと管理サイトのドメインは分けるべき？」という問いに回答し、今後のプロジェクトの自由度を制限する発言をする可能性が高いので、一度同席しまずは、基準となるポリシーを提示させるか、こちらで請け負って提示するので、費用を捻出するかの判断を企業側と詰めます。skyopen さんにこの交渉は多分出来ないと判断しています。次に、基準となるポリシーは出てこないので、こちらで請け負う体制を整えます。次とは書きましたが、費用面の話もあるので、打ち合わせ同席より先に体制確保に動きます。協業できるベンダーを探すのがポイントですが、セキュリティに関してはほぼ丸投げ、かつ契約条件もかなりハードルは高いと思うため、自分で動くと思います。日々の進捗確認として、課題管理表とガントで skyopen さんが枝葉と本筋の取り違いをしていないかの確認を欠かさないようにします。交渉をしてもらわないと、プロジェクトに影響が出る立場なので、抜本的な対策として、PM研修に早期に参加してもらい、リスク/コストの管理方法を学んでもらうと思います。多分ですが、体系的なプロジェクト管理を学んでいないことが原因だと思います。意識改革が必要なので、セミナー等でさくっと考え方を切り替え、その後、書籍や実務で事例を積んでいただければと。頑張ってください。

キャンセル

+1

ドメインを分けるのと同じだと、分けた方が大元のアクセス量が減るのでセキュリティは確実に向上します。

ドメイン毎にドキュメントルートも分ける。
ユーザアクセス用のドキュメントルートには管理者用のログインスクリプトはおかない
管理者側の方には接続元IPを固定する（海外からアクセス出来ないようにするだけでも随分違う）
管理者側のドメインはDNSのGeoRouting(Route53等で提供されている接続元地域ごとに名前解決のIPを変更する機能)で海外からは名前解決出来なくする
別のサーバにして、管理者機能が必要な時だけ起動する

という感じに、同じドメインにするよりは対応出来る幅が増えます。
*.htaccessやapacheのconfで対応可能なところも多くあります。が、設定はドメイン毎に分けられた方がシンプルになりますね。

デメリットとしては、
ドメイン取得及び管理のコスト
SSL証明書のコスト
DNSのレコード管理コスト
等があったりします。

ただ、セキュリティ対策は上限が無いので、
例えばIPAが発表している指針やチェック表
https://www.ipa.go.jp/security/vuln/websecurity.html
等をベースに、どこまで対応するかの方向性を先に決めてそれをクリアするには
どう対応するのが良いかという観点で進める方が良いかと思います。

投稿 2016/06/08 18:07

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

2016/06/09 02:19

整理された回答で大変分かりやすかったです。ありがとうございます！

別ドメインにすることで、アクセス量が減るということに加え、５つほどの追加的なうち手が実行し易くなるというメリットが分かりました。

また、デメリットやセキュリティに関する総合的な指針についても分かりました。

整理された回答で大変分かりやすかったです。ありがとうございます！別ドメインにすることで、アクセス量が減るということに加え、５つほどの追加的なうち手が実行し易くなるというメリットが分かりました。また、デメリットやセキュリティに関する総合的な指針についても分かりました。

キャンセル

同じタグがついた質問を見る

Apache
URL

score 2 · Accepted Answer · 2016-06-09T07:30

同じサーバの同じドメイン上に管理画面を置いた場合のリスクは、第三者が管理画面(少なくともログイン画面に)にアクセスしやすくなってしまうと言うことです。もし、管理画面へ誰でもログインできるような脆弱性があった(どんなに慎重に作成しても脆弱性が存在する可能性を完全に0にはできません)場合は、悪意ある第三者がログインして、情報の盗み出しや改竄等がされてしまう可能性があります。

たぶん、上のことは認識済みかと思います。特にWordPressやEC-CUBEのようなメジャーなWebアプリを用いている場合、デフォルトの管理画面のURLが誰でも知っているものになるため、脆弱性が発見され次第、世界中からログインされる可能性があります。

第1の方法として、それを防ぐために、ドメインを変える、管理画面のURLを/admin/など類推されるもの以外に変える、はある程度有効だと思います。ただ、この方法は数打ちゃ当たる方式で攻撃するような悪意がある第三者には有効ですが、その企業を標的にしている場合は、どこからしか情報が漏れて、管理画面のURLを知られてしまいます。無いよりはマシかも程度の対策です。

第2の方法として、上記に加えて、Apache上でアクセス制限(管理者が所属する企業のIPアドレス以外からはアクセスできないようにするということ、URL単位で設定できますので/adamin/の場合でも可能です)した場合ですが、これは極めて有効です。この制限を打ち破るにはApacheの脆弱性を打ち破るしかありません。逆に言えば、Apacheにアクセス制限に対する脆弱性があった場合は、同じように入り込まれてしまう可能性があります。ただ、もっと留意すべきなのはApacheの設定ミスです。一部だけ制限すると言った場合は全体を制限するよりも設定が複雑になり、設定ミスで制限がかかっていない状態になっていたという場合があります。

第3の方法として、さらに制限をするため、管理サイトは全く別のサーバに持っていくという物です。管理サイトはiptablesと言ったファイアウォールレベルでアクセス制限をかけ、第三者に接続することすら許さないようにします。Apache側も制限をかけておけば、「iptablesによる制限」+「Apacheの設定による制限」+「管理画面のログインによる制限」と3重の壁で守られるため、一つや二つの脆弱性で突破される可能性を限りなく低くすることができます。この方法の問題は、サーバをもう一つ立てることになるため、費用がかかるという点です。

費用対効果を考えて、どこまでするかになると思います。ただ、「第1の方法」は守っているように見えて余りそうではありません。近年は、企業にとって標的型攻撃の方が問題であり、そういった場合は「第1の方法」は防御の体をなしているとは言えません。むしろ、システムの改修や管理が複雑になるなどデメリットが発生する可能性があります。「第1の方法」は簡単にできるのであればする程度で、「第2の方法」を中心に据えた方が良いと思います。そして、予算に余裕があれば、「第3の方法」を検討してみてください。

質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう！

ユーザーサイトと管理サイトのドメインは分けるべき？

関連した質問

同じタグがついた質問を見る

質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう！

ユーザーサイトと管理サイトのドメインは分けるべき？

15分調べてもわからないことは、teratailで質問しよう！

関連した質問

同じタグがついた質問を見る

SNSアカウントでログイン

teratailアカウントでログイン