Information Protection のセキュリティのベスト プラクティスSecurity best practices for Information Protection

Information Protection のソフトウェア開発キット (SDK) では、あらゆる種類の保護された情報を発行および使用するための堅牢なシステムが提供されます。Information Protection Software Development Kits (SDKs) provide a robust system for publishing and consuming protected information of all types. システムを可能な限り強化するために、ベスト プラクティスを使用して情報保護が有効なアプリケーションを構築する必要があります。To help a system be as strong as possible, information protection-enabled applications must be built using best practices. アプリケーションでは、このエコシステムのセキュリティを維持できるようにするための責任を共有します。Applications share responsibility in helping maintain the security of this ecosystem. セキュリティ リスクを特定し、アプリケーション開発時に導入されたそのリスクの緩和策を用意することで、安全性の低いソフトウェアが実装される可能性を最小限に抑えることができます。Identifying security risks and providing mitigations for those risks introduced during application development helps to minimize the likelihood of a less secure software implementation.

SDK を使用してアプリケーションの電子証明書を入手するために、この情報で署名の必要な法的契約を補います。This information supplements the legal agreement that must be signed, to obtain digital certificates for applications using the SDKs.

扱わない内容Subjects not covered

以下は開発環境およびセキュリティで保護されたアプリケーションを作成するための重要な考慮事項ですが、この記事では扱いません。Although the following subjects are important considerations for creating a development environment and secure applications, they're out of scope for this article:

  • ソフトウェア開発プロセス管理: 構成管理、ソース コードのセキュリティ保護、デバッグ済みコードに対するアクセスの最小化、バグに対する優先度の割り当て。Software development process management — Configuration management, securing source code, minimizing access to debugged code, and assigning priority to bugs. 顧客によっては、ソフトウェア開発プロセスをより安全にすることが何よりも重要な場合があります。For some customers, having a more secure software development process is of paramount importance to them. また、開発プロセスを既定している顧客もいます。Some customers even prescribe a development process.
  • 一般的なコーディング エラー: バッファー オーバーランの回避に関する情報。Common coding errors — Information for avoiding buffer overruns. 最新版の『Writing Secure Code』(堅牢なコードの作成) (Michael Howard、David LeBlanc 共著、Microsoft Press、2002 年) を参照して、一般的な脅威と緩和策を確認することをお勧めします。We recommend the latest version of Writing Secure Code by Michael Howard and David LeBlanc (Microsoft Press, 2002) to review these generic threats and mitigations.
  • ソーシャル エンジニアリング: 製造元の組織内にいる開発者または他の人物による悪用からのコードの保護に役立つ、手続きと構造的対策に関する情報が含まれます。Social engineering — Includes information about procedural and structural safeguards, to help protect code against exploitation by developers or others within the manufacturer's organization.
  • 物理的セキュリティ: コード ベースへのアクセスのロックと、証明書への署名に関する情報が含まれます。Physical security — Includes information about locking down access to your code base and signing certificates.
  • プレリリース ソフトウェアの展開または配布: ベータ ソフトウェアの配布に関する情報が含まれます。Deployment or distribution of prerelease software — Includes information about distributing your beta software.
  • ネットワーク管理: 物理ネットワーク上の侵入検知システムに関する情報が含まれます。Network management — Includes information about intrusion-detection systems on your physical networks.

脅威モデルと緩和Threat models and mitigations

デジタル情報の所有者は、資産の暗号化が解除される環境を評価できる必要があります。Digital information owners need the ability to evaluate the environments in which their assets will be decrypted. 最低限のセキュリティ標準の声明では、情報の所有者にアプリケーションのセキュリティ レベルを理解し、評価するためのフレームワークが提供されます。A statement of minimum security standards provides information owners with a framework for understanding and assessing the security level of the applications.

