Azure NetApp Files의 이중 프로토콜 보안 스타일 및 권한 동작 이해
SMB 및 NFS는 사용자 및 그룹 액세스에 대해 서로 다른 권한 모델을 사용합니다. 따라서 프로토콜 액세스에 대해 원하는 권한 모델을 적용하도록 Azure NetApp 파일 볼륨을 구성해야 합니다. NFS 전용 환경의 경우, 결정은 간단합니다. UNIX 보안 스타일을 사용하는 것입니다. SMB 전용 환경의 경우 NTFS 보안 스타일을 사용합니다.
동일한 데이터 세트(이중 프로토콜)에서 NFS와 SMB가 필요한 경우 다음 두 가지 질문에 따라 결정을 내려야 합니다.
- 사용자가 어떤 프로토콜에서 사용 권한을 가장 많이 관리하게 되나요?
- 원하는 권한 관리 엔드포인트는 무엇인가요? 즉, 사용자에게 NFS 클라이언트 또는 Windows 클라이언트에서 사용 권한을 관리하는 기능이 필요합니까? 또는 둘 모두?
볼륨 보안 스타일은 실제로 사용 권한 스타일로 간주될 수 있습니다. 여기서 결정 요소는 원하는 ACL 관리 스타일입니다.
참고 항목
보안 스타일은 볼륨을 만들 때 선택됩니다. 보안 스타일을 선택한 후에는 변경할 수 없습니다.
Azure NetApp Files 볼륨 보안 스타일 정보
Azure NetApp Files에는 볼륨 보안 스타일에 대한 다음 두 가지 주요 선택 항목이 있습니다.
UNIX - UNIX 보안 스타일은 기본 POSIX 모드 비트(0755와 같은 표준 읽기/쓰기/실행 권한이 있는 소유자/그룹/Everyone 액세스) 및 NFSv4.x ACL과 같은 UNIX 스타일 권한을 제공합니다. POSIX ACL은 지원되지 않습니다.
NTFS - NTFS 보안 스타일은 표준 Windows NTFS 권한과 동일한 기능을 제공하며, ACL의 세분화된 사용자 및 그룹과 자세한 보안/감사 권한도 함께 제공합니다.
이중 프로토콜 NAS 환경에서는 하나의 보안 권한 스타일만 활성화할 수 있습니다. 각 보안 스타일을 선택하기 전에 각 보안 스타일에 대한 고려 사항을 평가해야 합니다.
| 보안 스타일 | 고려 사항 |
|---|---|
| UNIX | - Windows 클라이언트는 UNIX 특성에 매핑되는 SMB를 통해서만 UNIX 권한 특성(읽기/쓰기/실행만, 특별한 권한 없음)을 설정할 수 있습니다. - NFSv4.x ACL에는 GUI 관리가 없습니다. 관리는 nfs4_getfacl 및 nfs4_setfacl 명령을 사용하여 CLI를 통해서만 수행됩니다. - 파일 또는 폴더에 NFSv4.x ACL이 있는 경우 Windows 보안 속성 탭에서 해당 ACL을 표시할 수 없습니다. |
| NTFS | - UNIX 클라이언트는 chown/chmod와 같은 명령을 사용하여 NFS를 통해 특성을 설정할 수 없습니다. - NFS 클라이언트는 ls 명령을 사용할 때 대략적인 NTFS 권한만 표시합니다. 예를 들어 사용자에게 POSIX 모드 비트(예: 트래버스 디렉터리)로 완전히 변환할 수 없는 Windows NTFS ACL에 권한이 있는 경우 가장 가까운 POSIX 모드 비트 값(예: 실행 권한의 경우 1)으로 변환됩니다. |
볼륨 보안 스타일을 선택하면 사용자에 대한 이름 매핑을 수행하는 방법이 결정됩니다. 이 작업은 이중 프로토콜 볼륨이 사용 중인 프로토콜에 관계없이 예측 가능한 권한을 유지하는 방법의 핵심 요소입니다.
적절한 볼륨 보안 스타일을 선택하기 위한 의사 결정 매트릭스로 다음 표를 사용합니다.
| 보안 스타일 | 대부분 NFS | 대부분 SMB | 세분화된 보안 필요 |
|---|---|---|---|
| UNIX | X | - | X(NFSv4.x ACL 사용) |
| NTFS | - | X | X |
Azure NetApp Files에서 이름 매핑이 작동하는 방식
Azure NetApp Files에서 사용자만 인증되고 매핑됩니다. 그룹은 매핑되지 않습니다. 대신 그룹 구성원은 사용자 ID를 사용하여 결정됩니다.
사용자가 Azure NetApp Files 볼륨에 액세스하려고 하면 해당 시도가 ID를 따라 서비스에 전달됩니다. 해당 ID에는 사용자 이름 및 고유 숫자 ID(NFSv3의 UID 번호, NFSv4.1의 이름 문자열, SMB용 SID)가 포함됩니다. Azure NetApp Files는 해당 ID를 사용하여 구성된 이름 서비스에 대해 인증하는 방법으로 사용자의 ID를 확인합니다.
- 숫자 ID에 대한 LDAP 검색은 Active Directory에서 사용자 이름을 조회하는 데 사용됩니다.
- 이름 문자열은 LDAP 검색을 사용하여 사용자 이름을 조회하고 클라이언트와 서버는 NFSv4.1에 대해 구성된 ID 도메인을 참조하여 일치 여부를 확인합니다.
- Windows 사용자는 Active Directory에 대한 표준 Windows RPC 호출을 사용하여 쿼리됩니다.
- 그룹 구성원도 쿼리되고, 모든 항목이 자격 증명 캐시에 추가되어 볼륨에 대한 후속 요청에서 더 빠르게 처리됩니다.
- 현재 사용자 지정 로컬 사용자는 Azure NetApp Files에서 사용할 수 없습니다. Active Directory의 사용자만 이중 프로토콜과 함께 사용할 수 있습니다.
- 현재 이중 프로토콜 볼륨과 함께 사용할 수 있는 유일한 로컬 사용자는 루트 및
nfsnobody사용자입니다.
Azure NetApp Files에서 사용자 이름을 인증하고 유효성을 검사한 후에 이중 프로토콜 볼륨 인증을 수행할 다음 단계는 UNIX 및 Windows 상호 운용성을 위한 사용자 이름 매핑입니다.
볼륨의 보안 스타일에 따라 Azure NetApp Files에서 이름 매핑을 수행하는 방법이 결정됩니다. Windows 및 UNIX 권한 의미 체계는 서로 다릅니다. 이름 매핑을 수행할 수 없는 경우 인증에 실패하고 클라이언트에서 볼륨에 대한 액세스가 거부됩니다. 이 상황이 발생하는 일반적인 시나리오는 NFSv3 액세스가 NTFS 보안 스타일의 볼륨에 시도되는 경우입니다. NFSv3의 초기 액세스 요청은 Azure NetApp Files에 숫자 UID로 제공됩니다. 1001의 숫자 ID로 명명된 user1이라는 사용자가 NFSv3 탑재에 액세스하려고 하면 인증 요청이 숫자 ID 1001로 도착합니다. 그러면 Azure NetApp Files가 숫자 ID 1001을 가져와 1001을 사용자 이름으로 확인하려고 시도합니다. 볼륨에 대한 NTFS 권한에는 숫자 ID 대신 Windows 사용자 이름이 포함되므로 이 사용자 이름은 유효한 Windows 사용자에 매핑하는 데 필요합니다. Azure NetApp Files는 구성된 LDAP(이름 서비스 서버)를 사용하여 사용자 이름을 검색합니다. 사용자 이름을 찾을 수 없는 경우 인증에 실패하고 액세스가 거부됩니다. 이 작업은 파일 및 폴더에 원치 않는 액세스를 방지하기 위해 설계되었습니다.
보안 스타일에 기반한 이름 매핑
Azure NetApp Files(Windows에서 UNIX로 또는 UNIX에서 Windows로)에서 이름 매핑이 발생하는 방향은 사용 중인 프로토콜뿐만 아니라 볼륨의 보안 스타일에 따라서도 달라집니다. Windows 클라이언트에서는 액세스를 허용하기 위해 항상 Windows에서 UNIX로 이름 매핑이 필요하지만 항상 일치하는 UNIX 사용자 이름이 필요한 것은 아닙니다. 구성된 이름 서비스 서버에 유효한 UNIX 사용자 이름이 없는 경우, Azure NetApp Files는 SMB 연결에 대한 초기 인증을 허용하는 65534라는 숫자 UID를 사용하여 대체 기본 UNIX 사용자를 제공합니다. 그 후에는 파일 및 폴더 권한이 액세스를 제어합니다. 일반적으로 65534는 nfsnobody 사용자와 일치하기 때문에 대부분의 경우 액세스가 제한됩니다. 반대로, NTFS 보안 스타일을 사용 중인 경우 NFS 클라이언트는 UNIX-Windows 이름 매핑만 사용해야 합니다. Azure NetApp Files에는 기본 Windows 사용자가 없습니다. 따라서 요청 이름과 일치하는 유효한 Windows 사용자를 찾을 수 없는 경우, 액세스가 거부됩니다.
다음 표에는 사용 중인 프로토콜에 따라 다양한 이름 매핑 순열과 동작 방식이 분류되어 있습니다.
| 프로토콜 | 보안 스타일 | 이름 매핑 방향 | 적용되는 권한 |
|---|---|---|---|
| SMB | UNIX | Windows-UNIX | UNIX UNIX(모드 비트 또는 NFSv4.x ACL) |
| SMB | NTFS | Windows-UNIX | NTFS ACL (공유에 액세스하는 Windows SID 기준) |
| NFSv3 | UNIX | 없음 | UNIX (모드 비트 또는 NFSv4.x ACL*) |
| NFSv4.x | UNIX | UNIX 사용자 이름에 대한 숫자 ID | UNIX UNIX(모드 비트 또는 NFSv4.x ACL) |
| NFS3/4.x | NTFS | UNIX-Windows | NTFS ACL (매핑된 Windows 사용자 SID 기준) |
참고 항목
Azure NetApp Files의 이름 매핑 규칙은 현재 LDAP를 사용해야만 제어할 수 있습니다. 서비스 내에서 명시적 이름 매핑 규칙을 만드는 옵션은 없습니다.
이중 프로토콜 볼륨을 사용하는 이름 서비스
사용되는 NAS 프로토콜에 관계없이 이중 프로토콜 볼륨은 이름 매핑 개념을 사용하여 사용 권한을 올바르게 처리합니다. 따라서 이름 서비스는 볼륨에 액세스하기 위해 SMB 및 NFS를 모두 사용하는 환경에서 기능을 유지하는 데 중요한 역할을 합니다.
이름 서비스는 NAS 볼륨에 액세스하는 사용자 및 그룹의 ID 소스 역할을 합니다. 이 작업에는 표준 도메인 서비스와 LDAP 기능을 모두 사용하는 Windows 및 UNIX 사용자 및 그룹 모두에 대한 소스 역할을 할 수 있는 Active Directory가 포함됩니다.
이름 서비스는 어려운 요구 사항은 아니지만 Azure NetApp Files 이중 프로토콜 볼륨에 매우 권장됩니다. 서비스 내에서 사용자 지정 로컬 사용자 및 그룹을 만드는 개념은 없습니다. 따라서 프로토콜 간에 적절한 인증과 정확한 사용자 및 그룹 소유자 정보를 갖기 위해서는 LDAP가 필요합니다. 소수의 사용자만 있고 정확한 사용자 및 그룹 ID 정보를 채울 필요가 없는 경우 LDAP가 있는 로컬 NFS 사용자가 이중 프로토콜 볼륨 기능에 액세스하도록 허용하는 것이 좋습니다. 이 기능을 사용하도록 설정하면 확장된 그룹 기능이 사용되지 않습니다.
클라이언트, 이름 서비스 및 스토리지가 서로 다른 영역에 상주하는 경우
경우에 따라 NAS 클라이언트는 스토리지 및 이름 서비스에 대한 격리된 연결이 있는 여러 인터페이스가 있는 분할된 네트워크에 상주할 수 있습니다.
이러한 예 중 하나는 스토리지가 Azure NetApp Files에 상주하는 반면, NAS 클라이언트 및 도메인 서비스는 모두 온-프레미스(예: Azure의 허브 스포크 아키텍처)에 상주하는 경우입니다. 이러한 시나리오에서는 NAS 클라이언트와 이름 서비스 모두에 대한 네트워크 액세스를 제공해야 합니다.
다음 그림은 이러한 종류의 구성에 대한 예를 보여 줍니다.
