Разное

Парольная защита: Общий доступ с парольной защитой Windows 10: как отключить и проблемы

Содержание

Защита информации с помощью паролей — Cogito, ergo sum

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

Чтобы основательно погрузиться  в проблему, вернемся на десять лет назад.

Эволюция самых популярных паролей.

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

  • 16% использовали собственное имя;
  • 12% использовали слово «password»;
  • 11% использовали название любимой спортивной команды;
  • 8% использовали дату рождения.

Прошло десять лет (с). В начале 2013 году в Лаборатории Касперского провели свое исследование с тем же вопросом, но уже в 25 странах.

Картинка немного изменилась:

  • 16% используют собственную дату рождения;
  • 15% используют сочетание цифр «123456»;
  • 6% используют слово «password» на местном языке;
  • 6% используют кличку домашнего животного.

Отклонения от данных в 2003 года в пределах статистической погрешности. А в конце 2013 года у Adobe произошла утечка данных 150 миллионов паролей, чем не преминули воспользоваться исследователи информационной безопасности.  Компания SplashData проанализировала миллионы паролей в свободном доступе и составила список самых популярных паролей 2013 года. В итоге получилось интересно и предсказуемо:

  • 123456
  • password
  • 12345678
  • qwerty
  • abc123
  • 123456789
  • 111111
  • iloveyou
  • adobe123
  • 123123
  • Admin1234
  • password1

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

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

Простые правила составления паролей

  1. «Один пароль — один ресурс»  — это хорошее правило. Но опять же в силу современных условий — неудобное. Необходимо разделять ресурсы на корпоративные, чувствительные и мусорные. Для корпоративных и чувствительных ресурсов пароли следует следовать принципу «один ресурс — один пароль».  Для мусорных и одноразовых интернет-ресурсов, можно применять  отдельный либо временный почтовый ящик и более ли менее защищенный пароль.
  2. Как и в 2003 году требования на минимальную длину в 15 символов остаются актуальными и на сегодняшний день. Раньше это было связано с одной полезной особенностью, что пароли более 15 символов некорректно сохранялись в LM хэше, что  существенно затрудняло его подбор. Сегодня все намного прозаичнее: распределенные вычисления и проброс вычислительной мощности на GPU, что позволяет перебирать около пары миллиардов значений в минуту.
  3. Не сохраняйте пароли, храните cookies и сессии до закрытия браузера. Так например существовала уязвимость в Safari, которая хранила пароли не зашифрованными.
  4. Стандартные правила составления паролей:
  • пароль не должен содержать части пользовательского имени;
  • символы латинского алфавита в разных регистрах;
  • цифры от 0-9;
  • специальные символы;
  • буквы вместо цифр. Популярное  решение сокращения букв из эпохи SMS: «F»-«4» и так далее.

       5. Регулярная смена паролей. На чувствительных ресурсах раз в месяц, на остальных  — раз в два месяца.

       6. Пароль — это ваша личная тайна.

 

Проблема запоминания паролей

Не могу запомнить — основная отмазка/проблема всех пользователей, и как результат: «записывание и приклеивание».

 

1. Парольные фразы

Когда у моего брата, нехорошие люди вскрыли аккаунт в одной из популярных российских социальных сетей, я спросил у него про  пароль. Ответом был вышеприведенный популярный список и фраза «Я не могу запомнить». Некоторые системные администраторы этому всячески способствуют, выдавая зубодробительные варианты из генератора паролей. Если на системного администратора повлиять сложно — рабочие инструкции, то в обычной жизни крайне удобным способом являются парольные фразы.  Далеко ходить не нужно, только в песненке «В лесу родилась елочка»  содержится 24 парольные фразы. Добавьте еще пару цифр и букв разными регистрами  и получится отличный пароль.  Так что любимая песня или стихотворение станут отличным подспорьем.

 

2. Парольные менеджеры

Для тех у кого плохая память или плотно сидящая на шее лень, существует специальное программное обеспечение — парольный менеджер. Задачей парольного менеджера служит создание криптоконтейнера с доступом по одному, так называемому мастер паролю. На рынке таких программ достаточно много, как для Windows, OS X, Linux.  Обзоров парольных менеджеров делать не буду ибо они, все как на одно лицо: криптоконтейнер, напоминания о смене пароля, генератор паролей по заданному алгоритму, автозаполнение форм, автологин.  Поэтому приведу описания тех которыми пользовался:

  • Kaspersky Password Manager. Однозначно нужная вещь для техноманьяков. Доступ к паролям с помощью мастер-пароля, USB-токена, bluetooth устройство. Стоит недорого, сам использую при работе с Windows.
  • Norton Password Manager&Online Identify Security. Американское изделие для простых пользователей.  Попроще, но зато бесплатное. Есть мобильное приложение и возможность хранения в облаке, чего делать определенно не стоит.
  • 1Password. Самый популярный парольный менеджер для OS X и iOS. Существует версия для каноничного PowerPC, начиная с Tiger 10.4 и плагины для встраивания в браузер. Есть мобильная версия.
  • Очумелые ручки. Если мучает паранойя или не охота платить, то пользователи OS X могут создать шифрованный . dmg, а пользователи Windows/Linux  шифрованный TrueCrypt  образ диска. Запускаем Office/LibreOffice, ставим пароль на открытие созданного файла и самодельный парольный менеджер готов.
  • Пользователям Linux парольный менеджер не нужен ибо осиливший консоль, осилит остальное.

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

 

3. Отсутствие желания защищаться

Существуют такие персонажи, которым все «по барабану». Обычно аргументируется это тем, что: мне нечего скрывать / я честный человек / я не несу никаких потерь. Эти аргументы не заслуживают никакого внимания или уважения. Попытайтесь донести человеку то, что в его контакт-листе или в списке адресатов,  ни он один.  Намеренно подставляя себя, он подставляет и раскрывает остальных друзей, близких.

 В повседневной жизни общение с человеком можно свести к телефону или скайпу.

 

Гораздо хуже, если такой персонаж заводится в компании.  «Законных» методов решения этой проблемы не существует. Если сотрудник является обычный офисным мусором, то пары предупреждений с последующим увольнением будет достаточно. Но в жизни случается так, что попадается особо ценный сотрудник, которого толкования, о данном аспекте,  тоже упорно не желают беспокоить.

У меня было пару подобных случаев и решились они методом предупреждения с «подставой», в виде «раскрытия информации по контрактам» или раскрывался не особо чувствительный кусок служебно-личной переписки с интересными подробностями рабочей жизни персонажа. Человек морально садился в лужу и ситуация для него, уже не казалась не заслуживающей внимания. Один раз после такого сценария, на всех парах примчался молодой гений продаж и попросил поставить все, начиная от отдельного шифрованного раздела сетевого диска, заканчивая USB-токеном на загрузку.

 Если и это не срабатывало, то увольнение.

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

 

Двухфакторная аутентификация

С развитием интернет-сервисов и глобального внедрения становится модной и актуальной двухфакторная аутентификация. Работает эта технология довольно просто. Ваш аккаунт сервиса привязывается к телефонному номеру, вводится логин/пароль и на указанный номер приходит дополнительный «уникальный пароль». Такое решение позволяет значительно усилить защиту аккаунта.  Но если,  под рукой не будет смартфона или резервных кодов на бумаге, то в доступе будет отказано.

 

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

Понравилось это:

Нравится Загрузка. ..

Похожее

Уроки 8 — 9§1.4. Защита от несанкционированного доступа к информации




