• Внедрение Инфраструктуры Открытых Ключей на основе Windows Server. Сетевой ответчик, особенности настройки.

    Степан Москалев, Леонид Шапиро

     

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

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

    Со временем список отзыва сертификатов будет расти, особенно если мы будем внедрять различные типы сертификатов и количество пользователей системы будет увеличиваться. Сертификаты надо будет отзывать, например, если пользователь покидает компанию, и его сертификат надо аннулировать, или же сертификат скомпрометирован и нуждается в отзыве. Такой сертификат, верней, его серийный номер помещается в список отзыва сертификатов (CRL), который должен быть опубликован и доступен клиентам на Distribution Point – центре распространения. Обычно это WEB сервер и LDAP каталог.

    Кроме основного или базового списка отзыва, может быть также использован и разностный или Delta CRL. Он содержит аннулированные сертификаты, которые были отозваны после публикации предыдущего базового списка. Использование Delta CRL позволяет сократить объем передаваемых клиенту данных [4].

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

    Теперь давайте вспомним, что делается, для проверки не отозван ли сертификат. Проверяется поле сертификата CRL Distribution Point (CDP), которое и содержит информацию о месте расположения списка отзыва сертификатов, за которым нам и предстоит обратиться.

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

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

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

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

    Оказывается, такое решение уже давно есть и называется «сетевой ответчик» или online responder Online Certificate Status Protocol (OCSP) [5]. Эта функциональность есть в составе центра сертификации Microsoft [6].

    Как он работает? В отличие от списков отзыва сертификатов (CRL), которые распространяются периодически и содержат сведения обо всех отозванных и приостановленных сертификатах, сетевой ответчик обрабатывает только отдельные запросы от клиентов о состоянии сертификата. Объем получаемых данных на один запрос остается постоянным вне зависимости от возможного количества отозванных сертификатов. Это позволяет снизить накладные расходы при проверках сертификатов. Однако ссылка на OCSP Online Responder должна быть включена в проверяемый сертификат. Дополнительно можно указать OCSP, Online Responder через групповые политики [7].

    Суть работы OCSP простая. См. Рисунок 1.  Клиент для проверки статуса сертификата отправляет запрос на OCSP Responder с указанием серийного номера проверяемого сертификата. Online Responder на своей стороне проверяет статус сертификата и возвращает этот статус клиенту. Сначала ответчик OCSP определяет, имеет ли он кешированные ответы для одного и того же запроса. Если да, то он может отправить ответ клиенту.

    Если нет уже кэшированного ответа, тогда ответчик OCSP проверяет, есть ли у него локальный кешированный список отзыва CRL. Если да, то по нему он проверит статус сертификата, и отправит ответ клиенту, который будет подписан сертификатом OCSP. Если кешированного списка отзыва нет, то тогда OCSP сам обратится по указанному в CDP расширении сертификата пути, проанализирует полученную информацию и отправит окончательный ответ клиенту [8].

    Рисунок 1 Алгоритм работы OCSP

     

    Использовать протокол OCSP умеют только клиенты под управлением Windows Vista и выше. Предыдущие ОС могут его поддерживать только за счёт сторонних компонентов [8].

    Очевидно, использование этой технологии целесообразно, особенно в больших компаниях.

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

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

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

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

     

    Приступим к установке OCSP.

    Начнем с настройки на стороне издающего сервера сертификатов.

    Заходим на сервер учетной записью пользователя, обладающей правами Enterprise Admin и переходим к установке.

    1. Запустите Server Manager. Нажмите ToolsCertification Authority.
    2. Нажмите правой кнопкой мыши на Certificate Templates и выберите
    3. Выберите шаблон OCSP Response Signing и измените свойства
    4. На вкладке Security добавьте учётную запись компьютера, на котором устанавливается OCSP и дайте ей права Read, Enroll и Auto Enroll.
    5. Нажмите OK для принятия изменений в шаблоне OCSP Response Signing.
    6. На вкладке General посмотрите продолжительность действия сертификата Validity period: (по умолчанию стоит 2 недели, если OCSP сервер не будет членом домена, то есть смысл в увеличении данного параметра (выдача будет производиться в ручном режиме)).
    7. Закройте Certificate Templates.
    8. Нажмите правой кнопкой мыши на Certificate Templates и выберите New – Certificate Template to Issue.
    9. Выберите шаблон OCSP Response Signing и нажмите
    10. Запустите Windows PowerShell [8].
    11. Для добавления путей публикации OCSP в Authority Information Access (AIA) выполните следующую команду:

    Add-CAAuthorityInformationAccess http://pki.nwtraders.msft/ocsp -AddToCertificateOcsp -Force

    1. Перезагрузите службу сертификатов: Restart-Service CertSvc

     

    Теперь можно приступать к установке Online Responder на сервере Веб сервере.

     

    1. Выполните установку OCSP при помощи PowerShell, для чего запустите Windows PowerShell.
    2. Для установки роли выполните следующую команду: Install-WindowsFeature ADCS-Online-Cert -IncludeManagementTools
    3. Выполните следующую команду: Install-ADcsOnlineResponder
    4. Нажмите Y
    5. Запустите Server Manager.
    6. Нажмите ToolsInternet Information Services Manager.
    7. Нажмите на имени сервера.
    8. Нажмите Sites.
    9. Нажмите Default Web Site.
    10. Убедитесь в наличии сайта OCSP.
    11. В Server Manager.
    12. Нажмите Tools – Online Responder Management.
    13. Нажмите правой кнопкой мыши на Revocation Configuration и выберите Add Revocation Configuration.
    14. В окне Add Revocation Configuration на вкладе Getting Started With Adding A Revocation Configuration нажмите Next.
    15. В окне Add Revocation Configuration на вкладе Name The Revocation Configuration введите имя конфигурации (оно может быть любое) IssuingCA01 и нажмите Next.
    16. В окне Add Revocation Configuration на вкладе Select CA Certifícate Location выберите Select a certificate for an Existing enterprise CA и нажмите Next.
    17. В окне Add Revocation Configuration на вкладе Choose CA Certificate выберите Browse CA certificates published in Active Directory и нажмите Browse.
    18. В окне Select Certification Authority выберите сертификат издающего центра и нажмите кнопку OK.
    19. Нажмите Next.
    20. В окне Add Revocation Configuration на вкладе Select Signing Certificate выберите Automatically select a signing certificate и установите флаг Auto-Enroll for an OCSP signing certificate нажмите Next. См. Рисунок 2

     

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

    Рисунок 2 Выбор сертификата

    21. В окне Add Revocation Configuration на вкладе Revocation Provider нажмите Provider….

    22. Убедитесь, что в окне Revocation Provider Properties в области Base CRLs: (область Delta CRLs: пока оставляем без изменений) путь http стоит первым. См. Рисунок 3.

     

    Рисунок 3. Пути к спискам отзыва

    23. В окне Revocation Provider Properties в области Delta CRLs: нажмите кнопку ADD… и введите маршрут http://pki.nwtraders.msft/PKI/IssuingCA01+.crl нажмите кнопку OK.

    24. В окне Revocation Provider Properties в области Delta CRLs: нажмите кнопку ADD… и введите маршрут:///CN=IssuingCA01,CN=ICA01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Nwtraders,DC=msft?deltaRevocationList?base?objectClass=cRLDistributionPoint нажмите кнопку OK.

     

    Примечание: Маршруты удобно взять из утилиты pkiview.msc запустив ее на издающем центре сертификатов. pki.netraders.msft – путь, используемый в тестовом примере.

    25. Нажмите кнопку OK.

    26. В окне Add Revocation Configuration на вкладе Revocation Provider нажмите Finish.

    Установка OCSP завершена.

    Проверка работы Online Responder

    1. В Server Manager.
    2. Нажмите Tools – Online Responder Management.
    3. Нажмите левой кнопкой мыши на Online Responder: Nwtraders.msft.
    4. Убедитесь, что напротив IssuingCA01 стоит статус Working. См. Рисунок 4.

     

    Примечание: websrv1.nwtraders.msft – используемый в примере сервер WEB.

    Рисунок 4 Проверка работоспособности

     

    5. Нажмите левой кнопкой мыши на Array Configuration и нажмите на имени WEB сервера. См. Рисунок 5.

     

    Рисунок 5. Просмотр свойств сертификата

    6. Нажмите левой кнопкой мыши на View Signing Certificate и посмотрите свойства сертификата:

    • Кем выдан.
    • Кому выдан.
    • Срок действия.
    • Какой шаблон использован при выдаче.

     

    См. Рисунок 6,  Рисунок 7

     

    Рисунок 6. Свойства сертификата. Вкладка “General”

     

    Рисунок 7. Свойства сертификата. Вкладка “Details”

    7. Зайдите на сервер издающего удостоверяющего центра с правами администратора сервера «nwtraders\Administrator».

    Запустите из командной строки утилиту pkiview.msc.

    8. Уберитесь в наличии пути OCSP Location#1 в настройках издающего центра сертификатов

    9. Посмотрите статус напротив пути OCSP Location#1.

     

     

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

     

    Продолжение следует…

     

    Статья опубликована в журнале “Системный Администратор”

     

    Литература

    [1] Шапиро Л. Внедрение инфраструктуры открытых ключей на основе Windows Server 2016. Часть 1. Предварительный этап. / «Системный администратор», № 1-2, 2018 г. – С. 23-27. URL: http://samag.ru/archive/article/3576.

    [2] Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 2. RootCA / «Системный администратор», № 3, 2018 г. – С. 16-19. URL: http://samag.ru/archive/article/3605

    [3] Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 3. Установка и настройка издающего центра сертификации (Issuing CA)/ «Системный администратор», № 7-8, 2018 г. – С. 26-28. URL: http://samag.ru/archive/more/184

    [4] PKI Design Considerations: Certificate Revocation and CRL Publishing Strategies https://blogs.technet.microsoft.com/xdot509/2012/11/26/pki-design-considerations-certificate-revocation-and-crl-publishing-strategies/

    [5] Online Certificate Status Protocol https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol

    [6] Certification Authority Guidance https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)

    [7] PKI Design Considerations: Certificate Revocation and CRL Publishing Strategies https://blogs.technet.microsoft.com/xdot509/2012/11/26/pki-design-considerations-certificate-revocation-and-crl-publishing-strategies/

    [8] PowerShell Documentation https://docs.microsoft.com/en-us/powershell/

    • Внедрение Инфраструктуры Открытых Ключей на основе Windows Server. Установка и настройка издающего центра сертификации

       

      Степан Москалев

      Леонид Шапиро

       

      В этой части нашего цикла мы рассмотрим развертывание издающего удостоверяющего центра в двухуровневой иерархии. В отличие от корневого, этот сервер должен быть постоянно доступен клиентам, причем здесь мы имеем в виду не только возможность получения сертификатов, но и что важней, их отзыва при компрометации. Точно также, как и с корневым УЦ, перед установкой понадобится подготовить файл capolicy.inf [1] и разместить его правильном месте расположения [2].

       

      Пример структуры capolicy.inf может выглядеть следующим образом:

      [Version]

      Signature=”$Windows NT$”

      [PolicyStatementExtension]

      Policies=InternalPolicy

      [InternalPolicy]

      OID=1.2.3.4.1455.67.89.5

      URL=http://pki.nwtraders.msft/PKI/cps.txt

      [certsrv_server]

      RenewalKeyLength=2048

      RenewalValidityPeriodUnits=5

      RenewalValidityPeriod=Years

      CRLPeriodUnits=1

      CRLPeriod=Weeks

      CRLOverlapUnits=1

      CRLOverlapPeriod=Days

      CRLDeltaPeriodUnits=1

      CRLDeltaPeriod=Days

      LoadDefaultTemplates=0

      AlternateSignatureAlgorithm=1

       

      Познакомиться с синтаксисом файла capolicy.inf можно в первой статье этого цикла [2].

      На следующем шаге можно переходить к установке самого сервиса Active Directory Certificate Services. Установка может быть выполнена как с помощью графического интерфейса, так и с помощью команд PowerShell [3]. Второй вариант обычно проще и занимает меньше времени.

      Install-AdcsCertificationAuthority –CAType EnterpriseSubordinateCA –CACommonName “IssuingCA01” –KeyLength 2048 –HashAlgorithmName SHA256 –CryptoProviderName “RSA#Microsoft Software Key Storage Provider”

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

      С точки зрения безопасности, следует использовать внешний защищенный носитель информации для обмена и не подключать корневой центр сертификации к сети. Непосредственно для запроса сертификата можно воспользоваться утилитой certreq [4] уже на самом корневом центре сертификации.

      Certreq -submit C:\test\ICA01.Nwtraders.msft_IssuingCA01.req, где test папка, в которой был сохранен файл запроса.

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

      certutil -resubmit 2

      certreq –Retrieve 2 C:\test\ICA01.crt

      После этого полученный сертификат переносится на издающий УЦ и устанавливается на нем.

      certutil -installCert C:\test\ICA01.crt [5]

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

      Первое – опубликовать сертификат корневого центра сертификации на издающем центре сертификатов ICA01, для чего выполнить следующую команду:

      certutil –addstore –f root C:\test\RootCA_ROOTCA.crt

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

      После этого службу надо запустить

      Start-Service CertSvc

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

      Поскольку мы не еще проводили публикацию сертификата корневого УЦ и его списка отзыва в службе каталога Active Directory Domain Services, это можно будет сделать теперь, для чего выполняются команды:

      certutil –dspublish –f C:\test\ROOTCA_ROOTCA.crt – публикация сертификата;

      certutil –dspublish –f C:\test\ROOTCA.crl ROOTCA – публикация списка отзыва сертификатов;

      ROOTCA в данной команде это имя центра сертификации.

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

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

      Удалите настройки CrlDistributionPoint, заданные по-умолчанию.

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

      Разумное решение – использование именно внешнего WEB сервера клиентами для получения сертификатов и списков отзыва.

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

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

      Удаление путей можно выполнить с помощью PowerShell

      $crllist = Get-CACrlDistributionPoint

      foreach ($crl in $crllist) { Remove-CACrlDistributionPoint $crl.uri -Force }

       

      Для добавления новых путей публикации CrlDistributionPoint выполните следующие команды:

      Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force

      Add-CACRLDistributionPoint -Uri http://pki.nwtraders.msft/PKI/%3%8%9.crl -AddToCertificateCDP -AddToFreshestCrl -Force [6]

      Add-CACRLDistributionPoint -Uri “ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10” -PublishToServer -AddToCrlCdp -AddToFreshestCrl -AddToCertificateCDP -PublishDeltaToServer -Force [6]

      Если с основными компонентами приведенных команд все понятно, то ряд параметров под знаком % могут вызывать вопросы. На самом деле здесь нет ничего сложного и познакомиться с тем что обозначает какая из переменных можно по приведенной ссылке [6]

       

      Для обеспечения автоматической публикации CRL добавьте:

      Add-CACRLDistributionPoint -Uri \\pki.nwtraders.msft\pki\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force

      По сравнению с корневым центром сертификатов добавляется переменная %9 (<DeltaCRLAllowed>) так как в ROOTCA список DeltaCRL отсутствует. [7]

       

      Тоже самое следует проделать для AIA путей, то есть надо удалите настройки CAAuthorityInformationAccess, заданные по-умолчанию:

      $aialist = Get-CAAuthorityInformationAccess

      foreach ($aia in $aialist) { Remove-CAAuthorityInformationAccess $aia.uri -Force }

      Добавить локальный путь при помощи команды PowerShell не получится, для этого придется воспользоваться графическим интерфейсом или командой certutil.

      certutil -setreg CA\CACertPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%3%4.crt\n1:\\pki.nwtraders.msft\pki\%3%4.crt”

      Добавить пути публикации http и ldap при помощи команд PowerShell.

      Add-CAAuthorityInformationAccess http://pki.nwtraders.msft/PKI/%3%4.crt -AddToCertificateAia -Force

      Add-CAAuthorityInformationAccess “ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11” -AddToCertificateAia -Force

       

      Для настройки срока действия сертификата и периодичности публикации CRL используется команда certutil, мы подробно рассмотрели постустановочную настройку на примере корневого центра сертификации в предыдущей статье [7].

      certutil -setreg CA\ValidityPeriodUnits 5

      certutil -setreg CA\ValidityPeriod “Years”

      certutil -setreg CA\CRLPeriodUnits 1

      certutil -setreg CA\CRLPeriod “Weeks”

      certutil -setreg CA\CRLOverlapUnits 1

      certutil -setreg CA\CRLOverlapPeriod “Days”

      certutil -setreg CA\CRLDeltaPeriodUnits 1

      certutil -setreg CA\CRLDeltaPeriod “Days”

       

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

      certutil -setreg CA\AuditFilter 127

      Перезагрузите службу сертификатов:

      Restart-Service CertSvc

       

      Опубликуйте списки CRL:

      certutil -CRL

      Далее нужно скопировать сертификат издающего центра сертификации центр распространения (Distribution Point).

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

      Графическая консоль сервера сертификатов позволит удостовериться в том, что пути к спискам отзыва и самим сертификатам УЦ изменены, параметры аудита заданы. Также следует удостовериться что клиенты получают доступ по указанным путям и могут загрузить сертификаты и списки отзыва. В нашем примере это проверка HTTP пути http://pki.nwtraders.msft/PKI/.

       

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

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\IssuingCA01\

      Где IssuingCA01 – это введенное нами при установке имя УЦ. и посмотреть значение ключей реестра:

       

      CRLPublicationURLs

      CACertPublicationURLs

      ValidityPeriodUnits

      ValidityPeriod

      CRLPeriodUnits

      CRLPeriod

      CRLOverlapUnits

      CRLOverlapPeriod

      CRLDeltaPeriodUnits

      CRLDeltaPeriod

      AuditFilter

      DSConfigDN

      DSDomainDN

       

      Наконец, воспользоваться консолью EnterprisePKI, запустив из командной строки утилиту pkiview.msc, в столбце «Status» для всех путей должно быть статус «OK».

       

      Кроме этого, можно воспользоваться ADSI Edit для проверки информации в службе каталога.

       

      Перейдите по пути CN=Public Key Services,CN=Services,CN=Configuration,DC=Nwtraders,DC=msft.

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

      CDP – Содержит CRL (базовый и дельта), которые опубликованы в AD.

      Certificate Templates – cодержит шаблоны сертификатов.

      Certification Authorities – cодержит сертификаты корневых центров сертификации (Root CA для нашего случая).

      Enrollment Services – cодержит сертификаты центров сертификации, которые могут выдавать сертификаты в данной службе каталогов.

      KRA – Содержит сертификаты (key recovery agents) агентов восстановления.

      OID – Содержит информацию о OID используемых службой сертификации (Certification Authorities).

       

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

      В следующей статье мы поговорим о работе с центрами распространения (Distribution Points)

      Продолжение следует…

       

      Литература

      [1] Prepare the CAPolicy.inf File – https://technet.microsoft.com/en-us/
      library/jj125373(v=ws.11).aspx.

      [2] Шапиро Л. Внедрение инфраструктуры открытых ключей
      на основе Windows Server 2016. Часть 1. Предварительный
      этап. / «Системный администратор», № 1-2, 2018 г. – С. 23-27.
      URL: http://samag.ru/archive/article/3576.

      [3] Утилита Certreq – https://docs.microsoft.com/en-us/windowsserver/
      administration/windows-commands/certreq_1.

      [4] PowerShell Documentation – https://docs.microsoft.com/en-us/
      powershell/.

      [5] Certutil – https://docs.microsoft.com/en-us/windows-server/
      administration/windows-commands/certutil.

      [6] Certification Authority Guidance – https://docs.microsoft.com/
      en-us/previous-versions/windows/it-pro/windows-server-2012-R2-
      and-2012/hh831574(v=ws.11).

      [7] PKI Design Considerations: Certificate Revocation
      and CRL Publishing Strategies – https://blogs.technet.
      microsoft.com/xdot509/2012/11/26/pki-design-considerationscertificate-
      revocation-and-crl-publishing-strategies/.

      [8] Москалев С., Шапиро Л. Инфраструктура открытых ключей
      в Windows Server 2016. Часть 2. RootCA. //«Системный адми-
      нистратор», № 3, 2018 г. – С. 16-19. URL: http://samag.ru/archive/
      article/3605.http://samag.ru/archive/article/3605

      • Back to School 2018: Udemy-курсы Ильи Рудь от 10$.

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

         

        • Установка и настройка корневого центра сертификации (RootCA)

          Степан Москалев

          Леонид Шапиро

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

          • Атаки DDoS и выбор средств противостояния. Построение тестового стенда.

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

            • Атаки DDoS и методы противодействия

              Вряд ли найдется хоть одно предприятие, независимо от его сферы деятельности, где не применяются интернет технологии. Для многих компаний невозможность или трудности работы в сети приводят к катастрофическим последствиям, чем не преминули воспользоваться злоумышленники и конкуренты, проводя целый комплекс атак, приводящих к весьма серьезным неприятностям. Так что же это за атаки и почему они нередко оказываются весьма успешными? Как им противостоять? В качестве примера возьмем интернет-магазин как наиболее простой и понятный вариант. Пусть достигнуты отличные результаты, интернет-магазин имеет успех. Вдруг вы заметили сокращение объема заказов. Стали поступать жалобы от постоянных клиентов, что сайт магазина не отвечает или работает крайне медленно. Эта ситуация начинает повторяться все чаще. Наконец, практически все время к магазину становится невозможно получить доступ. В чем же дело? Вы оказались слишком успешны. Вам объявили кибервойну! Следует иметь в виду, что ни одна из сфер деятельности не осталась без внимания злоумышленников. Атакам подвергаются не только интернет-магазины, но и финансовая сфера, сайты учебных заведений, медицинских учреждений, некоммерческих организаций и многие другие. Надо сказать, что нечестные методы конкурентной борьбы стали гораздо совершеннее, и развитие IT технологий не только предоставило нам новые эффективные инструменты ведения бизнеса, но и создало новое оружие для борьбы с ним. Можно весьма эффективно уничтожать конкурентов, не прибегая к еще недавно столь популярным методам «грубой силы». Теперь на службе у преступников информационные технологии… Здесь речь идет о DDoS атаках, жертвами которых мы и оказались.

              • Внедрение Инфраструктуры Открытых Ключей на основе Windows Server 2016

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

                • Доверие в сфере информационных технологий

                  • Рубрика: Security,Windows
                  • Автор: Леонид Шапиро
                  • Дата: Friday 09 Mar 2018

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

                  • Битва гипервизоров: VMware vs Hyper-V

                    За последние 9 лет было написано множество статей на тему “какой гипервизор для виртуализации серверов лучше” и, как правило, каждая статья становилась очередным полем битвы сторонников разных вендоров. Все статьи, даже те, которые были написаны независимыми специалистами, имеют один серьезный недостаток – они устарели достаточно быстро и с выходом новых версии продуктов стали практически неактуальны. В рамках данного труда я сделал свежее сравнение двух лидеров рынка – VMware и Hyper-V – и планирую ответить на по-прежнему актуальный вопрос “кто же круче?”. Сразу отвечу на возражение “почему ты не рассматриваешь решения KVM, Xen, Nutanix и легион других?”. Все очень просто: меня интересует ровно то, что актуальней всего на рынке и пока доля продукта исчисляется в 1-2-3%  от общей массы, тратить  свое время на “неуловимого Джо” нет никакого желания.

                    • О волшебной палочке дополнительного образования.

                      60504738Раньше я всегда говорил о том, что выбирая информационные технологии, вы выбираете область, где придется учится всю жизнь. Чуть позже я понял, что областей, где не надо учиться всю жизнь, практически нет. Если откинуть механические работы, где важна ловкость рук, то совсем нет.  Юристы, врачи, летчики, режиссеры и легион других профессий учатся не меньше нашего брата.  Получается, что любой, кто имеет профессиональные амбиции и серьезные планы на жизнь, должен воспринимать пожизненное образование, как что-то само собой разумеющееся. Парадокс ситуации в том, что с каждым десятилетием знания становится все проще и дешевле добывать, а иногда они просто бесплатны.  Но при этом в мире нет переизбытка суперквалифицированных специалистов, более того, их всегда стабильный дефицит. Видимо, это связано с тем, что наличие доступного спортзала рядом с домом не делает вас атлетом. Я учусь всю сознательную жизнь и последние 10 лет жизни активно учу, поэтому тема обучения мне близка. В данной статье хотелось бы «без дураков» поговорить об источниках знаний и их особенностях. А так же о том какой источник более эффективен.