모드 비트 권한은 의미론상 소유자, 그룹 및 기타 모든 사람에게만 적용됩니다. 즉, 기본 NFSv3에 대한 세부적인 사용자 액세스 제어가 없습니다. Google Cloud NetApp Volumes POSIX ACL이나 확장된 속성(예: chattr)을 지원하지 않으므로 세분화된 ACL은 NFSv3를 사용하는 다음 시나리오에서만 가능합니다.

두 방법 모두 UNIX ID 관리를 위한 LDAP 연결과 유효한 UNIX 사용자 및 그룹 정보가 채워져야 합니다(섹션 참조)."LDAP" )이며 NetApp Volumes-Performance 인스턴스에서만 사용할 수 있습니다. 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 액세스 제어 목록" .

마지막으로, NFS 그룹 멤버십(NFSv3 및 NFSV4.x 모두)은 RPC 패킷 제한에 따라 AUTH_SYS의 기본 최대값인 16으로 제한됩니다. NFS Kerberos는 최대 32개의 그룹을 제공하고 NFSv4 ACL은 세분화된 사용자 및 그룹 ACL(ACE당 최대 1024개 항목)을 통해 이러한 제한을 제거합니다.

또한, Google Cloud NetApp Volumes 최대 32개까지 지원되는 그룹을 확장하는 확장 그룹 지원을 제공합니다. 이렇게 하려면 유효한 UNIX 사용자 및 그룹 ID가 포함된 LDAP 서버에 대한 LDAP 연결이 필요합니다. 이를 구성하는 방법에 대한 자세한 내용은 다음을 참조하세요. "NFS 볼륨 생성 및 관리" Google 문서에서.

NFSv3를 사용하면 클라이언트와 서버는 숫자 ID로 읽기 또는 쓰기를 시도하는 사용자가 유효한 사용자인지 확인할 필요가 없습니다. 그저 암묵적으로 신뢰될 뿐입니다. 숫자 ID를 스푸핑하는 것만으로도 파일 시스템이 잠재적인 침해 위험에 노출됩니다. 이러한 보안 취약점을 방지하기 위해 Google Cloud NetApp Volumes 에는 몇 가지 옵션이 있습니다.

궁극적으로 NFS 보안은 사용하는 프로토콜 버전이 제공하는 것에 따라 제한됩니다. NFSv3는 전반적으로 NFSv4.1보다 성능이 뛰어나지만 동일한 수준의 보안을 제공하지는 않습니다.

NFSv4.1에는 추가 보안 기능이 있기 때문에 NFSv3를 사용하는 데 필요하지 않은 일부 외부 종속성이 있습니다(SMB가 Active Directory와 같은 종속성을 요구하는 것과 유사).

Google Cloud NetApp Volumes NFSv4.x ACL에 대한 지원을 제공하며, 이는 다음과 같은 일반 POSIX 스타일 권한에 비해 뚜렷한 이점을 제공합니다.

NFSv4 ACL은 Windows 파일 수준 ACL(NTFS ACL)과 다르지만 기능은 비슷합니다. 그러나 다중 프로토콜 NAS 환경에서 NFSv4.1 ACL이 있고 이중 프로토콜 액세스(동일한 데이터 세트에서 NFS와 SMB)를 사용하는 경우 SMB2.0 이상을 사용하는 클라이언트는 Windows 보안 탭에서 ACL을 보거나 관리할 수 없습니다.

참고로, 다음 용어가 정의되어 있습니다.

SETATTR 작업 중에 클라이언트가 파일에 NFSv4.1 ACL을 설정하면 Google Cloud NetApp Volumes 해당 ACL을 개체에 설정하여 기존 ACL을 대체합니다. 파일에 ACL이 없으면 파일의 모드 권한은 OWNER@, GROUP@, EVERYONE@으로부터 계산됩니다. 파일에 기존 SUID/SGID/STICKY 비트가 있는 경우 영향을 받지 않습니다.

GETATTR 작업 중에 클라이언트가 파일에 대한 NFSv4.1 ACL을 받으면 Google Cloud NetApp Volumes 해당 개체와 연결된 NFSv4.1 ACL을 읽고, ACE 목록을 구성한 다음 해당 목록을 클라이언트에 반환합니다. 파일에 NT ACL이나 모드 비트가 있는 경우, 모드 비트에서 ACL이 구성되고 클라이언트로 반환됩니다.