§1.4.1. Защита с использованием паролей




Содержание урока

§1.4. Защита от несанкционированного доступа к информации. §1.4.1. Защита с использованием паролей

§1.4. Защита от несанкционированного доступа к информации. §1.4.2. Биометрические системы защиты

§1.5. Физическая защита данных на дисках

Практическая работа 1.7. Биометрическая защита: идентификация по характеристикам речи


Защита с использованием паролей

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

При этом может производиться регистрация всех попыток несанкционированного доступа.

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

Рис. 1.15. Вход по паролю в BIOS Setup

Защита с использованием пароля используется при загрузке операционной системы (при загрузке системы каждый пользователь должен ввести свой пароль) (рис. 1.16).

Рис. 1.16-1. Ввод пароля в операционной системе Windows

Рис. 1.16-2. Ввод пароля в операционной системе Linux

От несанкционированного доступа может быть защищен каждый диск, папка или файл локального компьютера. Для них могут быть установлены определенные права доступа (полный доступ, изменение, чтение, запись и др.), причем права могут быть различными для различных пользователей (рис. 1.17).

Рис. 1.17. Установка прав доступа к папке в операционной системе Windows


Контрольные вопросы

1. Как защищается информация в компьютере с использованием паролей?

Следующая страница §1.4. Защита от несанкционированного доступа к информации. §1.4.2. Биометрические системы защиты

Cкачать материалы урока

защита паролем, шифрование, разграничение прав доступа.

Методы защиты баз данных в различных СУБД несколько отличаются друг от друга. Анализ современных СУБД фирм Borland и Microsoft показывает, что они условно делятся на две группы: основные и дополнительные.

К основным средствам защиты относится:

— защита паролем;

— шифрование данных и программ;

— разграничение прав доступа к объектам базы данных;

— защита полей и записей таблиц БД.

Защита паролем представляет собой простой и эффективный способ защиты БД от несанкционированного доступа. Пароли устанавливаются пользователями или администраторами БД. Учет и хранение паролей выполняется самой СУБД. Обычно, пароли хранятся в определенных системных файлах СУБД в зашифрованном виде. После ввода пароля пользователю СУБД предоставляются все возможности по работе с БД.

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

Более мощным средством защиты данных от просмотра является их шифрование. Шифрование – это преобразование читаемого текста в нечитаемый текст, при помощи некоторого алгоритма; применяется для защиты уязвимых данных.

Процесс дешифрования восстанавливает данные в исходное состояние.

В целях контроля использования основных ресурсов СУБД во многих системах имеются средства установления прав доступа к объектам БД. Права доступа определяют возможные действия над объектами. Владелец объекта (пользователь, создавший объект), а также администратор БД имеют все права. Остальные пользователи к разным объектам могут иметь различные уровни доступа. Разрешение на доступ к конкретным объектам базы данных сохраняется в файле рабочей группы.

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

По отношению к таблицам могут предусматриваться следующие права доступа:

— просмотр (чтение) данных;

— изменение (редактирование) данных;

— добавление новых записей;

— добавление и удаление данных;

— изменение структуры таблицы.

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

Защита данных в полях таблиц предусматривает следующие уровни прав доступа:

— полный запрет доступа;

— только чтение;

— разрешение всех операций (просмотр, ввод новых значений, удаление и изменение).

По отношению к формам могут предусматриваться две основные операции:

— вызов для работы и проектирование (режим Конструктора). Запрет вызова Конструктора целесообразно выполнять для экранных форм готовых приложений, чтобы конечный пользователь случайно не изменил приложение;

— защита отдельных элементов. Например, некоторые поля исходной таблицы вообще могут отсутствовать или скрыты от пользователя, а некоторые поля — доступны для просмотра.

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

К дополнительным средствам защиты БД можно отнести такие, которые нельзя прямо отнести к средствам защиты, но которые непосредственно влияют на безопасность данных. Их составляют следующие средства:

— встроенные средства контроля значений данных в соответствии с типами;

— повышения достоверности вводимых данных;

— обеспечения целостности связей таблиц;

— организации совместного использования объектов БД в сети.

 

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

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

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

Повреждение базы данных может проявляться при попытке пользователя открыть, сжать, зашифровать или дешифровать БД. При наличии повреждений базы данных, созданной в СУБД Access, для ее восстановления необходимо:

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

— создать резервную копию базы данных;

— выполнить команду Сервис / Служебные данные / Восстановить;

— указать имя папки и файла восстанавливаемой базы данных.

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

Резервная копия может быть точной копией исходной БД или сжатой (архивной) копией. Сжатие может осуществляться аппаратно или программно. Аппаратное сжатие предпочтительно с точки зрения временных затрат на эту операцию, но увеличивает стоимость аппаратной части.

Резервное копирование может осуществляться во время работы с БД (режим online) или в другое время. Копия может создаваться по инициативе оператора, либо автоматически в заданное время путем запуска соответствующей утилиты.

При организации резервного копирования администратор решает такие вопросы как:

— какие устройства выбрать для резервного копирования;

— когда и с какой частотой выполнять резервное копирование.

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

Репликация (replication) – создание специальных копий (реплик) базы данных, с которыми пользователи могут работать одновременно на разных рабочих станциях.

Журнал транзакций БД — это особая часть БД, недоступная пользователям СУБД, в которую посту­пают записи обо всех изменениях основной части БД. Для эффективной реализации функции ведения журнала изменений БД необходимо обеспечить повышенную надежность хранения и поддержания в рабочем состоянии са­мого журнала. Иногда для этого в системе хранят несколько ко­пий журнала. В разных СУБД изменения базы данных фикси­руются в журнале на разных уровнях. Иногда запись в журнале соответствует какой-то операции изменения БД (на­пример, операции удаления строки из таблицы реляционной БД), а иногда — минимальной внутренней операции модификации страницы внешней памяти. В некоторых схемах используются оба подхода одновременно.

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

Откат отменяет изменения, произведенные в базе дан­ных ошибочными или незавершенными транзакциями. Затем повторно запускаются транзакции, которые выполнялись в мо­мент возникновения сбоя.

 

 

Читайте также:

 

Недостатки парольной аутентификации

Как показывает статистика, 84% пользователей не против отказаться от паролей, как средства доступа к важной информации. Большинство опрошенных респондентов выступили за использование альтернативной формы верификации. Многие предпочитают вводу пароля сканирование отпечатков пальца.

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

Недостатки парольной аутентификации

Опрос пользователей подтвердил мнение специалистов по безопасности. Около половины опрошенных пользуются одним и тем же паролем для осуществления доступа к совершенно разным системам — как к личным аккаунтам на сайтах, так и в корпоративной сети. Многие из них осознают, что такой подход категорически противопоказан для защиты конфиденциальной информации и других немаловажных данных. Утечка пароля, в таких случаях, может навредить информации сразу на нескольких ресурсах.

Недостаток пароля проявляется и, благодаря, человеческому фактору. Из опрошенных, 77 % пользователей записывают пароли на бумажках, что является критически небезопасным. В основном, на такие поступки их побуждают сайты и системы, которые в целях безопасности, периодически требуют заменить пароль, или принуждают пользователей формировать пароль не по привычной схеме, а по предлагаемым шаблонам.

Главный недостаток парольной аутентификации — это возможность передачи пароля другому лицу, что происходит довольно часто. И если в личной жизни страдает от таких поступков лично пользователь, то в корпоративных сетях это несет финансовую, юридическую и репутационную угрозу самой компании.

