Когда в Windows нужны права администратора — UAC, защищённые области и как это отличить на этапе проектирования

В консультациях вокруг Windows часто смешиваются такие темы.

• Когда действительно нужен «запуск от имени администратора»
• Почему UAC всё ещё появляется, хотя учётная запись администраторская
• Всегда ли установка требует прав администратора
• Нужно ли повышение прав и во время выполнения, если приложение лежит в Program Files
• На что на практике влияет разница между HKCU и HKLM
• Как строить приложение, которому права администратора нужны «только для части операций»

Это решается не просто тем, «является ли пользователь администратором». На практике это в значительной мере определяется тем, куда выполняется запись, чью конфигурацию затрагивает изменение и к какому защищённому объекту ОС оно обращается.

flowchart TB
    accTitle: Что определяет, нужны ли права администратора
    accDescr: Нужны ли права администратора, определяется не тем, является ли человек администратором, а тем, куда выполняется запись, кого затрагивает изменение и к какому защищённому объекту ОС оно обращается.
    a0["Является ли человек администратором"] -.-> a1["Этого недостаточно"]
    b0["Вопросы, которые реально работают"] --> b1["Куда пишем"]
    b0 --> b2["Кого затрагивает изменение"]
    b1 --> b3["К какому защищённому объекту ОС обращаемся"]

Рис. 1: Нужность прав определяет не должность пользователя, а место записи, зона влияния и объект защиты.

В статье по порядку разберём ситуации, когда в Windows нужны права администратора, начиная с основ UAC, и на практических примерах покажем, где заканчиваются права стандартного пользователя и начинается вопрос повышения прав. Содержание опирается на официальные материалы Microsoft, доступные на март 2026 года.¹²³⁴⁵

1. Сначала выводы

Сразу перечислим практические выводы.

• Нужны ли в Windows права администратора, определяется не тем, «насколько впечатляюща операция», а тем, «затрагивает ли она ОС или машину целиком».¹⁴
• Обработка, ограниченная только собственным профилем, — например %AppData%, %LocalAppData%, HKCU, Documents, — как правило, обходится без прав администратора.⁶⁷
• Наоборот, обработка, затрагивающая всю машину, всех пользователей или защищённые области, — например Program Files, Windows, System32, общемашинные настройки в HKLM или HKCR, службы Windows, драйверы ядра, брандмауэр, задачи с максимальным уровнем прав, — обычно требует прав администратора.⁴⁶⁸⁹¹⁰
• Важно понимать: членство пользователя в группе Administrators и то, что приложение сейчас работает с токеном доступа администратора, — разные вещи. При включённом UAC даже у администратора обычные процессы работают на уровне стандартного пользователя и повышаются только при необходимости.²⁶
• Установка не равна обязательным правам администратора. Как в случае установки per-user, при размещении под %LocalAppData% возможна архитектура, позволяющая распространять и обновлять приложение без прав администратора.¹¹¹²
• «Приложение, которому почему-то каждый раз нужны права администратора» на деле чаще всего либо записывает данные времени выполнения в защищённую область, либо декларирует requireAdministrator / highestAvailable в манифесте.⁴¹³
• По направлению развития Windows тоже склоняется к тому, чтобы явно повышать права только в момент необходимости. Функция Administrator protection (preview) в Windows 11 это направление показывает довольно ясно.⁵

В итоге самый практичный взгляд такой: нужны ли права администратора, определяется не статусом пользователя, а границей, к которой обращается приложение.

flowchart TB
    accTitle: Нужность повышения прав разделяется зоной влияния
    accDescr: Нужны ли права администратора, определяется не сложностью операции, а тем, затрагивает ли она ОС или машину целиком. Обработка в своём профиле чаще обходится без прав, обработка всей машины, всех пользователей или защищённых областей — чаще требует их.
    j1{"Затрагивает ли ОС или машину целиком"}
    j1 -->|"Замыкается в своём профиле"| r1["Чаще обходится без прав администратора"]
    j1 -->|"Вся машина, все пользователи, защищённые области"| r2["Чаще нужны права администратора"]
    r0["Насколько сложна операция"] -.-> r3["Не критерий решения"]

Рис. 2: Развилка — не сложность обработки, а зона влияния изменения.

Карта знаний этой статьи

Эта статья разбирает ситуации, когда в Windows нужны права администратора, с точки зрения того, идёт ли запись в защищённые области, которые затрагивают ОС или машину целиком. При включённом UAC процесс, запущенный пользователем-администратором, по умолчанию тоже работает с правами стандартного пользователя, и повышение запрашивается только в момент операции, которая трогает защищённые области вроде Program Files или HKLM. Установка не всегда требует администратора: при per-user установке можно распространять и обновлять без прав администратора, но администратор часто нужен, если данные времени выполнения пишутся в защищённые области или срабатывают условия installer detection. Модели отделения административных операций — Administrator Broker Model, служба, задача с наивысшими правами и COM с повышением; Administrator protection (preview) в Windows 11 ещё дальше продвигает направление «повышать только в нужный момент».

