Extend WSS 3.0 to protect Office documents with IRM and AD RMS

[アーティクル]
08/25/2016

SharePoint の内部Information Rights Management を SharePoint に統合する

Pav Cherny

コードのダウンロード: ChernySharePoint2009_05.exe(871 KB)

AD RMS の運用階層と運用前階層
AD RMS の運用前トポロジ
運用前のサーバー構成
SharePoint IRM の構成の問題
運用前に固有の問題
コンパイルと登録
IRM プロテクタのテスト
カスタムの IRM ドキュメントプロテクタを展開する
まとめ

Microsoft Office SharePoint Server (MOSS) 2007 には、Information Rights Management (IRM) フレームワークベースのプロテクタが付属しています。このプロテクタを使用することで、Microsoft Office ユーザーは SharePoint と Active Directory Rights Management Services (AD RMS) との統合によるメリットを享受できます。しかし、残念ながら、Windows SharePoint Services (WSS) 3.0 には、標準では IRM プロテクタは付属していません。ただし、解決策はあります。MSDN コードギャラリーの数あるすばらしいサンプルアプリケーションやコードスニペットの中に、2008 年 8 月にマイクロソフトが公開した Microsoft Office ファイル形式プロテクタのソースコードがあります。このソースコードは、現状有姿の状態で、無償で、世界全域における非独占的な権利を許諾する Microsoft 公開ライセンス (Ms-PL) の下で提供されています。このソースコードはコンパイルして、IRM プロテクタを WSS 3.0 に追加できるので、掘り出し物です。これで、どの SharePoint 環境でも、AD RMS ベースのセキュリティとコンプライアンス機能を利用できます。

今月のコラムでは、先月に引き続き SharePoint と AD RMS の統合について取り上げ、AD RMS 運用前開発環境を構築し、IRM プロテクタをコンパイルして、コンパイルしたコンポーネントを WSS 3.0 に統合する方法を説明します。IRM プロテクタのコンパイルに運用前環境が必要なわけではありませんが、運用環境で発生する可能性がある一般的な AD RMS の構成の問題が明らかになるため、興味深い演習となります。AD RMS 運用環境階層および運用前環境階層についての概念と、それらが AD RMS、Microsoft Office、および WSS 3.0 の展開に与える影響について理解するには、C/C++ 開発者である必要はありません。また、IRM プロテクタのコンパイルとテストに、C/C++ 開発スキルは必要ありません。ソースコードの拡張や統合されたプロテクタの自律型プロテクタへの変換など、開発者向けのトピックについては、この記事では取り上げません。この記事で取り上げる唯一の開発作業は、セットアッププロジェクトの作成です。このプロジェクトにより、数回のマウスクリック操作で、コンパイルしたプロテクタコンポーネントを WSS 3.0 運用サーバーに展開できるようになります。TechNet Magazine のコードのダウンロードページから入手できる 5 月号の付属リソースには、x64 バージョンの Windows Server 2008 を実行しているコンピュータでの展開、コンパイル、およびテストの手順をガイドするワークシートとツールが含まれています。

AD RMS の運用階層と運用前階層

SharePoint には、AD RMS を使用してコンテンツの暗号化と暗号化解除を行う他のアプリケーションと同様に、アプリケーションを AD RMS 階層に登録するためのデジタル署名されたマニフェストが必要です。このマニフェストでは、安全な環境を構築し、メモリ内の非暗号化コンテンツを保護するために、アプリケーションのアドレス空間への読み込みを許可および禁止するモジュールを定義しています。マニフェストを有効にするには、AD RMS の証明書階層に属する証明機関 (CA) によるデジタル署名が必要です。この階層には、マイクロソフトが管理するアプリケーション署名 CA がある運用階層か、開発者がアプリケーションマニフェストに自己署名できる運用前階層を使用します。ただし、マニフェストは両方の階層に登録することはできず、どちらかの階層にのみ登録します。運用階層と運用前階層では、ルート証明機関が異なるため、運用 CA によって署名されたマニフェストは運用前階層では無効で、自己署名されたマニフェストは運用階層では無効です。アプリケーションマニフェストの詳細については、AD RMS SDK を参照してください。

