Безопасность кластера

Настройка шифрования сообщений

Основные этапы конфигурирования:

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

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

stopsrc -s clcomdes
	startsrc -s clcomdes

перейдите в SMIT HACMP Cluster Security (Безопасность кластера HACMP); выполните smit cm_config_security;(рис 9.1) Включение автоматического распространения ключей

перейдите в SMIT HACMP Cluster Security (Безопасность кластера HACMP): выполните smit cm_config_security.(рис 9.2) Конфигурирование режима аутентификации сообщений

Нажмите Enter.(рис 9.3) Генерирование ключаЕсли выбрано автоматическое распространение ключей, то следует перейти к ша гу 5, "Активизация ключа". Теперь скопируйте файл ключа с этого узла на другие узлы. Можно использовать любой метод передачи, но мы рекомендуем применять один из следующих способов:

scp /usr/es/sbin/cluster/etc/key_md5_aes \
node2:/usr/es/sbin/cluster/etc/key_md5_aes

Повторите эти действия на всех узлах.

Изменение ключа аутентификации

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

Устранение неполадок аутентификации и шифрования сообщений

При возникновении ошибок коммуникации кластера (например, при отказе верификации кластера или если C-SPOC не может связаться с другими узлами) следует отключить и аутентификацию сообщений и шифрование сообщений:

Проверка текущих параметров аутентификации сообщений

Текущие параметры аутентификации и шифрования сообщений можно проверить следующим образом:

Запустите smit hacmp.

Выберите Extended Configuration (Расширенное конфигурирование).

Выберите Extended Topology Configuration (Расширенное конфигурирование топологии).(рис 9.4) Проверка параметров аутентификации сообщений

Выберите Show HACMP Topology (Отображение топологии HACMP).

Выберите Show Cluster Definition (Отображение определения кластера). Нажмите Enter для вывода параметров определения кластера (рис. 9.4).

Защищенное удаленное выполнение команд в HACMP

Скрипты запуска и остановки приложений, настраиваемые скрипты обработки событий и прочие скрипты могут требовать выполнения команд на удаленных узлах. Для этой цели все еще можно использовать rsh, однако это небезопасно, так как при этом аутентификация основана на файле .rhosts. Мы настоятельно рекомендуем использовать Secure Shell (SSH). Кроме того, функционирование DLPAR также требует применения SSH.

SSH и Secure Socket Layer (SSL) совместно обеспечивают аутентификацию, конфиденциальность и целостность данных. Аутентификация SSH основана на инфраструктуре открытых-закрытых ключейБолее распространен термин "Public Key Infrastructure, PKI" (инфраструктура открытых ключей), наличие закрытого (private) ключа подразумевается. , тогда как SSL осуществляет шифрование сетевого трафика.

SSH содержит следующие утилиты, заменяющие классические r-команды:

ssh защищенная удаленная оболочка, подобная rsh или rlogin;
scp защищенное удаленное копирование, подобное rcp;
sftp утилита зашифрованной передачи файлов, подобная ftp.

Установка SSH

Весьма удобно, что IBM поставляет SSH и все его компоненты вместе с AIX. Ниже приведен список требуемых компонентов.

Другой вариант состоит в том, чтобы скопировать наиболее актуальные пакеты из Интернета:

rpm -i openssl-0.9.6m-1.aix5.1.ppc.rpm

Настройка SSH для удаленного выполнения команд без пароля

Некоторые скрипты могут требовать использования SSH и SCP в конфигурации без применения паролей. В этом случае SSH использует пары открытых и закрытых ключей для аутентификации. Закрытый ключ хранится на локальном хосте, тогда как открытый ключ пересылается на удаленные узлы и добавляются в их базу данных авторизованных ключей.

При выполнении команды SSH (например, ssh node2 date ) коммуникация подписывается с использованием закрытого или секретного ключа узла-источника. Эту подпись можно дешифровать только с применением открытого ключа узла-источника. Если узел-получатель может успешно дешифровать подпись, это подтверждает подлинность узла-отправителя.

Для настройки удаленного выполнения команд через SSH без паролей следует выполнить следующие действия на всех узлах кластера:

ssh-keygen -t rsa -f ~/.ssh/node1

mv ~/.ssh/node1 ~/.ssh/identity

cat ~/.ssh/node1.pub >> ~/.ssh/authorized_keys

scp ~/.ssh/node1.pub nodeX:~/.ssh/node1.pub

ssh nodeX "cat ~/.ssh/node1.pub >> ~/.ssh/authorized_keys"

Теперь SSH должен работать на всех узлах не запрашивая пароль.

