코드 시리즈로 보안 인프라를 정복코더: 전송 계층 보호 부족

조직에서 보안 인프라를 IaC(코드)로 배포하기 위해 수행할 수 있는 단계에 대해 자세히 알아보려는 개발자라면 올바른 위치에 도달하게 됩니다. IaC 보안 모범 사례에서 레벨을 올리기 위해 설계된 IaC 시리즈의 다음 장입니다.

시작하기 전에 마지막 할부에서 도전과제를 어떻게 처리했습니까? 안전하지 않은 암호화를 마스터한 경우 세부 정보를 자세히 파헤치기 전에 전송 계층 보호가 부족한 방법을 살펴보겠습니다.

더 많은 것을 배우고 완벽한 점수를 달성하고 싶으십니까? 읽기:

마지막 기사에서는 응용 프로그램 및 프로그램에 저장된 중요하거나 개인 데이터를 보호하기 위해 안전한 암호화를 갖는 것의 중요성에 대해 이야기했습니다. 당신은 강한 암호화가있는 경우, 그것은 방어의 완벽한 마지막 라인 역할을. 공격자가 해당 데이터를 도용할 수 있더라도 강력하게 암호화된 경우 해당 파일 내부에 잠긴 정보는 여전히 보호됩니다.

그러나 데이터를 미디수 보호하는 것은 완전한 데이터 방어의 한 부분일 뿐입니다. 유효한 사용자가 보호된 데이터에 액세스해야 할 때마다 사용자에게 전송해야 합니다. 때때로 응용 프로그램은 전체 워크로드의 일부로 다른 프로그램과 데이터를 공유합니다. 전송 계층이 보호되지 않는 한 외부 스누핑과 무단 내부 보기 모두에 취약합니다. 따라서 전송 계층 보호가 충분하지 않아 심각한 문제가 발생할 수 있습니다.

그것은 일반적인 문제입니다. OWASP 보안 조직은 전송 계층 보호부족에대한 전체 페이지를 유지관리합니다.

충분한 운송 계층 보호가 위험한 이유는 무엇입니까?

전송 계층을 충분히 보호하지 못하면 숙련된 해커가 중간 공격과 같은 기술을 사용하여 사용자와 응용 프로그램 간에 흐르는 정보를 가로챌 수 있습니다. 아마도 이러한 종류의 스누핑의 가장 위험한 측면은 네트워크 및 제어 외부에서 발생하기 때문에 내부 사이버 보안 플랫폼이나 스캔에 거의 완전히 보이지 않는다는 것입니다.

예를 들어 Nginx 서비스를 배포하는 Docker 환경에서는 다음을 수행합니다.

서비스:
nginx:
이미지: 로컬 호스트:5000/scw_nginx
빌드: ./nginx
비밀:
- nginx_cert
- nginx_key
볼륨:
- 유형 : 바인딩
출처: ./nginx/nginx.conf
대상: /etc/nginx/nginx.conf
read_only: 예
포트:
- 80:8443
네트워크:
- 프론트 엔드
전개시키다:
restart_policy: *기본 restart_policy
리소스: *기본 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 구성의 서버 섹션에는 SSL이 연결을 보호하도록 강제하기 위해 8443 ssl만 수신대기됩니다.

내부자 위협으로부터 데이터를 보호하려면 개발자는 TLS 1.2와 같은 강력한 전송 계층 암호화 프로토콜을 사용해야 합니다. TLS 1.2 또는 이와 동등한 프로토콜이 있으면 SSL v2와 같은 약한 프로토콜을 인프라에서 완전히 제거하고 자동으로 사용이 금지되어야 합니다.

또한 사용 중인 데이터와 전송 계층이 모두 충분히 보호될 때까지 응용 프로그램 보안이 완전히 완료되지 않습니다. 이렇게 하면 내부적으로 및 권한이 있는 외부 사용자에게 전송할 때 데이터에 대한 완전한 엔드 투 엔드 보호를 보장할 수 있습니다.
체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.