PCI DSS 결제 카드 데이터 보안 표준, NGINX Plus 사용 사례

PCI(Payment Card Industry) DSS(Data Security Standard) 또는 PCI DSS 는 소비자의 신용 카드 번호 및 기타 개인 데이터를 보호하기 위한 인증 표준입니다. 해당 포스트에서는 NGINX Plus를 사용하여 PCI DSS 모범 사례를 쉽게 구현하는 방법을 설명합니다.

목차

1. PCI DSS란?
 1-1. 왜 PCI DSS가 필요한가?
1-2. PCI DSS의 주요 내용은 무엇인가요?
1-3. PCI DSS 인증은 어떻게 이루어지나요?
1-4. PCI DSS 인증의 장점은 무엇인가요?
2. SSL에서 TLS 최신 버전으로 이동
3. TLS 활성화 후 테스트
4. 업스트림에 대한 통신 암호화
5. TLS 1.1 비활성화
6. WAF 추가
7. 모든 통신 암호화
8. 참고 및 옵션
 8-1. Linux 환경에서 root로 작업하지 않기
 8-2. 동적 구성
 8-3 이중 인증
9. 일반 모범 사례

1. PCI DSS란?

PCI DSS는 Payment Card Industry Data Security Standard의 약자로, 결제 카드 산업의 데이터 보안 표준을 말합니다. 간단히 말해서, 이 표준은 신용카드 정보와 같은 중요한 개인 정보를 안전하게 관리하고 보호하기 위한 규칙들을 정해 놓은 것입니다.

1-1. 왜 PCI DSS가 필요한가?

인터넷이 발달하면서 온라인 쇼핑이나 결제가 폭발적으로 늘어났습니다. 그런데 이 과정에서 신용카드 정보와 같은 민감한 정보들이 해킹에 노출되는 사례들도 늘어나고 있습니다. 이를 방지하고, 소비자들이 안심하고 결제할 수 있도록 하기 위해 PCI DSS가 만들어졌습니다.

1-2. PCI DSS의 주요 내용은 무엇인가요?

PCI DSS는 크게 6가지 핵심 목표와 12가지 요구사항으로 구성되어 있습니다. 여기서는 간단하게 주요 내용만 살펴볼것입니다.

  1. 방화벽 사용: 네트워크를 안전하게 보호하기 위해 방화벽을 사용해야 합니다.
  2. 기본 비밀번호 변경: 시스템의 기본 비밀번호를 변경하고, 강력한 비밀번호를 사용해야 합니다.
  3. 데이터 암호화: 신용카드 정보와 같은 민감한 정보는 암호화해서 저장하고 전송해야 합니다.
  4. 정기적인 보안 점검: 시스템과 네트워크의 보안 상태를 정기적으로 점검하고 관리해야 합니다.
  5. 접근 제한: 민감한 정보에 대한 접근 권한을 엄격하게 제한해야 합니다.

1-3. PCI DSS 인증은 어떻게 이루어지나요?

  1. 준비: 업체는 자체 보안 정책을 준비하고, PCI DSS 요구사항에 맞추어 시스템과 네트워크를 개선해야 합니다.
  2. 자가 평가: 업체는 자가 평가 질문지(Self-Assessment Questionnaire)를 통해 자체 평가를 진행하고, 진단 결과를 확인해야 합니다.
  3. 외부 감사: 인증 기관의 전문가들이 업체의 시스템과 네트워크를 검토하고, PCI DSS 요구사항을 충족하는지 확인합니다.
  4. 인증 획득: 외부 감사를 통과하면, 업체는 PCI DSS 인증을 획득할 수 있습니다.
  5. 지속적인 관리: 인증을 획득한 후에도 업체는 지속적으로 보안을 유지하고, 정기적으로 자가 평가 및 외부 감사를 받아야 합니다.

1-4. PCI DSS 인증의 장점은 무엇인가요?

