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