ACL에 DENY ACE가 있으면 액세스가 거부되고, ALLOW ACE가 있으면 액세스가 허용됩니다. 그러나 ACL에 두 ACE가 모두 없는 경우에도 액세스가 거부됩니다.

보안 설명자는 보안 ACL(SACL)과 임의 ACL(DACL)로 구성됩니다. NFSv4.1이 CIFS/SMB와 상호 운용되는 경우 DACL은 NFSv4와 CIFS에 일대일로 매핑됩니다. DACL은 ALLOW와 DENY ACE로 구성됩니다.

기본적인 경우 chmod NFSv4.1 ACL이 설정된 파일이나 폴더에서 실행되면 기존 사용자 및 그룹 ACL은 유지되지만 기본 OWNER@, GROUP@, EVERYONE@ ACL이 수정됩니다.

NFSv4.1 ACL을 사용하는 클라이언트는 시스템의 파일과 디렉토리에 대한 ACL을 설정하고 볼 수 있습니다. ACL이 있는 디렉토리에 새 파일이나 하위 디렉토리가 생성되면 해당 개체는 해당 태그가 지정된 ACL의 모든 ACE를 상속합니다. "상속 플래그" .

파일이나 디렉토리에 NFSv4.1 ACL이 있는 경우, 해당 ACL은 파일이나 디렉토리에 액세스하는 데 사용된 프로토콜에 관계없이 액세스를 제어하는 데 사용됩니다.

파일과 디렉토리는 부모 디렉토리의 NFSv4 ACL에서 ACE를 상속받습니다(적절한 수정이 필요할 수 있음). 단, ACE에 올바른 상속 플래그가 지정되어 있어야 합니다.

NFSv4 요청의 결과로 파일이나 디렉토리가 생성되는 경우, 결과 파일이나 디렉토리의 ACL은 파일 생성 요청에 ACL이 포함되어 있는지 아니면 표준 UNIX 파일 액세스 권한만 포함되어 있는지에 따라 달라집니다. ACL은 상위 디렉토리에 ACL이 있는지 여부에 따라 달라집니다.

NFSv4.1 ACL 권한은 대문자와 소문자로 구성된 일련의 문자 값을 사용합니다(예: rxtncy ) 접근을 제어합니다. 이러한 문자 값에 대한 자세한 내용은 다음을 참조하세요. "방법: NFSv4 ACL 사용" .

"NFSv4 ACL은 ACL 상속을 제공하는 기능을 제공합니다." . ACL 상속은 NFSv4.1 ACL이 설정된 개체 아래에 생성된 파일이나 폴더가 해당 구성에 따라 ACL을 상속할 수 있음을 의미합니다. "ACL 상속 플래그" .

"우마스크"관리자 상호 작용 없이 디렉토리에 파일과 폴더가 생성되는 권한 수준을 제어하는 데 사용됩니다. 기본적으로 Google Cloud NetApp Volumes umask가 상속된 ACL을 재정의할 수 있도록 허용합니다. 이는 예상되는 동작입니다. "RFC 5661" .

NFSv4.1 ACL에는 특정 형식이 있습니다. 다음 예는 파일에 설정된 ACE입니다.

위의 예는 다음의 ACL 형식 지침을 따릅니다.

의 유형 A 허용하다라는 뜻입니다. 이 경우에는 주체가 그룹이 아니고 상속을 포함하지 않기 때문에 상속 플래그가 설정되지 않습니다. 또한 ACE는 AUDIT 항목이 아니므로 감사 플래그를 설정할 필요가 없습니다. NFSv4.1 ACL에 대한 자세한 내용은 다음을 참조하세요. "http://linux.die.net/man/5/nfs4_acl" .

NFSv4.1 ACL이 제대로 설정되지 않은 경우(또는 클라이언트와 서버에서 이름 문자열을 확인할 수 없는 경우) ACL이 예상대로 작동하지 않거나 ACL 변경 사항이 적용되지 않고 오류가 발생할 수 있습니다.

