트래픽 관리 도구를 활용해 Kubernetes를 보호하는 6가지 방법

Jenn GileNGINX 제품 마케팅 총괄

편집자 – 이 글은 총 10편으로 구성된 시리즈의 일부입니다:

1. 프로덕션급 Kubernetes로 복잡성 줄이기
2. 고급 트래픽 관리로 Kubernetes의 복원력을 향상하는 방법
3. Kubernetes에서 가시성을 개선하는 방법
4. 트래픽 관리 도구를 사용하여 Kubernetes를 보호하는 6가지 방법(이 게시물)
5. 인그레스 컨트롤러 선택 가이드 1부: 요구 사항 파악하기
6. 인그레스 컨트롤러 선택 가이드, 2부: 위험 요소와 미래 대비
7. 인그레스 컨트롤러 선택 가이드, 3부: 오픈 소스 vs. 기본 제공 vs. 상용
8. 인그레스 컨트롤러 선택 가이드, 4부: NGINX 인그레스 컨트롤러 옵션
9. 서비스 메시를 선택하는 방법
10. 동적 Kubernetes 클라우드 환경에서 NGINX Ingress Controller 성능 테스트

전체 블로그 시리즈를 무료 eBook으로 다운로드할 수도 있습니다. Kubernetes를 테스트 환경에서 프로덕션 환경으로 전환하기.

As discussed in 속도를 저하시키지 않고 클라우드 네이티브 앱을 보호하는 방법에서 설명했듯이, 저희는 클라우드 네이티브 앱을 기존 앱보다 보호하기 어렵게 만드는 세 가지 요인을 확인했습니다:

1. 클라우드 네이티브 앱 제공은 도구의 난립을 초래하고 일관되지 않은 엔터프라이즈급 서비스를 제공합니다
2. 클라우드 네이티브 앱 제공 비용은 예측하기 어렵고 높을 수 있습니다
3. SecOps 팀은 클라우드 네이티브 앱을 보호하는 데 어려움을 겪고 있으며 DevOps 팀과 갈등을 빚고 있습니다

세 가지 요인 모두 보안에 동일한 수준으로 영향을 미칠 수 있지만, 세 번째 요인은 가장 ‘인간적인’ 문제이기 때문에 해결하기가 가장 어려울 수 있습니다. SecOps가 클라우드 네이티브 앱을 보호할 수 없거나 보호할 권한이 없는 경우, 취약점과 침해 사고처럼 명백한 결과도 있지만 민첩성 저하와 디지털 혁신 정체처럼 겉으로 드러나지 않는 결과도 있습니다.

이러한 숨겨진 비용을 좀 더 자세히 살펴보겠습니다. 조직은 민첩성과 비용 절감 효과를 기대하며 Kubernetes를 선택합니다. 하지만 Kubernetes 환경에서 보안 사고가 발생하면 대부분의 조직은 운영 환경에서 Kubernetes 배포를 철회합니다. 이로 인해 조직의 미래에 필수적인 디지털 혁신 이니셔티브가 지연될 뿐만 아니라, 엔지니어링 노력과 비용도 낭비됩니다. 따라서 논리적인 결론은 다음과 같습니다. Kubernetes를 테스트 환경에서 운영 환경으로 전환하려면 보안을 조직 구성원 모두가 책임지는 전략적 요소로 간주해야 합니다.

이 게시물에서는 Kubernetes 트래픽 관리 도구로 해결할 수 있는 6가지 보안 사용 사례를 살펴봅니다. 이를 통해 SecOps는 DevOps 및 NetOps와 협업하여 클라우드 네이티브 앱과 API를 더욱 효과적으로 보호할 수 있습니다. 이러한 기법을 조합해 고객에게 미치는 영향을 최소화하면서 앱과 API를 안전하게 보호하는 종합적인 보안 전략을 수립하는 경우가 많습니다.

1. 사이버 공격을 방지하기 위해 CVE를 신속하게 해결하세요
2. OWASP Top 10 및 서비스 거부 공격 차단
3. 앱에서 인증 및 권한 부여 작업을 분리
4. 가드레일을 적용한 셀프서비스 설정
5. 엔드투엔드 암호화 구현
6. 클라이언트가 신뢰할 수 있는 구현의 강력한 암호화 알고리즘을 사용하고 있는지 확인하세요

보안 및 ID 용어

사용 사례를 살펴보기에 앞서, 이 글 전반에서 접하게 될 몇 가지 보안 및 ID 관련 용어를 간단히 알아보겠습니다.

• 인증 및 권한 부여 – 적절한 사용자와 서비스만 백엔드 또는 애플리케이션 구성 요소에 액세스할 수 있도록 보장하는 데 필요한 기능:
  • 인증 – 요청을 보내는 클라이언트가 자신이 주장하는 당사자인지 확인하기 위한 신원 검증입니다. 비밀번호나 JSON 웹 토큰(JWT)과 같은 ID 토큰을 통해 수행됩니다.
  • 권한 부여 – 리소스 또는 기능에 액세스할 수 있는 권한을 확인합니다. 세션 쿠키, 세션 ID, 그룹 ID 또는 토큰 내용과 같은 계층 7 속성을 액세스 토큰으로 사용하여 수행합니다.
• 주요 취약점 및 노출(CVE) – 공개적으로 알려진 결함, 즉 “소프트웨어, 펌웨어, 하드웨어 또는 서비스 구성 요소에서 악용될 수 있는 약점으로 인해 영향을 받는 하나 이상의 구성 요소의 기밀성, 무결성 또는 가용성에 부정적인 영향을 미치는 결함”을 수록한 데이터베이스입니다(https://www.cve.org/). CVE는 도구를 관리하는 개발자, 침투 테스터, 사용자나 고객 또는 커뮤니티 구성원(예: ‘버그 헌터’)이 발견할 수 있습니다. 악의적인 행위자에게 유리한 기회를 주지 않도록 취약점을 공개하기 전에 소프트웨어 소유자에게 패치를 개발할 시간을 주는 것이 일반적입니다.
• 서비스 거부(DoS) 공격 – 악의적 행위자가 사이트를 마비시킬 목적으로 웹사이트에 대량의 요청(TCP/UDP 또는 HTTP/HTTPS)을 보내는 공격입니다. DoS 공격은 가용성에 영향을 미치므로 주로 공격 대상의 평판을 훼손합니다. 분산 서비스 거부(DDoS) 공격은 여러 출처에서 동일한 네트워크나 서비스를 공격하는 방식으로, 공격자 네트워크의 규모가 매우 클 수 있어 방어하기가 더 어렵습니다. DoS 공격을 방어하려면 공격을 적응형으로 식별하고 차단하는 도구가 필요합니다. 자세한 내용은 분산 서비스 거부(DDoS)란 무엇인가요?
• 종단 간 암호화(E2EE) – 사용자와 앱 간에 데이터가 오가는 전 과정에서 데이터를 완전히 암호화하는 방식입니다. E2EE에는 SSL 인증서가 필요하며 경우에 따라 mTLS도 필요할 수 있습니다.
• 상호 TLS(mTLS) – 클라이언트와 호스트 모두에 인증(SSL/TLS 인증서 사용)을 요구하는 방식입니다. mTLS를 사용하면 클라이언트와 호스트 간에 전송되는 데이터의 기밀성과 무결성도 보호할 수 있습니다. mTLS는 동일한 클러스터에 있는 두 서비스 사이에서 Kubernetes 파드 수준까지 적용할 수 있습니다. SSL/TLS 및 mTLS에 관한 훌륭한 소개는 mTLS란 무엇인가요?에서 F5 Labs를 참조하세요.
• SSO(Single Sign-On) – SSO 기술(SAML, OAuth, OIDC 포함)을 사용하면 인증 및 권한 부여를 더 쉽게 관리할 수 있습니다.
  • 간소화된 인증 – SSO를 사용하면 사용자가 각 리소스나 기능마다 고유한 ID 토큰을 보유할 필요가 없습니다.
  • 표준화된 권한 부여 – SSO를 사용하면 역할, 부서 및 직급에 따라 사용자 접근 권한을 설정할 수 있으므로 각 사용자의 권한을 개별적으로 구성할 필요가 없습니다.
• SSL(보안 소켓 계층)/TLS(전송 계층 보안) – 네트워크로 연결된 컴퓨터 간에 인증 및 암호화된 연결을 설정하기 위한 프로토콜입니다. SSL/TLS 인증서는 웹사이트의 신원을 인증하고 암호화된 연결을 설정합니다. SSL 프로토콜은 1999년에 폐기되고 TLS 프로토콜로 대체되었지만, 이러한 관련 기술을 여전히 “SSL” 또는 “SSL/TLS”라고 통칭하는 경우가 많습니다. 일관성을 위해 이 글의 나머지 부분에서는 SSL/TLS라는 용어를 사용하겠습니다.
• 웹 애플리케이션 방화벽(WAF) – 리버스 프록시로, 앱과 API를 대상으로 하는 정교한 공격(OWASP Top 10 및 기타 지능형 위협 포함)을 탐지하고 차단하는 동시에 “안전한” 트래픽은 통과시킵니다. WAF는 민감한 데이터를 탈취하거나 시스템을 장악하여 대상을 손상시키려는 공격을 방어합니다. 일부 공급업체는 WAF와 DoS 방어 기능을 하나의 도구로 통합하여 제공하는 반면, 다른 공급업체는 WAF와 DoS 도구를 별도로 제공합니다.
• 제로 트러스트 – 보안 수준이 높은 조직에서 자주 사용되지만 모든 조직에 적용할 수 있는 보안 개념으로, 데이터의 저장 및 전송 전 단계에서 데이터를 보호해야 한다는 원칙입니다. 즉, 조직은 기본적으로 어떤 사용자나 기기도 ‘신뢰’하지 않으며, 모든 트래픽을 철저히 검증해야 합니다. 제로 트러스트 아키텍처에는 일반적으로 인증, 권한 부여, mTLS가 함께 적용되며, E2EE도 구현될 가능성이 높습니다.

사용 사례: 사이버 공격을 방지하기 위해 CVE를 신속하게 해결

솔루션: 적시에 선제적으로 패치 알림을 제공하는 도구를 사용하세요

According to a Ponemon Institute의 연구에 따르면, 2019년에는 심각하거나 우선순위가 높은 취약점에 대한 패치가 출시된 시점부터 해당 취약점을 악용하려는 공격이 조직에서 관찰되기까지 평균 43일의 ‘유예 기간’이 있었습니다. F5 NGINX에서는 이후 몇 년 동안 이 기간이 크게 단축되는 것을 확인했으며(심지어 2021년 Apple iOS 15의 경우에는 제로데이까지 단축됨), 이러한 이유로 가능한 한 빨리 패치할 것을 권장합니다. 하지만 CVE가 발표된 후에도 트래픽 관리 도구용 패치가 몇 주 또는 심지어 몇 달 동안 제공되지 않는다면 어떻게 해야 할까요?

전담 엔지니어링 팀이 아닌 커뮤니티 기여자들이 개발하고 유지 관리하는 도구는 CVE 발표보다 몇 주 또는 몇 달 뒤처질 수 있어, 조직이 43일이라는 기간 내에 패치를 적용하기 어려울 수 있습니다. 한 사례에서는, OpenResty가 NGINX 관련 보안 패치를 적용하는 데 4개월이 걸렸습니다. 이로 인해 OpenResty 기반 Ingress 컨트롤러를 사용하는 모든 사용자가 최소 4개월 동안 취약점에 노출되었습니다. 하지만 실제로는 오픈 소스 프로젝트에 의존하는 소프트웨어에 패치가 제공되기까지 추가로 지연되는 경우가 많습니다.

CVE 패치를 가장 빠르게 적용하려면 트래픽 관리 도구를 선택할 때 다음 두 가지 특성을 확인하세요:

• 전담 엔지니어링 팀 – 도구 개발을 커뮤니티 자원봉사자가 아닌 엔지니어링 팀이 관리하면, 도구의 안정적인 운영에 전념하는 인력이 있으며 가능한 한 신속하게 패치를 릴리스하는 일을 우선시할 수 있다는 뜻입니다.
• 통합된 코드베이스 – 외부 종속성 없이(OpenResty와 관련해 설명한 것처럼) 애자일 스프린트 한 번이면 패치를 적용할 수 있습니다.

CVE 패치에 대한 자세한 내용은 NGINX Plus로 보안 취약점을 빠르고 간편하게 완화하기를 참조하세요.

사용 사례: OWASP 10대 보안 위험 및 DoS 공격 차단

솔루션: 유연하고 Kubernetes 친화적인 WAF 및 DoS 방어 기능을 배포하세요

Kubernetes 앱에 적합한 WAF 및 DoS 보호 솔루션을 선택할 때는 기능 외에도 다음 두 가지 요소를 고려해야 합니다:

• 유연성 – 도구를 Kubernetes 내부에 배포하는 것이 가장 적합한 경우도 있으므로, Kubernetes 내부와 외부 어디서든 실행할 수 있는 인프라 독립적인 도구가 필요합니다. 모든 배포 환경에서 동일한 도구를 사용하면 정책을 재사용할 수 있고 SecOps 팀의 학습 부담도 줄일 수 있습니다.
• 리소스 사용량 – 최고의 Kubernetes 도구는 리소스 사용량이 적어 처리량, 초당 요청 수, 지연 시간에 미치는 영향을 최소화하면서 리소스를 적절히 사용할 수 있습니다. DevOps 팀은 보안 도구가 애플리케이션 속도를 저하시킨다는 인식 때문에 도입을 꺼리는 경우가 많으므로, 리소스 사용량이 적은 고성능 도구를 선택하면 도입 가능성을 높일 수 있습니다.

WAF와 DoS 보호 기능을 통합한 도구가 더 효율적으로 보일 수 있지만, 실제로는 더 큰 설치 공간으로 인한 CPU 사용량과 유연성 측면에서 모두 문제가 발생할 수 있습니다. 두 기능이 모두 필요하지 않은 경우에도 WAF와 DoS 보호 기능을 함께 배포해야 하기 때문입니다. 결국 이 두 가지 문제는 Kubernetes 배포의 총소유비용을 높이는 동시에 다른 필수 도구와 서비스에 대한 예산 확보를 어렵게 만들 수 있습니다.

조직에 적합한 보안 도구를 선택했다면 이제 해당 도구를 어디에 배포할지 결정해야 합니다. Kubernetes 앱을 보호하기 위한 애플리케이션 서비스는 일반적으로 다음 네 위치에 배포할 수 있습니다:

• 프런트 도어에서(외부 로드 밸런서(예: F5 NGINX Plus 또는 F5 BIG‑IP)에 배포) – 여러 클러스터에 전역 정책을 적용할 수 있으므로 전반적인 글로벌 보호에 적합합니다
• 에지에서 (인그레스 컨트롤러에서, 예: F5 NGINX Ingress Controller) – 단일 클러스터 전체에 표준화된 '세분화된' 보호를 제공하는 데 적합
• 서비스 수준에서(NGINX Plus와 같은 경량 로드 밸런서에서) – 클러스터 내 소수의 서비스가 고유한 정책을 공통으로 필요로 하는 경우 필요한 접근 방식일 수 있습니다
• Pod에서(애플리케이션의 일부로) – 정책이 앱에만 적용되는 경우 사용할 수 있는 고도로 맞춤화된 접근 방식

그렇다면 네 가지 옵션 중 어떤 것이 가장 좋을까요? 음…상황에 따라 다릅니다!

WAF를 배포할 위치

먼저, WAF 배포 방식은 좀 더 세심한 판단이 필요한 경우가 많으므로 이에 대해 살펴보겠습니다.

• 프런트 도어 및 에지 – 조직에서 '심층 방어' 보안 전략을 선호하는 경우, 전역 보호와 사용자 지정 보호 간의 효율적인 균형을 제공할 수 있도록 외부 로드 밸런서와 Ingress 컨트롤러 모두에 WAF를 배포하는 것이 좋습니다.
• 프런트 도어 또는 에지 – '심층 방어' 전략을 사용하지 않는 경우에는 한 위치에만 배포해도 되며, 배포 위치는 담당 조직에 따라 달라집니다. 기존 NetOps 팀이 보안을 담당한다면 전통적인 프록시(외부 로드 밸런서)에서 관리하는 방식을 더 편하게 여길 수 있습니다. 반면 Kubernetes에 익숙하고 보안 구성을 클러스터 구성과 가까운 곳에 두려는 DevSecOps 팀은 인그레스 수준에 WAF를 배포할 수 있습니다.
• 서비스 또는 Pod별 – 팀에서 서비스나 앱에 대한 특정 요구 사항이 있는 경우 필요에 따라 추가 WAF를 선택적으로 배포할 수 있습니다. 하지만 이러한 위치에 배포하면 비용이 더 많이 든다는 점에 유의해야 합니다. 개발 시간이 늘어나고 클라우드 예산이 증가할 뿐만 아니라, “어떤 WAF가 의도치 않게 트래픽을 차단하고 있는가?”와 같은 문제를 파악하기 위한 문제 해결 작업으로 인해 운영 비용도 증가할 수 있습니다.

DoS 방어를 배포할 위치

DoS 공격 방어는 한 곳, 즉 프런트 도어나 Ingress 컨트롤러 중 한 곳에만 필요하므로 비교적 간단합니다. 프런트 도어와 에지 모두에 WAF를 배포하는 경우, 가장 광범위한 지점을 보호할 수 있도록 프런트 도어 WAF 앞에 DoS 방어를 배포하는 것이 좋습니다. 이렇게 하면 원치 않는 트래픽이 WAF에 도달하기 전에 걸러져 컴퓨팅 리소스를 더 효율적으로 사용할 수 있습니다.

각 배포 시나리오에 대한 자세한 내용은 Kubernetes에서 애플리케이션 서비스 배포하기, 2부를 참조하세요.

사용 사례: 앱에서 인증 및 권한 부여 분리

솔루션: 인그레스 지점에서 인증 및 권한 부여를 중앙 집중화

앱과 서비스에 흔히 구현되는 비기능 요구 사항 중 하나는 인증 및 권한 부여입니다. 소규모 환경에서는 이 방식으로 인해 복잡성이 어느 정도 증가하더라도 관리 가능한 수준이며, 앱을 자주 업데이트할 필요가 없다면 충분히 감수할 수 있습니다. 하지만 규모가 커지고 릴리스 속도가 빨라지면 앱에 인증 및 권한 부여 기능을 통합하는 방식은 더 이상 유지하기 어렵습니다. 각 앱이 적절한 액세스 프로토콜을 준수하도록 관리하다 보면 앱의 비즈니스 로직에 집중하기 어려워질 수 있으며, 더 심각하게는 이를 간과해 정보 유출로 이어질 수도 있습니다. SSO 기술을 사용하면 개별 사용자 이름과 비밀번호 대신 하나의 자격 증명 세트를 사용하여 보안을 강화할 수 있지만, 개발자는 여전히 SSO 시스템과 연동하기 위한 코드를 앱에 포함해야 합니다.

더 나은 방법이 있습니다. 인증 및 권한 부여를 Ingress 컨트롤러에 위임하는 것입니다.

Ingress 컨트롤러는 이미 클러스터로 유입되는 모든 트래픽을 검사하고 적절한 서비스로 라우팅하므로, 인증과 권한 부여를 중앙에서 처리하기에 효율적인 선택입니다. 이를 통해 개발자는 애플리케이션 코드에서 관련 로직을 구축하고 유지 관리하며 반복 구현해야 하는 부담에서 벗어날 수 있습니다. 대신 네이티브 Kubernetes API를 사용하여 인그레스 계층에서 SSO 기술을 신속하게 활용할 수 있습니다.

이 주제에 대해 자세히 알아보려면 Okta 및 NGINX Ingress Controller를 사용하여 Kubernetes용 OpenID Connect 인증 구현하기를 참조하세요.

사용 사례: Guardrails를 적용한 셀프서비스 설정

솔루션: 역할 기반 액세스 제어(RBAC) 구현

Kubernetes는 RBAC를 사용하여 다양한 유형의 사용자가 이용할 수 있는 리소스와 작업을 제어합니다. 이는 관리자 또는 슈퍼유저가 사용자나 사용자 그룹이 클러스터 내의 Kubernetes 객체 또는 특정 네임스페이스와 상호 작용할 수 있는 방식을 지정할 수 있게 해 주는 유용한 보안 조치입니다.

Kubernetes RBAC는 기본적으로 활성화되어 있지만, Kubernetes 트래픽 관리 도구에도 RBAC가 활성화되어 있고 조직의 보안 요구 사항에 부합하는지 확인해야 합니다. RBAC를 적용하면 사용자는 티켓이 처리될 때까지 기다릴 필요 없이 업무 수행에 필요한 기능에 제한적으로 액세스할 수 있습니다. 하지만 RBAC를 구성하지 않으면 사용자에게 불필요하거나 자격이 없는 권한이 부여될 수 있으며, 이러한 권한이 오용될 경우 보안 취약점으로 이어질 수 있습니다.

Ingress 컨트롤러는 RBAC로 구성할 경우 여러 사용자와 팀에 서비스를 제공할 수 있는 대표적인 도구입니다. Ingress 컨트롤러가 단일 네임스페이스 수준까지 세분화된 액세스 관리를 지원하면 RBAC를 사용해 멀티테넌시를 통한 효율적인 리소스 활용이 가능합니다.

예를 들어 여러 팀이 다음과 같이 Ingress 컨트롤러를 사용할 수 있습니다:

• 네트워크 운영팀 – 애플리케이션의 외부 진입점(예: 호스트 이름 및 TLS 인증서)을 구성하고 트래픽 제어 정책을 여러 팀에 위임합니다
• DevOps 팀 A – TCP/UDP 부하 분산 및 라우팅 정책을 프로비저닝합니다
• DevOps 팀 B – 과도한 요청으로부터 서비스를 보호하기 위해 요청 속도 제한 정책을 구성합니다
• ID 팀 – 인증 및 권한 부여 구성 요소를 관리하는 동시에 엔드투엔드 암호화 전략의 일환으로 mTLS 정책을 구성합니다
• DevSecOps 팀 – WAF 정책을 설정합니다

NGINX Ingress Controller에서 RBAC를 활용하는 방법을 알아보려면 NGINX Ingress Controller를 활용한 고급 Kubernetes 배포를 시청하세요. 13분 50초부터 전문가들이 보안, 셀프서비스, 멀티테넌시를 위해 RBAC와 리소스 할당을 활용하는 방법을 설명합니다.

사용 사례: 엔드투엔드 암호화 구현

솔루션: 트래픽 관리 도구를 사용하세요

엔드투엔드 암호화(E2EE)는 민감한 정보나 개인정보를 취급하는 조직에서 점점 더 보편적인 요구 사항이 되고 있습니다. 금융 데이터든 소셜 미디어 메시지든, 소비자의 개인정보 보호에 대한 기대와 GDPR 및 HIPAA 같은 규제가 맞물리면서 이러한 보호 방식에 대한 수요가 증가하고 있습니다. E2EE를 구현하기 위한 첫 단계는 백엔드 앱이 SSL/TLS 트래픽을 수신하도록 설계하거나, 앱에서 SSL/TLS 관리를 분리해 처리하는 도구를 사용하는 것입니다(보안 기능 분리, 성능, 키 관리 등의 측면에서 후자가 권장됨). 그런 다음 환경의 복잡성에 따라 트래픽 관리 도구를 구성합니다.

가장 일반적인 시나리오: Ingress Controller를 사용한 E2EE

엔드포인트가 하나뿐인 앱(단순한 앱 또는 Kubernetes로 '리프트 앤 시프트'한 모놀리식 앱)이 있거나 서비스 간 통신이 없는 경우, Ingress 컨트롤러를 사용하여 Kubernetes 내에서 E2EE를 구현할 수 있습니다.

1단계: Ingress 컨트롤러가 서비스 측 인증서 또는 mTLS 인증서를 사용하는 암호화된 SSL/TLS 연결만 허용하도록 설정하세요. 인그레스 및 이그레스 트래픽 모두에 적용하는 것이 가장 좋습니다.

2단계: Ingress 컨트롤러가 트래픽을 앱으로 전송하기 전에 복호화한 후 다시 암호화하도록 요구하는 일반적인 기본 설정을 처리합니다. 이 작업은 몇 가지 방법으로 수행할 수 있으며, 선택할 방법은 Ingress 컨트롤러와 요구 사항에 따라 달라집니다:

• Ingress 컨트롤러가 SSL/TLS 패스스루를 지원하는 경우, 연결을 복호화하거나 SSL/TLS 인증서 또는 키에 액세스하지 않고도 서버 이름 표시(SNI) 헤더를 기반으로 SSL/TLS로 암호화된 연결을 라우팅할 수 있습니다.
• 또는 SSL/TLS 종료를 설정할 수 있습니다. 이 경우 Ingress 컨트롤러가 트래픽을 종료한 다음, 평문으로 전달하거나 mTLS 또는 서비스 측 SSL/TLS를 사용해 트래픽을 다시 암호화하여 Kubernetes 서비스의 백엔드 또는 업스트림으로 프록시합니다.

덜 일반적인 시나리오: Ingress 컨트롤러와 서비스 메시를 사용한 E2EE

클러스터 내에서 서비스 간 통신이 이루어지는 경우, 두 영역에 E2EE를 구현해야 합니다. 즉, Ingress 컨트롤러를 통한 인그레스·이그레스 트래픽과 서비스 메시를 통한 서비스 간 트래픽입니다. E2EE에서 서비스 메시의 역할은 지정된 서비스끼리만 안전하게 통신하도록 보장하는 것입니다. E2EE용 서비스 메시를 설정할 때는 서비스 간 mTLS(인증서 필수로 설정)와 서비스 간 트래픽 액세스 제어(통신이 허용된 서비스를 지정)라는 두 가지 요소를 통해 제로 트러스트 환경을 구현해야 합니다. 이상적으로는 Kubernetes 클러스터 전체에서 완전한 E2EE 보안을 구현하기 위해 애플리케이션 간에도 mTLS를 적용해야 합니다. 이는 서비스 메시와 인그레스·이그레스 컨트롤러를 통해 관리됩니다.

네트워크를 통해 전송되면서 노출된 데이터를 암호화하는 방법에 대한 자세한 내용은 NGINX Service Mesh의 mTLS 아키텍처를 참조하세요.

사용 사례: 클라이언트가 신뢰할 수 있는 구현의 강력한 암호화 알고리즘을 사용하도록 보장

솔루션: 연방 정보 처리 표준(FIPS) 준수

소프트웨어 업계에서 FIPS는 일반적으로 암호화를 구체적으로 다루는 간행물인 FIPS PUB 140-2 암호화 모듈에 대한 보안 요구사항을 의미하며, 이는 미국과 캐나다가 공동으로 마련한 표준입니다. 이 표준은 민감한 정보를 보호하기 위해 양국 연방 기관에서 인정하는 암호화 모듈의 시험 및 인증 절차를 표준화합니다. “하지만 잠깐만요!”라고 생각하실 수도 있습니다. “저는 북미 정부 기관과 일하지 않으니 FIPS는 상관없어요.” 하지만 업종이나 지역에 관계없이 FIPS를 준수하는 것은 현명한 선택이 될 수 있습니다. FIPS는 사실상 전 세계 암호화의 기준이기도 하기 때문입니다.

FIPS를 준수하는 것이 반드시 어려운 일은 아니지만, 운영 체제와 관련 트래픽 관리 도구가 모두 FIPS 모드로 작동할 수 있어야 합니다. 운영 체제를 FIPS 모드로 실행하기만 하면 FIPS 규정을 준수할 수 있다는 일반적인 오해가 있습니다. 운영 체제가 FIPS 모드로 실행 중이더라도 Ingress 컨트롤러와 통신하는 클라이언트가 강력한 암호화 알고리즘을 사용하지 않을 수 있습니다. FIPS 모드로 작동할 때는 운영 체제와 Ingress 컨트롤러에서 일반적인 SSL/TLS 암호화 알고리즘 중 일부만 사용할 수 있습니다.

Kubernetes 배포에 FIPS를 설정하는 과정은 다음 네 단계로 이루어집니다:

• 1단계: 운영 체제를 FIPS 모드로 구성합니다
• 2단계: 운영 체제와 OpenSSL이 FIPS 모드인지 확인합니다
• 3단계: Ingress 컨트롤러 설치
• 4단계: FIPS 상태 확인을 수행하여 FIPS 140-2 준수 여부 확인

아래 예시와 같이 운영 체제와 NGINX Plus에서 사용하는 OpenSSL 구현 모두에서 FIPS 모드를 활성화하면, NGINX Plus로 들어오고 나가는 모든 최종 사용자 트래픽이 검증된 FIPS 지원 암호화 엔진을 통해 복호화 및 암호화됩니다.

FIPS에 대한 자세한 내용은 NGINX Plus로 FIPS 규정 준수 달성에서 확인하세요.

NGINX로 Kubernetes 보안 강화

이러한 보안 방법 중 일부(또는 전부)를 구현할 준비가 되었다면, 사용 중인 도구가 해당 사용 사례를 지원하는 데 필요한 기능과 역량을 갖추고 있는지 확인해야 합니다. NGINX는 프로덕션 환경에 바로 적용할 수 있는 Kubernetes 트래픽 관리 도구 제품군을 통해 이를 지원합니다:

• NGINX Ingress Controller – NGINX Plus 기반의 Kubernetes용 Ingress 컨트롤러로, 고급 트래픽 제어 및 조정, 모니터링 및 가시성, 인증 및 SSO를 처리하고 API 게이트웨이 역할을 합니다.
• F5 NGINX App Protect – F5의 시장 선도적인 보안 기술을 기반으로 구축되어 NGINX Ingress Controller 및 NGINX Plus와 통합되는 최신 앱과 API를 위한 종합적인 보호 기능입니다. 모듈식 접근 방식을 사용하여 다양한 배포 시나리오에 유연하게 대응하고 리소스 활용을 최적화할 수 있습니다:
  • NGINX App Protect WAF – OWASP Top 10을 비롯한 다양한 위협으로부터 보호하고 PCI DDS를 준수하는 강력하고 가벼운 WAF입니다.
  • NGINX App Protect DoS – 클라우드와 아키텍처 전반에서 일관되고 적응형인 보호 기능을 제공하는 행동 기반 DoS 탐지 및 완화 솔루션입니다.
• F5 NGINX Service Mesh – NGINX Plus를 엔터프라이즈 사이드카로 제공하는 경량의 즉시 사용 가능하며 개발자 친화적인 서비스 메시입니다.

지금 무료 30일 평가판을 신청하여 NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller를 시작하고, 항상 무료로 제공되는 NGINX Service Mesh를 다운로드하세요.

작성자 소개

Jenn GileNGINX 제품 마케팅 총괄

Jenn Gile의 다른 블로그 게시물