Cloud9

지금부터 릴리스 자동화, OWASP Top 10, SAST, SCA, Optional, DAST, 보안 코드 리뷰를 살펴볼 것이다. 

아직 완벽히 이해가 되지 않았고 오류도 많이 발생했지만 하나씩 살펴보겠다

• 다음과 같은 릴리스 파이프라인을 구성하는게 릴리스 자동화의 목표이다.

앞으로 보일 서비스에 대한 간단한 용어를 정리해봤다.

• 사용하는 서비스
  • AWS CodeCommit  - Git 레포지토리
  • AWS CodeBuild  - 웹 애플리케이션에서 컨테이너를 빌드하고 이를 Private Container Registry에 게시하는 통합 서비스
  • Amazon ECR  - Private Container Registry
  • AWS CodePipeline  - 릴리스 파이프라인을 오케스트레이션 할 지속적 배포 서비스
  • Amazon ECS on Fargate  - 웹 애플리케이션을 배포할 컴퓨팅 리소스

릴리스 자동화 

 

1. AWS Cloud9에 액세스를 한다. 

 

 

2. cloud9를 입력하고 아래와 같이 Open IDE  버튼을 클릭한다. 

 

3. AWS Cloud9 으로 이동하여 터미널 창으로 이동한 다음 파이프라인 코드를 다운로드 한다. 

curl 'https://static.us-east-1.prod.workshops.aws/public/f3f1ca24-1266-4cd6-9bca-979f70f1fa25/assets/pipeline.zip' --output pipeline.zip
unzip pipeline.zip -d pipeline && rm pipeline.zip

 

4. 그렇게 되면 pipeline이라는 새폴더가 생긴다. 

 

AWS CDK 구성

AWS Cloud Development Kit으로 코드로 클라우드 인프라 구성을 하는 것이다. 

다음과 같은 코드로 CDK를 구성한다. ( 그냥 python으로 가상환경 설정을 하는 것이다. ) 

cd ~/environment/pipeline
python3 -m venv .venv
source .venv/bin/activate

파이프라인 및 도구 배포 

이제 작동하는 CDK 환경이 준비되었으나 릴리스 파이프라인을 배포할 수 있다. 

 

일단 이런 파이프라인으로 해보겠다는데,, 아직 잘 모르겠다... 

그리고 다음과 같은 명령어를 실행한다. 

cdk bootstrap // cdk 명령을 실행하기 전에 cdk가 배포를 수행하는 데 필요한 리소스 가져오기 
cdk synth // cdk가 제대로 설치 및 구성이 되었는 지 확인 
cdk deploy --require-approval never // release pipeline을 배포하도록 한다.

설치가 완료되면 다음과 같다. 

 

위으 코드를 통해 flask-app이라는 빈 레지토리가 생성됨을 알 수 있다. 

해당 코드 config.yaml코를 통해 생성이 된 것 같다. 

config.yaml코드는 다음과 같다. 

 

### Staging Auto-Deploy
auto_deploy_staging: False
initial_image: public.ecr.aws/adelagon/flask-app:latest

### Static Application Security Testing (SAST) Step
sast:
  enabled: True

### Software Composition Analysis (SCA) Step
sca:
  enabled: True

### License Checker Step
license:
  enabled: True

### Dynamic Application Security Testing (DAST) Step
dast:
  enabled: False
  zaproxy:
    instance_type: t3.medium
    api_key: SomeRandomString

 

 

AWS 콘솔 검색창에 Elastic Container Reigstry를 선택하면 flask-app이라는 새 비공개 저장소가 표시되어야 한다. 

 

vpc도 배포,, repository도 배포,, codebuild에도 배포,, 다 배포가 됐다. 

 

->  릴리스 자동화라는게 사실 잘 이해가 되지는 않는다. .. 

 

OWASP Top 10 

이번 파트에서는 침투테스터의 대상이 되는 응용프로그램을 살펴보겠다. 

 

파라미터 공격 

CloudFormation에서 AppSecWorkshopStack을 선택한다. 그리고 해당 스택에 들어가서 TasksFlaskAppServiceURL을 클릭하여 웹 사이트를 열어야 한다. 

여기서 인젝션, Broken Authentication, Broken Access Control, 보안 구성 오류, Cross-Site-Scripting 공격을 수행해볼 수 있다. 

 

 

Injection 

HTML 마크업을 사용하여 코드가 데이터를 동적으로 인젝션 할 수 있는지 .... 

jinja 템플릿은 이중 괄호를 사용한다. .... 

{{request.application.__globals__.__builtins__.__import__('os').popen('ls').read()}}

해당 명령어를 사용하면 현재 디렉토리 list를 할 수 있다.

Broken Authentication

-> 인증권한을 탈취한다. 

 

Broken Access Control 

