클라우드 네이티브 애플리케이션을 위한 6가지 필수 보안 수칙

클라우드 네이티브 아키텍처가 등장하면서 애플리케이션 개발, 배포, 관리 방법이 크게 바뀌었다. 클라우드 네이티브 아키텍처는 확장성과 탄력성, 유연성 측면에서 상당한 이점을 제공하지만, 그에 따르는 보안 과제도 있다.
 

이런 과제 대부분은 전통적인 모놀리식 애플리케이션 과제와는 다르다. 개발자는 미묘한 차이를 이해하는 것이 중요하다. 현대의 클라우드 네이티브 애플리케이션에는 과거의 보안 과제와 새로운 보안 과제가 혼합돼 있고, 이를 포괄적으로 해결해야 하기 때문이다.

여기서는 안전하고 탄력적이며, 확장 가능한 클라우드 네이티브 애플리케이션을 구축하기 위해 필수적인 6가지 안전한 코딩 방법을 살펴본다. 단순히 ‘있으면 좋은’ 것이 아니라, 모든 클라우드 네이티브 애플리케이션의 전체적인 보안 태세에 기여하는 근본적인 원칙이다.

제로 트러스트 아키텍처

클라우드 네이티브 생태계에서 마이크로서비스의 모듈형이라는 특성에는 장점과 과제가 동시에 존재한다. 마이크로서비스를 개발할 때 더 넓은 애플리케이션 맥락에서의 마이크로서비스 소비를 섣부르게 예단하는 것은 금물이다. 마이크로서비스의 핵심은 재사용 가능한 모듈형 구성요소라는 점이다. 즉, 처음에는 한 애플리케이션 내의 특정 용도로 설계된 동일한 마이크로서비스가 나중에 전혀 다른 보안 제약 조건이 있는 다른 애플리케이션에 통합될 수 있다는 의미다.

이런 유동성을 고려하면 마이크로서비스에 접근할 때는 제로 트러스트 원칙에 따르는 것이 무엇보다 중요하다. 어떤 서비스가 다른 서비스를 무작정 신뢰하지 않도록 함으로써 사용 맥락에 관계없이 각 마이크로서비스의 방어를 강화할 수 있다. 제로 트러스트의 2가지 핵심 요소는 마이크로 세그먼트화(micro-segmentation)와 서비스 대 서비스 인증(service-to-service authentication)이다.

마이크로 세그먼트화는 애플리케이션을 더 작고 관리가 용이한 구성요소(마이크로서비스)로 분할하고 각각에 대해 독립적인 보안 제어를 설정하는 것이다. 이렇게 하면 한 구성요소가 침해되더라도 공격 표면이 제한된다. 예를 들어, 클라우드 네이티브 전자상거래 애플리케이션에서 재고, 결제, 사용자 인증을 각각 고유한 보안 프로토콜을 사용하는 서로 다른 마이크로서비스로 분리할 수 있다.

서비스 대 서비스 인증은 단순히 사용자 인증에 의존하지 않고 정보를 교환하기 전에 서비스가 상호 인증하도록 한다. 이를 위해 mTLS(mutual TLS)와 같은 기술이 사용된다. 예를 들어, 전자상거래 플랫폼의 재고 마이크로서비스가 결제 마이크로서비스에 결제 세부정보를 요청할 때 mTLS를 사용해 두 서비스의 ID를 확인할 수 있다.

입력 검증

SQL 주입 및 파일 경로 탐색과 같은 공격은 부실한 입력 검증을 악용하는 경우가 많다. 마이크로서비스가 여러 API를 노출할 수 있는 클라우드 네이티브 애플리케이션에서는 이와 같은 공격의 위험이 훨씬 더 커진다. 보안을 위해 모든 입력에 대한 엄격한 검증과 위생 처리를 보장하는 것이 중요하다. 즉 최종 사용자, 다른 서비스, 내부 데이터베이스를 비롯해 어디에서 오는 데이터든 모두 잠재적 악성 데이터로 취급해야 한다.

엄격한 API 보안 조치는 유형 검사, 경계 검증, 화이트리스팅을 포함한다. 유형 검사와 경계 검증은 입력의 데이터 유형을 검증해서 예상되는 유형과 일치하는지 확인하고, 특정 유형의 입력에 대해 경계 또는 제한을 설정해 오버플로우, 언더플로우 또는 기타 악의적인 입력 기반 공격을 차단한다. 예를 들어, 전자상거래 사이트에 구매할 품목의 수량을 입력하는 필드가 있는 경우 이 필드는 양의 정수만 수락하고 음수 또는 알파벳 문자와 같은 입력은 거부하도록 해야 한다. 또한 품목 100개와 같은 상한을 설정해서 현실적이지 않거나 피해를 입힐 가능성이 있는 주문을 방지해야 한다.

화이트리스팅은 허용되는 입력 또는 값 범위를 목록으로 유지하는 것이다. 이 목록에 사전에 정의돼 있는 기준을 충족하는 입력만 수락해야 한다. 가령 맞춤형 기능을 위한 색상 입력을 받는 API라면 화이트리스트를 사용해서 빨간색의 경우 #FF0000과 같은 특정 색상 코드만 허용하도록 해야 한다.

