Security as Code

2018년 초 AI(Artificial Intelligence)기반의 새로운 과제를 시작하면서 인프라스트럭처 애즈 코드(Infrastructure as Code)를 적용할 것인지 논의하였다. 소규모 과제의 경우에는 인프라스트럭처 애즈 코드를 적용하고 싶지 않다는 주장이 나왔기 때문이었다. 인프라스트럭처를 모두 코드로 만들어서 관리하는 장점은 알겠지만, 규모가 너무 작아서 작업자가 GUI 도구로 간단하게 만들어 버리는 것이 더 빠른 경우도 있다는 주장이었다. 또한 그 정도 간단한 과제라면 장애복구도 매우 간단하게 수행할 수 있는데, 이를 위해 테라폼(Terraform) 또는 클라우드 포메이션(CloudFormation)을 이용하여 코드를 만들고 검증하는 과정이 오히려 부담스럽다는 의견이었다. 배보다 배꼽이 크다는 주장에 대해서, 충분히 그럴 수 있다고 생각한다. 동네 앞 편의점에 라면 몇 개 사러 나가는데, 마치 대형마트에 갈 것 처럼 SUV를 끌고 갈 필요는 없기 때문이다. 인프라스트럭처 애즈 코드라는 개념과 도구도 필요에 따라 적절하게 선택해야 한다는 의견에는 충분히 공감한다.

그러나 작은 규모의 과제라도 인프라스트럭처 애즈 코드를 해야하는 이유를 한 가지 제안해 보려고 한다. 그것은 보안이다. 시큐리티 그룹 또는 방화벽은 시간이 지날수록 복잡해진다. 처음에는 모든 연결을 차단하도록 설정했다가 필요한 부분만 규칙으로 만들어서 추가한다. 하지만 이렇게 추가하다보면 누가 언제 무슨 목적으로 만들었는 지 확인하기 어렵다. 그래서 꼭 필요한 통신을 미리 설계하고 이를 바탕으로 코드를 작성해 두면, 이러한 문제점을 미리 방지할 수 있다. 필요한 방화벽 규칙이 있다면, 코드로 작성해서 모두에게 검토를 받고 그대로 적용하면 되기 때문이다.
 

 
그래서 DevOps^[각주:1]를 보안까지 확장하여, DevSecOps를 만들 수 있다. 즉 개발이 완료된 이후에 보안상태를 점검하는 것이 아니라 개발이 진행되는 과정에서 함께 보안을 챙기는 것이다. 흔히 애자일을 병의 예방에 비유하기도 한다. 이미 병이 커지면 치료가 어렵고 그래서 꾸준한 운동과 주기적인 검진을 통해서 건강을 챙겨야 하는 모습과 비슷하기 때문이다. 이러한 비유를 서비스(Software Service)의 품질 부분인 기능과 안정성에만 초점을 맞추었고 그래서 개발과 운영의 협업 형태인 DevOps가 나타났다. 이제 보안도 애자일의 범주안에 들어와야 한다. 뒷짐지고 있다가 출시가 임박해서야 법률을 내세워 감사역할만 하면 안된다. 오히려 적극적으로 개발초기에 보안담당자들이 보안 규칙을 코드로 작성해서 제공해 주어야 한다.
 
위 그림과 같이 보안 설정을 코드로 작성한 사례는 라디오 서비스를 개발할 때 적용했다. 보안 검토에 걸리는 시간을 1개월 이상에서 1주일로 단축하였고 그 경험을 바탕으로 테라폼 모듈(Module)을 만들어서 다른 서비스들에게 확대 적용하였다. 그래서 보안검토 요청 전에 보안 요구사항을 미리 완수하고 점검할 수 있는 수준이 되었다. 테라폼 모듈만 실행하면 해당 서비스는 보안 요구사항을 자동으로 만족시킬수 있기 때문이었다. 이와 같은 사례와 경험이 있었기 때문에, 작은 과제에는 코드를 이용해서 인프라스트럭처를 관리하는 것이 오히려 독이 된다는 사람들을 설득할 수 있었다.^[각주:2] 결과적으로 규모가 작은 과제도 테라폼을 적용하였고, 보안 검토와 운영환경 구성을 빠르면서도 빈틈없이 완수 했다.

---

 

1. 개발과 운영이 힘을 합쳐 서비스 품질을 높이는 것 [본문으로]
2. Jikji Code [본문으로]