Information Protection のセキュリティのベスト プラクティス

重要

2020 年 3 月より前にリリースされた Microsoft Rights Management Service SDK のバージョンは非推奨です。以前のバージョンを使用するアプリケーションは、2020 年 3 月のリリースを使用するように更新する必要があります。 詳細については、 非推奨の通知を参照してください。

Microsoft Rights Management Service SDK の追加の機能強化は計画されていません。 分類、ラベル付け、保護サービスにMicrosoft Information Protection SDK を導入することを強くお勧めします。

Information Protection のソフトウェア開発キット (SDK) では、あらゆる種類の保護された情報を発行および使用するための堅牢なシステムが提供されます。 システムを可能な限り強化するために、ベスト プラクティスを使用して情報保護が有効なアプリケーションを構築する必要があります。 アプリケーションでは、このエコシステムのセキュリティを維持できるようにするための責任を共有します。 セキュリティ リスクを特定し、アプリケーション開発時に導入されたそのリスクの緩和策を用意することで、安全性の低いソフトウェアが実装される可能性を最小限に抑えることができます。

SDK を使用してアプリケーションの電子証明書を入手するために、この情報で署名の必要な法的契約を補います。

扱わない内容

以下は開発環境およびセキュリティで保護されたアプリケーションを作成するための重要な考慮事項ですが、この記事では扱いません。

• ソフトウェア開発プロセス管理: 構成管理、ソース コードのセキュリティ保護、デバッグ済みコードに対するアクセスの最小化、バグに対する優先度の割り当て。 顧客によっては、ソフトウェア開発プロセスをより安全にすることが何よりも重要な場合があります。 また、開発プロセスを既定している顧客もいます。
• 一般的なコーディング エラー: バッファー オーバーランの回避に関する情報。 最新版の『Writing Secure Code』(堅牢なコードの作成) (Michael Howard、David LeBlanc 共著、Microsoft Press、2002 年) を参照して、一般的な脅威と緩和策を確認することをお勧めします。
• ソーシャル エンジニアリング: 製造元の組織内にいる開発者または他の人物による悪用からのコードの保護に役立つ、手続きと構造的対策に関する情報が含まれます。
• 物理的セキュリティ: コード ベースへのアクセスのロックと、証明書への署名に関する情報が含まれます。
• プレリリース ソフトウェアの展開または配布: ベータ ソフトウェアの配布に関する情報が含まれます。
• ネットワーク管理: 物理ネットワーク上の侵入検知システムに関する情報が含まれます。

脅威モデルと緩和

デジタル情報の所有者は、資産の暗号化が解除される環境を評価できる必要があります。 最低限のセキュリティ標準の声明では、情報の所有者にアプリケーションのセキュリティ レベルを理解し、評価するためのフレームワークが提供されます。

政府機関や医療など、一部の業界には証明と認定のプロセスと標準があり、自社製品に適用される可能性があります。 このような最低限のセキュリティの推奨事項を満たすことは、顧客独自の認定に代わるものではありません。 しかし、セキュリティ標準の意図は、現在および将来の顧客の要件に備えることです。また、開発サイクルの初期段階で行う投資はアプリケーションの利点になります。 これらのガイドラインは推奨事項であり、正式な Microsoft 認定プログラムではありません。

権限管理サービス システムの脆弱性には、以下のように主要カテゴリがいくつかあります。

• 漏えい: 承認されていない場所に情報が出現する。
• 破損: ソフトウェアまたはデータが承認されていない方法で変更される。
• 拒否: コンピューティング リソースを使用できなくなる。

これらのトピックでは、主に漏えいに関する問題を中心に扱います。 API システムの整合性は、長期間にわたって情報を保護し、指定されたエンティティに対してのみアクセスを有効にする機能に依存します。 これらのトピックでは、破損の問題についても触れます。 拒否の問題は扱いません。

Microsoft では、最低限の標準を満たすことに関連するテストやテスト結果の確認を行いません。 最低限の標準が満たされていることの確認は、パートナーが責任を持って行う必要があります。 Microsoft は、一般的な脅威を緩和できる推奨事項について、2 つの追加レベルを用意しています。 一般的に、これらの提案は付加的なものです。 たとえば、推奨事項への対応では、特に明記されていない限り、該当する最低限の標準を満たしていると仮定しています。

標準レベル	説明
最低限の標準	保護された情報を処理するアプリケーションは、Microsoft から受け取った製品の証明書で署名する前に、最低限の標準を満たす必要があります。 パートナーでは一般的に、ソフトウェアの最終リリース時に製品階層証明書を使用します。 アカウントがこの最低限の標準を満たしているかどうかを確認するために、パートナーの独自の内部テストが使用されます。 最低限の標準を満たすことは、Microsoft によるセキュリティの保証ではありません。また、そのように解釈しないでください。 Microsoft では、最低限の標準を満たすことに関連するテストやテスト結果の確認を行いません。 最低限の標準が満たされていることの確認は、パートナーが責任を持って行う必要があります。
推奨される標準	推奨されるガイドラインにより、強化されたアプリケーションのセキュリティへの道筋が計画され、実装されるセキュリティ条件の増加に従って SDK が進化できる方法が提供されます。 ベンダーは、このより高いレベルのセキュリティ ガイドラインに従って構築することで、自社のアプリケーションを差別化する場合があります。
優先される標準	この標準は、現在定義されているセキュリティの最高のカテゴリです。 ベンダーが高度なセキュリティとマークされたアプリケーションを開発する場合、この標準を目指す必要があります。 この標準に従うアプリケーションは、攻撃に対する脆弱性を最小限に抑えられる可能性が高くなります。

