Одной из самых больших проблем с Software Restriction Policies была настройка доверенных издателей (Trusted Publishers), о которой я уже писал: Секреты Software Restriction Policies (часть 3). Другое, более элегантное решение лежало практически на поверхности, но я его никак не замечал. В кратце напомню проблематику:

Если у нас есть недозволенное подписанное приложение, то мы можем импортировать сертификат цифровой подписии в секцию Trusted Publishers для доверия конкретному издателю. Но кроме этого нам нужно обеспечить доверие сертификату подписи, путём размещения корневого сертификата в цепочке в секцию Trusted Root Certification Authorites пользовательского хранилища (User Store). Чтобы как-то защититься от этого, приходилось в политике SRP запрещать пользователям добавлять сертификаты цифровых подписей в секцию Trusted Publishers (делая её read-only). Это спасало от нечистых на руку пользователей, которые могли добавлять свои сертификаты и обходить политику. Однако, этот метод имел серьёзные негативные эффекты: переставал работать Windows Update на Windows XP/2003, останавливалась служба Windows Defender, невозможно было использовать продукты Live и др.

Сегодня блуждая по политикам наткнулся на ещё одну настройку, которая запрещает доверять сертификатам в пользовательском контейнере Trusted Root CAs! Для этого нужно открыть редактор групповой политики и перейти по пути:

Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> выбрать свойства Trusted Root CAs

и здесь убрать единственную галочку. В Windows Vista/2008 и выше эта настройка выделена в отдельный элемент. Вместо Trusted Root CAs элемент называется Certificate Paths Validation Settings:

Хоть пути до настроек чуточку отличаются, но суть от этого не меняется. Достаточно убрать эту галочку и получать профит. Так же, как и с паблишерами, секция Trusted Root CAs в пользовательском хранилище становится в режим Read Only. Причём, эта настройка удаляет все корневые сертификаты, которые были добавлены пользователями (т.е. существуют только в пользовательских хранилищах, но не в компьютерном), т.е. администраторам не надо будет заботиться о чистке пользовательских Cert Store, оно будет вычещенно само. Если попытаться импортировать корневой сертификат из файла, то получите вот такой бонус:

как вы видите, у нас нету больше возможности добавлять свои сертификаты в этот контейнер.

Примечание: данная настройка отсутствует в политике Windows XP

Кстати говоря, данная настройка в Windows 7/Windows Server 2008 R2 так же позволяет избежать атаки на правила издателя (Publisher) AppLocker'а путём подстановки своего корневого сертификата и запуска файлов с поддельной цифровой подписью.

