ИТ-архитектура от А до Я: Комплексное решение. Первое издание

•Через Group Policy Management Editor (GPME) открываем ветку:

•Computer Configuration> Policies> Software Settings> Software Installation

Д•обавляем новый пакет, выбираем путь к файлу AdmPwd.E.CSE.Setup.x64.msi

В нашем случае все программы располагаются в директории \\FSS-PDC-MS01\WKML (Well Known Media Library). Для этого необходимо предварительно развернуть файловый сервер и настроить соответствующий ресурс.

•Тип установки: Assigned

•Деактивируем User Configuration секцию данной групповой политики.

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

•Политика применяется на все компьютеры в соответствующей Организационной Единице (OU).

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

•Расширяем схему Активного Каталога (Active Directory): Import-module AdmPwd.ps и update-AdmPwdADSchema

•В классе «Computer» будут добавлены два новых атрибута: ms-MCS-AdmPwd и ms-MCS-AdmPwdExpirationTime

•Настраиваем права администраторов (ADDS-ADM), локальных администраторов компьютеров (ADDS-ADM-LOCAL) и группы подразделения Поддержки Пользователей (HELP-DESK-ADM) на доступ к атрибуту ms-MCS-AdmPwd в котором хранятся пароли администраторов в открытом виде. Доступ к этому атрибуту имеют все, кто имеет права «All Extended Rights».

•Find-AdmPwdExtendedRights -Identity MyCompany-Workstations | Format-Table ExtendedRightHolders находим всех кто имеет право доступа в OU «MyCompany-Workstations».

•Открываем оснастку ADSIEdit и подключаемся к Default naming context

•Разворачиваем дерево и находим нужный OU (MyCompany-Workstations)> [правая кнопка мышки]> PROPERTIES

•Переходим к закладке> SECURITY> [ADVANCED]

•Нажимаем [ADD]

•В разделе [SELECT PRINCIPAL] указываем имя группы (MYCOMPANY-USERS) и снимаем доступ «All Extended Rights»

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

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

•Назначаем разрешение для компьютеров на модификацию собственных атрибутов (SELF) ms-MCS-AdmPwd и ms-MCS-AdmPwdExpirationTime так как изменения производятся от имени компьютера:

•Set-AdmPwdComputerSelfPermission -OrgUnit MyCompany-Workstations

•Предоставляем группе (HELP-DESK-ADM) права на чтение атрибутов (паролей):

•Set-AdmPwdReadPasswordPermission -OrgUnit MyCompany-Workstations -AllowedPrincipals HELP-DESK-ADM

Предоставляем группе (HELP-DESK-ADM) права на сброс значения атрибутов (паролей):

•Set-AdmPwdResetPasswordPermission -Identity MyCompany-Workstations -AllowedPrincipals HELP-DESK-ADM

•Создаем GPO политику (LAPS-CONFIG) для управления LAPS (через оснастку Group Policy Management)

•Через Group Policy Management Editor (GPME) открываем ветку:

Computer Configuration -> Administrative Templates -> LAPS Enterprise

•Настраиваем:

Enable local admin password management: Enabled

Password Settings: Enabled – в политике задается сложности пароля, его длину и частота изменения.

Complexity: Large letters, small letters, numbers, specials

Length: 12 characters

Age: 30 days

Name of administrator account to manage: Not Configured (по умолчанию меняется пароль с SID -500)

Do not allow password expiration time longer than required by policy: Enabled

•Деактивируем User Configuration секцию данной групповой политики.

•Применяем политику на соответствующую организационную единицу (MyCompany-Workstations).

•Политика применяется на все компьютеры в соответствующей Организационной Единице (OU).

Просмотр пароля и установить дату истечения пароля возможно через утилиту (AdmPwd UI) или через команду:

Get-AdmPwdPassword -ComputerName <computername>

Установка Fine-Grained Password Policy

Для повышения безопасности ИТ инфраструктуры можно установить различные требования парольной политики для различных групп сотрудников (пользователи и администраторы). Настройку можно произвести через оснастку Активного Каталога или консоль PowerShell. Требования: функциональный уровень домена Windows 2008 и выше, права Enterprise Admins. Настройка производится контролере домена.

