코드형 인프라, 보안이 필요한 이유와 베스트 프랙티스

기업들이 클라우드 컴퓨팅을 수용함에 따라 코드형 인프라(Infrastructure as Code, IaC)의 도입 비율이 지속적으로 상승하고 있다. 여러 신기술이 그러하듯 보안은 흔히 IaC 상에서 부차적으로 다뤄지거나 완전히 잊혀진다. IaC의 보안은 중요하다. 이번 기사에서는 IaC를 최적으로 보안하는 방법과 이 중대한 보안 활동을 소홀히 하는 데 따른 위험을 설명한다. 
 

코드형 인프라란 무엇인가? 

전통적인 인프라 전개 방식에는 조달 과정, 물리적 인프라, 긴 대기 시간, 서버 랙이 관여했다. 클라우드 컴퓨팅이 출현했지만, 초기의 인프라 관리 방식은 이른바 ‘클릭-옵스(click-ops)’가 관여했다. 다시 말해 클라우드 서비스 업체(Cloud Service Provider, CSP)의 시스템 콘솔에 수동으로 들어가 인프라를 직접 설정해야 했다. 이 접근법은 비효율적이고 오류가 잦고 기업 클라우드 환경에서 확장의 문제가 있다.
   
IaC는 이 패러다임을 바꾸어 코드 및 프로그램에 의한 인프라 관리를 허용한다. 이는 전통적인 애플리케이션 코드와 거의 비슷하다. 다시 말해 소스 컨트롤, 버저닝, 재사용, 이식성, 드리프트 검출, 자동화 등의 베스트 프랙티스를 이용할 수 있다.
 
인기 있는 IaC 버전으로는 AWS의 클라우드포메이션(Cloudformation), 애저의 블루프린츠(Blueprints) 등의 CSP 전용 IaC가 있다. 또한 인기 있는 서드파티 IaC 선택지도 있다. 인기가 가장 높은 해시코프(HashiCorp)의 테라폼(Terraform)은 1억 회 이상 다운로드됐다. 서드파티 IaC의 효과라면 여러 CSP 환경에서 쓰일 수 있다는 점이다. 

용이성과 함께 하는 위험 

IaC의 온갖 장점에도 불구하고 클라우드 환경으로 불필요한 위험을 유입시키는 것을 피하기 위해 반드시 알아두어야 할 위험들이 있다. IaC 템플릿의 신속한 프로비저닝은 안전하지 않은 구성 및 위험을 기업 전체에 신속하게 유입시킬 수 있다. 공개적으로 이용할 수 있는 IaC 템플릿 역시 마찬가지이다. 이들 템플릿은 보안 모범 관행으로부터의 이탈이나 불안전한 구성을 포함할 수 있고, 흔히 포함하고 있다. 

팔로알토의 ‘유닛 42(Unit 42)’의 ‘클라우드 위협 보고서: 2020년 봄(Cloud Threat Report: Spring 2020)’에서는 여러 우려되는 결과들을 보여준다. IaC에 걸쳐 보안을 실행할 능력이 있음에도 불구하고 기업들은 이를 하지 않았다. 조사를 거친 거의 50%에 이르는 클라우드포메이션 템플릿이 잠재적으로 취약한 구성을 가지고 있었다. 또한 22%에 가까운 테라폼 구성 파일이 최소한 하나의 불안전한 구성을 가지고 있었다.
 
IaC 보안업체인 브릿지크루(BridgeCrew)가 시행한 조사에서 1만 5,000개 이상의 테라폼 파일을 분석한 결과, 거의 50%의 파일에서 데이터를 노출할 수 있거나 워크로드를 훼손할 수 있는 구성 오류가 있음을 발견했다. 이들 파일은 1,000만 회가 넘게 다운로드 되었다.
 
이런 연구에서 알 수 있듯이 기업들은 IaC 이용을 극대화하면서도 흔히 보안 구성 오류와 취약점을 검사하지 않은 채 템플릿을 이용한다. 내부적으로 개발된 IaC 템플릿과 공개 리포지터리에서 입수한 템플릿이 모두 그러하다. 공개 리포지터리이든, 내부 리포지터리이든 IaC 템플릿을 이용할 때에는 주의를 기울여야 하고 구성 오류와 취약점을 검사해야 한다. 

대다수의 클라우드 데이터 침해가 고객의 구성 오류의 결과임을 감안하면 신속하고 역동적인 IaC 프로비저닝을 보다 엄격하게 보안해야 할 것이다. 구성 오류가 대규모로 복제될 가능성이 있기 때문이다. 

IaC 보안 베스트 프랙티스 

IaC는 다른 코드 메커니즘과 동일한 형식으로 사용되기 때문에 이를 유사한 구조 및 워크플로우 안으로 통합할 수 있다. 따라서 소스코드 관리(Source Code Management, SCM) 리포지터리에 저장될 수 있고, 지속 통합/지속 개발(Continuous Integration/Continuous Deployment, CI/CD) 파이프라인에 통합될 수 있고, 런타임 환경에서 검사될 수 있다. 