政府機関や医療など、一部の業界には証明と認定のプロセスと標準があり、自社製品に適用される可能性があります。Some industries, such as government and health care, have certification and accreditation processes and standards that may apply to your product. このような最低限のセキュリティの推奨事項を満たすことは、顧客独自の認定に代わるものではありません。Meeting these minimum security recommendations isn't a substitute for the unique accreditation needs of your customers. しかし、セキュリティ標準の意図は、現在および将来の顧客の要件に備えることです。また、開発サイクルの初期段階で行う投資はアプリケーションの利点になります。However, the intent of the security standards is to help you prepare for current and future customer requirements, and any investment you make early in the development cycle will benefit your application. これらのガイドラインは推奨事項であり、正式な Microsoft 認定プログラムではありません。These guidelines are recommendations, not a formal Microsoft certification program.

権限管理サービス システムの脆弱性には、以下のように主要カテゴリがいくつかあります。There are several major categories of vulnerabilities in a rights management services system including:

  • 漏えい: 承認されていない場所に情報が出現する。Leakage — Information appears in unauthorized locations.
  • 破損: ソフトウェアまたはデータが承認されていない方法で変更される。Corruption — Software or data is modified in an unauthorized manner.
  • 拒否: コンピューティング リソースを使用できなくなる。Denial — A computing resource isn't available for use.

これらのトピックでは、主に漏えいに関する問題を中心に扱います。These topics focus primarily on leakage issues. API システムの整合性は、長期間にわたって情報を保護し、指定されたエンティティに対してのみアクセスを有効にする機能に依存します。The integrity of an API system depends upon its ability, over time, to protect information, enabling access only to designated entities. これらのトピックでは、破損の問題についても触れます。These topics also touch upon corruption issues. 拒否の問題は扱いません。Denial issues aren't covered.

Microsoft では、最低限の標準を満たすことに関連するテストやテスト結果の確認を行いません。Microsoft doesn't test or review test results related to meeting the minimum standard. 最低限の標準が満たされていることの確認は、パートナーが責任を持って行う必要があります。The partner is responsible for ensuring the minimum standards are met. Microsoft は、一般的な脅威を緩和できる推奨事項について、2 つの追加レベルを用意しています。Microsoft provides two additional levels of recommendations to help mitigate common threats. 一般的に、これらの提案は付加的なものです。In general, these suggestions are additive. たとえば、推奨事項への対応では、特に明記されていない限り、該当する最低限の標準を満たしていると仮定しています。For example, meeting preferred recommendations assumes that you have met minimum standards, where applicable, unless otherwise specified.

標準レベルStandard level 説明Description
最低限の標準Minimum standard 保護された情報を処理するアプリケーションは、Microsoft から受け取った製品の証明書で署名する前に、最低限の標準を満たす必要があります。An application that handles protected information must meet the minimum standard, before it can be signed with the production certificate received from Microsoft. パートナーでは一般的に、ソフトウェアの最終リリース時に製品階層証明書を使用します。Partners generally use the production hierarchy certificate, at the time of final release of the software. アカウントがこの最低限の標準を満たしているかどうかを確認するために、パートナーの独自の内部テストが使用されます。A partner's own internal tests are used to verify whether the application meets this minimum standard. 最低限の標準を満たすことは、Microsoft によるセキュリティの保証ではありません。また、そのように解釈しないでください。Meeting the minimum standard isn't, and shouldn't be construed as, a guarantee of security by Microsoft. Microsoft では、最低限の標準を満たすことに関連するテストやテスト結果の確認を行いません。Microsoft doesn't test or review test results related to meeting the minimum standard. 最低限の標準が満たされていることの確認は、パートナーが責任を持って行う必要があります。The partner is responsible for ensuring the minimum is met.
推奨される標準Recommended standard 推奨されるガイドラインにより、強化されたアプリケーションのセキュリティへの道筋が計画され、実装されるセキュリティ条件の増加に従って SDK が進化できる方法が提供されます。Recommended guidelines both chart a path to improved application security, and provide an indication of how the SDK may evolve as more security criteria are implemented. ベンダーは、このより高いレベルのセキュリティ ガイドラインに従って構築することで、自社のアプリケーションを差別化する場合があります。Vendors may differentiate their applications by building to this higher level of security guidelines.
優先される標準Preferred standard この標準は、現在定義されているセキュリティの最高のカテゴリです。This standard is the highest category of security currently defined. ベンダーが高度なセキュリティとマークされたアプリケーションを開発する場合、この標準を目指す必要があります。Vendors who develop applications marketed as highly secure should aim for this standard. この標準に従うアプリケーションは、攻撃に対する脆弱性を最小限に抑えられる可能性が高くなります。Applications that adhere to this standard are likely to be the least vulnerable to attack.

