뒤늦게 작성하는 AWS보안 실습 워크샵 후기

4/19일에 진행된 오프라인 보안 실습을 진행하러 강남 센터필드에 있는 AWS를 방문했다
오후 1시부터 오후 5시까지 약 4시간 가량 진행이 되는 실습이였다. 내가 생각했던 것보다 실습장이 컸고 많은 회사의 개발자들이 와있었다. 데브옵스에 대한 보안 실습이였기 때문에 걱정이 많이 됐었다. 하지만 실습 환경이 굉장히 준비가 잘 되어 있었고 써져 있는대로만 테스트를 하면 크게 문제가 없어보였다. 그리고 무엇보다 막혔을때 도와줄 분들이 (아마도 aws관계자분들인거 같다 ㅎㅎ) 많이 계셔서 실습 도중에 막히거나 의문이 드는 부분에 대해서는 부담없이 질문 할 수 있었다. ㅎㅎ

진행했던 실습은 AWS에서 제공하는 CI/CD 파이프라인을 설정하여 자동 빌드를 통해 배포를 자동화하는 실습을 진행했다. CodePipeline을 사용하여 코드 변경이 있을 때마다 코드를 빌드, 테스트 및 배포하는 실습도 진행이 되었다. 실습 환경은 fastapi - python를 사용하게 되었는데 이미 만들어져 있는 프로젝트를 push하여 배포되는 과정을 보게 됐다. 이 과정에서 SAST, DAST라는 어플리케이션 보안을 점검할 수 있는 서비스를 사용해보았다.

• SAST: 정적 어플리케이션 보안 점검
• DAST: 동적 어플리케이션 보안 점검

어떤 개발자든지 데이터를 도난당하기 쉬운 취약한 코드를 만들 수 있다. 그렇기 때문에 애플리케이션 보안 테스트는 코드가 안전하고 취약성과 보안 문제가 없는지 확인하는 데 필수적이지만 어떤식으로 보안이 뚫리는지에 대해서는 눈으로 본적이 없었다. 실제로 실습에서 어떤 보안이 취약한 코드로 만들어진 테스트를 위한 사이트가 있었고 해당 사이트를 502로 만들어 보라는 강사님의 이야기가 있었다. 대충 이야기를 해보자면 중괄호 안에서는 exit, quit와 같은 스크립트 명령어가 먹히는 검색창이 있었고 이를 활용해서 서버를 다운시키는 퀴즈였다. (참고로 나는 2 / 0을 넣어보았고 502는 뜨지 않았지만 divide by zero에 관련된 에러가 떴었다.) 이렇게 빈틈이 있는, 보안성이 취약한 사이트를 만들어놓고 여러 테스트를 통해서 보안이 어떻게 뚫릴 수 있는지를 보았다.

이러한 보안성에 취약한 코드를 사전에 점검하고 문제점을 알려주는 서비스가 바로 위의 SAST, DAST이다.

찾아보니 SAST는 소스 코드를 통계적으로 검사하여 애플리케이션 취약점 및 SQL 인젝션과 같은 결함을 포함한 모든 취약점 소스를 감지하여 애플리케이션을 보호하는 테스트 접근 방식이다 SAST는 결함을 탐지하기 위해 애플리케이션의 내부 구성 요소를 광범위하게 분석하기 때문에 “화이트박스” 보안 테스트라고도 불리며 빌드가 완료되기 전에 애플리케이션 개발 초기 단계의 코드 수준에서 수행되고 응용 프로그램의 구성 요소가 테스트 환경에 결합된 후에도 수행할 수 있다

DAST는 작동 상태에서 애플리케이션 또는 소프트웨어 제품을 테스트하는 프로세스이다. DAST를 사용하여 배포 후 런타임에 애플리케이션의 모든 보안 결함을 찾을 수 있고 인증 문제, 서버 설정, 논리 오류, 타사 위험, 암호화 취약성 등을 포함한 다양한 항목을 검사할 수 있다.

사실 모든게 만들어져 있는 실습 환경에서 거의 복사 붙여넣기로 테스트를 진행했기 때문에 각 서비스에 대한 이해는 완벽히 할 수 없었지만 AWS에서 제공해주는 기능에 대해 새롭게 알 수 있었고 실제로 보안이 뚫린다는게 거창한데서 뚫리는게 아니라 생각지도 못한곳에서 뚫릴 수 있다는 걸 알게 되었다. 기회가 된다면 서비스에 적용 시켜보는것도 나쁘지 않을것 같다.

근데 테스트 환경이라서 그런지.. 배포 되는 과정이 굉장히.. 굉장히 느렸다.. 적용시킨다면 배포시 걸리는 평균적인 시간은 고려해봐야 할 듯 싶다.

실습을 하면서 강사님이 했던말이 기억에 남는다. “사실,, 보안에 돈을 많이 쓰면 이런 복잡한거 안해도 됩니다”, “우리 서비스 털어 갈려는 흔적도 없다고 보안에 투자하는 돈 낭비라고 생각하고 투자를 없애는날 털립니다.”