AD RMS サーバーを Active Directory フォレストに配置すると、暗黙的に AD RMS 階層が確立されます。既定では、AD RMS インストールルーチンは Microsoft DRM Server 自己登録サービス CA を使用して、サーバーライセンサ証明書 (SLC) を発行します。これは、信頼のルートにある Microsoft DRM Production Root につながる階層の一部です。図 1 に、運用 AD RMS サーバーの SLC から派生するこの証明チェーンを示します。ご使用の環境で AD RMS 階層を検査する場合は、AD RMS Certificate Chain ツール (CertificateChain.exe) が収録された付属リソースを確認してください。

図 1 AD RMS 運用前階層に属する AD RMS アプリケーション署名証明書

Microsoft DRM 運用ルートは運用階層を確立するものです。マイクロソフトでは、運用証明書を取得し、アプリケーションを運用階層に登録する事前要件として、すべてのソフトウェアベンダに Production License Agreement の締結を義務付けています。運用証明書の目的は、リリースするアプリケーションのマニフェストを作成して、これに署名することです。ただし、開発目的の場合は、運用前証明書を使用する必要があります。当初、マイクロソフトでは、ソフトウェアベンダに対して、運用前証明書の取得要件として Development License Agreement の締結を義務付けていましたが、現在では公開キー (ISVTier5AppSIgningPubKey.dat)、秘密キー (ISVTier5AppSigningPrivKey.dat)、および対応する運用前証明書 (ISVTier5AppSignSDK_Client.xml) が AD RMS SDK に含まれているため、マイクロソフトと契約を結ばなくても、開発中にマニフェストに署名できます。なお、これらのキーと運用前証明書は、Microsoft Office ファイル形式プロテクタソースコードパッケージにも含まれています。

運用前証明書を使用してアプリケーションマニフェストに署名した場合、そのアプリケーションを運用 AD RMS サーバーと連携して使用することはできません。図 1 からわかるように、isvtier5appsignsdk_client.xml の証明書チェーンのルート発行者は Microsoft DRM ISV Root で、これが運用サーバーのルートではないことは明らかです。isvtier5appsignsdk_client.xml は AD RMS Certificate Chain ツールを使用して検査できます。このため必然的に、信頼のルートに Microsoft DRM ISV Root がある SLC を持つ AD RMS サーバーが必要になります (図 1 参照)。このような AD RMS サーバーを展開するには、開発環境用に別の Active Directory フォレストを構築する必要があります。

AD RMS の運用前トポロジ

別の Active Directory フォレストを構築する場合、AD RMS の運用前トポロジについて検討することをお勧めします。具体的には、AD RMS をスタンドアロンサーバーにインストールするか、ドメインコントローラに直接インストールするかを決める必要があります。ほとんどの場合、開発目的であれば、ドメインコントローラへの展開で十分です。ただし、これは運用環境では推奨されません。運用環境では、AD RMS をドメインコントローラに展開しないでください。ドメインコントローラに展開すると、AD RMS ネットワーク ID として指定するドメインユーザーアカウントがローカルにログオンするために、ドメイン管理者のアクセス許可が必要になります。ドメインコントローラでローカルにログオンするには、管理者特権が必要です。メンバサーバーでは、ドメインユーザーアカウントに管理者特権を付与する必要はありません。この運用環境におけるドメインコントローラの問題については、Jason Tyler のブログ記事「The DOs and DON'Ts of RMS」(RMS の推奨事項と禁止事項) を参照してください。RMS をドメインコントローラに展開するという考えについて、Jason は「あまりにもひどい考えなので、いつもそんな話を目にするたびに、書いた人にムチをとってきて物置小屋の裏で私に会うように言いたいぐらい」だと述べています。

次の問題は、WSS 3.0、2007 Office system、および Microsoft Visual Studio 2008 をドメインコントローラにインストールするかどうかということです。この場合は、開発環境であっても、別個のサーバーを使用する必要があります。AD RMS の問題と同様に、WSS 3.0 のセキュリティ構成は、ドメインコントローラとメンバサーバーでは異なります。メンバサーバーを使用することで、WSS 3.0 の運用環境に匹敵する構成を維持でき、コンパイルしたコンポーネントをテストする際に、より信頼性の高い結果が得られます。もちろん、Microsoft Hyper-V Server 2008 を使用する場合は、ドメインコントローラとメンバサーバーを同じ物理コンピュータに置くことができます (図 2 参照)。Hyper-V は 64 ビットの仮想化テクノロジであるため、どちらの仮想マシンでも Windows Server 2008 の x64 エディションを使用できます。Hyper-V Server 2008 にはグラフィカルな管理ツールは付属していませんが、Hyper-V Server Remote Management Tools を別の Windows Vista ワークステーションにインストールして使用できます。その手順については、付属リソースのワークシート Installing Hyper-V Server Remote Management on a Windows Vista Workstation を参照してください。