인터넷 노출 제어

애플리케이션에서 인터넷에 노출되는 요소가 많을수록 공격 표면도 커진다. 특히 느슨하게 결합된 여러 서비스에 걸쳐 기능이 분산되는 경우가 많은 클라우드 네이티브 애플리케이션에서는 더욱 그렇다. 인터넷 액세스를 필수적인 구성요소로 제한하면 공격자의 잠재적 진입점을 제한할 수 있다. 인터넷 노출을 제어하는 주요 방법은 방화벽 규칙, VPC(Virtual Private Cloud), 드리프트 관리가 대표적이다.

고급 방화벽 설정을 사용해서 모든 비필수 포트를 차단하라. 네트워크를 세그먼트화해서 서로 다른 서비스를 격리하고 각 서비스의 노출을 최소화할 수 있다. 예를 들어, 결제 게이트웨이를 주 애플리케이션 서비스로부터 격리해 하나의 서비스가 침해되더라도 다른 서비스는 안전하게 유지되도록 한다.

VPC를 구현해서 애플리케이션의 여러 부분을 격리하라. 여기에는 각 서비스 유형에 대한 별도의 서브넷과 이들 간의 트래픽을 제한하기 위한 네트워크 ACL이 포함돼야 한다. 예를 들어, 전자상거래 애플리케이션을 사용자 인증, 제품 카탈로그, 결제 처리를 위한 개별 VPC로 분할한다.

서비스에서 구성 드리프트를 모니터링하라. 해당 서비스와 무관한 API 요청을 수용하기 위한 수정 작업 등 다른 부분에서의 변경으로 인해 내부 서비스가 실수로 대중에 노출되는 경우가 종종 발생한다. 의도하지 않은 구성 변경에 대한 알림을 설정하고 드리프트 발생 시 즉각 대처해야 한다. 가령 관리 목적의 액세스만 가능한 내부 보고 서비스가 있다고 가정해 보자. 관련 없는 API 수정으로 인해 이 서비스가 일반 직원 또는 대중에 의도치 않게 노출되는 경우 드리프트 관리 툴이 개발팀에 이 같은 의도하지 않은 노출을 알려 즉각적인 수정이 이뤄지도록 해야 한다.

안전한 파일 저장

파일에 데이터를 저장하는 경우, 특히 민감 데이터라면 높은 수준의 보안이 필요하다. 데이터베이스 자체적인 위험도 있지만 파일을 저장할 때도 주의하지 않으면 그보다 더 위험해질 수 있다. 파일 기반 데이터는 보관 시 항상 암호화해야 한다. 또한 파일에 액세스할 수 있는 사람을 제한하기 위한 엄격한 통제 수단이 있어야 한다. 안전한 파일 저장 방법은 보관 시 암호화, 역할 기반 액세스 제어가 포함된다. 또한 임시 파일에도 면밀한 주의가 필요하다. 임시 파일은 말처럼 임시가 아니기 때문이다.

가장 안전한 데이터 저장을 보장하려면 항상 플랫폼 네이티브 암호화 방법을 사용해야 한다. 그러면 공격자가 물리적 스토리지에 접근하더라도 데이터를 읽을 수 없다. 예를 들어, 클라우드 스토리지 솔루션이 제공하는 내장 암호화 방법을 사용해서 사용자 데이터를 암호화한 다음 저장한다.

RBAC(Role-based Access Control) 메커니즘을 사용해 저장된 파일에 대한 액세스를 관리하라. 모든 액세스를 로그로 남겨 감사 증적을 만들어야 한다. 가령 의료 애플리케이션이라면 환자 레코드에 대한 액세스는 특정 의료 담당자에 한해 허용해야 한다.

프로세스나 디버깅 중에 임시 파일을 생성할 때는 주의해야 한다. 의도치 않게 임시 파일에 민감한 정보가 포함될 수 있기 때문이다. 임시 파일을 자동으로 제거하는 루틴을 구현해서 필요 이상으로 오래 남지 않도록 한다. 예를 들어, 개발자가 사용자 인증 오류 문제를 해결하기 위해 임시 로그를 생성하는 경우 문제가 해결된 뒤 해당 로그를 삭제하는 자동화된 프로세스를 마련해서 민감 데이터가 남지 않도록 해야 한다. 부주의는 생각보다 쉽게 발생하므로(마이크로소프트에서도 발생한 적이 있음) 정리 프로세스를 철저히 확인하는 것이 중요하다.

최소 권한 원칙

클라우드 네이티브 애플리케이션 개발에는 최소 권한 원칙을 적용하는 것이 무엇보다 중요하다. 서비스는 기능을 수행하는 데 필요한 권한만 가져야 한다. 이렇게 하면 공격자가 침해된 서비스를 사용해서 시스템의 다른 부분을 공격할 위험이 최소화된다. 코드에 최소 권한 원칙을 적용하기 위한 단계에는 범위가 지정된 권한, 임시 자격 증명, 정기적인 감사가 포함된다.

