인공 지능
NFS 를 참조하십시오
변경 제안
PDF
NFS는 RFC(Request for Comments)에 정의된 공개 IETF 표준인 분산 파일 시스템 프로토콜로, 누구나 프로토콜을 구현할 수 있도록 합니다.
Cloud Volumes Service의 볼륨은 클라이언트 또는 클라이언트 세트에 액세스할 수 있는 경로를 내보내 NFS 클라이언트에 공유됩니다. 이러한 내보내기를 마운트할 수 있는 권한은 Cloud Volumes Service 관리자가 구성할 수 있는 내보내기 정책 및 규칙에 의해 정의됩니다.
NetApp NFS 구현은 프로토콜의 골드 표준으로 간주되며 수많은 엔터프라이즈 NAS 환경에서 사용됩니다. 다음 섹션에서는 NFS와 Cloud Volumes Service에서 사용할 수 있는 특정 보안 기능 및 구현 방법에 대해 설명합니다.
기본 로컬 UNIX 사용자 및 그룹
Cloud Volumes Service에는 다양한 기본 기능을 위한 여러 기본 UNIX 사용자 및 그룹이 포함되어 있습니다. 이러한 사용자 및 그룹은 현재 수정 또는 삭제할 수 없습니다. 현재 새 로컬 사용자 및 그룹을 Cloud Volumes Service에 추가할 수 없습니다. 기본 사용자 및 그룹 외부의 UNIX 사용자 및 그룹은 외부 LDAP 이름 서비스에서 제공해야 합니다.
다음 표에서는 기본 사용자 및 그룹과 해당 숫자 ID를 보여 줍니다. LDAP 또는 이러한 숫자 ID를 다시 사용하는 로컬 클라이언트에서는 새 사용자 또는 그룹을 생성하지 않는 것이 좋습니다.
| 기본 사용자: 숫자 ID | 기본 그룹: 숫자 ID |
|---|---|
|
|
|
NFSv4.1을 사용하는 경우 NFS 클라이언트에서 디렉토리 목록 명령을 실행할 때 루트 사용자가 아무도 표시되지 않을 수 있습니다. 이는 클라이언트의 ID 도메인 매핑 구성 때문입니다. 의 섹션을 참조하십시오 NFSv4.1 및 그 누구도 사용자/그룹을 대상으로 하지 않습니다 이 문제에 대한 자세한 내용 및 해결 방법을 확인하십시오. |
루트 사용자입니다
Linux에서 루트 계정은 Linux 기반 파일 시스템의 모든 명령, 파일 및 폴더에 액세스할 수 있습니다. 이 계정의 강력한 기능 때문에 보안 모범 사례에 따라 루트 사용자를 비활성화하거나 제한해야 하는 경우가 많습니다. NFS 내보내기에서 루트 사용자가 파일과 폴더에 가지고 있는 파워는 내보내기 정책과 규칙, 루트 스쿼시(root squash)라는 개념을 통해 Cloud Volumes Service에서 제어할 수 있습니다.
루트 스쿼싱 기능을 사용하면 NFS 마운트에 액세스하는 루트 사용자가 익명 숫자 사용자 65534에 스쿼트됩니다(“ 섹션 참조)익명 사용자") 및 은(는) 현재 CVS - Performance를 사용하는 경우에만 사용할 수 있습니다. 이 경우 내보내기 정책 규칙 생성 중 루트 액세스에 대해 Off를 선택합니다. 루트 사용자가 익명 사용자에게 스쿼트되면 chown 또는 을 실행할 수 있는 액세스 권한이 더 이상 없습니다 "setuid/setgid 명령(고정 비트)" NFS 마운트의 파일 또는 폴더와 루트 사용자가 생성한 파일 또는 폴더에 anon UID가 소유자/그룹으로 표시됩니다. 또한 루트 사용자가 NFSv4 ACL을 수정할 수 없습니다. 그러나 루트 사용자는 chmod 및 삭제된 파일에 대한 명시적 권한이 없는 액세스 권한을 계속 가집니다. 루트 사용자의 파일 및 폴더 권한에 대한 액세스를 제한하려면 NTFS ACL을 사용하여 볼륨을 사용하고, "root"라는 Windows 사용자를 생성하고, 파일 또는 폴더에 원하는 권한을 적용하는 것이 좋습니다.
익명 사용자
익명(anon) 사용자 ID는 유효한 NFS 자격 증명 없이 도착하는 클라이언트 요청에 매핑된 UNIX 사용자 ID 또는 사용자 이름을 지정합니다. 여기에는 루트 스쿼싱 사용 시 루트 사용자가 포함될 수 있습니다. Cloud Volumes Service의 anon 사용자는 65534입니다.
이 UID는 일반적으로 Linux 환경의 사용자 이름 'nobody' 또는 'nfsnobody'와 관련이 있습니다. Cloud Volumes Service는 로컬 UNIX 사용자 ' pcuser ' 로 65534도 사용합니다(“ 절 참조)기본 로컬 UNIX 사용자 및 그룹"). LDAP에서 일치하는 유효한 UNIX 사용자를 찾을 수 없는 경우 Windows에서 UNIX로의 이름 매핑의 기본 대체 사용자입니다.
Linux의 사용자 이름과 UID 65534의 Cloud Volumes Service 간 사용자 이름 차이로 인해 65534에 매핑된 사용자의 이름 문자열이 NFSv4.1을 사용할 때 일치하지 않을 수 있습니다. 따라서 일부 파일 및 폴더에 대해 사용자로 'nobody'가 표시될 수 있습니다. 자세한 내용은 " 단원을 참조하십시오NFSv4.1 및 그 누구도 사용자/그룹을 대상으로 하지 않습니다"를 참조하십시오.
액세스 제어/내보내기
NFS 마운트에 대한 초기 엑스포트/공유 액세스는 엑스포트 정책 내에 포함된 호스트 기반 엑스포트 정책 규칙을 통해 제어됩니다. 호스트 IP, 호스트 이름, 서브넷, 넷그룹 또는 도메인이 정의되어 NFS 공유를 마운트하는 액세스 권한과 호스트에 허용되는 액세스 수준을 허용합니다. 엑스포트 정책 규칙 구성 옵션은 Cloud Volumes Service 레벨에 따라 다릅니다.
CVS-SW의 경우 내보내기 정책 구성에 다음 옵션을 사용할 수 있습니다.
-
* 클라이언트 일치. * 쉼표로 구분된 IP 주소 목록, 쉼표로 구분된 호스트 이름, 서브넷, 넷그룹, 도메인 이름 목록.
-
* RO/RW 액세스 규칙 * 내보내기에 대한 액세스 수준을 제어하려면 읽기/쓰기 또는 읽기 전용 을 선택합니다. CVS - 성능은 다음 옵션을 제공합니다.
-
* 클라이언트 일치. * 쉼표로 구분된 IP 주소 목록, 쉼표로 구분된 호스트 이름, 서브넷, 넷그룹, 도메인 이름 목록.
-
* RO/RW 액세스 규칙. * 읽기/쓰기 또는 읽기 전용 을 선택하여 내보내기에 대한 액세스 수준을 제어합니다.
-
* 루트 액세스(켜기/끄기). * 루트 스쿼시를 구성합니다(“ 절 참조)루트 사용자입니다"를 참조하십시오.)
-
* Protocol type. * 이 옵션은 NFS 마운트에 대한 액세스를 특정 프로토콜 버전으로 제한합니다. 볼륨에 대해 NFSv3과 NFSv4.1을 모두 지정할 때 두 확인란을 모두 비워 두거나 두 확인란을 모두 선택합니다.
-
* Kerberos 보안 수준(Kerberos 활성화 가 선택된 경우). * 읽기 전용 또는 읽기-쓰기 액세스에 대해 krb5, krb5i 및/또는 krb5p의 옵션을 제공합니다.
변경 소유권(chown) 및 변경 그룹(chgrp)
Cloud Volumes Service의 NFS에서는 루트 사용자만 파일 및 폴더에 대해 chown/chgrp를 실행할 수 있습니다. 다른 사용자는 자신이 소유한 파일에서도 'Operation not mitted(작업이 허용되지 않음)' 오류를 볼 수 있습니다. 루트 스쿼시를 사용하는 경우(“ 섹션에서 다룹니다루트 사용자입니다”), 루트가 비루트 사용자에게 스쿼트되고 chown 및 chgrp에 대한 액세스가 허용되지 않습니다. 현재 Cloud Volumes Service에는 루트 이외의 사용자에 대한 chown 및 chgrp를 허용하는 대안이 없습니다. 소유권을 변경해야 하는 경우 이중 프로토콜 볼륨을 사용하고 보안 스타일을 NTFS로 설정하여 Windows 측의 권한을 제어할 수 있습니다.
권한 관리
Cloud Volumes Service는 모드 비트(예: rwx의 경우 644, 777 등)와 NFSv4.1 ACL을 모두 지원하여 UNIX 보안 스타일을 사용하는 볼륨의 NFS 클라이언트에 대한 사용 권한을 제어합니다. 이러한 사용자(chmod, chown 또는 nfs4_setfacl 등)에 대해 표준 권한 관리가 사용되며 이를 지원하는 모든 Linux 클라이언트와 함께 작동합니다.
또한 NTFS로 설정된 이중 프로토콜 볼륨을 사용하는 경우 NFS 클라이언트는 Windows 사용자에 대한 Cloud Volumes Service 이름 매핑을 활용할 수 있으며, 이 이름 매핑은 NTFS 권한을 확인하는 데 사용됩니다. Cloud Volumes Service를 Windows 사용자 이름에 올바르게 매핑하려면 유효한 UNIX 사용자 이름이 필요하기 때문에 이를 위해서는 Cloud Volumes Service에 대한 LDAP 연결이 필요합니다.
NFSv3에 대한 세부적인 ACL 제공
모드 비트 사용 권한은 소유자, 그룹 및 다른 모든 관련자만 사용할 수 있습니다. 즉, 기본 NFSv3에 대해 세부적인 사용자 액세스 제어를 사용할 수 없습니다. Cloud Volumes Service는 POSIX ACL 또는 확장된 특성(예: chattr)을 지원하지 않으므로 NFSv3을 사용하는 다음 시나리오에서만 세분화된 ACL을 사용할 수 있습니다.
-
유효한 UNIX와 Windows 사용자 간 매핑을 사용하는 NTFS 보안 스타일 볼륨(CIFS 서버 필요)
-
NFSv4.1 ACL은 관리 클라이언트 마운트 NFSv4.1을 사용하여 ACL을 적용하여 적용됩니다.
두 방법 모두 UNIX ID 관리를 위한 LDAP 연결과 유효한 UNIX 사용자 및 그룹 정보를 채워야 합니다(섹션 참조) ""LDAP"") 및 은 CVS - 성능 인스턴스에서만 사용할 수 있습니다. NFS에서 NTFS 보안 스타일 볼륨을 사용하려면 SMB 연결이 구성되어 있지 않더라도 이중 프로토콜(SMB 및 NFSv3) 또는 이중 프로토콜(SMB 및 NFSv4.1)을 사용해야 합니다. NFSv3 마운트에서 NFSv4.1 ACL을 사용하려면 프로토콜 유형으로 'both(NFSv3/NFSv4.1)'를 선택해야 합니다.
일반 UNIX 모드 비트는 NTFS 또는 NFSv4.x ACL이 제공하는 사용 권한과 동일한 수준의 세분성을 제공하지 않습니다. 다음 표에서는 NFSv3 모드 비트와 NFSv4.1 ACL 간의 사용 권한 세분화를 비교합니다. NFSv4.1 ACL에 대한 자세한 내용은 을 참조하십시오 "NFS4_ACL-NFSv4 액세스 제어 목록".
| NFSv3 모드 비트 | NFSv4.1 ACL |
|---|---|
|
ACE(액세스 제어 항목) 형식(허용/거부/감사) * 상속 플래그 * directory-inherit * file-inherit * no-propagate-inherit * inherit-only 권한 * 읽기-데이터(파일)/목록-디렉토리(디렉토리) * 쓰기-데이터(파일)/생성-파일(디렉토리) * 추가-데이터(파일)/생성-하위 디렉토리(디렉토리) * 실행(파일)/변경-디렉토리(디렉토리) * 삭제 * delete-child * read-attributes * write-named-attributes * write-named-acner-write-write-acl-write-write-write-write-acl-write-write-write-write-acl-write-write-write-write- |
마지막으로, RPC 패킷 제한에 따라 NFS 그룹 멤버 자격(NFSv3 및 NFSv4.x에서 모두)은 AUTH_SYS에 대한 기본값 최대 16으로 제한됩니다. NFS Kerberos는 최대 32개의 그룹과 NFSv4 ACL을 제공하므로 사용자 및 그룹 ACL(ACE당 최대 1024개 항목)을 세부적으로 적용하여 제한을 제거할 수 있습니다.
또한 Cloud Volumes Service는 지원되는 최대 그룹을 32개까지 확장할 수 있도록 확장된 그룹 지원을 제공합니다. 이를 위해서는 유효한 UNIX 사용자 및 그룹 ID가 포함된 LDAP 서버에 대한 LDAP 연결이 필요합니다. 이 구성을 구성하는 방법에 대한 자세한 내용은 을 참조하십시오 "NFS 볼륨 생성 및 관리" Google 문서.
NFSv3 사용자 및 그룹 ID
NFSv3 사용자 및 그룹 ID는 이름이 아닌 숫자 ID로 와이어를 통해 제공됩니다. Cloud Volumes Service는 NFSv3을 사용하는 이러한 숫자 ID에 대해 사용자 이름 확인을 수행하지 않으며 UNIX 보안 스타일 볼륨에서는 모드 비트만 사용합니다. NFSv4.1 ACL이 있으면 NFSv3을 사용하더라도 ACL을 제대로 해결하려면 숫자 ID 조회 및/또는 이름 문자열 조회가 필요합니다. NTFS 보안 스타일 볼륨에서 Cloud Volumes Service는 유효한 UNIX 사용자로 숫자 ID를 확인한 다음 유효한 Windows 사용자에게 매핑하여 액세스 권한을 협상해야 합니다.
NFSv3 사용자 및 그룹 ID의 보안 제한
NFSv3에서는 클라이언트와 서버가 숫자 ID로 읽기 또는 쓰기를 시도하는 사용자가 유효한 사용자인지 확인할 필요가 없으며 암시적으로 신뢰됩니다. 이렇게 하면 숫자 ID를 스푸핑하여 파일 시스템이 잠재적 위반으로 열립니다. 이와 같은 보안 문제를 방지하기 위해 Cloud Volumes Service에서 몇 가지 옵션을 사용할 수 있습니다.
-
NFS용 Kerberos를 구현하면 사용자가 사용자 이름 및 암호 또는 keytab 파일로 인증하여 Kerberos 티켓을 받아 마운트에 액세스할 수 있도록 합니다. Kerberos는 CVS에서 사용 가능 - 성능 인스턴스와 NFSv4.1에서만 지원됩니다.
-
엑스포트 정책 규칙에 따라 호스트 목록을 제한하면 NFSv3 클라이언트가 Cloud Volumes Service 볼륨에 액세스할 수 있는 범위가 제한됩니다.
-
이중 프로토콜 볼륨을 사용하고 NTFS ACL을 볼륨에 적용하면 NFSv3 클라이언트가 숫자 ID를 유효한 UNIX 사용자 이름으로 확인하게 되어 액세스 마운트에 대한 올바른 인증이 필요합니다. 이를 위해서는 LDAP를 설정하고 UNIX 사용자 및 그룹 ID를 구성해야 합니다.
-
루트 사용자를 스쿼팅하면 루트 사용자가 NFS 마운트에 수행할 수 있는 손상을 제한하지만 위험을 완전히 제거할 수는 없습니다. 자세한 내용은 " 단원을 참조하십시오루트 사용자입니다.”
궁극적으로 NFS 보안은 고객이 제공하는 프로토콜 버전으로 제한됩니다. NFSv3은 일반적으로 NFSv4.1보다 더 우수한 성능을 제공하지만, 같은 수준의 보안을 제공하지 않습니다.
NFSv4.1
NFSv4.1은 NFSv3과 비교할 때 다음과 같은 이유로 더욱 뛰어난 보안 및 안정성을 제공합니다.
-
임대 기반 메커니즘을 통한 통합 잠금
-
상태 저장 세션
-
단일 포트에서 모든 NFS 기능 지원(2049)
-
TCP 전용
-
ID 도메인 매핑
-
Kerberos 통합(NFSv3은 Kerberos 사용 가능, NFS에만 해당, NLM 같은 보조 프로토콜에는 사용할 수 없음)
NFSv4.1 종속성
NFSv4.1의 추가 보안 기능 덕분에 NFSv3을 사용할 필요가 없는 몇 가지 외부 의존성이 발생했습니다(Active Directory와 같은 SMB의 의존도 필요 방식과 유사).
NFSv4.1 ACL
Cloud Volumes Service는 NFSv4.x ACL을 지원하므로 다음과 같은 일반적인 POSIX 스타일 사용 권한에 비해 뚜렷한 이점을 제공합니다.
-
파일 및 디렉토리에 대한 사용자 액세스를 세부적으로 제어
-
NFS 보안 강화
-
CIFS/SMB와의 상호 운용성 향상
-
AUTH_SYS 보안을 사용하여 사용자당 16개 그룹의 NFS 제한을 제거합니다
-
ACL은 GID(Group ID) 확인이 필요하지 않으므로 GID 리무진을 효과적으로 제거할 수 있습니다. 따라서 Cloud Volumes Service가 아닌 NFS 클라이언트에서 ACL을 제어할 수 있습니다. NFSv4.1 ACL을 사용하려면 클라이언트의 소프트웨어 버전이 이를 지원하고 적절한 NFS 유틸리티가 설치되어 있어야 합니다.
NFSv4.1 ACL과 SMB 클라이언트 간의 호환성
NFSv4 ACL은 Windows 파일 레벨 ACL(NTFS ACL)과 다르지만 유사한 기능을 제공합니다. 그러나 멀티 프로토콜 NAS 환경에서 NFSv4.1 ACL이 있고 동일한 데이터 세트의 NFS 및 SMB(이중 프로토콜 액세스)를 사용 중인 경우에는 SMB2.0 이상을 사용하는 클라이언트에서 Windows 보안 탭의 ACL을 보거나 관리할 수 없습니다.
NFSv4.1 ACL의 작동 방식
참고로 다음 용어가 정의되어 있습니다.
-
* 액세스 제어 목록(ACL). * 권한 항목의 목록입니다.
-
* ACE(액세스 제어 항목).* 목록에 있는 권한 항목.
SetAttr 작업 중에 클라이언트가 파일에서 NFSv4.1 ACL을 설정하면 Cloud Volumes Service는 개체에 해당 ACL을 설정하여 기존 ACL을 대체합니다. 파일에 ACL이 없으면 파일에 대한 모드 권한은 owner@, group@ 및 everyone@에서 계산됩니다. 파일에 기존 SUID/SGID/고정 비트가 있으면 영향을 받지 않습니다.
GETATTR 작업 중에 클라이언트가 파일에서 NFSv4.1 ACL을 받으면 Cloud Volumes Service는 오브젝트와 연결된 NFSv4.1 ACL을 읽고 ACE 목록을 생성하고 목록을 클라이언트에 반환합니다. 파일에 NT ACL 또는 모드 비트가 있는 경우 ACL은 모드 비트에서 구성되며 클라이언트로 반환됩니다.
ACL에 거부 ACE가 있는 경우 액세스가 거부되고 ACE 허용 이 있는 경우 액세스가 부여됩니다. 그러나 ACL에 ACE가 없는 경우에도 액세스가 거부됩니다.
보안 설명자는 SACL(보안 ACL) 및 DACL(임의 ACL)으로 구성됩니다. NFSv4.1이 CIFS/SMB와 상호 운용될 경우 DACL은 NFSv4와 CIFS에 매핑된 일대일 매핑입니다. DACL은 allow 및 deny ACE로 구성됩니다.
NFSv4.1 ACL이 설정된 파일 또는 폴더에서 기본적인 "chmod"를 실행하면 기존 사용자 및 그룹 ACL이 유지되지만 기본 소유자 @, group@, everyone@acls는 수정됩니다.
NFSv4.1 ACL을 사용하는 클라이언트는 시스템의 파일 및 디렉토리에 대한 ACL을 설정하고 볼 수 있습니다. ACL이 있는 디렉터리에 새 파일이나 하위 디렉터리가 만들어지면 해당 개체는 해당 ACL로 태그가 지정된 ACL의 모든 ACE를 상속합니다 "상속 플래그".
파일 또는 디렉토리에 NFSv4.1 ACL이 있으면 해당 ACL을 사용하여 파일 또는 디렉토리에 액세스하는 데 사용되는 프로토콜에 관계없이 액세스를 제어할 수 있습니다.
파일 및 디렉토리는 ACE에 올바른 상속 플래그가 지정된 경우 상위 디렉토리의 NFSv4 ACL에서 ACE를 상속합니다(적절한 수정 사항이 있을 수 있음).
NFSv4 요청의 결과로 파일 또는 디렉토리가 생성되면 결과 파일 또는 디렉토리의 ACL은 파일 생성 요청에 ACL이 포함되어 있는지 또는 표준 UNIX 파일 액세스 권한만 포함되는지에 따라 달라집니다. ACL은 상위 디렉토리에 ACL이 있는지 여부에도 따라 달라집니다.
-
요청에 ACL이 포함된 경우 해당 ACL이 사용됩니다.
-
요청에 표준 UNIX 파일 액세스 권한만 있고 상위 디렉토리에 ACL이 없는 경우 클라이언트 파일 모드를 사용하여 표준 UNIX 파일 액세스 권한을 설정합니다.
-
요청에 표준 UNIX 파일 액세스 권한만 있고 상위 디렉토리에 상속할 수 없는 ACL이 있는 경우, 요청에 전달된 모드 비트를 기반으로 하는 기본 ACL이 새 개체에 설정됩니다.
-
요청에 표준 UNIX 파일 액세스 권한만 포함되어 있지만 상위 디렉토리에 ACL이 있는 경우 ACE에 적절한 상속 플래그가 지정된 경우 상위 디렉토리의 ACL에 있는 ACE는 새 파일 또는 디렉토리에 의해 상속됩니다.
ACE 권한
NFSv4.1 ACL 사용 권한은 일련의 대문자 및 소문자 값('rxtncy' 등)을 사용하여 액세스를 제어합니다. 이러한 문자 값에 대한 자세한 내용은 을 참조하십시오 "방법: NFSv4 ACL 사용".
umask 및 ACL 상속을 사용하는 NFSv4.1 ACL 동작
"NFSv4 ACL을 사용하면 ACL 상속을 제공할 수 있습니다". ACL 상속은 NFSv4.1 ACL이 설정된 개체 아래에 생성된 파일 또는 폴더가 의 구성에 따라 ACL을 상속할 수 있음을 의미합니다 "ACL 상속 플래그입니다".
"umask(umask" 관리자 개입 없이 디렉터리에서 파일과 폴더를 만들 수 있는 권한 수준을 제어하는 데 사용됩니다. 기본적으로 Cloud Volumes Service에서는 umask 가 에 따라 예상되는 동작을 나타내는 상속된 ACL을 재정의할 수 있도록 합니다 "RFC 5661".
ACL 형식 지정
NFSv4.1 ACL에는 특정한 형식이 있습니다. 다음은 파일에 설정된 ACE 예제입니다.
A::ldapuser@domain.netapp.com:rwatTnNcCy
앞의 예제는 의 ACL 형식 지침을 따릅니다.
type:flags:principal:permissions
A의 유형은 "허용"을 의미합니다. 이 경우 보안 주체가 그룹이 아니며 상속을 포함하지 않으므로 상속 플래그가 설정되지 않습니다. 또한 ACE는 감사 항목이 아니므로 감사 플래그를 설정할 필요가 없습니다. NFSv4.1 ACL에 대한 자세한 내용은 을 참조하십시오 "http://linux.die.net/man/5/nfs4_acl".
NFSv4.1 ACL이 제대로 설정되지 않았거나 클라이언트 및 서버에서 이름 문자열을 확인할 수 없는 경우 ACL이 예상대로 작동하지 않거나 ACL 변경이 적용되지 않고 오류가 발생할 수 있습니다.
샘플 오류에는 다음이 포함됩니다.
Failed setxattr operation: Invalid argument Scanning ACE string 'A:: user@rwaDxtTnNcCy' failed.
명시적 거부
NFSv4.1 권한에는 소유자, 그룹 및 모든 사용자에 대한 명시적 거부 특성이 포함될 수 있습니다. 따라서 NFSv4.1 ACL은 기본적으로 -deny를 사용하기 때문에 ACL이 명시적으로 ACE에 의해 부여되지 않으면 거부됩니다. 명시적 거부 특성은 액세스 ACE를 명시적 또는 명시적으로 재정의합니다.
거부 ACE는 Ddes 특성 태그로 설정됩니다.
아래 예에서 group@은 모든 읽기 및 실행 권한을 허용하지만 모든 쓰기 액세스는 거부됩니다.
sh-4.1$ nfs4_getfacl /mixed A::ldapuser@domain.netapp.com:ratTnNcCy A::OWNER@:rwaDxtTnNcCy D::OWNER@: A:g:GROUP@:rxtncy D:g:GROUP@:waDTC A::EVERYONE@:rxtncy D::EVERYONE@:waDTC
거부 ACE는 혼란스럽고 복잡할 수 있으므로 가능하면 피해야 합니다. 명시적으로 정의되지 않은 ACL 허용 은 암시적으로 거부됩니다. 거부 ACE가 설정되면 사용자에게 액세스 권한이 부여될 것으로 예상되는 경우 액세스가 거부될 수 있습니다.
앞의 ACE 집합은 모드 비트에서 755와 동일하며, 이는 다음을 의미합니다.
-
소유자에게는 모든 권한이 있습니다.
-
그룹은 읽기 전용입니다.
-
다른 사람들은 읽기 전용입니다.
그러나 사용 권한이 775 상응 권한으로 조정되더라도 모든 사용자에 대해 명시적 거부 설정이 설정되어 있으므로 액세스가 거부될 수 있습니다.
NFSv4.1 ID 도메인 매핑 종속성
NFSv4.1은 ID 도메인 매핑 논리를 보안 계층으로 활용하여 NFSv4.1 마운트에 액세스하려는 사용자가 실제로 자신들이 주장하는 사용자인지 확인합니다. 이 경우 NFSv4.1 클라이언트에서 들어오는 사용자 이름 및 그룹 이름에 이름 문자열이 추가되고 Cloud Volumes Service 인스턴스로 보내집니다. 사용자 이름/그룹 이름 및 ID 문자열 조합이 일치하지 않으면 사용자 및/또는 그룹이 클라이언트의 '/etc/idmapd.conf' 파일에 지정된 기본 nobody 사용자로 충돌합니다.
이 ID 문자열은 특히 NFSv4.1 ACL 및/또는 Kerberos를 사용하는 경우 적절한 권한 준수를 위한 요구 사항입니다. 따라서 적절한 사용자 및 그룹 이름 ID 확인을 위해 클라이언트와 Cloud Volumes Service 간에 일관성을 유지하기 위해 LDAP 서버와 같은 이름 서비스 서버 종속성이 필요합니다.
Cloud Volumes Service는 정적 기본 ID 도메인 이름 값인 ddefaultv4iddomain.com 를 사용합니다. NFS 클라이언트는 ID 도메인 이름 설정에 대해 DNS 도메인 이름으로 기본 설정되지만, '/etc/idmapd.conf'에서 ID 도메인 이름을 수동으로 조정할 수 있습니다.
Cloud Volumes Service에서 LDAP가 활성화된 경우 Cloud Volumes Service는 NFS ID 도메인을 자동화하여 DNS에서 검색 도메인에 대해 구성된 대로 변경할 수 있으며, 다른 DNS 도메인 검색 이름을 사용하지 않는 한 클라이언트를 수정할 필요가 없습니다.
Cloud Volumes Service가 로컬 파일 또는 LDAP에서 사용자 이름 또는 그룹 이름을 확인할 수 있는 경우 도메인 문자열이 사용되고 일치하지 않는 도메인 ID는 아무도 입력할 수 없습니다. Cloud Volumes Service가 로컬 파일 또는 LDAP에서 사용자 이름 또는 그룹 이름을 찾을 수 없는 경우 숫자 ID 값이 사용되며 NFS 클라이언트가 이름을 제대로 확인합니다(NFSv3 동작과 유사).
클라이언트의 NFSv4.1 ID 도메인을 Cloud Volumes Service 볼륨에서 사용 중인 도메인과 일치하도록 변경하지 않고도 다음과 같은 동작이 발생합니다.
-
로컬 UNIX 사용자 및 그룹에 정의된 루트와 같이 Cloud Volumes Service에 로컬 항목이 있는 UNIX 사용자 및 그룹이 nobody 값으로 스쿼트됩니다.
-
LDAP에 항목이 있는 UNIX 사용자 및 그룹(Cloud Volumes Service가 LDAP를 사용하도록 구성된 경우)은 DNS 도메인이 NFS 클라이언트와 Cloud Volumes Service 간에 서로 다른 경우 아무도 사용하지 않습니다.
-
로컬 항목이나 LDAP 항목이 없는 UNIX 사용자 및 그룹은 숫자 ID 값을 사용하고 NFS 클라이언트에 지정된 이름으로 확인합니다. 클라이언트에 이름이 없으면 숫자 ID만 표시됩니다.
다음은 이전 시나리오의 결과입니다.
# ls -la /mnt/home/prof1/nfs4/ total 8 drwxr-xr-x 2 nobody nobody 4096 Feb 3 12:07 . drwxrwxrwx 7 root root 4096 Feb 3 12:06 .. -rw-r--r-- 1 9835 9835 0 Feb 3 12:07 client-user-no-name -rw-r--r-- 1 nobody nobody 0 Feb 3 12:07 ldap-user-file -rw-r--r-- 1 nobody nobody 0 Feb 3 12:06 root-user-file
클라이언트 및 서버 ID 도메인이 일치하면 동일한 파일 목록이 표시됩니다.
# ls -la total 8 drwxr-xr-x 2 root root 4096 Feb 3 12:07 . drwxrwxrwx 7 root root 4096 Feb 3 12:06 .. -rw-r--r-- 1 9835 9835 0 Feb 3 12:07 client-user-no-name -rw-r--r-- 1 apache apache-group 0 Feb 3 12:07 ldap-user-file -rw-r--r-- 1 root root 0 Feb 3 12:06 root-user-file
이 문제와 해결 방법에 대한 자세한 내용은 “ 절을 참조하십시오NFSv4.1 및 그 누구도 사용자/그룹을 대상으로 하지 않습니다.”
Kerberos 종속성
NFS에서 Kerberos를 사용하려면 Cloud Volumes Service에서 다음 권한이 있어야 합니다.
-
Kerberos KDC(메일 센터 서비스)용 Active Directory 도메인
-
LDAP 기능에 대한 UNIX 정보로 채워진 사용자 및 그룹 속성이 있는 Active Directory 도메인(Cloud Volumes Service의 NFS Kerberos에는 적절한 기능을 위해 사용자 SPN-UNIX 사용자 매핑이 필요합니다.)
-
Cloud Volumes Service 인스턴스에 대해 LDAP가 설정되었습니다
-
DNS 서비스에 대한 Active Directory 도메인입니다
NFSv4.1 및 그 누구도 사용자/그룹을 대상으로 하지 않습니다
NFSv4.1 구성에서 가장 흔히 발생하는 문제 중 하나는 'user:group'의 'nobody:nobody'의 조합으로 'ls'를 사용하여 파일 또는 폴더가 목록에 표시되는 것입니다.
예를 들면 다음과 같습니다.
sh-4.2$ ls -la | grep prof1-file -rw-r--r-- 1 nobody nobody 0 Apr 24 13:25 prof1-file
숫자 ID는 99입니다.
sh-4.2$ ls -lan | grep prof1-file -rw-r--r-- 1 99 99 0 Apr 24 13:25 prof1-file
경우에 따라 파일의 소유자가 올바르지만 '아무도'가 그룹에 표시되지 않을 수 있습니다.
sh-4.2$ ls -la | grep newfile1 -rw-r--r-- 1 prof1 nobody 0 Oct 9 2019 newfile1
아무도 없나요?
NFSv4.1의 'nobody' 사용자는 nfsnobody 사용자와 다릅니다. "id" 명령을 실행하여 NFS 클라이언트가 각 사용자를 보는 방법을 볼 수 있습니다.
# id nobody uid=99(nobody) gid=99(nobody) groups=99(nobody) # id nfsnobody uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)
NFSv4.1에서는 'nobody' 사용자가 'idmapd.conf' 파일에 정의된 기본 사용자이며 사용할 모든 사용자로 정의할 수 있습니다.
# cat /etc/idmapd.conf | grep nobody #Nobody-User = nobody #Nobody-Group = nobody
이 문제가 발생하는 이유는 무엇입니까?
이름 문자열 매핑을 통한 보안은 NFSv4.1 작업의 핵심 요소이므로 이름 문자열이 제대로 일치하지 않을 때 기본 동작은 일반적으로 사용자와 그룹이 소유한 파일 및 폴더에 액세스할 수 없는 사용자에게 스쿼시를 하는 것입니다.
파일 목록에서 사용자 및/또는 그룹에 대해 'nobody'가 표시되는 경우 이는 일반적으로 NFSv4.1에서 잘못 구성된 항목이 있음을 의미합니다. 케이스 민감도는 여기에서 확인할 수 있습니다.
예를 들어 user1@CVSDEMO.LOCA L(uid 1234, gid 1234)이 내보내기에 액세스하는 경우 Cloud Volumes Service에서 user1@CVSDEMO.LOCA L(uid 1234, gid 1234)을 찾을 수 있어야 합니다. Cloud Volumes Service의 사용자가 USER1@CVSDEMO.LOCA L인 경우 일치하지 않습니다(대문자 user1과 소문자 user1 비교). 대부분의 경우 클라이언트의 메시지 파일에서 다음을 볼 수 있습니다.
May 19 13:14:29 centos7 nfsidmap[17481]: nss_getpwnam: name 'root@defaultv4iddomain.com' does not map into domain 'CVSDEMO.LOCAL' May 19 13:15:05 centos7 nfsidmap[17534]: nss_getpwnam: name 'nobody' does not map into domain 'CVSDEMO.LOCAL'
클라이언트와 서버는 모두 사용자가 실제로 자신이 주장하는 사람이라는 데 동의해야 합니다. 따라서 클라이언트가 보는 사용자에게 Cloud Volumes Service가 보는 사용자와 동일한 정보가 있는지 확인하려면 다음을 확인해야 합니다.
-
* NFSv4.x ID domain. * Client:'idmapd.conf' file; Cloud Volumes Service는 defaultv4iddomain.com 파일을 사용하며 수동으로 변경할 수 없습니다. NFSv4.1과 함께 LDAP를 사용하는 경우 Cloud Volumes Service는 ID 도메인을 AD 도메인과 동일한 DNS 검색 도메인이 사용 중인 것으로 변경합니다.
-
* 사용자 이름 및 숫자 ID. * 이 옵션은 클라이언트가 사용자 이름을 찾는 위치를 결정하고 이름 서비스 스위치 구성(client: ' nsswitch.conf' 및/또는 로컬 passwd 및 group 파일)을 활용합니다. Cloud Volumes Service는 이를 수정할 수 없지만 활성화된 경우 구성에 LDAP를 자동으로 추가합니다.
-
* 그룹 이름 및 숫자 ID. * 이 옵션은 클라이언트가 그룹 이름을 찾는 위치를 결정하고 이름 서비스 스위치 구성(client: ' nsswitch.conf' 및/또는 로컬 passwd 및 group 파일)을 활용합니다. Cloud Volumes Service는 이를 수정할 수 없지만 활성화된 경우 구성에 LDAP를 자동으로 추가합니다.
거의 모든 경우에 클라이언트의 사용자 및 그룹 목록에 'nobody'가 표시되면 Cloud Volumes Service와 NFS 클라이언트 간의 사용자 또는 그룹 이름 도메인 ID 변환입니다. 이 시나리오를 방지하려면 LDAP를 사용하여 클라이언트와 Cloud Volumes Service 간의 사용자 및 그룹 정보를 확인합니다.
클라이언트의 NFSv4.1에 대한 이름 ID 문자열을 보는 중입니다
NFSv4.1을 사용하는 경우 앞서 설명한 대로 NFS 작업 중에 이름 문자열 매핑이 발생합니다.
NFSv4 ID에 대한 문제를 찾기 위해 '/var/log/messages'를 사용하는 것 외에도 을 사용할 수 있습니다 "nfsidmap -l" NFSv4 도메인에 올바르게 매핑된 사용자 이름을 보려면 NFS 클라이언트에서 명령을 실행하십시오.
예를 들어, 이 명령은 클라이언트에서 찾을 수 있는 사용자 및 Cloud Volumes Service가 NFSv4.x 마운트에 액세스하는 이후의 명령 출력입니다.
# nfsidmap -l 4 .id_resolver keys found: gid:daemon@CVSDEMO.LOCAL uid:nfs4@CVSDEMO.LOCAL gid:root@CVSDEMO.LOCAL uid:root@CVSDEMO.LOCAL
NFSv4.1 ID 도메인(이 경우, 즉 NetApp-user)에 제대로 매핑되지 않는 사용자가 동일한 마운트에 액세스하여 파일을 만지려고 하면 'nobody:nobody'가 예상한 대로 할당됩니다.
# su netapp-user sh-4.2$ id uid=482600012(netapp-user), 2000(secondary) sh-4.2$ cd /mnt/nfs4/ sh-4.2$ touch newfile sh-4.2$ ls -la total 16 drwxrwxrwx 5 root root 4096 Jan 14 17:13 . drwxr-xr-x. 8 root root 81 Jan 14 10:02 .. -rw-r--r-- 1 nobody nobody 0 Jan 14 17:13 newfile drwxrwxrwx 2 root root 4096 Jan 13 13:20 qtree1 drwxrwxrwx 2 root root 4096 Jan 13 13:13 qtree2 drwxr-xr-x 2 nfs4 daemon 4096 Jan 11 14:30 testdir
nfsidmap-l 출력에서는 디스플레이에 사용자 pcuser가 표시되지만 NetApp-user는 표시되지 않습니다. 이는 엑스포트 정책 규칙('65534')의 익명 사용자입니다.
# nfsidmap -l 6 .id_resolver keys found: gid:pcuser@CVSDEMO.LOCAL uid:pcuser@CVSDEMO.LOCAL gid:daemon@CVSDEMO.LOCAL uid:nfs4@CVSDEMO.LOCAL gid:root@CVSDEMO.LOCAL uid:root@CVSDEMO.LOCAL