Проектирование и настройка Yandex Cloud: Terraform, IAM, Security

Вы переезжаете на Yandex Cloud или запускаете новый проект «с нуля». Без грамотного фундамента — неправильная сеть, лишние открытые порты или IAM с правами суперадмина — уже через месяц вы переделываете всё. Особенно остро это ощущается при масштабировании: если изначально не заложить правильную сетевую топологию и разграничение доступа, то каждый новый сервис требует пересборки всей инфраструктуры.

Типичная ситуация: команда разработки наспех развернула приложение в одном каталоге, дала всем роль editor, а спустя две недели случайно удалили production-базу. Мы проектируем облачную инфраструктуру под ключ: от сетевой топологии до мониторинга и compliance. Оценим ваш проект за 1 день. Наш опыт — более 50 успешных проектов на Yandex Cloud, включая миграции банковских систем и e-commerce платформ, где каждый потерянный час стоил миллионы. Гарантируем zero-downtime при развёртывании. Правильно спроектированная облачная инфраструктура снижает операционные расходы на 30% и сокращает время вывода продукта на рынок на 40%. Закажите аудит вашей инфраструктуры — это займет один день и ничего не стоит.

Типичные проблемы в Yandex Cloud

Чаще всего сталкиваются с:

• Неверная организационная структура — все ресурсы в одном каталоге, нет разделения по окружениям. Это приводит к случайным удалениям и перекрёстному влиянию.
• Избыточные Security Groups — открыты порты 0.0.0.0/0, доступ к базам из интернета. Это увеличивает поверхность атаки.
• IAM с переизбытком прав — сервисные аккаунты с role editor на весь каталог. При компрометации одного ключа под угрозой вся инфраструктура.

Эти ошибки мы исправляем на старте, чтобы вы не переплачивали за простой и не теряли данные.

Как спроектировать организационную структуру?

Yandex Cloud строится на трёх уровнях: Organization → Cloud → Folder. Folder — аналог Resource Group в Azure или Project в GCP. Ресурсы живут в Folder'ах, IAM назначается на уровне Organization, Cloud или Folder.

Типичная структура для командного проекта:

Organization: my-company
└── Cloud: my-cloud
    ├── Folder: prod
    ├── Folder: staging
    ├── Folder: dev
    └── Folder: shared-services # мониторинг, registry, bastion

Разные Folder'ы — разные биллинговые метрики и права. Dev-команда получает Editor на dev, read-only на prod. Это позволяет избежать случайного удаления ресурсов в production.

Как спроектировать сеть в Yandex Cloud?

VPC в Yandex Cloud — глобальная (охватывает все зоны), подсети — зональные. Для production используем классическую схему: public подсети под bastion-хост, private подсети для приложений и баз данных.

resource "yandex_vpc_network" "main" {
  name = "main-network"
  folder_id = var.folder_id
}

resource "yandex_vpc_subnet" "private_a" {
  name = "private-a"
  zone = "ru-central1-a"
  network_id = yandex_vpc_network.main.id
  v4_cidr_blocks = ["10.10.10.0/24"]
  folder_id = var.folder_id
  route_table_id = yandex_vpc_route_table.nat.id
}

resource "yandex_vpc_gateway" "nat" {
  name = "nat-gateway"
  folder_id = var.folder_id
  shared_egress_gateway {}
}

resource "yandex_vpc_route_table" "nat" {
  name = "nat-route"
  network_id = yandex_vpc_network.main.id
  folder_id = var.folder_id
  static_route {
    destination_prefix = "0.0.0.0/0"
    gateway_id = yandex_vpc_gateway.nat.id
  }
}

Private подсети не имеют публичных IP. Исходящий трафик — через NAT-шлюз. Входящий — только через Security Groups. Такая схема предотвращает прямой доступ к базам данных из интернета и снижает поверхность атаки.

Security Groups: минимум правил

Yandex Cloud Security Groups — stateful. Ответный трафик разрешён автоматически. По умолчанию все входящие запрещены. Наш опыт: достаточно 3-5 правил для 80% приложений.

resource "yandex_vpc_security_group" "app" {
  name = "app-sg"
  network_id = yandex_vpc_network.main.id
  folder_id = var.folder_id

  ingress {
    protocol = "TCP"
    port = 8080
    v4_cidr_blocks = ["10.10.0.0/16"]
  }

  ingress {
    protocol = "TCP"
    port = 22
    security_group_id = yandex_vpc_security_group.bastion.id
  }

  egress {
    protocol = "ANY"
    v4_cidr_blocks = ["0.0.0.0/0"]
  }
}

IAM: один сервисный аккаунт = одна роль