각 구성요소의 책임에 맞춰 세밀하게 권한 설정을 조정하라. 이는 여러 관점에서 중요하지만 API 관점을 간과하는 경우가 많다. API에 읽기와 쓰기가 필요한가? 그렇다면 이를 두 개의 개별 API로 만들고 각각에 필요한 최소한의 권한만 부여해야 한다. 예를 들어, 변경 작업을 수행할 가능성이 높은 사용자 등록 서비스는 데이터를 보고하는 읽기 전용 서비스와는 범위가 다른 권한 집합을 가져야 한다.

평상시보다 더 높은 권한이 필요한 작업에는 단기 자격 증명을 사용하고, 작업이 완료된 즉시 만료되도록 하라. 예를 들어, 승격된 권한이 필요한 백업 작업의 경우 백업이 완료되는 즉시 만료되는 임시 자격 증명을 사용한다.

정기적인 감사와 수시 감사를 실시해서 권한이 지나치게 높은 역할을 찾아서 교정하라. 자동화된 툴은 이런 역할을 식별해서 교정 조치를 제안할 수 있다. 예를 들어, 자동화된 감사 툴을 사용해서 시스템의 역할과 권한을 주기적으로 점검하고 필요 이상의 액세스 권한이 부여된 역할을 파악한다. 그런 다음 교정 조치를 통해 권한을 정상 범위로 설정한다.

로그 데이터 마스킹

로깅은 모니터링과 디버깅을 위해 필수적이지만 로그에는 민감한 정보도 포함될 수 있다. 데이터 마스킹은 로그에 나타나는 민감 정보를 가린 버전으로 대체해서 데이터 유출 위험을 낮춘다. 로그에 데이터 마스킹을 구현하기 위한 주요 구성요소에는 자동화된 치환(redaction) 툴, 중앙화된 로그 관리 및 로그 보존 정책이 포함된다.

전문적인 소프트웨어 툴을 사용해 로그에서 자동으로 민감한 정보를 스캔하고 치환하라. 이런 툴은 주민등록번호, 신용카드번호 또는 비밀번호와 같은 패턴을 인식하도록 프로그래밍할 수 있다. 예를 들어, 금융 애플리케이션에서 신용카드 정보가 로그에 기록되기 전에 자동으로 치환되도록 해서 마지막 4자리만 참조를 위해 보이게 해야 한다.

다양한 소스에서 오는 로그를 집계하는 중앙화된 로그 관리 시스템을 구축하라. 이렇게 하면 모니터링이 강화될 뿐 아니라 마스킹 및 치환 정책이 모든 로그에 균일하게 적용돼 민감 데이터 유출 가능성이 낮아진다. 예를 들어, 여러 마이크로서비스가 있는 분산 클라우드 네이티브 애플리케이션에서는 모든 서비스의 로그를 중앙 시스템에 집계해서 들어오는 모든 로그에 일관적으로 데이터 마스킹 규칙이 적용되도록 해야 한다.

로그 파일의 보존 기간에 대한 엄격한 정책을 수립하라. 이 정책을 규정 준수 요구사항에 맞추고 해당 기간을 초과하는 로그는 자동으로 삭제되도록 한다. 예를 들어, GDPR 규정 준수를 위해 개인 데이터가 포함된 로그는 감사 또는 법적으로 필요한 경우를 제외하고 30일 후 자동으로 삭제되도록 설정한다.

더 나은 보안을 위한 진전

안전하고 회복 탄력성이 높고 확장 가능한 클라우드 네이티브 애플리케이션을 구축하기 위해서는 전통적인 애플리케이션 개발과는 다른 새로운 베스트 프랙티스가 필요하다. 핵심은 제로 트러스트 아키텍처부터 로그 데이터 마스킹에 이르는 이런 방법을 최대한 빨리 개발 수명 주기에 통합해서 보안을 설계 및 배포 프로세스의 필수 요소로 만드는 것이다.

이와 동시에 실제 구현에 있어서의 현실적인 과제를 인식하는 것도 중요하다. 빠르게 변화하는 개발 환경에서 모든 보안 조치를 동시에 통합한다는 것은 매우 어려운 작업처럼 보일 것이다. 일단 개발자가 관련 위험을 인식하는 것이 중요하다. 즉시 완벽해지는 것을 목표로 두지 말고 각 방법을 이해하는 데 우선순위를 둔 다음 애플리케이션의 요구사항 및 맥락에 따라 무엇을, 언제 통합할지를 전략적으로 결정해야 한다.

사이버보안 환경은 끊임없이 진화하므로 복잡하고 분산된 시스템을 보호하기 위한 전략도 진화해야 한다. 여기서 살펴본 방법과 인사이트를 갖추면 클라우드 네이티브 애플리케이션 보안을 위한 민첩하고 정보에 근거한 여정을 더 효과적으로 계획할 수 있을 것이다.
editor@itworld.co.kr