図 2 Hyper-V ホスト上の小規模な AD RMS 開発環境

運用前のサーバー構成

Active Directory Rights Management Services の役割をインストールする前に、サーバーで特定のレジストリ設定を構成して、AD RMS のインストールによってサーバーが運用前階層に登録されるようにします。この構成を行わないと、誤った階層が確立されます。AD RMS サーバーは階層間で移動できないことに注意してください。サーバーが運用階層に登録されている場合は、AD RMS をアンインストールし、Active Directory の AD RMS サービス接続ポイント (SCP) を削除して、レジストリを構成し、Active Directory Rights Management Services の役割を再インストールする必要があります。

以下のコードは、Windows Server 2008 を実行しているコンピュータの AD RMS 階層を定義するレジストリ設定です。Hierarchy パラメータを 1 に設定することで、運用前階層を実現できます。このパラメータの値を 0 に設定するか、パラメータを設定しないと、AD RMS は運用階層に展開されます。下位互換性を維持するためのレジストリ設定も存在しますが、これはこの場合の開発環境の要件ではありません。詳細については、AD RMS SDK のレジストリ構成についてのトピックを参照してください。次のコードはレジストリ (.reg) ファイル形式で保存し、AD RMS サーバーの運用前階層を実現できます。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS\2.0]
"Hierarchy"=dword:00000001

図 3 AD RMS クライアントが AD RMS サーバーにアクセスできない

SharePoint IRM の構成の問題

AD RMS サーバーの展開と構成は、それほど複雑ではありません。むしろ注意が必要なのは、WSS 3.0 を実行するメンバサーバーで行う、SharePoint を運用前階層に登録するための構成です。単純に SharePoint 3.0 サーバーの全体管理を起動して、[サーバー構成の管理] タブを開き、[Information Rights Management] をクリックして [Active Directory で指定した既定の RMS サーバーを使用する] を選択することはできません。ここで [OK] をクリックしても、図 3 のようなエラーメッセージが表示されるだけです。メッセージからわかるように、既定で Windows Server 2008 によってインストールされているため、AD RMS クライアント (msdrm.dll) は存在しますが、AD RMS サーバーにアクセスできません。

