NGINX를 사용하여 Kubernetes 앱을 위한 Zero Trust 보안 설계

사이버보안 공격의 정교함과 수는 기하급수적으로 늘어나고 있으며, 이로 인해 온프레미스, 하이브리드, 멀티 클라우드 Kubernetes 환경에 배포된 앱이 노출될 위험이 상당히 커지고 있습니다. 기존 보안 모델은 경계 기반이며, 사용자가 환경의 보안 경계 내에 위치하는 경우 신뢰할 수 있고 사용자 간 통신이 안전하다고 가정합니다. 오늘날의 분산 환경에서 경계 내부의 안전 지대라는 개념은 더 이상 존재하지 않습니다. 환경 "내부"에서 시작되는 통신은 외부 위협만큼 위험할 수 있습니다.

이 블로그에서는 Kubernetes 인프라를 보호하기 위해 Zero Trust 모델을 도입하는 이점과 NGINX가 보안 태세를 개선하는 데 어떻게 도움이 될 수 있는지 알아봅니다.

제로 트러스트란 무엇인가요?

제로 트러스트 는 위치가 아닌 신원을 기반으로 하는 보안 모델입니다. 이는 요청자가 회사 내부, 원격지 또는 클라우드에 있는지 여부에 관계없이 애플리케이션, 데이터 및 장치에 대한 액세스 요청은 공격일 수 있다고 가정합니다.

Zero Trust의 세 가지 핵심 원칙인 '절대 신뢰하지 않기, 항상 확인하기, 지속적으로 모니터링하기'를 구현하기 위해 모든 사용자, 서비스, 애플리케이션 및 장치는 지속적으로 인증 및 승인 증명을 제시해야 합니다. 시간 제한이 있는 권한은 동적 액세스 정책과 최소 권한 기준에 따라 부여됩니다.

모든 통신은 암호화되고 모든 당사자를 인증하고 동적 액세스 정책에 따라 권한을 부여하는 정책 결정/시행 지점(PDP/PEP)을 통해 라우팅됩니다. 또한, 보안 위험을 분석, 평가하고 완화하기 위한 감사, 모니터링, 보고 및 자동화 기능이 갖춰져 있습니다.

Zero Trust가 보안 태세를 개선하는 방법

Zero Trust는 여러 가지 방법으로 보안 태세를 개선합니다.

• 승인되지 않은 활동을 자동으로 차단합니다
• 노출된 공격 표면을 줄이기 위해 액세스 제어를 시행합니다.
• 행동 이상 및 침해 지표 감지
• 액세스 시간을 제한하는 실시간 최소 권한 정책을 정의합니다.
• 진행 중인 공격을 차단하기 위해 지속적으로 신원을 인증하고 검증합니다.

Zero Trust는 Kubernetes 환경에서 실행되는 최신 클라우드 네이티브 앱에 특히 중요합니다. 느슨하게 결합되고 이식 가능한 분산 앱과 서비스는 컨테이너화되어 위치 기반 보안이 불가능한 하이브리드 멀티 클라우드 환경에서 실행됩니다. 보안은 필연적으로 신원 및 권한에 대한 지속적인 검증, 종단 간 암호화, 모니터링에 달려 있습니다.

제로 트러스트 보안을 달성하는 방법

Zero Trust 원칙을 충족하려면 Kubernetes 환경에서 사용자, 애플리케이션, 서비스에 대한 인증, 권한 부여, 액세스 제어, 정책, 암호화, 모니터링, 감사와 같은 중요한 보안 기능을 제공해야 합니다.

이를 달성할 수 있는 한 가지 방법은 앱 자체에 보안을 구축하는 것입니다. 하지만 이는 개발자가 신뢰 구축 및 검증, 사용자 신원 및 인증서 관리, 모든 통신 암호화 및 복호화 등 여러 보안 절차를 구현해야 한다는 것을 의미합니다. 또한 TLS 및 SSO(Single Sign‑On)와 같은 타사 기술을 이해하고 통합해야 합니다. 이 모든 것이 이미 복잡한 Kubernetes 배포를 더욱 복잡하게 만들 뿐만 아니라, 개발자는 앱의 비즈니스 기능을 최적화하는 데 집중해야 하는 것(그리고 원하는 것!)에서 주의가 산만해집니다.

당황하지 마세요. 더 나은 방법이 있습니다. 보안 및 기타 비기능적 요구 사항을 Kubernetes 인프라에 오프로드하세요! Ingress 컨트롤러 및 서비스 메시와 같은 Kubernetes 클러스터용 연결 도구는 사용자 또는 다른 앱이나 서비스에서 시작된 모든 앱과 서비스 간 통신에 대해 PDP 및 PEP를 제공할 수 있습니다. 즉, 앱을 더 빠르고 쉽게 제공하는 동시에 핵심 비즈니스 전문성과 기능에 집중할 수 있습니다.

F5 NGINX가 어떻게 도움이 될 수 있는지

아래 다이어그램에서 알 수 있듯이, 안전한 Kubernetes 연결을 위한 NGINX 솔루션에는 온프레미스, 하이브리드, 멀티 클라우드 등 모든 환경에서 대규모 및 종단 간 으로 사용자, 분산 애플리케이션, 마이크로서비스 및 API를 성공적으로 보호하는 데 필요한 모든 인프라 독립적인 구성 요소와 도구가 포함되어 있습니다. 세계에서 가장 인기 있는 데이터 플레인을 기반으로 하는 이 솔루션은 다음을 결합합니다.

• Kubernetes용 Ingress 컨트롤러이자 타사 ID 및 SSO 공급자와 통합되는 PDP/PEP인 NGINX Ingress Controller . NGINX Plus 기반의 NGINX Ingress Controller는 고급 연결, 모니터링 및 가시성, 인증 및 SSO를 처리하고 API 게이트웨이 역할을 합니다.
• 가볍고 턴키 방식의 개발자 친화적 서비스 메시인 NGINX Service Mesh는 Kubernetes 클러스터 내에서 서비스 연결을 보호합니다. 각 Kubernetes 서비스와 함께 배치되어 PDP/PEP 역할을 하는 엔터프라이즈급 사이드카는 NGINX Plus를 기반으로 합니다.
• F5의 시장을 선도하는 보안 기술을 기반으로 최신 앱과 API를 종합적으로 보호하는 NGINX App Protect입니다 . 배포 시나리오의 유연성과 최적의 리소스 활용을 위해 모듈식 접근 방식을 사용합니다.
  • NGINX App Protect WAF – OWASP Top 10을 보호하고 PCI DDS 규정 준수를 제공하는 강력하고 가벼운 WAF
  • NGINX App Protect DoS – 클라우드와 아키텍처 전반에 걸쳐 일관되고 적응적인 보호를 제공하는 동작형 DoS 탐지 및 완화

NGINX 솔루션을 사용하면 다음이 가능합니다.

• 릴리스 속도를 늦추거나 성능을 저하시키지 않고 분산 환경 전반에 강력한 보안 제어를 통합합니다.
• 지속적인 인증, 신원 검증, 동작 이상 감지를 통해 진행 중인 공격을 자동으로 차단합니다.
• 여러 팀에 걸쳐 실시간 최소 권한 정책, 세분화된 액세스 제어, 종단 간 암호화 및 거버넌스를 구현합니다.
• 통합적이고 강력한 WAF 및 앱 수준 DoS 방어 기능을 통해 코드에서 고객에게 앱을 안전하게 제공하세요.
• 세부적인 실시간 및 과거 지표를 통해 Kubernetes 환경의 보안 태세를 지속적으로 평가하고 개선합니다.
• 기술 통합을 통해 보안 사용자-서비스 및 서비스-서비스 간 통신의 배포 및 관리를 간소화합니다.

NGINX로 포괄적인 Zero Trust 보안 구현

조직이 확장됨에 따라 앱 기능에 특화되지 않은 요구 사항(예: Zero Trust 보안 기능)을 애플리케이션 계층에서 오프로드하는 것이 중요해집니다. 위에서 설명한 대로 이를 통해 개발자는 앱 전체에서 보안 논리를 구축, 유지 관리, 복제하는 부담으로부터 해방될 수 있습니다. 대신 플랫폼 수준에서 보안 기술을 쉽게 활용할 수 있습니다. NGINX는 NGINX Ingress Controller를 통해 클러스터 가장자리에서 Kubernetes에 대한 중앙 집중식 보안 정책 시행을 제공하고, NGINX Service Mesh를 통해 클러스터 내에서 Kubernetes에 대한 중앙 집중식 보안 정책 시행을 제공합니다. 앱 보안 요구 사항에 따라 에지 또는 클러스터 내에 NGINX App Protect WAF 및 DoS를 배포하여 정교한 사이버 공격으로부터 고급 애플리케이션 보호 기능을 추가할 수 있습니다.

Kubernetes 배포에 대한 포괄적인 Zero Trust 보안을 구현하는 데 필요한 기능이 NGINX 솔루션에 어떻게 포함되어 있는지 자세히 살펴보겠습니다.

인증 및 권한 부여

Zero Trust 보안의 핵심 원칙 중 하나는 모든 기기, 사용자, 서비스 및 요청이 인증되고 승인된다는 것입니다. 인증은 신원을 확인하는 프로세스입니다. 즉, 커뮤니케이션에 참여하는 각 당사자가 주장하는 바와 같은 신원인지 확인하는 프로세스입니다. 승인은 당사자가 요청한 리소스나 기능에 대한 액세스 권한이 있는지 확인하는 프로세스입니다.

이 원칙을 해결하기 위해 NGINX 솔루션은 HTTP 기본 인증 , JSON 웹 토큰(JWT) , Okta 및 Azure Active Directory(AD)와 같은 ID 공급자와 통합을 통한 OpenID Connect를 포함하여 인증 및 권한 부여를 구현하기 위한 여러 옵션을 제공합니다. NGINX 솔루션은 서비스에 안전한 ID를 발급합니다(애플리케이션 사용자에게 인증서 형태의 ID가 발급되는 것과 유사). 이를 통해 사용자는 인증을 받고 Kubernetes 클러스터 전체에서 작업을 수행할 수 있는 권한을 부여받을 수 있습니다. NGINX 솔루션은 워크로드 ID를 처리하는 것 외에도 공개 키 인프라(PKI) 및 인증 기관과의 기본 통합을 통해 인증서 관리를 자동화합니다.

NGINX Ingress Controller는 이미 클러스터에 들어오는 모든 요청을 면밀히 조사하여 적절한 서비스로 라우팅하기 때문에 중앙화된 사용자 인증 및 권한 부여, 일부 시나리오에서의 서비스 인증을 위한 가장 효율적인 위치입니다.

자세한 내용은 블로그에서 Okta와 NGINX Ingress Controller를 사용하여 Kubernetes에 대한 OpenID Connect 인증 구현을 읽어보세요.

데이터 암호화 및 무결성

또 다른 Zero Trust 원칙은 모든 커뮤니케이션은 보안되어야 하며, 참여자가 어디에 있든 기밀성과 무결성이 유지되어야 한다는 것입니다. 데이터는 허가받지 않은 타인에게 읽혀서는 안 되며 전송 중에 수정되어서도 안 됩니다. 이 원칙을 충족하기 위해 NGINX 솔루션은 사용자-서비스 통신에는 SSL/TLS 암호화를 사용하고, 서비스-서비스 통신에는 상호 TLS(mTLS) 인증 및 암호화를 사용합니다.

앱 아키텍처에 Kubernetes 클러스터 내의 서비스 간 통신이 포함되지 않은 경우 NGINX Ingress Controller만으로도 데이터 무결성 요구 사항을 충족할 수 있습니다. 두 가지 기본 옵션이 있습니다.

• TLS Passthrough를 사용하면 NGINX Ingress Controller는 SSL/TLS로 암호화된 연결을 해독하거나 SSL/TLS 인증서나 키에 대한 액세스를 요구하지 않고 서비스에 직접 라우팅합니다.
• SSL/TLS 종료를 사용하면 NGINX Ingress Controller가 역방향 프록시 역할을 하여 요청자와의 TLS 연결을 종료한 다음 mTLS 또는 서비스 측 SSL/TLS를 사용하여 Kubernetes 서비스(백엔드 및 업스트림 서버)에 대한 새로운 연결을 암호화합니다.

클러스터 내에서 서비스 간 통신이 아키텍처에 포함되는 경우 데이터 무결성을 위해 NGINX Ingress Controller와 NGINX Service Mesh가 모두 필요합니다. NGINX 서비스 메시는 특정 서비스만 서로 통신하도록 허용하고 mTLS를 사용하여 서비스를 인증하고 서비스 간 통신을 암호화합니다. NGINX Service Mesh를 사용하면 "제로터치" 방식으로 mTLS를 구현할 수 있습니다. 즉, 개발자는 애플리케이션에 인증서를 추가로 적용할 필요가 없고 상호 인증이 수행되고 있다는 사실도 알 필요가 없습니다.

Kubernetes 클러스터에서 통신을 보호하는 방법에 대한 자세한 내용은 블로그의 NGINX 서비스 메시의 mTLS 아키텍처를 참조하세요.

접근 제어 및 접근 정책

액세스 제어는 Zero Trust 모델의 또 다른 중요한 요소입니다. 쿠버네티스는 역할 기반 액세스 제어(RBAC)를 사용하여 다양한 사용자가 사용할 수 있는 리소스와 작업을 규제합니다. 이는 사용자 또는 사용자 그룹이 클러스터 내의 Kubernetes 객체나 네임스페이스와 상호작용하는 방식을 결정합니다.

NGINX Kubernetes 연결 솔루션은 조직의 보안 정책에 쉽게 맞출 수 있도록 RBAC를 지원합니다. RBAC를 도입하면 사용자는 IT 티켓을 제출하고 처리가 완료될 때까지 기다리지 않고도 업무에 필요한 기능에 대한 접근 권한을 얻게 됩니다. RBAC가 없으면 사용자는 필요하지 않거나 권한이 없는 권한을 얻을 수 있으며, 권한이 오용되면 취약점이 발생할 수 있습니다.

NGINX Ingress Controller로 RBAC를 구성하면 조직의 애플리케이션 개발 및 제공 환경에서 다양한 역할에 맞게 권한을 조정하여 여러 사람과 팀의 액세스를 제어할 수 있습니다. 세분화된 액세스 관리 도구를 통해 여러 팀에서 셀프 서비스와 거버넌스를 구현할 수 있습니다.

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

관찰 가능성

감사, 모니터링, 로깅, 추적 및 보고는 Zero Trust 환경의 핵심 요소입니다. Kubernetes 애플리케이션 인프라의 상태에 대해 수집할 수 있는 정보가 많을수록, 그리고 보다 효과적으로 이를 연관시키고, 분석하고, 평가할수록 보안 태세를 더욱 강화할 수 있습니다.

아마도 여러분은 이미 Kubernetes 배포 환경에서 모니터링 도구를 사용하고 있을 것이고, 또 다른 도구는 필요하지 않을 것입니다. 클러스터 내부에서 무슨 일이 일어나고 있는지 전체적으로 파악할 수 있도록 NGINX Plus API를 구축하여 JSON을 허용하고 OpenTelemetry , Grafana, Prometheus 와 같은 널리 사용되는 도구와 미리 통합된 모든 타사 도구로 메트릭을 쉽게 내보낼 수 있도록 했습니다. 심층 추적을 통해 앱 연결에 대한 타겟팅된 통찰력을 얻을 수 있으므로 요청이 종단 간에 어떻게 처리되는지 이해할 수 있습니다. NGINX Ingress Controller는 클러스터와 외부 클라이언트 간의 연결에 대한 통찰력을 제공하는 반면, NGINX Service Mesh는 클러스터 내의 컨테이너화된 마이크로서비스 기반 앱과 서비스 간의 연결을 처리합니다.

WAF 및 DoS 보호

NGINX App Protect를 사용하면 OWASP Top 10 및 Layer 7 서비스 거부(DoS) 공격과 같은 위협으로부터 분산 애플리케이션을 보호하여 보안을 더욱 강화할 수 있습니다. 엔드투엔드 NGINX 보안 연결 솔루션의 필수 구성 요소인 NGINX App Protect는 기본적인 시그니처를 훨씬 뛰어넘어 가장 진보된 위협으로부터 민첩하고 앱 중심의 보안을 제공합니다. F5의 선도적이고 신뢰할 수 있는 보안 전문성을 활용하며, 릴리스 속도와 성능에 영향을 주지 않습니다. 이 솔루션을 사용하면 보안 원격 측정 데이터를 타사 분석 및 가시성 솔루션으로 쉽게 전달할 수 있으며, 신뢰도 높은 서명 및 자동화된 동작 분석을 통해 거짓 긍정률을 줄일 수 있습니다.

NGINX App Protect의 모듈형 디자인은 필요에 따라 동일하거나 다른 인스턴스에 WAF와 DoS 보호 중 하나 또는 둘 다를 배포할 수 있음을 의미합니다. 예를 들어, 클러스터 가장자리에 NGINX Ingress Controller를 배포하기로 결정할 수 있습니다. 이는 단일 클러스터 전체에서 일관된 세분화된 보호를 제공하는 데 이상적입니다. 대신 클러스터 내 여러 앱에 대한 앱별 정책이 필요한 경우 서비스 또는 Pod 수준에서 WAF 및/또는 DoS 보호 기능을 배포할 수 있습니다.

WAF와 DoS 보호 기능을 구축하는 방법에 대한 자세한 내용은 블로그에서 보다 안전한 앱을 위해 보안 도구 전환을 읽어보세요.

Kubernetes를 위한 NGINX Zero Trust 보안 솔루션 시작하기

Kubernetes 여정의 시작에 있는 사용자이든 오랫동안 Kubernetes를 운영 환경에서 사용해 온 고급 사용자이든, NGINX는 모든 사용자의 요구 사항을 충족하고 보안 태세를 개선하는 데 필요한 포괄적인 도구와 빌딩 블록 세트를 제공합니다.

NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller의 무료 30일 체험판을 요청하고, 항상 무료인 NGINX Service Mesh를 다운로드하여 시작하세요.