Дополнительные сведения об OpenSSL и OpenSSH можно найти в Интернете:

Безопасность WebSmit

WebSMIT является очень хорошим инструментом конфигурирования и мониторинга кластера. Однако WebSMIT осуществляет доступ к файлам HACMP и выполняет команды кластера под учетной записью пользователя root. Это является потенциально уязвимым местом в безопасности, однако при тщательном планировании и реализации безопасности риск можно полностью устранить. Этот раздел описывает требования безопасности и механизмы, используемые в средах WebSMIT.

Для обеспечения максимальной безопасности WebSMIT можно выполнить конфигурирование следующих элементов:

Для аутентификации WebSMIT требует SSL и SSL-сертификат. При установке Apache генерируется самоподписанный (self-signed) сертификат, который можно использовать в WebSMIT.

Параметры безопасности WebSMIT

Параметры безопасности WebSMIT хранятся в файле /usr/es/sbin/cluster/wsm/ wsm_smit.conf. По умолчанию файл содержит максимальные установки параметров безопасности. В этом разделе описываются опции безопасности.

Авторизованный порт

Параметр AUTHORIZED_PORT представляет порт TCP, используемый для коммуникаций WebSMIT. По умолчанию применяется порт 42267. Рекомендуем изменить значение этого параметра на другой номер, чтобы не допустить доступа неавторизованного пользователя к WebSMIT через стандартный порт. Если определить номер порта здесь, то WebSMIT будет использовать тот протокол (http или https), который связан с этим портом в файле конфигурации HTTP-сервера. Например, если определить порт 42267 в качестве порта SSL в файле httpd.conf, то браузер будет использовать шифрование и в URL нужно будет применять "https://".

Принудительное использование защищенного http

Параметр REDIRECT_TO_HTTPS=1 позволяет использовать только защищенные https-коммуникации, чтобы все данные передавались по сети в зашифрованном виде. Если был определен параметр AUTHORIZED_PORT, то эта переменная не применяется. В противном случае будет выполнено перенаправление браузера на порт SSL вне зависимости от введенного URL. Отношение между параметрами AUTHORIZED_ PORT и REDIRECT_TO_HTTPS см. в табл. 9.1.

Аутентификация AIX

WebSMIT может применять аутентификацию AIX вдобавок к аутентификации веб-сервера путем установки параметра REQUIRE_AUTHENTICATION=1. В этом случае WebSMIT запрашивает имя и пароль пользователя AIX. Так как при этом используются механизмы аутентификации AIX, отказы при входе в систему могут вызвать блокирование учетной записи.

Допустимые пользователи

Переменная ACCEPTED_USERS содержит список идентификаторов пользователей AIX, которым разрешен доступ к WebSMIT. Все пользователи, указанные в этой переменной, будут иметь в WebSMIT уровень привилегий пользователя root. По умолчанию задано значение ACCEPTED_USERS="root".

Тайм-аут сеанса

Переменная SESSION_TIMEOUT определяет значение тайм-аута сеанса, по истечении которого пользователь WebSMIT должен выполнить повторный вход в систему вне зависимости от того, активен он или нет. По умолчанию задан тайм-аут в 20 мин.

Идентификатор пользователя веб-сервера

Переменная REQUIRED_WEBSERVER_UID содержит идентификатор пользователя, используемый в скриптах cgi-bin в WebSMIT. Здесь должен указываться тот же идентификатор, который применяется и в веб-сервере. Кроме того, следует убедиться в том, что этот идентификатор пользователя не имеет привилегий входа в AIX, чтобы никто не мог переключиться в эту учетную запись. По умолчанию употребляется учетная запись "nobody".

Разрешение или запрет на доступ к определенным панелям SMIT в WebSMIT

Можно сконфигурировать, к каким панелям SMIT можно получить доступ через WebSMIT. В качестве имени панели SMIT применяется быстрый путь SMIT к заданной панели; вывод этого имени выполняется нажатием F8 в SMIT (рис. 9.5). Например, панель SMIT Extended Topology Configuration (Расширенное конфигурирование топологии) имеет имя "cm_extended_topology_config_menu_dmn".Файл /usr/es/sbin/cluster/ wsm/wsm_smit.allow содержит список панелей SMIT, к которым разрешен доступ из WebSMIT. Ко всем остальным панелям доступ запрещен.

В файле /usr/es/sbin/cluster/wsm/wsm_smit.deny можно перечислить панели SMIT, недоступные из WebSMIT. Если панель задана и в .allow- и в .deny-файле, приоритет имеет указание в .deny-файле.