PCI DSS 인증을 받으면 다음과 같은 장점이 있습니다.

  1. 신뢰도 향상: 고객들에게 안전한 결제 환경을 제공한다는 것을 증명함으로써 업체의 신뢰도가 향상됩니다.
  2. 고객 정보 보호: 신용카드 정보와 같은 민감한 정보를 안전하게 관리하고 보호할 수 있어, 고객 정보 유출 위험이 줄어듭니다.
  3. 법적 준수: 일부 국가에서는 PCI DSS 인증을 법적으로 요구하고 있어, 인증을 받음으로써 법적인 문제를 방지할 수 있습니다.
  4. 비즈니스 확장: 인증을 받은 업체는 다양한 결제 수단을 제공할 수 있어, 비즈니스 기회를 확장할 수 있습니다.

결론적으로, PCI DSS는 온라인 결제 시스템을 안전하게 운영하기 위한 중요한 표준입니다. 업체들은 이 표준을 준수함으로써 고객들의 신용카드 정보와 같은 민감한 정보를 보호하고, 안전한 결제 환경을 제공할 수 있습니다. 비록 여러분이 전문가는 아니지만, 이 글을 통해 PCI DSS에 대한 기본적인 이해를 갖추셨기를 바랍니다.

2. SSL에서 TLS 최신 버전으로 이동

SSL(Secure Sockets Layer)이 비활성화되었으며 10년 이상 지속되었습니다. 2015년 PCI 보안 표준 위원회는 공식적으로 이를 선언하고 SSL을 대체하는 프로토콜인 TLS(Transport Layer Security)의 최신 버전으로 이동하는 것에 대한 권고 사항을 발표했습니다. 요약은 다음과 같습니다.

  • 20년 이상 동안 SSL(Secure Sockets Layer)은 지금까지 출시된 가장 널리 사용되는 암호화 프로토콜 중 하나로 시장에 출시되었으며 프로토콜에 노출된 다양한 보안 취약성에도 불구하고 오늘날에도 널리 사용되고 있습니다.
  • 15년 전에 SSL v3.0은 TLS v1.0으로 대체되었으며 이후 TLS v1.1 및 v1.2로 대체되었습니다.
  • 현재까지 SSL 및 초기 TLS는 수정 사항이 없는 프로토콜의 보안 취약성으로 인해 더 이상 최소 보안 표준을 충족하지 않습니다. 엔터티가 가능한 한 빨리 안전한 대안으로 업그레이드하고 SSL 및 초기 TLS로의 폴백을 비활성화하는 것이 매우 중요합니다.
  • SSL은 PCI DSS에서 강력한 암호화의 예에서 제거되었으며 2016년 6월 30일 이후에는 더 이상 보안 제어로 사용할 수 없습니다.

지난 2년 동안 애플리케이션은 TLS 버전(1.0 ~ 1.2)을 사용하는 경우 PCI DSS를 준수했습니다. 그러나 2018년 7월 1일부터 TLS 1.0 사용자는 공격을 완화하고 위험을 최소화하기 위해 다른 접근 방식을 사용한다는 것을 문서화할 수 없는 한 PCI DSS를 준수하지 않습니다. PCI 보안 표준 위원회에 따르면 다음과 같습니다

  • 2018년 6월 30일 이후에도 기업 환경에 SSL 또는 초기 TLS가 있는 경우 시스템이 취약성에 영향을 받지 않는 것으로 확인되었음을 문서화하고 특정 환경에 대한 Compensating Controls를 통한 취약성 해결 프로세스를 완료해야 합니다.

PCI DSS 규정 준수를 감사하는 엔티티에서 근무하는 경우 PCI DSS 3.2.1 규정 준수를 유지하기 위해 6월 30일 이전에 TLS 1.0에서 최신 버전으로 마이그레이션할 계획이 이미 있을 수 있습니다. 여기서는 NGINX Plus를 사용하여 5가지 DCI PSS 모범 사례를 계획에 통합하는 방법에 대해 설명합니다.

