Глава 8. Доверие к устройствам
В Главе 5 мы построили фундамент идентичности: IdP, протоколы, фишинго-устойчивая MFA. Но знание кто запрашивает доступ — недостаточно. Нужно знать с какого устройства. Администратор, подключающийся с корпоративного ноутбука с шифрованным диском и актуальным EDR — это не то же самое, что администратор с личного телефона без пароля.
Зачем нужно доверие к устройствам
NIST SP 800-207 (Section 2, Tenet 4) формулирует: «Доступ к ресурсам определяется динамической политикой — включая наблюдаемое состояние идентичности клиента, приложения/сервиса и запрашивающего актива». Тенет 5 добавляет: «Организация мониторит и измеряет целостность и состояние безопасности всех принадлежащих и ассоциированных активов».
Источник: NIST SP 800-207, Section 2
CISA ZTMM v2.0 выделяет устройства (Devices) как отдельный столп из пяти. Модель зрелости определяет семь функций для оценки:
| Функция | Initial | Advanced | Optimal |
|---|---|---|---|
| Соблюдение политик | Самоотчётные характеристики, ручные обновления | Автоматизированная оценка соответствия, патч-менеджмент | Непрерывная верификация в реальном времени |
| Управление активами | Учёт физических устройств | Автоматическая инвентаризация, мультивендор | Полный реестр в реальном времени, IoT/OT |
| Доступ к ресурсам | Характеристики устройства учитываются | Верифицированные данные в решениях о доступе | Risk score устройства в реальном времени |
| Обнаружение угроз | Базовая автоматизация | Консолидированная защита, MTD | Единая XDR-платформа для всех активов |
Источник: CISA ZTMM v2.0, Devices Pillar, Microsoft mapping
Три проблемы, которые решает доверие к устройствам:
1. «Теневое IT». Сотрудники используют личные устройства без ведома ИТ-отдела. Устройство без шифрования и обновлений — вектор для утечки данных.
2. Компрометация endpoint. Даже корпоративное устройство может быть скомпрометировано — отключен антивирус, установлено уязвимое ПО, устаревшая ОС. Без непрерывной оценки состояния это не обнаружится до инцидента.
3. Статическое доверие. Устройство, прошедшее проверку при регистрации, остаётся «доверенным» навсегда — даже если через месяц его диск расшифрован, а EDR удалён. Zero Trust требует непрерывной оценки.
Оценка состояния устройства (Posture Assessment)
Что проверяем
Оценка состояния устройства — это набор сигналов, собираемых с endpoint и используемых Механизмом политик (PE) для решения о доступе. Основные сигналы:
| Категория | Сигнал | Зачем |
|---|---|---|
| ОС | Версия, билд, уровень патча | Неподдерживаемые ОС не получают security-обновлений |
| Шифрование | BitLocker (Windows), FileVault (macOS), LUKS (Linux) | Защита данных при физической краже |
| Экран блокировки | Таймаут, тип пароля, биометрия | Защита от несанкционированного доступа |
| Антивирус/EDR | Активен, определения актуальны | Обнаружение вредоносного ПО |
| Firewall | Включен, правила применены | Защита от сетевых атак |
| Jailbreak/Root | Обнаружение модификации ОС | Компрометированная ОС = недоверенное устройство |
| TPM | Наличие и версия TPM 2.0 | Hardware root of trust |
| Secure Boot | Включен, подписи верифицированы | Защита цепочки загрузки |
| Сертификаты | Наличие корпоративных сертификатов | Подтверждение принадлежности к организации |
MDM/UEM: кто собирает сигналы
Mobile Device Management (MDM) и Unified Endpoint Management (UEM) — платформы, которые регистрируют устройства, применяют политики и собирают данные о состоянии.
Microsoft Intune — облачное решение для управления Windows, macOS, iOS, Android и Linux (Ubuntu 22.04/24.04 LTS, RHEL 8/9).
Ключевые проверки по платформам:
| Платформа | Проверки |
|---|---|
| Windows | BitLocker, Secure Boot, Code Integrity, TPM, версия ОС, Firewall, Defender, ELAM, machine risk score (Defender for Endpoint) |
| macOS | FileVault, SIP (System Integrity Protection), Firewall, Gatekeeper, версия ОС |
| iOS/iPadOS | Jailbreak detection, device threat level, версия ОС, managed email |
| Android | Play Integrity (basic/device/strong), root detection, security patch level, шифрование |
| Linux | dm-crypt (LUKS), пароль, custom compliance через POSIX-скрипты |
Источник: Intune compliance settings per platform
Jamf Pro — специализированная платформа для Apple-устройств (macOS, iOS, iPadOS, tvOS). Интегрируется с Entra ID и другими IdP для передачи состояния соответствия.
Omnissa Workspace ONE (ранее VMware Workspace ONE — выделен из Broadcom в независимую компанию Omnissa в 2024 году) — мультиплатформенный UEM с интеграцией в Workspace ONE Access для conditional access.
Интервалы оценки
Состояние устройства — не статический снимок. Intune проверяет соответствие:
| Фаза | Частота |
|---|---|
| Первые 15 минут после регистрации | Каждые 3 минуты (Windows/Android) |
| Следующие 2 часа | Каждые 15 минут |
| Установившийся режим | Примерно каждые 8 часов |
| Apple-устройства | Каждые 15 минут первый час, затем ~8 часов |
Срок действия состояния соответствия по умолчанию — 30 дней (настраивается 1–120 дней). Рекомендуется установить «Mark devices with no compliance policy as: Not compliant» при использовании Conditional Access.
Источник: Intune compliance evaluation intervals
Аппаратный корень доверия: TPM и аттестация
TPM 2.0
Trusted Platform Module (TPM) — специализированный криптографический чип (или firmware-реализация — fTPM), стандартизированный ISO/IEC 11889:2015. TPM 2.0 обязателен для Windows 11.
Ключевые возможности:
- Platform Configuration Registers (PCR) — регистры, хранящие хеши компонентов загрузки. PCR0–PCR7 принадлежат firmware и не могут быть сброшены без перезагрузки TPM
- Endorsement Key (EK) — уникальный ключ, прошитый производителем, доказывающий подлинность TPM
- Attestation Identity Key (AIK) — ключ для удалённой аттестации, не раскрывающий EK
Измеренная загрузка (Measured Boot)
При загрузке каждый компонент (UEFI firmware → загрузчик → ОС → драйверы) хешируется и результат расширяется (extend) в соответствующий PCR-регистр. Это пассивная запись — TPM не блокирует загрузку при обнаружении изменений (в отличие от Secure Boot, который активно блокирует неподписанный код).
Процесс extend: PCR_new = Hash(PCR_old || measurement) — невозможно «откатить» значение без сброса TPM.
Источник: TCG PC Client Platform Firmware Profile Specification
Удалённая аттестация
Удалённая аттестация позволяет серверу верифицировать целостность устройства:
Windows: DHA → Microsoft Azure Attestation (MAA)
Microsoft Device Health Attestation (DHA) использовал SOAP/XML для проверки TPM-измерений. С 2023 года для Windows 11 DHA заменяется на Microsoft Azure Attestation (MAA) — REST-сервис на attest.azure.net, возвращающий результат как JSON Web Token.
MAA расширяет проверки DHA: помимо BitLocker и Secure Boot, проверяются ELAM (Early Launch Anti-Malware), HVCI (Hypervisor-protected Code Integrity), VBS (Virtualization-Based Security) и защита DMA.
Источник: HealthAttestation CSP, MAA blog
Apple: Managed Device Attestation (MDA)
Apple реализует аппаратную аттестацию через Secure Enclave (выделенный криптопроцессор). Managed Device Attestation доступна на iOS 16, iPadOS 16.1, macOS 14 и tvOS 16.
Механизм: MDM отправляет DeviceInformation-запрос с ключом DevicePropertiesAttestation. Устройство генерирует hardware-bound приватный ключ внутри Secure Enclave и возвращает сертификат с проверенными свойствами в кастомных OID. Apple отказывает в аттестации, если оборудование или firmware скомпрометированы.
Для сертификатов используется протокол ACME с расширениями для аттестации — сервер ACME может валидировать цепочку сертификатов и OID-свойства.
Источник: Apple Managed Device Attestation
Android: Hardware-backed Keystore и Play Integrity
Android использует аппаратную защиту ключей (hardware-backed keystore, Android 7+) с StrongBox (выделенный security-чип) на флагманских устройствах. Google Play Integrity API (заменил SafetyNet) оценивает целостность устройства по трём уровням: basic, device, strong integrity.
С мая 2025 года Google требует для strong integrity на Android 13+ аппаратные сигналы безопасности и security-патч не старше 12 месяцев.
Источник: Play Integrity API, Intune Android compliance
SPIRE и TPM: tpm_devid node attestor
В Главе 7 мы рассмотрели SPIRE-аттестацию для Kubernetes. Для bare-metal серверов и IoT-устройств SPIRE поддерживает tpm_devid node attestor — аттестация через DevID-сертификат, привязанный к TPM. SPIRE-сервер проверяет:
- Proof of possession — узел владеет приватным ключом, соответствующим DevID-сертификату
- Proof of residency — ключевая пара сгенерирована и хранится внутри TPM (через endorsement certificate chain)
SPIFFE ID для узла формируется из fingerprint (SHA1 хеш ASN.1 DER-кодировки сертификата).
Источник: SPIRE tpm_devid plugin
BYOD vs корпоративные устройства
Zero Trust не запрещает BYOD — он устанавливает разные уровни доверия в зависимости от управляемости устройства.
Типы регистрации (на примере Microsoft Entra ID)
| Характеристика | Entra ID Registered (BYOD) | Entra ID Joined (корпоративное) | Hybrid Joined (гибрид) |
|---|---|---|---|
| Сценарий | Личные устройства | Облачные корпоративные | On-prem AD + облако |
| Владение | Личное | Организация | Организация |
| Управление | Ограниченное (MDM опционально) | Полное (Intune/MDM) | Group Policy + MDM |
| Уровень доверия | Минимальный | Максимальный | Высокий |
| SSO | Облачные ресурсы | Облако + on-prem | Нативный AD + облако |
| Conditional Access | Ограниченные контроли | Полные контроли | Полные контроли |
Источник: Entra ID device identity overview
Microsoft рекомендует (2025): новые устройства развёртывать как Entra ID Joined (cloud-native). Hybrid join описывается как «промежуточный шаг на пути к Entra join».
Стратегия уровней доступа
| Уровень доверия | Тип устройства | Доступ |
|---|---|---|
| 1 (наивысший) | Корпоративное + managed + compliant | Полный доступ ко всем ресурсам |
| 2 | Корпоративное + managed + non-compliant | Ограниченный доступ + remediation |
| 3 | BYOD + registered + managed (MDM) | Доступ к разрешённым приложениям |
| 4 | BYOD + unmanaged | Только веб-приложения в браузере (MAM) |
| 5 (наименьший) | Неизвестное устройство | Блокировка или только self-service |
Device trust в мультиоблачных средах
Microsoft: Conditional Access + Intune
Microsoft Conditional Access — движок политик, который оценивает сигналы (идентичность, устройство, местоположение, приложение, risk level) и принимает решение: разрешить, заблокировать, потребовать дополнительную верификацию.
Структура политики:
- Assignments: пользователи/группы, облачные приложения, условия (платформа, местоположение, risk level)
- Grant controls:
compliantDevice,domainJoinedDevice,mfa,block - Session controls: sign-in frequency, persistent browser, Continuous Access Evaluation (CAE)
Continuous Access Evaluation (CAE) — стандарт на базе OpenID CAEP, обеспечивающий near real-time реагирование на критические события:
| Событие | Реакция |
|---|---|
| Аккаунт удалён/отключён | Немедленное прекращение сессии |
| Пароль изменён/сброшен | Немедленная ревалидация |
| MFA включена для пользователя | Ревалидация |
| Все refresh-токены отозваны | Ревалидация |
| Высокий user risk (ID Protection) | Ревалидация |
| IP-адрес изменился (нарушение Named Locations) | Немедленная блокировка |
С CAE токены могут жить до 28 часов (вместо стандартного 1 часа) — безопасность обеспечивается не коротким TTL, а реактивной ревалидацией.
Источник: Continuous Access Evaluation
Google: Access Context Manager
Google Chrome Enterprise Premium (ранее BeyondCorp Enterprise, переименовано в апреле 2024) использует Access Context Manager для определения уровней доступа (access levels). Два типа:
- Basic access levels — условия с AND/NOR логикой
- Custom access levels — выражения на Common Expression Language (CEL)
Сигналы от устройств собирает Endpoint Verification (расширение Chrome для macOS, Windows, Linux):
| Сигнал | Значения |
|---|---|
allowedEncryptionStatuses | ENCRYPTED, UNENCRYPTED, ENCRYPTION_UNSUPPORTED |
osConstraints | DESKTOP_WINDOWS, DESKTOP_MAC, DESKTOP_CHROME_OS, DESKTOP_LINUX + minimumVersion |
requireScreenlock | true / false |
requireAdminApproval | true / false |
requireCorpOwned | true / false |
Источник: Access Context Manager attributes
AWS: Verified Access с device trust providers
AWS Verified Access поддерживает сторонних провайдеров device trust:
| Провайдер | Доступные сигналы |
|---|---|
| CrowdStrike | assessment.overall (1-100), assessment.os, assessment.sensor_config, platform, serial_number |
| Jamf | risk (HIGH/MEDIUM/LOW/SECURE), osv (версия ОС), groups |
| JumpCloud | device.is_managed (boolean), org_id |
Политики пишутся на языке Cedar:
// Разрешить доступ только с устройств, где ZTA score > 50
permit(principal, action, resource)
when { context.crowdstrike.assessment.overall > 50 };Сессии по умолчанию — 1 день (для провайдеров, созданных после 24 февраля 2025).
Источник: AWS Verified Access device trust, Third-party trust provider context
Lab: Conditional Access с проверкой устройства
Сценарий
Настроим две политики:
- Intune compliance policy — требует BitLocker, Secure Boot, актуальную ОС
- Conditional Access policy — разрешает доступ к Exchange Online только с compliant-устройств
Дополнительно создадим access level в Google Cloud Access Context Manager.
Шаг 1: Intune Compliance Policy (Microsoft Graph API)
# Создание compliance policy для Windows через Graph API
# Требуется: DeviceManagementConfiguration.ReadWrite.All
ACCESS_TOKEN="<your-access-token>"
curl -X POST \
"https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicies" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"@odata.type": "#microsoft.graph.windows10CompliancePolicy",
"displayName": "ZT-Windows-Baseline",
"description": "Zero Trust baseline: BitLocker, Secure Boot, OS >= 10.0.19045",
"passwordRequired": true,
"passwordBlockSimple": true,
"passwordMinimumLength": 8,
"passwordRequiredType": "alphanumeric",
"requireHealthyDeviceReport": true,
"osMinimumVersion": "10.0.19045",
"earlyLaunchAntiMalwareDriverEnabled": true,
"bitLockerEnabled": true,
"secureBootEnabled": true,
"codeIntegrityEnabled": true,
"storageRequireEncryption": true
}'Источник: Create windows10CompliancePolicy (Graph API)
Шаг 2: Conditional Access Policy (Microsoft Graph API)
# Создание Conditional Access policy
# Требуется: Policy.Read.All + Policy.ReadWrite.ConditionalAccess
curl -X POST \
"https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"displayName": "Require compliant device – Exchange Online",
"state": "enabledForReportingButNotEnforced",
"conditions": {
"clientAppTypes": ["all"],
"applications": {
"includeApplications": [
"00000002-0000-0ff1-ce00-000000000000"
]
},
"users": {
"includeUsers": ["All"],
"excludeGroups": ["<break-glass-group-id>"]
}
},
"grantControls": {
"operator": "OR",
"builtInControls": [
"compliantDevice",
"domainJoinedDevice"
]
}
}'Доступные builtInControls: mfa, compliantDevice, domainJoinedDevice, approvedApplication, compliantApplication, block.
Важно: политика создаётся в режиме enabledForReportingButNotEnforced (report-only). Проверьте результаты в Sign-in logs → Conditional Access перед переключением в enabled.
Источник: Create conditionalAccessPolicy (Graph API)
Шаг 3: Google Cloud Access Context Manager
# access-level-corporate-devices.yaml
# gcloud access-context-manager levels create corporate-devices \
# --title="Corporate Managed Devices" \
# --basic-level-spec=access-level-corporate-devices.yaml \
# --policy=<policy-id>
- ipSubnetworks:
- 203.0.113.0/24
devicePolicy:
allowedEncryptionStatuses:
- ENCRYPTED
osConstraints:
- osType: DESKTOP_MAC
minimumVersion: "14.0.0"
- osType: DESKTOP_WINDOWS
minimumVersion: "10.0.0"
- osType: DESKTOP_CHROME_OS
minimumVersion: "120.0.0"
requireScreenlock: true
requireAdminApproval: trueCustom access level на CEL для более гибких условий:
// Корпоративные Windows-устройства ИЛИ одобренные Mac
(device.os_type == OsType.DESKTOP_WINDOWS &&
device.is_corp_owned_device &&
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED) ||
(device.os_type == OsType.DESKTOP_MAC &&
device.is_admin_approved_device &&
device.versionAtLeast("14.0.0"))Источник: Access level attributes, Custom access level specification
Шаг 4: AWS Verified Access — device trust provider
# Создание device trust provider (CrowdStrike)
aws ec2 create-verified-access-trust-provider \
--trust-provider-type device \
--device-trust-provider-type CrowdStrike \
--policy-reference-name crowdstrike \
--device-options '{"TenantId": "<crowdstrike-tenant-id>"}'
# Политика Cedar: ZTA score > 50 И managed device
# permit(principal, action, resource)
# when {
# context.crowdstrike.assessment.overall > 50
# };Источник: AWS Verified Access — device trust providers
Проверка
| Что проверяем | Как |
|---|---|
| Intune compliance | Entra admin center → Devices → Compliance → Monitor |
| Conditional Access | Sign-in logs → Conditional Access tab → What If tool |
| Access Context Manager | gcloud access-context-manager levels list --policy=<id> |
| Verified Access | CloudWatch Logs → Verified Access group logs |
Итоги
| Аспект | Решение |
|---|---|
| Что проверяем | OS version, шифрование, firewall, AV/EDR, TPM, Secure Boot, jailbreak |
| Кто собирает сигналы | MDM/UEM: Intune, Jamf, Omnissa Workspace ONE |
| Hardware root of trust | TPM 2.0 (Windows), Secure Enclave (Apple), Hardware Keystore (Android) |
| Удалённая аттестация | DHA/MAA (Windows), MDA (Apple), Play Integrity (Android), SPIRE tpm_devid (bare-metal) |
| BYOD стратегия | Разные уровни доступа: managed → unmanaged, compliant → non-compliant |
| Непрерывная оценка | Intune sync (~8ч), CAE (near real-time), Endpoint Verification (Chrome) |
| Мультиоблако | Conditional Access (Azure), Access Context Manager (GCP), Verified Access (AWS) |
В Главе 9 мы углубимся в непрерывную оценку устройств: EDR/XDR, osquery и Fleet как источники телеметрии, и интеграция endpoint-сигналов с Механизмом политик.