Если панель SMIT указана в файле /usr/es/sbin/cluster/wsm/wsm_smit.redirect, WebSMIT выполняет перенаправление страницы на заданный URL. Этот файл уже содержит некоторые панели, которые не следует изменять.

#################################
# webSMIT  .allow file		#
#################################
cm_hacmp_main_menu_dmn

Журналы WebSMIT

WebSMIT регистрирует все свои операции в журналах, подобно SMIT. Файл wsm_ smit.log расположен в каталоге ../log относительно скриптов cgi-bin. Например, при использовании скриптов cgi-bin из заданного по умолчанию каталога /usr/es/sbin/ cluster/wsm/cgi-bin файл журнала находится в каталоге /usr/es/sbin/cluster/wsm/log. Кроме того, в файл wsm_smit.script записывается последняя команда WebSMIT. HACMP не осуществляет управление этими файлами журналов, они могут неограниченно расти, подобно файлу smit.log. Команда snap -e может осуществлять сбор файлов журналов WebSMIT, только если они находятся каталоге по умолчанию /usr/ es/sbin/cluster/wsm/log.

HACMP и брандмауэры

При размещении кластера HACMP за брандмауэром следует учитывать следующие аспекты:

Безопасность RSCT

В этой лекции описывается терминология и понятия, используемые в безопасности RSCT. Также описывается архитектура безопасности RSCT и механизмы, используемые в HACMP. Предполагается, что у вас есть знание RSCT и его базовых компонентов (таких, как RMC, диспетчеры ресурсов и т. д.). Важно понимать, что основная часть компонентов и механизмов, описанных в этой главе, не нуждается в конфигурировании; уровень безопасности RSCT работает сразу же. Кроме того, конфигурирование некоторых функций и файлов выполняется только после настройки аутентификации и шифрования сообщений HACMP (см. раздел 9.2, "Использование зашифрованных межузловых коммуникаций"). Некоторые из описанных функций не применяются в HACMP, но являются неотъемлемой частью безопасности RSCT.

RSCT и HACMP

HACMP использует RSCT в качестве уровня базовой инфраструктуры. Узлы HACMP связываются с одноранговыми узлами через компоненты RSCT, проверяя их состояние или запрашивая доступ к их ресурсам. Службы топологии (Topology Services) и службы групп (Group Services) реализуют мониторинг пульса HACMP через одноранговый домен RSCT. Подсистема RMC применяется для следующего:

На рис. 9.6 показана связь между компонентами HACMP и RSCT.

Каждый раз, когда компонент HACMP (например, диспетчер кластера) одного сервера отправляет функциональный запрос к ресурсу RMC (локальному или уда(рис 9.7) RSCT и HACMP(рис 9.6) Обзор базовых коммуникаций кластераленному), вызывается подсистема RSCT и запросы отправляются на узел, на котором находится ресурс. (рис. 9.7).

Так как удаленные подключения представляют собой подключения сокетов TCP/ IP, их необходимо защищать, чтобы обеспечить подлинность запрашивающего узла и серверного узла в кластере. Здесь в действие вступают службы безопасности кластера (Cluster Security Services, CtSec).

Между узлами кластера осуществляется связь типа "клиент-сервер". В следующих разделах под клиентом подразумевается приложение, например локальный диспетчер ресурсов или функция HACMP, использующая клиентский API RMC.

Эти клиентские приложения подключены к общим библиотекам RMC и CtSec. Если эти клиенты запрашивают доступ к ресурсам на удаленном узле, демон RMC на этом удаленном узле будет сервером для этих запросов.

Обзор служб безопасности кластера (CtSec)

Службы безопасности кластера (Cluster Security Services, CtSec) интегрированы в подсистему RSCT и используются в RMC для определения подлинности клиента с узла. Этот процесс аутентификации создает контекст безопасности, применяемый RMC для связи между участвующими узлами в целях выполнения клиентских запросов.

При создании этого контекста безопасности CtSec используют учетные данные для аутентификации. Эти учетные данные применяются для определения подлинности узла и клиентского приложения. Для доступа к ресурсам на удаленном узле, в процессе аутентификации оба узла отправляют и сравнивают учетные данные.

Этот процесс позволяет достичь следующих целей:

Аутентификация на основе учетных данных использует другие компоненты для создания и идентификации учетных данных. Такая архитектура на основе компонентов, представленная на рис. 9.8, позволяет в будущем выполнять расширение уровня безопасности в RSCT.

В RMC службы CtSec отвечают только за аутентификацию. Вообще RMC отвечает за авторизацию с использованием таблицы управления доступом (access control list, ACL), разрешая или запрещая доступ к ресурсам в кластере.

