코드 정복 보안 인프라 코드 시리즈: 불충분한 전송 계층 보호

조직 내에서 안전한 코드형 인프라(IaC) 배포를 시작하기 위해 필요한 단계를 배우고자 하는 개발자라면 잘 찾아오셨습니다. 이번 글은 IaC 보안 모범 사례를 한 단계 더 발전시키기 위해 마련된 IaC 시리즈의 다음 장입니다.

시작하기 전에, 지난번 과제는 잘 해결하셨나요? 안전하지 않은 암호화 문제를 마스터했다면, 본격적으로 내용을 살펴보기 전에 불충분한 전송 계층 보호 문제를 어떻게 해결하는지 확인해 보겠습니다.

더 자세히 배우고 완벽한 점수를 받고 싶으신가요? 계속 읽어보세요.

지난 기사에서는 애플리케이션과 프로그램이 저장하는 중요 데이터나 개인 정보를 보호하기 위한 안전한 암호화의 중요성에 대해 다루었습니다. 강력한 암호화는 최후의 방어선 역할을 합니다. 공격자가 데이터를 탈취하더라도 강력하게 암호화되어 있다면 파일 내의 정보는 안전하게 보호됩니다.

하지만 저장 데이터(data at rest)를 보호하는 것만으로는 완전한 데이터 방어라고 할 수 없습니다. 유효한 사용자가 보호된 데이터에 액세스해야 할 때마다 해당 데이터는 사용자에게 전송되어야 합니다. 애플리케이션은 전체 워크로드의 일부로서 다른 프로그램과 데이터를 공유하기도 합니다. 전송 계층이 보호되지 않으면 외부의 도청이나 내부의 무단 열람에 취약해집니다. 따라서 불충분한 전송 계층 보호는 심각한 문제를 야기할 수 있습니다.

이는 흔한 문제입니다. 보안 조직인 OWASP는 불충분한 전송 계층 보호에 관한 전체 페이지를 운영하고 있을 정도입니다.

불충분한 전송 계층 보호가 위험한 이유는 무엇일까요?

전송 계층을 충분히 보호하지 않으면 숙련된 해커가 중간자 공격(man-in-the-middle attack)과 같은 기술을 사용하여 사용자와 애플리케이션 간에 흐르는 정보를 가로채기가 비교적 쉽습니다. 이러한 도청의 가장 위험한 점은 네트워크 외부에서 발생하기 때문에 내부 사이버 보안 플랫폼이나 스캔으로는 거의 감지되지 않는다는 것입니다.

예를 들어, Nginx 서비스를 배포하는 Docker 환경의 경우를 보겠습니다.

services:
 nginx:
   image: localhost:5000/scw_nginx
   build: ./nginx
   secrets:
     - nginx_cert
     - nginx_key
   volumes:
     - type: bind
       source: ./nginx/nginx.conf
       target: /etc/nginx/nginx.conf
       read_only: yes
   ports:
     - 80:8443
   networks:
     - frontend
   deploy:
     restart_policy: *default-restart_policy
     resources: *default-resources_policy

이 Nginx 서비스 구성은 연결을 암호화하거나 보호하지 않으므로, 해당 링크를 통해 교환되는 모든 정보가 다양한 공격이나 도청에 취약해집니다.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

누군가 전송 계층을 도청하고 있다는 첫 번째 신호는 대량의 도난당한 사용자 비밀번호가 후속 공격에 사용될 때 나타나는 경우가 많습니다. 고객 정보, 금융 기록 또는 중요한 회사 기밀과 같은 다른 데이터가 안전하지 않은 전송 계층을 통해 도난당하면, 침해 사실조차 인지하지 못할 수도 있습니다.

보호가 필요한 것은 사용자와 애플리케이션 사이의 전송 계층뿐만이 아닙니다. 백엔드에서는 많은 애플리케이션이 서로 통신하며 워크플로우 체인 상의 다른 서버와도 통신합니다. 이러한 내부 통신은 일반적으로 외부 도청에는 취약하지 않지만, 네트워크 접근 권한은 있으나 특정 민감 정보에 대한 열람 권한은 없는 사용자에게 데이터가 노출될 수 있습니다.

완벽한 데이터 보호를 위한 전송 계층 보안 강화

전송 계층 보호는 애플리케이션을 개발하는 단계에서 수행하는 것이 가장 좋습니다. 이 과정은 안전한 백엔드 인프라를 구축하는 것에서 시작됩니다. 웹사이트의 경우 모든 통신은 HTTPS를 사용해야 합니다. HTTP와 HTTPS 인프라를 혼용하지 마십시오. 보안되지 않은 HTTP 요청을 HTTPS 인프라로 자동 리디렉션하도록 사이트를 설정해야 합니다.

위의 예시에서 전송 계층을 올바르게 보호하는 방법은 다음과 같습니다.

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

이 예시에서 Nginx 서비스와의 모든 연결은 강력하게 암호화됩니다. Nginx 설정의 서버 섹션에는 listen 8443 ssl 만 포함되어 있어 SSL을 통해 연결을 강제로 보호합니다.

내부 위협으로부터 데이터를 보호하려면 개발자는 TLS 1.2와 같은 강력한 전송 계층 암호화 프로토콜을 사용해야 합니다. TLS 1.2 이상을 적용한 후에는 SSL v2와 같이 취약한 프로토콜을 인프라에서 완전히 제거하여 사용되지 않도록 차단해야 합니다.

애플리케이션 보안은 저장 데이터와 전송 계층이 모두 충분히 보호될 때 비로소 완성된다는 점을 항상 기억하십시오. 그래야 내부 데이터는 물론 승인된 외부 사용자에게 전송되는 데이터까지 완벽한 종단간 보호를 보장할 수 있습니다.
이 취약점에 대한 자세한 정보와 기타 보안 결함으로부터 조직과 고객을 보호하는 방법은 Secure Code Warrior 블로그 페이지에서 확인하실 수 있습니다. 또한 데모를 체험하여 사이버 보안 기술을 최신 상태로 유지해 보세요.