Архитектура и решения безопасности в облаке часть 104.06.2022 15:01

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

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

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

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

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

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

resource "yandex_vpc_security_group" "RESOURSE-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 							
  }
  
}

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

Стандарты нашей компании предусматривали использование минимальной гранулярности доступа к группам безопасности. Штатно такой ролью в облаке являлась «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 решения

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

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

Итоги

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

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

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

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

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

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

© Habrahabr.ru