悪意のあるソフトウェアMalicious software

Microsoft は、悪意のあるソフトウェアからコンテンツを保護するために、アプリケーションが満たす必要がある最小限の標準を定義しています。Microsoft has defined minimum required standards that your application must meet to protect content from malicious software.

アドレス テーブルを使用して悪意のあるソフトウェアをインポートするImporting malicious software by using address tables

情報保護 SDK では、インポート アドレス テーブル (IAT) の実行時や変更時のコード変更はサポートされません。The information protection SDK doesn't support code modification at run time or modification of the import address table (IAT). インポート アドレス テーブルは、プロセス空間に DLL が読み込まれるたびに作成されます。An import address table is created for every DLL loaded in your process space. また、アプリケーションがインポートするすべての関数のアドレスが指定されます。It specifies the addresses of all functions that your application imports. 最も一般的な攻撃は、アプリケーション内の IAT エントリを変更して悪意のあるソフトウェアに向けるなどの攻撃です。One common attack is to modify the IAT entries within an application to, for example, point to malicious software. SDK でこの種類の攻撃が検出されると、アプリケーションは停止されます。The SDK stops the application when it detects this type of attack.

最低限の標準Minimum standard

  • 実行時に、アプリケーション プロセスのインポート アドレス テーブルは変更することはできません。You can't modify the import address table in the application process during execution. アプリケーションでは、アドレス テーブルを使用して、実行時に呼び出される多く関数を指定します。Your application specifies many of the functions called at run time by using address tables. 実行時や実行後に、これらのテーブルを変更することはできません。These tables can't be altered during or after run time. 特に、この制限は、運用証明書を使用して署名されたアプリケーションに対してコードプロファイルを実行できないことを意味します。Among other things, this restriction means you can't perform code-profiling on an application signed by using the production certificate.
  • マニフェストに指定されているどの DLL 内からでも、DebugBreak 関数を呼び出すことはできません。You can't call the DebugBreak function from within any DLL specified in the manifest.
  • DONT_RESOLVE_DLL_REFERENCES フラグが設定された LoadLibrary を呼び出すことはできません。You can't call LoadLibrary with the DONT_RESOLVE_DLL_REFERENCES flag set. このフラグで、ローダーに対して、インポート対象のモジュールへのバインディングをスキップするように指示し、それによってインポート アドレス テーブルを変更します。This flag tells the loader to skip binding to the imported modules, thereby modifying the import address table.
  • 実行時や実行後に /DELAYLOAD リンカー スイッチに変更を加えて、遅延読み込みを変更することはできません。You can't alter delayed loading by making run-time or subsequent changes to the /DELAYLOAD linker switch.
  • 独自のバージョンの Delayimp.lib ヘルパー関数を用意して、遅延読み込みを変更することはできません。You can't alter delayed loading by providing your own version of the Delayimp.lib helper function.
  • 情報保護 SDK 環境が存在する場合、認証済みモジュールで遅延読み込みされたモジュールをアップロードすることはできません。You can't unload modules that are delay-loaded by authenticated modules, while the information protection SDK environment exists.
  • /DELAY:UNLOAD リンカー スイッチを使用して、遅延モジュールのアップロードを有効にすることはできません。You can't use the /DELAY:UNLOAD linker switch to enable unloading of delayed modules.

ライセンス権限の誤った解釈Incorrectly interpreting license rights