flowchart LR
    accTitle: Карта знаний: когда в Windows нужны права администратора
    accDescr: Схема, которая показывает, как критерий «идёт ли запись в защищённые области ОС» влияет на запрос повышения UAC, выбор per-user или per-machine установки, связь с installer detection и виртуализацией и на то, как выбирать между четырьмя моделями разделения прав.
    admin_rights["права администратора"]
    uac["UAC (контроль учётных записей)"]
    protected_system_location["защищённые области ОС"]
    integrity_level["уровень целостности"]
    installer_detection["installer detection (обнаружение установщика)"]
    file_registry_virtualization["виртуализация файлов и реестра (VirtualStore)"]
    requested_execution_level["requestedExecutionLevel (уровень запуска)"]
    runtime_data_storage["место хранения runtime-данных"]
    user_profile_storage_location["хранилище в профиле пользователя"]
    per_machine_install["установка per-machine (на всю машину)"]
    per_user_install["установка per-user"]
    administrator_broker_model["Administrator Broker Model"]
    sporadic_admin_operation["редкие операции с правами администратора"]
    os_service_model["Operating System Service Model"]
    continuous_unattended_admin_operation["постоянные, частые и unattended операции администратора"]
    elevated_task_model["Elevated Task Model"]
    short_scheduled_admin_task["короткая типовая задача администратора"]
    admin_com_object_model["Administrator COM Object Model"]
    existing_com_integration["интеграция с существующим COM"]
    administrator_protection["Administrator protection (preview)"]
    windows_service["служба Windows"]
    windows_firewall["брандмауэр Windows"]
    protected_system_location -->|"требует"| admin_rights
    uac -->|"использует"| integrity_level
    uac -.->|"требует"| admin_rights
    installer_detection -.->|"может вызвать"| uac
    file_registry_virtualization -->|"несовместимо с"| requested_execution_level
    protected_system_location -->|"не рекомендуется"| runtime_data_storage
    user_profile_storage_location -->|"рекомендуется для"| runtime_data_storage
    per_machine_install -->|"требует"| protected_system_location
    per_user_install -->|"требует"| user_profile_storage_location
    per_machine_install -->|"требует"| admin_rights
    administrator_broker_model -->|"рекомендуется для"| sporadic_admin_operation
    os_service_model -->|"рекомендуется для"| continuous_unattended_admin_operation
    elevated_task_model -->|"рекомендуется для"| short_scheduled_admin_task
    admin_com_object_model -->|"рекомендуется для"| existing_com_integration
    administrator_protection -.->|"преемник"| uac
    installer_detection -->|"несовместимо с"| requested_execution_level
    windows_service -.->|"требует"| admin_rights
    windows_firewall -.->|"требует"| admin_rights
    elevated_task_model -->|"требует"| admin_rights
    administrator_broker_model -.->|"требует"| admin_rights
    os_service_model -->|"требует"| admin_rights
    admin_com_object_model -->|"требует"| admin_rights

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 22, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что вообще означает «нужны права администратора»

В этом вопросе сначала стоит разделить пользователя и процесс.

UAC в Windows — функция безопасности, которая мешает несанкционированным изменениям ОС. В Microsoft Learn поясняется, что UAC уведомляет при попытке внести изменения, требующие разрешений уровня администратора.¹

Кроме того, в официальном описании UAC сказано, что приложения, которым нужен токен доступа администратора, запрашивают согласие конечного пользователя, а дочерние процессы наследуют токен доступа родителя, и родитель с потомком работают на одном уровне целостности.²

Отсюда следуют два вывода.

2.1 Даже «пользователь-администратор» не работает как администратор постоянно

В Microsoft Learn поясняется, что при включённом UAC даже процессы, запущенные членом группы Administrators, выполняются с правами стандартного пользователя, если их специально не повысили.⁶

Так происходит потому, что при входе администратора Windows создаёт два токена доступа, и в обычной работе используется только ограниченный. На схеме это выглядит так.²

flowchart TD
    accTitle: Два токена при входе администратора
    accDescr: При входе администратора Windows готовит отфильтрованный токен уровня стандартного пользователя и полный токен администратора. Обычные приложения, включая Проводник, идут по отфильтрованному токену; повышение через UAC нужно только для изменения защищённых областей.
    L["Администратор входит в систему"] --> S["Windows готовит два токена"]
    S --> F["Отфильтрованный токен<br/>уровень стандартного пользователя"]
    S --> A["Полный токен администратора<br/>только после повышения прав"]
    F --> N["Обычный запуск приложений<br/>Проводник тоже здесь"]
    N --> C["Дочерний процесс наследует токен родителя<br/>поэтому тоже на уровне стандартного пользователя"]
    N --> Q{"Обращение к защищённой области или службе?"}
    Q -- "нет" --> OK["Можно выполнить как есть"]
    Q -- "да" --> P["Запрос согласия UAC"]
    P --> A
    A --> E["Только повышенный процесс может менять защищённые области"]

Рис. 3: При входе администратора создаются два токена; в обычной работе используется сторона уровня стандартного пользователя.

«Я администратор, а UAC всё равно каждый раз появляется» — потому что процесс стартовал с отфильтрованным токеном, а пришла операция, которую можно сделать только полным токеном администратора. Токен фиксируется при запуске, поэтому добавить его потом можно только новым процессом — это тоже читается из этой схемы.

Иными словами,

• ваша учётная запись Windows — администраторская
• но приложение, только что запущенное двойным щелчком, работает без повышения прав
• поэтому UAC появляется только в момент операции, которой нужны права администратора

— и это нормально.

«Я же администратор, почему прав всё равно не хватает» — совершенно штатное поведение Windows.

2.2 Внутри одного процесса нельзя сделать «только эту операцию — вдруг администраторской»

UAC — не магия на уровне функций, а вопрос того, с каким токеном работает процесс. Дочерние процессы наследуют токен родителя, поэтому нельзя спроектировать так, чтобы внутри не повышенного UI-процесса в момент нажатия кнопки отдельные методы того же процесса становились административными.²

Если это необходимо, нужна отдельная единица выполнения, например:

• выделить отдельный EXE
• использовать службу
• использовать задачу с максимальным уровнем прав
• использовать повышенный COM

¹⁴

Если проектировать, не зная этой предпосылки, обычно всё сводится к слегка болезненному запросу вроде «хотим, чтобы только эта кнопка выполнялась от имени администратора».

flowchart TB
    accTitle: Повысить права только у части методов внутри процесса нельзя
    accDescr: UAC определяется токеном процесса, дочерние процессы наследуют токен родителя. Нельзя сделать административными отдельные методы внутри не повышенного UI-процесса; при необходимости выделяют отдельный EXE, службу, задачу с максимальным уровнем прав или повышенный COM.
    p1["Не повышенный UI-процесс"] -.-> p2["Сделать административными только часть методов нельзя"]
    p1 --> p3["При необходимости — отдельная единица выполнения"]
    p3 --> q1["Выделить отдельный EXE"]
    p3 --> q2["Использовать службу"]
    q1 --> q3["Использовать задачу с максимальным уровнем прав"]
    q2 --> q4["Использовать повышенный COM"]

Рис. 4: Повышение прав идёт на уровне процесса, поэтому нужную обработку выделяют в отдельную единицу выполнения.

Эти два пункта — ещё и рассадник недопонимания, поэтому в главе 9 «Частые заблуждения» они снова разобраны в виде вопросов и ответов. Для внутреннего объяснения глава 9 обычно короче и удобнее для цитирования.

3. От чего это зависит — как распознать в первую очередь

Самый понятный способ разобраться — по следующим трём линиям.

1. Куда выполняется запись
2. Чью конфигурацию затрагивает изменение
3. Обращается ли операция к объекту, который защищает ОС

3.1 Типичные области, запись в которые требует повышения прав

