次の方法で共有


BizTalk Server を展開する際のセキュリティに関する推奨事項

このセクションでは、Microsoft BizTalk Server 環境を保護するための、機能によらない一般的な推奨事項について説明します。

トポロジ レベルの推奨事項

チャネル レベルの暗号化を使用する。 既定で、BizTalk Server 内のさまざまなコンポーネント間のネットワーク データ フローは、クリア テキストになっています。 特定のコンピューターから別のコンピューターにメッセージが移動される際のデータのスニッフィングまたは改ざんが心配な場合、インターネット プロトコル セキュリティ (IPSec) または Secure Sockets Layer (SSL) などのチャネル レベルの暗号化を使用することをお勧めします。 BizTalk Server は既定でチャネル レベルの暗号化を構成しませんが、暗号化キーやパスワードなどの重要なデータについてはクリア テキストで送信しません。 SSO データベースでは、マスター シークレット サーバーによって提供されるマスター シークレット (暗号化キー) を使用した暗号化形式で機密情報を保存して、機密情報を管理します。 既定で、SSO データベースは、暗号化形式で機密情報を受信、保存、および送信します。

SSL の詳細については、「」を参照してください https://go.microsoft.com/fwlink/p/?LinkId=189708

サーバーの物理的なセキュリティを確保する。 サーバー、デバイス、ネットワーク、ケーブル、電源装置、および他のコンポーネントの物理的なセキュリティも考慮する必要があります。 安全な環境にコンピューターを設置し、データベースなどのビジネスで重要な情報を含むコンピューターへのアクセスを制限してください。

使用するコンポーネントだけをインストールする。 インターネット インフォメーション サービス (IIS) を境界ネットワークのコンピューターまたは HTTP アダプターおよび SOAP アダプターを実行するコンピューターにインストールする場合、ファイル転送プロトコル (FTP)、WebDAV、および簡易メール転送プロトコル (SMTP) など、IIS のサブコンポーネントをインストールする必要はありません。 同じように、使用している環境に必要な BizTalk Server 機能のインストールおよび構成だけを行います。 たとえば、BizTalk メッセージ キュー アダプターを使用している場合は、BizTalk メッセージ キュー アダプターのみ構成してください。 これにより、使用している環境の攻撃可能な部分を減らすことができます。

インターネット エクスプローラーを使用している場合は、インターネット エクスプローラーの強化されたセキュリティを有効にすることをお勧めします。

サービス パックと更新プログラムをインストールします。 SQL Serverを含む、BizTalk Serverリソースを持つすべてのサーバーに、常に最新の製品サービス パックと Microsoft 更新プログラムをインストールすることをお勧めします。

スクリプトまたはバインド ファイルにパスワードをクリア テキストで保存しない。 BizTalk Server 管理者だけがスクリプトの表示、変更、および実行を行えるように、強力な随意アクセス制御リスト (DACL) を使用している場所にスクリプトを保存する必要があります。 スクリプトおよびバインド ファイルにパスワードが必要な場合は、スクリプトを使用して構成または展開したらすぐにパスワードをマスクしてください。 これらのファイルのパスワードをクリア テキストのままにしないでください。

強力な随意アクセス制御リスト (DACL) を使用する。 リソースへのアクセスは、そのリソースを使用するユーザーおよびアカウントだけに制限されていること、およびそのユーザーおよびアカウントに付与されているのはタスクを行う必要最低限の権限であることを確認してください。 BizTalk Server 管理者の DACL を使用している場所に構成スクリプトを配置してください。スクリプトにクリア テキストのパスワードは設定しないでください。 該当するサービス アカウントと BizTalk 管理者だけにアクセス権を付与するため、BizTalk Server で使用するすべてのサービス アカウントの一時ディレクトリに DACL が格納されていることを確認してください。

カスタム アダプターがある場合は、強力な DACL を持つ場所にアダプター拡張機能コンポーネントを格納することをお勧めします。そのため、BizTalk Server管理者のみがこれらのコンポーネントに対する書き込みアクセス許可を持ちます。

境界ネットワークに BizTalk Server を配置しない。 企業の規模に関係なく、境界ネットワークに BizTalk Server を配置すると、BizTalk Server が、インターネットによる直接的な攻撃および境界ネットワークの他のサーバーからの攻撃を受ける危険があります。 BizTalk Server はデータ ドメインの Microsoft SQL Server データベースと通信するため、悪意のあるユーザーが BizTalk Server に侵入して、重要なビジネス プロセスおよび構成データを改ざんする危険性があります。

BizTalk Server のグループおよびアカウント

最小限のアクセス権限とユーザー権利のアカウントを使用する。 BizTalk Server システムのすべてのアカウントには、タスクを行うために必要な最小限のユーザー権利を付与します。 たとえば、処理サーバーで使用するサービス アカウントに、BizTalk Server、SQL Server、または Windows Server の管理者のユーザー権利は必要ありません。 アカウントがBizTalk Serverでタスクを実行するために必要な最小限のセキュリティ アクセス許可とユーザー権限の詳細については、「最小セキュリティ ユーザー権限」を参照してください。 BizTalk Serverが使用するグループとアカウントの詳細については、「BizTalk Serverの Windows グループとユーザー アカウント」を参照してください。