3. TLS 활성화 후 테스트

첫 번째 단계는 최신 프로토콜과 암호를 사용하도록 NGINX Plus 구성을 수정하는 것입니다.
(가독성을 위해 ssl_ciphers 디렉티브에 대한 매개 변수에 줄 바꿈을 추가했습니다)

server {
    # ...
    ssl_protocols TLSv1.1 TLSv1.2;
    ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:
                ECDH+AES128:DH+AES:!AES256-GCM-SHA256:!AES256-GCM-SHA128:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    # ...
}

그런 다음 Qualys SSL Server Test, Mozilla의 Observatory 또는 둘 다를 기준으로 사이트를 테스트합니다. 일단 그렇게 하면, 준비가 다 된 거죠? 음, 그것은 완전한 과정의 한 단계일 뿐입니다.

4. 업스트림에 대한 통신 암호화

다양한 proxy_ssl_* 지시문을 사용하여 업스트림 서버와의 통신도 강력한 암호화로 보호되도록 할 수 있습니다.
예를 들어 다음 구성은 NGINX Plus와 업스트림 서버 간의 통신을 위해 TLS 1.2를 지정합니다.

server {
    # ...
    proxy_ssl_protocols TLSv1.2;
    proxy_ssl_ciphers   HIGH:!aNULL:!MD5;
    # ...
}

또 다른 옵션은 NGINX Plus 관리자 가이드에 설명된 대로 클라이언트 인증서를 사용하는 것입니다 .

전체 PCI DSS 컴플라이언스 프로세스는 지속적입니다. 항상 새로운 공격 벡터와 TLS 1.3과 같은 새로운 프로토콜이 존재합니다. 다음 감사에 대비하십시오!

5. TLS 1.1 비활성화

모든 클라이언트가 TLS 1.2를 통해 통신할 수 있는 경우에도 TLS 1.1을 사용해야 하는 이유가 있습니까? 하나는 모든 브라우저가 모든 버전의 TLS와 호환되는 것은 아니라는 것입니다. Wikipedia는 현재 웹 브라우저에서 지원되는 프로토콜에 대한 개요를 제공합니다.

그런 다음 가능한 경우 TLS 1.1을 완전히 실행 중지하십시오. TLS 1.2를 사용하는 것이 좋습니다.

사이트를 보호할 때 가장자리에서 HTTP/2를 추가로 사용 가능으로 설정할 수 있습니다. HTTP/2는 브라우저와 이를 지원하는 서버 간의 보다 효율적인 통신을 가능하게 합니다. (HTTP/2는 일반적으로 인터넷이 아닌 내부 네트워크를 통해 발생하기 때문에 사이트의 서버 간 통신에 큰 이점을 제공하지 않습니다.) Chrome, Edge, Firefox, Internet Explorer, Opera 및 Safari를 포함한 모든 최신 버전의 주요 브라우저는 HTTP/2를 지원합니다.

NGINX Plus는 OpenSSL 1.0.2 이상으로 구축된 지원되는 운영 체제에서 HTTP/2를 지원합니다. NGINX Plus R15 이상은 요청이 많았던 두 가지 보조 기능인 HTTP/2 서버 푸시 및 gRPC도 지원합니다. 이러한 기능을 사용하면 경우에 따라 암호화된 트래픽이 HTTP/1.1을 통한 암호화되지 않은 트래픽보다 빠릅니다!

6. WAF 추가

PCI DSS 환경에서는 WAF(Web Application Firewall)가 필수입니다.

어떤 규칙 세트를 사용하든지 로그 파일을 모니터링하는 것이 중요합니다. 트리거된 규칙뿐만 아니라 가능한 오탐지 감지에 대해서도 마찬가지입니다. 이를 돕기 위해 원격 syslog 서버에 로그인하도록 NGINX Plus를 구성할 수 있습니다.

