При увеличении объёма использования облачных ресурсов возникла необходимость встраивания методологии CI/CD в процесс облачной разработки, так как в текущем варианте скорость раскатки приложений и сервисов хоть и стала быстрее, но по концепции не сильно отличалась от baremetal-инфраструктуры.

При обсуждении архитектуры решения обнаружилось несколько факторов, которые препятствовали внедрению данных методик в используемом компанией облаке (Яндекс.Облако). В статье я расскажу компромиссные методы преодоления этих препятствий.

Согласование сетевых и системных доступов в нашей компании — это отдельный процесс, который находится в зоне ответственности подразделения информационной безопасности и подразумевает использование согласованной матрицы ролей для системных и ACL (Access Control List) для сетевых доступов.

Разработчики и администраторы облачной инфраструктуры получали доступ к набору ролей, который не включал возможностей управления “Группами Безопасности

Команда информационной безопасности осуществляла переход на описание Групп безопасности при помощи Terraform. Для повышения эффективности перехода внутри команды мной было организовано обучение коллег базовым концепциям Infrastructure as Code. После обмена опытом увеличилась скорость обработки запросов на предоставление доступа в части облачной инфраструктуры.

Пример группы безопасности в Terraform

resource "yandex_vpc_security_group" "RESOURCE-NAME-SG-1" {
  name        = "SG-NAME"
  description = "you comment"
  network_id  = "NETWORK_ID"
  folder_id =   "ID-folder" #указываем id фолдера, для которого предназначены SG
    
  ingress { #входящий доступ
    protocol       = "TCP"
    description    = "sample"
    v4_cidr_blocks = ["172.27.0.0/16"]
    port           = 22
  }
  
  egress { #исходящий доступ
    protocol       = "TCP"
    description    = "sample"
    v4_cidr_blocks = ["172.27.0.0/16"]
    from_port      = 8080
    to_port        = 8099
  }
  
  egress {
    protocol       = "ANY"
    description    = "sample"
    security_group_id  = "SG-ID" # SG сошлется на другую SG
    port      = 6432
   }

  ingress {
    protocol          = "ANY"
    description       = "sample"
    predefined_target = "self_security_group" #SG сошлется на саму себя
    from_port      = 1
    to_port        = 65535
   }  

  ingress {
    protocol       = "TCP"
    description    = "rule1 description"
    predefined_target = "loadbalancer_healthchecks" #Проверка состояния балансировщика
    port           = 8080 							
   }
}

Пример корпоративной матрицы ролей:

Роль

Права доступа

Администратор Kubernetes 

viewer

k8s.admin

Администратор виртуальных

машин каталога(базовая роль)

viewer

vpc.viewer

compute.admin

load-balancer.privateAdmin

alb.editor

Администратор сети облака

viewer

vpc.admin

load-balancer.admin

Владелец облака

cloud.owner

Пользователь Container Registry каталога

container-registry.images.pusher

Администратор Container Registry каталога

container-registry.admin

Пользователь хранилища каталога

storage.editor

Администратор хранилища каталога

storage.admin

Пользователь сервисных аккаунтов каталога

iam.serviceAccounts.user

iam.serviceAccounts.tokenCreator

Администратор хранилища сертификатов каталога

certificate-manager.admin

Администратор мониторинга каталога

monitoring.editor

Пользователь мониторинга каталога

monitoring.viewer

Read-only Пользователь каталога

viewer for folder

Read-only Пользователь облака

viewer for cloud

Администратор баз данных каталога

mdb.admin

Пользователь баз данных каталога

mdb.viewer

Администратор Key Management Service

kms.admin

Пользователь Key Management Service

kms.keys.encrypterDecrypter

Пользователь Datalens в облаке

datalens.instances.user

Администратор Datalens в облаке

datalens.instances.admin