Каждый компонент (VM, Kubernetes-ноды, CI/CD) получает отдельный сервисный аккаунт с минимальными правами. Для GitHub Actions используем Workload Identity Federation — временные токены, никаких секретов.

# Создание SA
$ yc iam service-account create --name app-sa --folder-id <folder-id>
# Роль на конкретный ресурс
$ yc resource-manager folder add-access-binding <folder-id> \
  --role container-registry.images.puller \
  --service-account-id <sa-id>

Как создать сервисный аккаунт с минимальными правами?

1. Создайте сервисный аккаунт: yc iam service-account create --name app-sa --folder-id <folder-id>.
2. Назначьте роль только на нужный ресурс, например, container-registry.images.puller на конкретный реестр.
3. Используйте федерацию удостоверений для временных токенов — так вы никогда не храните ключи.
4. Добавьте сервисный аккаунт в группу доступа для простоты управления.
5. Проверьте, что у сервисного аккаунта нет лишних прав, выполнив yc iam service-account list-access-bindings --id <sa-id>.

Object Storage, Registry, мониторинг и соответствие 152-ФЗ

Yandex Object Storage — S3-совместим, с lifecycle-правилами и шифрованием через KMS. Container Registry — без отдельных паролей, всё через IAM. Хранение в Object Storage обходится около $1–1 за ГБ в месяц, что значительно дешевле западных аналогов для российских проектов. Экономия на лицензиях при использовании Managed Service for Kubernetes вместо самостоятельной установки достигает 50%, что в денежном выражении составляет от $270–390 в месяц для среднего проекта.

resource "yandex_storage_bucket" "app" {
  bucket = "my-app-storage"
  folder_id = var.folder_id
  access_key = yandex_iam_service_account_static_access_key.storage.access_key
  secret_key = yandex_iam_service_account_static_access_key.storage.secret_key

  lifecycle_rule {
    id = "logs-cleanup"
    enabled = true
    prefix = "logs/"

    expiration {
      days = 90
    }

    noncurrent_version_expiration {
      days = 30
    }
  }

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "aws:kms"
        kms_master_key_id = yandex_kms_symmetric_key.main.id
      }
    }
  }
}

Yandex Monitoring собирает метрики всех сервисов автоматически. Для логов приложений используем Cloud Logging с retention 30 дней. Алерты через webhook или PagerDuty. Настроим дашборды с ключевыми SLO: latency p99 не выше 200ms, error rate < 0.1%.

Yandex Cloud сертифицирован по 152-ФЗ (УЗ-3). Данные — только российские зоны, шифрование через KMS, аудит через Cloud Audit Trails. Дополнительно настраиваем логирование всех действий. Это закрывает требования регулятора для большинства проектов.

«Yandex Cloud соответствует требованиям 152-ФЗ до УЗ-3» — Официальная документация.

Разграничение доступа на старте

Ошибка IAM — самая частая проблема при аудите. На одном проекте сервисный аккаунт CI/CD имел роль editor на весь каталог. При компрометации пайплайна злоумышленник смог бы запустить криптомайнер на любой VM. Мы исправили: создали отдельные SA для каждой задачи, выдали container-registry.images.puller для сборки, compute.instanceAdmin только для конкретной ноды. Риск упал до нуля.

resource "yandex_iam_service_account" "ci_cd" {
  name        = "ci-cd-sa"
  description = "Service account for CI/CD"
  folder_id   = var.folder_id
}

resource "yandex_resourcemanager_folder_iam_member" "ci_cd_puller" {
  folder_id = var.folder_id
  role      = "container-registry.images.puller"
  member    = "serviceAccount:${yandex_iam_service_account.ci_cd.id}"
}

resource "yandex_resourcemanager_folder_iam_member" "ci_cd_compute" {
  folder_id = var.folder_id
  role      = "compute.instanceAdmin"
  member    = "serviceAccount:${yandex_iam_service_account.ci_cd.id}"
  condition {
    expression = "resource.name == 'my-app-server'"
    title      = "Limit to specific instance"
  }
}

Что входит в работу и сроки

После завершения вы получаете:

• Архитектурную схему сети (draw.io)
• Весь Terraform-код в репозиторий
• Описание IAM-ролей и сервисных аккаунтов
• Runbook по инцидентам
• Доступы к мониторингу и логированию
• Обучение команды (опционально)

Стоимость рассчитывается индивидуально после аудита. Гарантируем сопровождение в течение месяца после сдачи. Свяжитесь с нами, чтобы получить оценку вашего проекта за 1 рабочий день. Получите консультацию — мы расскажем, как оптимально построить инфраструктуру под ваши задачи.