Переменная облачность

Начинать работать с безопасностью облаков проще всего до момента их появления. Я поясню. По аналогии с тем, как облака на небе когда-то были водой в океане (или наоборот), так и облака в AWS когда-то были описаны с помощью специального языка разметки. Стоп, а как же удобный GUI, клик-клик, создать новую EC2? Так тоже можно, но не стоит.

Конечно, можно. Но представьте, что вам нужно создать 100 виртуальных машин в 5 регионах? А потом ещё всё то же самое для тестового окружения. А потом ещё раз. А потом внести изменения во всё это. А потом всё сломалось, и вы решили, что искать ошибку слишком долго, а проще накатить по новой.

Как раз тут и возникает идея про инфраструктуру как код (Infrastructure as code). Представьте, что можно описать всю вашу сложную инфраструктуру с серверами, пользователями, дисковыми массивами, сетями и всем остальным с помощью языка программирования. В AWS эта служба называется AWS Cloudformation, и есть инженеры, которые целую карьеру построили на создании таких инфраструктур. Тут сразу нужно оговориться, что не обязательно пользоваться штатным инструментом для создания инфраструктуры. Сейчас есть решения, которые вообще не привязаны к какому-то поставщику услуг, например, тот же TerraForm. Если вы вдруг решите переехать с AWS в Azure, то с помощью TerraForm сделать это будет куда проще. Но пока мы во владениях Amazon, шаблоны Cloudformation – наш выбор. Шаблоны можно разрабатывать на YAML или JSON. Я агитирую за YAML, потому что в нём можно писать комментарии. Или я просто не знаю, как это делать в JSON.

Шаблон CloudFormation состоит из функциональных блоков. Например:

  VPC1:
	    Type: AWS::EC2::VPC
	    Properties:
	      CidrBlock: 10.16.0.0/16
	      EnableDnsSupport: true
	      EnableDnsHostnames: true
	      Tags:
	        - Key: Name
	          Value: production-vpc

Всё, кстати, читабельно – создаём VPC с нужным CIDR блоком, назовём production-vpc. И далее создадим подсеть:

 Subnet1:
	    Type: AWS::EC2::Subnet
	    Properties:
	      VpcId: !Ref VPC1
	      AvailabilityZone: !Select [ 0, !GetAZs '' ]
	      CidrBlock: 10.16.0.0/20
	      Tags:
	        - Key: Name
	          Value: Subnet1

Добавим Security group:

  VPC1SecurityGroup:
	    Type: 'AWS::EC2::SecurityGroup'
	    Properties:
	      VpcId: !Ref VPC1
	      GroupDescription: Enable SSH access via port 22 IPv4 & v6
	      SecurityGroupIngress: 
	        - Description: 'Allow SSH IPv4 IN'
	          IpProtocol: tcp
	          FromPort: '22'
	          ToPort: '22'
	          CidrIp: '0.0.0.0/0'
	        - Description: 'Allow SSH IPv6 IN'
	          IpProtocol: tcp
	          FromPort: '22'
	          ToPort: '22'
	          CidrIpv6: ::/0

и виртуальную машину:

PrivateEC2:
	    Type: AWS::EC2::Instance
	    DependsOn: 
	      - ssminterfaceendpoint
	      - ssmec2messagesinterfaceendpoint
	      - ssmmessagesinterfaceendpoint
	    Properties:
	      InstanceType: "t2.micro"
	      ImageId: !Ref LatestAmiId
	      IamInstanceProfile: !Ref EC2InstanceProfile
	      SubnetId: !Ref Subnet1
	      SecurityGroupIds: 
	        - !Ref VPCBSecurityGroup
	      Tags:
	        - Key: Name
	          Value: MyFirstEC2

Выглядит немного громоздко, но тут как обычно – сделали один раз, пользуемся постоянно.

Но как раз тут и начинаются первые сложности. Логично, что если эта вещь будет тиражироваться постоянно, то специалист по безопасности должен убедиться, что в тираж не пойдет какая-то проблема, которая быстро примелькается и про неё все забудут. Глазами такое не прочитаешь, зато на помощь приходят автоматизированные сканеры, которые помогут найти недостатки. Их довольно много. Первое, на что натыкаются, – это Cfn Nag и Checkov, на них же часто и останавливаются. Тут важно помнить, что это не какой-то искусственный интеллект, моделирующий угрозы. Сканеры, как правило, проверят следующее:

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

Это довольно простые вещи, но это как раз те самые 20%, которые решат 80% проблем в будущем. Тем более, автоматически, тем более, бесплатно.

Злоумышленник будет в восторге, если найдет ваш шаблон, но шаблон ему не поможет, если вы грамотно всё спланировали. А вот если он сможет внести изменения в ваш шаблон, вот тут уже проблема для другого разговора.

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