Это предпосылка для следующих разделов, поэтому сначала список областей, в которые «если писать — нужно повышение прав». Почти всё, что появится с главы 4, попадает в одну из строк этой таблицы.

Явно «не нужна» только последняя строка; C:\ProgramData — условная, остальное — сторона повышения прав. Иначе говоря, нужность повышения почти целиком определяется тем, удастся ли сдвинуть запись приложения в эту последнюю строку и %ProgramData%.⁴⁶⁷

flowchart TB
    accTitle: Нужность повышения прав почти целиком зависит от того, куда удаётся сдвинуть запись
    accDescr: Если запись приложения удаётся сдвинуть в профиль и ProgramData, проект ближе к работе без повышения прав. Если запись остаётся в защищённых областях, повышение прав остаётся нужным.
    w1["Выписать, куда приложение пишет"] --> j1{"Удаётся ли сдвинуть в профиль и ProgramData"}
    j1 -->|"Удаётся"| r1["Ближе к проекту без повышения прав"]
    j1 -->|"Остаётся в защищённой области"| r2["Остаётся на стороне повышения прав"]

Рис. 5: Нужность повышения прав почти целиком решает то, куда удаётся сдвинуть запись.

3.2 Таблица решений по тому, что нужно сделать

С той же стороны «что нужно сделать» таблица выглядит так. Оценку унифицировали в три значения: обязательно / зависит от ситуации / не нужно.

Если сильно обобщить:

• Изменения для себя обычно укладываются в права стандартного пользователя
• Изменения для всех обычно затрагивают администратора
• Обращение к защитной границе ОС требует администратора

Если сначала посмотреть только на эти три пункта, объяснить, «почему появляется UAC», становится намного проще.

flowchart TB
    accTitle: Распознавать по тому, для кого изменение
    accDescr: Изменения для себя чаще укладываются в права стандартного пользователя, изменения для всех чаще требуют администратора, обращение к защитной границе ОС требует администратора. Грубо, но на практике полезно.
    q1{"Для кого изменение"}
    q1 -->|"Для себя"| r1["Чаще хватает стандартного пользователя"]
    q1 -->|"Для всех"| r2["Чаще в деле администратор"]
    q1 -->|"Защитная граница ОС"| r3["Нужен администратор"]

Рис. 6: Если сначала спросить «для кого изменение», причину UAC объяснить гораздо проще.

4. Типичные случаи, где обычно нужны права администратора

4.1 Установка, обновление и удаление для всех пользователей

В описании архитектуры UAC на Microsoft Learn сказано, что многие установщики пишут в системные каталоги и разделы реестра, у стандартного пользователя нет достаточных прав доступа, и Windows обнаруживает программу установки и запрашивает повышение прав.³

Важный момент: дело не в том, что «установщик привилегирован, потому что он установщик» — повышение прав нужно потому, что место записи является защищённой областью.

Типичные примеры:

• размещение в Program Files
• запись общемашинной информации в HKLM
• регистрация COM или интеграция для всех пользователей
• установка службы или драйвера
• наличие общемашинного пути обновления

В таких случаях права администратора чаще всего нужны.³⁸

flowchart TB
    accTitle: Почему установщик запрашивает повышение прав
    accDescr: Повышение прав нужно не потому, что установщик «важный», а потому что он пишет в системные каталоги и ключи реестра вроде Program Files и HKLM, у стандартного пользователя прав недостаточно, и Windows обнаруживает программу установки.
    i1["Многие установщики"] --> i2["Пишут в системные каталоги и ключи реестра"]
    i2 --> i3["У стандартного пользователя недостаточно прав"]
    i3 --> i4["Windows обнаруживает и запрашивает повышение"]
    i1 -.-> i5["Не потому, что установщик «важный»"]

Рис. 7: Повышение прав нужно потому, что установщик пишет в защищённую область.

4.2 Запись данных времени выполнения в Program Files или HKLM

Это тоже встречается очень часто. В руководстве Microsoft по проектированию UAC сказано, что ненужного повышения прав следует избегать, а многие старые программы без необходимости требуют прав администратора именно потому, что пишут в HKLM / HKCR или в системные папки Program Files / Windows.⁴

Кроме того, в описании стандартного пользователя прямо указано, что он не может писать в папку Program Files или HKEY_LOCAL_MACHINE и не может выполнять операции, изменяющие систему.⁶

То есть если такие

• файлы настроек
• логи
• кеш
• состояние для каждого пользователя
• история недавно использованного

— данные, которые меняются во время выполнения, положены в папку установки или в HKLM, одного этого уже достаточно, чтобы получить «это приложение не запускается без прав администратора».

И происходит это нередко не потому, что приложение действительно рассчитано на администратора, а просто потому, что неудачно выбрано место хранения.

flowchart TB
    accTitle: Что бывает, если данные времени выполнения писать в защищённую область
    accDescr: Если настройки, логи, кеш и историю, которые меняются во время выполнения, кладут в папку установки или HKLM, приложение легко становится «без администратора не запускается». Причина чаще в месте хранения, а не в том, что приложение рассчитано на администратора.
    d1["Настройки, логи, кеш, история и другие данные времени выполнения"] --> d2["Кладут в папку установки или HKLM"]
    d2 --> d3["Приложение не работает без запуска от имени администратора"]
    d3 -.-> d4["Причина чаще только в выборе места хранения"]

Рис. 8: «Каждый раз нужен администратор» часто оказывается местом хранения данных времени выполнения.

4.3 Регистрация служб Windows и изменение их конфигурации

Службы находятся под управлением ОС, поэтому, разумеется, их нельзя трогать легкомысленно.

В официальной документации о правах доступа диспетчера управления службами поясняется, что для вызова CreateService нужен SC_MANAGER_CREATE_SERVICE, а открыть дескриптор, пригодный для CreateService, может только процесс с правами администратора.⁸

Также говорится, что право SERVICE_CHANGE_CONFIG, необходимое для ChangeServiceConfig / ChangeServiceConfig2, позволяет изменить исполняемый файл, который запускает система, и потому должно предоставляться только администраторам.⁸

Поэтому такие операции, как

• регистрация службы
• изменение исполняемого файла или типа запуска службы
• удаление службы
• изменение дескриптора безопасности службы

предполагают наличие прав администратора.

