アーカイブ: Windows Desktop Apps v1.2 の認定要件
ドキュメントのバージョン: 1.2
ドキュメントの日付: 2012 年 5 月 31 日
このドキュメントには、Windows 8 デスクトップ アプリ認定プログラムに参加するためにデスクトップ アプリが満たす必要がある技術的要件と適格性の資格が含まれています。 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 ソフトウェア開発キット (SDK) に含まれるコンポーネントの 1 つです。
アプリの適格性
アプリがデスクトップ アプリ認定資格をWindows 8するには、次の条件と、このドキュメントに記載されているすべての技術的要件を満たす必要があります。
- スタンドアロン アプリである必要があります
- ローカル Windows 8.1 コンピューターで実行する必要があります
- 認定された Windows Server アプリのクライアント コンポーネントにすることができます
- コードと機能が完成している必要があります
1.アプリは互換性があり、回復性があります
アプリがクラッシュしたり、応答を停止したりすると、ユーザーが多くの不満を引き起こします。 アプリは回復性と安定性が期待されており、このような障害を排除することで、ソフトウェアの予測性、保守性、パフォーマンス、信頼性を高めるのに役立ちます。
- 1.1 アプリは、Windows 互換性モード、AppHelp メッセージ、およびその他の互換性修正プログラムに依存してはなりません
1.2 アプリが VB6 ランタイムに依存しないようにする
1.3 アプリは、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)。
少なくとも、アプリはユーザー データを保存して準備し、再起動後に必要な情報を指定する必要があります。
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 ルールが Windows サービスに適用されないことにも注目してください。 マニフェストは、埋め込みまたは外部にすることができます。
マニフェストを作成するには、.exe.manifest という名前 <app_name> ファイルを作成し、EXE と同じディレクトリに格納します。 アプリに内部マニフェストがある場合、外部マニフェストは無視されることに注意してください。 次に例を示します。
<requestedExecutionLevel level=""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
- [スタート] メニュー [AllPrograms > STARTUP]
- %ProgramFiles% のネイティブ 32 ビットおよび 64 ビット アプリの場合は 、x64 で実行されている 32 ビット アプリの場合は %ProgramFiles(x86)% です。 このフォルダーに対して構成されたセキュリティ アクセス許可のため、ユーザー データまたはアプリ データをこの場所に格納しないでください。
- たとえば、アプリで次の設定を行うべきではありません。
- フォントやドライバーなどのファイルをインストールするための正しい方法を使用します。
- アプリがインストールされると、データを格納する適切なユーザーの場所がありません。 インストール後にコンピューター レベルで既定の関連付け動作を変更しようとすると、アプリによって失敗します。 代わりに、既定値をユーザー単位レベルで要求する必要があります。これにより、複数のユーザーが互いの既定値を上書きできなくなります。
- グローバル アセンブリ キャッシュ (GAC) に書き込むアプリには放棄が必要です。.NET アプリでは、アセンブリの依存関係をプライベートに保ち、アセンブリの共有が明示的に必要でない限り、アプリ ディレクトリに格納する必要があります。
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 を呼び出して実行する必要があります。
デスクトップ アプリで実行されたテストの概要
| テスト名 | 可能なテスト結果 |
|---|---|
| システム再起動マネージャー メッセージに従う | 合格/失敗 |
| クリーンリバーシブルインストール | 成功/失敗/警告 |
| 互換性 & 回復性テスト | 成功/失敗/警告 |
| デジタル署名されたファイル テスト | 成功/失敗/警告 |
| 正しいフォルダーテストにインストールする | 警告 |
| マルチユーザー セッション テスト | 警告 |
| OS バージョン チェック テスト | 合格/失敗 |
| セーフ モード テスト | 合格/失敗 |
| x64 Windows テストのサポート | 合格/失敗 |
| Windows セキュリティ機能の変更をテストする (Attack Surface Analyzer) | 合格/失敗/警告 |
| Windows セキュリティ機能の変更をテストする (BinScope Binary Analyzer) | 警告 |
| ユーザー アカウント制御 (UAC) テスト | 合格/失敗/警告 |
まとめ
これらの要件が進化するにつれて、以下のリビジョン履歴の変更に注目します。 最善の作業を行うには安定した要件が不可欠であるため、Microsoft は、行う変更が持続可能であり、アプリの保護と強化を継続することを目指します。
優れたカスタマー エクスペリエンスを提供する取り組みに参加していただきありがとうございます。
改定履歴
| Date | バージョン | リビジョンの説明 | ドキュメントへのリンク |
|---|---|---|---|
| 2011 年 12 月 20 日 | 1.0 | プレビュー用のドキュメントの最初の下書き。 | |
| 2012 年 1 月 26 日 | 1.1 | セクション #2 に更新します。 | 1.1 |
| 2012 年 5 月 31 日 | 1.2 | サマリー テスト結果を追加しました 最終文書 |
1.2 |
デスクトップ アプリ認定の詳細を確認する
| 要件 | 説明 | 詳細 |
|---|---|---|
| 互換性と回復性 | クラッシュハング & は、ユーザーにとって大きな中断であり、フラストレーションを引き起こします。 アプリは回復性と安定性が期待されており、このような障害を排除することで、ソフトウェアがより予測可能で、保守可能で、パフォーマンスが高く、信頼できることを保証するのに役立ちます。 |
Windows Vista、Windows 7、Windows 8 オペレーティング システム アプリケーション検証ツール AppInit DLL |
| 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 ビット アーキテクチャの利点を活用するか、64 ビット バージョンの Windows で 32 ビット バージョンのアプリが適切に実行されることを期待しています。 |
アプリケーションの互換性: Windows Vista 64 ビット |