규칙적이고 반복적인 업무 자동으로 처리해주는 자동화 플랫폼 IaC
수많은 장점 가지고 있지만 특별한 보안 프로세스인 SaC 적용해야 온전해져
[보안뉴스 문가용 기자] 코로나 기간 동안 확고하게 자리를 잡은 것이 하나 있으니 바로 IaC이다. 많은 조직들이 IaC를 도입함으로써 IT 운영의 속도를 높이고 자동화하기 시작했다. IaC는 Infrastructure as Code의 준말이다.
IaC를 통해 조직들은 애플리케이션 기반 시설을 설정하고 구축할 때 사람의 손으로 하나하나 변경 내용을 적용했던 것에서 벗어날 수 있게 된다. 늘 반복되는, 예측 가능한 일들을 자동으로 처리해 주는 것이 바로 IaC이기 때문이다. 이런 IaC를 제공하는 플랫폼들도 이미 여럿 시장에 나와 있다. 테라폼(Terraform), 셰프(Chef), 퍼펫(Puppet), 앤서블(Ansible), 설트스택(SaltStack), AWS 클라우드포매이션즈(AWS CloudFormations)가 바로 그것이다.
그런데 기존의 보안 방법론만을 고수해서는 IaC의 장점을 활용하지 못할 수 있다. 즉 위에 명시한 여러 서비스들을 활용한다고 해서 IaC의 모든 것을 온전히 누리는 건 아니라는 뜻이다. IaC를 도입하려는 조직은 반드시 SaC까지 한꺼번에 고려해야 한다. SaC는 ‘security as code’의 준말이다. 인프라만이 아니라 보안까지 ‘코드로서’ 처리하는 것이다.
IaC, 새로운 보안 개념을 필요로 한다
필자가 하려는 말을 간단히 풀자면, 자동화를 위한 코드도 보호해야 한다는 것이다. IaC 시스템은 자동으로 자원과 애플리케이션들을 구축한다. IaC가 이런 기능을 담당해주니 사람들은 편하게 사업의 다른 요소들에 신경을 쓸 수 있게 된다.
그런데 이 시스템이 자동으로 구축하는 앱과 자원들이 잘못 설정되어 있거나, IaC의 워크플로우 자체에 취약한 부분이 있다면 어떻게 될까? 생각하기 싫은 도미노 현상이 생겨난다. 취약한 요소들이 걷잡을 수 없이 조직 내 곳곳으로 퍼져가게 되고, 공격자들이 이를 발견이라도 하게 되면 돌이킬 수 없는 사태가 벌어진다. IaC는 강력한 ‘비즈니스 조력자’이지만, 동시에 강력한 취약점 유포자이기도 하다.
자동화 기술로 진행되는 워크플로우를 보호하려 했을 때의 어려움 중 하나는, 뭔가를 실행하기 위한 시스템이나 서비스로 접근하는 경로가 여러 가지라는 것이다. 게다가 조직 내 수많은 사람들이 여러 경로를 통해 여러 가지 서비스와 시스템에 접근해 IaC를 활용한다. 따라서 원인의 추적이라는 게 어려워진다. 조직들이 설정과 관련된 변경 사항을 제때 공지하지 않거나, 공지를 해도 못 듣는 구성원이 하나 둘 쌓이면 문제는 훨씬 더 복잡해진다.
그러므로 IaC를 기반으로 한 인프라를 보호한다는 것은 제일 먼저 설정에 관한 신뢰의 구심점을 마련하는 것부터 시작한다. 예를 들어 깃(Git) 리포지터리에 환경설정과 관련된 내용을 코드로 만들어 저장해 두고 그것을 항상 기준으로 삼는 것이 좋다. 일부에서는 이렇게 설정 내용을 관리하는 걸 깃옵스(GitOps)라고 부르기도 한다. 모든 사람이 공동으로 사용할 수 있는 신뢰의 구심점을 정의했다면, 그것을 바탕으로 접근, 감사, 평가의 과정을 도입시켜야 한다.
1) 접근 관리 : 신뢰의 구심점이 될 만한 설정 내용이 어딘가에 마련되어 있다면, 이제 해당 내용에 대한 접근 방법을 정의해야 한다. 기껏 신뢰의 구심점이랍시고 마련했는데 아무나 들어가서 막 만질 수 있으면 소용이 없으니까. 누가 어떤 상황에서 어느 정도나 이 설정 내용을 변경할 수 있는지 규정하고, 이를 문서화 해서 누구나 알도록 한다.
2) 감사와 규정 준수 : 설정 내용을 아무나 접근하지 못했다고 해서 끝이 아니다. 누군가는 허가를 받아 이 내용을 변경할 것이고, 그것이 조직 전체적으로 영향을 미칠 것이다. 그렇다면 그 변화가 제대로, 정당하게 이뤄졌는지를 감사하고, 산업이나 국가가 정한 규정 내에서 행해졌다는 것도 평가할 수 있어야 한다. 감사를 철저히 하면 할수록 신뢰의 구심점은 정말로 신뢰받을 만한 것이 된다.
3) 평가 : 접근을 통제하고 후속 조치로서 감사를 하더라도 좋지 않은 결과를 가져다 주는 변화를 못 막을 때가 있다. 그러므로 이 모든 과정을 주기적으로 검사 및 평가하는 과정이 필요하다. IaC가 조직 전체적으로 건강하게 운영되고 있는지 확인하는 과정이 있어야 한다는 것이다.
여기까지 했다면 확실하게 규정된 단일 생산 프로세스를 마련해야 한다. 즉 조직 내 모든 사람(개발자, 운영자, 보안 담당자 등)이 확실하게 이해하고 기준으로 삼을 수 있는 ‘업무 프로세스’가 전사적으로 선포되어야 한다는 것이다. 이는 조직 내 고립된 영역들을 깨부수고 조직 간 협업 체제를 굳히는 것을 말하기도 한다. 개발 따로 보안 따로 가는 과거의 업무 프로세스로는 IaC를 제대로 보호할 수 없고 따라서 IaC의 장점을 최대한 누리지도 못한다.
특히 IaC는 인프라를 코드로, SaC는 보안을 코드로 말한다는 개념이니 개발자 친화적인 환경이 될 수밖에 없다. 그러니 개발자들이여, 자기 앞의 모니터를 깨고 나올 필요가 있다. 이제 보안 담당자들도 코드로 말하고 인프라 관리자들도 코드로 말하기 시작했으니 말이다.
필자가 여러 SaC 성공 케이스를 분석했을 때 게이트보다 가드레일이 보다 잘 작동하는 것을 여러 번 목격했다. 즉 보안 점검이 완료되지 않은 코드는 가로막는다는 개념보다, 미흡한 부분을 보충하여 통과시켜주는 것이(가드레일) 보다 효과적이었다는 것이다. 이렇게 해야 ‘코드라는 언어’로 개발자들에게 말을 거는 효과가 나타난다. 그들의 마음이 열린다는 것이다. 고지대 등산을 해보라. 가드레일이 얼마나 우리 걸음을 빠르게 하는지 체험할 수 있을 것이다.
그렇다면 개발자들과 보안 담당자가 코드라는 공통의 언어로 이야기하는 게 실제 보안에 얼마나 도움이 될까? 생산(즉 개발)의 모든 과정을 투명하게 볼 수 있고, 따라서 그 때 그 때 알맞은 수정을 할 수 있게 된다. 감사와 평가, 조치라는 보안 임무가 부담되지 않는 분량으로 주어지며 이를 기반으로 보다 꼼꼼한 보안 업무를 수행할 수 있게 된다.
글 : 댄 허바드(Dan Hubbard), Lacework
[국제부 문가용 기자(globoan@boannews.com)]
수많은 장점 가지고 있지만 특별한 보안 프로세스인 SaC 적용해야 온전해져
[보안뉴스 문가용 기자] 코로나 기간 동안 확고하게 자리를 잡은 것이 하나 있으니 바로 IaC이다. 많은 조직들이 IaC를 도입함으로써 IT 운영의 속도를 높이고 자동화하기 시작했다. IaC는 Infrastructure as Code의 준말이다.
[이미지 = utoimage]
IaC를 통해 조직들은 애플리케이션 기반 시설을 설정하고 구축할 때 사람의 손으로 하나하나 변경 내용을 적용했던 것에서 벗어날 수 있게 된다. 늘 반복되는, 예측 가능한 일들을 자동으로 처리해 주는 것이 바로 IaC이기 때문이다. 이런 IaC를 제공하는 플랫폼들도 이미 여럿 시장에 나와 있다. 테라폼(Terraform), 셰프(Chef), 퍼펫(Puppet), 앤서블(Ansible), 설트스택(SaltStack), AWS 클라우드포매이션즈(AWS CloudFormations)가 바로 그것이다.
그런데 기존의 보안 방법론만을 고수해서는 IaC의 장점을 활용하지 못할 수 있다. 즉 위에 명시한 여러 서비스들을 활용한다고 해서 IaC의 모든 것을 온전히 누리는 건 아니라는 뜻이다. IaC를 도입하려는 조직은 반드시 SaC까지 한꺼번에 고려해야 한다. SaC는 ‘security as code’의 준말이다. 인프라만이 아니라 보안까지 ‘코드로서’ 처리하는 것이다.
IaC, 새로운 보안 개념을 필요로 한다
필자가 하려는 말을 간단히 풀자면, 자동화를 위한 코드도 보호해야 한다는 것이다. IaC 시스템은 자동으로 자원과 애플리케이션들을 구축한다. IaC가 이런 기능을 담당해주니 사람들은 편하게 사업의 다른 요소들에 신경을 쓸 수 있게 된다.
그런데 이 시스템이 자동으로 구축하는 앱과 자원들이 잘못 설정되어 있거나, IaC의 워크플로우 자체에 취약한 부분이 있다면 어떻게 될까? 생각하기 싫은 도미노 현상이 생겨난다. 취약한 요소들이 걷잡을 수 없이 조직 내 곳곳으로 퍼져가게 되고, 공격자들이 이를 발견이라도 하게 되면 돌이킬 수 없는 사태가 벌어진다. IaC는 강력한 ‘비즈니스 조력자’이지만, 동시에 강력한 취약점 유포자이기도 하다.
자동화 기술로 진행되는 워크플로우를 보호하려 했을 때의 어려움 중 하나는, 뭔가를 실행하기 위한 시스템이나 서비스로 접근하는 경로가 여러 가지라는 것이다. 게다가 조직 내 수많은 사람들이 여러 경로를 통해 여러 가지 서비스와 시스템에 접근해 IaC를 활용한다. 따라서 원인의 추적이라는 게 어려워진다. 조직들이 설정과 관련된 변경 사항을 제때 공지하지 않거나, 공지를 해도 못 듣는 구성원이 하나 둘 쌓이면 문제는 훨씬 더 복잡해진다.
그러므로 IaC를 기반으로 한 인프라를 보호한다는 것은 제일 먼저 설정에 관한 신뢰의 구심점을 마련하는 것부터 시작한다. 예를 들어 깃(Git) 리포지터리에 환경설정과 관련된 내용을 코드로 만들어 저장해 두고 그것을 항상 기준으로 삼는 것이 좋다. 일부에서는 이렇게 설정 내용을 관리하는 걸 깃옵스(GitOps)라고 부르기도 한다. 모든 사람이 공동으로 사용할 수 있는 신뢰의 구심점을 정의했다면, 그것을 바탕으로 접근, 감사, 평가의 과정을 도입시켜야 한다.
1) 접근 관리 : 신뢰의 구심점이 될 만한 설정 내용이 어딘가에 마련되어 있다면, 이제 해당 내용에 대한 접근 방법을 정의해야 한다. 기껏 신뢰의 구심점이랍시고 마련했는데 아무나 들어가서 막 만질 수 있으면 소용이 없으니까. 누가 어떤 상황에서 어느 정도나 이 설정 내용을 변경할 수 있는지 규정하고, 이를 문서화 해서 누구나 알도록 한다.
2) 감사와 규정 준수 : 설정 내용을 아무나 접근하지 못했다고 해서 끝이 아니다. 누군가는 허가를 받아 이 내용을 변경할 것이고, 그것이 조직 전체적으로 영향을 미칠 것이다. 그렇다면 그 변화가 제대로, 정당하게 이뤄졌는지를 감사하고, 산업이나 국가가 정한 규정 내에서 행해졌다는 것도 평가할 수 있어야 한다. 감사를 철저히 하면 할수록 신뢰의 구심점은 정말로 신뢰받을 만한 것이 된다.
3) 평가 : 접근을 통제하고 후속 조치로서 감사를 하더라도 좋지 않은 결과를 가져다 주는 변화를 못 막을 때가 있다. 그러므로 이 모든 과정을 주기적으로 검사 및 평가하는 과정이 필요하다. IaC가 조직 전체적으로 건강하게 운영되고 있는지 확인하는 과정이 있어야 한다는 것이다.
여기까지 했다면 확실하게 규정된 단일 생산 프로세스를 마련해야 한다. 즉 조직 내 모든 사람(개발자, 운영자, 보안 담당자 등)이 확실하게 이해하고 기준으로 삼을 수 있는 ‘업무 프로세스’가 전사적으로 선포되어야 한다는 것이다. 이는 조직 내 고립된 영역들을 깨부수고 조직 간 협업 체제를 굳히는 것을 말하기도 한다. 개발 따로 보안 따로 가는 과거의 업무 프로세스로는 IaC를 제대로 보호할 수 없고 따라서 IaC의 장점을 최대한 누리지도 못한다.
특히 IaC는 인프라를 코드로, SaC는 보안을 코드로 말한다는 개념이니 개발자 친화적인 환경이 될 수밖에 없다. 그러니 개발자들이여, 자기 앞의 모니터를 깨고 나올 필요가 있다. 이제 보안 담당자들도 코드로 말하고 인프라 관리자들도 코드로 말하기 시작했으니 말이다.
필자가 여러 SaC 성공 케이스를 분석했을 때 게이트보다 가드레일이 보다 잘 작동하는 것을 여러 번 목격했다. 즉 보안 점검이 완료되지 않은 코드는 가로막는다는 개념보다, 미흡한 부분을 보충하여 통과시켜주는 것이(가드레일) 보다 효과적이었다는 것이다. 이렇게 해야 ‘코드라는 언어’로 개발자들에게 말을 거는 효과가 나타난다. 그들의 마음이 열린다는 것이다. 고지대 등산을 해보라. 가드레일이 얼마나 우리 걸음을 빠르게 하는지 체험할 수 있을 것이다.
그렇다면 개발자들과 보안 담당자가 코드라는 공통의 언어로 이야기하는 게 실제 보안에 얼마나 도움이 될까? 생산(즉 개발)의 모든 과정을 투명하게 볼 수 있고, 따라서 그 때 그 때 알맞은 수정을 할 수 있게 된다. 감사와 평가, 조치라는 보안 임무가 부담되지 않는 분량으로 주어지며 이를 기반으로 보다 꼼꼼한 보안 업무를 수행할 수 있게 된다.
글 : 댄 허바드(Dan Hubbard), Lacework
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-05-30] 
.jpg)
.jpg)
.jpg)