Компоненты служб безопасности кластера (CtSec)

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

Контекст безопасности, создаваемый CtSec, содержит учетные данные клиента и сервера, состояние аутентификации (выполнена или не выполнена) и информацию о сеансе (например, ключ сеанса или время завершения действия). Контекст безопасности создается компонентами CtSec и отправляется в RMC как результат аутентификации CtSec.

Абстрактный уровень механизма (MAL)

CtSec экспортирует интерфейс в приложения, требующие реализации безопасности кластера. Этот интерфейс называется абстрактным уровнем механизма (mechanism abstract layer, MAL). MAL обеспечивает общий, независимый от механизма интерфейс для базовых механизмов безопасности и отправляет эти общие инструкции на сконфигурированные модули безопасности.

Такие подключаемые модули механизма безопасности называются подключаемыми модулями механизма (mechanism pluggable module, MPM). Результатом работы MAL и сконфигурированного MPM является контекст безопасности, содержащий учетные данные и ключ сеанса, используемые обеими сторонами, участвующими в процессе связи.

Если клиент отключает аутентификацию, установив значение переменной окружения CTSEC_CC_MECH=none, MAL не применяет MPM для аутентификации, а возвращает контекст безопасности без аутентификации как результат процесса аутентификации. Конфигурирование MPM выполняется в файле /var/ct/cfg/ctcec.cfg. Этот файл содержит все MPM, которые службы CtSec должны использовать в процессе аутентификации. В будущих версиях компания IBM собирается разработать другие модули безопасности. Применение модулей основывается на предопределенных приоритетах.

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

Подключаемый модуль механизма (MPM)

Каждый подключаемый модуль механизма (mechanism pluggable module, MPM) преобразует общие задачи, получаемые с уровня MAL, в необходимые задачи, используемые механизмом безопасности для выполнения запросов MAL. MPM осуществляет сбор всех учетных данных, необходимых для выполнения процесса аутентификации каждым отдельным механизмом безопасности. MPM также осуществляет сопоставление сетевых идентификационных данных с локальными идентификационными данными [см. раздел "Служба IDM (Identity Mapping Service) "].

В настоящее время поддерживается только UNIX MPM. Модуль UNIX MPM был создан для работы как в 32-, так и в 64-разрядных средах, в зависимости от ядра операционной системы. Благодаря модульной архитектуре MAL и MPM в последующих версиях могут быть добавлены другие механизмы безопасности. MPM представляют собой объектные модули, загружаемые MAL во время выполнения.

MPM расположены в каталоге /usr/sbin/rsct/lib. Каждый MPM должен иметь ссылку в каталоге /usr/lib/, указывающую на соответствующий файл в каталоге ( пример 9.2 ).