오류의 예는 다음과 같습니다.

NFSv4.1 권한에는 OWNER, GROUP, EVERYONE에 대한 명시적 DENY 속성이 포함될 수 있습니다. 그 이유는 NFSv4.1 ACL이 기본적으로 거부되기 때문입니다. 즉, ACE에서 ACL을 명시적으로 허가하지 않으면 거부됩니다. 명시적 DENY 속성은 명시적이든 아니든 모든 ACCESS ACE보다 우선합니다.

DENY ACE는 속성 태그로 설정됩니다. D .

아래 예에서 GROUP@은 모든 읽기 및 실행 권한이 허용되지만 모든 쓰기 액세스 권한은 거부됩니다.

가능하면 DENY ACE는 피해야 합니다. 혼란스럽고 복잡할 수 있기 때문입니다. 명시적으로 정의되지 않은 ALLOW ACL은 암묵적으로 거부됩니다. DENY ACE가 설정된 경우, 사용자는 액세스 권한이 부여되어야 할 때 액세스가 거부될 수 있습니다.

이전 ACE 세트는 모드 비트에서 755와 동일하며 다음을 의미합니다.

그러나 권한을 775와 동일하게 조정하더라도 EVERYONE에 대한 명시적인 DENY 설정으로 인해 액세스가 거부될 수 있습니다.

NFSv4.1은 ID 도메인 매핑 논리를 보안 계층으로 활용하여 NFSv4.1 마운트에 액세스하려는 사용자가 주장한 사람인지 확인하는 데 도움을 줍니다. 이러한 경우 NFSv4.1 클라이언트에서 제공되는 사용자 이름과 그룹 이름은 이름 문자열을 추가하여 Google Cloud NetApp Volumes 인스턴스로 전송됩니다. 해당 사용자 이름/그룹 이름과 ID 문자열 조합이 일치하지 않으면 사용자 및/또는 그룹은 지정된 기본 nobody 사용자로 압축됩니다. /etc/idmapd.conf 클라이언트의 파일.

이 ID 문자열은 적절한 권한 준수를 위해 필요하며, 특히 NFSv4.1 ACL 및/또는 Kerberos를 사용하는 경우에 필요합니다. 따라서 클라이언트와 Google Cloud NetApp Volumes 간의 일관성을 보장하고 적절한 사용자 및 그룹 이름 ID 확인을 위해 LDAP 서버와 같은 이름 서비스 서버 종속성이 필요합니다.

Google Cloud NetApp Volumes 정적 기본 ID 도메인 이름 값을 사용합니다. defaultv4iddomain.com . NFS 클라이언트는 ID 도메인 이름 설정에 대해 기본적으로 DNS 도메인 이름을 사용하지만 수동으로 ID 도메인 이름을 조정할 수 있습니다. /etc/idmapd.conf .

Google Cloud NetApp Volumes 에서 LDAP가 활성화된 경우, Google Cloud NetApp Volumes NFS ID 도메인을 DNS의 검색 도메인에 구성된 내용으로 자동으로 변경하며, 다른 DNS 도메인 검색 이름을 사용하지 않는 한 클라이언트는 수정할 필요가 없습니다.

Google Cloud NetApp Volumes 로컬 파일이나 LDAP에서 사용자 이름이나 그룹 이름을 확인할 수 있는 경우, 도메인 문자열이 사용되고 일치하지 않는 도메인 ID는 none으로 처리됩니다. Google Cloud NetApp Volumes 로컬 파일이나 LDAP에서 사용자 이름이나 그룹 이름을 찾을 수 없는 경우 숫자 ID 값이 사용되고 NFS 클라이언트가 이름을 올바르게 확인합니다(이는 NFSv3 동작과 유사함).

Google Cloud NetApp Volumes 볼륨이 사용하는 것과 일치하도록 클라이언트의 NFSv4.1 ID 도메인을 변경하지 않으면 다음과 같은 동작이 나타납니다.

다음은 이전 시나리오의 결과를 보여줍니다.

클라이언트와 서버 ID 도메인이 일치하면 동일한 파일 목록이 다음과 같이 표시됩니다.

