보안 거버넌스, 클라우드 문화에 대응하는 조직

By CarlsenColumn

더이상 클라우드는 단순히 인프라의 전환을 의미하지 않습니다. 우리가 일하는 방식, 협업하는 문화, 보안의 패러다임까지 완전히 바꾸고 있습니다. 특히 보안 담당자로서 가장 체감되는 변화는 “통제에서 신뢰로”의 전환이 아닐까 싶습니다. 모든 것이 유연해지고, 경계는 희미해졌으며, 보안의 책임 역시 분산되었습니다. 이런 변화 속에서 조직이 클라우드 보안 거버넌스를 어떻게 재정립할 수 있을까요? 오늘은 그 고민에 대해 이야기를 나눠보고자 합니다.

1. 클라우드 문화란 무엇인가?

클라우드 문화는 기술적인 클라우드 도입을 넘어서, 빠른 변화 수용과 애자일(Agile)한 업무 방식, DevOps 기반의 자동화, 셀프서비스와 권한 분산을 특징으로 합니다.

즉, IT 부서만의 독점이 아닌, 전사적으로 기술을 활용하는 방식이 보편화된다는 뜻입니다.

2. 클라우드 문화에 존재하는 위협

예를 들어 개발팀이 AWS IAM Role을 직접 구성하거나, 마케팅 부서가 SaaS 도구를 구매해 사용하는 모습은 더 이상 낯설지 않습니다. 문제는 이 과정에서 보안팀이 배제되거나, 사후 통제만 가능한 구조가 되어버린다는 것입니다.

3. 기존 보안 거버넌스 모델의 한계

클라우드 마이그레이션 과정에서, 보안 아키텍처의 구현보다 먼저 간주되어야 할 주제는, 클라우드 환경을 반영한 보안 거버넌스 모델의 수립입니다.

1) 보안 거버넌스 모델의 재수립이 필요한 이유

전통적인 보안 거버넌스는 중앙 통제 중심의 승인 절차, 네트워크 기반의 접근 제어, 온프레미스 환경에서의 물리적 보안을 기반으로 설계되었습니다. 그러나 클라우드 환경에서는 다음과 같은 한계에 부딪힙니다:

  • 경계 기반 보안의 무력화: 클라우드 자산은 네트워크 경계를 넘나듭니다. VPN과 방화벽만으로는 한계가 명확합니다.
  • 속도 vs 보안의 충돌: 빠르게 배포하고 실험하는 문화 속에서 보안은 종종 ‘방해 요소’로 인식됩니다. CI/CD 과정에서 취약점을 분석하고, 안정성을 확보하는 Sec 프로세스는 여전히 간과되고 있습니다.
  • 권한 남용 및 무분별한 리소스 생성: IAM 정책이나 리소스 접근 권한이 명확히 관리되지 않으면, 의도치 않은 보안 사고로 이어집니다.
  • 책임소재의 불명확: 클라우드는 기존의 레거시 환경보다 다양한 이해관계자를 포함하고 있습니다.
  • Shadow IT : 특히 생성형 AI의 보편화와 클라우드 기반 SaaS의 접근성이 높아지면서 Shadow IT 문제는 더욱 심화되고 있습니다.

* Shadow IT : 조직(보안팀, 부서)의 통제를 받지 않고 사용되는 IT 자산

2) 특히 Shadow IT가 위험한 이유

인터넷망과, 내부망의 망분리가 되지 않은 일반적 환경에서 언제나 발생할 수 있습니다. 위협을 끼치는 대상을 특정할 수 없기 때문에 더욱 위험하게 간주해야 합니다.

  • 비인가 데이터 유출: 직원이 Google Drive, Dropbox, Notion 등 외부 SaaS에 민감한 업무 데이터를 업로드할 경우, 그 데이터는 기업 통제 범위를 벗어나게 됩니다.
  • 감사 추적 불가: 어떤 사용자가 어떤 서비스를 사용했는지에 대한 가시성이 없기 때문에, 사고 발생 시 원인 파악이 어렵습니다.
  • 보안 기준 미달 서비스 사용: 보안 인증이나 규정 준수 기준이 충족되지 않은 SaaS를 사용할 경우, 기업 전체의 보안 위험이 증가합니다.

