Общие сведения о стиле безопасности и поведении разрешений с двумя протоколами в Azure NetApp Files

Статья
10/24/2023

S МБ и NFS используют различные модели разрешений для доступа пользователей и групп. В результате том Azure NetApp File должен быть настроен для учета требуемой модели разрешений для доступа к протоколу. Для сред, доступных только для NFS, решение является простым — используйте стили безопасности UNIX. Для сред, доступных только для S МБ, используйте стили безопасности NTFS.

Если требуется NFS и S МБ в одинаковых наборах данных (двойной протокол), решение должно быть принято на основе двух вопросов:

Какой протокол будет управлять разрешениями пользователей в большинстве случаев?
Что такое требуемая конечная точка управления разрешениями? Другими словами, пользователям требуется возможность управлять разрешениями от клиентов NFS или клиентов Windows? Или и то, и другое?

Стили безопасности томов действительно можно рассматривать как стили разрешений, где нужный стиль управления ACL является определяющим фактором.

Примечание.

Стили безопасности выбираются при создании тома. После выбора стиля безопасности его нельзя изменить.

Сведения о стилях безопасности томов Azure NetApp Files

Существует два основных варианта для стилей безопасности томов в Azure NetApp Files:

UNIX — стиль безопасности UNIX предоставляет разрешения в стиле UNIX, такие как базовые биты режима POSIX (владелец/ группа/все доступ с стандартными разрешениями на чтение и запись и выполнение, например 0755) и NFSv4.x. Списки ACL POSIX не поддерживаются.

NTFS — стиль безопасности NTFS предоставляет идентичные функциональные возможности, как стандартные разрешения WINDOWS NTFS, с детализированными пользователями и группами в списках управления доступом и подробными разрешениями на безопасность и аудит.

В среде NAS с двумя протоколами только один стиль разрешений безопасности может быть активным. Прежде чем выбрать один из них, следует оценить рекомендации по каждому стилю безопасности.

Стиль безопасности Рекомендации

UNIX — Клиенты Windows могут задавать только атрибуты разрешений UNIX через S МБ, которые сопоставляются с атрибутами UNIX (только чтение и запись и выполнение; специальные разрешения не выполняются).
— списки ACL NFSv4.x не имеют управления графическим интерфейсом. Управление выполняется только с помощью интерфейса командной строки с помощью nfs4_getfacl и nfs4_setfacl команд.
— Если файл или папка содержит списки управления доступом NFSv4.x, вкладка свойств безопасности Windows не может отобразить их.

NTFS — Клиенты UNIX не могут задавать атрибуты через NFS с помощью таких команд, как chown/chmod.
— клиенты NFS отображают только приблизительные разрешения NTFS при использовании ls команд. Например, если у пользователя есть разрешение в ACL WINDOWS NTFS, который не может быть чисто преобразован в бит режима POSIX (например, в каталог обхода), он преобразуется в ближайшее значение режима POSIX (например 1 , для выполнения).

Стиль безопасности	Рекомендации
UNIX	— Клиенты Windows могут задавать только атрибуты разрешений UNIX через S МБ, которые сопоставляются с атрибутами UNIX (только чтение и запись и выполнение; специальные разрешения не выполняются). — списки ACL NFSv4.x не имеют управления графическим интерфейсом. Управление выполняется только с помощью интерфейса командной строки с помощью nfs4_getfacl и nfs4_setfacl команд. — Если файл или папка содержит списки управления доступом NFSv4.x, вкладка свойств безопасности Windows не может отобразить их.
NTFS	— Клиенты UNIX не могут задавать атрибуты через NFS с помощью таких команд, как `chown/chmod`. — клиенты NFS отображают только приблизительные разрешения NTFS при использовании `ls` команд. Например, если у пользователя есть разрешение в ACL WINDOWS NTFS, который не может быть чисто преобразован в бит режима POSIX (например, в каталог обхода), он преобразуется в ближайшее значение режима POSIX (например `1` , для выполнения).

Выбор стиля безопасности тома определяет, как выполняется сопоставление имен для пользователя. Эта операция является основной частью того, как тома двойного протокола поддерживают прогнозируемые разрешения независимо от используемого протокола.

Используйте следующую таблицу в качестве матрицы принятия решений для выбора соответствующих стилей безопасности томов.

Стиль безопасности	В основном NFS	В основном S МБ	Потребность в детализированной безопасности
UNIX	X	-	X (использование списков управления доступом NFSv4.x)
NTFS	-	X	X

Как работает сопоставление имен в Azure NetApp Files

В Azure NetApp Files только пользователи проходят проверку подлинности и сопоставляются. Группы не сопоставляются. Вместо этого членство в группах определяется с помощью удостоверения пользователя.

Когда пользователь пытается получить доступ к тому Azure NetApp Files, попытка передачи удостоверения в службу. Это удостоверение включает имя пользователя и уникальный числовый идентификатор (номер UID для NFSv3, строка имени для NFSv4.1, SID для S МБ). Azure NetApp Files использует это удостоверение для проверки подлинности в настроенной службе имен для проверки удостоверения пользователя.

Поиск числовых идентификаторов LDAP используется для поиска имени пользователя в Active Directory.
Строки имен используют поиск LDAP для поиска имени пользователя и клиента и сервера, чтобы убедиться в соответствии с заданным доменом идентификатора для NFSv4.1 .
Пользователи Windows запрашиваются с помощью стандартных вызовов Windows RPC к Active Directory.
Членства в группах также запрашиваются, и все добавляется в кэш учетных данных для ускорения обработки последующих запросов к тому.
В настоящее время пользовательские локальные пользователи не поддерживаются для использования с Azure NetApp Files. С двумя протоколами можно использовать только пользователей в Active Directory.
В настоящее время единственные локальные пользователи, которые можно использовать с томами двойного протокола, являются корневыми и пользователем nfsnobody .

