Настройка безопасности¶

В целях безопасности серсис NiFi предоставляет несколько различных параметров конфигурации. Наиболее важными являются свойства под заголовком “security properties” в файле nifi.properties.

Для безопасной работы должны быть установлены свойства, приведенные в таблице.

Табл. 4. Описание свойств безопасности NiFi¶
Свойство	Описание
nifi.security.keystore	Имя файла Keystore, содержащего закрытый ключ сервера
nifi.security.keystoreType	Тип Keystore. Должен быть либо PKCS12, либо JKS. JKS является предпочтительным типом, файлы PKCS12 загружаются библиотекой BouncyCastle
nifi.security.keystorePasswd	Пароль Keystore
nifi.security.keyPasswd	Пароль для сертификата в Keystore. Если значение не установлено, используется `nifi.security.keystorePasswd`
nifi.security.truststore	Имя файла Truststore для авторизации при подключении к NiFi. Защищенный инстанс без Truststore отклоняет все входящие подключения
nifi.security.truststoreType	Тип Truststore. Должен быть либо PKCS12, либо JKS. JKS является предпочтительным типом, файлы PKCS12 загружаются библиотекой BouncyCastle
nifi.security.truststorePasswd	Пароль Truststore
nifi.security.needClientAuth	Значение `true` требует пройти аутентификацию при подключении клиентов. Свойство используется протоколом кластера NiFi для подтверждения, что узлы в кластере аутентифицированы и имеют сертификаты, которым доверяют Truststores

После настройки перечисленных свойств можно разрешить доступ к пользовательскому интерфейсу через HTTPS вместо HTTP. Это достигается путем установки свойств nifi.web.https.host и nifi.web.https.port. Свойство nifi.web.https.host указывает, на каком хосте должен работать сервер. При необходимости доступности интерфейса HTTPS со всех сетевых интерфейсов следует использовать значение 0.0.0.0. Для того, чтобы администраторы могли настраивать приложение для работы только на определенных сетевых интерфейсах, следует указать свойства nifi.web.http.network.interface и nifi.web.https.network.interface.

Important

При включении HTTPS необходимо исключить свойство nifi.web.http.port, так как NiFi поддерживает либо HTTP, либо HTTPS

Так же и с nifi.security.needClientAuth – веб-сервер может быть настроен на требование аутентификации на основе сертификатов у пользователей, обращающихся к интерфейсу. Для этого веб-сервер не должен поддерживать аутентификацию имени пользователя и пароля с помощью протокола LDAP или Kerberos, так как любой из этих параметров настраивает проверку подлинности клиента на основе сертификатов, а у кого их нет, могут войти в систему под своими учетными данными или получить анонимный доступ. Но если аутентификация по имени пользователя и паролю и анонимный доступ не настроены, то веб-сервер запрашивает аутентификацию клиента на основе сертификата (см. Аутентификация пользователя).

После защиты пользовательского интерфейса следует обеспечить внутренние кластерные коммуникации и связь между сайтами. Это достигается установкой свойств nifi.remote.input.secure и nifi.cluster.protocol.is.secure в значение true.

Набор средств генерации TLS¶

Для упрощения установки NiFi и автоматического создания необходимых хранилищ ключей, доверительного хранилища и соответствующих файлов конфигурации можно использовать утилиту командной строки tls-toolkit, что так же обеспечит безопасность многочисленных узлов NiFi.

Wildcard-сертификаты (т. е. два узла node1.nifi.apache.org и node2.nifi.apache.org, которым назначается тот же сертификат с записью CN или SAN .nifi.apache.org) официально не поддерживаются и не рекомендуются. Их использование имеет множество недостатков и приемлемо только, если каждый сертификат поддерживает дополнительную уникальную запись SAN и запись CN.

Потенциальные проблемы использования wildcard-сертификатов:

Кластерные связи многократно используют идентификаторы сертификатов для определения узла, а если сертификат представляет собой подстановочное DN, то он не даст ответа;
Администраторам может потребоваться предоставить кастомный идентификатор узла в authorizers.xml для .nifi.apache.org, поскольку все действия прокси-сервера разрешаются только в сертификате DN (см. Аутентификация пользователя);
Администраторы не имеют возможности отслеживать, в каком узле выполняется действие, так как все они направляются в один и тот же DN;
Администраторы, запускающие несколько инстансов на одном компьютере и используя разные порты для их идентификации, могут случайно поместить узел node1 с портом node2, и адрес будет в итоге удален, потому что он использует тот же сертификат, а обработчик узла блокирует его, так как имя узла node1 не указано в качестве допустимого хоста для инистанса node2;
Если wildcard-сертификат скомпрометирован, все узлы оказываются под угрозой.