Стандарты нашей компании предусматривали использование минимальной гранулярности доступа к группам безопасности. Штатно такой ролью в облаке являлась “vpc.securityGroups.admin” назначающая права доступа к созданию, редактированию и удалению групп безопасности. При использовании мультифолдерной модели передавать данный доступ в управление являлось риском нарушения изоляции dev и prod-сред в облаке.

Для решения этой ситуации был направлен фич-реквест в поддержку облака на создание роли с меньшей гранулярностью. Роль “vpc.securityGroups.user” позволила использовать группы безопасности без возможности их редактирования. Так появилась новая роль для корпоративной матрицы ролей — "Пользователь групп безопасности".

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

Про наш переход использование мультифолдерного подхода вы можете прочитать в статье Как мы переезжали на новую сетевую маршрутизацию и Interconnect в Яндекс.Облаке.

Изменения в процессе при работе с группами безопасности
Изменения в процессе при работе с группами безопасности

Для сбора логов, мониторинга и организации механизма оповещений о действиях в облаке наша команда адаптировала под себя следующие решения из библиотеки Yandex.Cloud Security Solution Library.

Решение с Elastic кластером было использовано для агрегации логов и удобного поиска по событиям и передачей в SOC для построения схемы приоритезации реагирования на критические события.

Решение позволяет собирать, мониторить и анализировать аудит логи в Yandex.Cloud Managed Service for Elasticsearch (ELK) из Yandex Audit Trails

Пример дашборда решения с визуализацией изменений за определенный период
Пример дашборда решения с визуализацией изменений за определенный период
Схема работы SIEM решения
Схема работы SIEM решения

Решение с Yandex Cloud: Trails-function-detector позволило отслеживать и реагировать на критические действия в облаке в реальном времени. Само решения является хорошим примером реализации возможностей различных интеграций с Cloud Functions. В нашей компании оно развёрнуто с необходимыми доработками, реализованными в рамках задач мониторинга информационной безопасности.

Схема решения Yandex.Cloud Trails-function-detector
Схема решения Yandex.Cloud Trails-function-detector

Итоги

Использование новых принципов и подходов отлично сработало. Использование групп безопасности позволило совместить несовместимое и при этом дало возможность получить запас изоляции dev и prod сред.

Управляемые сервисы Yandex Cloud позволили значительно ускорить процессы разработки:

Было: команда разработки делает заявку на создание нужных ресурсов, ресурсы развёртываются подразделением инфраструктуры или членами команды срок ожидания составляет от нескольких часов до нескольких дней.

Стало: команда информационной безопасности создаёт группы безопасности с использованием Terraform для планируемой схемы инфраструктуры, а команда разработки сама создаёт нужные ресурсы в dev и prod-окружении по требованию за несколько минут, используя предварительно согласованный список доступов.

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

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

Комментарии (4)


  1. V_Winter
    06.06.2022 13:20
    +1

    В целом – отличная статья.
    Конечно, возникают вопросы относительно примера корпоративной матрицы ролей и упоминания “vpc.securityGroups.admin” и “vpc.securityGroups.user”. Можно было обфусцировать ID и предложить некую взаимосвязь.


    1. innomaker Автор
      06.06.2022 13:25

      “vpc.securityGroups.admin” и “vpc.securityGroups.user” стандартные Роли в Яндекс.Облаке, их упоминания есть в документации. В примере матрицы, как раз и указывается взаимосвязь с удобно читаемыми ролями, которые запрашивает пользователь.


      1. V_Winter
        06.06.2022 13:42
        +1

        К сожалению, подобная связь не очевидна.
        Опять же, говорить, что vpc.securityGroups.user это стандартная роль после фразы "Для решения этой ситуации был направлен фич-реквест в поддержку облака на создание роли с меньшей гранулярностью. Роль “vpc.securityGroups.user” позволила использовать функционал групп безопасности без возможности их редактирования".

        P.S. Избавьтесь от слова "функционал".


        1. innomaker Автор
          06.06.2022 14:02

          Немного дополнил, надеюсь теперь более очевидно