機能ごとに異なるアカウントを使用する。 BizTalk Server 環境のセキュリティを確保するには、使用している環境で実行されているホスト インスタンスごとに、異なるサービス アカウントを作成することをお勧めします。 これにより、パスワードの更新中の可用性も向上します。 1 つのサービス アカウントが、BizTalk Server用の複数の Windows グループのメンバーではないことをお勧めします。

さらに、BizTalk ホストごとに異なる Windows グループを使用し、あるグループのメンバーであるサービス アカウントを別のホストの Windows グループのメンバーにしないことをお勧めします。 これにより、各 BizTalk ホストのセキュリティの分離が強化されます。

追跡ホスト専用の Windows グループを作成し、ホスト インスタンスの追跡にこのグループのサービス アカウントを使用することをお勧めします。 他のサービスにこのサービス アカウントを使用しないでください。また、ホスト インスタンスの追跡に BizTalk 管理者のアカウントを使用しないでください。

機能ごとに異なるホストを使用する。 追跡のみを目的にしたホストを作成することをお勧めします。 "ホストの追跡" を構成しているホストは、メッセージ ボックス データベース内の追跡テーブルへの読み取り/書き込みアクセスだけでなく、追跡データベースのテーブルへのアクセスも許可されています。 そのため、ホストの追跡を行うホストで実行されているオブジェクトにも、これらのテーブルへの読み取り/書き込みアクセスが許可されています。 パイプラインやオーケストレーションなどのユーザー項目の重要な追跡データへのアクセスをブロックするため、メッセージの処理、送信、および受信を行わない追跡専用のホストを作成することをお勧めします。

また、メッセージの処理、受信、および送信には異なるホストを使用することをお勧めします。 これにより、企業の個人の証明書にアクセスする場合に使用するサービス アカウントを分離できます。 これらのアカウントで実行するコードが少ないほど、脆弱性を利用してアカウントに侵入される危険性が軽減されます。また、個人の証明書に侵入される危険性も軽減されます。

パスワードを定期的に変更する。 サービス アカウントのパスワードは定期的に変更する必要があります。 ホスト インスタンスに複数のサービス アカウントを使用している場合、各サービス アカウントのパスワードを変更する必要があります。

注意事項

ホスト インスタンスのサービス アカウントに使用するパスワードは、BizTalk 管理コンソールで変更する必要があります。 ホスト インスタンスのサービス アカウントに使用するパスワードをコンピューターの管理コンソールで変更すると、構成の問題が発生する可能性があります。

BizTalk 管理者グループのメンバーシップを制限する。 BizTalk Server 管理者は、BizTalk Server 環境全体で使用するユーザー権利 (ほとんどのデータへのアクセスや暗号化などを含む) を持ちます。 このため、BizTalk 管理者が誤って正しくない構成を行うと、重大なセキュリティ ホールが生じることになります。 BizTalk 管理者の不注意は、カスタム データの機密性、整合性、可用性を危険にさらすなど、システムに取り返しのつかない損害を与える可能性があります。

開発者が直接オーケストレーションを実稼働環境のコンピューターに展開する場合、ドメイン管理者は、開発者に BizTalk 管理者のユーザー権利を付与する必要があります。 このことは、前述の理由により推奨されていません。

COM+ 管理者グループのメンバーシップを制限する。 構造上のさまざまな理由により、COM+ 管理者は、複数の BizTalk Server コンポーネントの管理者としてのユーザー権利を持ちます。 実際、コンピューター上の COM+ 管理者は BizTalk 管理者の役割も果たすと考える必要があります。また、BizTalk 実稼働サーバーのこのグループへのメンバーシップを制限する必要があります。

ユーザーのアクセスは、必ずアクセスするサービスを実行しているコンピューターだけに制限する。 すべてのアカウントに、すべてのコンピューターへのアクセス権が必要なわけではありません。 BizTalk ホスト インスタンスは、重要な情報をメモリに格納します。 この情報には、パスワードや企業情報などの重要なデータが含まれる可能性があります。 非常に厳密なローカル ユーザー ポリシーをこれらのコンピューターに設定する必要があります。 たとえば、これらのコンピューターのローカル ログオン権限は、展開を保持するためにそれを必要とするユーザーだけに付与します。 これにより、スワップ ファイルおよびクラッシュ ダンプへのアクセスによる脅威を緩和します。

Power Users グループの権限を制限または削除する。 Power Users グループの既定の権限を使用すると、このグループのユーザー権利を持つメンバーは、グローバル アセンブリ キャッシュ (GAC) に登録されている BizTalk アセンブリなど、コンピューター全体の設定を変更できます。 各コンピューターには、アプリケーション間で共有されるアセンブリを格納する GAC があります。 Power Users グループのアセンブリを変更する権限を削除するか、実稼働の BizTalk Server の Power Users グループを削除することをお勧めします。

参照

グループとサービス アカウントのAccess ControlAccess Control管理ロールの最小セキュリティ ユーザー権利計画のセキュリティ