Вот таким нехитрым способом мы можем значительно укрепить SRP и AppLocker от криптографических махинаций с цифровыми подписями. Хотя, это нас не спасёт от случаев, если сертификат подписи выдан публичным CA, которому система доверяет по умолчанию. В таком случае SRP можно защитить только через запрет установки своих паблишеров. А вот AppLocker спасти уже не удастся :(

з.ы. на днях я ВНЕЗАПНО узнал о существовании такой мега-завальной штеллы как Snipping Tool, который поставляется вместе с Windows Vista и выше для создания скриншотов нужных окон! За 2,5 года использования висты я ни разу его так и не запустил, из-за чего приходилось извращаться через Paint, что было несколько уныло, зато у меня теперь есть удобный инструмент для снятия пруфпиков и ещё один веский повод сказать, что Vista рулит! :rock:

Вася Гусев прислал мне одну замечательную ссылку на пост (а в посте ссылка на документ) Дмитрия Буланова по управлению AppLocker'ом с использованием Windows PowerShell: http://dimanb.spaces.live.com/blog/cns!7D6C59DEE1DA79E5!323.entry

В принципе, это хорошо, т.к. мне уже, возможно, не понадобится об этом писать. Однако, я не разделяю такого оптимизма автора документа (кстати говоря, авторство принадлежит не Дмитрию, а только перевод. Причём, бездарный перевод) и считаю, что такая поддержка со стороны PowerShell ещё ниже опускает уровень защиты AppLocker. Но и сам документ выглядит как типичный маркетинговый булшит, поскольку содержит несколько ложных утверждений и достаточно много подтасованных фактов. Давайте посмотрим документ внимательней:

Уже несколько лет администраторам в организациях приходилось устанавливать стороннее программное обеспечение, за что организациям приходилось тратить немалые средства. Теперь с появлением AppLocker у администраторов нет необходимости в поиске стороннего программного обеспечения, т.к. с появлением Windows 7 и Windows Server 2008 R2 AppLocker добавлен в групповые политики.

При этом автор очень сильно недоговаривает, поскольку SRP существует ещё с 2001 года (когда вышел RTM Windows XP). Т.е. раньше тоже были средства контроля используемых приложений.

Часто со временем, после развертывания операционных систем, конфигурация программного обеспечения типичного рабочего места оказывается далека от желаемого результата. Несогласованности приходят чаще, не столько от установки, сколько от работы несоответствующего стандартам программного обеспечения в пределах настольного окружения. Пользователи инсталлируют программное обеспечение из разнообразных источников: компакт-дисков и дисковых накопителей, загрузки файлов из сети Интернет, совместного использования файлов через совместные пиринговые сети, и через электронную почту. Результат – возможность заражения компьютера вредоносным программным кодом

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

Software Restriction Policies (SRP), в Windows XP и Windows Vista, было одним из первых решений прикладного контроля. SRP дал IT-администраторам грубый механизм, для определения и написания политик контроля за приложениями. Однако SRP мог ограничить управление в динамической настольной среде, где приложения устанавливались и обновлялись на постоянной основе, т.к. они в основном использовали правила хэширования. С правилами хэширования, каждый раз при обновлении программного обеспечения необходимо было создавать новые правила хэширования.

Враньё! Особенно выделенное. В ряде моментов SRP более гибок, чем AppLocker. Если говорить про правила хешей, то AppLocker вносит только одно удобство – позволяет за раз добавить несколько файлов в правило хеша из одной папки. Но дальше в этом плане ничем не отличается от SRP. А с правилами путей профитов в AppLocker по сравнению с SRP почти и нету, поскольку в правилах путей как правила используются wildcards, вместо полных путей до конечного файла. Про паблишеров я отмечусь чуть ниже.

С появлением AppLocker в операционной системе Windows 7 растет необходимость введения решений прикладного контроля на предприятии: простой и гибкий механизм, который позволяет администраторам конкретизировать разрешения для запуска программного обеспечения в своей программной среде. В результате, AppLocker обеспечивает не только защиту безопасности, но и оперативность и удобство по развертыванию политик

Этим автор ещё раз доказывает своё мнение, что до AppLocker'а у нас был ад и Израиль и у нас не было SRP. И прочитайте выделенное. Мне это говорит, что наоборот, AppLocker – источник всех проблем. Не будь его, не росла эта необходимость. В чём оперативность здесь – мне пока непонятно. Да, и что есть прикладной контроль? Есть мнение, что это от английского Application Control (жертва пиратского промпта? © Artem Pronichkin).

1. Ограничение в запуске нелицензионного программного обеспечения на рабочем месте;
2. Понижение уязвимости, средствами запрещения запуска несанкционированных приложений на вашем рабочем месте, в том числе запуск вредоносного кода;
3. Запрещать пользователям запуск приложений, которые бесполезно потребляют сетевую пропускную способность;
4. Ограничение пользователей от запуска приложений, которые дестабилизируют их рабочую среду;
5. Эффективность конфигурации управления;
6. Позволять пользователям устанавливать и запускать одобренное администратором программное обеспечение основанное на деловых потребностях;
7. Гарантировать, согласованность установки программного обеспечения с корпоративными политиками и правилами, например PCI DSS, Sarbanes-Oxley, HIPAA, Basel II, и другое.

пункт 3 - покажите!!! Как? Я тоже хочу использовать такую функциональность! Т.е. создавать правила на основе критериев: только приложения, которые полезно потребляют пропускную способность сети. В последнем пункте заметил несколько новых слов, значения которых я не знаю. Подозреваю, что основная целевая аудитория документа тоже не сильно владеет такими терминами.

Но вообще все эти пункты укладываются в более короткий список:

• Контроль запуска только разрешённых администратором приложений. Что исключает возможность несанкционированного запуска потенциально опасного, вредного или лишнего ПО.

Размазывать единственное предназначение AppLocker'а (равно как и SRP) на 7 пунктов незачем. Разве что – задавить читателя массой возможностей нового продукта.

разрешения, запрещения и исключения

в русском языке вряд ли есть такое слово, как “запрещения”. Правильнее будет “запрет”. Промпт переводит как умеет…

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

в этом предложении я ничего не понял, кроме “белый список приложений”.

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

Хотелось бы мне знать, чем в данном случае явный запрет будет отличаться от отдельного запрета? Технически это одно и то же. Т.е. если мы одним правилом накрываем достаточно большую область, в которой нужно создать исключения, то создание исключения или отдельного запрета будет равноценным, поскольку тут так же работает правило приоритета более точного правила. А SRP этим не обделён ни разу.

AppLocker вводит правила издателя, которые основаны на прикладных цифровых подписях. Правила издателя дают возможность создания правил, которые включают возможность обновления программного обеспечения. Например, организация может создать правило, чтобы “разрешить все версии, большие, чем 9.0 для запуска Acrobat Reader, если у программного обеспечения Adobe есть цифровая подпись”. После чего, когда у Adobe появится новая версия Acrobat, вы можете безопасно запустить обновление программы без необходимости создания нового правила для последующей версии приложения.

Вот здесь снова появляется ложь. Правила издателя были в SRP, только немного в ином виде (Certificate Rule). Опять же, следует учитывать, что вы можете использовать эту возможность только при условии, что у файла есть цифровая подпись. Нету подписи – вот вам пачка хешей, работайте. Плюс, как я уже упоминал, AppLocker не закрывает одну опасную брешь в концепции цифровых подписей – не проверяется доверие конкретной цифровой подписи. Кто угодно может прочитать правило паблишера (да-да, именно средствами родного PowerShell, поскольку других вменяемых средств нету) и подписать свой файл своей же подписью, которую AppLocker скушает и разрешит для запуска. Вобщем, разработчики AppLocker'а допустили 2 фатальные ошибки, из-за которых эти профиты могут просто потерять реальный практический смысл:

1. совершенно испоганили правило издателя (publisher), отменив проверку доверия конкретной цифровой подписи;
2. разрешили пользователям со стандартыми правами (standard user) читать все настройки этой политики.

Поэтому эти 2 пункта следует рассматривать не как бенефиты AppLocker'а, а как его недостатки в контексте безопасности. Это было сделано в пользу удобства и в ущерб безопасности. И это не говоря о том, что не все редакции Windows 7 могут использовать эту политику.

Правила AppLocker могут быть ассоциированы с конкретным пользователем или группой в пределах организации. Это обеспечивает гранулирование контроля, что позволяет вам поддерживать требования компании и предписания благодаря которым пользователи могут управлять специфическими приложениями. Например, вы можете создать правило, чтобы “разрешить сотрудникам Отдела Финансов управлять линией приложений, которые относятся к их деятельности”. Эти приложения блокируются от запуска для всех пользователей, которые не находятся в Отделе Финансов (в том числе администраторы), но все еще обеспечивают доступ для тех, у кого есть надобность управлять данными приложениями.

На самом деле это тоже не прорыв. Подобная реализация на уровне групп пользователей была и в SRP, поскольку SRP можно было конфигурировать в секции User Configuration и фильтровать политику с помощью Security Filtering. Т.е. данный функционал был чуть причёсан и сделан более user-friendly.

Благодаря AppLocker в Windows 7, у администраторов появляется возможность контроля за приложениями пользователей.

Ещё раз отмечаю, что AppLocker в этом отношении не единственный бесплатный инструмент.

Вобщем, мой совет читателям – избегать подобных переводов, как ересь и ЛПП, поскольку промпт никогда (во всяком случае – в обозримом будущем) не сможет переводить тексты со смыслом и именно тем смыслом, который заложен в оригинале. Поэтому предлагаю ссылки на оригинальные статьи, которые были переведены в этом документе:

• Windows 7 AppLocker Executive Overview
• Getting Started with AppLocker management using Powershell

Спасибо за внимание :-)

