Azure NetApp Files의 데이터 암호화 이해
Azure NetApp Files는 다음 두 가지 방법을 통해 데이터를 암호화합니다.
- 미사용 데이터 암호화: 데이터가 FIPS 140-2 준수 표준을 사용하여 현재 위치에서 암호화됩니다.
- 전송 중 암호화: 데이터가 클라이언트와 서버 간에 전송될 때 유선을 통해 암호화됩니다.
미사용 암호화 이해
Azure NetApp Files의 미사용 데이터는 다음 두 가지 방법으로 암호화할 수 있습니다.
- 단일 암호화는 Azure NetApp Files 볼륨에 소프트웨어 기반 암호화를 사용합니다.
- 이중 암호화는 물리적 스토리지 디바이스 계층에 하드웨어 수준 암호화를 추가합니다.
Azure NetApp Files는 표준 CryptoMod를 사용하여 AES-256 암호화 키를 생성합니다. CryptoMod는 CMVP FIPS 140-2 검증 모듈 목록에 나열됩니다. 자세한 내용은 FIPS 140-2 Cert #4144를 참조하세요. 암호화 키는 볼륨과 연결되며 Microsoft 플랫폼 관리형 키 또는 고객 관리형 키일 수 있습니다.
전송 중 데이터 암호화 이해
Azure NetApp Files는 미사용 데이터를 보호하는 것 외에도 엔드포인트 간에 전송 중일 때 데이터를 보호할 수 있습니다. 사용되는 암호화 방법은 프로토콜 또는 기능에 따라 달라집니다. DNS는 Azure NetApp 파일에서 전송 중 암호화되지 않습니다. Azure NetApp Files의 SMB 및 NFS 암호화, LDAP, 데이터 복제에 대해 알아보려면 계속해서 읽어보세요.
SMB 암호화
SMB3.x 프로토콜 버전을 사용하는 Windows SMB 클라이언트는 기본적으로 SMB 암호화를 지원합니다. SMB 암호화는 엔드투엔드로 수행되며 AES-256-GCM/AES-128-GCM 및 AES-256-CCM/AES-128-CCM 암호화 제품군을 사용하여 SMB 대화 전체를 암호화합니다.
SMB 암호화는 Azure NetApp Files 볼륨에 필요하지는 않지만 추가 보안을 위해 사용할 수 있습니다. SMB 암호화는 성능 오버헤드를 추가합니다. SMB 암호화 관련 성능 고려 사항에 대한 자세한 내용은 Azure NetApp Files의 SMB 성능 모범 사례를 참조하세요.
SMB 연결에 암호화 필요
Azure NetApp Files는 모든 SMB 연결에서 암호화를 적용하는 옵션을 제공합니다. 암호화를 적용하면 암호화되지 않은 SMB 통신이 허용되지 않으며 SMB 연결에 SMB3 이상을 사용합니다. 암호화는 AES 암호화를 사용하여 수행되며 모든 SMB 패킷을 암호화합니다. 이 기능이 제대로 작동하려면 SMB 클라이언트가 SMB 암호화를 지원해야 합니다. SMB 클라이언트가 암호화 및 SMB3을 지원하지 않으면 SMB 연결이 허용되지 않습니다. 이 옵션을 사용하도록 설정하면 IP 주소가 동일한 모든 공유에 암호화가 필요하므로 암호화에 대한 SMB 공유 속성 설정이 재정의됩니다.
SMB 공유 수준 암호화
또는 Azure NetApp Files 볼륨의 개별 공유 수준에서 암호화를 설정할 수 있습니다.
UNC 강화
2015년, Microsoft는 SMB 공유 간에 원격 코드 실행을 허용할 수 있는 원격 네트워크 경로 취약성을 해결하기 위해 UNC 강화(MS15-011 및 MS15-014)를 도입했습니다. 자세한 내용은 MS15-011 및 MS15-014: 그룹 정책 강화를 참조하세요.
UNC 강화는 UNC 경로를 보호하기 위한 세 가지 옵션을 제공합니다.
RequireMutualAuthentication– 스푸핑 공격을 차단하는 데 ID 인증이 필요/필요하지 않음RequireIntegrity– 변조 공격을 차단하는 데 무결성 검사가 필요/필요하지 않음RequirePrivacy– 트래픽 스니핑을 방지하기 위해 프라이버시(SMB 패킷의 전체 암호화)를 사용/사용 안 함
Azure NetApp Files는 세 가지 형태의 UNC 강화를 모두 지원합니다.
NFS Kerberos
또한 Azure NetApp Files는 AES-256-GCM/AES-128-GCM 및 AES-256-CCM/AES-128-CCM 암호화 제품군을 사용하여 Kerberos 인증을 통해 NFSv4.1 대화를 암호화하는 기능을 제공합니다.
NFS Kerberos를 사용하여 Azure NetApp Files는 세 가지 보안 버전을 지원합니다.
- Kerberos 5(
krb5) – 초기 인증에만 해당합니다. NFS 내보내기에 액세스하려면 Kerberos 티켓 교환/사용자 로그인이 필요합니다. NFS 패킷은 암호화되지 않습니다. - Kerberos 5i(
krb5i) – 초기 인증 및 무결성 검사에 사용됩니다. NFS 내보내기에 액세스하려면 Kerberos 티켓 교환/사용자 로그인이 필요하고 MITM(중간자(man-in-the-middle)) 공격을 방지하기 위해 각 NFS 패킷에 무결성 검사를 추가합니다. - Kerberos 5p(
krb5p) – 초기 인증, 무결성 검사 및 프라이버시에 사용됩니다. NFS 내보내기에 액세스하려면 Kerberos 티켓 교환/사용자 로그인이 필요하고, 무결성 검사를 수행하고, 각 NFS 패킷에 GSS 래퍼를 적용하여 콘텐츠를 암호화합니다.
각 Kerberos 암호화 수준은 성능에 영향을 줍니다. 암호화 유형 및 보안 버전이 더 안전한 방법을 통합함에 따라 성능 영향이 증가합니다. 예를 들어 krb5가 krb5i보다 성능이 우수하고, krb5i가 krb5p보다 성능이 우수하고, AES-128이 AES-256보다 성능이 우수합니다. Azure NetApp Files에서 NFS Kerberos의 성능 영향에 대한 자세한 내용은 Azure NetApp Files NFSv4.1 볼륨에 대한 Kerberos의성능 영향을 참조하세요.
참고 항목
NFS Kerberos는 Azure NetApp Files에서 NFSv4.1에만 지원됩니다.
다음 이미지에서는 Kerberos 5(krb5)가 사용됩니다. 초기 인증 요청(로그인/티켓 획득)만 암호화됩니다. 다른 모든 NFS 트래픽은 일반 텍스트로 도착합니다.
Kerberos 5i(krb5i, 무결성 검사)를 사용하는 경우 추적은 NFS 패킷이 암호화되지 않았지만 클라이언트와 서버가 체크섬을 사용하여 전송된 데이터의 무결성을 보장하도록 요구하는 GSS/Kerberos 래퍼가 패킷에 추가되었음을 보여줍니다.
Kerberos 5p(개인 정보 보호, krb5p)는 추적 이미지에 표시된 대로 GSS/Kerberos 래퍼를 사용하여 모든 NFS 트래픽에 대한 엔드투엔드 암호화를 제공합니다. 이 방법은 모든 NFS 패킷의 암호화를 처리해야 하므로 성능 오버헤드가 가장 큽니다.
데이터 복제
Azure NetApp Files에서는 전체 볼륨을 Azure의 영역 또는 지역 간에 복제하여 데이터 보호를 제공할 수 있습니다. 복제 트래픽은 Azure 클라우드에 상주하므로 전송은 패킷 스니핑 및 중간자(man-in-the-middle) 공격(통신 엔드포인트 간 도청 또는 가장)을 방지하기 위해 액세스가 제한된 보안 Azure 네트워크 인프라에서 수행됩니다. 또한 복제 트래픽은 FIPS 140-2 준수 TLS 1.2 표준을 사용하여 암호화됩니다. 자세한 내용은 보안 FAQ를 참조하세요.
LDAP 암호화
일반적으로 LDAP 검색 및 바인딩 트래픽은 일반 텍스트로 케이블을 통과합니다. 즉, 네트워크 패킷을 스니핑할 수 있는 사용자는 LDAP 서버에서 사용자 이름, 숫자 ID, 그룹 멤버 자격 등과 같은 정보를 얻을 수 있습니다. 그런 다음, 이 정보를 사용하여 사용자를 스푸핑하고, 피싱 공격을 위한 이메일을 보내는 등의 작업을 수행할 수 있습니다.
LDAP 통신을 가로채서 읽는 것을 방지하기 위해 LDAP 트래픽은 각각 LDAP 서명과 LDAP over TLS를 통해 AES 및 TLS 1.2를 활용하는 유선 암호화를 사용할 수 있습니다. 이러한 옵션을 구성하는 방법에 대한 자세한 내용은 Active Directory 연결 만들기 및 관리를 참조하세요.
LDAP 서명
LDAP 서명은 사용자 및 그룹에 대한 UNIX ID를 호스트하는 Microsoft Active Directory 서버에서의 연결과 관련이 있습니다. 이 기능을 사용하면 LDAP 연결을 호스트하는 AD 서버에 대한 SASL(단순 인증 및 보안 계층) LDAP 바인딩에 무결성 확인을 사용할 수 있습니다. 서명은 Active Directory의 KDC(Kerberos 키 배포 센터) 서비스와의 GSS-API 통신을 사용하기 때문에 보안 인증서의 구성이 필요하지 않습니다. LDAP 서명은 LDAP 패킷의 무결성만 확인합니다. 패킷의 페이로드를 암호화하지 않습니다.
LDAP 서명은 그룹 정책을 통해 LDAP 서명을 기회에 따라 지원하거나(없음 - 클라이언트에서 요청한 경우 지원) LDAP 서명을 적용(필수)하도록 Windows 서버 쪽으로부터 구성할 수도 있습니다. LDAP 서명은 일반적으로 최종 사용자에게 드러나지 않는 성능 오버헤드를 LDAP 트래픽에 추가할 수 있습니다.
Windows Active Directory를 사용하면 LDAP 서명 및 봉인(LDAP 패킷의 엔드투엔드 암호화)을 사용할 수도 있습니다. Azure NetApp Files는 이 기능을 지원하지 않습니다.
LDAP 채널 바인딩
Windows Active Directory 도메인 컨트롤러에서 발견된 보안 취약성으로 인해 Windows 서버의 기본 설정이 변경되었습니다. 자세한 내용은 Microsoft 보안 권고 ADV190023을 참조하세요.
기본적으로 관리자가 채널 바인딩과 함께 LDAP 서명을 사용하도록 설정하는 것이 좋습니다. LDAP 클라이언트가 채널 바인딩 토큰 및 LDAP 서명을 지원하는 경우 채널 바인딩 및 서명은 필수이며 레지스트리 옵션은 새 Microsoft 패치에 의해 설정됩니다.
Azure NetApp Files는 기본적으로 LDAP 채널 바인딩을 기회에 따라 지원합니다. 즉, LDAP 채널 바인딩은 클라이언트가 지원하는 경우에 사용됩니다. 채널 바인딩을 지원/전송하지 않는 경우 통신이 계속 허용되고 채널 바인딩이 적용되지 않습니다.
LDAP over SSL(포트 636)
Azure NetApp Files의 LDAP 트래픽은 모든 경우에 포트 389를 통과합니다. 이 포트는 수정할 수 없습니다. LDAP over SSL(LDAPS)은 지원되지 않으며 대부분의 LDAP 서버 공급업체에게 레거시로 간주됩니다(1995년 공표된 RFC 1777). Azure NetApp Files에서 LDAP 암호화를 사용하려면 LDAP over TLS를 사용합니다.
LDAP over StartTLS
LDAP over StartTLS는 2000년에 RFC 2830을 통해 도입되었으며 2006년에 RFC 4511을 통해 LDAPv3 표준으로 결합되었습니다. StartTLS가 표준이 된 후 LDAP 공급업체는 LDAPS를 사용 중단된 것으로 간주하기 시작했습니다.
LDAP over StartTLS는 LDAP 연결에 포트 389를 사용합니다. 초기 LDAP 연결이 설정되면 StartTLS OID가 교환되고 인증서가 비교됩니다. 그러면 모든 LDAP 트래픽이 TLS를 사용하여 암호화됩니다. 아래에 표시된 패킷 캡처는 LDAP 바인딩, StartTLS 핸드셰이크 및 후속 TLS 암호화 LDAP 트래픽을 보여줍니다.
LDAPS와 StartTLS 사이에는 두 가지 주요 차이점이 있습니다.
- StartTLS는 LDAP 표준의 일부입니다. LDAPS는 그렇지 않습니다. 따라서 LDAP 서버 또는 클라이언트에서 LDAP 라이브러리 지원은 다를 수 있으며 기능이 모든 경우에 작동할 수도 있고 작동하지 않을 수도 있습니다.
- 암호화가 실패하면 StartTLS에서는 구성을 일반 LDAP로 대체할 수 있습니다. LDAPS는 그렇지 않습니다. 결과적으로 StartTLS는 유연성 및 복원력을 제공하지만 잘못 구성된 경우 보안 위험도 존재합니다.
LDAP over StartTLS 사용 시 보안 고려 사항
StartTLS에서는 관리자가 원하는 경우 일반 LDAP 트래픽으로 대체할 수 있습니다. 보안을 위해 대부분의 LDAP 관리자는 이를 허용하지 않습니다. StartTLS에 대한 다음 권장 사항은 LDAP 통신을 보호하는 데 도움이 될 수 있습니다.
- StartTLS가 사용하도록 설정되고 인증서가 구성되어 있는지 확인합니다.
- 내부 환경의 경우 자체 서명된 인증서를 사용할 수 있지만 외부 LDAP의 경우 인증 기관을 사용합니다. 인증서에 대한 자세한 내용은 자체 서명된 SSL과 인증 기관 간의 차이점을 참조하세요.
- StartTLS를 사용하지 않는 LDAP 쿼리 및 바인딩을 방지합니다. 기본적으로 Active Directory는 익명 바인딩을 사용하지 않도록 설정합니다.
Active Directory 보안 연결
Azure NetApp Files 볼륨이 포함된 Active Directory 연결은 가장 강력한 Kerberos 암호화 유형인 AES-256을 먼저 시도하도록 구성할 수 있습니다. AES 암호화를 사용하도록 설정하면 도메인 컨트롤러 통신(예: 예약된 SMB 서버 암호 재설정)은 도메인 컨트롤러에서 지원되는 가장 강력한 사용 가능한 암호화 유형을 사용합니다. Azure NetApp Files는 도메인 컨트롤러 통신에 대해 다음 암호화 유형을 시도된 인증 순서대로 지원합니다. AES-256, AES-128, RC4-HMAC, DES
참고 항목
Azure NetApp Files(예: RC4-HMAC 및 DES)에서 약한 인증 유형을 사용하지 않도록 설정할 수 없습니다. 대신, 그렇게 하려는 경우 인증 요청이 사용을 시도하지 않도록 도메인 컨트롤러에서 사용하지 않도록 설정해야 합니다. 도메인 컨트롤러에서 RC4-HMAC를 사용하지 않도록 설정한 경우 적절한 기능을 위해 Azure NetApp Files에서 AES 암호화를 사용하도록 설정해야 합니다.