После проверки подлинности и проверки имени пользователя Azure NetApp Files следующим шагом является сопоставление имен пользователей для взаимодействия с UNIX и Windows.

Стиль безопасности тома определяет, как выполняется сопоставление имен в Azure NetApp Files. Семантика разрешений Windows и UNIX отличаются. Если сопоставление имен не удается выполнить, проверка подлинности завершается ошибкой, а доступ к тому от клиента запрещен. Распространенный сценарий, когда эта ситуация возникает при попытке доступа NFSv3 к тому с помощью стиля безопасности NTFS. Первоначальный запрос доступа из NFSv3 поставляется в Azure NetApp Files в качестве числового пользовательского интерфейса. Если пользователь user1 с числовым идентификатором 1001 пытается получить доступ к подключению NFSv3, запрос проверки подлинности поступает в виде числового идентификатора 1001. Затем Azure NetApp Files принимает числовый идентификатор 1001 и пытается разрешить 1001 имя пользователя. Это имя пользователя требуется для сопоставления с допустимым пользователем Windows, так как разрешения NTFS на томе будут содержать имена пользователей Windows вместо числового идентификатора. Azure NetApp Files будет использовать настроенный сервер службы имен (LDAP) для поиска имени пользователя. Если имя пользователя не удается найти, проверка подлинности завершается ошибкой и доступ запрещен. Эта операция выполняется путем разработки, чтобы предотвратить нежелательный доступ к файлам и папкам.

Сопоставление имен на основе стиля безопасности

Направление сопоставления имен в Azure NetApp Files (Windows с UNIX или UNIX в Windows) зависит не только от используемого протокола, но и стиля безопасности тома. Клиенту Windows всегда требуется сопоставление имен Windows с UNIX, чтобы разрешить доступ, но не всегда требуется соответствующее имя пользователя UNIX. Если в настроенном сервере службы имен нет допустимого имени UNIX, Azure NetApp Files предоставляет резервный пользователь UNIX по умолчанию с числовым пользовательским идентификатором пользовательского 65534 интерфейса, чтобы разрешить начальную проверку подлинности для подключений S МБ. После этого разрешения файлов и папок будут управлять доступом. Так как 65534 обычно соответствует nfsnobody пользователю, доступ ограничен в большинстве случаев. И наоборот, клиенту NFS нужно использовать сопоставление имен от UNIX к Windows только в том случае, если используется стиль безопасности NTFS. В Azure NetApp Files нет пользователя Windows по умолчанию. Таким образом, если допустимый пользователь Windows, соответствующий запрашиваемой имени, не удается найти, доступ будет отклонен.

В следующей таблице описаны различные перемутации сопоставлений имен и их поведение в зависимости от используемого протокола.

Протокол	Стиль безопасности	Направление сопоставления имен	Применяемые разрешения
SMB	UNIX	От Windows к UNIX	UNIX (списки управления доступом в режиме или NFSv4.x)
SMB	NTFS	От Windows к UNIX	Списки управления доступом NTFS (на основе общего ресурса доступа к идентификатору безопасности Windows)
NFSv3	UNIX	нет	UNIX (a mode-bits or NFSv4.x ACLs*)
NFSv4.x	UNIX	Числовой идентификатор имени пользователя UNIX	UNIX (списки управления доступом в режиме или NFSv4.x)
NFS3/4.x	NTFS	От UNIX к Windows	Списки управления доступом NTFS (на основе сопоставленного идентификатора безопасности пользователя Windows)

Примечание.

Правила сопоставления имен в Azure NetApp Files в настоящее время можно контролировать только с помощью LDAP. В службе нет возможности создавать явные правила сопоставления имен.

Службы имен с томами двойного протокола

Независимо от того, какой протокол NAS используется, тома двойного протокола используют концепции сопоставления имен для правильной обработки разрешений. Таким образом, службы имен играют важную роль в поддержании функциональности в средах, использующих как S МБ, так и NFS для доступа к томам.

Службы имен служат источниками удостоверений для пользователей и групп, обращаюющихся к томам NAS. Эта операция включает Active Directory, которая может выступать в качестве источника для пользователей и групп Windows и UNIX, использующих как стандартные доменные службы, так и функции LDAP.

Службы имен не являются жестким требованием, но настоятельно рекомендуется для томов двойного протокола Azure NetApp Files. В службе нет концепции создания пользовательских локальных пользователей и групп. Таким образом, чтобы иметь правильную проверку подлинности и точную информацию о пользователе и владельце группы в протоколах, LDAP является необходимостью. Если у вас есть только несколько пользователей, и вам не нужно заполнять точные сведения об удостоверениях пользователей и групп, рассмотрите возможность использования функции разрешения локальных пользователей NFS с LDAP для доступа к функциональным возможностям тома с двумя протоколами. Помните, что включение этой функции отключает расширенные функции группы.

Когда клиенты, службы имен и хранилище находятся в разных областях

В некоторых случаях клиенты NAS могут жить в сегментированной сети с несколькими интерфейсами, имеющими изолированные подключения к службам хранилища и имен.

Один из таких примеров заключается в том, что хранилище находится в Azure NetApp Files, а клиенты NAS и доменные службы находятся в локальной среде (например , центральной архитектуре в Azure). В этих сценариях необходимо предоставить сетевой доступ как к клиентам NAS, так и к службам имен.

На следующем рисунке показан пример такой конфигурации.

Share via