Infraestrutura como Código – Cinco fatores que podem quebrar um pipeline DevSecOps

RÔMULO CONCEIÇÃO * 

O uso de pipelines para deploy de aplicações já está amplamente consolidado e é o que esperamos dos times de DevOps. A pipeline de infraestrutura como código, porém, ainda não está tão consolidada assim e é esse o tema do nosso artigo hoje.

A nuvem pública nos permitiu ter uma uniformidade na criação dos recursos computacionais, de armazenamento de rede e de segurança, ao manipular a infraestrutura com um código.

No padrão Infra as Code (IaC) temos diversas vantagens semelhantes as de código de aplicações e negócios, por meio da qual analisamos a qualidade da codificação das regras de negócio, sintaxe, existência de comentários além da própria complexidade lógica.

Ao analisarmos alguns fatores que podem quebrar a build de um pipeline de código, percebemos que duplicidades de trechos de código superior a 30%; que complexidade ciclomática menor que 21 e que cobertura de código menor que 50% costumam ser comprometedores.

Na IaC outras análises nos ajudam a garantir a segurança do ambiente permitindo interromper a pipeline de criação da infraestrutura e, consequentemente, a alteração ou criação dos recursos tecnológicos.

Abaixo, elencamos 05 (cinco) fatores que poderiam quebrar a construção de um pipeline de infraestrutura como código:

1 – Permissões Abusivas: 

Um exemplo seria o parse no código de infraestrutura AWS validando uma permissão muito abusiva.

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “Stmt1623338417213”,
“Action”: [““], “Effect”: “Allow”, “Resource”: ““
}
]
}

“Action”: [“*”], especifique os serviços e as ações permitidas que deverão ser acessados por essa role.

Essa analise de segurança evita permissões abusivas sendo representada pelo *, o desenvolvedor de infraestrutura pode utilizar as ferramentas dos provedores para auxilio nessa configuração.

Ex: AWS – https://awspolicygen.s3.amazonaws.com/policygen.html

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “Stmt1623338417213”,
“Action”: [
“ec2:CopyImage”,
“ec2:DescribeImageAttribute”,
“ec2:DescribeImages”
],
“Effect”: “Allow”,
“Resource”: “*”
}
]
}

2. Attache de IPs válidos em recursos de IaaS em subnet privada 

IPAddress:
Type: AWS::EC2::EIP
IPAssoc:
Type: AWS::EC2::EIPAssociation
Properties:
InstanceId: !Ref ‘EC2Instance’
EIP: !Ref ‘IPAddress’
Tags:
Name: id-autorizacao
Value: 12345

3. Alteração de regras de in bound  para o mundo 0.0.0.0/0 

InstanceSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Enable SSH access
SecurityGroupIngress:
– IpProtocol: tcp
FromPort: ’22’
ToPort: ’22’
CidrIp: ‘0.0.0.0/0’

4. Attache do internet gateway em tabelas de roteamento de subnets “privadas”

InternetGateway:
Type: “AWS::EC2::InternetGateway”
Properties:
Tags:
Key: “Name”
Value: “IGW-DEFAULT”

GatewayToInternet: 
  Type: "AWS::EC2::VPCGatewayAttachment" 
  Properties: 
    VpcId: 
      Ref: "VPC" 
    InternetGatewayId: 
      Ref: "InternetGateway" 


PublicRoute: 
  Type: "AWS::EC2::Route" 
  DependsOn: "GatewayToInternet" 
  Properties: 
    RouteTableId: 
      Ref: "PrivateRouteTable" 
    DestinationCidrBlock: "0.0.0.0/0" 
    GatewayId: 
      Ref: "InternetGateway" 

5. Lançamentos de instâncias fora da lista de famílias computacionais padrão 

Parameters:
InstanceType:
Description: WebServer EC2 instance type
Type: String
Default: t3.large
AllowedValues: [t3.medium, t3.large, t3.xlarge, t3.2xlarge]
ConstraintDescription: must be a valid EC2 instance type.

O Interessante é o que se busca na qualidade de código de desenvolvimento de aplicações.  

• Legibilidade 
• Manutenibilidade 
• Baixa Complexidade 
• Reusabilidade 

O código de infraestrutura se busca analisar 

• Segurança 
• Padronização 
• Custos 

Portanto o DevSecOps

“Se você quiser uma definição simples de DevSecOps, é abreviação de desenvolvimento, segurança e operações. Seu mantra é responsabilizar todos pela segurança com o objetivo de implementar decisões e ações de segurança na mesma escala e velocidade que as decisões e ações de desenvolvimento e operações.”

https://www.forcepoint.com/cyber-edu/devsecops

“DevSecOps significa pensar em segurança de aplicativos e infraestrutura desde o início. Também significa automatizar alguns portões de segurança para evitar que o fluxo de trabalho do DevOps desacelere. Selecionar as ferramentas certas para integrar continuamente a segurança, como concordar”

https://www.redhat.com/en/topics/devops/what-is-devsecops

Conclusão

O uso de ferramentas SAST “Static Application Security Testing” está cada vez mais evidente para uma pipeline de DevSecOps e o comportamento dos desenvolvedores em se preocupar com segurança, custos e operações é evidente no seu dia-a-dia por isso essas rotinas de qualidade de código são importantes.

Neste sentido, considerando tudo o que expomos acima, o Grupo Mult possui a expertise necessária para auxiliá-lo entendendo as particularidades do seu negócio, da sua arquitetura corporativa e, não apenas apoiá-lo na melhor escolha, como também, na estratégia da sua migração.

(*) Arquiteto de Nuvem no Grupo Mult