SMB, NFS 및 컨테이너 액세스를 위한 홈 NAS ACL 감사 체크리스트

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

안전한 접근 방식은 ID, 유효 권한, 모든 접근 경로의 상속을 매핑하는 증거 우선 ACL 감사를 단일 명령이 아니라 관찰 가능한 게이트의 순서로 다루는 것입니다.

홈 NAS에서 공유 데이터를 SMB, NFS, 컨테이너로 내보낼 때 실질적인 위험은 동일한 NAS 경로가 SMB, NFS, 컨테이너 바인드 마운트를 통해 서로 다른 유효 접근 권한을 부여하는 것입니다. 현재 ID와 복구 지점을 기록하고, 영향이 가장 적은 판별 작업부터 시작하며, 다른 변수를 변경하기 전에 통과 및 실패 결과를 해석하고, 스토리지가 불안정해지거나 복구 가능한 유일한 사본이 노출될 상황이면 중단하십시오. 아래 워크플로는 원래 워크로드가 성공하거나 증거가 에스컬레이션 경계에 도달한 후에만 종료됩니다.

권한 상태를 고정하고 모든 ID 매핑하기

대표 공유 하나를 선택하고 해당 데이터셋 또는 파일 시스템, 내보내기 이름, SMB 공유 정의, NFS 내보내기, 컨테이너 바인드 마운트 및 현재 소유권을 기록하십시오. NAS와 각 컨테이너 내부에서 숫자 UID 및 GID 값을 캡처하십시오. 사용자 이름이 일치한다는 사실만으로 기본 ID가 일치한다고 볼 수는 없습니다.

POSIX ACL에는 이름이 지정된 사용자, 이름이 지정된 그룹, 기본 항목 및 유효 권한을 제한할 수 있는 마스크가 추가됩니다. POSIX ACL 마스크 동작은 getfacl에 표시된 마스크 때문에 겉보기에는 넉넉한 항목이 더 좁게 적용될 수 있는 이유를 설명하며, 명령줄 보기와 SMB 또는 NFS 동작을 비교할 때 필수적입니다.

인벤토리 작업 중에는 재귀적 chmod, chown 또는 ACL 교체를 실행하지 마십시오. 먼저 getfacl -p 출력과 서비스 설정을 저장하십시오. 모든 클라이언트 ID를 숫자로 된 서버 측 ID에 연결하거나 명시적으로 매핑되지 않은 것으로 표시했다면 기준선 검증을 통과한 것입니다.

각 프로토콜을 통한 유효 접근 테스트

공유 아래에 전용 감사 사용자와 임시 디렉터리를 만드십시오. Windows 또는 macOS에서는 SMB를 통해, Linux NFS 클라이언트에서는 NFS를 통해, 대상 컨테이너에서는 직접 목록 조회, 읽기, 생성, 이름 변경, 삭제를 각각 테스트하십시오. 각 작업 후 소유자, 그룹, 모드, ACL 및 사용한 프로토콜을 기록하십시오.

인증과 파일 시스템 권한 부여를 구분하십시오. SMB 로그인이 성공해도 매핑된 Unix ID에 쓰기 권한이 없을 수 있고, NFS 클라이언트가 서버에서 허용되지만 잘못된 로컬 소유자로 해석되는 숫자 ID를 제시할 수 있습니다. 테스트 사이에는 ID 또는 ACL 변수 하나만 변경하십시오.

관찰된 권한이 의도한 접근 매트릭스와 일치하고 새로 생성된 파일에 예상한 소유자, 그룹 및 기본 ACL이 적용될 때만 경로가 통과합니다. 한 프로토콜이 다르게 동작하면 광범위한 변경을 중단하고 공유 파일 시스템을 건드리기 전에 해당 프로토콜의 매핑 계층을 추적하십시오.

상속, 마스크 및 컨테이너 매핑 검사

상위 디렉터리의 기본 ACL과 새로 생성된 파일 및 디렉터리의 접근 ACL을 비교하십시오. 그룹 변경 후 ACL 마스크를 확인하고, SMB 서비스가 생성 또는 디렉터리 마스크를 적용하는지 확인하며, 파일을 제자리에서 수정하지 않고 원자적으로 교체하는 애플리케이션을 식별하십시오. 교체 작업은 제자리 수정과 다른 상속 결과를 만들 수 있습니다.

컨테이너의 경우 런타임 사용자, 보조 그룹, 사용자 네임스페이스 재매핑 및 바인드 마운트된 호스트 경로를 검사하십시오. 네트워크 마운트된 Docker 볼륨의 데이터베이스 접근에 관한 관련 ZimaSpace 가이드는 NFSv4 이름 매핑이 실패 계층일 때 유용합니다. 이 감사는 세 경로 전체에서 종단 간 권한을 입증하는 데 초점을 둡니다.

애플리케이션을 root로 실행하여 매핑 문제를 해결하려 하지 마십시오. 컨테이너가 임시 파일을 생성할 수 없다면 NAS 정책에 맞게 지원되는 UID, GID 또는 보조 그룹을 조정하고, 운영 트리를 변경하기 전에 동일한 테스트를 반복하십시오.

가장 범위가 좁은 수정 적용 및 증거 보존

한 번에 한 계층씩 수정하십시오. 먼저 ID 매핑, 다음으로 그룹 구성원 자격, 그다음 상속된 기본값, 마지막으로 예외적인 파일 ACL 순서로 진행합니다. 임시 디렉터리에 변경 사항을 적용하고 모든 작업을 다시 확인한 후, 저장된 롤백 ACL과 함께 운영 하위 트리에 범위가 제한된 변경을 준비하십시오.

배포 후에는 자격 증명을 캐시하는 클라이언트를 재시작하거나 다시 연결하고, 필요한 경우 NFS를 다시 마운트하며, 프로세스 시작 시 그룹 목록이 고정되는 컨테이너만 재시작하십시오. 동일한 테스트 매트릭스를 반복하고 기존 파일과 새 파일이 모두 의도한 대로 동작하는지 확인하십시오.

허용 및 거부된 모든 작업이 문서화된 매트릭스와 일치하고, 새 객체가 올바르게 상속되며, 저장된 ACL로 이전 상태를 복원할 수 있을 때 감사가 종료됩니다. 소유권이 의도적으로 혼합되어 있거나, 스냅샷 또는 하드 링크로 인해 롤백이 복잡하거나, NAS 스토리지에서 오류가 보고될 때는 무작정 재귀 작업을 수행하지 말고 에스컬레이션하십시오.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.