Эффективная аутентификация

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

Ответы на вопрос «17. Парольная схема защиты.»

По функциональному назначению парольный вход используется:

— для контроля загрузки системы;

— контроля функционирования;

— с целью блокировки.

С целью контроля загрузки может устанавливаться процедура идентификации и аутентификации пользователя перед началом загрузки системы, например, встроенными средствами BIOS. В этом случае выполнить загрузку системы сможет только санкционированный пользователь.

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

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

Для решения задачи контроля функционирования вычислительной системы выделяются:

  1. Контроль пользователя при доступе в систему. Реализуется в том числе штатными средствами ОС.
  2. Контроль при запуске процесса. Благодаря этому при запуске некоторых приложений может быть установлена парольная защита. Прежде всего, здесь интерес представляет установка пароля ответственного лица, например, начальника подразделения.
  3. Контроль при доступе к локальным ресурсам. Например, при доступе к локальному принтеру и т.д. также может использоваться аутентификация ответственного лица.
  4. Контроль при доступе к сетевым ресурсам. Реализуется в том числе штатными средствами ОС. Например, доступ к ресурсам можно разделить паролем. Так осуществляется сетевой доступ к общим ресурсам по протоколу NETBIOS для ОС семейства Windows.

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

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

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

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

 » С целью контроля доступа выделяется контроль пользователя при доступе в систему. Также могут иметь место контроль при запуске процесса (прежде всего, здесь интерес представляет установка пароля ответственного лица) и контроль при доступе к локальным и сетевым ресурсам.

 « С целью снятия блокировки (реакции) используется контроль администратора безопасности или ответственного лица. Кроме того, пользователь может выставить блокировку на некоторые приложения и т.д. Для их снятия осуществляется контроль пользователя.

Особенности парольной защиты, исходя из принадлежности пароля

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

Авторизация ответственного лица может устанавливаться для реализации физического контроля доступа пользователя к ресурсам, прежде всего, к запуску процесса. При этом особенностью здесь является то, что авторизация ответственного лица осуществляется не при доступе в систему, а в процессе функционирования текущего пользователя.

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

 Таким образом, приложение физически запускается ответственным лицом с локальной консоли защищаемого объекта. В результате ответственное лицо будет знать, кто и когда запросил доступ в сеть Internet, так как сам принимает решение ~ разрешать доступ или нет. Если доступ разрешается, ответственное лицо может полностью контролировать данный доступ, т.к. запуск приложения возможен только в его присутствии.

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

Правила парольной защиты

Кадровая безопасность

  1. Пользователи должны следовать установленным в Компании процедурам поддержания режима безопасности при выборе и использовании паролей.

    Пароли являются основным средством подтверждения прав доступа пользователей к информационным системам.

    Пользователь обязан:

    • Не разглашать идентификационные данные.

    • Использовать пароли, отвечающие критериям качественного пароля, принятым в Компании.

    • Менять временный пароль при первом входе в информационную систему.

    • Регулярно менять пароли.

    • Не использовать автоматический вход в систему.

    Пример политики создания паролей для учетных записей

    Политика паролей для пользовательских учетных записей

    1. Длина пароля – не менее 8 символов.

    2. Пароль обязательно должен включать в себя прописные и строчные буквы, цифры, специальные символы.

    3. Максимальный срок действия пароля должен быть ограничен двумя месяцами.

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

    5. Новый пароль пользователя не должен совпадать как минимум с тремя предыдущими паролями.

    6. Пароль не должен совпадать с именем учетной записи пользователя.

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

    8. Рекомендуется, чтобы пароли пользователей на доступ к различным ресурсам корпоративной информационной системы (для учетных записей домена, электронной почты, базы данных) различались.

    9. Недопустимо хранение пароля в открытом виде на любых видах носителей информации.

    Политика паролей для административных учетных записей

    1. Длина пароля – не менее 16 символов.

    2. Пароль обязательно должен включать в себя прописные и строчные буквы, цифры, специальные символы.

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

    4. Новый пароль пользователя не должен совпадать как минимум с предыдущим паролем.

    5. Пароль не должен совпадать с именем учетной записи пользователя.

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

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

    8. Недопустимо хранение пароля в открытом виде на любых видах носителей информации.

    9. Криптографические ключи, используемые для аутентификации, должны быть защищены парольными фразами. Требования к стойкости парольных фраз криптографических ключей идентичны требованиям к паролям административных учетных записей.

 

Развертывание локальной защиты паролем Azure AD

  • 20 минут на чтение

В этой статье

Пользователи часто создают пароли, в которых используются общеупотребительные местные слова, такие как школа, спортивная команда или известный человек. Эти пароли легко угадать, и они слабы против атак по словарю. Чтобы обеспечить соблюдение надежных паролей в вашей организации, защита паролей Azure Active Directory (Azure AD) предоставляет глобальный и настраиваемый список запрещенных паролей.Запрос на изменение пароля не выполняется, если в этом списке запрещенных паролей есть совпадение.

Чтобы защитить локальную среду доменных служб Active Directory (AD DS), вы можете установить и настроить защиту паролем Azure AD для работы с локальным контроллером домена. В этой статье показано, как установить и зарегистрировать прокси-службу защиты паролей Azure AD и агент контроллера домена для защиты паролей Azure AD в локальной среде.

Дополнительные сведения о том, как защита паролем Azure AD работает в локальной среде, см. В разделе Как применить защиту паролем Azure AD для Windows Server Active Directory.

Стратегия развертывания

На следующей схеме показано, как основные компоненты защиты паролем Azure AD работают вместе в локальной среде Active Directory:

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

Мы рекомендуем начинать развертывание в режиме audit . Режим аудита — это исходная настройка по умолчанию, в которой можно продолжать устанавливать пароли.Пароли, которые могут быть заблокированы, записываются в журнал событий. После того, как вы развернете прокси-серверы и агенты DC в режиме аудита, проследите за влиянием, которое политика паролей будет иметь на пользователей, когда политика будет применяться.

На этапе аудита многие организации обнаруживают, что применимы следующие ситуации:

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

Кроме того, усиленная проверка пароля может повлиять на автоматизацию развертывания существующего контроллера домена Active Directory. Мы рекомендуем, чтобы во время оценки периода аудита произошло как минимум одно повышение и одно понижение контроллера домена, чтобы выявить такие проблемы. Дополнительные сведения см. В следующих статьях:

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

Важно отметить, что защита паролей Azure AD может проверять пароли только во время смены пароля или операций установки. Пароли, которые были приняты и сохранены в Active Directory до развертывания защиты паролей Azure AD, никогда не будут проверяться и будут продолжать работать как есть. Со временем все пользователи и учетные записи в конечном итоге начнут использовать пароли, проверенные защитой паролей Azure AD, поскольку их существующие пароли обычно истекают.Учетные записи, для которых настроен «пароль никогда не истекает», освобождаются от этого.

Учет нескольких лесов

Нет дополнительных требований для развертывания защиты паролем Azure AD в нескольких лесах.

Каждый лес настраивается независимо, как описано в следующем разделе, чтобы развернуть локальную защиту паролей Azure AD. Каждый прокси-сервер защиты паролей Azure AD может поддерживать только контроллеры домена из леса, к которому он присоединен.

Программное обеспечение защиты паролем Azure AD в любом лесу не знает о программном обеспечении защиты паролем, развернутом в других лесах, независимо от конфигураций доверия Active Directory.

Особенности контроллера домена только для чтения

