Notification Services のセキュリティに関する注意点
Notification Services では、データベース ロールと、制限されたデータベース ユーザー アカウントを使用して、セキュリティを実装します。このトピックでは、Notification Services のセキュリティ モデルの概要と、Notification Services アプリケーションのセキュリティを向上させるための推奨事項について説明します。
Notification Services のセキュリティ モデル
Notification Services には、ホストされるイベント プロバイダ、ジェネレータ、およびディストリビュータを実行するエンジンがあります。その他に、イベントの送信やサブスクリプションの管理を行うクライアント アプリケーションを使用することもできます。
エンジンやクライアント アプリケーションによって使用されるログイン アカウントは、Windows 認証または SQL Server 認証を使用して SQL Server にアクセスします。これらのアカウントは、データベース ユーザー アカウントを通じてデータベースにアクセスし、Notification Services データベース ロールのメンバシップを通じてインスタンス データベースとアプリケーション データベースに対する必要な権限を取得します。
次の図は、各エンジン コンポーネント、ホストされないイベント プロバイダ、およびサブスクリプション管理インターフェイスに必要な権限を提供するデータベース ロールを示しています。
データベース権限は、データベース ロールに割り当てられます。個々のコンポーネントのデータベース ユーザーは、正しいロールのメンバになることによって必要な権限を取得します。
- イベント プロバイダによって使用されるアカウントは、NSEventProvider データベース ロールのメンバシップを通じて権限を取得します。イベント プロバイダ ホストは、ホストされるイベント プロバイダを実行します。ホストされないイベント プロバイダは、独立したアプリケーションです。
- ジェネレータによって使用されるアカウントは、NSGenerator データベース ロールのメンバシップを通じて権限を取得します。
- ディストリビュータによって使用されるアカウントは、NSDistributor データベース ロールのメンバシップを通じて権限を取得します。
- サブスクリプション管理インターフェイスによって使用されるアカウントは、NSSubscriberAdmin データベース ロールのメンバシップを通じて権限を取得します。
ホストされるイベント プロバイダ、ジェネレータ、およびディストリビュータをエンジンで実行する場合、そのアカウントは NSRunService データベース ロールを通じて必要なすべての権限を取得できます。
Notification Services のセキュリティを実装する方法の詳細については、「Notification Services のセキュリティの設定」を参照してください。
条件アクションのための追加アカウント
Microsoft SQL Server 2005 の Notification Services には、サブスクリプション ルールの新機能があります。これにより、イベント ドリブン ルールと定期的なルールで条件アクションを使用できるようになったため、サブスクライバは、ユーザー定義のクエリ句を使用して、より強力なサブスクリプションを定義することができます。
条件アクションに基づくサブスクリプションではユーザー定義のクエリ句を使用できるため、クエリで利用できるデータを制限する必要があります。このため、条件アクションを実行するためのデータベース ユーザーを定義する必要があります。このデータベース ユーザーに対しては、入力データを含むテーブルとビューのクエリのみを許可します。
条件アクションを含むルールはジェネレータによって実行されます。ただし、条件アクションのクエリは、指定されているデータベース ユーザーによってさらに制限されます。データベース ユーザーは、Notification Services アプリケーションを定義するときに指定します。
条件アクションの詳細については、「条件アクションの定義」を参照してください。
Windows 権限
データベース権限に加えて、一部のコンポーネントには追加の Windows 権限も必要です。
- Notification Services エンジンの実行に使用するアカウントは、Windows グループ SQLServer2005NotificationServicesUser$ComputerName のメンバである必要があります。このアカウントは、サービスの実行に使用される Notification Services バイナリにアクセスできます。エンジンの実行に Windows サービス NS$instanceName を使用している場合、インスタンスを登録するときに、Notification Services によってこのサービス アカウントが SQLServer2005NotificationServicesUser$ComputerName グループに追加されます。
Notification Services バイナリへのアクセスに必要なその他のコンポーネントにも、SQLServer2005NotificationServicesUser$ComputerName グループのメンバシップが必要な場合があります。Notification Services のアセンブリとリソースが、グローバル アセンブリ キャッシュ (GAC) に含まれている場合、このグループのメンバシップなしで使用できます。 - イベント プロバイダでは、フォルダや他のデータベースの権限が必要な場合があります。たとえば、ファイル システム監視イベント プロバイダには、イベント スキーマが記述されている XML スキーマ定義 (XSD) ファイルに対する読み取りアクセス権と、イベント ファイルがドロップされるフォルダに対する読み取りおよび変更のアクセス権が必要です。SQL Server イベント プロバイダには、イベント ソースとして使用されるデータベース テーブルまたはビューに対するアクセス権が必要です。
- ディストリビュータには、SMTP (Simple Mail Transfer Protocol) サーバー、SMS (Short Message Service)、Web サーバー、ファイル システムなどの配信サービスに通知を配信する権限が必要です。XSL 変換 (XSLT) コンテンツ フォーマッタを使用するディストリビュータには、XSLT ファイルに対するアクセス権も必要です。
セキュリティに関する推奨事項
以下のセクションでは、Notification Services エンジン、サブスクリプション管理インターフェイス、カスタム イベント プロバイダ、カスタム配信プロトコル、およびその他のカスタム アプリケーションをセキュリティで保護するための推奨事項について説明します。
Notification Services エンジン
Notification Services のインスタンスを配置するときには、以下に示す Notification Services エンジンのセキュリティに関する推奨事項を考慮してください。
- データベース アクセスに Windows 認証を使用するようにエンジンを構成します。
- 権限の低いドメイン アカウントまたはローカル アカウントでエンジンを実行します。ローカル システム、ローカル サービス、またはネットワーク システムの各アカウントや、Administrators グループのアカウントは使用しないでください。
ただし、配信プロトコルによっては、サービスを実行するアカウントに追加の特権が必要な場合もあります。たとえば、ローカルのインターネット インフォメーション サービス (IIS) の SMTP サービスを使用して通知を送信する場合は、エンジンを実行するアカウントがローカルの Administrators グループのメンバである必要があります (リモート コンピュータの SMTP サービスを通じて通知を送信する場合は、管理者の特権は必要ありません)。 - Notification Services のインスタンスを配置するときには、各エンジンに必要な権限のみが許可されていることを確認します。
シングルサーバー配置の場合は、インスタンスのホストされるイベント プロバイダ、ジェネレータ、およびディストリビュータがすべてそのエンジンで実行されます。エンジンによって使用されるアカウントは、NSRunService データベース ロールのメンバシップを通じて必要なデータベース権限を取得する必要があります。
スケールアウト配置の場合は、各エンジンの権限を制限します。たとえば、エンジンでイベント プロバイダのみを実行する場合は、エンジンのアカウントを NSEventProvider データベース ロールのメンバにし、その他のデータベース権限やサーバー権限を許可しないようにして、アカウントに許可されるデータベース権限を制限します。NSRunService ロールは、エンジンですべてのエンジン コンポーネントを実行する場合以外は使用しないでください。メモ : 各エンジンで何を実行するかは、アプリケーションを定義するときに、ホストされる各イベント プロバイダ、ジェネレータ、およびディストリビュータにシステム名を指定することによって構成します。 - Notification Services エンジン コンポーネントと SQL Server データベース エンジンが別のサーバーにある場合は、データベース エンジンで TCP/IP または名前付きパイプが有効になっていることを確認します。ほとんどのネットワーク プロトコルは、データベース エンジンのセキュリティを向上させるために既定でオフになっています。
- ログイン アカウントに強力なパスワードが設定されていることを確認します。強力なパスワードの詳細については、Microsoft Windows のマニュアルで「強力なパスワードを作成する」を参照してください。
- カスタム イベント プロバイダ、コンテンツ フォーマッタ、プロトコルなど、エンジンによって実行されるすべてのコードが、信頼できるソースのものであることを確認します。Notification Services では、Notification Services のインスタンスの作成や更新に使用するインスタンス構成やアプリケーション定義に含まれているコードは、信頼できるソースのものであると見なされます。アプリケーションを定義するときには、アセンブリの完全修飾名を使用して、誤ったアセンブリが読み込まれないようにします。
- Notification Services では、プロトコル ヘッダー フィールドは検証できません。したがって、プロトコル フィールドのサブスクライバ、サブスクライバ デバイス、またはサブスクリプションの情報をアプリケーションで使用する場合は、ユーザー入力を検証するか、ユーザー定義の値ではなくアプリケーション定義の値を使用します。悪質なユーザー データの例については、「SQL インジェクション」を参照してください。
- 構成ファイルまたはアプリケーション データを含んでいるすべてのフォルダをセキュリティで保護します。ファイルとフォルダのセキュリティ保護の詳細については、「ファイルおよびフォルダのセキュリティ保護」を参照してください。
Notification Services エンジンのホスト
通常、Notification Services エンジンは、Notification Services のインスタンスを登録する際に作成する NS$instanceName Windows サービスになります。ただし、Windows サービスを使用する代わりに独自のアプリケーションでエンジンをホストすることもできます。
エンジンは、データベース エンジンにログインし、Notification Services のインスタンスを実行します。Notification Services エンジンを独自のアプリケーションでホストする場合は、ソース ファイルとバイナリがセキュリティで保護されていることを確認してください。
エンジンをホストする方法の詳細については、「Notification Services エンジンのホスト」を参照してください。
サブスクリプション管理インターフェイス
サブスクリプション管理インターフェイスにより、ユーザーが通知アプリケーションにサブスクライブし、サブスクリプションを作成できるようになります。サブスクリプション管理インターフェイスは、NSSubscriberAdmin データベース ロールのメンバシップを通じて、インスタンス データベースとアプリケーション データベースのデータベース権限を取得します。
サブスクリプション管理インターフェイスを開発するときには、以下に示すセキュリティに関する推奨事項を考慮してください。
- サブスクライバやサブスクリプションのデータを追加、削除、または変更する前に、サブスクライバの ID を確認し、その ID をサブスクライバ ID と照合します。
- NSSubscriberAdmin データベース ロール (またはそれより高い有効な権限) のメンバであるアカウントを持つユーザーやアプリケーションは、サブスクライバとサブスクリプションのデータを変更できます。不要な権限を許可しないようにして、サブスクリプション管理インターフェイスが使用するユーザー名とパスワードを保護します。
- アプリケーションのデータベース接続に使用するユーザー名とパスワードなどの機密情報をプレーン テキストで格納しないでください。機密情報は、Data Protection Application Programming Interface (DPAPI) を使用して暗号化した後、レジストリに格納します。
- アプリケーションでユーザーの識別に社会保障番号などの機密情報を使用する必要がある場合は、機密情報とは関係ないユーザー ID をユーザーに提供し、データベースの参照テーブルを使用して機密情報と照合します。
サブスクリプション管理インターフェイスは、多くの場合、Web アプリケーションです。ASP.NET アプリケーションのセキュリティ オプションの詳細については、「サブスクリプション管理インターフェイスの配置」を参照してください。
カスタム イベント プロバイダ
イベント プロバイダは、Notification Services アプリケーションにイベント データを送信します。ホストされるイベント プロバイダとホストされないイベント プロバイダのいずれも、独自に開発してアプリケーションで使用できます。カスタム イベント プロバイダを開発するときには、以下に示すセキュリティに関する推奨事項を考慮してください。
- イベント プロバイダが NSEventProvider データベース ロールを使用してイベントを送信することを確認します。
- ユーザーやアプリケーションは、有効なイベント プロバイダ名と、アプリケーション データベースの NSEventProvider データベース ロールのメンバシップ (またはそれより高い有効な権限) を持つアカウントさえあれば、イベントを送信できます。不要な権限を許可しないようにして、ホストされないイベント プロバイダが使用するユーザー名とパスワードを保護します。
- ユーザー名やパスワードなどの機密情報をプレーン テキストで格納しないでください。機密情報は、DPAPI を使用して暗号化した後、レジストリに格納します。
- すべてのカスタム コンポーネントのソース ファイルとバイナリをセキュリティで保護します。
ホストされるカスタム イベント プロバイダは、イベント プロバイダ ホストのコンテキストでイベントを送信します。したがって、ホストされるイベント プロバイダでは、コードでセキュリティ資格情報を指定しなくてもイベントを送信できます。以下は、ホストされるイベント プロバイダに特有の推奨事項です。
- アプリケーションを作成するときに、ホストされるカスタム イベント プロバイダに関する情報をアプリケーション定義で指定します。Notification Services は、アプリケーション定義のすべての情報を信頼します。アセンブリの完全修飾名を使用して、誤ったアセンブリが読み込まれないようにします。
ホストされないイベント プロバイダは、Notification Services アプリケーションのコンテキストの外部で実行されます。以下は、ホストされないイベント プロバイダに特有の推奨事項です。
- ホストされないイベント プロバイダは、Notification Services によって明示的に信頼されていません。したがって、ホストされないイベント プロバイダでは、コードでセキュリティ資格情報を指定する必要があります。指定するアカウントは、データベース エンジンのインスタンスにログインできなければなりません。また、関連付けられるデータベース ユーザー アカウントは、各インスタンス データベースとアプリケーション データベースの NSEventProvider データベース ロールのメンバである必要があります。
カスタム配信プロトコル
カスタム配信プロトコルは、Notification Services エンジンのコンテキストで実行されます。すべてのカスタム コンポーネントと同様に、ソース ファイルとバイナリをセキュリティで保護して機密情報を保護します。
Notification Services 管理オブジェクト
Notification Services のインスタンスの構成、アプリケーションの定義、または管理アプリケーションの開発に Notification Services 管理オブジェクト (NMO) を使用する場合は、ソース ファイルとバイナリ ファイルがセキュリティで保護されていることを確認してください。インスタンス データベースやアプリケーション データベースを含むファイルには、サーバー名、ユーザー名、パスワードなどの機密情報が含まれている可能性があります。
インスタンスおよびアプリケーションのメタデータ ファイルやその他のファイルの詳細については、「ファイルおよびフォルダのセキュリティ保護」を参照してください。
参照
概念
Notification Services のセキュリティの設定
その他の技術情報
SQL Server のセキュリティに関する注意点
Notification Services の配置