Вариант 1:

Настройка через оболочку Active Directory Administrative Center. Открываем оснастку Active Directory Administrative Center и переходим на ветвь: System -> Password Settings Container

Правая кнопка: New -> Password Settings

Вариант 2:

Настройка чрез консоль PowerShell:

New-ADFineGrainedPasswordPolicy -Name «Tech Admin Password Policy» -Precedence 1 `

– MinPasswordLength 12 -MaxPasswordAge «30» -MinPasswordAge «7» `

– PasswordHistoryCount 50 -ComplexityEnabled:$true `

– LockoutDuration «8:00» `

– LockoutObservationWindow «8:00» -LockoutThreshold 5 `

– ReversibleEncryptionEnabled:$false

•Добавление группу:

Add-ADFineGrainedPasswordPolicySubject -Identity «Tech Admin Password Policy» -Subjects «IT Admins»

•Добавление администратора (ADMIN1) к политике (как пример на пользователя):

Add-ADFineGrainedPasswordPolicySubject -Identity «Tech Admin Password Policy» -Subjects «ADMIN1»

Restricted Groups добавление в группу локальных администраторов через GPO

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

•Открываем оснастку Group Policy Management на контроллере домена.

•Создаем новую групповую политику: RESTRICTED-ADM-LOCAL

•Через Group Policy Management Editor (GPME) открываем ветку:

Computer Configuration> Policies> Windows Settings> Windows Security> Restricted Groups

•Добавляем группу: [ADD GROUP] и выбираем Administrators

•Входим в группу и добавляем членов группы [ADD MEMBERS of this GROUP]

•Добавляем нашу доменную группу (ADDS-ADM-LOCAL)

•Деактивируем User Configuration секцию данной групповой политики

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

Отключение автозапуска Service Manager через GPO

Добавление данной записи через групповую политику позволит снизить нагрузку на сервера т.к. данная оболочка потребляет определённое количество ресурсов. Желательно включить для всех серверов организации. Настраивается через: Computer/Policies/Administrative Templates/System/Service Manager, enable отключение опции Disable Service Manager startup.

Сопровождение

Сопровождение сервиса возможно средствами ИТ департамента. Не требуется частого вмешательства в работу сервиса. Достаточно 10 минут в день на мониторинг состояния. Перечень регламентных работ может содержать следующие задачи:

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

Требования к квалификации сотрудников

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

•Базовые знания по сетевым технологиям;

•Базовые знания по технологиям виртуализации;

•Продвинутые знания по Windows 2016 Server;

•Продвинутые знания по Windows Active Directory и DNS;

•Продвинутые знания по администрированию активного каталога, настройка DNS, групповых политик;

•Продвинутые знания по сервисам инфраструктуры Microsoft;

•Опыт работы по внедрению и сопровождению систем Windows 2016 (не менее одного года) схожей инфраструктуры;

Система обновления

Используется выделенный сервис WSUS или «A02 Система обновлений WSUS в составе SCCM 2016». Обновление серверов леса и дерева через выделенный сервер обновления. Ввиду важности сервиса необходимо тестирование обновлений. Обновление серверов может происходить последовательно без прерывания работы в рабочие часы. Порядок обновления серверов не имеет значения. Желательно для серверов сегмента «T0 Servers» иметь выделенный сервер обновлений.

Резервирование

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

5 Last Days (Differential) +1 Last Week (Full) + one Current Month (Full)

Необходимое пространства для резервных копий:

Максимальное пространство для резервных копий одного сервера порядка 75GB. Для резервных копий основного сайта, с учетом 60% заполнения дисков порядка 300GB. Для резервного сайта – 150GB.

Архивирование

Архивирование резервных копий серверов возможно в течении 2—12 месяцев. Рекомендуемая схема архивирования: 2 Months (Full Backups). Как правило нет необходимости в хранении архива виртуальных машин.

Оценка рисков

Оценка рисков, связанных с функционированием сервиса можно свести к следующим трем ключевым анализам:

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

•SFA (P) анализ – анализ отказа сервисов и служб необходимых для работы текущего сервиса. В нашем случае как пример, компоненты сервиса развернуты на платформе виртуализации и значить зависит от корневых сервисов С01-С03:

SFA (P) анализ

•SFA (D) анализ – анализ работы сервисов при отказе данного сервиса и определение весового показатель критичности сервиса. В данном случае контролер домена и служба DNS является критичной для большинства ИТ сервисов и как пример:

SFA (D) анализ

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

CFIA анализ

Стоимость решения

Стоимость решения формируется из стоимости:

•Выделенных компонентов сервиса;

•Совместного использования сетевых компонентов;

•Базового сопровождение сервиса (мониторинг, обновление и т п);

В стоимость решения не входит:

•Стоимость резервного сайта;

•Стоимость «тестовой» и «образцовой» площадки;

•Стоимость по внедрению (планирование, дизайн, и т п);

•Стоимость систем обеспечения;

•Стоимость систем обновления, мониторинга и т п;

•Стоимость поддержки пользователей;

Дополнительная стоимость на доступ к сервису со стороны сотрудников может быть распределена по стоимости между ИТ сервисами и пользователями. Для снижения затрат рекомендуется использовать Microsoft Enterprise CAL Suite. Стоимость сервиса рассчитывается из планового использования в течении 3—5 лет и будет рассмотрена в следующей главе книги.

Индикаторы производительности

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

Аудит и контроль логов

Срок хранения логов как правило порядка 12 месяцев. В зависимости от наличия системы централизованного сбора логов или политики ИБ организации, событий могут хранится отдельно или в составе архивных копий виртуальных машин. Журнал логов должен быть доступен сотрудникам департамента Безопасности. Должно быть обеспечена целостность и неизменность логов на всем протяжении жизненного цикла.

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

•Computer\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy

•Computer\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies

•Computer\Policies\Windows Settings\Security Settings\Local Policies\Security Options

•Audit Account Logon Event

•Audit Account Management

•Audit Directory Service Access

•Audit Logon Events (Local Computer)

•Audit Object Access (Access non-Active Directory objects)

•Audit Policy Changes

•Audit Privilege use

•Audit Process Tracking

•Audit System events

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

Код события | Назначение

12 Смена пароля администратора утилитой LAPS (AdmPwd);

13 Сохранение пароля администратора утилитой LAPS (AdmPwd);

866 Запуск исполняемого файла из запрещенного правила SRP;

1102 Очищен лог журнала аудита;

4706 Создано доверительное отношение домену;

4713 Kerberos политика была изменена;

4715 Аудит политика (SACL) для объекта была изменена;

4724 Попытка сброса пароля;

4727 Создана «security-enabled global» группа;

4739 Изменена политика домена (Domain Policy);

4780 ACL установлена для учетной записи группы администраторов;

4865 Добавлена информация, относительно «trusted forest»;

4867 Изменена информация, относительно «trusted forest»;

4907 Настройки аудита объекта изменены;

6145 Ошибки при обработке security policy групповых политик;

4609 Windows выключен;

4624 Учетная запись удачно вошла в систему;

4625 Запись «failed to log on» находясь в статусе «locked out»;

4634 Учетная запись вышла из системы;

4648 A logon attempted using explicit credentials.

4720 Создана пользовательская учетная запись;

4722 Пользовательская учетная запись активирована;

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

4724 Пароль сброшен другой учетной записью;

4725 Пользовательская учетная запись отключена;

4726 Пользовательская учетная запись удалена;

4728 Добавлен объект в «security-enabled global» группу;

4729 Объект удален из «security-enabled global» группы;

4730 «A security-enabled global» группа удалена;

4731 «A security-enabled local» группа создана;

4732 Добавлен объект в «security-enabled local» группу;

4733 Объект удален из «security-enabled local» группы;

4734 «A security-enabled local» группа удалена;

4738 Пользовательская учетная запись изменена;

4740 Пользовательская учетная запись заблокирована;

4741 Компьютерная учетная запись изменена;

4742 Компьютерная учетная запись изменена;

4743 Компьютерная учетная запись удалена;

4756 Объект добавлен в «security-enabled universal» группу;

4757 Объект удален из «security-enabled universal» группы;

4767 Пользовательская учетная запись разблокирована;

4781 Имя пользовательской учетной записи изменено;

4798 A user’s local group membership was enumerated

4799 Изменения в группе администраторов (A security-enabled local group membership (BUILTIN\Administrators) was enumerated)

4800 Компьютер заблокирован

4801 Компьютер разблокирован

Средства мониторинга и контроля

Штатные средства мониторинга системы и/или специализированные средства (SCOM). Помимо базовых событий сервера, необходимо мониторить события (ошибки и предупреждения) следующих источников: DFS Replication, Directory Service и File Replication Service.

Управление

Настройка серверов происходит через консоль выделенной рабочей станции управления (Dedicated Administration Workstation DAW), подключенную в сегмент «Управления». Административные задачи, такие как создание пользователей, смена членство в группах и т п, должны быть делегированы соответствующим группам.

Отчетность по сервису

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

Рекомендации

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

•Не устанавливать дополнительные сервисы;

•Использовать установку Server Core;

•Для физических серверов установить пароль на BIOS;

•Для физических серверов установить загрузку с диска;

•Не устанавливать DHCP сервис на контроллеры домена;

•Использовать только Security update only для DNS сервиса;

•Указывать только IP адреса участвующие в репликации;

•Использование шаблонов безопасности;

•Желательно отключать физический сервер последним, а включать первым, так как он содержит все FSMO роли;

•Желательно исключить из регулярного антивирусного сканирования следующие папки:

D:\NTDSDB\ntds. dit

D:\NTDSDB\EDB.chk

E:\NTDSLOG\EDB*.log

E:\NTDSLOG\EDB. log

E:\NTDSLOG\Edbres*.jrs

D:\NTDSDB\TEMP. edb

D:\NTDSDB\*.pat

D:\SYSVOL\domain

D:\SYSVOL\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory

D:\SYSVOL\staging

D:\SYSVOL\staging areas

D:\SYSVOL\sysvol

•Желательно иметь документ по обработке дублированных имен объектов активного каталога (в основном имена и фамилии пользователей).

P02: Внутренний Центр Сертификации

Назначение

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

Требования

Можно сформулировать основные требования к сервису:

•Высокая производительность

•Высокая отказоустойчивость

•Высокая масштабируемость

•Низкая стоимость владения

•Обслуживание порядка 1000 пользователей

•Обслуживание порядка 1000 устройств

Архитектура

Центр сертификации строится на платформе Microsoft Windows 2016 Server Standard. Служба «Центр Сертификации» CA PKI. Сервис разворачивается в дата центре. Служба строится по классической «двух узловой» схеме.

Сервер «Offline Root CA» физический сервер, не в домене, физически установлен в дата центре. Большую часть времени выключен. Его задача выдавать сертификаты для «Subordinate Issue CA».

Сервера «Subordinate Domain Integrated Issue CA» кластер виртуальных серверов, располагается на виртуальных машинах, включены в домен. Их задача выдавать сертификаты для ресурсов домена, формирование шаблонов.

Сервера «Online Certificate Service Responder» кластер виртуальных серверов, располагается на виртуальных машинах, включены в домен. Их задача проверять отозванные сертификаты и указывать на узлы центра сертификации. Может располагаться на серверах «Subordinate Domain Integrated Issue CA». Выделение их на отдельные машины и перенос в другой сегмент снижает трафик из внешней сети в сегмент серверов и повышает уровень безопасности. При наличии средств балансировки нагрузки можно обойтись без применения кластера.

Возможности решения

Возможности принятого решения:

•Выдача сертификатов для компьютеров;

•Выдача сертификатов для пользователей;

•Выдача сертификатов для служб и программ;

•Возможность автоматического получения (auto enrollment) и обновления сертификатов;

Ограничения решения

Ограничения, накладываемые данным решением:

•Возможности автоматического получения (auto enrollment) и обновления сертификатов только для Windows систем, входящих в состав домена;

Физическая архитектура

Физическая архитектура представляет из себя:

•ADCS-PDC-CA – Сервер «Offline Root CA» – физический сервер. Вычислительные ресурсы соответствуют виртуальной машине размера XS. Операционная система сервера Windows 2016 Standard 64 бит с установленным GUI. Сервер не входит в состав домена.

•ADS-PDC-IS01 и ADCS-PDC-IS02 – Сервера «Issue Subordinate» – виртуальные машины. Вычислительные ресурсы соответствуют виртуальной машине размера S. Операционная система сервера Windows 2016 Standard 64 бит с установленным GUI. Является частью домена.

•ADCS-PDC-OCSR01 и ADCS-PDC-OCSR02 – Сервера «OCSR Responder» – виртуальные машины. Вычислительные ресурсы соответствуют виртуальной машине размера S. Операционная система сервера Windows 2016 Standard 64 бит с установленным GUI. Является частью домена.

Логическая архитектура

Логическая архитектура представляет из себя ADCS-PDC-CA – Сервер «Offline Root CA» – сервер, расположенный в сегменте VLAN10 «T0 SERVERS». Роль сервера: Выделенный сервер с ролью «Certificate Authority» включенный по схеме «Offline Standalone». Предназначен для выдачи сертификатов для серверов выдачи сертификатов «Subordinate Issue CA»;

ADCS-PDC-IS01 и ADCS-PDC-IS02 – Сервера выдачи сертификатов «Subordinate Domain Integrated Issue CA» – сервера располагаются в сегменте VLAN20 «T1 SERVERS». Роль серверов: Выделенный сервер с ролью «Subordinate Issue Certificate Authority» включенный по схеме «Enterprise». Сервера собраны в кластер. Предназначен для выдачи сертификатов конечным устройствам и пользователям;

ADCS-PDC-OCSR01 и ADCS-PDC-OCSR02 – Сервера проверки сертификатов «OCSR Responder» – сервера располагаются в сегменте VLAN40 «DMZ». Роль серверов: Выделенный сервер с ролью «OCSR Responder». Предназначен для указания на источник (AIA) и проверки отозванных сертификатов (CRL) конечными устройствами и пользователям;

Лицензирование

Лицензирование сервиса включает в себя лицензирование серверных операционных систем (Windows 2016 Server Standard) и клиентского доступа на пользователя (Windows CAL USER) и устройство (Windows CAL DEV). Не требуют лицензирования встроенная служба центра сертификации (ADCS).

Стоимость лицензирования серверных операционных систем виртуальных машин сервиса включена в стоимость платформы виртуализации. Физический сервер требует отдельного лицензирования. Клиентские лицензии на доступ к серверам (Windows CALs) являются частью пакета Enterprise CAL Suite.

Зависимости и окружение

Центр сертификации является ключевым сервисом для всей ИТ инфраструктуре. Для его развертывания необходимо наличие платформы виртуализации (C01), Системы Хранения Данных СХД (C02), Сетевой Инфраструктуры (C03) и служб Активного Каталога и DNS (P01).

Мощности

Текущая модель позволяет обслуживать порядка 1000 объектов.

Масштабирование

Масштабирование сервиса возможно двумя путями: Повысить вычислительные мощности серверов или добавить дополнительные сервера.

Отказоустойчивость и восстановление

Сервера построены по схеме отказоустойчивости. Корневой сервер уникальный, его восстановление возможно только из резервной копии или реплики резервного сайта.

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

Роли и ответственности

Административная роль «Adm_PKI_Administrator» для конфигурирования серверов. Сервисная роль для запуска серверов не предусмотрена. Для разворачивания Сервера «Subordinate Domain Integrated Issue CA» необходимо использовать права «Enterprise Administrator» корневого домена леса. Данный пользователь добавляется в группу локальную «Administrators» на сервере PKI-PDC-IS01. За работу сервиса отвечает «системный администратор».

Установка

Установка серверов (PKI-PDC-CA, PKI-PDC-IS01, PKI-PDC-OCSR01)

Сервер PKI-PDC-CA:

•Добавление роли Active Directory Certificate Services – Certificate Authority

•Настройка CA (с правами локального администратора, Standalone CA, Root CA,)

•Создаем новый ключ (RSA # Microsoft Software Key Storage Provider, Key length = 4096, Hash algorithm = SHA256)

•Указываем имя CA:

Common Name: HOLDING-PKI-ROOT-CA

Distinguish Name Prefix: DC=HOLDING, DC=local

Preview Distinguish Name: CN=HOLDING-PKI-ROOT-CA, DC=HOLDING, DC=local

Период действия = 5 лет. (Если период действия 20 лет, то необходимо изменить значение регистра: KLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CAName

•Так как CA Offline, то добавляем две команды PowerShell (чтобы проверка CRL и AIA была на сервере PKI-PDC-OCSR01. Добавляет в регистр значения для alias проверки):

certutil. exe -setreg ca\DSConfigDN «CN=configuration, DC=MYCOMPANY, DC=local»

certutil. exe -setreg ca\DSDomainDN «DC=MYCOMPANY, DC=local»

•Настройки Extensions CA certificate (PKI-ROOT-CA -> Properties -> Extensions). Удаляем все записи и добавляем:

CRL Distribution Point (CDP): http://pki.mycompany.local/cdp/<CaName><CRLNameSuffix>.CRL

•Check: Include in CDP extension of issue certificates

Authority Information Access (AIA): http://pki.mycompany.local/aia/<CaName><CertificateName>.CRT

•Check: Include in the AIA extension of issue certificates

•Перезапуск сервиса

•Меняем период публикации CRL publication interval to 5 years (Revoked Certificate -> Properties ->)

•Публикуем Certificate Revocation List (CRL)

По умолчанию CRL и AIA располагаются в директории: c:\Windows\system32\CertSrv\CertEnroll

•Копируем оба файла на носитель для переноса на сервер PKI-PDC-OCSR01

•Экспортируем сертификат PKI-ROOT-CA (Properties -> Details -> Copy в формате PKCS #7 Certificates *.P7B включая все сертификаты, указанные в пути)

•Генерируем новый запрос (All Tasks -> Submit new request …)

•Находим запрос сервера PKI-PDC-IS01

•Выпускаем сертификат (Pending Certificate -> All Tasks -> Issue)

•Экспортируем сертификат PKI-PDC-IS01 (в формате PKCS #7 Certificates *.P7B включая все сертификаты, указанные в пути)

•Копируем на сервер PKI-PDC-IS01

Сервер PKI-PDC-IS01:

•Добавление роли Active Directory Certificate Services – Certificate Authority, Certificate Authority Web Enrollment

•Перезагрузка сервера и настройка сервиса

•Настройка Sub CA (с правами Enterprise Administrators, Enterprise CA, Subordinate CA,)

•Создаем новый ключ (RSA # Microsoft Software Key Storage Provider, Key length = 4096, Hash algorithm = SHA256)

•Запрашиваем сертификат у корневого CA. По умолчанию сохраняем в директории C:\

•Копируем запрос на корневой CA в папку по умолчанию

•Импорт сертификата PKI-ROOT-CA

•Импорт сертификата PKI-PDC-IS01

•Запускаем сервис (сайт проверки CRL и AIA уже настроен на сервере PKI-PDC-OCSR01)

•Генерируем шаблоны сертификатов или используем имеющиеся.

•Добавляем MYCOMPANY\Domain Users права READ и ENROLL на сертификаты.

•Добавим HOLDING\Administrators в группу локальных администраторов сервера.

Сервер PKI-PDC-OCSR01:

•Добавление роли Active Directory Certificate Services – Online CRL Service Responder

•Настройка Online CRL Service Responder

•Установка требует вручную запросить сертификат OCSR Signing (через консоль mmc – Certificates)

Обходной вариант установки сайта для проверки AIA и CRL

•Добавление роли IIS

•Создание папки: c:\inetpub\wwwroot\PKI\cdp и c:\inetpub\wwwroot\PKI\aia

•Создание сайта: http://pki.mycompany.local (Сайт: PKI, расположение: папка PKI, имя хоста: pki.mycompany. local)

•Предоставить доступ группе Cert Publishers на READ, WRITE, MODIFY

•Копируем CRL и AIA файлы с корневого сервера CA в папки cdp и aia соответственно.

Сервер ADDS-PDC-DC01:

•Добавление CNAME записи в DNS: PKI то PKI-PDC-OCSR01.mycompany. local

•Импортируем сертификаты CA и Subordinate CA через GPO в разделы Trusted Root Certification Authority.

•Через GPO настраиваем auto-enroll.

Конфигурирование

Доступ к конфигурации серверов доступен через сервер управления в соответствии с процессом «Управления изменениями».

Контроль трафика по протоколам и портам 1

Контроль трафика по протоколам и портам 2

Сопровождение

Сопровождение сервиса возможно средствами ИТ департамента. Не требуется частого вмешательства в работу сервиса. Достаточно 10 минут в день на мониторинг состояния. Перечень работ соответствует базовому списку.

Требования к квалификации сотрудников

Качественное внедрение и сопровождение сервиса возможно при соблюдении следующих требований:

•Базовые знания по сетевым технологиям,

•Базовые знания по технологиям виртуализации

•Продвинутые знания по Windows 2016 Server,

•Продвинутые знания по сервисам инфраструктуры Microsoft,

•Продвинутые знания по инфраструктуре Private Key Infrastructure PKI и сервиса Microsoft Certificate Authority CA,

•Опыт работы по внедрению и сопровождению систем Windows 2016 (не менее одного года) схожей инфраструктуры.

Система обновления

Используется система обновлений WSUS в составе SCCM 2016.

Резервирование

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

5 Last Days (Differential) +1 Last Week (Full) + one Current Month (Full)

Архивирование

Архивирование резервных копий серверов в течении двух месяцев. Если отсутствует система сбора логов, то достаточно архивирование логов событий. Срок хранения логов 12 месяцев. Рекомендуемая схема архивирования: 2 Months (previous months Full Backups)

Оценка рисков

Оценка рисков сервиса:

•BIA анализ – Отказ сервиса ведет к отказу большинства ИТ сервисов и как следствие простой в работе бизнеса.

•SFA (P) анализ – анализ отказа сервисов и служб необходимых для работы текущего сервиса. Отказ платформы виртуализации (С01, С02), сервисов (С03) и (Р01) приведет к полному отказу.

•SFA (D) анализ – анализ работы сервисов при отказе данного сервиса. Сервис используется для большинства сервисов ИТ инфраструктуры и как следствие преиведет к их частичному или полному отказу. сервисов Р01, Р04, S01, S03, S04, S05, А01, А02, А04, А05, А06, С01, D02, D03, D05, D07 и D08. Также повлияет на работу систем конечных пользователей.

•CFIA анализ – анализ работы сервиса при отказе компонентов сервиса. В примере показан развернутый список компонентов связанных сервисов.

CFIA анализ

Стоимость решения

Стоимость решения формируется из стоимости:

•Стоимости выделенных компонентов сервиса,

•Стоимости совместного использования сетевых компонентов,

•Стоимости платформы виртуализации (операционных систем)

•Стоимости базового сопровождение сервиса (мониторинг, обновление и т п).

Дополнительная стоимость на доступ к сервису со стороны пользователей (на устройство или пользователя). В качестве лицензии используется Microsoft Enterprise CAL Suite и с частичным распределением стоимости по сервисам. В стоимость решения не входит:

•Стоимость резервного сайта

•Стоимость внедрения («тестовая» и «образцовая» площадки)

•Работы по внедрению (планирование, дизайн, внедрение и т п)

•Системы обеспечения (электричество, ИБП, охлаждение и т п)

•Стоимость систем обновления, мониторинга и т п

•Стоимость сервиса Поддержки Пользователей (Service Desk)

Индикаторы производительности

Мониторинг состояния параметров Процессор, Память, Дисковое пространство, Активность сети.

Аудит и контроль логов

Журнал логов копируется в департамент Информационной Безопасности. Следующий список событий имеет отношение к работе сервиса.