私は、net.tcp を介してクライアント アプリの n インスタンス (私のオフィスの別のプログラマーによって開発されている) と通信する WCF サービスに取り組んでいます。
少なくともロールアウトが近づくまでは、この段階でこれを設定する必要はないと感じたため、現時点ではセキュリティなしで net.tcp を使用しています。
WCF アプリケーションの開発中に、標準バインディング (私の場合は net.tcp) をセキュリティなしで使用し、ビジネス ロジックが完成したら、すべてのセキュリティ要件を実装しても害はありますか? セキュリティの実装後に機能しない可能性があることに注意する必要があることはありますか?
全体的な設計では最初からセキュリティを考慮する必要がありますが、コンポーネントを特定のセキュリティ戦略に結合することはお勧めできません。一部のコンポーネントを安全でない方法で使用したり、さまざまなセキュリティオプションを提供する別のプロトコルで使用したりすることをお勧めします。
だから私の答えはイエスとノーです。はい、最初から考える必要がありますが、コンポーネントをセキュリティのニーズに結び付けてはいけません。
とはいえ、net.tcpを使用することがわかっているので、このバインディングではトランスポートセキュリティがデフォルトでオンになっていることに注意する必要があります。
詳細については、Juval Lowyの素晴らしいプログラミングWCFサービスの第10章を参照してください。Lowyは、ServiceModelExライブラリ（本で詳しく説明）で、コンポーネントの作成後にプラグインできる非常に優れたフレームワークを提供します。探しているものと正確に一致しない場合でも、ニーズに合わせてカスタマイズできます。
セキュリティは、最後に追加するのではなく、最初から検討する必要があります。
セキュリティの計画を作成し、最後ではなく、進行中に実装します。
参照: Microsoft .NET: エンタープライズ向けアプリケーションの設計
http://www.amazon.com/Microsoft®-NET-Architecting-Applications-PRO-Developer/dp/073562609X _
最初から焼き込むか、最後に平手打ちするかの 2 つの選択肢があります。一般的なセキュリティでは、アイシングでは実際には機能しないので、そこに入れるにはケーキを台無しにする必要があります。
しかし、あなたの質問は、セキュリティの問題を解決するために何かをする必要があることをすでに知っていると私は見ています。あなたは何をすべきか決めていないだけです。その場合、最終的なソリューションをプラグインできるようにする抽象化を中心に設計する必要があるというテリーに同意します。
私があなただったら、おそらく脅威モデルを作成し、それを使用して、サービスによって提示される入力とリスクを検討します。これは、最終的に何をすべきか、また抽象化がすべてのベースをカバーしているかどうかを判断するのに役立ちます。