悪意のあるソフトウェア

Microsoft は、悪意のあるソフトウェアからコンテンツを保護するために、アプリケーションが満たす必要がある最小限の標準を定義しています。

アドレス テーブルを使用して悪意のあるソフトウェアをインポートする

情報保護 SDK では、インポート アドレス テーブル (IAT) の実行時や変更時のコード変更はサポートされません。 インポート アドレス テーブルは、プロセス空間に DLL が読み込まれるたびに作成されます。 また、アプリケーションがインポートするすべての関数のアドレスが指定されます。 最も一般的な攻撃は、アプリケーション内の IAT エントリを変更して悪意のあるソフトウェアに向けるなどの攻撃です。 SDK でこの種類の攻撃が検出されると、アプリケーションは停止されます。

最低限の標準

• 実行時に、アプリケーション プロセスのインポート アドレス テーブルは変更することはできません。 アプリケーションでは、アドレス テーブルを使用して、実行時に呼び出される多く関数を指定します。 実行時や実行後に、これらのテーブルを変更することはできません。 特に、この制限は、運用証明書を使用して署名されたアプリケーションに対してコードプロファイルを実行できないことを意味します。
• マニフェストに指定されているどの DLL 内からでも、DebugBreak 関数を呼び出すことはできません。
• DONT_RESOLVE_DLL_REFERENCES フラグが設定された LoadLibrary を呼び出すことはできません。 このフラグで、ローダーに対して、インポート対象のモジュールへのバインディングをスキップするように指示し、それによってインポート アドレス テーブルを変更します。
• 実行時や実行後に /DELAYLOAD リンカー スイッチに変更を加えて、遅延読み込みを変更することはできません。
• 独自のバージョンの Delayimp.lib ヘルパー関数を用意して、遅延読み込みを変更することはできません。
• 情報保護 SDK 環境が存在する場合、認証済みモジュールで遅延読み込みされたモジュールをアップロードすることはできません。
• /DELAY:UNLOAD リンカー スイッチを使用して、遅延モジュールのアップロードを有効にすることはできません。

ライセンス権限の誤った解釈

SDK 発行ライセンスに表記されている権利をアプリケーションで正しく解釈および適用されていない場合、情報所有者が意図していなかった方法で情報が入手可能になることがあります。 たとえば、発行ライセンスで付与されているのが、情報の閲覧権限のみであるにもかかわらず、アプリケーションでユーザーに対して、暗号化されていない情報の新しいメディアへの保存が許可される場合などです。

Azure Information Protection (AIP)

情報保護システムでは、権限がいくつかのグループにまとめられます。 詳細については、「Azure Information Protection の使用権限の構成」を参照してください。

AIP では、ユーザーに対して、情報の暗号化を解除すること、または解除しないことを許可します。 情報自体の保護機能はありません。 ユーザーに情報の暗号化を解除する権限がある場合は、API でそれが許可されます。 暗号化が解除された後でその情報を管理または保護することは、アプリケーションの責任です。 情報の不正使用を防ぐように環境およびインターフェイスを管理することは、アプリケーションの責任です。 たとえば、ライセンスで表示権限のみが付与されている場合、[印刷] ボタンと [コピー] ボタンを無効にします。 テスト スイートでは、認識しているすべてのライセンス権限に対して、アプリケーションが正しく動作することを検証する必要があります。

最低限の標準

• XrML v.1.2 の権利の顧客実装は、XrML Web サイト (http://www.xrml.org) で入手できる XrML 仕様で説明されているように、これらの権利の定義と一致している必要があります。 アプリケーションに固有の権限がある場合、アプリケーションに関連するすべてのエンティティについて定義する必要があります。
• テスト スイートとテスト プロセスでは、アプリケーションでサポートされる権限に対して、アプリケーションが正しく動作していることを検証する必要があります。 また、サポートされていない権限に対して動作しないことを検証する必要があります。
• 発行アプリケーションを構築する場合は、使用される固有の権限を説明する情報を入手できるようにする必要があります。 これには、発行アプリケーションでサポートされている(サポートされていない)もの、およびこれらの権限を解釈する方法が含まれます。 さらに、ユーザー インターフェイスで、個別の情報に対して許可または禁止されている各権限の意味について、エンド ユーザーに対して明らかにする必要があります。
• アプリケーションで実装される新しい権限の追加で抽象化される権限がある場合、新しい用語にマップする必要があります。 たとえば、MANAGER という新しい権限には、抽象化された権限として、印刷、コピー、および編集権限が含まれる可能性があります。

推奨される標準

現時点ではありません。

優先される標準

現時点ではありません。

次の手順

AIP SDK を使用してアプリケーションを実装するためのベスト プラクティスには、次の記事が含まれています。

• 脅威モデルと緩和
• セキュリティ攻撃