События изменения или установки пароля не обрабатываются и не сохраняются на контроллерах домена только для чтения (RODC). Вместо этого они перенаправляются на контроллеры домена с возможностью записи. Вам не нужно устанавливать программное обеспечение агента контроллера домена для защиты паролей Azure AD на контроллерах домена только для чтения.

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

Рекомендации по обеспечению высокой доступности

Основная проблема защиты паролем — это доступность прокси-серверов защиты паролем Azure AD, когда контроллеры домена в лесу пытаются загрузить новые политики или другие данные из Azure.Каждый агент контроллера домена для защиты паролей Azure AD использует простой алгоритм циклического перебора при выборе прокси-сервера для вызова. Агент пропускает прокси-серверы, которые не отвечают.

Для большинства полностью подключенных развертываний Active Directory с работающей репликацией состояния каталога и папки sysvol для обеспечения доступности достаточно двух прокси-серверов защиты паролей Azure AD. Эта конфигурация приводит к своевременной загрузке новых политик и других данных. При желании вы можете развернуть дополнительные прокси-серверы защиты паролей Azure AD.

Конструкция программного обеспечения агента контроллера домена для защиты паролей Azure AD устраняет обычные проблемы, связанные с высокой доступностью. Агент контроллера домена для защиты паролей Azure AD поддерживает локальный кэш последней загруженной политики паролей. Даже если все зарегистрированные прокси-серверы станут недоступны, агенты DC защиты паролей Azure AD продолжат применять свою политику кэшированных паролей.

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

Требования к развертыванию

Для получения информации о лицензировании см. Требования к лицензированию защиты паролей Azure AD.

Применяются следующие основные требования:

  • На всех компьютерах, включая контроллеры домена, на которых установлены компоненты защиты паролем Azure AD, должна быть установлена ​​универсальная среда выполнения C.

  • Для регистрации леса Windows Server Active Directory в Azure AD необходима учетная запись с правами администратора домена Active Directory в корневом домене леса.

  • Служба распространения ключей должна быть включена на всех контроллерах домена в домене под управлением Windows Server 2012. По умолчанию эта служба включается с помощью ручного запуска триггера.

  • Сетевое подключение должно существовать как минимум между одним контроллером домена в каждом домене и как минимум одним сервером, на котором размещается прокси-служба для защиты паролей Azure AD. Это подключение должно позволять контроллеру домена доступ к порту 135 сопоставителя конечных точек RPC и к порту сервера RPC в службе прокси.

    • По умолчанию порт сервера RPC является динамическим портом RPC, но его можно настроить для использования статического порта.

  • Все машины, на которых будет установлена ​​служба прокси-сервера защиты паролей Azure AD, должны иметь сетевой доступ к следующим конечным точкам:

    Конечная точка Назначение
    https://login.microsoftonline.com Запросы аутентификации
    https: // регистрация предприятия.windows.net Функция защиты паролем Azure AD

Агент контроллера домена для защиты паролем Azure AD

К агенту контроллера домена защиты паролем Azure AD применяются следующие требования:

  • Все машины, на которых будет установлено программное обеспечение агента контроллера домена для защиты паролей Azure AD, должны работать под управлением Windows Server 2012 или более поздней версии.
    • Домен или лес Active Directory не обязательно должен находиться на функциональном уровне домена Windows Server 2012 (DFL) или на функциональном уровне леса (FFL).Как упоминалось в Принципах разработки, для запуска программного обеспечения агента DC или прокси не требуется минимального DFL или FFL.
  • На всех машинах, на которых работает агент контроллера домена защиты паролей Azure AD, должен быть установлен .NET 4.5.
  • Любой домен Active Directory, на котором работает служба агента контроллера домена для защиты паролей Azure AD, должен использовать репликацию распределенной файловой системы (DFSR) для репликации sysvol.

    • Если ваш домен еще не использует DFSR, вы должны выполнить миграцию перед установкой защиты паролем Azure AD.Дополнительные сведения см. В разделе Руководство по миграции репликации SYSVOL: репликация FRS на DFS

      .

      Предупреждение

      Программное обеспечение агента контроллера домена для защиты паролем Azure AD в настоящее время устанавливается на контроллеры домена в доменах, которые все еще используют FRS (технологию-предшественницу DFSR) для репликации sysvol, но программное обеспечение НЕ будет работать должным образом в этой среде.

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

      Перенесите свой домен на использование DFSR как можно скорее, как для неотъемлемых преимуществ DFSR, так и для разблокировки развертывания защиты паролем Azure AD. Будущие версии программного обеспечения будут автоматически отключены при работе в домене, который все еще использует FRS.

Прокси-служба защиты паролей Azure AD

К прокси-службе защиты паролей Azure AD применяются следующие требования:

  • Все машины, на которых будет установлена ​​прокси-служба защиты паролей Azure AD, должны работать под управлением Windows Server 2012 R2 или более поздней версии.

    Примечание

    Развертывание прокси-службы защиты паролей Azure AD является обязательным требованием для развертывания защиты паролей Azure AD, даже если контроллер домена может иметь исходящее прямое подключение к Интернету.

  • На всех машинах, на которых будет установлена ​​прокси-служба защиты паролей Azure AD, должна быть установлена ​​.NET 4.7.

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

  • Все машины, на которых размещается прокси-служба защиты паролей Azure AD, должны быть настроены для разрешения исходящего трафика TLS 1.2 HTTP.

  • A Глобальный администратор или Администратор безопасности учетная запись для регистрации прокси-службы и леса защиты паролей Azure AD в Azure AD.

  • Сетевой доступ должен быть включен для набора портов и URL-адресов, указанных в процедурах настройки среды Application Proxy.

Предварительные требования для средства обновления агента Microsoft Azure AD Connect

Служба обновления агента Microsoft Azure AD Connect устанавливается вместе с прокси-службой защиты паролей Azure AD. Для работы службы Microsoft Azure AD Connect Agent Updater требуется дополнительная настройка:

Предупреждение

Прокси-сервер защиты паролей Azure AD и прокси приложения Azure AD устанавливают разные версии службы Microsoft Azure AD Connect Agent Updater, поэтому в инструкциях содержится ссылка на содержимое прокси-сервера приложения.Эти разные версии несовместимы при установке рядом друг с другом, и это не позволит службе обновления агента связываться с Azure для получения обновлений программного обеспечения, поэтому вам никогда не следует устанавливать прокси-сервер для защиты паролей Azure AD и прокси-сервер приложения на одном компьютере.

Загрузить необходимое программное обеспечение

Для локального развертывания защиты паролем Azure AD требуются два установщика:

  • Агент контроллера домена для защиты паролей Azure AD ( AzureADPasswordProtectionDCAgentSetup.msi )
  • Прокси-сервер защиты паролем Azure AD ( AzureADPasswordProtectionProxySetup.exe )

Загрузите оба установщика из центра загрузки Microsoft.

Установить и настроить прокси-сервис

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

В следующем разделе вы устанавливаете агенты DC для защиты паролей Azure AD на контроллерах домена в локальной среде AD DS. Эти агенты DC связываются с прокси-службой для получения последних списков запрещенных паролей для использования при обработке событий смены пароля в домене.