ls -al /usr/sbin/rsct/lib/*.mpm*
-r--r--r-- 1 bin bin 192120 Sep 06 13:26 /usr/sbin/rsct/lib/unix.mpm
-r--r--r-- 1 bin bin 199952 Sep 24 11:27 /usr/sbin/rsct/lib/unix.mpm64
ls -al /usr/lib/*.mpm*
lrwxrwxrwx 1 root system 27 Oct 11 10:22 /usr/lib/unix.mpm ->
/usr/sbin/rsct/lib/unix.mpm
lrwxrwxrwx 1 root system 29 Oct 11 10:22 /usr/lib/unix.mpm64 ->
/usr/sbin/rsct/lib/unix.mpm64

Подключаемый модуль UNIX MPM

Ядром модуля UNIX MPM является клиентский API ctcasd (см. раздел "Аутентификация на основе хостов с использованием ctcasd"), который создает учетные данные аутентификации на основе хостов (host-based authentication, HBA).

Компонент ctcasd вызывается только при использовании сокетов TCP/IP для удаленных подключений. Если запрос предназначен для локального хоста, UNIX MPM применяет сокеты домена UNIX в ядре. Безопасность ядра является доверенной, и не требует использования дополнительных функций безопасности.

Аутентификация на основе хостов с использованием ctcasd

Демон службы Cluster Technology Cluster Authentication Service (ctcasd) создает учетные данные на основе имени хоста и идентификационных данных клиента. Помните о том, что клиентом называется приложение, использующее клиентский API RMC.

Кроме того, ctcasd создает ключ сеанса, который может применяться в качестве симметричного ключа для обмена данными между узлами после аутентификации. Этот ключ сеанса необходим для шифрования и дешифрования данных в RSCT с использованием алгоритма симметричного ключа, который имеет более высокое быстродействие, чем алгоритмы открытого и закрытого ключа (public and private key algorithms, PPK).

Чтобы обеспечить конфиденциальность данных о секретном ключе сеанса и целостность учетных данных хоста, ctcasd использует пару открытый/закрытый ключ для шифрования и дешифрования этой информации. В текущей реализации эта пара ключей генерируется с использованием алгоритма RSA512. Это можно изменить, задав 1024-разрядный ключ, путем редактирования файла конфигурации ctcasd ( /usr/ sbin/rsct/cfg/ctcasd.cfg ).

Чтобы убедиться в том, что ctcasd использует корректный открытый ключ в процессе шифрования, открытые ключи в файле списка доверенных хостов (trusted host list, THL) связываются с именем хоста. Поэтому необходимо, чтобы все узлы в кластере HACMP выполняли разрешение имен идентичным образом.

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

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

Распространение открытых ключей по всем узлам выполняет RSCT. При добавлении узла в одноранговый кластер RSCT выполняет команды для обмена открытыми ключами между управляющим сервером и его узлами.

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

Служба IDM (Identity Mapping Service)

Результат работы службы IDM (Identity Mapping Service) используется для авторизации. Служба IDM сопоставляет сетевые идентификационные данные с локальными идентификационными данными, если в файлах конфигурации (называемых сопоставлениями, maps) задано правило сопоставления.

Эти локальные идентификационные данные могут использоваться в RMC для извлечения разрешения из таблицы управления доступом RMC. Описание сбора подсистемой RMC разрешений доступа к ресурсам из таблиц управления доступом см. в разделе "Таблица управления доступом RMC".

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

Как описывается в разделе "Таблица управления доступом RMC", подсистема RMC осуществляет сбор разрешений доступа к ресурсам, используя сначала сетевые идентификационные данные клиента.

Например, если пользователь david должен существовать на всех узлах в кластере из четырех узлов и иметь доступ к ресурсам на определенном узле, файл ACL подсистемы RMC на этом узле должен содержать записи для всех сетевых идентификационных данных клиента. Пример 9.3 показывает выходные данные определенного ресурса в файле ACL RMC для четырех узлов.

IBM.FileSystem
david@node001 * rw # access for david from node 001
david@node002 * rw # access for david from node 002
david@node003 * rw # access for david from node 003
david@node004 * rw # access for david from node 004

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

Файл конфигурации сопоставлений, /var/ct/cfg/ctsec_map.global, содержит отношения сопоставления между локальными и сетевыми идентификационными данными. В нашем примере файл сопоставлений должен содержать только одну строку, чтобы сопоставить пользователя david на всех узлах кластера с локальными идентификационными данными mapped_david:

unix:david@<cluster>=mapped_david

Это обеспечивает сопоставление пользователя david с каждого узла в текущем активном кластере с локальными идентификационными данными mapped_david с использованием сопоставлений, инициируемых UNIX MPM. Эти локальные идентификационные данные не обязательно должны существовать в качестве реальногопользователя в операционной системе. Доступ к ресурсам осуществляется, даже если эти идентификационные данные не существуют локально (в /etc/passwd ).

При использовании таких идентификационных данных с сопоставлением ресурс в файле ACL требует только одной записи, как показано в примере 9.4 .

IBM.FileSystem
mapped_david * rw # access for david from node 001

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

Изначально глобальный файл сопоставлений содержит эти записи, как показано в примере 9.5 (например, unix: определяет MPM, используемый для аутентификации, а =root определяет локальные идентификационные данные).

cat /var/ct/cfg/ctsec_map.global
unix:root@<cluster>=root
unix:root@<any_cluster>=any_root
unix:*@LOCALHOST=*

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

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

Таблица управления доступом RMC

RMC использует таблицу управления доступом (access control list, ACL) для разрешения или запрета доступа к ресурсам в одноранговом домене RSCT. Таблица управления доступом обновляется HACMP во время процедур администрирования кластера (например, при добавлении и удалении узлов).

После успешной аутентификации клиента в RMC, выполняется поиск разрешений по заданным критериям в ACL (рис. 9.7). Файл ACL RMC имеет расположение /usr/ sbin/rsct/cfg/ctrmc.acl.

Файл ACL состоит из разделов (stanzas), содержащих классы ресурсов и определенные разрешения пользователей и хостов в кластере. RMC применяет два типа идентификационных данных для извлечения разрешений, хранящихся в ACL. Эти типы идентификационных данных следующие:

В процессе просмотра файла ACL сначала выполняется поиск сетевых идентификационных данных, а затем локальных идентификационных данных.