* 사례 : 한 프로젝트 팀이 JIRA 외에 자체적으로 Trello를 도입해 협업을 진행하던 중, 민감한 요구사항 문서가 공개 링크로 노출되는 사고가 발생한 적이 있습니다. 이 문제의 핵심은 ‘도구 선택의 자율성’이 아니라, 그 자율성이 거버넌스 체계 안에서 관리되지 않았다는 점이었습니다.

4. 클라우드 시대에 대응하는 보안 거버넌스 모델

위와 같은 위협과 제약으로 인해, 클라우드 문화와 환경 전체를 고려한 새로운 보안 거버넌스 모델의 도입이 필요한 시점입니다.

아래 항목들은 새로운 보안 거버넌스 모델의 수립 과정에서 중요하게 간주되어야 할 내용을 포함하고 있습니다.

  • 문화적 위협의 보완통제: 클라우드네이티브 환경에서의 DevOps는 사실상 직무분리의 불가능 영역입니다. 이를 보완통제 하기 위해 DevSecOps와 같은 보완통제 전략이 필요합니다.
  • Security as Code : CI/CD 파이프라인 내에 보안 검증을 자동화하고, Terraform이나 CloudFormation 같은 IaC 도구와 연계하여 인프라 보안을 코드로 관리합니다. 이렇게 하면 “보안을 따로 적용하는” 것이 아니라, 개발 프로세스 안에 녹아들게 됩니다.
  • 자원의 경계 범위 확장 및 위험관리 계획 수정: 클라우드 환경까지 고려한 보안 경계의 설정이 필요합니다. 언제나 데이터에 대한 책임이 이용자에게 있음을 지각하는 것이 중요합니다.
  • 동적 계정 및 권한관리: 클라우드 IAM 설정은 시시각각 변합니다. 권한은 최소한으로 시작하고, 주기적으로 권한을 감사(Audit)하는 프로세스를 운영해야 합니다. AWS Access Analyzer, Azure PIM 등이 대표적 도구입니다. 또한 계정 발급은 체계적인 프로세스를 포함하고, 인사DB 등과 연동된, 동적 계정관리가 필요합니다.
  • 지속적인 외부자 현황 파악: CSP, MSP, 3rd Party Vendor 등 다양한 이해관계자와의 계약 과정에서 책임 영역과 이에 대한 역할을 명확하게 협의하는 것이 중요합니다. 또한 그레이존을 예방하기 위해 정기적으로 외부자 현황을 파악하는 별도 프로세스가 수행되어야 합니다.
  • Shadow IT 예방 : Cloud Access Security Broker(CASB) 솔루션을 도입하면, 조직 내에서 사용되는 비인가 SaaS 사용 현황을 탐지할 수 있습니다. 또한 DLP(Data Loss Prevention) 기능과 연계하여 데이터 유출을 사전 차단할 수도 있습니다.

5. 결론

이제 보안은 ‘감시자’가 아니라, 협력자이자 촉진자의 역할로 전환되어야 합니다.
클라우드 중심의 조직 문화에서는 유연함과 속도가 경쟁력이고, 보안 역시 그 속도를 따라가야 합니다.

특히 해당 과정에서 사용자 중심의 거버넌스 모델과 기술적 통제가 함께 구축되어야할 것입니다.
또한 이와 더불어 가장 중요한 것은 기술 도입뿐 아니라, 사용자 교육과 정책 정립이 병행되어야 한다는 점을 명심해야 합니다.

언제나 결국 사람과 문화가 핵심입니다.
거버넌스는 더 이상 규제의 도구가 아니라, 공동의 책임을 나누고 지속 가능성을 만드는 수단으로 자리 잡아야 할 때입니다.

참고자료 :
AWS Security Governance at Scale whitepaper – https://aws.amazon.com/whitepapers/
Google Cloud Security Foundations guide – https://cloud.google.com/architecture/framework?hl=ko

Post Views: 185