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

편집자 - 이 게시물은 10부작 시리즈의 일부입니다.

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

또한 전체 블로그 세트를 무료 전자책인 ' 테스트에서 프로덕션까지 Kubernetes 활용' 으로 다운로드할 수 있습니다.

속도 저하 없이 클라우드 네이티브 앱 보안 에서 논의한 대로, 우리는 클라우드 네이티브 앱을 기존 앱보다 보안하기 어렵게 만드는 세 가지 요소를 관찰했습니다.

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에 대한 훌륭한 소개 내용을 보려면 F5 Labs에서 mTLS란 무엇인가?를 참조하세요.

• Single Sign‑On(SSO) – SSO 기술(SAML, OAuth, OIDC 포함)을 사용하면 인증 및 권한 부여를 보다 쉽게 관리할 수 있습니다.

  • 간소화된 인증 – SSO를 사용하면 사용자가 서로 다른 리소스나 기능마다 고유한 ID 토큰을 가질 필요가 없습니다.

  • 표준화된 권한 부여 – SSO를 사용하면 역할, 부서 및 근속 기간에 따라 사용자 액세스 권한을 설정할 수 있으므로 각 사용자에 대한 권한을 개별적으로 구성할 필요가 없습니다.

• SSL(Secure Sockets Layer)/TLS(Transport Layer Security) – 네트워크로 연결된 컴퓨터 간에 인증되고 암호화된 링크를 설정하기 위한 프로토콜입니다. SSL/TLS 인증서는 웹사이트의 신원을 인증하고 암호화된 연결을 설정합니다. SSL 프로토콜은 1999년에 더 이상 사용되지 않고 TLS 프로토콜로 대체되었지만, 이러한 관련 기술을 여전히 "SSL" 또는 "SSL/TLS"라고 부르는 것이 일반적입니다. 일관성을 위해 이 게시물의 나머지 부분에서는 SSL/TLS를 사용하겠습니다.

• 웹 애플리케이션 방화벽(WAF) – 앱 및 API에 대한 정교한 공격( OWASP Top 10 및 기타 고급 위협 포함)을 탐지하고 차단하는 동시에 "안전한" 트래픽은 통과시키는 역방향 프록시입니다 . WAF는 민감한 데이터를 훔치거나 시스템을 하이재킹하는 등 타겟에 해를 끼치려는 공격으로부터 방어합니다. 일부 공급업체는 동일한 도구에 WAF와 DoS 보호 기능을 통합하지만, 다른 공급업체는 WAF와 DoS 도구를 별도로 제공합니다.

• 제로 트러스트(Zero trust) – 높은 수준의 보안을 제공하는 조직에서 자주 사용되는 보안 개념이지만 모든 사람에게 해당되며, 데이터는 저장 및 전송의 모든 단계에서 보안되어야 합니다. 이는 조직이 기본적으로 어떠한 사용자나 장치도 "신뢰"하지 않기로 결정했지만 모든 트래픽을 철저히 검토하도록 요구한다는 것을 의미합니다. 제로 트러스트 아키텍처에는 일반적으로 인증, 권한 부여 및 mTLS가 결합되어 있으며 조직에서 E2EE를 구현할 가능성이 높습니다.

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

해결책: 시기적절하고 사전 예방적인 패치 알림이 가능한 도구 사용

Ponemon Institute의 연구 에 따르면, 2019년에 중요하거나 우선순위가 높은 취약성에 대한 패치가 릴리스된 후 조직에서 해당 취약성을 악용하려는 공격이 발생하는 데까지 평균 43일의 "유예 기간"이 있었습니다. F5 NGINX에서는 그 기간이 이후 몇 년 동안 상당히 좁아지는 것을 보았습니다( 2021년 Apple iOS 15의 경우 Day Zero 까지 좁아짐). 따라서 가능한 한 빨리 패치를 적용할 것을 권장합니다. 하지만 CVE가 발표된 후 몇 주 또는 몇 달이 지나도 트래픽 관리 도구에 대한 패치가 제공되지 않는다면 어떻게 해야 할까요?

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

가장 빠른 CVE 패치를 받으려면 트래픽 관리 도구를 선택할 때 두 가지 특징을 살펴보세요.

• 전담 엔지니어링 팀 – 커뮤니티 자원봉사자가 아닌 엔지니어링 팀이 도구 개발을 관리하는 경우 도구의 상태를 유지하고 가능한 한 빨리 패치 릴리스를 우선 순위로 지정할 수 있는 사람들의 그룹이 있다는 것을 알 수 있습니다.
• 통합된 코드 기반 – 외부 종속성 없이(OpenResty에서 논의한 것과 같이) 패치는 민첩한 스프린트만큼 떨어져 있습니다.

CVE 패치에 대한 자세한 내용은 NGINX Plus를 사용하여 빠르고 쉽게 보안 취약점 완화를 읽어보세요.

사용 사례: OWASP Top 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 와 같은 Ingress 컨트롤러 에서) – 단일 클러스터에서 표준인 "세분화된" 보호를 제공하는 데 이상적입니다.
• 서비스에서 (NGINX Plus와 같은 경량 로드 밸런서에서) – 클러스터 내에 고유한 정책에 대한 공유 요구 사항이 있는 소수의 서비스가 있는 경우 필요한 접근 방식이 될 수 있습니다.
• 포드에서 (애플리케이션의 일부로서) – 정책이 앱에 특화되어 있는 경우 사용될 수 있는 매우 사용자 지정적인 접근 방식

그렇다면 네 가지 옵션 중에서 어떤 것이 가장 좋을까요? 글쎄요... 상황에 따라 다르죠!

WAF를 배포할 위치

먼저, WAF 배포 옵션을 살펴보겠습니다. 이는 보다 미묘한 선택이기 때문입니다.

• 프런트 도어 및 엣지 - 조직에서 "심층 방어" 보안 전략을 선호하는 경우 글로벌 및 사용자 지정 보호의 효율적인 균형을 제공하기 위해 외부 로드 밸런서와 Ingress 컨트롤러 모두에 WAF를 배포하는 것이 좋습니다.
• 정문 또는 가장자리 - "심층 방어" 전략이 없는 경우 단일 위치가 허용되며 배치 위치는 소유권에 따라 달라집니다. 기존 NetOps 팀이 보안을 담당하는 경우 기존 프록시(외부 로드 밸런서)에서 보안을 관리하는 것이 더 편안할 수 있습니다. 그러나 Kubernetes를 편안하게 사용하고 클러스터 구성 근처에서 보안 구성을 선호하는 DevSecOps 팀은 수신 수준에서 WAF를 배포하도록 선택할 수 있습니다.
• 서비스 또는 포드당 - 팀에 서비스나 앱에 대한 특정 요구 사항이 있는 경우, 별도로 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 인증 구현을 참조하세요.

사용 사례: 가드레일로 셀프 서비스 설정

해결책: 역할 기반 액세스 제어(RBAC) 구현

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

Kubernetes RBAC는 기본적으로 활성화되어 있지만 Kubernetes 트래픽 관리 도구도 RBAC를 지원하고 조직의 보안 요구 사항에 부합하는지 확인해야 합니다. RBAC를 도입하면 사용자는 티켓이 처리될 때까지 기다리지 않고도 업무에 필요한 기능에 대한 접근 권한을 얻게 됩니다. 하지만 RBAC를 구성하지 않으면 사용자는 필요하지 않거나 권한이 없는 권한을 얻을 수 있으며, 권한이 오용되면 취약점이 발생할 수 있습니다.

Ingress 컨트롤러는 RBAC로 구성될 때 수많은 사람과 팀에 서비스를 제공할 수 있는 도구의 대표적인 예입니다. Ingress 컨트롤러가 단일 네임스페이스까지 세분화된 액세스 관리를 허용하는 경우 RBAC를 사용하여 멀티 테넌시를 통해 리소스를 효율적으로 사용할 수 있습니다.

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

• NetOps 팀 – 애플리케이션의 외부 진입점(호스트 이름 및 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 Controller 및 서비스 메시를 사용하는 E2EE

클러스터 내에 서비스 간 통신이 있는 경우 Ingress 컨트롤러를 통한 유입-유출 트래픽 과 서비스 메시를 통한 서비스 간 트래픽의 두 가지 평면에서 E2EE를 구현해야 합니다. E2EE에서 서비스 메시의 역할은 특정 서비스만 서로 통신할 수 있도록 하고, 이를 안전한 방식으로 수행하는 것입니다. E2EE에 대한 서비스 메시를 설정하는 경우 두 가지 요소를 통해 제로 트러스트 환경을 활성화해야 합니다. 서비스 간 mTLS(인증서가 필요하도록 설정)와 서비스 간 트래픽 액세스 제어(어떤 서비스가 통신이 허가되었는지 지정)입니다. 이상적으로는 Kubernetes 클러스터 전체에서 진정한 E2EE 보안을 구현하기 위해 서비스 메시와 인그레스-이그레스 컨트롤러가 관리하는 애플리케이션 간에도 mTLS를 구현합니다.

전송 중에 노출된 데이터를 암호화하는 방법에 대한 자세한 내용은 NGINX 서비스 메시의 mTLS 아키텍처를 참조하세요.

사용 사례: 신뢰할 수 있는 구현을 통해 클라이언트가 강력한 암호를 사용하고 있는지 확인하십시오.

해결책: 연방 정보 처리 표준(FIPS) 준수

소프트웨어 산업에서 FIPS는 일반적으로 암호화에 대한 구체적인 간행물인 암호화 모듈에 대한 FIPS PUB 140-2 보안 요구 사항을 의미하며, 이는 미국과 캐나다의 공동 작업입니다. 이는 양국의 연방 기관에서 민감한 정보를 보호하기 위해 수용하는 암호화 모듈의 테스트와 인증을 표준화합니다. "하지만 잠깐만요!" 당신은 말합니다. "저는 북미 정부 기관과 일하지 않기 때문에 FIPS에 관심이 없습니다." FIPS 규정을 준수하는 것은 업계나 지역에 관계없이 현명한 선택이 될 수 있습니다. FIPS는 사실상 글로벌 암호화 기준이기 때문입니다.

FIPS를 준수하는 것은 어렵지 않지만 운영 체제와 관련 트래픽 관리 도구가 모두 FIPS 모드에서 작동할 수 있어야 합니다. FIPS 규정 준수는 단순히 FIPS 모드에서 운영 체제를 실행함으로써 달성된다는 일반적인 오해가 있습니다. FIPS 모드의 운영 체제를 사용하더라도 Ingress 컨트롤러와 통신하는 클라이언트가 강력한 암호를 사용하지 않을 가능성이 있습니다. FIPS 모드에서 작동하는 경우 운영 체제와 Ingress 컨트롤러는 일반적인 SSL/TLS 암호의 하위 집합만 사용할 수 있습니다.

Kubernetes 배포를 위한 FIPS 설정은 4단계 프로세스입니다.

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

아래 예에서 NGINX Plus에서 사용하는 운영 체제와 OpenSSL 구현 모두에 FIPS 모드가 활성화된 경우, NGINX Plus에서 주고받는 모든 최종 사용자 트래픽은 검증된 FIPS 지원 암호화 엔진을 사용하여 복호화되고 암호화됩니다.

NGINX Plus를 통한 FIPS 규정 준수 달성 에서 FIPS에 대해 자세히 알아보세요.

NGINX로 Kubernetes를 보다 안전하게 만들기

이러한 보안 방법 중 일부(또는 전체)를 구현할 준비가 되었다면 도구에 사용 사례를 지원하는 데 적합한 기능과 역량이 있는지 확인해야 합니다. NGINX는 프로덕션에 적합한 Kubernetes 트래픽 관리 도구 모음을 통해 도움을 줄 수 있습니다.

• NGINX Ingress Controller – Kubernetes 용 NGINX Plus 기반 Ingress 컨트롤러로, 고급 트래픽 제어 및 셰이핑, 모니터링 및 가시성, 인증 및 SSO를 처리하고 API 게이트웨이 역할을 합니다.

• F5 NGINX App Protect – F5의 시장을 선도하는 보안 기술을 기반으로 구축된 최신 앱과 API에 대한 종합적 보호로, NGINX Ingress Controller와 NGINX Plus와 통합됩니다. 배포 시나리오의 유연성과 최적의 리소스 활용을 위해 모듈식 접근 방식을 사용하세요.

  • NGINX App Protect WAF – PCI DDS 규정을 준수하면서 OWASP Top 10 이상을 보호하는 강력하고 가벼운 WAF입니다.

  • NGINX App Protect DoS – 클라우드와 아키텍처 전반에서 일관되고 적응적인 보호를 통해 동작 기반 DoS를 감지하고 완화합니다.

• F5 NGINX 서비스 메시 – 가볍고, 턴키 방식이며, 개발자 친화적인 서비스 메시로, 엔터프라이즈 사이드카로 NGINX Plus를 제공합니다.

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