이 문제와 해결 방법에 대한 자세한 내용은 "섹션"을 참조하세요.NFSv4.1 및 nobody 사용자/그룹 ."

NFS와 함께 Kerberos를 사용하려면 Google Cloud NetApp Volumes 에 다음이 있어야 합니다.

NFSv4.1 구성에서 가장 흔히 나타나는 문제 중 하나는 파일이나 폴더가 목록에 표시되는 경우입니다. ls 소유한 것으로서 user:group 의 조합 nobody:nobody .

예를 들어:

그리고 숫자형 ID는 99 .

어떤 경우에는 파일에 올바른 소유자가 표시될 수 있지만 nobody 그룹으로서.

아무도 아닌 사람은 누구인가?

그만큼 nobody NFSv4.1의 사용자는 다음과 다릅니다. nfsnobody 사용자. NFS 클라이언트가 각 사용자를 어떻게 보는지 보려면 다음을 실행하세요. id 명령:

NFSv4.1을 사용하면 nobody 사용자는 다음에 의해 정의된 기본 사용자입니다. idmapd.conf 파일이며 원하는 사용자로 정의할 수 있습니다.

왜 이런 일이 일어날까요?

이름 문자열 매핑을 통한 보안은 NFSv4.1 작업의 핵심 원칙이므로 이름 문자열이 제대로 일치하지 않을 때의 기본 동작은 해당 사용자를 일반적으로 사용자 및 그룹이 소유한 파일과 폴더에 액세스할 수 없는 사용자에게로 밀어넣는 것입니다.

당신이 볼 때 nobody 파일 목록에 있는 사용자 및/또는 그룹의 경우 이는 일반적으로 NFSv4.1에 잘못 구성된 부분이 있음을 의미합니다. 여기서는 대소문자를 구분하는 것이 중요합니다.

예를 들어, user1@CVSDEMO.LOCAL(uid 1234, gid 1234)이 내보내기에 액세스하는 경우 Google Cloud NetApp Volumes user1@CVSDEMO.LOCAL(uid 1234, gid 1234)을 찾을 수 있어야 합니다. Google Cloud NetApp Volumes 의 사용자가 USER1@CVSDEMO.LOCAL인 경우, 일치하지 않습니다(대문자 USER1 대 소문자 user1). 많은 경우 클라이언트의 메시지 파일에서 다음 내용을 볼 수 있습니다.

클라이언트와 서버는 모두 사용자가 주장하는 사람인지에 동의해야 하므로 클라이언트가 보는 사용자가 Google Cloud NetApp Volumes 보는 사용자와 동일한 정보를 가지고 있는지 확인하려면 다음 사항을 확인해야 합니다.

거의 모든 경우에, 당신이 본다면 nobody 클라이언트의 사용자 및 그룹 목록에서 문제는 Google Cloud NetApp Volumes 와 NFS 클라이언트 간의 사용자 또는 그룹 이름 도메인 ID 변환입니다. 이러한 시나리오를 방지하려면 LDAP를 사용하여 클라이언트와 Google Cloud NetApp Volumes 간의 사용자 및 그룹 정보를 확인하세요.

NFSv4.1을 사용하는 경우 이전에 설명한 대로 NFS 작업 중에 이름-문자열 매핑이 수행됩니다.

사용하는 것 외에도 /var/log/messages NFSv4 ID 문제를 찾으려면 다음을 사용할 수 있습니다. "nfsidmap -l" NFS 클라이언트에서 명령을 실행하여 NFSv4 도메인에 올바르게 매핑된 사용자 이름을 확인합니다.

예를 들어, 이는 클라이언트에서 찾을 수 있는 사용자와 Google Cloud NetApp Volumes NFSv4.x 마운트에 액세스한 후의 명령 출력입니다.

NFSv4.1 ID 도메인에 제대로 매핑되지 않은 사용자(이 경우, netapp-user ) 동일한 마운트에 접근하려고 시도하고 파일을 터치하면 할당됩니다. nobody:nobody 예상대로.

그만큼 nfsidmap -l 출력은 사용자를 보여줍니다 pcuser 디스플레이에는 있지만 netapp-user ; 이것은 우리의 수출 정책 규칙에 있는 익명 사용자입니다.(65534 ).