アーカイブ: Windows Desktop Apps v3.1 の認定要件
ドキュメントのバージョン: 3.1
ドキュメントの日付: 2013 年 6 月 18 日
このドキュメントには、Windows 8.1 デスクトップ アプリ認定プログラムに参加するためにデスクトップ アプリが満たす必要がある技術的要件と適格性の資格が含まれています。 Windows 7 の場合、このプログラムは Windows ソフトウェア ロゴ プログラムと呼ばれていました。
ようこそ。
Windows プラットフォームは、製品とパートナーの広範なエコシステムをサポートしています。 製品に Windows ロゴを表示することは、Microsoft と会社の間の品質に対する関係と共有のコミットメントを表します。 お客様は、互換性基準を満たし、Windows プラットフォームで良好なパフォーマンスを発揮するため、製品の Windows ブランドを信頼しています。 Windows アプリ認定資格を正常に渡すと、アプリを Windows 互換センターに表示できます。また、Windows ストアにデスクトップ アプリ参照を一覧表示するために必要な手順でもあります。
Windows アプリ認定プログラムは、Windows ブランドを搭載したサードパーティ製アプリが Windows を実行している PC に簡単にインストールでき、信頼性を確保するために役立つプログラムと技術要件で構成されています。 お客様は、購入するシステムの安定性、互換性、信頼性、パフォーマンス、品質を評価します。 Microsoft は、PC 用 Windows プラットフォームで実行するように設計されたソフトウェア アプリのこれらの要件を満たすために投資に重点を置いています。 これらの取り組みには、Windows ソフトウェアを実行している PC でのエクスペリエンスの一貫性、パフォーマンスの向上、セキュリティの強化のための互換性テストが含まれます。 Microsoft 互換性テストは、業界パートナーと共同で設計されており、業界の発展と消費者の需要に応じて継続的に改善されています。
Windows アプリ認定キットは、これらの要件への準拠を検証するために使用され、Windows 7 ソフトウェア ロゴ プログラムの検証に使用される WSLK に置き換えられます。 Windows アプリ認定キットは、Windows Software Development Kit (SDK) for Windows 8.1に含まれるコンポーネントの 1 つです。
アプリの適格性
アプリが Windows 8.1 デスクトップ アプリ認定資格を取得するには、次の条件と、このドキュメントに記載されているすべての技術的要件を満たす必要があります。
- スタンドアロン アプリである必要があります
- ローカル Windows 8.1 コンピューターで実行する必要があります
- 認定された Windows Server アプリのクライアント コンポーネントにすることができます
- コードと機能が完成している必要があります
- ファイルやレジストリ キーを介してなど、ローカル メカニズムを介して Windows ストア アプリと通信することはできません
- Windows システムのセキュリティや機能を危険にさらしたり、侵害したりしてはなりません
- 一意の名前を持つ必要があり、他のユーザーが商標登録することはできません
デスクトップ アプリがウイルス対策および/またはスパイウェア対策 (マルウェア対策) 製品カテゴリに送信される場合は、マルウェア対策プラットフォームガイドラインに準拠している必要があります。 WINDOWS 8 ANTIMALWARE API 使用許諾契約書は、提出前に署名され、有効になっている必要があります。 パートナーは、 のメンバーであるか、または契約に記載されている組織のメンバーであり、良好な立場にある研究者を持っている必要があります。 この機能は、契約に記載されている組織によってWindows 8で認定されている必要があります。 アプリは、過去 12 か月間に少なくとも 1 回テストされ、検出とクリーニングの認定を受けている必要があります。
1.アプリは互換性があり、回復性があります
アプリがクラッシュしたり、応答を停止したりすると、ユーザーが多くの不満を引き起こします。 アプリは回復性と安定性が期待されており、このような障害を排除することで、ソフトウェアの予測性、保守性、パフォーマンス、信頼性を高めるのに役立ちます。
- 1.1 アプリは、Windows 互換性モード、AppHelp メッセージ、およびその他の互換性修正プログラムに依存してはなりません
1.2 アプリには互換性マニフェストが必要で、サポートされているバージョンの Windows に適した GUID を使用する必要があります
1.3 SetProcessDPIAware を呼び出すのではなく、アプリケーションのアセンブリ マニフェストを使用してアプリを DPI 対応にする必要がある
1.4 アプリが VB6 ランタイムに依存しないようにする
1.5 アプリは、HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dllsを使用して Win32 API 呼び出しをインターセプトするために任意の DLL を読み込まてはなりません。
2. アプリは Windows セキュリティのベスト プラクティスに従う必要がある
Windows セキュリティのベスト プラクティスを使用すると、Windows 攻撃対象領域への露出を回避するのに役立ちます。 攻撃対象のサーフェスは、悪意のある攻撃者がターゲット ソフトウェアの脆弱性を利用してオペレーティング システムを悪用するために使用するエントリ ポイントです。 最悪のセキュリティ脆弱性の 1 つは、特権の昇格です。
- 2.1 アプリで強力で適切な ACL を 使用して実行可能ファイルをセキュリティで保護する 2.2 アプリでは、ディレクトリをセキュリティで保護するために強力で適切な ACL を 使用する必要があります 2.3 アプリでは、強力で適切な ACL を 使用してレジストリ キーをセキュリティで保護する必要があります 2.4 アプリは、強力で適切な ACL を使用して、オブジェクト 2.5 を含むディレクトリをセキュリティで保護する必要があります 2.5 アプリは、改ざんに対して脆弱なサービスへの管理者以外のアクセスを減らす必要があります 2.6 アプリは、強力で適切な ACL を使用してレジストリ キーをセキュリティで保護する必要があります 2.4 アプリで強力で適切な ACL を 使用する必要があります。24 時間ごとに 2 回以上再起動してから再起動する
Windows アプリ認定プログラムは、WINDOWS システムを危険にさらさない方法で ACL とサービスが実装されていることを確認することで、Windows 攻撃サーフェスが公開されていないことを確認します。
3. アプリで Windows セキュリティ機能がサポートされる
Windows オペレーティング システムには、システムのセキュリティとプライバシーをサポートする多くの機能があります。 オペレーティング システムの整合性を維持するには、アプリでこれらの機能をサポートする必要があります。 不適切にコンパイルされたアプリでは、バッファー オーバーランが発生し、サービス拒否が発生したり、悪意のあるコードが実行されたりする可能性があります。
- 3.1 アプリで AllowPartiallyTrustedCallersAttribute (APTCA) を使用して、厳密な名前付きアセンブリへの安全なアクセスを確保する必要がある
3.2 安全な例外処理を保証するには、/SafeSEH フラグを使用してアプリをコンパイルする必要があります
3.3 データの実行を防ぐために、/NXCOMPAT フラグを使用してアプリをコンパイルする必要がある
3.4 アドレス空間レイアウトのランダム化 (ASLR) に /DYNAMICBASE フラグを使用してアプリをコンパイルする必要がある
3.5 アプリで共有 PE セクションの読み取り/書き込みを行わない
4.アプリは、システム再起動マネージャーのメッセージに従う必要があります
ユーザーがシャットダウンを開始すると、通常、シャットダウンが成功することを強く望みます。彼らは急いでオフィスを出て、ちょうど自分のコンピュータをオフにしたいかもしれません。 アプリは、シャットダウンをブロックしないことで、この望みを尊重する必要があります。 ほとんどの場合、シャットダウンは重要ではない場合があります。アプリは重大なシャットダウンの可能性に備える必要があります。
- 4.1 アプリで重大なシャットダウンを適切に処理する必要がある
- 重大なシャットダウンでは、FALSE をWM_QUERYENDSESSIONに返すアプリはWM_ENDSESSION送信され、閉じられますが、WM_QUERYENDSESSIONに応答してタイムアウトしたアプリは終了します。
- WM\_QUERYENDSESSION と LPARAM = ENDSESSION\_CLOSEAPP(0x1)。
コンソール アプリは SetConsoleCtrlHandler を呼び出して、シャットダウン通知を処理する関数を指定できます。 サービス アプリは RegisterServiceCtrlHandlerEx を呼び出して、シャットダウン通知を受け取る関数を指定できます。
- WM\_ENDSESSION と LPARAM = ENDSESSION\_CLOSEAPP(0x1)。
少なくとも、アプリはユーザー データを保存して準備し、再起動後に必要な情報を指定する必要があります。
注: 中断できない操作のためにシャットダウンをブロックする必要があるアプリは、ユーザーに理由を説明する必要があります。 ShutdownBlockReasonCreate を使用して、ユーザーに理由を説明する文字列を登録します。 操作が完了すると、アプリは ShutdownBlockReasonDestroy を呼び出して、システムをシャットダウンできることを示す必要があります。
5.アプリは、クリーン、元に戻せるインストールをサポートする必要があります
クリーン、元に戻せるインストールにより、ユーザーはシステム上のアプリを正常に管理 (展開および削除) できます。
- 5.1 アプリは、クリーン、元に戻せるインストールを適切に実装する必要があります
- DisplayName
- InstallLocation
- Publisher
- UninstallString
- VersionMajor または MajorVersion
- VersionMinor または MinorVersion
- インストールが失敗した場合、アプリはそれをロールバックし、マシンを以前の状態に復元できる必要があります。
- インストール、アンインストール、または更新の最後に、コンピューターの再起動が唯一のオプションになることはありません。 ユーザーには、後で再起動する機会が必要です。
- Windows インベントリ ツールとテレメトリ ツールには、インストールされているアプリに関する完全な情報が必要です。 MSI ベースのインストーラーを使用している場合、MSI によって以下のレジストリ エントリが自動的に作成されます。 MSI インストーラーを使用していない場合、インストール モジュールはインストール時に次のレジストリ エントリを作成する必要があります。
6. アプリは、ファイルとドライバーにデジタル署名する必要があります
Authenticode デジタル署名を使用すると、ユーザーはソフトウェアが本物であることを確認できます。 また、ファイルがウイルスに感染しているかどうかなど、ファイルが改ざんされているかどうかを検出することもできます。 カーネル モード コード署名の適用は、コード整合性 (CI) と呼ばれる Windows 機能です。これにより、ファイルのイメージがメモリに読み込まれるたびにファイルの整合性を検証することで、オペレーティング システムのセキュリティが向上します。 CI は、悪意のあるコードがシステム バイナリ ファイルを変更したかどうかを検出します。 また、カーネル モジュールの署名が正しく検証されない場合に、診断およびシステム監査ログ イベントを生成します。
- 6.1 すべての実行可能ファイル (.exe、.dll、.ocx、.sys、.cpl、.drv、.scr) は Authenticode 証明書で署名する必要があります
6.2 アプリによってインストールされるすべてのカーネル モード ドライバーには、Windows ハードウェア認定プログラムを通じて取得された Microsoft 署名が必要です。 すべてのファイル システム フィルター ドライバーは、Microsoft によって署名されている必要があります。
6.3 例外および権利放棄
- 権利放棄は、署名されていないサードパーティ再頒布可能パッケージ (ドライバーを除く) に対してのみ考慮されます。 この権利放棄を許可するには、再頒布可能パッケージの署名付きバージョンを要求する通信証明が必要です。
7. アプリは、オペレーティング システムのバージョンに基づいてインストールまたはアプリの起動をブロックチェック
技術的な制限がない場合、ユーザーがアプリのインストールまたは実行を人為的にブロックされていないことが重要です。 一般に、Windows Vista 以降のバージョンの Windows 用にアプリを作成した場合、オペレーティング システムのバージョンをチェックする必要はありません。
- 7.1 アプリでバージョンチェックを実行して等価性を確認してはいけません
- Windows XP、Windows Vista、Windows 7 でも実行される 1 つのパッケージとして配信され、オペレーティング システムのバージョンをチェックして、特定のオペレーティング システムにインストールするコンポーネントを決定する必要があるアプリ。
- 承認された API 呼び出しのみを使用してオペレーティング システムの最小バージョンのみをチェックするアプリ (インストール時のみ、実行時ではありません) で、アプリ マニフェストの最小バージョン要件を適切に一覧表示するアプリ。
- 承認された API 呼び出しのみを使用してオペレーティング システムのバージョンをチェックするセキュリティ アプリ (ウイルス対策、ファイアウォールなど)、システム ユーティリティ (デフラグ、バックアップ、診断 ツールなど)。
- 特定の機能が必要な場合は、その機能自体が使用可能かどうかをチェックします。 Windows XP が必要な場合は、Windows XP 以降 (>= 5.1) のチェック。 これにより、検出コードは将来のバージョンの Windows で引き続き機能します。 ドライバー インストーラーとアンインストール モジュールは、オペレーティング システムのバージョンをチェックしないでください。
8. アプリがセーフ モードでサービスまたはドライバーを読み込まない
セーフ モードを使用すると、ユーザーは Windows の診断とトラブルシューティングを行うことができます。 ドライバーとサービスは、ストレージ デバイス ドライバーなどの基本的なシステム操作や、ウイルス対策スキャナーなどの診断と回復の目的で必要な場合を除き、セーフ モードで読み込まれるように設定しないでください。 既定では、Windows がセーフ モードの場合は、Windows にプレインストールされたドライバーとサービスのみが開始されます。
- 8.1 例外および権利放棄
- セーフ モードで起動する必要があるドライバーとサービスには、権利放棄が必要です。 権利放棄要求には、SafeBoot レジストリ キーへの該当するドライバーまたはサービスの書き込みが含まれており、アプリまたはサービスをセーフ モードで実行する必要がある技術的な理由について説明する必要があります。 アプリ インストーラーは、次のレジストリ キーを使用して、このようなすべてのドライバーとサービスを登録する必要があります。
メモ： これらのドライバーとサービスをテストして、エラーなしでセーフ モードで機能することを確認する必要があります。
9. アプリは、ユーザー アカウント制御のガイドラインに従う必要があります
一部の Windows アプリは管理者アカウントのセキュリティ コンテキストで実行され、アプリは多くの場合、過剰なユーザー権限と Windows 特権を要求します。 リソースへのアクセスを制御することで、ユーザーはシステムを制御し、望ましくない変更から保護することができます。 望ましくない変更は、コンピューターを制御するルートキットなどの悪意のある変更や、特権が制限されているユーザーによって行われたアクションの結果である可能性があります。 リソースへのアクセスを制御するための最も重要なルールは、ユーザーが必要なタスクを実行するために必要な最小限のアクセス標準ユーザー コンテキストを提供することです。 ユーザー アカウント制御 (UAC) のガイドラインに従うと、システムが常にセキュリティ 上のリスクにさらされることなく、アプリで必要なときに必要なアクセス許可がアプリに提供されます。 ほとんどのアプリでは、実行時に管理者特権は必要ありません。標準ユーザーとして実行するだけで問題ありません。
- 9.1 アプリには、実行レベルを定義し、実行するためにアプリに必要な特権をオペレーティング システムに通知するマニフェストが必要です
- 実行レベルが highestAvailable に設定されている管理ツールまたはシステム ツール、および/または requireAdministrator
- ユーザー インターフェイス特権の分離 (UIPI) をバイパスするには、アクセシビリティまたは UI オートメーション フレームワーク アプリのみが uiAccess フラグを true に設定します。 アプリの使用率を適切に開始するには、このフラグは Authenticode 署名済みである必要があり、ファイル システム内の保護された場所 (Program Files) に存在する必要があります。
- アプリ マニフェストのマーキングは、DLL ではなく EXEs にのみ適用されます。 これは、UAC がプロセスの作成時に DLL を検査しないためです。 また、UAC ルールが Microsoft サービスに適用されないことにも注目してください。 マニフェストには、埋め込みまたは外部のいずれかを指定できます。
マニフェストを作成するには、.exe.manifest という名前 <app_name> ファイルを作成し、EXE と同じディレクトリに格納します。 アプリに内部マニフェストがある場合、外部マニフェストはすべて無視されることに注意してください。 次に例を示します。
<requestedExecutionLevel=""asInvoker |highestAvailable |requireAdministrator"" uiAccess=""true|false""/>
- 管理機能は、管理特権で実行される別のプロセスに移動する必要があります。 スタート メニューのプログラム グループからアクセスでき、昇格を要求するアプリなど、ユーザー向けアプリは Authenticode 署名済みである必要があります。
- 昇格された特権 (requireAdministrator または highestAvailable) を使用してメイン プロセスを実行するアプリでは、権利放棄が必要です。 メイン プロセスは、アプリへのユーザーのエントリ ポイントとして識別されます。 権利放棄は、次のシナリオで考慮されます。
10. アプリは、既定で正しいフォルダーにインストールする必要があります
ユーザーは、ファイルの既定のインストール場所と一貫性があり、セキュリティで保護されたエクスペリエンスを持っている必要があります。一方で、任意の場所にアプリをインストールするオプションを維持する必要があります。 また、複数のユーザーが互いのデータと設定を破損または上書きすることなく同じコンピューターを使用できるように、アプリ データを正しい場所に格納する必要もあります。 Windows には、プログラムとソフトウェア コンポーネント、共有アプリ データ、およびユーザー固有のアプリ データを格納するためのファイル システム内の特定の場所が用意されています
- 10.1 アプリは、既定で Program Files フォルダーにインストールする必要があります
- レジストリの実行キー HKLM と、またはソフトウェア\Microsoft\Windows\CurrentVersion の HKCU
- レジストリ実行キー HKLM、またはソフトウェア\Wow6432Node\Microsoft\windows\CurrentVersion の HKCU
- [スタート] メニュー [すべて] [プログラムの > スタートアップ]
- %ProgramFiles% のネイティブ 32 ビット アプリと 64 ビット アプリの場合は 、x64 で実行されている 32 ビット アプリの場合は %ProgramFiles(x86)% です。 このフォルダーに対して構成されているセキュリティアクセス許可のため、ユーザー データまたはアプリ データをこの場所に格納しないでください。
- たとえば、アプリでは次のいずれかを設定しないでください。
- フォントやドライバーなどのファイルをインストールするための正しい方法を使用します。
- アプリがインストールされると、データを格納する適切なユーザーの場所がありません。 インストール後にコンピューター レベルで既定の関連付け動作を変更しようとすると、アプリが失敗します。 代わりに、ユーザー単位のレベルで既定値を要求する必要があります。これにより、複数のユーザーが互いの既定値を上書きできなくなります。
- グローバル アセンブリ キャッシュ (GAC) に書き込むアプリでは、アセンブリの依存関係をプライベートに保ち、アセンブリの共有が明示的に必要でない限り、アプリ ディレクトリに格納する必要があります。
11. アプリはマルチユーザー セッションをサポートする必要がある
Windows ユーザーは、競合や中断なしに同時セッションを実行できる必要があります。
- 11.1 アプリは、ローカルまたはリモートで複数のセッションで実行されている場合、アプリの通常の機能が悪影響を受けないようにする必要があります
11.2 アプリの設定とデータ ファイルをユーザー間で保持することはできません
11.3 ユーザーのプライバシーと設定をユーザーのセッションに分離する必要がある
11.4 アプリのインスタンスを相互に分離する必要がある
- これは、あるインスタンスのユーザー データがアプリの別のインスタンスに表示されないことを意味します。 非アクティブなユーザー セッションのサウンドは、アクティブなユーザー セッションでは聞こえないはずです。 複数のアプリ インスタンスが共有リソースを使用する場合、アプリは競合がないことを確認する必要があります。
- UAC の要件を参照してください。
12. アプリは x64 バージョンの Windows をサポートする必要があります
64 ビット ハードウェアがより一般的になると、ユーザーはアプリ開発者が 64 ビット アーキテクチャの利点を利用することを期待しています。アプリを 64 ビットに移行するか、32 ビット バージョンのアプリが 64 ビット バージョンの Windows で適切に実行されることを期待しています。
- 12.1 アプリで 64 ビットをネイティブにサポートする必要があります。または、64 ビット バージョンの Windows との互換性を維持するために、少なくとも 32 ビットの Windows ベースのアプリを 64 ビット システムでシームレスに実行する必要があります
12.2 アプリとそのインストーラーに 16 ビット コードを含めたり、16 ビット コンポーネントに依存したりしてはなりません
12.3 アプリのセットアップで、64 ビット アーキテクチャ用の適切なドライバーとコンポーネントを検出してインストールする必要がある
12.4 シェル プラグインは、64 ビット バージョンの Windows で実行する必要があります
12.5 WoW64 エミュレーターで実行されているアプリは、Wow64 仮想化メカニズムを転覆またはバイパスしようとしないでください
- アプリが WoW64 エミュレーターで実行されているかどうかを検出する必要がある特定のシナリオがある場合は、IsWow64Process を呼び出して実行する必要があります。
まとめ
これらの要件が進化するにつれて、以下のリビジョン履歴の変更に注目します。 最善の作業を行うには安定した要件が不可欠であるため、Microsoft は、行う変更が持続可能であり、アプリの保護と強化を継続することを目指します。
優れたカスタマー エクスペリエンスを提供する取り組みに参加していただきありがとうございます。
改定履歴
| Date | バージョン | リビジョンの説明 | ドキュメントへのリンク |
|---|---|---|---|
| 2011 年 12 月 20 日 | 1.0 | プレビュー用のドキュメントの最初のドラフト。 | |
| 2012 年 1 月 26 日 | 1.1 | セクション #2 に更新します。 | 1.1 |
| 2012 年 5 月 31 日 | 1.2 | 概要テスト結果を追加しました | 1.2 |
| 2012 年 6 月 29 日 | 3.0 | 最終的なドキュメントWindows 8する | 3.0 |
| 2013 年 6 月 18 日 | 3.1 | ドキュメントのWindows 8.1 | 3.1 |
デスクトップ アプリ認定の詳細を確認する
| 要件 | 説明 | 詳細 |
|---|---|---|
| 互換性と回復性 | クラッシュハング & は、ユーザーにとって大きな中断であり、フラストレーションを引き起こします。 アプリは回復性と安定性が期待されるため、このような障害を排除することで、ソフトウェアの予測性、保守性、パフォーマンス、信頼性を高めるのに役立ちます。 互換性を保つだけでなく、適切な GUID を宣言するために、ユーザー向けのアプリ エントリ ポイントをマニフェストする必要があります。 ユーザー向けのアプリ エントリ ポイントは、高 DPI 対応のためにマニフェストする必要があり、HIGH-DPI をサポートするために適切な API が呼び出されていること。 |
Windows Vista、Windows 7、Windows 8 オペレーティング システム アプリケーション検証ツール AppInit DLL アプリ (実行可能) マニフェスト 高 DPI Win32 アプリケーションの作成 |
| Windows セキュリティのベスト プラクティスに従う | Windows セキュリティのベスト プラクティスを使用すると、Windows 攻撃対象領域への露出を回避するのに役立ちます。 攻撃対象のサーフェスは、悪意のある攻撃者がターゲット ソフトウェアの脆弱性を利用してオペレーティング システムを悪用するために使用するエントリ ポイントです。 最悪のセキュリティ脆弱性の 1 つは、特権の昇格です。 |
Attack Surface Analyzer アクセス制御リスト |
| Windows セキュリティ機能のサポート | Windows オペレーティング システムでは、システムのセキュリティとプライバシーをサポートするための多くの手段が実装されています。 アプリケーションでは、OS の整合性を維持するために、これらのメジャーをサポートする必要があります。 アプリケーションを不適切にコンパイルすると、バッファー オーバーランが発生し、サービス拒否が発生したり、悪意のあるコードが実行されたりする可能性があります。 |
BinScope ツールリファレンス |
| システム再起動マネージャー メッセージに従う | ユーザーがシャットダウンを開始すると、ほとんどの場合、シャットダウンが成功することを強く望みます。彼らは急いでオフィスを出て、自分のコンピュータをオフにしたいだけかもしれません。 アプリは、シャットダウンをブロックしないことで、この望みを尊重する必要があります。 ほとんどの場合、シャットダウンは重要ではない場合があります。アプリは重大なシャットダウンの可能性に備える必要があります。 |
Windows Vista でのアプリケーション のシャットダウンの変更 再起動マネージャーの開発 |
| クリーンリバーシブルインストール | クリーン、元に戻せるインストールにより、ユーザーはシステム上のアプリを正常に管理 (展開および削除) できます。 |
方法: ClickOnce アプリケーションと共に必須コンポーネントをインストールする 64 ビット システムでのアプリケーションのインストール |
| ファイルとドライバーにデジタル署名する | Authenticode デジタル署名を使用すると、ユーザーはソフトウェアが本物であることを確認できます。 また、ファイルがウイルスに感染した場合など、ファイルが改ざんされているかどうかを検出することもできます。 カーネル モード コード署名の適用は、コード整合性 (CI) と呼ばれる Windows 機能です。これにより、ファイルのイメージがメモリに読み込まれるたびにファイルの整合性を検証することで、オペレーティング システムのセキュリティが向上します。 CI は、悪意のあるコードがシステム バイナリ ファイルを変更したかどうかを検出します。 また、カーネル モジュールの署名が正しく検証されない場合に、診断およびシステム監査ログ イベントを生成します。 |
Windows 上のカーネル モジュールのデジタル署名 |
| オペレーティング システムのバージョンに基づいてインストールまたはアプリの起動をブロックしないチェック | 技術的な制限がない場合、ユーザーがアプリのインストールや実行を人為的にブロックされていないことが重要です。 一般に、アプリが Windows Vista 以降のリリース用に作成された場合、オペレーティング システムのバージョンをチェックする理由はありません。 |
オペレーティング システムのバージョン管理 |
| セーフ モードでサービスとドライバーを読み込まない | セーフ モードを使用すると、ユーザーは Windows の診断とトラブルシューティングを行うことができます。 システムの基本的な操作 (ストレージ デバイス ドライバーなど) や診断と回復の目的 (ウイルス対策スキャナーなど) に必要な場合を除き、ドライバーとサービスをセーフ モードで読み込むよう設定しないでください。 既定では、セーフ モードでは、Windows にプレインストールされていないほとんどのドライバーとサービスは起動しません。 システムが基本的な操作または診断と回復の目的で必要とする場合を除き、これらは無効のままにする必要があります。 |
オペレーティング システムがセーフ モードで実行されているかどうかの判断 |
| ユーザー アカウント制御 (UAC) ガイドラインに従う | 一部の Windows アプリは管理者アカウントのセキュリティ コンテキストで実行され、多くは過剰なユーザー権限と Windows 特権を必要とします。 リソースへのアクセスを制御することで、ユーザーは不要な変更に対してシステムを制御できます (望ましくない変更は、マシンを密に引き継ぐルートキットや、従業員が職場のコンピューターに禁止ソフトウェアをインストールするなど、特権が制限されているユーザーからのアクションなど、悪意のある可能性があります)。 リソースへのアクセスを制御するための最も重要なルールは、ユーザーが必要なタスクを実行するために必要な最小限のアクセス標準ユーザー コンテキストを提供することです。 UAC ガイドラインに従うと、必要に応じてアプリに必要なアクセス許可が提供され、システムは常にセキュリティ 上のリスクにさらされることはありません。 |
ユーザー アカウント コントロール UAC: アプリケーション更新のガイドライン |
| 既定で正しいフォルダーにインストールする | ユーザーは、選択した場所にアプリをインストールするオプションを維持しながら、ファイルの既定のインストール場所と一貫性のある安全なエクスペリエンスを持っている必要があります。 また、複数のユーザーが互いのデータと設定を破損または上書きすることなく、同じコンピューターを使用できるように、アプリ データを正しい場所に格納する必要があります。 |
インストール/アンインストールの要件の概要 |
| マルチユーザー セッションのサポート | Windows ユーザーは、競合や中断なしで同時セッションを実行できる必要があります。 |
リモート デスクトップ サービスのプログラミング ガイドライン |
| x64 バージョンの Windows をサポートする | 64 ビット ハードウェアの普及に伴い、ユーザーはアプリ開発者がアプリを 64 ビットに移行することで 64 ビット アーキテクチャの利点を活用するか、32 ビット バージョンのアプリが 64 ビット バージョンの Windows で十分に実行されることを期待しています。 |
アプリケーションの互換性: Windows Vista 64 ビット |