검토해볼 가치가 있는 IaC 검사 도구는 많이 있다. 인기있는 오픈소스 도구로는 테라스캔(Terrascan), 체코브(Checkov), 테라폼 린터(TFLint)가 있다. 각 도구는 수많은 컴플라이언스 프레임워크에 합치하는 수천 가지 정책에 대해 클라우드 인프라 템플릿을 검사해 컴플라이언스 위반과 취약점을 가져오는 불안전한 구성이 없는 지 확인한다. 

예를 들어 아큐릭스(Accurics)의 IaC 검사 플랫폼은 애저 블루프린츠, AWS 클라우드포메이션 템플릿, 쿠버네티츠 YAML 매니페스트 등의 IaC 템플릿을 스캔할 수 있어 취약한 구성 및 구성 오류가 시스템 환경에 유입되는 것을 차단한다. 아큐릭스는 CIS 벤치마크(CIS Benchmarks), SOC2, PCI DSS, HIPPA 등 10가지 표준에 걸쳐 1,500개가 넘는 정책을 포함한다. 
 

여기에는 템플릿이 처음 생성되어 SCM 리포지터리에 저장될 때 이를 스캔하는 일이 포함된다. 따라서 취약점이나 컴플라이언스 위반이 IaC 제작자에게 전달되어 신속히 치유될 수 있다. 

또한 IaC 템플릿은 다양한 제어 게이트를 갖춘 CI/CD 파이프라인의 일부로서 검사될 수 있어서 이들이 런타임 환경으로 유입되어 조직의 클라우드 환경에 부적절한 위험을 초래하는 일을 막을 수 있다. 이는 클라우드 환경으로 프로비저닝 되는 인프라가 취약점을 가져오지 않음을 확인하는 데 유용하다. 아울러 프로비저닝이 연관 기업 및 산업 컴플라이언스 프레임워크에 부합함을 확인하는 데에도 유용하다. 

마지막으로, 지속 클라우드 보안 태세 관리(Continuous Cloud Posture Management, CSPM)를 구현할 필요가 있다. 이는 과거에 ‘양호한 것’으로 알려져 프로비저닝과 실행이 허용되었던 IaC 템플릿이 일탈하지 않았고, 불안전하거나 컴플라이언스에 위배되는 변화가 수동으로 도입되지 않았음을 확인한다. 이곳에서 런타임 환경을 지속적으로 스캔해 이런 시나리오와 위험을 모니터링해야 한다. 변화와 위반이 탐지된다면 ‘코드형 교정(remediation-as-code)’을 이행해 시스템 환경을 이전에 검토되고 승인된 상태로 복원할 수 있다. 

또한 IaC 템플릿이 처음 가동될 때 존재하지 않았던 새롭게 추가된 컴플라이언스 및 보안 점검 사항이 있을 수 있기 때문에 IaC가 있는 SCM 리포지터리를 정기적으로 검사하는 것이 중요하다. 이는 과거에 알려지지 않았지만 현재 있을 수 있는 것을 발견하는 데 유용하다. 

IaC 거버넌스의 첫 단계 

기업은 이 환경에서 어떤 형식의 IaC가 누구에 의해 어디서 사용되고 있는지, 이들 템플릿이 어떻게 생성되고 저장되고 실행되는지 등을 결정하면서 IaC 거버넌스의 구현을 시작할 수 있다. 

그 후 보안 팀이 앞서 언급한 도구를 통해 엄격히 도입해 기존의 워크플로우에 이를 통합하고, 취약점 및 컴플라이언스 이탈을 발견하고, IaC 제작자에게 신속한 교정을 요청하는 일을 시작할 수 있다. 
 
여느 보안과 마찬가지로, 보안을 기존의 작업 흐름과 방식에 통합해 정체가 되지 않도록 하는 것이 중요하다. 개발자 워크플로우에 ‘건전한’ 마찰을 도입한다면 생산성이 취약점에 의해 불필요한 영향을 받지 않고, 컴플라이언스 문제가 대처 되고, 그러면서도 이해관계자와 고객을 위해 적절한 속도로 작업을 진행할 수 있을 것이다. 

기업의 클라우드 컴퓨팅 도입, 데브옵스/데브섹옵스(DevOps/DevSecOps) 접근법으로의 전환, 속도 및 동적 능력의 향상의 추구가 늘어남에 따라 IaC 도입은 계속 증가할 것이다. 앞서 논의한 베스트 프랙티스와 도구를 보안에 활용한다면 이들 도입을 안전하게 촉진할 수 있고, 아울러 불필요한 위험과 심지어 클라우드 환경의 악용이 급속히 유입되는 것을 막을 수 있다. editor@itworld.co.kr