Выберите один или несколько серверов для размещения прокси-службы защиты паролей Azure AD. Следующие рекомендации относятся к серверу (-ам):

  • Каждая такая служба может предоставлять политики паролей только для одного леса.Хост-компьютер должен быть присоединен к любому домену в этом лесу.
  • Поддерживается установка прокси-службы либо в корневом, либо в дочернем доменах, либо в их комбинации.
  • Вам необходимо сетевое соединение по крайней мере между одним DC в каждом домене леса и одним прокси-сервером для защиты паролем.
  • Вы можете запустить прокси-службу защиты паролей Azure AD на контроллере домена для тестирования, но тогда этому контроллеру домена потребуется подключение к Интернету. Такое подключение может быть проблемой безопасности.Мы рекомендуем эту конфигурацию только для тестирования.
  • Мы рекомендуем как минимум два прокси-сервера защиты паролей Azure AD в каждом лесу для обеспечения избыточности, как отмечалось в предыдущем разделе, посвященном вопросам высокой доступности.
  • Не поддерживается запуск прокси-службы защиты паролей Azure AD на контроллере домена только для чтения.

Чтобы установить прокси-службу защиты паролей Azure AD, выполните следующие действия:

  1. Чтобы установить прокси-службу защиты паролей Azure AD, запустите AzureADPasswordProtectionProxySetup.Установщик программного обеспечения exe .

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

      AzureADPasswordProtectionProxySetup.exe / тихий

    Примечание

    Служба брандмауэра Windows должна быть запущена перед установкой пакета AzureADPasswordProtectionProxySetup.exe , чтобы избежать ошибки установки.

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

    Если вы используете брандмауэр стороннего производителя, его все равно необходимо настроить в соответствии с требованиями развертывания. К ним относятся разрешение входящего доступа к порту 135 и порту прокси-сервера RPC. Дополнительные сведения см. В предыдущем разделе о требованиях к развертыванию.

  2. Программное обеспечение прокси-сервера для защиты паролей Azure AD включает новый модуль PowerShell, AzureADPasswordProtection .Следующие шаги запускают различные командлеты из этого модуля PowerShell.

    Чтобы использовать этот модуль, откройте окно PowerShell от имени администратора и импортируйте новый модуль следующим образом:

      Модуль импорта AzureADPasswordProtection

  3. Чтобы убедиться, что прокси-служба защиты паролей Azure AD работает, используйте следующую команду PowerShell:

      Get-Service AzureADPasswordProtectionProxy | эт

    Результат должен показать Статус из Работает .

  4. Прокси-служба запущена на машине, но у нее нет учетных данных для связи с Azure AD. Зарегистрируйте прокси-сервер защиты паролей Azure AD в Azure AD с помощью командлета Register-AzureADPasswordProtectionProxy .

    Для этого командлета требуются учетные данные Global Administrator или Security Administrator для вашего клиента Azure. Этот командлет также необходимо запускать с использованием учетной записи с правами локального администратора.

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

    Командлет Register-AzureADPasswordProtectionProxy поддерживает следующие три режима проверки подлинности. Первые два режима поддерживают многофакторную аутентификацию Azure AD, а третий — нет.

    Подсказка

    Может возникнуть заметная задержка до завершения при первом запуске этого командлета для определенного клиента Azure.Если не сообщается о сбое, не беспокойтесь об этой задержке.

    • Интерактивный режим аутентификации:

        Register-AzureADPasswordProtectionProxy -AccountUpn '[email protected]'

      Примечание

      Этот режим не работает в операционных системах Server Core. Вместо этого используйте один из следующих режимов аутентификации. Кроме того, этот режим может выйти из строя, если включена конфигурация усиленной безопасности Internet Explorer. Обходной путь — отключить эту конфигурацию, зарегистрировать прокси-сервер и снова включить его.

    • Режим аутентификации по коду устройства:

        Register-AzureADPasswordProtectionProxy -AccountUpn '[email protected]' -AuthenticateUsingDeviceCode

      При появлении запроса перейдите по ссылке, чтобы открыть веб-браузер и ввести код аутентификации.

    • Тихий режим аутентификации (на основе пароля):

        $ globalAdminCredentials = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $ globalAdminCredentials

      Примечание

      Этот режим не работает, если для вашей учетной записи требуется Многофакторная аутентификация Azure AD.В этом случае используйте один из двух предыдущих режимов проверки подлинности или вместо этого используйте другую учетную запись, для которой не требуется MFA.

      Вы также можете увидеть, что MFA требуется, если регистрация устройств Azure (которая используется под защитой паролей Azure AD) настроена для глобального требования MFA. Чтобы обойти это требование, вы можете использовать другую учетную запись, которая поддерживает MFA с одним из двух предыдущих режимов проверки подлинности, или вы также можете временно ослабить требование MFA регистрации устройств Azure.

      Чтобы внести это изменение, найдите и выберите Azure Active Directory на портале Azure, затем выберите Устройства> Параметры устройства . Установите Требовать многофакторную аутентификацию для подключения устройств с по № . Не забудьте перенастроить этот параметр обратно на Да после завершения регистрации.

      Мы рекомендуем обходить требования MFA только для целей тестирования.

    В настоящее время нет необходимости указывать параметр -ForestCredential , который зарезервирован для будущих функций.

    Регистрация прокси-службы защиты паролей Azure AD необходима только один раз за время существования службы. После этого прокси-служба защиты паролей Azure AD автоматически выполнит любое другое необходимое обслуживание.

  5. Теперь зарегистрируйте локальный лес Active Directory с необходимыми учетными данными для связи с Azure с помощью командлета PowerShell Register-AzureADPasswordProtectionForest .

    Примечание

    Если в вашей среде установлено несколько прокси-серверов защиты паролем Azure AD, не имеет значения, какой прокси-сервер вы используете для регистрации леса.

    Для этого командлета требуются учетные данные Global Administrator или Security Administrator для вашего клиента Azure. Для этого также требуются права локального администратора Active Directory Enterprise. Вы также должны запустить этот командлет, используя учетную запись с правами локального администратора. Учетная запись Azure, используемая для регистрации леса, может отличаться от локальной учетной записи Active Directory.

    Этот шаг выполняется один раз для каждого леса.

    Командлет Register-AzureADPasswordProtectionForest поддерживает следующие три режима проверки подлинности.Первые два режима поддерживают многофакторную аутентификацию Azure AD, а третий — нет.

    Подсказка

    Может возникнуть заметная задержка до завершения при первом запуске этого командлета для определенного клиента Azure. Если не сообщается о сбое, не беспокойтесь об этой задержке.

    • Интерактивный режим аутентификации:

        Register-AzureADPasswordProtectionForest -AccountUpn '[email protected]'

      Примечание

      Этот режим не работает в операционных системах Server Core.Вместо этого используйте один из следующих двух режимов аутентификации. Кроме того, этот режим может выйти из строя, если включена конфигурация усиленной безопасности Internet Explorer. Обходной путь — отключить эту конфигурацию, зарегистрировать лес, а затем снова включить его.

    • Режим аутентификации по коду устройства:

        Register-AzureADPasswordProtectionForest -AccountUpn '[email protected]' -AuthenticateUsingDeviceCode

      При появлении запроса перейдите по ссылке, чтобы открыть веб-браузер и ввести код аутентификации.

    • Тихий режим аутентификации (на основе пароля):

        $ globalAdminCredentials = Get-Credential
