데이터 보안 보장

Mendix Private Cloud의 경우 TLS를 여러 가지 방법으로 구현하여 데이터 보안을 보장합니다.

• “인그레스 TLS” – 웹 브라우저(또는 다른 HTTP 클라이언트)와 다음 간의 트래픽을 암호화하는 데 사용됩니다. Mendix 실행 시간.
• “클라이언트 TLS” – 클라이언트 인증서(런타임에서 구성할 수 있음)는 원격 서버에서 클라이언트의 ID를 확인하는 데 사용됩니다. Mendix 런타임. 동시에, Mendix 런타임은 원격 서버에서 제시한 인증서를 사용하여 해당 서버의 신원을 검증합니다.
• “TLS 신뢰” – 데이터베이스, 파일 저장소 또는 레지스트리에 연결할 때 개인 루트 CA를 신뢰하는 데 사용됩니다. 신뢰할 수 있는 루트 인증서는 원격 서버의 진위성을 검증하고 다른 외부 서비스에 연결하는 동안에도 사용됩니다(예: 내부에서 사용되는 REST 또는 SOAP 서비스). Mendix 앱).

그렇다면 Service Mesh는 왜 필요한 걸까요? 사실, Service Mesh는 무엇일까요? 안전한 커뮤니케이션의 기초를 이해하는 것으로 시작해 보겠습니다.

TLS란 무엇인가요?

TLS (전송 계층 보안)은 데이터 암호화, 신원 확인, 데이터 무결성 유지를 통해 잠재적으로 신뢰할 수 없는 네트워크에서 두 장치 간의 안전한 통신을 보장하는 암호화 프로토콜입니다.

주요 구성 요소는 다음과 같습니다.

• 공개 키와 개인 키라고 하는 두 가지 키.
• 두 키 모두 만료 기간이 설정되어 있습니다.
• 공개 키로 암호화된 데이터는 개인 키로만 해독할 수 있습니다.
• 개인 키로 암호화된 데이터는 공개 키로만 해독할 수 있습니다.

TLS는 어떻게 작동하나요?

간단히 말해서, 서버에는 TLS 인증서와 키 쌍도 있습니다. 그런 다음 프로세스는 다음과 같습니다.

1. 클라이언트가 서버에 연결합니다.
2. 서버가 TLS 인증서를 보냅니다.
3. 클라이언트는 서버의 인증서(TLS 핸드셰이크)를 검증합니다.
4. 클라이언트와 서버는 암호화된 TLS 연결을 통해 정보를 교환합니다.

여기서 핵심은 TLS에서 클라이언트만 서버의 신원을 확인한다는 것을 이해하는 것입니다.

그럼 mTLS는 무엇일까요?

상호 전송 수준 보안(mTLS)은 TLS 위에 구축됩니다. 프로세스는 매우 유사하지만 클라이언트가 자체 인증서와 키 쌍을 그림에 추가한다는 점이 다릅니다. 즉, 클라이언트와 서버는 서로의 신원을 확인합니다.

mTLS의 작동 방식은 다음과 같습니다.

1. 클라이언트가 서버에 연결합니다.
2. 서버가 TLS 인증서를 보냅니다.
3. 클라이언트는 서버의 인증서(TLS 핸드셰이크)를 검증합니다.
4. 클라이언트가 TLS 인증서를 보냅니다.
5. 서버는 클라이언트의 인증서를 검증합니다(TLS 핸드셰이크).
6. 그런 다음 보안 채널을 통해 연결이 설정됩니다.

그렇다면 서비스 메시는 무엇일까요?

서비스 메시는 마이크로서비스 아키텍처 내에서 작동하는 네트워킹 인프라입니다. 주요 목표는 이러한 서비스 간에 데이터가 이동할 때 보안을 강화하고 암호화를 관리하는 것입니다.

이 게시물의 목적을 위해 서비스 메시가 제공할 수 있는 많은 기능 중 세 가지에만 초점을 맞추겠습니다.

• 서비스 간 암호화: 서비스 메시는 TLS와 mTLS를 사용하여 이러한 서비스 간 통신을 암호화하고 인증합니다.
• 인증서 관리: 서비스 메시는 인증서 발급, 순환, 배포를 자동화하여 TLS 인증서 관리를 간소화합니다.
• 제로 트러스트 네트워킹: 서비스 메시는 종종 "제로 트러스트" 접근 방식을 채택하는데, 이는 서비스 간 통신이 기본적으로 신뢰되지 않는다는 것을 의미합니다. TLS와 mTLS는 이 접근 방식에서 중요한 역할을 하는데, 신뢰할 수 있는 네트워크 내에서도 통신 당사자의 신원을 확인하고 데이터를 암호화하기 때문입니다.

서비스 메시 Mendix 프라이빗 클라우드를 위해

이 데모에서는 AWS EKS용 공식 Terraform 배포 모듈 Kubernetes 클러스터를 프로비저닝하는 데 사용되었습니다. 결과적으로 구성된 인프라는 처음부터 다음과 같은 주요 기능을 제공합니다.

• A Mendix "mendix"라는 네임스페이스 내에서 구성된 Operator 및 Agent.
• TLS(보안 연결)가 설정되었습니다. Mendix 데이터베이스, 저장소, 레지스트리와 같은 애플리케이션 및 필수 구성 요소입니다.
• 로드 밸런서와 사이에 설정된 보안 연결 Mendix 워크로드.

따라서 여기서의 목표는 서비스 메시를 활성화하여 Zero Trust Networking을 보장하는 것입니다. 모든 포드는 상호 TLS를 통해 보안된 방식으로 모든 내부 Kubernetes 서비스와 통신합니다.

다른 게 있나요? 네, Pod로 라우팅되는 모든 외부 트래픽을 보호하기 위해 Ingress 컨트롤러를 "메시"에 포함시킬 겁니다.

흥미로울 것 같나요?

혹시 혼란스러울까요?

아마도 몇 개의 다이어그램이 도움이 될 것입니다.

우리는 지금 여기에 있습니다…

참고 : Mendix 에이전트 및 개발자 포털은 연결 모드에만 적용됩니다.

…그리고 이것이 우리가 원하는 최종 상태입니다.

버전 2.5부터 Mendix Operator는 Connected와 Standalone 제품 모두에서 Istio 및 Linkerd와 호환됩니다.

간단하게 설명하기 위해 Linkerd만 살펴보고 활성화하겠지만 Istio의 경우도 프로세스가 매우 비슷합니다.

Linkerd 설치

에 따라 공식 문서 설치하기 위해서:

• Linkerd CLI는 운영 체제에 따라 다릅니다.
• Linkerd CRD
• Linkerd 확장 프로그램(viz 및 대시보드는 모두 강력히 권장됨)

Mendix Private Cloud 메시 주입을 위해

꽤 멋진 기능 Mendix 프라이빗 클라우드의 경우 메시 "주입"을 환경별로 활성화할 수 있고(빠른 검증 테스트나 격리에 적합) 전체 네임스페이스에 대해 활성화할 수도 있습니다.

Linkerd를 활성화하는 방법에 대한 빠른 참조는 아래 이미지를 참조하세요. 그러나 공식 문서를 확인하세요. 광범위한 연결 독립형 자세한 내용은.

한 환경에 Linkerd 활성화

첫째, Linkerd 주석은 terrapp1이라는 애플리케이션에 대해 개발자 포털에서 직접 활성화됩니다.

보시다시피, 활성화하고 변경 사항을 적용하면 Mendix Pod가 다시 시작되고 Linkerd 대시보드가 ​​주석을 감지하고 Pod를 메시된 것으로 표시합니다.

좋습니다. 이제 첫 번째 앱이 Linkerd에 성공적으로 추가되었고 mTLS가 이미 작동 중입니다.

전체 네임스페이스에 대해 Linkerd 활성화

다음 단계로 넘어가서 전체를 추가해 보겠습니다. Mendix 메시에 네임스페이스를 추가하여 Operator, Agent 및 애플리케이션 간의 연결을 보호합니다!

아래 영상에서 보듯이, 우리는 다음을 수행해야 합니다:

1. Linkerd 주입을 위해 전체 네임스페이스(이름 "mendix")에 주석을 달았습니다.
2. 구성을 살펴보고 주석이 네임스페이스에 추가되었는지 확인하세요.

참고: Pod가 메시에 자동으로 추가되지 않으면 각 배포를 축소하거나 확장하는 것이 좋습니다.

• • kubectl scale 배포 mendix-operator —replicas=0
  • kubectl scale 배포 mendix-agent —replicas=0
  • 위의 내용을 반복하여 replicas=1을 추가합니다.

와후! 이제 제로 트러스트 네트워킹 목표에 가까워지고 있습니다. Developer Portal에서 새 애플리케이션을 배포하고 Mesh에 자동으로 추가되는 방식을 살펴보겠습니다!

메시에 NGINX 인그레스 추가

대부분의 고객 설정에서 TLS 종료 Kubernetes 클러스터 내에 있는 인그레스 컨트롤러에서 구성됩니다. 간단히 말해서, 이는 외부 인바운드 트래픽이 암호화된(TLS) 인그레스 서비스에 도착하고, 암호화되지 않은(일반 http) Pod에 제공된다는 것을 의미합니다.

여기서 마지막 단계는 인그레스 컨트롤러와 해당 서비스 내의 모든 서비스 간에 mTLS를 보장하는 것입니다. Mendix 네임스페이스. 그러기 위해서는 다음이 필요합니다.

• 메시에 NGINX 인그레스 컨트롤러 배포를 추가합니다. 지시를 따르다 클러스터에 NGINX를 어떻게 설치했는지(helm 또는 YAML)에 따라 달라집니다.
• 꼭 추가하세요 thenginx.ingress.kubernetes.io/service-upstream 컨트롤러가 Pod 엔드포인트를 사용하지 않고 대신 서비스의 클러스터 IP 및 포트를 사용하도록 하려면 주석을 적절히 추가해야 합니다.

이제 Nginx가 메시에 추가되면 모든 포드 트래픽이 mTLS를 사용하는지 확인할 시간입니다.

NGINX는 메시되어 안전하게 트래픽을 전송합니다. Mendix 어플리케이션

맺음말

견고한 서비스 메시 아키텍처의 중요성은 지나치게 강조할 수 없으며, 마이크로서비스 환경 내에서 세분화된 가시성, 안전한 통신, 정책 시행을 제공하는 기능은 데이터와 시스템을 보호하는 데 가장 중요합니다.

활용 Mendix Private Cloud와 Istio 및 Linkerd의 원활한 통합을 통해 조직은 민첩성과 보안을 조화롭게 조화시킬 수 있습니다. Mendix의 신속한 개발 기능은 서비스 메시의 엄격한 보안 조치를 보완하여 기업이 방어 태세를 약화시키지 않고 혁신할 수 있도록 지원합니다.

끊임없이 진화하는 위협의 시대에 서비스 메시와 Mendix 프라이빗 클라우드는 정보 보안에 대한 미래 지향적인 접근 방식을 보여줍니다.

즐거운 메싱 되세요!