모든 규칙 집합에서 로그 파일을 모니터링하는 것은 트리거된 규칙뿐만 아니라 가능한 잘못된 긍정을 탐지하는 데도 중요합니다. 이 문제를 해결하기 위해 원격 syslog 서버에 기록하도록 NGINX Plus를 구성할 수 있습니다.

분석에 도움이 되도록 ELK(Elastic search/Logstash/Kibana) 스택의 최신 버전인 Elastic Stack(Elastic Stack)과 같은 도구에 로그를 입력할 수 있습니다. 또한 원격 서버에서 WORM(Once-Read Many) 저장소를 쓰기 위해 백업할 수 있습니다. WORM 저장소의 데이터는 변경할 수 없으므로 로그가 변조될 가능성 없이 안전하게 저장됩니다.

이 방법의 또 다른 장점은 NGINX Plus가 실행 중인 서버의 로그 파일에 쓸 때 디스크 I/O에서 발생하는 성능 저하를 방지한다는 것입니다.

7. 모든 통신 암호화

내부 네트워크는 종종 신뢰할 수 있는 것으로 간주되는 반면, Edge를 보호하고 모든 표준을 충족하기 위해 많은 노력을 기울입니다. 그러나 감사자(또는 침입자)가 내부 네트워크에 네트워크 스니퍼(sniffer)를 가지고 있으면 데이터베이스 연결, 애플리케이션 데이터 및 인증 데이터를 포함한 암호화되지 않은 모든 트래픽을 읽을 수 있습니다.

예를 들어 PCI DSS를 사용하려면 사용자가 인터넷을 통해 전송되는 트래픽을 보호하는 TLS 연결을 통해 사이트를 인증해야 합니다. 그러나 내부적으로 암호화되지 않은 LDAP 서버에 대해 인증 프로세스를 수행할 수 있습니다.

한 가지 해결책은 내부 네트워크가 안전하다는 사실에 의존하지 않고 내부 트래픽에 LDAPS를 사용하는 것입니다.

시스템 내의 유선을 통해 전송되는 정보를 확인하려면 Wireshark가 유용한 도구입니다. 다음 그림에서 Wireshark는 서버 간 전송을 캡처하고 LDAP 쿼리에 대한 이 예에서와 같이 일반 텍스트로 암호를 쉽게 볼 수 있습니다.

Wireshark를 통해 일반 텍스트로 LDAP 자격 증명을 사용하여 서버 간 전송을 캡처한 결과입니다.

또 다른 예로, 개발자는 프록시 서버를 우회하여 암호화되지 않은 개발 애플리케이션 서버에 직접 액세스할 수 있습니다. 이 경우, 의심할 여지없이 광범위한(전체는 아니지만) 액세스 권한을 부여하는 자격 증명을 쉽게 스니핑할 수 있습니다.

프로덕션에서 TLS 프록시를 사용할 때의 또 다른 권장 사항은 개발 환경을 프로덕션 환경과 최대한 유사하게 만드는 것입니다.

8. 참고 및 옵션

위에서 설명한 다섯 가지 모범 사례는 PCI DSS 규정 준수에 필요합니다. 또한 사이트의 보안을 더욱 향상시키는 데 도움이 되는 몇 가지 옵션과 추가 정보가 있습니다.

8-1. Linux에서 root로 작업하지 않기

기본적으로, NGINX는 시스템에 의해 시작되고 환경을 설정하고 권한이 있는 포트를 바인딩하고 인증서를 처리한 다음 유효 사용자를 루트가 아닌 사용자로 변경하여 권한을 삭제합니다.

SSL 인증서는 루트 사용자만 액세스할 수 있고 NGINX에 할당된 권한 없는 사용자는 액세스할 수 없으므로 기본 설정을 사용하여 보안을 설정할 수 있습니다.

하지만 여러 가지 선택지가 있습니다. 예를 들어 NGINX Plus를 루트로 시작하지 않으려면 다음을 수행할 수 있습니다.

setcap CAP_NET_BIND_SERVICE /usr/sbin/nginx

권한 있는 사용자로 실행되지 않고 1024 미만의 포트의 NGINX 바인딩을 허용합니다

IP 투명성이 필요한 경우 다음과 같은 CAP_NET_RAW 기능을 NGINX에 추가할 수 있습니다.

setcap CAP_NET_RAW /usr/sbin/nginx

그러나 업스트림 서버의 경우 낮은 수준의 포트가 반드시 필요한 것은 아닙니다. 권한이 없는 포트에서도 NGINX Plus를 실행할 수 있습니다.

파일 시스템 사용 권한 외에도 다음과 같은 몇 가지 참고 사항이 있습니다:

  • 권한 없는 사용자의 모든 포트는 1024 이상이어야 합니다 (CAP_NET_BIND_SERVICE 기능을 할당하지 않은 경우)
  • 소켓을 사용하는 경우 NGINX 프로세스가 이러한 소켓에 액세스할 수 있는지 확인하십시오
  • setuid-call 은 NGINX Plus를 실행하는 권한이 없는 사용자에게는 작동하지 않으므로 NGINX Plus 구성의 사용자 지시문을 주석 처리해야 합니다

8-2. 동적 구성

업스트림 서버 그룹에 대한 구성 변경을 위해 NGINX Plus 서버에 대한 불필요한 로그인을 방지하려면 NGINX Plus API를 사용하여 동적으로 변경하거나 DNS를 사용하여 동적 Service Discovery을 수행하십시오. 그런 다음 NGINX Plus 구성 파일을 수동으로 수정하지 않고 업스트림 서버를 변경할 수 있습니다.

8-3. 이중 인증

타사 인증 방법은 하위 요청을 사용하여 NGINX Plus에 통합할 수 있습니다 . 따라서 인증을 위해 하드웨어 토큰과 같은 2단계 인증(2FA) 방법을 쉽게 통합할 수 있습니다.

9. 일반 모범 사례

이 포스트는 운영체제 강화와 같은 관련 작업이 아닌 NGINX Plus에 대한 변경 사항에 초점을 맞추고 있지만, 다음과 같은 보안 개선을 위한 추가 모범 사례도 권장합니다.

  • 버전 번호(예: NGINX Plus 또는 PHP 버전)를 불필요하게 노출하지 마십시오. server_tokens 디렉티브를 사용하여 오류 페이지 및 서버 응답 헤더에서 NGINX Plus 버전을 생략할 수 있습니다. NGINX Plus R9 이상에서는 값을 명시적으로 설정할 수도 있습니다.
  • 서버가 직접 또는 프록시 서버를 사용하여 NGINX Plus 리포지토리에 액세스할 수 없는 경우 로컬 리포지토리 미러(Local Repository Mirror)를 생성하는 것이 좋습니다.
  • 어디서나 트래픽을 암호화 하십시오.
  • FIPS(Federal Information Processing Standard) 140-2 준수가 필요하지 않더라도 비교적 쉽게 설정할 수 있습니다. FIPS 140-2 준수 시스템 에서 NGINX Plus는 FIPS 140-2 준수 로 인해 비활성화된 취약한 암호와 함께 TLS 암호화 네트워크 트래픽을 해독하고 암호화하는 데 사용할 수 있습니다 .
  • 가능한 한 관련 시스템에 대한 액세스를 제한하십시오.
  • 문서화가 핵심입니다. 귀하(또는 후계자)가 감사자에게 귀하의 설정을 설명할 수 있도록 귀하가 달성하려고 했던 것과 그것을 달성하기 위해 노력한 방법을 기록하십시오.

NGINX Plus를 직접 사용해 보려면 지금 무료 30일 평가판을 시작하거나 당사에 연락하여 사용 사례에 대해 논의하십시오.