-> 적절한 접근 제어 확인이 없기 때문에 관리자 권한이 없어도 누구나 다른 사람의 프로필을 볼 수 있다. 

 

보안 구성 오류 

-> http 헤더에 서버의 종류가 들어가 있고 개발 환결병 설정이 들어가있어 공격자가 애플리케이션에 대한 많은 정보를 수집할 수 있다. 

 

Cross - Stie Scripting ( XSS ) 

XSS를 사용하면 공격자가 피해자의 브라우저에서 스크립트를 실행할 수 있어 사용자 세션을 가로채는 것을 말한다. 

 

즉 공격자가 악성 스크립트를 포함한 웹 링크를 피해자에게 보내면 피해자가 그걸 클릭을 하면 해당 악성 웹 페이지가 실행되는 것을 말한다. 

 

 

SAST (Static Application Security Testing )

1. 코드 저장소를 초기화를 한다.

2. 코드를 다운로드 받아 git에 올린다. 

3. 그렇게 되면 codecommit에 있는 repository에 해당 코드들이 올라간 것을 확인할 수 있다. 

4. codepiepline 대시보드로 이동을 하면 git push를 수행할 때 자동으로 트리거가 되는 것을 확인할 수 있다. 

그 후 Sonar Qube로 들어가게 되면 다음과 같은 정보들을 확인할 수 있다. 

이렇게 SAST 세부 정보로 들어가면 SAST 결과가 나오게 된다. 

 

SAST : 코드 스캐닝을 하고  보안 약점이 있는 코드를 자동으로 수정하는 것을 말한다. 

SCA :  오픈소스 보안을 목적으로 코드에 대한 사용량 등을 가시화하는 것을 말한다. 
참고자료는 다음과 같다. 

https://insight.infograb.net/product/snyk/

DevOps 보안툴 Snyk 소개| 인포그랩 | GitLab기반 DevSecOps 구축,컨설팅,교육,CICD Pipeline,기술 지원 서비

작동 원리는 다음과 같다. 

1. CodCommit에 코드를 commit을 한다. 

2. CodePipeline에 설정된 CloudWatch에 의해 CodeBuild를 호출하게 된다. 

3. CodeBuild에 있는 buildspec.yml 파일에 의해 SonarQube에 Source Code를 넣어 정적 분석을 하게 된다 .

 

 

그 다음으로 살펴볼 것은 SCA 이다. 

SCA  ( Software Composition Analysis) 

등장 이유 

개발자들이 오픈 소스 구성 요소를 사용하여 엄청난 양의 작업을 하면서 보안 문제를 추적하는 것은 어렵게 됐고, 이와 같은 상황에서 소스코드의 사용량을 시각화하여 볼 수 있는 SCA가 등장하게 됐다 . 

 

종속성 확인  & 안전하지 않은 종속성 수정 

 

CodePipeline에 들어가면 SCA 단계가 실패했다는 것을 볼 수 있는데 버전 문제을 업그레이드 혹은 다운그레이드 해야한 다는 것을 알려준다.

-> 따라서 requirement.txt를 수정하여 다음과 같은 오류를 해결해준다. 

 

라이센스 분석 (Optional) 

-> 말 그대로 승인되지 않은 라이센스가 있는 지 확인을 한다. 

위에서 했던 것처럼 작업 실행 실패를 누르면 어떠한 원인으로 오류가 발생했는 지 알려준다. 

여기서는 wdb가 승인되지 않은 라이센스라고 오류가 떴다. 

그러면 마찬가지로 requirement.txt에서 wdb 설치 관련은 지워주면 된다 

 

이제 자동화된 보안 결과를 모두 수정을 했으므로 

그리고 마지막으로 git push를 하여 CodeCommit에 푸시를 한다. 

-> 그러면 정상적으로 build가 됐음을 확인할 수 있다 .

 

 

DAST  ( Dynamic Application Security Testing )

DAST는 웹 애플리케이션을 스캔하고 테스트하는 것을 말한다. 다만 SAST와 달리 소스 코드를 스캔하지 않는다. 

이를 침투 테스트라고 불리기도 한다. 

 

동작 과정은 다음과 같다. 

 

 

웹 애플리케이션을 배포하기 위해 파이프라인을 업데이트 해야 한다. 

DAST는 애플리케이션 런타임 중에 수행되기 때문에 ECS를 사용하여 배포를 해야 한다. 

배포를 하게 되면 즉시 분석을 수행하는 DAST 단계가 활성화가 된다. 

 

auto_deploy_stagin을 false에서 True로 설정하여 파이프라인에 배포되는 config.yaml 파일을 활성화한다. 

그 후 cdk deploy --require-approval never 
해당 명령어를 통해 배포한다.

 

그 후 Release Change 버튼을 클릭을 하면 배포가 된다. 

 

굳 ... !!