クライアントにはサイトの公開サイトがあり、Sitecoreを使用してイントラネットサイトを作成するように求めています。Sitecoreイントラネットサイト
公開サイトサイトとイントラネットサイトサイトのコンテンツは異なりますが、両方のサイトが同じコンテンツ作成者ユーザーを共有する可能性があります。
これを達成するためのベストプラクティスは何ですか？新しいインスタンスのsitecoreまたは同じインスタンスを使用します。
どのような考えですか？
お金（ライセンス）を節約し、同じユーザーをコンテンツ編集用に共有することもできます。新しいログインを必要とせず、同じ環境内で両方のサイトを編集できます。
フロントでは、新しいサイトのセキュリティをイントラネットとして簡単に設定できます。 httpsで動作していることを確認してください。両方のサイトでこれを行うのがベストプラクティスです。
私がSitecoreをイントラネットプラットフォームとして使用した最新のプロジェクトは、別個のインスタンスであるためにはっきりとユースケースを持っていました。 （@Gatogordoが指摘しているように）ライセンスを共有するのが理想的でしたが、組織はイントラネットと内部システム間のネットワーク接続に関する非常に厳格なセキュリティポリシーを持っていました。
イントラネットに内部ネットワークシステムとの統合がある場合は、DMZサーバー（パブリックWebサイトをサービスするSitecoreインスタンスなど）がこれらの内部システムに接続できる状況の組織のセキュリティポリシーを検討する必要があります（Sharepointインスタンスなど）。
フロントに心配がなければ、サイト全体でHTTPS +ログイン要件+ Sitecoreセキュリティによる匿名アクセスを無効にするだけで十分です。その中核となるイントラネットは、ログインした人が見ているウェブサイトであることが多く、サイト間で共有したいコンテンツやメディアライブラリのコンテンツが存在することがあります。
最終的な懸念事項は、展開と保守のスケジュールです。イントラネットとインターネットの両方で同じSitecoreインスタンスを運用している場合は、両方のVSソリューションが1つしかない可能性があることを理解する必要があります。インターネット用の修正プログラムを導入することも、イントラネットに影響を与える可能性があります。これは悪いことではありませんが、クライアントが配備の観点からシステムに影響を与えたくない状況があります。負荷分散されたCDノードを使用して、ダウンタイムの問題を軽減し、確実な回帰テストを確実に実施できます。
あなたの答えをありがとうジェイ！シングルインスタンスアプローチを使用する場合、これはクライアントが2枚のCDと1枚のCMを使用している拡張環境に影響します。 –
遅延@AhmadHarbに対する申し立て。スケーリングされているかどうかにかかわらず、セキュリティ、ネットワーク、および展開の懸念事項には影響しません。ただし、2つのCDを使用すると、負荷分散されたフロントエンドの利点を利用して、展開に関連するダウンタイムを軽減できます。 –
答えをいただきありがとうございます、これを達成するためにsitecoreに特別な設定がありますか？またはIISの制限は十分ですか？ –
イントラネットセキュリティでは、Sitecoreがこれを処理できます。エクストラネットドメインユーザー（およびロール）と連携し、コンテンツエディタの場合と同様に、これらのユーザーのセキュリティを有効または無効にすることができます。アクセスを取り消す最も簡単な方法は、匿名ユーザーのイントラネットのルートノードで継承を破ることです。 – Gatogordo