残念ながら、エラーメッセージ、トレースログ、およびアプリケーションイベントログのいずれでも、この問題の本質は明らかにされません。より詳しい情報を得る方法の 1 つは、直接 Internet Explorer からトレースログで指定されている URL (たとえば、https://adrms.litware.com:443/_wmcs/certification) にアクセスすることです。おそらく、クライアントによって信頼されていない自己署名 SSL (Secure Sockets Layer) 証明書を AD RMS サーバーが使用している場合、Internet Explorer には "この Web サイトのセキュリティ証明書には問題があります" というメッセージが表示されます。サーバーの SSL 証明書を信頼するには、ローカルコンピュータの信頼されたルート証明機関ストアに、サーバーの SSL 証明書をインストールする必要があります。証明書は、自分のユーザーアカウントだけではなく SharePoint のすべてのセキュリティアカウントからも利用できるようにする必要があるため、必ずローカルコンピュータの物理ストアにインストールしてください。この手順については、付属リソースのワークシート Deploying WSS01 in the AD RMS Preproduction Environment を参照してください。

自己署名 SSL 証明書の扱いは難しい場合があります。SharePoint では、Active Directory の AD RMS SCP を使用して、AD RMS 証明 Web サービスの URL を特定します。SCP で Web サーバーの SSL 証明書のホスト名と異なるホスト名の URL を指定している場合、SSL 証明書を信頼されたルート証明機関ストアにインストールしても、Web サーバーは信頼されないままです。図 4 に、この問題が発生する一般的な構成シナリオを示します。この構成では、AD RMS の URL に実際のホスト名と異なるエイリアスが使用されています。これは、メンテナンスと障害回復を容易にします。AD RMS の URL は AD RMS サーバーの展開後に変更することはできませんが、CNAME レコードでは必要に応じて別のサーバーの URL をポイントできるためです。図 4 の 4 段階の手順からわかるように、まず、SharePoint サーバーでは AD RMS SCP の serviceBindingInformation 属性を参照して、AD RMS の URL を特定します。次に、CNAME レコードを基に、ホスト名 adrms.litware.com を dc01.litware.com に解決します。SharePoint が dc01.litware.com に接続すると dc01.litware.com の SSL 証明書が返されるので、アドレス不一致の競合が発生します。

図 4 名前が一致しないことが原因で信頼されない SSL 証明書

この競合を解決するには、インターネットインフォメーションサービス (IIS) 6.0 Resource Kit の SelfSSL ツールを使用して、AD RMS サーバーに adrms.litware.com の SSL 証明書を発行します。ダウンロード情報と操作手順については、付属リソースのワークシート Deploying DC01 in the AD RMS Preproduction Environment を参照してください。

SSL 証明書の問題を解決することは、機能する構成を確立するための第一歩ですが、SSL 証明書が信頼されることだけが要件ではありません。まずサーバーの全体管理のアプリケーションプールの読み取りおよび実行アクセスを付与せずに IRM を構成した場合、"サーバーへのアクセス権が得られるまで、IRM は機能しません。使用されたドメインアカウント名: WSS01$@litware.com" というエラーメッセージが返されます。このエラーは、クライアントは AD RMS 証明 Web サービスの Certify メソッドを呼び出して RMS アカウント証明書 (RAC) を取得する必要がありますが、ServerCertification.asmx ファイルへのアクセス許可がないために、この呼び出しが失敗することが原因で発生します。既定では、AD RMS サーバーの SYSTEM アカウントのみにアクセス許可が付与されています。推奨されるソリューションは、ServerCertification.asmx の証明書フォルダからアクセス許可を継承し、読み取りアクセス許可と実行アクセス許可がある WSS 3.0 サーバーのコンピュータアカウントも併せて追加することです。これにより、使用される可能性がある全アプリケーションプールアカウントに、必要なアクセス許可が付与されます。詳細については、付属リソースのワークシート Deploying DC01 in the AD RMS Preproduction Environment を参照してください。

運用前に固有の問題

この時点で、運用前環境以外では IRM フレームワークは機能します。ここでは、AD RMS クライアントとアプリケーションは、異なる証明書チェーンを使用する必要があることを思い出してください。元の構成のままで IRM フレームワークを構成すると、"必要な Windows Rights Management クライアントはインストールされていますが、正しく構成されていません" というエラーが返され、トレースログには "コンピュータがアクティブ化されていません" というまた別の情報が記録されます。これは、AD RMS クライアントがこの時点でも運用階層に属していることを示しています。これについては、レジストリエディタを使用して確認できます。レジストリキー HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy と HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\uDRM\Hierarchy を確認してください。値が 0 の場合は運用階層が指定されています。この値を 1 にすると、運用前階層がアクティブになります。次に、構成の変更を簡単に適用できる .reg ファイルの内容を示します。

Windows Registry Editor Version 5.00

 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM]
"Hierarchy"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\uDRM]
"Hierarchy"=dword:00000001

ただし、レジストリの変更が直ちに有効にならない点については注意してください。AD RMS クライアントが既に最初にエラーになった操作中に正しくないコンピュータ証明書を生成していて、引き続きこの証明書を使用するため、依然としてエラーが発生します。WSS サーバーで C:\ProgramData\Microsoft\DRM\Server フォルダを開き、すべてのサブフォルダとファイルを削除します。また、%LOCALAPPDATA%\Microsoft フォルダも確認することをお勧めします。このフォルダに DRM サブフォルダがある場合は、このサブフォルダを削除してください。このフォルダには、運用前階層では使用できなくなったクライアントライセンスが格納されているためです。これらのサブフォルダとそこに格納されている証明書ファイルは、必要に応じて AD RMS クライアントにより再度作成されます。