Register-AzureADPasswordProtectionForest -AzureCredential $ globalAdminCredentials

      Примечание

      Этот режим не работает, если для вашей учетной записи требуется Многофакторная аутентификация Azure AD. В этом случае используйте один из двух предыдущих режимов проверки подлинности или вместо этого используйте другую учетную запись, для которой не требуется MFA.

      Вы также можете увидеть, что MFA требуется, если регистрация устройств Azure (которая используется под защитой паролей Azure AD) настроена для глобального требования MFA.Чтобы обойти это требование, вы можете использовать другую учетную запись, которая поддерживает MFA с одним из двух предыдущих режимов проверки подлинности, или вы также можете временно ослабить требование MFA регистрации устройств Azure.

      Чтобы внести это изменение, найдите и выберите Azure Active Directory на портале Azure, затем выберите Устройства> Параметры устройства . Установите Требовать многофакторную аутентификацию для подключения устройств с по № . Не забудьте перенастроить этот параметр обратно на Да после завершения регистрации.

      Мы рекомендуем обходить требования MFA только для целей тестирования.

      Эти примеры будут успешными только в том случае, если текущий вошедший в систему пользователь также является администратором домена Active Directory для корневого домена. Если это не так, вы можете указать альтернативные учетные данные домена с помощью параметра -ForestCredential .

    Регистрация леса Active Directory необходима только один раз за время существования леса. После этого агенты контроллера домена для защиты паролей Azure AD в лесу автоматически выполняют любое другое необходимое обслуживание.После успешного выполнения Register-AzureADPasswordProtectionForest для леса дополнительные вызовы командлета выполняются успешно, но в них нет необходимости.

    Для успешного выполнения Register-AzureADPasswordProtectionForest хотя бы один контроллер домена под управлением Windows Server 2012 или более поздней версии должен быть доступен в домене прокси-сервера защиты паролей Azure AD. Программное обеспечение агента контроллера домена для защиты паролей Azure AD необязательно устанавливать на контроллерах домена до этого шага.

Настроить прокси-службу для связи через HTTP-прокси

Если ваша среда требует использования определенного прокси-сервера HTTP для связи с Azure, выполните следующие действия для настройки службы защиты паролей Azure AD.

Создайте файл AzureADPasswordProtectionProxy.exe.config в папке % ProgramFiles% \ Azure AD Password Protection Proxy \ Service . Включите следующее содержание:

  <конфигурация>
   
      
      <прокси bypassonlocal = "истина"
         proxyaddress = "http://yourhttpproxy.com:8080" />

Если ваш HTTP-прокси требует аутентификации, добавьте useDefaultCredentials tag:

  <конфигурация>
   
      
      <прокси bypassonlocal = "истина"
         proxyaddress = "http: // yourhttpproxy.com: 8080 "/>

В обоих случаях замените http://yourhttpproxy.com:8080 на адрес и порт вашего конкретного прокси-сервера HTTP.

Если ваш прокси-сервер HTTP настроен на использование политики авторизации, необходимо предоставить доступ учетной записи компьютера Active Directory компьютера, на котором размещена служба прокси, для защиты паролем.

Мы рекомендуем остановить и перезапустить прокси-службу защиты паролей Azure AD после создания или обновления AzureADPasswordProtectionProxy.Файл exe.config .

Прокси-служба не поддерживает использование определенных учетных данных для подключения к HTTP-прокси.

Настройте прокси-службу для прослушивания определенного порта

Программное обеспечение агента контроллера домена для защиты паролем Azure AD использует RPC через TCP для связи с прокси-службой. По умолчанию прокси-служба защиты паролей Azure AD прослушивает любую доступную динамическую конечную точку RPC. Вы можете настроить службу для прослушивания определенного TCP-порта, если это необходимо из-за сетевой топологии или требований брандмауэра в вашей среде.

Чтобы настроить службу для работы под статическим портом, используйте командлет Set-AzureADPasswordProtectionProxyConfiguration следующим образом:

  Set-AzureADPasswordProtectionProxyConfiguration –StaticPort <номер порта>

Предупреждение

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

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

  Set-AzureADPasswordProtectionProxyConfiguration –StaticPort 0

Предупреждение

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

Прокси-служба защиты паролей Azure AD требует перезапуска вручную после любого изменения конфигурации порта. Вам не нужно перезапускать службу агента контроллера домена для защиты паролей Azure AD на контроллерах домена после внесения этих изменений конфигурации.

Чтобы запросить текущую конфигурацию службы, используйте командлет Get-AzureADPasswordProtectionProxyConfiguration , как показано в следующем примере

  Get-AzureADPasswordProtectionProxyConfiguration | эт

В следующем примере выходных данных показано, что прокси-служба защиты паролей Azure AD использует динамический порт:

  ServiceName: AzureADPasswordProtectionProxy
DisplayName: прокси для защиты паролем Azure AD
StaticPort: 0

Установите службу агента постоянного тока

Чтобы установить службу агента контроллера домена для защиты паролей Azure AD, запустите AzureADPasswordProtectionDCAgentSetup.msi пакет.

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

  msiexec.exe / i AzureADPasswordProtectionDCAgentSetup.msi / quiet / qn / norestart

Флаг / norestart можно опустить, если вы предпочитаете, чтобы программа установки автоматически перезагружала машину.

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

Установка локальной защиты паролем Azure AD завершается после того, как программное обеспечение агента DC установлено на контроллере домена и этот компьютер перезагружен. Никакая другая конфигурация не требуется и не возможна. События изменения пароля для локальных контроллеров домена используют настроенные списки запрещенных паролей из Azure AD.

Чтобы включить локальную защиту паролей Azure AD на портале Azure или настроить пользовательские запрещенные пароли, см. Включение локальной защиты паролей Azure AD.

Подсказка

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

Обновление прокси-сервиса

Прокси-служба защиты паролей Azure AD поддерживает автоматическое обновление. При автоматическом обновлении используется служба Microsoft Azure AD Connect Agent Updater, которая устанавливается вместе с прокси-службой.Автоматическое обновление включено по умолчанию и может быть включено или отключено с помощью командлета Set-AzureADPasswordProtectionProxyConfiguration .

Текущий параметр можно запросить с помощью командлета Get-AzureADPasswordProtectionProxyConfiguration . Мы рекомендуем всегда включать автоматическое обновление.

Командлет Get-AzureADPasswordProtectionProxy можно использовать для запроса версии программного обеспечения всех установленных прокси-серверов защиты паролей Azure AD в лесу.

Процесс обновления вручную

Обновление вручную выполняется путем запуска последней версии установщика программного обеспечения AzureADPasswordProtectionProxySetup.exe . Последняя версия программного обеспечения доступна в Центре загрузки Microsoft.

Не требуется удалять текущую версию прокси-службы защиты паролей Azure AD — установщик выполняет обновление на месте. При обновлении прокси-службы перезагрузка не требуется.Обновление программного обеспечения можно автоматизировать с помощью стандартных процедур MSI, например AzureADPasswordProtectionProxySetup.exe / quiet .

Обновление агента DC

Когда доступна более новая версия программного обеспечения агента контроллера домена для защиты паролей Azure AD, обновление выполняется путем запуска последней версии AzureADPasswordProtectionDCAgentSetup.msi . Последняя версия программного обеспечения доступна в Центре загрузки Microsoft.

Не требуется удалять текущую версию программного обеспечения агента DC — программа установки выполняет обновление на месте.При обновлении программного обеспечения агента DC всегда требуется перезагрузка — это требование вызвано основным поведением Windows.

Обновление программного обеспечения может быть автоматизировано с помощью стандартных процедур MSI, например msiexec.exe / i AzureADPasswordProtectionDCAgentSetup.msi / quiet / qn / norestart .

