BLOG
RECEBA CONTEÚDOS GERADOS POR ESPECIALISTAS ASSINE AGORA

    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

    Multron
    RECEBA CONTEÚDOS GERADOS POR ESPECIALISTAS