--- service: "Publicasta" schema_version: "1.0" article_id: 627 title: "Новый опыт AWS для разработчиков убирает трение при запуске облака — и делает первую проверку управления обязательной" language: "ru" default_language: "en" canonical_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review?lang=ru" json_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.json?lang=ru" api_url: "https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_new_builder_experience_defaults_need_governance_review?lang=ru" channel_url: "https://publicasta.com/api/public/v1/channels/it_today_news" channel_articles: "https://publicasta.com/api/public/v1/channels/it_today_news/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-17T06:59:30+00:00" updated_at: "2026-09-17T06:59:30+00:00" translations: - language: "ar" html_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review?lang=ar" markdown_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.md?lang=ar" json_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.json?lang=ar" - language: "de" html_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review?lang=de" markdown_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.md?lang=de" json_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.json?lang=de" - language: "en" html_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review?lang=en" markdown_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.md?lang=en" json_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.json?lang=en" - language: "es" html_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review?lang=es" markdown_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.md?lang=es" json_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.json?lang=es" - language: "fr" html_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review?lang=fr" markdown_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.md?lang=fr" json_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review?lang=pl" markdown_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.md?lang=pl" json_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review?lang=ru" markdown_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.md?lang=ru" json_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review?lang=zh" markdown_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.md?lang=zh" json_url: "https://publicasta.com/it_today_news/aws_new_builder_experience_defaults_need_governance_review.json?lang=zh" --- # Новый опыт AWS для разработчиков убирает трение при запуске облака — и делает первую проверку управления обязательной > AWS разворачивает регистрацию через проекты, управляемые разрешения, подключение кодинговых агентов и лимиты расходов. Это удобно, но перед использованием проекта в реальной работе нужно проверить идентичность, регион, квоты и выданный доступ. AWS меняет момент, в который новая облачная среда превращается в операционную ответственность. Новый сценарий регистрации рассчитан на разработчиков, которые хотят перейти от идеи к работающему коду, не изучая сначала всю модель аккаунтов AWS, IAM и организаций. Новый клиент может использовать уже существующую учётную запись Google, GitHub, Apple или Amazon, получить предварительно настроенный проект, пригласить коллег по электронной почте и подключить кодингового агента с помощью установочной подсказки. ![Ноутбук с типовой панелью облака и символами coding-агента, разрешений и бюджета](https://publicasta.com/storage/projects/17/pages/627/2026/09/3c9fd0c3-994f-4e6e-882f-ac85d90de9c2.webp) Это заметный сдвиг в процессе освоения облака. Первым решением AWS теперь не обязательно становится выбор структуры аккаунтов, схемы идентификации и конфигурации сервисов. Вместо этого началом может быть короткая подсказка, после которой приложение сразу разворачивается. AWS сообщает, что новый сценарий постепенно распространяется и пока доступен лишь ограниченному числу клиентов. Для ИТ-команд важно понимать: AWS не устранил риски облачной инфраструктуры. Несколько ранних решений просто скрыты за настройками по умолчанию. Для экспериментов и небольших команд это может быть полезно, но одновременно меняется место для проверки. Первичный контроль стоит провести сразу после создания проекта, пока среда ещё достаточно мала и понятна. ## Что именно запускает AWS Новый сценарий, описанный в документации [Sign up for AWS (new)](https://docs.aws.amazon.com/accounts/latest/reference/sign-in-new.html), организует работу вокруг проектов. Проект включает аккаунт AWS, созданные в нём ресурсы и настройки, которые определяют обмен доступом с коллегами. Проекты, принадлежащие одному человеку, образуют организацию, управляемую через AWS Settings. AWS описывает это как упрощённую среду для разработчиков, работающих в темпе ИИ. В обычном процессе AWS команда обычно заранее принимает решения о создании аккаунта, идентификации, разрешениях, регионах, биллинге и настройке сервисов. В новом сценарии AWS создаёт начальную структуру и применяет настройки по умолчанию, рассчитанные на быстрый старт проекта. В [объявлении AWS](https://aws.amazon.com/blogs/aws/aws-reimagines-the-getting-started-experience/) сказано, что новые клиенты могут начать со 100 долларов кредитов Free Tier. Документация AWS также предупреждает: у некоторых клиентов могут запросить платёжные данные или сразу подключить платный тариф. Поэтому бесплатные кредиты нельзя считать универсальной гарантией. В объявлении указано, что для платного проекта можно установить месячный лимит расходов, начиная с 20 долларов, а при достижении лимита AWS приостанавливает проект, не позволяя начислениям продолжаться сверх установленного потолка. Новый сценарий также предусматривает переход от небольшого проекта к более продвинутому администрированию AWS. Когда рабочей нагрузке понадобятся несколько регионов или функции управления, например собственные политики в AWS Organizations, AWS обещает включить расширенные возможности без миграции и простоя. Это важная особенность: стартовая среда не обязательно является одноразовым тестовым аккаунтом, который позднее придётся пересоздавать. При этом перед нами отдельная операционная модель. AWS берёт на себя часть управления организацией и доступом. В [сравнении вариантов регистрации](https://docs.aws.amazon.com/accounts/latest/reference/sign-up-for-aws.html) сказано, что новый сценарий управляет политиками организации, включая resource control policies и service control policies, а также ролями доступа людей. Клиентам, которым нужно самостоятельно создавать политики организации, следует использовать расширенный путь регистрации. На демонстрации продукта это различие легко не заметить. Отсутствие обязательной миграции не означает отсутствия архитектурного решения. Оно означает, что начальную архитектуру можно расширить до продвинутой модели. Организации всё равно нужно решить, соответствует ли управляемая модель её требованиям к контролю, границам ответственности и аудиту. ## Подключение кодингового агента — самая существенная деталь Объявление AWS упрощает не только регистрацию в консоли. После создания проекта клиент получает подсказку, предназначенную для настройки ИИ-инструмента программирования. В примере AWS агент устанавливает AWS CLI и Agent Toolkit for AWS, входит в среду и добавляет рекомендации для проекта в кодовую базу. Затем агент создаёт и разворачивает API с использованием Lambda, DynamoDB и API Gateway. Это новый тип сокращённого пути при подключении: облачный провайдер даёт разработчику инструкцию, превращающую универсальный кодинговый агент в оператора инфраструктуры нового проекта. Подсказка — не просто документация. Она становится частью цепочки доступа между человеком, агентом и облачными API. Это важно потому, что агент может делать больше, чем писать файлы приложения. AWS описывает подключённого агента как способного разворачивать ресурсы, запускать рабочие нагрузки и изменять приложение в соответствии с рекомендациями AWS. Сервисные процессы также могут автоматически настраивать разрешения между поддерживаемыми ресурсами. Поэтому разработчик может воспринимать результат как создание приложения агентом, хотя фактическое изменение включает аккаунт, идентичности, политики ресурсов, роли выполнения, сетевые решения, конфигурацию журналирования и тарифицируемую рабочую нагрузку. Удобство — центральная идея продукта. Возможность создать работающую конечную точку за несколько минут сама по себе не является недостатком. Операционный вопрос состоит в том, что команда может наблюдать и ограничивать при такой скорости. Подсказку, настраивающую агента, следует проверять так же, как bootstrap-скрипт, учётные данные CI или модуль инфраструктуры. У неё должен быть известный источник, проверенная версия и понятное описание идентичностей и инструментов, которые она активирует. Собственные рекомендации AWS по безопасности подтверждают этот вывод с более широкой точки зрения. В [контрольной модели для ИИ-кодинговых агентов](https://aws.amazon.com/blogs/security/balancing-speed-and-safety-a-control-framework-for-ai-coding-agents/) AWS называет рисками инъекции в подсказки и контекст, чрезмерно широкие настройки, неконтролируемые изменения в продакшене, риски цепочки поставок и неуправляемый внешний доступ, когда агенты читают недоверенный контент или вызывают инструменты. В рекомендациях предлагается отделять доверенную оркестрацию от агентов, работающих с недоверенными входными данными, применять минимально необходимые разрешения, требовать одобрения человека для необратимых действий и добавлять детерминированные проверки на этапе сборки. Новый опыт для разработчиков не устраняет эти риски. Он делает их актуальными раньше — в том числе для небольшого proof of concept. ## Настройки по умолчанию полезны, но не равны минимальным разрешениям Документация AWS по IAM довольно прямо описывает одну часть новой модели. В [руководстве по менеджеру ролей](https://docs.aws.amazon.com/en_en/IAM/latest/UserGuide/id_roles_create_role-manager_least-privilege.html) сказано: если сервис автоматически создаёт роль, AWS обычно может достаточно хорошо ограничить её область действия. Однако некоторые роли, особенно используемые вычислительными ресурсами или для управления облачной инфраструктурой, могут иметь широкие разрешения, поскольку AWS заранее не знает, что именно будет делать рабочая нагрузка. Для среды, в которой агент должен быстро собрать проект, это разумный инженерный компромисс. Система, которой приходится предугадывать будущие действия, не всегда может создать узкую окончательную политику до появления приложения. Ошибкой будет считать автоматически созданную роль готовым решением безопасности. Это начальная точка, и её область действия должна сужаться по мере того, как рабочая нагрузка становится известной. Та же документация объясняет, как проверять неиспользуемые разрешения с помощью IAM Access Analyzer. Для аккаунта нового типа AWS может предоставить анализатор неиспользуемого доступа на 90 дней после активации расширенных функций и отключения role manager. Анализатор сопоставляет разрешённые действия с фактически использованными и предлагает уменьшить набор разрешений. Есть важное ограничение: неиспользуемое не означает ненужное. AWS сообщает, что для этого сценария role manager рекомендация строится на активности за последние 30 дней. Ежеквартальная задача, путь аварийного восстановления или редкая административная операция могут выглядеть неиспользуемыми, хотя они необходимы. Перед применением рекомендации проверяющему нужно понимать рабочую нагрузку. Разумная трактовка роли по умолчанию такова: её достаточно для запуска проекта, но до проверки она временная, а ответственность за неё закреплена за конкретным человеком или командой. Первый деплой проекта должен сформировать краткий перечень ролей, политик, доверительных связей и разрешений на уровне ресурсов. Такой перечень полезнее общего утверждения, что аккаунт был создан с некими средствами безопасности. ## Управляемая граница проекта меняет устройство команды Модель проектов даёт небольшим командам очевидное преимущество. Коллег можно приглашать по электронной почте, и AWS сообщает, что каждый приглашённый получает доступ только к проектам, указанным в приглашении. Для обычного доступа людей в новой модели не нужно создавать IAM users. Это проще, чем сразу объяснять каждому начинающему разработчику различия между IAM users, ролями, политиками идентичности, политиками ресурсов и IAM Identity Center. Кроме того, такая схема создаёт более ясную границу между экспериментами. AWS утверждает, что ресурсы из разных проектов не могут обращаться друг к другу, если для конкретных ресурсов не включён межпроектный доступ. Но граница проекта не автоматически совпадает с границей бизнеса. Команде нужно спросить себя, что представляет собой проект. Это один прототип, один продукт, одна клиентская среда или временная задача? Кто владеет его данными? Кто получает уведомления о расходах? Кто может пригласить следующего участника? Что произойдёт, если первоначальный создатель уйдёт? Документация указывает квоты для новой модели управления аккаунтами: до 29 проектов во Free Plan, до 299 в Paid Plan и до 500 человек, которым можно открыть доступ к проекту. Для многих небольших команд этих значений достаточно, но они не заменяют дизайн аккаунтов или организации. Если группа начнёт использовать проекты как неформальную замену аккаунтам разработки, тестирования и продакшена, со временем граница может перестать соответствовать требованиям к соблюдению норм или восстановлению. Управляемая модель организации также требует отдельного решения от центрального ИТ-подразделения. Если компании нужны собственные service control policies, resource control policies или централизованный жизненный цикл политик, расширенный путь регистрации может оказаться лучшей отправной точкой. Если компании в основном требуется безопасное место для изолированных прототипов, управляемый путь может подойти — при условии, что правила классификации данных и владения аккаунтом определены заранее. ## Лимит расходов решает одну проблему, но не заменяет управление затратами Лимит расходов на уровне проекта — одна из самых практичных функций объявления. Он задаёт эксперименту понятный потолок и позволяет AWS приостановить проект после его достижения. Это лучше, чем требовать от разработчика заранее оценить цену каждого сервиса перед проверкой идеи, а для финансовой функции даёт конкретный контроль над проектами с небольшим риском. Тем не менее лимит следует воспринимать как автоматический выключатель, а не как полноценную систему FinOps. Приостановка может прервать демонстрацию, отключить конечную точку, остановить запланированную задачу или оставить незавершённый деплой. Команде нужно знать, что именно означает пауза для её приложения и потребуется ли для возобновления решение человека. Также стоит заранее найти ресурсы, расходы или операционные последствия которых не очевидны после первого API-вызова. AWS сообщает, что клиенты платят за фактическое использование в пределах лимита проекта и получают уведомления по мере приближения к нему. Это создаёт полезный рабочий порядок: рано включить уведомление, выяснить, какой ресурс увеличивает расходы, и оставить последнюю часть бюджета для осознанной работы. Не стоит ждать жёсткого потолка, чтобы обнаружить созданный агентом дорогой или доступный извне сервис. Владельца биллинга также желательно отделять от разработчика, который экспериментирует, если в проекте есть бизнес-данные или доступ клиентов. Человек, способный повысить лимит, должен понимать, какой деплой финансируется, зачем он нужен и как проект будет остановлен. Небольшой бюджет всё равно может создать серьёзную проблему безопасности или доступности, если он позволяет запустить неподходящую рабочую нагрузку. ## Что действительно изменилось по сравнению с прежним подключением к облаку Речь идёт не просто о более удобной консоли AWS. При традиционном подключении к облаку люди сначала переводят идею приложения в набор инфраструктурных решений, а уже потом выполняют деплой. Новый сценарий позволяет разработчику и агенту принимать многие из этих решений интерактивно, внутри проекта с управляемыми провайдером настройками по умолчанию. Это меняет профиль риска по четырём направлениям. Во-первых, сокращается время между созданием идентичности и появлением инфраструктуры, похожей на продакшен. До того как состоялась бы обычная встреча по проверке, у разработчика уже могут быть публичный API, база данных и роль выполнения. Во-вторых, становится менее предсказуемым исполнитель изменений. Человек обычно понимает, какую страницу консоли или конвейер деплоя он использует. Агент может изучить репозиторий, выбрать архитектурный вариант, установить инструменты, вызвать несколько API и повторить попытку после ошибки. Результат может быть корректным, но восстановить последовательность действий трудно, если журналирование и проверка не встроены в процесс. В-третьих, граница между приложением и платформой становится менее заметной. Задача по программированию может побочным эффектом создать IAM-роли, хранилища данных и сетевой доступ. Поэтому одного code review недостаточно. Изменения инфраструктуры и разрешений должны иметь собственную поверхность проверки. В-четвёртых, стартовая среда может приобрести организационное значение до того, как кто-либо решит, остаётся ли она стартовой или становится продуктовой. Прототип может начать собирать пользовательские данные, стать основой клиентской демонстрации или получить доменное имя. Необходимость усилить контроль может возникнуть раньше, чем команда формально объявит среду продакшеном. Это не аргументы против нового опыта. Это причины добавить быстрое правило перехода: любой проект, который обрабатывает чувствительные данные, обслуживает внешнего пользователя или существует дольше короткого эксперимента, должен пройти явную проверку безопасности и владения. ## Практическая проверка в первый час Команда может сохранить большую часть скорости нового сценария, добавив немного дисциплины. Проверка не обязана воспроизводить весь корпоративный процесс создания landing zone. Она должна ответить, ограничен ли проект, наблюдаем ли он и можно ли его откатить или остановить. ### Подтвердите идентичность и владельца Запишите, какая личная или организационная идентичность создала AWS Builder ID и проект. Если это не личный эксперимент, убедитесь, что адрес электронной почты контролируется компанией. Добавьте как минимум одного ответственного коллегу через поддерживаемый механизм доступа и зафиксируйте, кто может приглашать других участников. Не считайте вход через социальную учётную запись доказательством того, что организация владеет полученной рабочей нагрузкой. Владение — это бизнес-процесс. Запись о проекте, контакт для биллинга, репозиторий и владелец данных должны указывать на одну ответственную команду. ### Зафиксируйте начальный регион и границу проекта AWS создаёт первый проект в одном из трёх регионов и присваивает ему новое имя. Зафиксируйте регион до развёртывания сервисов, зависящих от данных. Проверьте задержку, требования к размещению данных, доступность сервисов, условия поддержки и предположения о восстановлении. Регион по умолчанию — отправная точка, а не глобальная архитектура. Перечислите ресурсы, созданные первым деплоем, и определите, не является ли какой-либо из них публичным. Для небольшого API это обычно означает проверку конечной точки, конфигурации API Gateway, доступа к хранилищу, доступности базы данных, мест назначения журналов и разрешений, используемых ролью выполнения. ### Проверьте роли до добавления данных Изучите автоматически созданные роли и их доверительные политики. Определите, какой субъект может принять каждую роль и какие сервисы или действия она может вызывать. Особенно внимательно проверьте роли, применяемые вычислительными ресурсами, деплоем или процессами управления инфраструктурой: AWS отмечает, что они могут оказаться шире, чем требуется окончательной рабочей нагрузке. Если приложение должно существовать дольше эксперимента, запланируйте проверку Access Analyzer после того, как рабочая нагрузка пройдёт обычные сценарии. Не удаляйте автоматически каждое действие, которое анализатор назвал неиспользуемым. Сопоставьте рекомендацию с требованиями к резервному копированию, обслуживанию, реагированию на инциденты и периодическим задачам. ### Сделайте полномочия агента явными Разделите разрешения, необходимые для чтения исходного кода, и разрешения для изменения инфраструктуры. Если агент может выполнять деплой, требуйте проверяемое изменение и одобрение человека для продакшена или необратимых операций. Не храните секреты в подсказках, репозиториях и сгенерированной конфигурации. Для экспериментов используйте отдельный проект, чтобы агент не мог случайно получить доступ к несвязанным средам. Саму конфигурационную подсказку следует хранить или указывать в контролируемом месте. Проверяйте обновления AWS CLI, Agent Toolkit и любые рекомендации для репозитория, которые создаёт агент. Файл с инструкциями проекта может повысить единообразие, но он всё равно является входными данными для автоматизированной системы и должен быть защищён от непроверенных изменений. ### Установите условие остановки Задайте лимит расходов до начала существенной работы над проектом. Добавьте получателей уведомлений, которые не ограничиваются первоначальным разработчиком. Решите, что должно произойти при достижении лимита: приостановить проект, расследовать ситуацию, сохранить журналы, повысить лимит или закрыть проект. Для эксперимента установите срок окончания и назначьте человека, который удалит больше не нужные ресурсы. Внутренняя запись о проекте может быть совсем простой: ```text Владелец: указанная команда, а не личный прототипный аккаунт Назначение: описание рабочей нагрузки в одном предложении Класс данных: публичные, внутренние, конфиденциальные или ограниченные Регион: начальный регион AWS и причина выбора Полномочия агента: только чтение, деплой в тест или одобренный путь в продакшен Бюджет: лимит проекта, получатели уведомлений и дата окончания Правило продвижения: проверка обязательна до появления внешних пользователей или чувствительных данных ``` Ценность такой записи не в формате. Важно, что команда делает решения видимыми до того, как проект становится трудно свернуть. ## Когда новый сценарий подходит Упрощённый путь хорошо подходит разработчику, проверяющему идею, небольшой команде, создающей одноразовый сервис, преподавателю или учащемуся, работающему в рамках ограниченного бюджета, а также организации, которой нужны изолированные прототипы без обязательного прохождения каждым разработчиком полного процесса выдачи аккаунта. Модель проектов, автоматическая настройка и ограничение расходов напрямую устраняют трение, из-за которого люди часто начинают неформально использовать облачные ресурсы. Гораздо менее очевидно, что такой путь подходит рабочей нагрузке, которой с самого начала нужны политики организации, написанные централизованно, сложное разделение между несколькими аккаунтами, строгие региональные ограничения, уже действующая федерация идентичностей, обработка регулируемых данных или продакшен-деплой с большим радиусом поражения. Такие команды всё ещё могут использовать новый сценарий для песочницы, но не должны путать быструю песочницу с продакшен-плоскостью управления. Решает не то, использует ли команда ИИ. Подключение агента делает изменения заметнее, но те же вопросы относятся и к человеку, работающему через консоль. Кто может менять среду? Какие разрешения выданы? Какие данные могут попасть внутрь? Как проверяются изменения? Как организация узнаёт, что существует? Как она остановит рабочую нагрузку и восстановит данные? ## Более широкий вывод об инфраструктуре Облачные провайдеры годами упрощали использование отдельных сервисов. Теперь AWS делает первый аккаунт и первый деплой похожими на рабочий процесс приложения. Это закономерная реакция на разработку с помощью ИИ, когда человек, формулирующий подсказку, ожидает, что платформа автоматически решит инфраструктурные детали. Компромисс состоит в том, что управление облаком приближается к самому моменту создания. Проверка безопасности, которая начинается после того, как агент уже создал ресурсы, превращается в уборку. Короткая проверка границы проекта, полномочий агента, ролей, региона и бюджета работает как механизм безопасного запуска: она объясняет разработчику, что разрешено делать, а что требует эскалации. Собственные опубликованные рекомендации AWS указывают на многоуровневый подход. Используйте настройки по умолчанию для старта, а затем проверяйте минимальные разрешения по мере того, как рабочая нагрузка становится известной. Применяйте автоматическое сканирование и детерминированные проверки для сгенерированных изменений. Сохраняйте одобрение человека для действий с высоким воздействием. Считайте внешний текст, инструкции репозитория и ответы инструментов потенциально недоверенными входными данными. Новый опыт AWS для разработчиков лучше понимать как более быстрый вход в облако с новой контрольной точкой, а не как замену операционным практикам. Первый проект можно создать за несколько минут. Первую проверку управления следует провести с такой же скоростью. ## Источники В статье использованы материалы AWS News Blog, документация AWS Account Management и IAM, публикация AWS Security Blog о контрольной модели для ИИ-кодинговых агентов, а также документ OWASP Top 10 for Large Language Model Applications v2.0. Ссылки на исходные материалы приведены в соответствующих разделах статьи.