SharePoint 3.0 サーバーの全体管理に戻り、IRM の構成を再び試みると、次のエラーメッセージが表示されますが、惑わされないでください。これは前と同じエラーメッセージですが、エラーの原因が実は異なります。トレースログを確認すると、"安全な環境を作成し、初期化しているときに問題が発生しました ..." と記録されています。今度はマニフェストの問題です。AD RMS Certificate Chain ツールを使用して、%PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\12\Bin フォルダの Stsprtid.xml を開くと確認できますが、SharePoint はこの時点でも運用環境用のマニフェストを使用しています (図 5 参照)。

図 5 運用前階層では使用できない運用環境用のマニフェスト

運用環境用の Stsprtid.xml ファイルは削除 (または名前を変更) して、AD RMS SDK と Microsoft Office ファイル形式プロテクタダウンロードパッケージに含まれている Genmanifest.exe ツールを使用して新しいマニフェストを生成し、IIS を再起動する必要があります。ダウンロードパッケージには、この作業を容易にする SharePoint 構成ファイル (sharepoint.mcf) とバッチファイル (genmft.bat および genmft.64.bat) が付属しています。ただし、64 ビット環境用のバッチファイルでは Microsoft Office アプリケーションしか運用前階層に登録されず、SharePoint は登録されません。64 ビットサーバーで SharePoint を登録するには、この記事の付属リソースに含まれる Sharepoint.bat を使用するか、直接 Genmanifest.exe ツールを使用してください。コマンドの構文は次のとおりです。

Genmanifest.exe -chain isvtier5appsignsdk_client.xml sharepoint.mcf
 Stsprtid.xml

Genmanifest.exe についてのページ (msdn.microsoft.com/en-us/library/aa362621(VS.85).aspx) も参照してください。

コンパイルと登録

SharePoint マニフェストファイルを置き換えたら、IRM 構成は無事完了です。これで大変な部分の作業は完了です。今度は、プロテクタコンポーネントをコンパイルしてテストし、成果を手にしましょう。これは簡単な作業です。ソースコードは Visual Studio 2005 プロジェクト形式になっていますが、これは問題なく Visual Studio 2008 にアップグレードできます。ただし、ここでは 64 ビットサーバーで作業していることに注意してください。この Visual Studio プロジェクトは 32 ビット環境用に構成されています。x64 プラットフォーム用にコンポーネントをコンパイルするには、この構成を変更する必要があります (図 6 参照)。詳細については、付属リソースのワークシート Compiling, Testing, and Deploying Microsoft Office File Format Protectors を参照してください。

図 6 64 ビットの WSS サーバー上で IRM プロテクタを使用するには、ソースコードを x64 プラットフォーム用にコンパイルする必要がある

COM コンポーネントの登録は Visual Studio によってビルド時に処理されますが、IRM プロテクタの WSS 3.0 への登録はユーザーが行う必要があります。各コンポーネントのクラス識別子 (CLSID) を HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\IrmProtectors に追加し、コンポーネントを登録してください。この手順を実行するレジストリファイルは、次のとおりです。

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server
 Extensions\12.0\IrmProtectors]
"{2E4402B2-F2DA-4BC8-BB2C-41BECF0BDDDB}"="MsoIrmProtector"
"{81273702-956F-4CBD-9B16-43790558EE29}"="OpcIrmProtector"

また、付属リソースの IrmProtectors.reg ファイルの内容も参照してください。このファイルには、参考用に複数の追加のキーが含まれています。これらのキーを含めたのは、MOSS 2007 の IRM プロテクタに同様のエントリがあるためです。唯一の違いは、MOSS プロテクタではプロテクタの設定を使用するのに対し、IRM プロテクタはハードコーディングされた値を使用することです。

IRM プロテクタのテスト