SDK 発行ライセンスに表記されている権利をアプリケーションで正しく解釈および適用されていない場合、情報所有者が意図していなかった方法で情報が入手可能になることがあります。If your application doesn't correctly interpret and enforce the rights expressed in the SDK issuance license, you may make information available in ways that the information owner didn't intend. たとえば、発行ライセンスで付与されているのが、情報の閲覧権限のみであるにもかかわらず、アプリケーションでユーザーに対して、暗号化されていない情報の新しいメディアへの保存が許可される場合などです。For example, when an application allows a user to save unencrypted information to new media, when the issuance license only confers the right to view the information.

Azure Information Protection (AIP)Azure Information Protection (AIP)

情報の保護システム権限を整理するいくつかのグループ化します。The information protection system organizes rights a few groupings. 詳細については、次を参照してください。 Azure Information Protection の使用権限を構成するします。For more information, see Configuring usage rights for Azure Information Protection.

AIP では、ユーザーに対して、情報の暗号化を解除すること、または解除しないことを許可します。AIP allows a user to either decrypt information or not. 情報自体の保護機能はありません。The information doesn't have any inherent protection. ユーザーに情報の暗号化を解除する権限がある場合は、API でそれが許可されます。If a user has the right to decrypt, the API permits it. 暗号化が解除された後でその情報を管理または保護することは、アプリケーションの責任です。The application is responsible for managing or protecting that information after it is in the clear. 情報の不正使用を防ぐように環境およびインターフェイスを管理することは、アプリケーションの責任です。An application is responsible for managing its environment and interface to prevent the unauthorized use of information. たとえば、ライセンスで表示権限のみが付与されている場合、 [印刷] ボタンと [コピー] ボタンを無効にします。For example, disabling the Print and Copy buttons if a license only grants the VIEW right. テスト スイートでは、認識しているすべてのライセンス権限に対して、アプリケーションが正しく動作することを検証する必要があります。Your test suite should verify that your application acts correctly on all the license rights that it recognizes.

最低限の標準Minimum standard

  • 顧客の XrML v.1.2 権限の実装は、XrML 仕様に記載されているこれらの権限の定義に従う必要があります。XrML 仕様は、XrML Web サイトで入手できます (http://www.xrml.org) 。The customer implementation of XrML v.1.2 rights should be consistent with the definitions of these rights, as described in the XrML specifications, which are available at the XrML Web site (http://www.xrml.org). アプリケーションに固有の権限がある場合、アプリケーションに関連するすべてのエンティティについて定義する必要があります。Any rights that are specific to your application must be defined for all entities that have an interest in your application.
  • テスト スイートとテスト プロセスでは、アプリケーションでサポートされる権限に対して、アプリケーションが正しく動作していることを検証する必要があります。Your test suite and test process should verify that your application executes properly against the rights that the application supports. また、サポートされていない権限に対して動作しないことを検証する必要があります。It should also verify that it doesn't act upon unsupported rights.
  • 発行アプリケーションを構築する場合は、使用される固有の権限を説明する情報を入手できるようにする必要があります。If you're building a publishing application, you must make information available that explains the intrinsic rights used. これには、発行アプリケーションでサポートされているものとされていないもの、およびこれらの権限を解釈する方法が含まれます。This includes those that are, and aren't, supported by the publishing application, and how these rights should be interpreted. さらに、ユーザー インターフェイスで、個別の情報に対して許可または禁止されている各権限の意味について、エンド ユーザーに対して明らかにする必要があります。In addition, the user interface should make clear to the end user what the implications are of each right granted or denied an individual piece of information.
  • アプリケーションで実装される新しい権限の追加で抽象化される権限がある場合、新しい用語にマップする必要があります。Any rights that are abstracted, by inclusion in new rights implemented by an application, must be mapped to the new terminology. たとえば、MANAGER という新しい権限には、抽象化された権限として、印刷、コピー、および編集権限が含まれる可能性があります。For example, a new right called MANAGER might include as abstracted rights the PRINT, COPY, and EDIT rights.

現時点ではありません。None at this time.

優先される標準Preferred standard

現時点ではありません。None at this time.

次の手順Next steps

AIP SDK を使用してアプリケーションを実装するためのベスト プラクティスには、次の記事が含まれています。Best practices for implementing applications by using the AIP SDK include the following articles: