Skip to main content
ONTAP Technical Reports
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

사용 사례 및 작업 부하

NFS over TLS는 세 가지 일반적인 배포 시나리오에 적합합니다: Kerberos 인프라 없이 네트워크를 통한 암호화, 공유 내보내기에 대한 클라이언트별 TLS 적용, 그리고 상호 클라이언트 인증.

모든 워크로드가 똑같이 이점을 얻는 것은 아닙니다. 적합한 패턴과 그렇지 않은 패턴을 파악하면 배포 계획을 세우는 데 도움이 됩니다.

사용 사례

Kerberos 인프라 없이 전송 중인 NFS 암호화. NFS 데이터 전송 암호화가 필요하지만 키 배포 센터(KDC)를 구축 및 운영하거나, 클라이언트에 키탭을 배포하거나, NAS 클라이언트를 포괄하도록 Kerberos 영역을 확장하고 싶지 않다면, NFS over TLS가 이 문제를 직접 해결해 줍니다. 스토리지 가상 머신(SVM)별로 서버 인증서를 설치하고, 암호화된 NFS 데이터를 전송해야 하는 각 데이터 논리 인터페이스(LIF)에서 NFS over TLS를 활성화하면 클라이언트는 표준 NFS 포트에서 TLS 1.3 인밴드 협상을 수행합니다. 새로운 인증 서비스는 필요하지 않습니다.

공유 NFS 내보내기에 대한 클라이언트별 TLS 전용 강제 적용. 암호화가 필요한 클라이언트와 암호화가 필요하지 않은 클라이언트가 혼재하는 경우, 다른 클라이언트에는 영향을 주지 않고 규제 대상 클라이언트가 암호화된 경로를 사용하도록 강제하는 방법이 필요합니다. 내보내기 정책 규칙 옵션 `-allow-nfs-tls-only true`이 바로 이러한 기능을 제공합니다. 다른 내보내기 정책 규칙은 그대로 유지하면서, 일치하는 클라이언트의 TCP를 통한 비TLS 마운트를 차단합니다.

스토리지-클라이언트 신뢰를 위한 상호 클라이언트 인증(mTLS). 제로 트러스트 네트워킹 원칙을 준수하거나 스토리지 컨트롤러가 연결하는 모든 클라이언트의 호스트 ID를 확인해야 하는 보안 강화 요구 사항이 있는 경우, LIF별 상호 TLS 옵션을 사용하십시오. Set -enforce-host-auth true on vserver nfs tls interface enable 또는 `vserver nfs tls interface modify`으로 설정하십시오. 그러면 ONTAP은 TLS 핸드셰이크 시점에 각 연결 클라이언트의 X.509 인증서를 SVM에 설치된 인증 기관(CA) 신뢰 체인에 대해 검증하고, 신뢰할 수 있는 인증서를 제시하지 않는 클라이언트를 거부합니다. 이를 통해 "내 등록된 호스트 플릿만 이 NFS LIF에 접근할 수 있음"이라는 암호화 적용을 실현할 수 있으며, 기존 내보내기 정책 호스트 필터에 추가하여 작동합니다.

워크로드

암호화는 무료가 아닙니다. TLS 핸드셰이크에는 측정 가능한 비용이 발생하며, TLS 레코드 암호화는 모든 RPC에 오버헤드를 추가합니다. 성능 영향은 작업 부하, 플랫폼, 하드웨어 오프로드 가능 여부에 따라 크게 달라집니다. 자세한 내용은 "성능"을 참조하십시오.

워크로드 패턴

클라이언트 수가 안정적이고 장기간 유지되는 NFS 마운트는 매우 적합합니다. TLS 핸드셰이크는 마운트 시점과 세션 재설정 시점에 발생하는 연결당 비용입니다. 클라이언트 수가 적고 안정적이며 한 번 마운트된 후 몇 시간 또는 며칠 동안 마운트 상태를 유지하는 경우, 이 비용은 충분히 감당할 수 있습니다.

이미 DNS 레코드를 통해 LIF와 호스트 이름 매핑을 깔끔하게 관리하고 있다면 NFS over TLS를 쉽게 프로비저닝할 수 있습니다. 이 기능은 LIF별로 구성되며, LIF의 정규화된 도메인 이름(FQDN)과 일치하는 일반 이름(CN)을 가진 서버 인증서를 설치하고, 해당 인증서의 주체 대체 이름(SAN) 목록에 LIF의 IP 주소가 포함되어야 합니다.

NFS over TLS는 전송 중 기밀성, 서버 ID, 그리고 선택적으로 클라이언트 호스트 ID가 보안 요구 사항일 때 적합한 도구입니다. 이는 TLS가 제공하는 속성과 정확히 일치합니다.

워크로드 안티 패턴

연결 끊김이 잦거나 마운트 요청이 폭증하는 상황은 이 방식에 적합하지 않습니다. 모든 새로운 TLS 연결에는 비대칭 암호화, 인증서 유효성 검사, 그리고 선택적인 mTLS 체인 유효성 검사를 포함한 TLS 1.3 핸드셰이크 비용이 발생합니다. 만약 많은 클라이언트가 마운트 후 간단한 작업을 수행하고 마운트를 해제한 다음 다시 연결하는 과정을 반복한다면, 이 핸드셰이크 비용을 분산해서 지불하는 대신 계속해서 지불하게 됩니다.