WSS で IRM プロテクタが認識されるようになったので、今度は、IIS を再起動し、SharePoint サイトを開いて、ドキュメントライブラリの AD RMS ポリシーを構成し、ドキュメントを作成、アップロード、およびダウンロードして、IRM プロテクタが機能することを確認します。ただし、基本的な COM の登録の問題解決が難航する場合は、テストに時間がかかる可能性があります。たとえば、Visual Studio で、構成を x64 ビットプラットフォーム用に変更するのを忘れた場合、コンパイル処理はエラーなく完了しますが、COM 登録は未完了のままになるため、WSS はプロテクタを読み込むことができず、AD RMS 保護をテストすることはできません。まず COM 登録を確認して、登録が正常に完了している場合にのみ SharePoint でのテストを実行することで、テストにかかる時間を短縮できます。図 7 は、COM 登録を確認するための基本的なスクリプトです。このスクリプトでは、単純に COM コンポーネントを読み込み、その結果をメッセージボックスに表示します。

On Error Resume Next
set MsoIrmProtector=NOTHING 
set OpcIrmProtector=NOTHING 

set MsoIrmProtector=CreateObject("MsoIrmProtector.MsoIrmProtector")
set OpcIrmProtector=CreateObject("OpcIrmProtector.OpcIrmProtector")

IF MsoIrmProtector IS NOTHING AND OpcIrmProtector IS NOTHING THEN
   Wscript.Echo "Unable to load MsoIrmProtector and OpcIrmProtector."
ELSEIF MsoIrmProtector IS NOTHING THEN
          Wscript.Echo "OpcIrmProtector loaded successfully, but
           unable to load MsoIrmProtector."
ELSEIF OpcIrmProtector IS NOTHING THEN
          Wscript.Echo "MsoIrmProtector loaded successfully, but
           unable to load OpcIrmProtector."
ELSE
Wscript.Echo "MsoIrmProtector and OpcIrmProtector loaded
           successfully."
END IF

図 7 SharePoint でプロテクタのテストを行う前に IRM プロテクタが COM コンポーネントとして適切に登録されていることを確認するスクリプト

On Error Resume Next
set MsoIrmProtector=NOTHING 
set OpcIrmProtector=NOTHING 

set MsoIrmProtector=CreateObject("MsoIrmProtector.MsoIrmProtector")
set OpcIrmProtector=CreateObject("OpcIrmProtector.OpcIrmProtector")

IF MsoIrmProtector IS NOTHING AND OpcIrmProtector IS NOTHING THEN
   Wscript.Echo "Unable to load MsoIrmProtector and OpcIrmProtector."
ELSEIF MsoIrmProtector IS NOTHING THEN
          Wscript.Echo "OpcIrmProtector loaded successfully, but
           unable to load MsoIrmProtector."
ELSEIF OpcIrmProtector IS NOTHING THEN
          Wscript.Echo "MsoIrmProtector loaded successfully, but
           unable to load OpcIrmProtector."
ELSE
Wscript.Echo "MsoIrmProtector and OpcIrmProtector loaded
           successfully."
END IF

登録設定が適切な場合、2007 Office system ドキュメント形式用の OpcIrmProtector コンポーネントは、すぐに機能します。ただし、古いバージョンの Office 形式用の MsoIrmProtector コンポーネントには、もう 1 つ要件があります。MsoIrmProtector.dll を格納しているフォルダには、テンプレートファイルを保持する 1033 サブフォルダも必要です。テンプレートファイルはソースコードと併せて提供されており、\MsoIrmProtector\Templates フォルダに格納されています。これらのファイルを 1033 サブフォルダにコピーして、MsoIrmProtector コンポーネントによってこれらのファイルが AD RMS 保護ドキュメントに組み込まれるようにして、Office 2000 や Office XP など、AD RMS をサポートしない Office アプリケーションとの下位互換性を確保する必要があります。この作業を行わないと、古いバージョンの Office ドキュメントを開くことができません。たとえば、ドキュメントライブラリに新しい Word 文書を作成すると、図 8 のようなエラーが表示されます。

図 8 MsoIrmProtector コンポーネントではテンプレートファイルなしで適切な形式で文書を作成できないため、Word でこの文書を読み取れない

カスタムの IRM ドキュメントプロテクタを展開する

お疲れさまでした。これで、WSS 3.0 用のカスタムの IRM プロテクタのビルド、登録、およびテストが無事に完了しました。今度は、これらのコンポーネントを WSS 3.0 運用サーバーに展開する必要があります。IRM プロテクタを運用環境で使用するには、すべての IRM プロテクタをサーバーにインストールする必要があります。手動で展開すると、手間がかかり、間違いが起こりやすくなります。そのため、セットアッププロジェクトをビルドし、必要なファイル構造に DLL とテンプレートドキュメントを追加し、コンポーネントを WSS 3.0 に組み込むために必要なレジストリ設定をインポートして、できあがった Microsoft Windows インストーラ (.msi) ファイルを展開に使用する方が適切です。