Important

Для keystores и truststores в NiFi рекомендуются JKS. Этот инструмент позволяет задавать другие типы хранилищ ключей в командной строке и игнорировать тип PKCS12 для использования в качестве доверительного хранилища, потому что данный формат имеет проблемы совместимости между реализациями BouncyCastle и Oracle

Инструмент командной строки tls-toolkit имеет два основных режима работы:

Standalone (автономный) – создает организацию сертификатов, хранилища ключей, доверительные хранилища и файлы nifi.properties в одной команде;
Client/Server (Клиент/Сервер) – использует Certificate Authority Server, который принимает запросы на подписание сертификатов от клиентов, подписывает и отправляет обратно. И клиент, и сервер проверяют идентификацию друг друга через общий секрет.

Standalone¶

Автономный режим вызывается запуском ./bin/tls-toolkit.sh standalone -h и отображает информацию об использовании с описаниями опций, которые могут быть указаны.

В автономном режиме с tls-toolkit можно использовать следующие параметры командной строки:

-a, --keyAlgorithm <arg> – алгоритм использования сгенерированных ключей (по умолчанию: RSA);
-B, --clientCertPassword <arg> – пароль сертификата клиента. Должно быть либо одно значение, либо одно для каждого DN клиента (если не задано, генерируется автоматически);
-c, --certificateAuthorityHostname <arg> – имя хоста NiFi Certificate Authority (по умолчанию: localhost);
-C, --clientCertDn <arg> – создание сертификата клиента, подходящего для использования в браузере, с указанным DN (может быть указан несколько раз);
-d, --days <arg> – количество дней, в течение которых выданный сертификат является действительным (по умолчанию: 1095);
-f, --nifiPropertiesFile <arg> – базовый файл nifi.properties для обновления (если не указан, используется встроенный файл, идентичный файлу по умолчанию при установке NiFi);
-g, --differentKeyAndKeystorePasswords – использование другого сгенерированного пароля для ключа и хранилища ключей;
-G, --globalPortSequence <arg> – использование последовательных портов, которые вычисляются для всех хостов в соответствии с предоставленными выражениями имен хостов (могут быть указаны несколько раз, но должны быть одинаковыми от запуска до запуска);
-h, --help – печать справки и выход;
-k, --keySize <arg> – количество бит для генерации ключей (по умолчанию: 2048);
-K, --keyPassword <arg> – пароль ключа. Либо одно значение, либо одинаковое для каждого хоста (если не задано, генерируется автоматически);
-n, --hostnames <arg> – список имен хостов через запятую;
--nifiDnPrefix <arg> – строка для добавления имени хоста (в начало) при определении DN (по умолчанию: CN=);
--nifiDnSuffix <arg> – строка для добавления имени хоста (в конец) при определении DN (по умолчанию: OU=NIFI);
-o, --outputDirectory <arg> – каталог для вывода keystore, truststore и config-файлов (по умолчанию: ../bin);
-O, --isOverwrite – перезапись существующего вывода хоста;
-P, --trustStorePassword <arg> – пароль truststore. Либо одно значение, либо одинаковое для каждого хоста (если не задано, генерируется автоматически);
-s, --signingAlgorithm <arg> – алгоритм подписи сертификатов (по умолчанию: SHA256WITHRSA);
-S, --keyStorePassword <arg> – пароль keytstore. Либо одно значение, либо одинаковое для каждого хоста (если не задано, генерируется автоматически);
--subjectAlternativeNames <arg> – разделенный запятыми список доменов для использования в качестве альтернативных имен в сертификате;
-T, --keyStoreType <arg> – тип создаваемого хранилища ключей (по умолчанию: jks).

Шаблоны имен хостов:

Для указания диапазона имен хостов используются квадратные скобки, например: [01-20];
Круглые скобки используются для определения, что на хосте (хостах) работает больше, чем один инстанс NiFi, например: (5).

Примеры:

Создать 4 набора хранилищ ключей, truststore, nifi.properties для localhost вместе с сертификатом клиента с предоставленным DN:
```
bin/tls-toolkit.sh standalone -n 'localhost(4)' -C 'CN=username,OU=NIFI'
```
Создать хранилище ключей, truststore, nifi.properties для 10 имен хостов NiFi в каждом из 4 поддоменов:
```
bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain'
```
Создать 2 набора хранилищ ключей, truststore, nifi.properties для 10 имен хостов NiFi в каждом из 4 поддоменов вместе с сертификатом клиента с предоставленным DN:
```
bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain(2)' -C 'CN=username,OU=NIFI'
```

Client/Server¶

Режим Клиент/Сервер опирается на Центр сертификации (Certificate Authority, CA) для выдачи сертификатов. Центр можно остановить, если узлы не подключены к сети.

Server¶

Сервер CA вызывается запуском ./bin/tls-toolkit.sh -h, который печатает информацию об использовании с описаниями опций, которые могут быть заданы.

В режиме сервера с tls-toolkit можно использовать следующие параметры командной строки:

-a, --keyAlgorithm <arg> – алгоритм использования сгенерированных ключей (по умолчанию: RSA);
--configJsonIn <arg> – место для чтения информации о конфигурации, подразумевает useConfigJson, если установлено (по умолчанию: значение configJson);
-d, --days <arg> – количество дней, в течение которых выданный сертификат является действительным (по умолчанию: 1095);
-D, --dn <arg> – DN для сертификата CA (по умолчанию: CN=YOUR_CA_HOSTNAME,OU=NIFI);
-f, --configJson <arg> – место записи информации о конфигурации (по умолчанию: config.json);
-F, --useConfigJson – флаг, указывающий, что вся конфигурация считывается из configJson (для облегчения автоматического использования, иначе в configJson производится только запись);
-g, --differentKeyAndKeystorePasswords – использование другого сгенерированного пароля для ключа и хранилища ключей;
-h, --help – печать справки и выход;
-k, --keySize <arg> – количество бит для генерации ключей (по умолчанию: 2048);
-p, --PORT <arg> – порт для прослушивания центром сертификации (по умолчанию: 8443);
-s, --signingAlgorithm <arg> – алгоритм подписи сертификатов (по умолчанию: SHA256WITHRSA);
-T, --keyStoreType <arg> – тип создаваемого хранилища ключей (по умолчанию: jks);
-t, --token <arg> – маркер для предотвращения MITM (должен быть таким же, как тот, что используется клиентами).

Client¶

Клиент может использоваться для запроса новых сертификатов из центра сертификации. Утилита клиента генерирует пару ключей и запрос подписи сертификата (CSR, Certificate Signing Request), после чего отправляет CSR в центр сертификации. Клиент вызывается запуском ./bin/tls-toolkit.sh client -h, который печатает информацию об использовании с описаниями опций, которые могут быть заданы.

В режиме клиента с tls-toolkit можно использовать следующие параметры командной строки:

-a, --keyAlgorithm <arg> – алгоритм использования сгенерированных ключей (по умолчанию: RSA);
-c, --certificateAuthorityHostname <arg> – имя хоста NiFi Certificate Authority (по умолчанию: localhost);
-C, --certificateDirectory <arg> – каталог записи сертификата CA (по умолчанию: .);
--configJsonIn <arg> – место для чтения информации о конфигурации, подразумевает useConfigJson, если установлено (по умолчанию: значение configJson);
-D, --dn <arg> – DN для сертификата клиента (по умолчанию: CN=<localhost name>,OU=NIFI, заполняется автоматически инструментом);
-f, --configJson <arg> – место записи информации о конфигурации (по умолчанию: config.json);
-F, --useConfigJson – флаг, указывающий, что вся конфигурация считывается из configJson (для облегчения автоматического использования, иначе в configJson производится только запись);
-g, --differentKeyAndKeystorePasswords – использование другого сгенерированного пароля для ключа и хранилища ключей;
-h, --help – печать справки и выход;
-k, --keySize <arg> – количество бит для генерации ключей (по умолчанию: 2048);
-p, --PORT <arg> – порт для прослушивания центром сертификации (по умолчанию: 8443);
--subjectAlternativeNames <arg> – разделенный запятыми список доменов для использования в качестве альтернативных имен в сертификате;
-T, --keyStoreType <arg> – тип создаваемого хранилища ключей (по умолчанию: jks);
-t, --token <arg> – маркер для предотвращения MITM (должен быть таким же, как тот, что используется клиентами).

В результате запуска клиента предоставляется сертификат CA, keystore, truststore и config.json с информацией о них, а также их пароли.

Сертификат клиента можно легко импортировать в браузер, указав: -T PKCS12.