Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
SMB и NFS используют различные модели разрешений для доступа пользователей и групп. В результате том Azure NetApp File должен быть настроен так, чтобы соответствовать требуемой модели разрешений для доступа по протоколу. Для сред, доступных только для NFS, решение является простым — используйте стили безопасности UNIX. Для сред, доступных только для SMB, используйте стили безопасности NTFS.
Если требуется NFS и SMB в одном наборе данных (двойной протокол), необходимо принять решение на основе двух вопросов:
- Какой протокол будет управлять разрешениями пользователей в большинстве случаев?
- Что такое требуемая конечная точка управления разрешениями? Другими словами, пользователям требуется возможность управлять разрешениями от клиентов NFS или клиентов Windows? Или оба?
Стили безопасности томов действительно можно рассматривать как стили разрешений, где нужный стиль управления ACL является определяющим фактором.
Примечание.
Стили безопасности выбираются при создании тома. После выбора стиля безопасности его нельзя изменить.
Информация о стилях безопасности файловых томов Azure NetApp Files
Существует два основных варианта для стилей безопасности томов в Azure NetApp Files:
UNIX — стиль безопасности UNIX предоставляет разрешения в стиле UNIX, такие как базовые биты режима POSIX (владелец/группа/все пользователи с стандартными разрешениями на чтение/запись/выполнение, например 0755) и ACL на базе NFSv4.x. Списки управления доступом POSIX не поддерживаются.
NTFS — стиль безопасности NTFS предоставляет идентичные функциональные возможности, как стандартные разрешения WINDOWS NTFS, с детализированными пользователями и группами в списках управления доступом и подробными разрешениями на безопасность и аудит.
В среде NAS с двумя протоколами только один стиль разрешений безопасности может быть активным. Прежде чем выбрать один из них, следует оценить рекомендации по каждому стилю безопасности.
| Стиль безопасности | Соображения |
|---|---|
| ЮНИКС | — Клиенты Windows могут задавать только атрибуты разрешений UNIX через SMB, которые сопоставляются с атрибутами 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 | В основном SMB | Потребность в детализированной безопасности |
|---|---|---|---|
| ЮНИКС | X | - | X (с использованием списков управления доступом NFSv4.x) |
| NTFS | - | X | X |
Как работает сопоставление имен в Azure NetApp Files
В Azure NetApp Files только пользователи проходят проверку подлинности и сопоставляются. Группы не сопоставляются. Вместо этого членство в группах определяется с помощью удостоверения пользователя.
Когда пользователь пытается получить доступ к тому Azure NetApp Files, его идентификатор передается службе. Это удостоверение включает имя пользователя и уникальный числовый идентификатор (идентификатор UID для NFSv3, строку имени для NFSv4.1, SID для SMB). Azure NetApp Files использует это удостоверение для аутентификации в настроенной службе имен, чтобы подтвердить личность пользователя.
- Поиск числовых идентификаторов LDAP используется для поиска имени пользователя в Active Directory.
- Строки имен используют поиск LDAP, чтобы найти имя пользователя, а клиент и сервер обращаются к заданному домену идентификатора для NFSv4.1, чтобы убедиться в соответствии.
- Пользователи в Windows опрашиваются с использованием стандартных вызовов Windows RPC в Active Directory.
- Членства в группах также проверяются, и все добавляется в кэш учетных данных для ускорения обработки последующих запросов к тому.
- В настоящее время пользовательские локальные пользователи не поддерживаются для использования с Azure NetApp Files. Только пользователи из Active Directory могут быть использованы с двумя протоколами.
- В настоящее время единственными локальными пользователями, которых можно использовать с томами двойного протокола, являются root и пользователь
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 по умолчанию с числовым UID 65534, чтобы разрешить первоначальную проверку подлинности для подключений SMB. После этого разрешения файлов и папок будут управлять доступом. Так как 65534 обычно соответствует nfsnobody пользователю, доступ ограничен в большинстве случаев. И наоборот, клиенту NFS нужно использовать сопоставление имен от UNIX к Windows только в том случае, если используется стиль безопасности NTFS. В Azure NetApp Files нет пользователя Windows по умолчанию. Таким образом, если допустимый пользователь Windows, соответствующий запрашиваемому имени, не будет найден, доступ будет отклонен.
В следующей таблице приводятся различные пермутации сопоставлений имен и их поведение в зависимости от используемого протокола.
| Протокол | Стиль безопасности | Ориентация сопоставления имён | Применяемые разрешения |
|---|---|---|---|
| Малый и средний бизнес (SMB) | ЮНИКС | От Windows к UNIX | ЮНИКС (битовые режимы или списки управления доступом NFSv4.x) |
| Малый и средний бизнес (SMB) | NTFS | От Windows к UNIX | Списки управления доступом NTFS (на основе SID Windows для доступа к общему ресурсу) |
| NFSv3 | ЮНИКС | Отсутствует | ЮНИКС (mode-bits или NFSv4.x ACLs*) |
| NFSv4.x | ЮНИКС | Числовой идентификатор имени пользователя UNIX | ЮНИКС (битовые режимы или списки управления доступом NFSv4.x) |
| NFS3/4.x | NTFS | От UNIX к Windows | Списки управления доступом NTFS (на основе сопоставленного идентификатора безопасности (SID) пользователя Windows) |
Примечание.
Правила сопоставления имен в Azure NetApp Files в настоящее время можно контролировать только с помощью LDAP. В службе нет возможности создавать явные правила сопоставления имен.
Службы именования с томами с поддержкой двух протоколов
Независимо от того, какой протокол NAS используется, тома двойного протокола используют концепции сопоставления имен для правильной обработки разрешений. Таким образом, службы имен играют важную роль в обслуживании функциональных возможностей в средах, использующих SMB и NFS для доступа к томам.
Службы имен служат источниками удостоверений для пользователей и групп, обращаюющихся к томам NAS. Эта операция включает Active Directory, которая может выступать в качестве источника для пользователей и групп Windows и UNIX, использующих как стандартные доменные службы, так и функции LDAP.
Службы имен не являются жестким требованием, но настоятельно рекомендуется для томов двойного протокола Azure NetApp Files. В службе отсутствует концепция создания локальных пользователей и групп. Таким образом, чтобы иметь правильную проверку подлинности и точную информацию о пользователе и владельце группы в протоколах, LDAP является необходимостью. Если у вас есть только несколько пользователей, и вам не нужно заполнять точные сведения об удостоверениях пользователей и групп, рассмотрите возможность использования функции разрешения локальных пользователей NFS с LDAP для доступа к функциональным возможностям тома с двумя протоколами. Помните, что включение этой функции отключает расширенные функции группы.
Когда клиенты, службы имен и хранилище находятся в разных областях
В некоторых случаях клиенты NAS могут жить в сегментированной сети с несколькими интерфейсами, имеющими изолированные подключения к службам хранилища и имен.
Один из таких примеров: ваше хранилище находится в Azure NetApp Files, а клиенты NAS и доменные службы находятся в локальной среде (например, центрально-лучевой архитектуре в Azure). В этих сценариях необходимо предоставить сетевой доступ как к клиентам NAS, так и к службам имен.
На следующем рисунке показан пример такой конфигурации.
