블로그

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

마티아스 마두, Ph.
게시일: 2020년 6월 1일

조직에서 보안 인프라를 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 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

리소스 보기
리소스 보기

때때로 응용 프로그램은 전체 워크로드의 일부로 다른 프로그램과 데이터를 공유합니다. 전송 계층이 보호되지 않는 한 외부 스누핑과 무단 내부 보기 모두에 취약합니다.

더 알고 싶으신가요?

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

데모 예약
공유하세요:
저자
마티아스 마두, Ph.
게시일: 2020년 6월 1일

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.

마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.

공유하세요:

조직에서 보안 인프라를 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 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

리소스 보기
리소스 보기

아래 양식을 작성하여 보고서를 다운로드하세요.

우리는 당신에게 우리의 제품 및 / 또는 관련 보안 코딩 주제에 대한 정보를 보낼 수있는 귀하의 허가를 바랍니다. 우리는 항상 최대한의주의를 기울여 귀하의 개인 정보를 취급 할 것이며 마케팅 목적으로 다른 회사에 판매하지 않을 것입니다.

전송
양식을 제출하려면 '분석' 쿠키를 활성화하세요. 완료되면 언제든지 다시 비활성화할 수 있습니다.

조직에서 보안 인프라를 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 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

리소스에 접근

아래 링크를 클릭하여 이 자료의 PDF를 다운로드하세요.

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

보고서 보기데모 예약
공유하세요:
더 알고 싶으신가요?

공유하세요:
저자
마티아스 마두, Ph.
게시일: 2020년 6월 1일

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.

마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.

공유하세요:

조직에서 보안 인프라를 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 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

목차

리소스 보기
더 알고 싶으신가요?

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

데모 예약다운로드
공유하세요:
리소스 허브

시작할 수 있는 리소스

더 많은 게시물
리소스 허브

시작할 수 있는 리소스

더 많은 게시물