Disclaimer: данный пост несёт исключительно теоретическую ценность. Никакой практической пользы от него вы не получите.

Блуждая по просторам интернетов, наткнулся на один свой пост, который уже похоронен в истории веков.

Как известно, при доступе к общим ресурсам (сетевым папкам) мы различаем 2 типа прав:

• Share Permissions
• NTFS Rights

Оба типа прав влияют на результирующие (эффективные) права пользователя при доступе к сетевому ресурсу. В общем смысле эффективные права будут являть собой наиболее ограничивающее разрешение из обоих типов прав. Например, на ресурс установлено право Share Permissions = Read, а NTFS = Full Control, то исходя из наиболее ограничивающего разрешения эффективным будет Read. Если Share Permissions = FullControl, а NTFS = Modify, то эффективным правом для пользователя будет Modify. Вот такая несложная схема. Т.е. там, где прав меньше, те и будут ваши :-) Как известно, эта проблема редко кого касается, т.к. обычно на уровне Share Permissions выдают FullControl на ресурс и дальше уже права регулируют за счёт NTFS. Как бы всё правильно, но если раскопать вопрос глубже, то появляются интересные моменты.

http://technet.microsoft.com/en-us/library/cc784499(WS.10).aspx – по этой ссылке можно найти сопоставление Share Permissons с NTFS Rights. Такое сопоставление удобно тем, что рассчитывать оба типа прав можно с использованием одних и тех же классов .NET, без необходимости городить отдельные библиотеки и классы для управления списками доступа ACL. Грубо говоря, фактическое сопоставление выглядит вот так (по схеме Share Permission = NTFS Right):