flowchart TB
    accTitle: Операции со службами и права администратора
    accDescr: Для CreateService нужен SC_MANAGER_CREATE_SERVICE, и открыть этот дескриптор может только процесс с Administrator privileges. Для изменения конфигурации нужен SERVICE_CHANGE_CONFIG, который позволяет сменить EXE, запускаемый системой, и потому должен выдаваться только администраторам.
    s1["Регистрация службы"] --> s2["Нужен SC_MANAGER_CREATE_SERVICE"]
    s2 --> s3["Дескриптор открывает только процесс администратора"]
    t1["Изменение конфигурации службы"] --> t2["Нужен SERVICE_CHANGE_CONFIG"]
    t2 --> t3["Должно выдаваться только администраторам"]

Рис. 9: Службы — объект управления ОС; и регистрация, и изменение конфигурации предполагают права администратора.

4.4 Установка драйвера ядра

В Microsoft Learn поясняется, что стандартный пользователь не может выполнять изменяющие систему задачи, такие как установка драйвера в режиме ядра.⁶

Это довольно понятная граница. Драйверы работают на стороне ядра, поэтому их нельзя ставить в один ряд с обычным «сохранением настроек пользовательского приложения».

• установка драйвера устройства
• установка виртуального или фильтрующего драйвера
• изменение компонентов, связанных с загрузкой или вводом-выводом

Такие операции разумно считать требующими прав администратора.

flowchart TB
    accTitle: Понятная граница драйвера ядра
    accDescr: Драйвер работает на стороне ядра, поэтому его нельзя ставить в один ряд с сохранением настроек пользовательского приложения. Задачи, изменяющие систему, вроде установки kernel-mode driver, стандартный пользователь выполнить не может.
    k1["Установка драйвера"] --> k2["В систему ставят компонент, который работает в ядре"]
    k2 --> k3["Задача, изменяющая систему"]
    k3 --> k4["Стандартный пользователь выполнить не может"]
    k1 -.-> k5["Нельзя ставить в один ряд с сохранением настроек приложения"]

Рис. 10: Всё, что трогает ядро, лежит на самой понятной административной границе.

4.5 Настройка брандмауэра и задач с высоким уровнем прав

Брандмауэр тоже часть границы безопасности ОС. В инструкциях Microsoft Learn по настройке брандмауэра прямо указано, что для управления Windows Firewall with Advanced Security на отдельном устройстве требуются administrative rights на этом устройстве.⁹

Что касается планировщика заданий, определено, что TASK_RUNLEVEL_LUA выполняется с минимальными правами, а TASK_RUNLEVEL_HIGHEST — с максимальными, а в документации по schtasks указано, что для планирования / просмотра / изменения всех задач на локальном компьютере требуется членство в группе Administrators.¹⁰

Подводя итог, такие конфигурации, как

• добавление или изменение правил Windows Firewall
• регистрация определённой операции как задачи с максимальным уровнем прав
• запуск задания от имени другого пользователя или SYSTEM

относятся к тем, где нужны права администратора.

flowchart TB
    accTitle: Брандмауэр и задачи с высоким уровнем прав
    accDescr: Изменение правил брандмауэра требует administrative rights на устройстве. Регистрация и выполнение задач планировщика с максимальным уровнем прав тоже предполагают членство в Administrators. И то и другое лежит на стороне администратора как часть границы безопасности ОС.
    f1["Изменить правила брандмауэра"] --> f2["Нужны administrative rights на этом устройстве"]
    g1["Зарегистрировать и выполнить задачу с максимальным уровнем прав"] --> g2["И регистрация, и выполнение предполагают повышение"]
    f2 --> h1["Часть границы безопасности ОС, сторона администратора"]
    g2 --> h1

Рис. 11: И брандмауэр, и задачи с высоким уровнем прав лежат на стороне администратора как граница безопасности ОС.

5. Типичные случаи, где права администратора на самом деле часто не нужны

Может казаться, что «Windows сразу требует администратора», но на самом деле частей, которые можно спроектировать без прав администратора, неожиданно много.

5.1 Собственные настройки, кеш и логи

В Microsoft Learn поясняется, что вместо опоры на виртуализацию ради совместимости приложению следует сохранять данные либо в per-user-расположении, либо в общем расположении внутри %alluserprofile% с корректно настроенными ACL.⁷

На практике удобно разделить так:

• Специфично для пользователя: %AppData%, %LocalAppData%, HKCU
• Общее, но обновляемое во время выполнения: %ProgramData% + проектирование ACL
• Сам исполняемый файл: защищённые области вроде Program Files

Если это разделение выполнено, можно сделать так, что установка самого приложения требует прав администратора, а повседневное использование — нет.

flowchart TB
    accTitle: Три разделения данных
    accDescr: Пользовательские данные — в AppData и HKCU, общие, но меняющиеся во время выполнения — в ProgramData с ACL, сам исполняемый файл — в защищённой области вроде Program Files. Тогда установке нужны права администратора, а повседневное использование — нет.
    z0["То, с чем работает приложение"] --> z1["Данные конкретного пользователя"]
    z0 --> z2["Общие, но обновляемые во время выполнения данные"]
    z0 --> z3["Сам исполняемый файл"]
    z1 --> y1["AppData / HKCU"]
    z2 --> y2["ProgramData + проектирование ACL"]
    z3 --> y3["Защищённые области вроде Program Files"]
    y2 -.-> y4["Повседневное использование можно оставить без администратора"]

Рис. 12: Если это тройное разделение есть, повышение прав нужно только в момент установки.

5.2 Установка и обновление per-user

В официальной документации Microsoft примеры размещения per-user встречаются совершенно обычно.

Например, в документации по клиенту Remote Desktop поясняется, что установка per-user выполняется в LocalAppData каждого профиля пользователя, и пользователь может обновлять его без прав администратора.¹¹

А в документации по OneDrive указано, что по умолчанию используется установка per-user, а установка per-machine выполняется командой с флагом /allusers, в результате чего появляется запрос UAC. Кроме того, per-user размещается под %localappdata%, а per-machine — под Program Files.¹²

Отсюда следует, что само слово «установка» ещё не определяет, нужны ли права администратора.

• Если каждый пользователь устанавливает в свою область, иногда можно обойтись без прав администратора
• Если устанавливать в область, общую для всех пользователей, права администратора обычно нужны

Важно заранее решить, per-user это или per-machine.