また、参照システムで展開をテストすることもお勧めします。何といっても、このようなテストを行うと、コンポーネントの展開前に整えておく必要がある重要な事前要件を明らかにすることができるというメリットがあります。具体的には、Visual Studio 2008 によって Microsoft .NET Framework 3.5 SP1 の依存関係が Setup.exe に追加されます。また、IRM プロテクタコンポーネントには Microsoft Visual C++ 再頒布可能パッケージが必要です。これは、Visual C++ を使用してコンパイルされた実行可能ファイルと DLL の標準の要件です。再頒布可能パッケージのバージョンは、開発環境で使用したバージョンと同じになるようにしてください。たとえば、Microsoft Visual Studio 2008 SP1 を使用する場合は、Microsoft Visual C++ 2008 SP1 再頒布可能パッケージ (x64) を展開します。付属リソースのワークシート Testing the Microsoft Office File Format Protectors Deployment では、単一サーバーへの IRM プロテクタ展開をテストする手順を説明しています。

まとめ

以前は Microsoft Office ドキュメントに対して IRM ベースの保護を提供するには MOSS 2007 が必要でしたが、MSDN コードギャラリーで提供されている Microsoft Office ファイル形式プロテクタのソースコードをコンパイルすることで、適切な IRM プロテクタコンポーネントを WSS 3.0 にも組み込むことができます。また、C や C++ のスキルがあり、SharePoint を AD RMS 運用前環境に展開している場合は、このソースコードを変更してカスタム機能を組み込むこともできます。ただし、ソースコードを変更した場合は、すべての AD RMS 対応ドキュメントライブラリに影響することに注意してください。独自のアプリケーションを IRM フレームワークに統合するためのすばらしいサンプルをお探しでない限り、ソースコードは変更せずに、更新されたコードや機能が追加された新しいバージョンがないか MSDN コードギャラリーを定期的に確認することをお勧めします。この場合、ソースコードは叩き台として非常に役立ちます。

ただし、IRM フレームワークは、SharePoint データベース内のコンテンツ項目の保護を目的に設計されていないことに注意してください。たとえば、暗号化ルーチンは変更しないでください。IRM フレームワークでは、コンテンツを保護する際に、アプリケーションプールアカウントと現在のユーザーの AD RMS アクセス許可しか付与しないため、暗号化ルーチンを変更すると、SharePoint ユーザーがドキュメントを開けなくなる可能性があります。また、完全に機能するシステムを構築するためには、他のプロテクタを必要とするプロテクタがあることにも注意してください。たとえば、古いバージョンの Office ドキュメント形式用の MsoIrmProtector プロテクタと 2007 Office system 形式用の OpcIrmProtector プロテクタはセットで使用します。OpcIrmProtector プロテクタなしで MsoIrmProtector プロテクタのみを展開した場合、Word 2007 ユーザーは SharePoint から template.doc コンテンツテンプレートを使用して新しいドキュメントを作成すると、保存されるファイルは Doc1.docx という名前になる可能性があります。MsoIrmProtector プロテクタは AD RMS 保護を template.doc に適用するため、Doc1.docx は、権利が保護された形式でドキュメントライブラリ内に格納されることになります。これは、アップロード時にコンテンツの暗号化を解除する OpcIrmProtector プロテクタがないためです。アプリケーションプールアカウントと現在のユーザーのみが、この文書を開くことができるエンティティになります。AD RMS を利用して SharePoint コンテンツデータベース内のドキュメントを保護する方法は、ISPExternalBinaryStorage COM インターフェイスを使用する方法など、他にもあります。

Pav Cherny は、主にコラボレーションとユニファイドコミュニケーションに関するマイクロソフトテクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイトペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、ドキュメント管理とローカライズサービスの専門企業 Biblioso Corporation の代表取締役です。

目次

図 7 SharePoint でプロテクタのテストを行う前に IRM プロテクタが COM コンポーネントとして適切に登録されていることを確認するスクリプト

その他のリソース