• Read = ReadAndExecute
• Change = Modify + DeleteSubfoldersAndFiles
• FullControl = FullControl

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

• Read = ReadAndExecute + Synchronize
• Change = Modify + DeleteSubfoldersAndFiles + Synchronize
• FullControl = FullControl (в обоих случаях Synchronize уже включено).

Обратите внимание на наличие DeleteSubfoldersAndFiles в Change. Windows оба этих типа прав рассчитывает через класс .NET – FileSystemRights и фактически их содержит не в текстовом виде, а в числовом. Вот как выглядят числовые сопоставления текстовым правам:

[↓] [vPodans] ([system.enum]::getnames([System.Security.AccessControl.FileSystemRights])) | %{@{$_ = ([System.Securit
y.AccessControl.FileSystemRights]"$_").value__}}

Name                           Value
----                           -----
ListDirectory                  1
ReadData                       1
WriteData                      2
CreateFiles                    2
CreateDirectories              4
AppendData                     4
ReadExtendedAttributes         8
WriteExtendedAttributes        16
Traverse                       32
ExecuteFile                    32
DeleteSubdirectoriesAndFiles   64
ReadAttributes                 128
WriteAttributes                256
Write                          278
Delete                         65536
ReadPermissions                131072
Read                           131209
ReadAndExecute                 131241
Modify                         197055
ChangePermissions              262144
TakeOwnership                  524288
Synchronize                    1048576
FullControl                    2032127


[↓] [vPodans]

Как видно из таблички, FullControl является суммой всех перечисленных прав. Давайте разберём, что такое Modify, т.е. какие права нужно иметь для получения этого Modify:

• ListFolder - 1
• CreateFiles - 2
• Createfolders(Directories) - 4
• ReadExtendedAttributes - 8
• WriteExtendedAttributes - 16
• Traverse - 32
• ReadAttributes - 128
• WriteAttributes - 256
• Delete - 65536
• ReadPermissions – 131072

В этом легко убедиться, т.к. если мы сложим все эти цифры, то получим 197055 (как и отражено в таблице). Обратимся к ссылке: http://vpodans.spaces.live.com/blog/cns!BB1419A2CFC1E008!170.entry.

Теперь нам нужно преобразовать права доступа в класс FileSystemRights. Преобразование типа прав так же было ранее мною описано в первой части Управление ACL в PowerShell. Пара слов о том, чем отличаются права Read, Change и Full Control в контексте разрешений сетевого ресурса от контекста разрешений NTFS. Этим правам в NTFS сопоставляются Read + Execute, Modify и Full Control соответственно и плюс право Synchonize. Поэтому давайте запишем маску доступа в переменную $ace:

$ace.AccessMask = [System.Security.AccessControl.FileSystemRights]"Modify, Synchronize"

Чтобы получить Change, нам достаточно к этому числу (197055) прибавить Synchronize (1048576):

[↓] [vPodans] ([System.Security.AccessControl.FileSystemRights]"Modify, Synchronize").value__
1245631

Вот это в понимании SecurityDescriptor является эквивалентом нашего Change. Но я чуть ранее просил вас обратить внимание на наличие DeleteSubfoldersAndFiles в Change. Но тут его уже всунуть просто некуда, т.к. 1245695 (это число получится, если к Modify прибавить Synchronize и DeleteSubfoldersAndFiles) не будет распознано SecurityDescriptor’ом в методе SetShareInfo, как валидное число.

Иными словами, что у нас получается:

1) Change в понимании фактических прав является суммой: Modify + DeleteSubfoldersAndDiles + Synchronize

2) Change в понимании .NET является суммой: Modify + Synchronize

И чем вызвано такое несоответствие мне неизвестно. Но в качестве теоретической справки это может быть полезным.

Короткая заметка.

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

• единая точка управления;
• охват множества компьютеров, совершая минимум движений;
• читабельность настроек и возможность их сохранения/восстановления;
• если настройки на какой-то машине были сбиты или изменены – политика перезапишет изменения на значения, которые установил администратор в групповой политике.

Однако, не везде у нас есть возможность использования такой настройки через GP, поскольку такая настройка есть только в ОС, в которых PowerShell поставляется по умолчанию – это Windows Server 2008, Windows Server 2008 R2 и Windows 7. Для остальных ОС такой настройки нету в политиках. Но не всё так плохо, как может показаться:

>> Administrative Templates for Windows PowerShell <<

Вам достаточно установить этот шаблон на компьютер, с которого вы управляете групповыми политиками. Данная политика будет размещена в секции: Computer Configuration –> Administrative Templates –> Windows Components –> Windows PowerShell.

Этот шаблон устанавливается на ОС не ниже Windows XP.

Disclaimer: данный материал публикуется только для ознакомительных целей и не рекомендуется для использования в реальной производственной среде.

Краткий ввод в курс дела. Что такое EV сертификат – это Extended Validation сертификат, который в браузере отображается зелёной полосой:

Что это означает? Это означает, что издатель сертификата (например, VeriSign) более серьёзно и внимательно изучил предъявителя этого сертификата, что даёт пользователям ещё большую гарантию, что сайт, на который вы попали, является тем самым сайтом, который вы набрали в адресной строке. А так же этим подтверждается, что сайт является зарегистрированной коммерческой организацией с сопутствующими проверками. Т.е. к получателю Extended Validation сертификатов предъявляются достаточно жёсткие требования. Эти сертификаты в Public Certification Authorities стоят значимо дороже, чем обычные SSL сертификаты (я посмотрел по предложениям и получилось в среднем увеличение цены в 2 раза). Плюс, такие сертификаты не имеют возможности использования WildCard доменов в Subject, хотя допускают Subject Alternative Names (когда одному web-сайту сопоставляется несколько имён). Такие сертификаты в интернете могут выпускать только одобренные центры сертификации (Certification Authorities). Список таких CA можно посмотреть вот здесь: http://cabforum.org/forum.html. Требования к работе с такими сертификатами для CA и покупателей: http://cabforum.org/documents.html

Но это всё лирика. Мы хотим внутри корпоративного домена поднять SSL веб-портал и чтобы там была такая же зелёная полоска :-) и мы можем такое сделать. Я покажу процесс на примере CA и домена под управлением Windows Server 2008 R2. Я предполагаю, что у вас уже развёрнут домен Active Directory и установлена роль AD CS (Active Directory Certificate Services).

Когда у нас предварительные подготовления закончены нам нужно произвести необходимые изменения в шаблоне Web Server. Для этого нужно сделать следующее:

1. на сервере с установленным CA запустить оснастку Certificate Templates: certtmpl.msc
2. выбрать шаблон Web Server и правой кнопкой выбрать Duplicate Certificate и выбрать версию шаблона 2 или 3 (Windows Server 2003 Enterprise Edition или Windows Server 2008 Enterprise Edition, соответственно).
3. В поле Template Display Name напишите новое имя шаблону (например, Web Server V2 или V3).
4. Убедитесь, что срок действия сертификатов на основе этого шаблона установлен 1 год (обычно для SSL веб-сайтов не выдают сертификаты на срок больше 1 года).
5. На вкладке Extensions выберите Issuance Policies –> Edit –> Add –> New:
    
   и скопируйте сгенерированный OID в поле Object Identifier, он нам ещё потребуется.
   
6. Напишите название вашей политики и адрес CPS (Certificate Practice Statement).
7. На вкладке Request Handling настройте свои значения (как экспорт закрытого ключа, архивация закрытого ключа) на своё усмотрение.
8. На вкладке Issuance Requirements поставьте ручное одобрение администратора CA (чтобы контролировать расход EV сертификатов :-), либо на вкладке Security отрегулируйте разрешения, кому можно запрашивать сертификат.
9. Сохраните шаблон.

Теперь раскройте оснастку Certificate Authority и перейдите в Certificate Templates –> New –> Template To Issue и выберите наш новый шаблон. После того, как все приготовления закончены, можно приступать к редактированию групповой политики.

Примечание: Для редактирования политики вам потребуется консоль GPMC в Windows Server 2008 R2, Windows 7 с установленным RSAT. При этом версия ОС на контроллере может быть другой, но не ниже Windows Server 2003, а сервер CA не ниже Windows Server 2003 Enterprise Edition.

Запустите оснастку GPMC и создайте новую политику, которая будет прилинкована на уровне домена. Безусловно, вы можете редактировать существующую Default Domain Policy, но я не рекомендую использовать дефолтную политику, а для каждой задачи создавать свою политику и линковать куда нужно. В редакторе политики перейдите по секции:

Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Public Key Policies –> Trusted Root Certification Authorities

здесь выберите All Task –> Import и импортируйте корневой сертификат вашего CA, который является корневым в вашем лесу. Далее, выберите свойства сертификата (не открывать сам сертификат) и перейдите в таб Extended Validation:

И добавьте сюда тот самый OID, который у вас был сгенерирован при создании новой Issuance Policy.

Теперь вам нужно перейти на ваш web-сервер. Если это Windows Server 2003, то вы можете запросить новый SSL сертификат из оснастки IIS. Если у вас web-сервер под управлением Windows Server 2008 или выше, то вы не можете больше запрашивать SSL сертификат из оснастки IIS, а только путём генерирования запроса в формате PKCS#7, либо через MMC оснастку Certificates запущенной от лица Local Computer. Запросите новый сертификат на основе вновь созданного шаблона (желательно при запросе указывать наиболее подробные сведения о вашем Web-сервере). Если у вас в политике шаблона указано ручное одобрение запроса – одобрите его в оснастке Certification Authority –> Pending Requests. После того, как сертификат сгенерирован, настройте ваш веб-сервер на работу с SSL с использованием этого сертификата.

Теперь подождите, пока отредактированная групповая политика применится на компьютерах домена. После чего запустите браузер на любом клиенте (не ниже Windows XP SP2 с установленным Internet Explorer 7 или выше) и наберите HTTPS адрес вашего веб-сервера и получайте профит:

И ещё раз о требованиях к операционным системам:

• Domain Controller – не ниже Windows Server 2003 Standard Edition. Для редактирования политики потребуется Windows 7 с RSAT или рядовой член домена под управлением Windows Server 2008 R2 с установленным компонентом Group Policy Management.
• CA – не ниже Windows Server 2003 Enteprise Edition (Кроме Windows Server 2003/2008 Standard/Web Edition).
• веб-сервер – любой.
• клиентский компьютер – не ниже Windows XP SP2 и с установленным Internet Explorer не ниже 7 версии.

И ещё раз напоминаю, что это будет видно только тем компьютерам, которые получили изменённую политику. Остальные компьютеры будут видеть обычный замочек и всё.

Have a nice day!