Введение: безопасность в дата-платформах — цели, принципы и контекст применения
Безопасность дата-платформ — фундаментальный элемент цифровой трансформации. Она обеспечивает защиту данных на протяжении всего цикла их обработки: от сбора и хранения до анализа и совместного использования. Глобальные требования к конфиденциальности, регуляторная среда и растущие риски киберугроз вынуждают проектировщиков архитектуры данных уделять внимание не только функциональности и производительности, но и устойчивости к внешним и внутренним угрозам. В условиях демократизации данных и разделяемой ответственности между бизнесом, ИТ и безопасностью, подход к безопасности в дата-платформах должен быть системным, непрерывным и встроенным в процесс разработки и эксплуатации.
В рамках данной главы рассматриваются цели и принципы обеспечения безопасности в современных дата-платформах, а также контекст применения с точки зрения архитектуры, управления доступом, шифрования и аудита. Особое внимание уделяется концепциям контроля доступа в контексте многоуровневой инфраструктуры, протоколам взаимодействия между компонентами и практикам интеграции с существующими решениями. В конце главы приводятся практические ориентиры и примеры реализации, которые помогают перейти от концепций к конкретным техническим решениям.
Ключевые идеи, которые будут раскрыты в главах курса, заключаются в следующем:
-
безопасность как встроенная характеристика архитектуры данных: от уровня кластеров до уровня доменных данных и сервисов;
-
управление доступом через сочетание моделей RBAC, ABAC и PBAC с принципом наименьших привилегий;
-
криптография как механизм защиты данных в покое и в движении, включая управление ключами и envelope encryption;
-
аудит и мониторинг как механизм обнаружения препятствий, регуляторного соответствия и оперативной реакции;
-
интеграции и протоколы для безопасной межсервисной и внешней коммуникации, включая OAuth2, mTLS и KMIP.
-
-
Краткое содержание главы
- Опорные принципы безопасной архитектуры дата-платформ: принципы нулевого доверия, изоляции данных и управления ключами.
- Контроль доступа и политика как код: подходы RBAC/ABAC/PBAC, управление идентификацией и федерация.
- Шифрование данных на покое и в движении: архитектура envelope encryption, ключи, вращение и защита ключей.
- Аудит, мониторинг и регуляторная ответственность: журналы, трассировка, интеграция с SIEM и требования соответствия.
- Интеграции и протоколы: безопасные протоколы взаимодействия, управление сертификатами и ключами, примеры паттернов.
Архитектура безопасности дата-платформ
Безопасность в дата-платформе должна быть реализована как многоуровневая логика, встроенная в архитектуру. Основная идея — разделение обязанностей и четкое разграничение зон ответственности: управляющая плоскость (control plane), плоскость данных (data plane) и план управления идентификацией и доступом (identity and access management, IAM). Эффективная архитектура предусматривает следующие элементы:
- единая идентификация и управление идентификацией пользователей, сервисов и рабочих процессов;
- встроенные точки контроля доступа на каждом уровне: на уровне каталогов, API-шлюзов, движков обработки и систем хранения;
- шифрование на всех стадиях жизненного цикла данных: от момента их появления до их устаревания;
- полноценная система аудита и мониторинга для обнаружения несанкционированного доступа и соответствия нормативам.
Архитектурные принципы включают концепцию нулевого доверия (zero trust): не предполагается автоматического доверия к любому субъекту внутри сети; проверки подлинности и авторизации выполняются на каждом шаге. В контексте дата-платформ это означает применение строгих механизмов аутентификации и авторизации для пользователей, сервисов и потоков данных, а также обязательное шифрование и журналирование всех операций над данными.
Технические решения должны учитывать специфику современных дата-платформ: многоарендность, разнотипность источников и потребителей данных, динамичность схем данных и требования к регуляторике. Важную роль играют механизмы управления секретами, безопасной конфигурации, версионирования политик и возможности быстрого отклонения доступа в случае инцидентов или обнаружения нарушений.
- Для систем шифрования целесообразно применить envelope encryption: ключи данных (DEK) шифруются мастер-ключами (KEK), которые сохраняются в безопасном хранилище ключей (KMS или HSM). Это обеспечивает возможность вращения и разделения обязанностей между хранением ключей и использованием их для шифрования данных.
- Архитектура должна предусматривать интеграцию с внешними и внутрикорпоративными сервисами: Identity Providers (IdP), секрет-менеджеры, сервис-обменники ключами, а также инструменты аудита и мониторинга.
Примерно так может выглядеть концептуальная карта архитектуры безопасности в дата-платформе:
-
Identity and Access Management (IdP) — федеративная аутентификация, SSO, OIDC, JWT.
-
Policy and Enforcement Points — политики доступа как код, PEP/ABAC решения.
-
Data Encryption Layer — шифрование на уровне файлов, столбцов, строк и метаданных; управление ключами.
-
Secrets and Credential Management — хранение и ротация секретов, автоматизация обновления.
-
Logging, Auditing и Monitoring — неотъемлемая часть инфраструктуры, незаменимая для регуляторики и реагирования на инциденты.
-
Network and Transport Security — TLS/DTLS, mTLS между сервисами.
-
Data Catalog и Lineage — прозрачность доступа и ответственность за данные.
-
В качестве примера интеграции можно рассмотреть сочетание HashiCorp Vault как центра секрета и KMS-провайдера облачной инфраструктуры (AWS KMS, Azure Key Vault) для envelope encryption. В рамках российского рынка возможно применениеCryptographic-providers и PKI-решений от локальных поставщиков для задач сертификации и защиты ключей. Важно, чтобы выбор инструментов соответствовал регуляторике и требованиям по локализации данных.
{
"Version": "1.0",
"Statement": [
{
"Effect": "Allow",
"Action": ["data:read", "data:write"],
"Resource": ["dp:*"],
"Condition": {"IpAddress": {"dataplat:SourceIp": "203.0.113.0/24"}}
}
]
}
-
Контроль доступов, аудит и шифрование должны быть встроены в конвейер CI/CD: политики доступа и параметры шифрования не должны зависеть от ручного вмешательства в продакшн. Это требует конфигурационного подхода и политики как код, которые версионируются и проходят тестирование на стадии разработки.
-
Концептуальные схемы взаимодействия и интеграции помогают выбрать нужные механизмы: для сервисов внутри облака часто применяют mTLS и токены OAuth2, для взаимодействия с партнерами — ограничиваемые API-ключи или VPC-пайплайны. Важно помнить, что безопасность — это не набор отдельных технологий, а интегрированная архитектура, где каждый компонент поддерживает общий стандарт взаимодействия и мониторинга.
-
Применение стандартов и практик должно происходить не только на уровне технологий, но и в рамках организации: политики должны быть закреплены в коде, процессы тестирования безопасности в DevSecOps, обучение персонала и регулярные проверки соответствия.
Контроль доступа: модели, политики и атрибуты
Контроль доступа в дата-платформе должен обеспечивать не только чтение и запись, но и разумное разделение ответственности, защиту критичных данных и гибкость внедрения. В этом разделе рассматриваются ключевые модели доступа, архитектурные паттерны политики и способы их реализации:
- RBAC (Role-Based Access Control): роли привязываются к набору разрешений, что упрощает управление доступами в широких структурах. Однако RBAC может приводить к раздутым ролям и трудностям в поддержке сложной динамики доступа.
- ABAC (Attribute-Based Access Control): доступ определяется набором атрибутов субъектов, объектов и окружения. ABAC позволяет тонко настраивать правила, особенно в условиях многообразия данных и временных ограничений.
- PBAC (Policy-Based Access Control) и Policy-as-Code: политика описывается как код, хранится в системе контроля версий, проверяется на тестах и разворачивается через конвейеры. Это обеспечивает прозрачность, воспроизводимость и аудит изменений.
- Модели привязки и федерации: интеграция с внешними IdP, поддержка SSO и OpenID Connect, возможность использования сервисных аккаунтов и цепочек JWT/Access Token’ов, поддержка mTLS для сервис‑то‑сервис взаимодействий.
- Принцип наименьших привилегий и разделение обязанностей: доступ предоставляется только на необходимый срок и для конкретной задачи; сервисам — только те действия, которые необходимы для их функции.
Архитектурная практика должна опираться на код политики и политики управления доступом как часть инфраструктуры. В качестве примера можно рассмотреть концептуальный фрагмент политики в формате JSON (Policy-as-Code):
{
"Version": "1.0",
"Statement": [
{
"Effect": "Allow",
"Action": ["dataset:read"],
"Resource": ["dataset:financial:*"],
"Condition": {
"StringEquals": { "department": "finance" }
}
},
{
"Effect": "Deny",
"Action": ["dataset:write"],
"Resource": ["dataset:financial:*"],
"Condition": { "Boolean": { "override": false } }
}
]
}
-
Пример выше иллюстрирует принцип «чтение разрешено только субъектам из отдела финансов» и запрет на запись без соответствующего допуска. В реальном решении такие политики часто реализуются через абстракцию политики доступа в виде сервисного слоя (PEP) и централизованного хранителя политик (Policy Engine), который интегрирован с IdP и секрет-менеджером.
-
Управление привилегиями должно сопровождаться схемами атрибутов: например, атрибутами могут быть роль, проект, регион, время суток, уровень доверия к устройству и состояние контекста (например, риск-оценка). ABAC предоставляет гибкость и возможность быстро адаптироваться к изменяющимся бизнес-требованиям без создания новых ролей.
-
Архитектура должна предусматривать аудит политики доступа: хранение версий политик, журнал изменений и механизм отката. Включение политики как кода в CI/CD позволяет тестировать новые правила и проверять их влияние на доступность и безопасность до развёртывания в продакшн.
-
В части реализации важно обеспечить совместимость между решениями IdP, каталогами пользователей и сервисами обработки данных. Примером реализации может служить архитектура с:
- IdP для аутентификации и федерации;
- отдельной системой управления политиками доступа (Policy Server);
- PEP на границе данных и внутри сервисов;
- централизованным хранилищем атрибутов и учетных данных;
- интеграцией с секрет-менеджером для безопасной выдачи временных учетных данных.
-
Пример интеграции в рамках одной экосистемы: корпоративный IdP (с поддержкой SAML/OIDC) + сервисные аккаунты с короткоживущими токенами + API Gateway с проверкой подписи токенов + база данных или хранилище данных с политиками доступа, применяемыми на уровне API и слоя обработки данных.
-
Внутренняя реализация может включать конфигурации в виде YAML/JSON, которые будут применяться к инструментам политик, а также тестовые сценарии для проверки любых изменений политики доступа. Важно, чтобы политики были читаемы и доступны для аудита, и чтобы изменение политики сопровождалось документированием причин и временым охватом.
-
Для примера можно рассмотреть два подхода в связке RBAC и ABAC в зависимости от контекста: RBAC хорошо работает в фиксированных бизнес-предметных областях и проектах, ABAC — в динамических контекстах и условиях доступа, например, когда требуется ограничение по времени доступа или по степени доверия устройства.
-
Что касается практики, рекомендуется:
- хранить политики как код и регистрировать их изменения;
- автоматизировать тестирование политики на регрессии;
- использовать временные креды и автоматическую их отзыв;
- внедрить мониторинг попыток нарушения и соответствующий отклик.
Шифрование данных: на покое, в движении и управление ключами
Шифрование выступает основным механизмом защиты данных на разных этапах жизненного цикла. В дата-платформах применяются три основных слоя защиты: шифрование в покое (data at rest), шифрование в движении (data in transit) и управление ключами (key management). Современная архитектура предполагает envelope encryption: DEK шифруются KEK, KEK — в надежном хранилище ключей, таким образом достигается гибкость вращения ключей и разделение обязанностей.
-
Шифрование в покое применяется ко всем данным, включая файловые системы, пары столбцов в дата-таблицах, блобы объектов хранения и метаданные. Алгоритмы обычно выбираются в диапазоне AES-256-GCM или ChaCha20-Poly1305 для обеспечения как конфиденциальности, так и целостности данных. В дата-платформах часто применяется файловое шифрование на уровне хранилища, а также шифрование отдельных столбцов (column-level encryption) для особо чувствительных полей.
-
Шифрование в движении включает использование TLS 1.2/1.3 между клиентами и сервисами, а также между сервисами внутри инфраструктуры (межсервисное TLS, mTLS). В случаях высоких требований к безопасности можно использовать mutual TLS с PKI-инфраструктурой и проверкой контекстной информации (например, сертификаты на уровне устройства и пользователя).
-
Управление ключами охватывает создание, хранение, вращение и удаление ключей. В envelope encryption ключи DEK защищаются KEK в KMS или HSM. Встроенные политики вращения ключей и аудит операций с ключами обеспечивают соответствие требованиям регуляторов и минимизируют риск компрометации.
-
Примеры практики шифрования в реальных сценариях:
- Использование облачных KMS: AWS KMS, Google Cloud KMS, Azure Key Vault — для хранения и вращения KEK.
- HashiCorp Vault как централизованный Secrets Management и Key Management в гибридной среде, обеспечивающий единое управление ключами и политиками.
- Российские решения PKI и криптохранения для локализованной инфраструктуры и соответствия требованиям локализации данных.
-
В части архитектурной реализации важна интеграция шифрования с политиками доступа и аудитом. Например, ограничение применения шифрования к конкретным наборам данных может зависеть от атрибутов пользователя, времени суток или контекста подозрительной активности. Шифрование должно быть прозрачным для приложений, не требуя изменений бизнес-логики, и в то же время поддерживать контроль над ключами (когда потребуется безопасное отключение доступа к данным).
-
Пример конфигурации envelope encryption может выглядеть следующим образом (упрощенная схема):
- KEK хранится в KMS;
- DEK используется сервисами обработки данных;
- данные зашифрованы AES-256-GCM;
- rotation KEK выполняется автоматически; DEK переиздаются по мере обновления данных.
encryption:
method: envelope
algorithm: AES-256-GCM
key_management:
provider: vault
key_name: dataplat-key
rotation_period_days: 365
-
Управление ключами требует строгого разделения обязанностей: специалисты по ключам должны быть отделены от разработчиков и администраторов эксплуатации, процесс вращения ключей должен быть автоматизированным, а аудит действий с ключами — неотъемлемой частью мониторинга безопасности.
-
Вопрос локализации данных и законодательства нередко диктует требования к сохранению ключей в рамках конкретной юрисдикции. В таком случае архитектура должна включать локальные KMS или гибридную схему, где часть ключей хранится в локальном HSM, а часть — в облаке, с синхронной политикой вращения и аудита.
Аудит и мониторинг: журналирование, трассировка и соответствие
Непрерывный аудит и мониторинг являются критическими компонентами устойчивости дата-платформ. Они помогают не только обнаруживать попытки несанкционированного доступа, но и подтверждать соответствие требованиям регуляторов, расследовать инциденты и улучшать безопасность.
-
Журналы должны быть неизменяемыми и полнохарактеризующими: кто выполнял операцию, когда и над какими данными. Важна полнота контекста: идентификатор пользователя, используемые ключи, применяемые политики, результат операции.
-
Трассировка (distributed tracing) — ключ к пониманию потоков данных через микро-сервисы: какие сервисы обрабатывали данные, где произошла задержка или ошибка, какие данные были затронуты. OpenTelemetry и аналогичные инструменты обеспечивают совместимый подход к трассировке.
-
Интеграция аудита с SIEM/SOAR платформа для автоматизированного реагирования на инциденты; регуляторика (ISO 27001, SOC 2, GDPR, локальные требования) требует четких регламентов на хранение логов, их доступности и нормативного хранения.
-
В контексте многоарендной среды аудит должен включать аспект разделения арендаторов и конфигураций: какие данные относятся к конкретному клиенту, как обеспечивается изоляция доступа между арендаторами и как обеспечивается видимость ответственности.
-
В реальной реализации аудит требует:
- единый центр журналирования, поддерживающий несколько источников данных;
- нулевые политики сохранения и ретенции сроками, соответствующими требованиям регуляторов;
- механизм обеспечения недоступности изменений журналов (WORM-хранилище, ауди-чеки);
- оповещения об инцидентах и автоматические реакции на громкие события (алгоритмы базовой эскалации, блокировка ключей, временная изоляция сервисов).
-
Примеры технических решений:
- сбор и нормализация логов с разных источников — база данных, объекты хранения, API-шлюзы, оркестраторам рабочих процессов.
- интеграция с SIEM для обнаружения аномалий в профиле доступа и поведения пользователей.
- использование трассировки для детектирования цепочек вызовов и проблем производительности, связанных с безопасностью.
-
Применение принципов аудита не ограничивается инцидентами: аудит также служит основой для постоянного улучшения архитектуры безопасности, выявления потенциальных слабых мест и поддержки бизнес-контекстной прозрачности.
Интеграции и протоколы: безопасные паттерны коммуникаций
Безопасность дата-платформ во многом определяется тем, как организовано взаимодействие между компонентами: сервисами обработки, хранилищами, каталогами данных и внешними системами. Вслед за базовыми принципами защиты данных необходимо обратить внимание на следующие аспекты:
-
Аутентификация и авторизация сервисов: сервис‑то‑сервис аутентификация должна происходить через короткоживущие токены и, при необходимости, mTLS. OAuth 2.0 и OpenID Connect применяются для управления доступом пользователей и делегирования полномочий между системами.
-
Управление сертификатами и PKI: сертификация и доверие между сервисами, периодическая ротация сертификатов, централизованное хранилище и автоматизация обновления.
-
Протоколы взаимодействия: TLS 1.2/1.3, mTLS, безопасная передача параметров через API и очереди сообщений; аутентификация и авторизация на уровне API Gateway и сервисов.
-
Управление ключами и секретами: Secrets Management как центральный узел для хранения ключей, секретов и процессов автоматической выдачи временных учетных данных. В гибридной среде важна поддержка нескольких провайдеров и механизмов резервирования.
-
Стратегии безопасной консолидации данных: ограничение доступа к данным через политики на уровне API, механизмы фильтрации и маскирования, а также обеспечение аудита операций доступа.
-
Пример реализации интеграции в рамках облачных и локальных сервисов может включать:
- IdP для аутентификации пользователей и сервисов;
- API Gateway, выполняющий проверку подписи токенов и контекстной политики;
- сервисы обработки данных, которые проверяют утверждения из токенов и соответствующую политику;
- секрет-менеджер для выдачи временных учетных данных и ключей;
- KMS/HSM для защиты ключей шифрования и управления ими.
{
"version": "1.0",
"flow": "oidc",
"token_endpoint_auth_method": "client_secret_post",
"scopes": ["openid", "profile", "dataset.read"]
}
-
В рамках интеграций целесообразно использовать паттерны безопасной передачи данных: авторизация на уровне каждого слоя, контроль доступа к данным по контексту запроса, шифрование и аудит. Важно обеспечить соответствие архитектурных решений требованиям регуляторов и локальных стандартов.
-
Примеры технологий и продуктов (ограничительно):
- Open-source: HashiCorp Vault как ключевой элемент Secrets Management и небольшой компонент KMS;
- Российские продукты: PKI/сертификация и криптооборудование в рамках локализованных решений, соответствующих требованиям локализации данных.
-
Обратите внимание, что безопасность в интеграциях не ограничивается технологиями, она включает политическую и операционную культуру: процессы обновления, тестирования на проникновение, мониторинг изменений и непрерывное улучшение архитектуры.
Key takeaways
- Безопасность в дата-платформах должна быть встроенной частью архитектуры, а не дополнительной функцией.
- Применение принципа нулевого доверия, изоляции данных и управления ключами совместно обеспечивает конфиденциальность, целостность и доступность данных.
- Контроль доступа должен сочетать RBAC, ABAC и политики как код (PBAC), а управление идентификацией — через федерацию и безопасную авторизацию пользователей и сервисов.
- Шифрование на покое и в движении, плюс envelope encryption и централизованное управление ключами, обеспечивает гибкость, масштабируемость и безопасность в динамичных средах.
- Аудит и мониторинг — критически важны для реагирования на инциденты, обеспечения соответствия требованиям и поддержки бизнес-процессов.
- Безопасные интеграции требуют согласованной политики, управления сертификатами, протоколов взаимодействия и управляемых процессов смены секретов и ключей.
- Практические реализации должны сочетать архитектурные принципы, политики как код и автоматизацию в CI/CD, чтобы снизить риск ошибок и повысить прозрачность.
FAQ
Какие основные принципы лежат в основе нулевого доверия в дата-платформах?
- Нулевое доверие предполагает, что любая попытка доступа оценивается независимо от того, откуда она исходит. Доступ предоставляется только после проверки подлинности, авторизации и контекстной оценки риска на каждом этапе. В рамках дата-платформ это означает применение атрибутной аутентификации (MFA, SSO), политик доступа как код, шифрования и надлежащего аудита для каждого сервиса и пользователя.
Как выбрать подходящие модели контроля доступа для дата-платформы?
- Выбор зависит от уровня динамичности задач и сложности данных. RBAC хорошо подходит для стабильных ролей, ABAC обеспечивает гибкость в условиях изменяющихся контекстов, PBAC позволяет внедрять политики на уровне сервисов. В реальных условиях часто применяется сочетание: RBAC для базовой структуры и ABAC/PBAC для конкретных сценариев доступа к чувствительным данным.
Что такое envelope encryption и зачем он нужен в дата-платформах?
- Envelope encryption разделяет шифрование на два слоя: DEK (Data Encryption Key) шифруется KEK (Key Encryption Key), который хранится в безопасном хранилище ключей. Это позволяет вращать KEK и разделять обязанности между хранением ключей и использованием их для шифрования данных, что повышает безопасность и управляемость.
Какие требования к аудиту являются критическими для соответствия нормативам?
- Неизменяемость журналов, полнота контекста доступа, хранение логов на подходящем уровне ретенции, возможность атрибутивной идентификации конкретных действий пользователей и сервисов, а также интеграция с SIEM/SOAR для автоматизированного реагирования. В рамках регуляторики важно документировать процесс и обеспечивать проверки соответствия.
Какие протоколы и практики обеспечивают безопасную интеграцию между сервисами внутри дата-платформы?
- TLS 1.2/1.3 для шифрования трафика, mTLS для сервис‑то‑сервис аутентификации, OAuth 2.0 и OpenID Connect для управления доступом, а также политика управления ключами и сертификациями. Важна консистентная реализация протоколов на уровне API Gateways, сервисов обработки и хранилищ данных.
Как реализовать управление ключами в гибридной облачной среде?
- Используйте централизованный Secrets Management и Key Management, который может работать с несколькими провайдерами (облачными KMS, локальными HSM). Реализуйте вращение ключей, ограничение доступа к ключам и аудит операций с ключами. В реальных условиях применяют гибридные решения с локализацией ключей там, где это требуется регуляторикой.
Какие примеры архитектурных паттернов можно применить для защиты данных в мульти‑арендной среде?
- Паттерны включают изоляцию данных между арендаторами на уровне доступа и объектов хранения, использование политики на уровне проекта и арендатора, управление секретами с ограничениями по сроку действия и контекстной информации, а также мониторинг мульти‑тенантного поведения для выявления аномалий.
Какие примеры технологий и продуктов полезны в рамках образовательной программы по безопасности дата‑платформ?
- Open-source: HashiCorp Vault для Secrets Management и ключей, OpenTelemetry для трассировки и мониторинга. Российские решения могут включать локальные PKI/сертификаты и криптохранения, соответствующие локализации данных и требованиям регуляторов. Выбор зависит от регуляторной среды, инфраструктуры и бюджета.
Как объяснить бизнес‑заинтересованным лицам важность инвестиций в безопасность дата‑платформ?
- Безопасность — не только риск-менеджмент и соответствие. Это фактор доверия клиентов, конкурентное преимущество и минимизация финансовых потерь от инцидентов. Инвестиции в архитектуру, политики и автоматизацию позволяют снизить вероятность потери данных, обеспечить соответствие и ускорить инновации за счет безопасной совместной работы и доверия к данным.
Какие шаги предпринять для начала внедрения безопасной архитектуры в существующую дата‑платформу?
-
Провести оценку текущей архитектуры, выделить зоны риска и критичные данные; определить целевые модели доступа; внедрить политики как код, начать с шифрования наиболее чувствительных наборов данных; внедрить централизованный аудит и мониторинг; организовать пилотный проект на одном направлении (например, доступ к финансовым данным) и затем масштабировать на другие домены.
-
В заключение, безопасная дата-платформа — это системная работа на стыке архитектуры, процессов и технологий. Реализация должна быть последовательной, проверяемой и адаптивной к изменениям бизнес-тортов, регуляторной среды и угроз кибербезопасности.
Безопасность данных невозможно обеспечить только отдельными инструментами — она должна быть встроена в архитектуру всей платформы данных: от хранения и обработки до управления доступом и политик Data Governance.
Узнайте, как выстроить полноценную Data Platform, где безопасность, управление данными и аналитическая инфраструктура работают как единая система — от Data Warehouse и Data Lake до Lakehouse-архитектуры и AI-ready среды.