Вы можете опустить флаг / norestart , если вы предпочитаете, чтобы программа установки автоматически перезагружала машину.

Командлет Get-AzureADPasswordProtectionDCAgent можно использовать для запроса версии программного обеспечения всех установленных в лесу агентов контроллера домена для защиты паролей Azure AD.

Следующие шаги

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

Защита паролем Azure AD — Azure Active Directory

  • 6 минут на чтение

В этой статье

Защита паролем Azure AD обнаруживает и блокирует известные слабые пароли и их варианты, а также может блокировать дополнительные слабые термины, характерные для вашей организации.Локальное развертывание защиты паролей Azure AD использует те же глобальные и настраиваемые списки запрещенных паролей, которые хранятся в Azure AD, и выполняет те же проверки локальных изменений пароля, что и Azure AD для изменений в облаке. Эти проверки выполняются во время смены пароля и событий сброса пароля для локальных контроллеров домена доменных служб Active Directory (AD DS).

Принципы проектирования

Защита паролем Azure AD разработана с учетом следующих принципов:

  • Контроллеры домена (DC) никогда не должны напрямую связываться с Интернетом.
  • На контроллерах домена не открываются новые сетевые порты.
  • Изменять схему AD DS не требуется. Программное обеспечение использует существующие объекты схемы контейнера AD DS и serviceConnectionPoint .
  • Минимальный функциональный уровень домена или леса AD DS (DFL / FFL) не требуется.
  • Программа не создает и не требует учетных записей в доменах AD DS, которые она защищает.
  • Пользовательские пароли в виде открытого текста никогда не покидают контроллер домена ни во время операций проверки пароля, ни в любое другое время.
  • Программное обеспечение не зависит от других функций Azure AD. Например, синхронизация хэша паролей (PHS) Azure AD не связана и не требуется для защиты паролей Azure AD.
  • Поддерживается инкрементное развертывание, однако политика паролей применяется только в том случае, если установлен агент контроллера домена (агент DC).

Постепенное развертывание

Защита паролем Azure AD поддерживает добавочное развертывание на контроллерах домена в домене AD DS. Важно понимать, что это на самом деле означает и каковы компромиссы.

Программное обеспечение агента контроллера домена для защиты паролей Azure AD может проверять пароли, только если оно установлено на контроллере домена, и только для изменений пароля, отправленных на этот контроллер домена. Невозможно контролировать, какие контроллеры домена выбираются клиентскими компьютерами Windows для обработки изменений пароля пользователя. Чтобы гарантировать согласованное поведение и универсальное применение защиты паролей Azure AD, программное обеспечение агента DC должно быть установлено на всех контроллерах домена в домене.

Многие организации хотят тщательно протестировать защиту паролей Azure AD на подмножестве своих контроллеров домена перед полным развертыванием.Для поддержки этого сценария защита паролем Azure AD поддерживает частичное развертывание. Программное обеспечение агента DC на данном DC активно проверяет пароли, даже если на других DC в домене не установлено программное обеспечение агента DC. Частичное развертывание этого типа небезопасно и рекомендуется только для целей тестирования.

Архитектурная схема

Перед развертыванием защиты паролем Azure AD в локальной среде AD DS важно понять основные концепции дизайна и функций.На следующей схеме показано, как компоненты защиты паролем Azure AD работают вместе:

  • Прокси-служба защиты паролей Azure AD работает на любом компьютере, присоединенном к домену, в текущем лесу AD DS. Основная цель службы — пересылать запросы на загрузку политики паролей от контроллеров домена в Azure AD, а затем возвращать ответы из Azure AD на контроллер домена.
  • DLL фильтра паролей агента DC получает запросы проверки пароля пользователя от операционной системы.Фильтр пересылает их в службу агента DC, которая работает локально на DC.
  • Служба агента DC в Azure AD Password Protection получает запросы на проверку пароля от библиотеки DLL фильтра паролей агента DC. Служба агента DC обрабатывает их, используя текущую (локально доступную) политику паролей и возвращает результат pass или fail .

Как работает защита паролем Azure AD

Локальные компоненты защиты паролем Azure AD работают следующим образом:

  1. Каждый экземпляр службы прокси-сервера защиты паролей Azure AD объявляет себя контроллерам домена в лесу, создавая объект serviceConnectionPoint в Active Directory.

    Каждая служба агента контроллера домена для защиты паролем Azure AD также создает объект serviceConnectionPoint в Active Directory. Этот объект используется в основном для отчетов и диагностики.

  2. Служба агента DC отвечает за инициирование загрузки новой политики паролей из Azure AD. Первый шаг — найти прокси-службу защиты паролей Azure AD, запросив в лесу прокси-объекты serviceConnectionPoint .

  3. При обнаружении доступной прокси-службы агент DC отправляет запрос на загрузку политики паролей службе прокси.Прокси-служба, в свою очередь, отправляет запрос в Azure AD, а затем возвращает ответ службе агента DC.

  4. После того, как служба агента контроллера домена получает новую политику паролей от Azure AD, служба сохраняет политику в выделенной папке в корне общей папки sysvol своего домена. Служба агента DC также отслеживает эту папку в случае репликации новых политик из других служб агента DC в домене.

  5. Служба агента DC всегда запрашивает новую политику при запуске службы.После запуска службы агента DC он ежечасно проверяет срок действия текущей локально доступной политики. Если политика старше одного часа, агент DC запрашивает новую политику из Azure AD через службу прокси, как описано ранее. Если текущая политика не старше одного часа, агент DC продолжает использовать эту политику.

  6. Когда DC принимает события смены пароля, кэшированная политика используется для определения того, принят новый пароль или отклонен.

Ключевые особенности и особенности

  • Каждый раз, когда загружается политика паролей защиты паролей Azure AD, эта политика специфична для клиента.Другими словами, политики паролей всегда представляют собой комбинацию глобального списка запрещенных паролей Microsoft и настраиваемого списка запрещенных паролей для каждого клиента.
  • Агент DC взаимодействует с прокси-службой через RPC через TCP. Прокси-служба прослушивает эти вызовы на динамическом или статическом RPC-порту, в зависимости от конфигурации.
  • Агент DC никогда не прослушивает доступный в сети порт.
  • Прокси-служба никогда не вызывает службу агента постоянного тока.
  • Прокси-служба не имеет состояния.Он никогда не кэширует политики или любое другое состояние, загруженное из Azure.
  • Служба агента DC всегда использует самую последнюю локально доступную политику паролей для оценки пароля пользователя. Если на локальном контроллере домена нет политики паролей, пароль принимается автоматически. Когда это происходит, регистрируется сообщение о событии, предупреждающее администратора.
  • Защита паролем Azure AD не является механизмом приложения политик реального времени. Может быть задержка между изменением конфигурации политики паролей в Azure AD и моментом, когда это изменение достигнет и будет применено ко всем контроллерам домена.
  • Защита паролем Azure AD действует как дополнение к существующим политикам паролей AD DS, а не как замена. Сюда входят любые другие сторонние библиотеки DLL фильтров паролей, которые могут быть установлены. AD DS всегда требует, чтобы все компоненты проверки пароля согласовывались перед принятием пароля.

Привязка леса / клиента для защиты паролем Azure AD

Для развертывания защиты паролем Azure AD в лесу AD DS требуется регистрация этого леса в Azure AD.Каждая развернутая прокси-служба также должна быть зарегистрирована в Azure AD. Эти регистрации леса и прокси связаны с конкретным клиентом Azure AD, который неявно определяется учетными данными, которые используются во время регистрации.