flowchart TB
    accTitle: Слово «установка» само по себе нужность прав не определяет
    accDescr: Установка per-user в свою область иногда обходится без администратора, установка per-machine в общую для всех область обычно требует администратора. Поэтому само слово «установка» ещё не определяет, нужны ли права.
    i0{"Какой способ установки"}
    i0 -->|"per-user"| i1["Каждый пользователь ставит в свою область"]
    i0 -->|"per-machine"| i2["Ставят в область, общую для всех"]
    i1 --> i3["Иногда обходятся без администратора"]
    i2 --> i4["Чаще нужны права администратора"]

Рис. 13: Не «установка = всегда администратор», а per-user или per-machine.

5.3 Обычные операции UI и бизнес-логика

И наоборот, сама по себе следующая обработка не требует прав администратора.

• открытие документов и изображений
• редактирование файлов в собственном профиле
• HTTP- и DB-коммуникация
• выполнение бизнес-логики
• отображение результата на экране
• чтение и запись собственных настроек

Если несмотря на это требуется «запускать всё приложение от имени администратора», причина чаще всего не в основной функциональности, а в том, что какая-то периферийная операция обращается к защищённой области.

flowchart TB
    accTitle: Причина не в основной функции, а в периферии
    accDescr: Открытие документов, бизнес-логика, чтение и запись своих настроек сами по себе прав администратора не требуют. Если всё равно нужен запуск всего приложения от имени администратора, причина чаще в том, что периферийная операция трогает защищённую область.
    m1["Открыть документ, связаться по сети, выполнить бизнес-логику"] --> m2["Сами по себе права администратора не нужны"]
    m3["И всё равно всё приложение требует запуска от имени администратора"] --> m4["Периферийная операция трогает защищённую область"]
    m4 -.-> m5["Причина не в основной функции"]

Рис. 14: Если основная обработка обычная, а администратор всё равно нужен, подозревайте место записи периферии.

6. Почему говорят «это приложение — только от имени администратора»

6.1 В манифесте задекларировано requireAdministrator

В манифесте приложения через requestedExecutionLevel можно задекларировать требуемый уровень прав. В Microsoft Learn определены следующие три варианта.¹³

• asInvoker: работает с теми же правами, что и запускающий процесс
• highestAvailable: работает с максимально доступными правами
• requireAdministrator: работает с правами администратора

Если у приложения установлено requireAdministrator, повышение прав предполагается при каждом запуске. Даже при highestAvailable, в зависимости от окружения, тоже может задействоваться повышение прав.¹³

Поэтому самый прямой ответ на вопрос «почему UAC появляется каждый раз» — потому что это приложение так задекларировано.

flowchart TB
    accTitle: Три декларации requestedExecutionLevel
    accDescr: В манифесте приложения requestedExecutionLevel бывает asInvoker, highestAvailable и requireAdministrator. При requireAdministrator повышение прав предполагается при каждом запуске, при highestAvailable оно может включаться в зависимости от среды.
    a1["requestedExecutionLevel в манифесте"] --> b1["asInvoker"]
    a1 --> b2["highestAvailable"]
    a1 --> b3["requireAdministrator"]
    b1 --> c1["Те же права, что у запускающего процесса"]
    b2 --> c2["В зависимости от среды может включиться повышение"]
    b3 --> c3["Повышение прав при каждом запуске"]

Рис. 15: Самая прямая причина постоянного UAC — декларация в манифесте.

6.2 Приложение попадает под installer detection Windows

В описании архитектуры UAC поясняется, что в Windows есть технология обнаружения установщиков (installer detection), и поскольку многие программы установки пишут в защищённые системные расположения, требуется повышение прав.³

Причём это происходит не просто из-за имени файла вроде setup.exe — Windows в определённой мере эвристически определяет «похоже, это установщик». В официальной документации перечислены такие условия.³

• 32-bit исполняемый файл
• отсутствует атрибут requestedExecutionLevel
• интерактивный процесс, запущенный стандартным пользователем при включённом UAC
• имя файла содержит слова вроде install, setup, update, и так далее

Поэтому то, что SetupLauncher.exe или Updater.exe внезапно запрашивают повышение прав, с точки зрения архитектуры Windows не является чем-то странным.

flowchart TB
    accTitle: Условия, при которых срабатывает installer detection
    accDescr: Installer detection в Windows эвристически считает файл установщиком, если это 32-bit исполняемый файл без requestedExecutionLevel, интерактивный процесс стандартного пользователя при включённом UAC и в имени есть install, setup, update и подобные слова, и тогда запрашивает повышение прав.
    c1["32-bit исполняемый файл"] --> e1["Считается похожим на установщик"]
    c2["Нет атрибута requestedExecutionLevel"] --> e1
    c3["В имени есть install / setup / update и подобное"] --> e1
    e1 --> e2["Запрашивается повышение прав"]

Рис. 16: Одних имени и атрибутов достаточно, чтобы файл сочли установщиком и запросили повышение прав.

6.3 Старое приложение «случайно работало» благодаря виртуализации

Этот момент легко понять неправильно.

В Microsoft Learn поясняется, что UAC предоставляет виртуализацию файлов и реестра для несоответствующих требованиям приложений, которые пытаются писать в защищённые области. При этом прямо указано, что это краткосрочная мера для совместимости, а не долгосрочное решение.³⁷

Кроме того, у виртуализации есть ограничения.

• не применяется к приложениям с уже повышенными правами
• применяется только к 32-bit приложениям
• отключается при наличии манифеста с requestedExecutionLevel
• изначально приложение следует исправить так, чтобы оно писало в правильное место

³⁷

То есть иногда кажется, будто старое 32-bit приложение «могло писать в Program Files без прав администратора», но на самом деле это может означать лишь то, что запись не выполнялась по-настоящему, а перенаправлялась в VirtualStore.

Поэтому в такие моменты, как

• переход на 64-bit
• добавление манифеста
• изменение способа сборки
• продвижение к соответствию UAC

«ошибка проектирования места хранения», ранее не проявлявшаяся, может внезапно стать видимой.

flowchart TB
    accTitle: Как всплывает «случайно работало» из-за виртуализации
    accDescr: Несоответствующее 32-bit приложение, которое пишет в защищённую область, виртуализация уводит в VirtualStore, и оно выглядит работающим. Это краткосрочная мера совместимости: при переходе на 64-bit или добавлении манифеста виртуализация перестаёт действовать, и ошибка места хранения внезапно становится видимой.
    v1["Несоответствующее 32-bit приложение пытается писать в защищённую область"] --> v2["Виртуализация уводит запись в VirtualStore"]
    v2 --> v3["Выглядит работающим, хотя пишет не туда"]
    v3 --> v4["Переход на 64-bit или манифест отключают виртуализацию"]
    v4 --> v5["Ошибка места хранения внезапно становится видимой"]

Рис. 17: Виртуализация — временная мера, поэтому ошибка проектирования всплывает в момент смены среды.

6.4 Проблема просто в том, что место обращения во время выполнения выбрано неудачно

На практике в конечном счёте это встречается чаще всего.

• сохранение настроек рядом с EXE
• запись логов в папку установки
• создание временных файлов внутри Program Files
• запись состояния для каждого пользователя в HKLM

При такой конфигурации получается неудобная форма: само приложение — обычный UI, но для запуска нужны права администратора.⁴⁶

Случаи, когда администратор нужен не потому, что операция сложна, а потому, что неудачно выбрано место хранения, встречаются очень часто.

6.5 Как проверить, какой из случаев у своего приложения

Разделы 6.1–6.4 описывают типы причин, но в реальном разборе нужно убедиться, какой из них относится к вашему приложению. Двух шагов обычно достаточно.

Шаг 1: посмотреть requestedExecutionLevel в манифесте

Сначала проверьте, не декларирует ли приложение повышение прав само. Встроенный в EXE манифест извлекают утилитой mt.exe из Windows SDK.

mt.exe -inputresource:MyApp.exe;#1 -out:MyApp.manifest

#1 — идентификатор ресурса манифеста, встраиваемого в исполняемый файл. В полученном XML ищите строку вроде следующей.

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

Если там requireAdministrator, причина — 6.1, можно остановиться. Если asInvoker, декларация ни при чём — переходите к шагу 2. Бывает и так, что манифест вообще не встроен. Это тоже важный факт: 32-bit исполняемый файл без requestedExecutionLevel может попасть и под installer detection из 6.2, и под виртуализацию из 6.3.³

Шаг 2: проверить, не появилась ли копия в VirtualStore

Дальше смотрят, не виртуализировались ли файлы, которые приложение «писало» в защищённую область. Куда идёт перенаправление, известно.

dir /s /a "%LocalAppData%\VirtualStore"

Если там лежат настройки или логи вашего приложения, оно писало не в Program Files, а в пользовательскую копию. Например, запись в C:\Program Files\Contoso\Settings.ini уходит в %LocalAppData%\VirtualStore\Program Files\Contoso\Settings.ini.³

То же и с реестром: запись в HKEY_LOCAL_MACHINE\Software уходит в HKEY_USERS\<SID пользователя>_Classes\VirtualStore\Machine\Software. От текущего пользователя то же самое видно в редакторе реестра по пути HKEY_CURRENT_USER\Software\Classes\VirtualStore\Machine\Software.⁷

Этих двух шагов достаточно, чтобы понять, причина «нужны права администратора» — декларация или место хранения. Если место хранения, по 7.3 править нужно его; добавлять повышение прав — не решение.

flowchart TB
    accTitle: Два шага, чтобы проверить причину
    accDescr: Сначала mt.exe извлекает манифест EXE и смотрят requestedExecutionLevel: requireAdministrator означает декларацию. Если asInvoker или декларации нет, проверяют копии в VirtualStore; если копии есть, причина в месте хранения, и править нужно его, а не добавлять повышение прав.
    s1["Шаг 1: посмотреть requestedExecutionLevel в манифесте"] --> j1{"Что задекларировано"}
    j1 -->|"requireAdministrator"| r1["Причина — декларация"]
    j1 -->|"asInvoker или декларации нет"| s2["Шаг 2: проверить копии в VirtualStore"]
    s2 -->|"Копии есть"| r2["Причина — место хранения"]
    r2 --> r3["Править место хранения (добавлять повышение прав — не решение)"]

Рис. 18: Декларация или место хранения: двумя шагами причина обычно разделяется.

7. Как спроектировать приложение так, чтобы избежать лишних повышений прав

7.1 Базовый вариант — asInvoker

Если приложение целиком действительно не является инструментом системного администрирования, базовая линия — запускать обычное UI-приложение без повышения прав. С точки зрения манифеста asInvoker — это декларация «работать с теми же правами, что и запускающий процесс».¹³

Если запускать от имени администратора вообще всё — повседневные операции с экраном, бизнес-логику, сохранение настроек для каждого пользователя, — увеличиваются такие проблемы:

• расширяется поверхность атаки
• становится трудно объяснить эксплуатацию
• UAC появляется каждый раз
• становится непонятно, «какой обработке на самом деле нужен администратор»

Руководство Microsoft по проектированию UAC тоже поясняет, что следует устранять ненужное повышение прав, оставляя права администратора только для задач, которым они действительно необходимы.⁴

flowchart TB
    accTitle: Какие проблемы растут, если всё гонять от имени администратора
    accDescr: Если повседневные операции с экраном и бизнес-логику тоже гонять от имени администратора, растёт поверхность атаки, каждый раз появляется UAC, становится трудно объяснить эксплуатацию и не видно, какой обработке администратор действительно нужен. Базовая линия — обычное UI-приложение без повышения прав.
    a1["Всё гонять от имени администратора"] --> b1["Растёт поверхность атаки"]
    a1 --> b2["UAC появляется каждый раз"]
    b1 --> b3["Трудно объяснить эксплуатацию"]
    b2 --> b4["Не видно, какая обработка действительно нужна"]
    b3 --> c1["Базовая линия — asInvoker без повышения"]
    b4 --> c1

Рис. 19: База — asInvoker, повышение прав оставляют только действительно нужным задачам.

7.2 Выносить в отдельную единицу выполнения только обработку, требующую администратора

В Microsoft Learn явно представлены модели, при которых приложение с операциями, требующими прав администратора, всё же работает как приложение стандартного пользователя, выделяя только необходимую часть.¹⁴

Четыре типовые модели:

• Administrator Broker Model UI-приложение стандартного пользователя + вспомогательный EXE с правами администратора
• Operating System Service Model UI стандартного пользователя + резидентная служба
• Elevated Task Model UI стандартного пользователя + запланированное задание с максимальным уровнем прав
• Administrator COM Object Model UI стандартного пользователя + повышенный COM

Грубое разделение по применению:

• Если административные операции нужны лишь изредка — вспомогательный EXE
• Если это постоянно, без участия пользователя, часто — служба
• Для коротких типовых заданий — задача с максимальным уровнем прав
• Если предполагается существующий COM — повышенный COM

О том, как конкретизировать этот подход для Windows-приложений, подробно рассказано в отдельной статье Как на практике выделить в Windows-приложении «только те операции, для которых нужны права администратора».

flowchart TB
    accTitle: Как выбирать из четырёх моделей разделения
    accDescr: Приложение стандартного пользователя выделяет только административную часть: редкие операции — helper EXE модели Administrator Broker, постоянные, без пользователя и частые — служба, короткие типовые задания — задача с максимальным уровнем прав, интеграция на существующем COM — повышенный COM.
    q1{"Каков характер административных операций"}
    q1 -->|"Лишь изредка"| m1["helper EXE (Broker Model)"]
    q1 -->|"Постоянно, без пользователя, часто"| m2["Служба"]
    m1 --> m3["Для коротких типовых заданий — задача с максимальным уровнем прав"]
    m2 --> m4["Если база — существующий COM, то повышенный COM"]

Рис. 20: Моделей разделения четыре; выбирают по частоте и форме административных операций.

7.3 Исправляем место хранения данных времени выполнения

Принцип выбора места хранения довольно прост.

• Данные, специфичные для пользователя, — в HKCU или %AppData%
• Локальный кеш — в %LocalAppData%
• Общие, но изменяющиеся во время выполнения данные — в %ProgramData% + ACL
• Сам исполняемый файл — в Program Files

В Microsoft Learn тоже поясняется, что приложению следует сохранять данные либо в per-user-расположении, либо в %alluserprofile% (фактически ProgramData) с корректно настроенными ACL.⁷

При таком упорядочивании легче добиться того, чтобы повышались права только у установщика, а сам работающий процесс оставался без повышения.

flowchart TB
    accTitle: Если поправить место хранения, повышение прав сужается
    accDescr: Пользовательские данные — в HKCU и AppData, локальный кеш — в LocalAppData, общие, но меняющиеся во время выполнения — в ProgramData с ACL, сам исполняемый файл — в Program Files. Тогда повышать права нужно только установщику, а работающий процесс остаётся без повышения.
    p1["Привести место хранения данных времени выполнения к этим правилам"] --> p2["Повышение прав нужно только для размещения исполняемого файла"]
    p2 --> p3["Повышают права только у установщика"]
    p2 --> p4["Работающее приложение остаётся без повышения"]

Рис. 21: Разбор мест хранения — основа того, чтобы замкнуть повышение прав на момент установки.

7.4 Решаем заранее — per-user или per-machine

Этот момент неожиданно часто упускают.

• Должно ли приложение устанавливаться каждым пользователем самостоятельно
• Должно ли оно устанавливаться в одно общее для всех пользователей место
• Кто отвечает за обновления
• Допустимо ли запускать исполняемый файл из профиля пользователя

Если это решение остаётся неясным, позже легко получить путаницу:

• установка требует администратора
• запуск тоже требует администратора
• обновление тоже требует администратора
• лишь часть работает в пользовательском контексте

Различие между per-user и per-machine — это не просто вопрос способа распространения, а само проектирование прав.

flowchart TB
    accTitle: Сначала решить per-user / per-machine
    accDescr: Если заранее не решить, ставит ли каждый пользователь себе сам, ставить ли в одно общее место и кто отвечает за обновления, права на установку, запуск и обновление разъезжаются. Разница per-user и per-machine — не способ распространения, а само проектирование прав.
    d1["Сначала решить per-user / per-machine"] -->|"Если решили"| d2["Права на установку, запуск и обновление совпадают"]
    d1 -.->|"Если идти в тумане"| d3["Часть от администратора, часть в user context, всё смешивается"]
    d2 --> d4["Это проектирование прав, а не способ распространения"]

Рис. 22: Решение per-user / per-machine — проектирование прав, которое принимают первым.

8. Куда движется Windows в будущем

По состоянию на март 2026 года в Windows 11 есть функция Administrator protection (preview). В Microsoft Learn эта функция описывается как сохраняющая обычное непривилегированное состояние и предоставляющая права администратора точно в момент необходимости (just-in-time).⁵

Кроме того, Microsoft поясняет, что перед операциями, требующими прав администратора, — такими как установка ПО, изменение системных настроек вроде времени или реестра, доступ к конфиденциальным данным, — требуется явная аутентификация.⁵

Сама функция пока в статусе preview, и её массовое развёртывание тоже идёт поэтапно.⁵

Здесь стоит отдельно зафиксировать, что preview означает на практике. У функции с пометкой preview до общего выпуска могут смениться поведение и набор настроек, и её вообще не обязательно удастся включить во всех средах. Поэтому на данный момент безопаснее избегать такого использования:

• разворачивать как стандартную производственную конфигурацию на всю организацию
• опускать проектирование повышения прав в приложении, исходя из того, что функция уже включена
• делать эту функцию обязательным требованием к среде заказчика

Реалистичная позиция — проверить поведение в тестовой среде и подогнать только направление проектирования под то, что «система со временем клонится сюда». Иначе говоря, если сейчас держать asInvoker как базу и минимизировать повышение прав, к общему выпуску этой функции не придётся суетиться.

flowchart TB
    accTitle: Реалистичная позиция к preview-функции
    accDescr: У preview до общего выпуска могут смениться поведение и настройки, поэтому не стоит разворачивать её как производственный стандарт, опускать проектирование повышения прав или делать обязательным требованием. Реалистично проверить поведение в тесте и подогнать только направление проектирования.
    p1["Administrator protection пока preview"] -.-> p2["Избегать общеорганизационного развёртывания как производственного стандарта и обязательных требований"]
    p1 --> p3["Проверить поведение в тестовой среде"]
    p3 --> p4["Подогнать только направление проектирования под будущий сдвиг"]
    p4 --> p5["Если база asInvoker и повышение прав минимально, суетиться не придётся"]

Рис. 23: Preview не делают предпосылкой; подгоняют только направление проектирования.

Но направление довольно ясное.

• не держать токен администратора постоянно
• повышать права только в момент необходимости
• изолировать сессию с повышенными правами
• яснее фиксировать «когда, какое приложение и почему стало администратором»

Иными словами, разумно ожидать, что архитектура «на всякий случай запускать всё от имени администратора» будет всё хуже сочетаться с будущей Windows.

flowchart TB
    accTitle: Куда клонится Windows
    accDescr: Windows клонится к тому, чтобы не держать токен администратора постоянно, повышать права только в нужный момент, изолировать повышенную сессию и яснее фиксировать, когда какое приложение почему стало администратором. Проект «на всякий случай всё от имени администратора» будет стыковаться всё хуже.
    w1["Не держать токен администратора постоянно"] --> w2["Повышать права только в нужный момент"]
    w2 --> w3["Изолировать повышенную сессию"]
    w3 --> w4["Яснее фиксировать когда, какое приложение и почему стало администратором"]
    w4 -.-> w5["Проект «всё от имени администратора» стыкуется всё хуже"]

Рис. 24: Направление ясно: повышение прав — «только в нужный момент и явно».

9. Частые заблуждения

9.1 «Я пользователь-администратор, значит UAC появляться не должен»

Появляется. При включённом UAC даже у членов группы Administrators обычные процессы работают без повышения прав, повышаясь только при необходимости.⁶²

9.2 «Если это установка, права администратора обязательны»

Не обязательно. Как в случае установки per-user в %LocalAppData%, существуют архитектуры, позволяющие распространять приложение без прав администратора.¹¹¹²

9.3 «Раз приложение размещено в Program Files, настройки тоже можно хранить там»

Нет. Место размещения исполняемого файла и место хранения данных, изменяющихся во время выполнения, следует разделять. Microsoft тоже приводит запись во время выполнения в Program Files или HKLM как типичный пример ненужного повышения прав.⁴⁷

9.4 «Достаточно запустить от имени администратора, и все проблемы проектирования решатся»

Не решатся. Приложение может временно заработать, но поверхность атаки, эксплуатационность, распространение и удобство поддержки при этом обычно ухудшаются. Более того, удобно повысить права только для части одного и того же процесса тоже нельзя.²¹⁴

9.5 «Раньше работало, значит и сейчас правильно»

Не обязательно. Если старое 32-bit приложение всего лишь «случайно работало» благодаря виртуализации, проблема проявится при переходе на 64-bit или добавлении манифеста. Виртуализация — временная мера для совместимости, а не долгосрочное решение.³⁷

10. Итог

Нужны ли в Windows права администратора, одной фразой определяется тем, «куда и что именно вы собираетесь изменить».

• Изменения для себя обычно укладываются в права стандартного пользователя
• Изменения для всех пользователей / всей машины обычно требуют администратора
• Обращение к защищённым областям и границам безопасности ОС требует прав администратора

А по-настоящему важно на практике — разделять обработку, которой права администратора действительно нужны, и обработку, которой администратор понадобился просто из-за неудачного выбора места хранения.

Особенно в разработке Windows-приложений весьма эффективны следующие принципы.

• UI по умолчанию без повышения прав
• Административная обработка выносится в отдельный EXE / службу / задачу
• Данные времени выполнения размещаются в AppData / HKCU / ProgramData
• per-user или per-machine решается заранее

flowchart TB
    accTitle: Линии, которые работают в разработке Windows-приложений
    accDescr: UI по умолчанию без повышения прав, административную обработку выносят в отдельный EXE, службу или задачу, данные времени выполнения сдвигают в AppData, HKCU и ProgramData, per-user или per-machine решают первым. Эти линии на практике хорошо работают.
    g1["UI по умолчанию без повышения прав"] --> g2["Административную обработку выносят в отдельный EXE / службу / задачу"]
    g2 --> g3["Данные времени выполнения сдвигают в AppData / HKCU / ProgramData"]
    g3 --> g4["per-user / per-machine решают первым"]

Рис. 25: Если эти четыре линии провести сразу, и UAC, и распространение, и проектирование становятся гораздо понятнее.

«Нужны ли права администратора» — это вопрос не о том, насколько внушительно приложение. Это вопрос о том, к какой границе ОС оно обращается.

Если с самого начала держать в голове эту точку зрения, поведение UAC, выбор способа установки и проектирование приложения становятся намного понятнее.

11. Смежные статьи

• Как на практике выделить в Windows-приложении «только те операции, для которых нужны права администратора»
• Минимальный чек-лист безопасности при разработке Windows-приложений
• Как выбрать способ распространения Windows-приложения — MSI/MSIX/ClickOnce/xcopy/собственный updater

12. Источники

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Почему появляется сообщение «Для запрошенной операции требуются права администратора»?

Потому что приложение пытается затронуть границу, которая влияет на ОС или машину целиком. Типичные примеры — запись в защищённые области вроде Program Files, Windows, System32, HKLM, регистрация или изменение конфигурации служб Windows, установка драйверов ядра, изменение правил брандмауэра. Повышение прав запрашивается и тогда, когда в манифесте объявлен requireAdministrator, а также когда имя файла содержит install / setup / update и подобные слова и попадает под installer detection в Windows. Дело не в том, что обработка «сложная»: очень часто причина просто в том, что настройки или логи лежат в защищённой области.

Почему UAC появляется, даже если я вошёл под учётной записью администратора?

Потому что при включённом UAC даже процессы, запущенные членом группы Administrators, по умолчанию выполняются с правами обычного пользователя, если их специально не повысили. Учётная запись Windows может быть администраторской, но только что запущенное приложение работает без повышения прав, и UAC появляется лишь в момент операции, которой действительно нужны права администратора, — это штатное поведение Windows. Членство пользователя в группе Administrators и то, что приложение сейчас работает с токеном доступа администратора, — разные вещи, их нужно рассматривать раздельно.

Всегда ли установка приложения требует прав администратора?

Не обязательно. Для установки per-user в %LocalAppData% возможна архитектура, позволяющая распространять и обновлять приложение без прав администратора. Например, установка клиента Remote Desktop по схеме per-user размещается в LocalAppData каждого профиля и может обновляться без прав администратора, а OneDrive по умолчанию тоже ставится per-user. Права администратора чаще нужны для установки per-machine — для всех пользователей, — которая пишет в Program Files или HKLM. Выбор между per-user и per-machine — не просто способ распространения, а часть проектирования прав, поэтому его стоит решить в первую очередь.

Можно ли выполнять от имени администратора только часть операций приложения?

Нельзя сделать так, чтобы «в момент нажатия этой кнопки» отдельные методы внутри того же процесса становились административными. UAC определяется тем, с каким токеном работает процесс, а дочерние процессы наследуют токен родителя. Если это необходимо, нужно выделить отдельную единицу выполнения. Типичные модели четыре: Administrator Broker — UI обычного пользователя плюс вспомогательный EXE с правами администратора; Operating System Service — резидентная служба; Elevated Task — запланированное задание максимального уровня прав; Administrator COM Object — повышенный COM.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.