Лес AD DS и все развернутые прокси-службы в лесу должны быть зарегистрированы у одного и того же клиента. Не поддерживается регистрация леса AD DS или каких-либо прокси-служб в этом лесу для разных клиентов Azure AD. Симптомы такого неправильно настроенного развертывания включают невозможность загрузки политик паролей.

Примечание

Таким образом, клиенты, у которых есть несколько клиентов Azure AD, должны выбрать одного выделенного клиента для регистрации каждого леса в целях защиты паролей Azure AD.

Скачать

Два необходимых установщика агента для защиты паролем Azure AD доступны в Центре загрузки Microsoft.

Следующие шаги

Чтобы начать использовать локальную защиту паролем Azure AD, выполните следующие инструкции:

Защита паролем

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

Защита системы от множества пользователей

Один из простых способов защитить ваши данные — это создать учетные записи для нескольких пользователей, назначив каждому индивидуальный профиль и собственный пароль.Когда пользователи входят в систему, они должны будут ввести имя пользователя и пароль, прежде чем перейти к своему настроенному рабочему столу. Хотя это не защитит документы, которые вы сохранили на жестком диске, но защитит ваши личные настройки, включая документы и папки, сохраненные на вашем рабочем столе.

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

Защита системных папок паролем

Вы также можете защитить паролем целые папки, используя инструменты, предоставляемые системой Windows. Для начала просто найдите папку, которую вы хотите защитить паролем, и выделите ее. Щелкните папку правой кнопкой мыши и выберите «Свойства». Щелкните вкладку «Общий доступ» и выберите параметр «Сделать эту папку частной». Это автоматически защитит папку паролем с вашим текущим паролем пользователя. Если у вас нет назначенного пароля, отобразится меню, в котором вы сможете его создать.После создания и подтверждения пароля нажмите «Применить», а затем «ОК». Чтобы получить доступ к папке, любой пользователь должен будет ввести пароль.

Защита экрана паролем

Возможно, вам нужно на мгновение отойти от компьютера, но вы не хотите оставлять этот важный документ без присмотра. Конечно, вы, вероятно, не уйдете долго, но все, что нужно, — это несколько минут, чтобы кто-то подошел и взглянул на вашу конфиденциальную информацию.Это когда вы должны использовать свои функции безопасности Windows и защитить паролем хранитель экрана. Если эта удобная функция включена, вы можете оставить свой компьютер, и когда появится экранная заставка, потребуется пароль для возврата на рабочий стол.

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

Чтобы защитить паролем хранитель экрана, щелкните правой кнопкой мыши рабочий стол и выберите в меню «Свойства». Этого также можно добиться, открыв Панель управления и нажав «Показать». Как только вы дойдете до окна «Свойства экрана», щелкните вкладку «Заставка». Внизу экрана щелкните вкладку «Power». Когда откроется новое окно, вы увидите опцию «Запрашивать пароль, когда компьютер выходит из ждущего режима». Просто установите флажок, нажмите «Применить», а затем «ОК».»Это автоматически назначит ваш пароль для заставки.

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

защита паролем — это … Что такое защита паролем?

  • защита паролем — Великобритания США существительное [неисчислимое] компьютерное программное обеспечение, для которого пользователь должен ввести пароль, прежде чем он или она сможет его использовать Тезаурус: компьютерное программное обеспечение гипоним… Полезный английский словарь

  • Защита паролем — [англ.], Kennwortschutz… Universal-Lexikon

  • защита паролем — ограничение доступа к ресурсу по запросу пароля (без которого доступ запрещен)… Современный английский словарь

  • защита паролем — британское / американское существительное [неисчислимое] компьютерное программное обеспечение, для которого пользователь должен ввести пароль, прежде чем он или она сможет его использовать… Английский словарь

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

  • защита паролем — Использование паролей в качестве меры безопасности для защиты от несанкционированного доступа… ИТ-глоссарий терминов, акронимов и сокращений

  • Взлом паролей — это процесс восстановления паролей из данных, которые были сохранены или переданы компьютерной системой.Распространенный подход — это неоднократные попытки угадать пароль. Цель взлома пароля может заключаться в том, чтобы помочь пользователю восстановить…… Wikipedia

  • Пароль — Чтобы узнать о других значениях, см. Пароль (значения). Пароль — это секретное слово или строка символов, которая используется для аутентификации, чтобы подтвердить личность или получить доступ к ресурсу (пример: код доступа — это тип пароля). Пароль…… Википедия

  • защита — существительное ADJECTIVE ▪ адекватный, эффективный, хороший, отличный ▪ добавленный, дополнительный, дополнительный ▪ специальный ▪… Словарь словосочетаний

  • Пароль — Mot de Pas Pour l’article homonyme, voir Mot de Pas (jeu télévisé).Un mot de pas ou mdp (en anglais: password ou pwd) — это моя аутентификация для использования утилизатора без ресурса или службы, не имеющая ограничений и…… Wikipédia en Français

  • Data Protection API — DPAPI (Data Protection Application Programming Interface) — это простой интерфейс программирования приложений для криптографии, доступный как встроенный компонент в Windows 2000 и более поздних версиях операционных систем Microsoft Windows. Теоретически Данные…… Википедия

    • Защита паролем | Zoho

    Защита паролем

    Теперь с помощью пароля вы можете ограничить доступ посетителя к отдельной странице или группе страниц.Есть два типа паролей.

    1. Пароль уровня сайта
    2. Пароль страницы


    Пароль сайта:

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

    Пароль страницы:

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

    Установка пароля на уровне сайта

    1. Откройте страницу настроек.

    2. Введите пароль в разделе «Защита паролем» и сохраните его.

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

    1. В конструкторе сайтов наведите указатель мыши на страницы и выберите в меню «Управление страницами».

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

    3. Установите флажок «Защитить эту страницу».

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

    5. Сохраните изменения.


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

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

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

    Защита паролем страниц

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

    Примечание: Защита паролем поддерживается только для веб-сервера Apache

    Goto Editor

    Когда используется SitePad Website Builder Панель инструментов.Наведите указатель мыши на опцию Pages на левой боковой панели, а затем щелкните на All Pages . Один раз на всех страницах. Нажмите Значок редактирования любой страницы.

    Вы будете перенаправлены в редактор.

    Выберите защиту паролем

    В SitePad Editor наведите указатель мыши на дополнительное меню на панели навигации. При наведении курсора на другие меню будут выпадать четыре кнопки , то есть Сбросить страницу, Параметры SEO, Пользовательский HTML и Защита паролем.

    Нажмите Защита паролем .

    Защита паролем страниц

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

    • При нажатии на Включить защиту паролем ваш параметр защиты паролем будет включен.
    • Вставьте Имя пользователя , которое хотите. Он будет запрошен при входе на защищенные паролем страницы / сайт.
    • Вставьте Пароль , который вы можете запомнить. Он будет запрошен при входе на защищенные паролем страницы / сайт.
    • Вставить Заголовок для аутентификации . Это будет отображаться в диалоговом окне «Вход в систему».
    • Выберите вариант из Защитить страницы , то есть Все страницы , если вы хотите защитить паролем весь сайт или хотите только выбранных страниц , затем выберите данную опцию.
    • Если была выбрана опция Selected Pages , вы найдете опцию Select Pages , с помощью которой вы можете выбрать, какую страницу защитить паролем.

    После внесения изменений нажмите Сохранить , чтобы сохранить параметр защиты страниц паролем.

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *