Сервис Elasticsearch в облаке Tencent начал предоставлять нам кластеры Elasticsearch на основе доступа по протоколу HTTPS Elastic; Служба Cloud Elasticsearch по умолчанию всегда использовала протокол безопасности HTTPS. И наш собственный кластер Elasticsearch,Начиная с версии 8.0,Функции безопасности также упрощены по умолчанию.,для пользователейАвтоматическая конфигурация:Аутентификация пользователя、Управление доступом на основе ролей для авторизации пользователей、использовать TLS Зашифрованная связь между узлами, использование HTTPS и Elasticsearch API Осуществлять зашифрованную связь.

Почему нам нужно это делатьсложныйконфигурация безопасности,И включить SSL/TLS для аутентификации и шифрования сообщений для служб Elasticsearch?

Потому что это поможет нам получить:

1. Безопасность передачи данных. Включение HTTPS и TLS шифрует всю передачу данных в кластере Elasticsearch, что помогает защитить конфиденциальные данные от доступа, кражи или подделки неавторизованными третьими лицами.
2. Аутентификация и авторизация. Кластер можно защитить от несанкционированного доступа, включив TLS, а для аутентификации можно использовать сертификат клиента.
3. Соблюдение требований соответствия: включение HTTPS и TLS помогает удовлетворить требования различных отраслевых и нормативных стандартов, таких как HIPAA, PCI DSS, GDPR и т. д.
4. Улучшенная безопасность. Включение HTTPS и TLS может повысить безопасность кластера и предотвратить кражу или подделку данных злоумышленниками посредством атак «человек посередине».

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

Хотя мы понимаем важность конфигурации безопасности, нелегко понять, почему это так, особенно когда речь идет о различных сертификатах CA, сертификатах, открытых ключах, секретных ключах и числах, связанных с этими конфигурациями безопасности, отпечатками пальцев сертификатов (finger). отпечатки), и выяснение связи между ними обычно вызывает у нас головокружение.

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

Основные понятия HTTPS и TLS

HTTPS (безопасный протокол передачи гипертекста) — это безопасный протокол HTTP, который использует протоколы SSL (Secure Sockets Layer) или TLS (Transport Layer Security) для шифрования и аутентификации данных для защиты безопасности сетевых коммуникаций.

Вот некоторые важные концепции HTTPS:

1. Сертификат ЦС (Сертификат центра сертификации): Сертификат сервера Центра сертификации (CA), выданный Сертификатом.,Используется для проверки подлинности сертификата сервера.Браузер или клиент будети Проверьте сервер, когда он устанавливает соединение Сертификат Этому доверяют?CAАгентство выдало。
2. Сертификат сервера（Server Сертификат): является разновидностью Сертификата. сервера,Используется для проверки личности сервера и предоставления открытого ключа клиенту.,для шифрования и аутентификации данных.
3. Отпечаток CA (отпечаток органа сертификации): относится к цифровому отпечатку сертификата, выданному CA, который используется для проверки подлинности сертификата.
4. Открытый ключ и закрытый ключ: открытый ключ используется для шифрования данных, а закрытый ключ используется для расшифровки данных и цифровой подписи.
5. цифровая подпись (Цифровая подпись): цифровая технология, используемая в Сертификате сервера.,Используется для проверки подлинности и целостности Сертификата.,Убедитесь, что содержимое Сертификата не было подделано.

При настройке безопасной связи кластера Elasticsearch мы будем использовать упомянутые выше элементы для проверки аутентификации сервера и клиента, а также шифрования и целостности связи.

Соответствующие элементы в кластере Elasticsearch

Когда мы настраиваем безопасную связь кластера Elasticsearch,Связь TLS между узлами кластера необходимо настраивать отдельно.,А также HTTPS-связь для клиентов и кластеров.

Теперь предположим, что у нас есть многоузловой кластер, и Kibana и Logstash должны взаимодействовать с кластером. Поэтому будут аналогичные роли, которые необходимо настроить:

[root@node1 cert_blog]# vi ~/tmp/cert_blog/instance.yml
# add the instance information to yml file
instances:
  - name: 'node1'
    dns: [ 'node1.elastic.test.com' ]
  - name: "node2"
    dns: [ 'node2.elastic.test.com' ]
  - name: 'my-kibana'
    dns: [ 'kibana.local' ]
  - name: 'logstash'
    dns: [ 'logstash.local' ]

然назадиспользовать配套изelasticsearch-certutilинструменты для создания соответствующих Сертификат ЦСи Сертификат сервера。

[root@node1 elasticsearch]# bin/elasticsearch-certutil cert --keep-ca-key --pem --in ~/tmp/cert_blog/instance.yml --out ~/tmp/cert_blog/certs.zip

После распаковки certs.zip появится следующий каталог и файлы:

├── ca
│   ├── ca.crt
│   └── ca.key
├── ca.zip
├── certs2.zip
├── node1
│   ├── node1.crt
│   └── node1.key
├── node2
│   ├── node2.crt
│   └── node2.key
├── my-kibana
│   ├── my-kibana.crt
│   └── my-kibana.key
├── logstash
│   ├── logstash.crt
│   └── logstash.key

среди них,ca.crtто естьElasticsearchсамоподписавшийсяСертификат ЦС,и es01.crt、 es02.crt、my-kibana.crt、logstash.crtждать,Они все этим пользуютсяca.crtСоответствующийca.keyизданныйСертификат сервера。

Будьте конкретны,ca.keyиca.crtдаиспользовать于生成и签发Сертификат сервераизCA（Certificate Центр сертификации — закрытый и открытый ключи центра сертификации. Центр сертификации — это доверенный объект, используемый для выдачи сертификатов сервера. Он используется для проверки личности владельца сертификата и цифровой подписи сертификата, чтобы гарантировать целостность и подлинность сертификата во время передачи.

ca.keyдаCAиз私钥,Используется для сертификата сервераруководитьцифровая подпись。Обычно должен состоять только изCAдоступ владельца,Потому что с его помощью можно выдать любой Сертификат.,и считать его надежным сертификатом. поэтому,Если закрытый ключ скомпрометирован или утерян,Это сделает все выданные сертификаты ненадежными. То есть,вышеиз Сертификат сервера（например,node1.crt）内изцифровая подпись,то естьиспользоватьca.key来加密изданный。

ca.crtдаCAиз公钥Сертификат,Используется для проверки подлинности и целостности Сертификата сервера.。Сертификатвключен вCAиз公钥,и данные подписи. При проверке Сертификата сервера,接收方可以использоватьca.crtпроверить Сертификатиз签名да否可信。если заслуживает доверия,Вы можете подтвердить Сертификатиз真实性и完整性。например,Клиент привязываетсяnode1час,node1из Сертификат сервераnode1.crt内изцифровая подпись,将использоватьca.crt中изCAиз公钥来руководить解密,如果解密出来из值да该Сертификат сервера（node1.crt）из哈希值,Это указывает на то, что сервер заслуживает доверия.

поэтому,посмотрим,В конфигурации Кибаны,Нам нужно будет настроитьelasticsearch.ssl.certificateAuthorities,Потому что нам это нужно, чтобы убедиться, что ES, на который мы ссылаемся, является тем ES, на который мы ожидаем ссылаться.

elasticsearch.username: "kibana"
elasticsearch.password: "<kibana_password>"
elasticsearch.ssl.certificateAuthorities: [ "/etc/kibana/config/certs/ca.crt" ]

Как сертификат ЦС проверяет подлинность веб-сайта и подлинность сертификата?

Вышеизложенное является относительно поверхностным. Давайте подробно объясним основной процесс проверки сертификата CA идентичности узла ES и подлинности сертификата (сертификата сервера):

• Когда узел ES,или клиент,Если вы хотите использовать протокол SSL/TLS и если вы хотите обмениваться данными с кластером,Он будет подан в агентство CA для получения сертификата. сервер. Агентство CA проверит подлинность веб-сайта и создаст сертификат. сервера。简单из说,то естьпроходитьca.crtиca.keyгенерироватьnode1.crt
• Сертификат сервера содержит открытый ключ сервера.、网站из名称（node1.elastic.test.com）、срок действия ицифровая подписьждать信息。Сертификат сервераизцифровая Подпись — пара закрытых ключей. Сертификат, используемый центром сертификации. Содержимое сервера шифруется и генерируется, это цифровая Подпись – залог подлинности Сертификата.。
• Когда клиент обращается к узлу, узел будет Сервер отправлен клиенту. Клиент проверит Сертификат сервераиз真实性,具体из验证流程如下：
  1. Клиент сначала проверяет наличие Сертификата. Истек ли срок действия сервера, если он истекает, этому Сертификату не доверяют.
  2. Клиент проверит Сертификат Доверен ли органу, выдавшему сервер, то есть проверьте Сертификат Существует ли ЦС в списке доверия клиента.
  3. Клиент ответит на Сертификат сервера中изцифровая Подпись для проверки для обеспечения Сертификат Содержимое сервера не было изменено. Клиент будет использовать Сертификат Пара открытых ключей в ЦСцифровая Подпись расшифровывается, если получен результат расшифровки Сертификат Содержимое на сервере соответствует, с указанием Сертификата. Сервер настоящий, иначе этому Сертификату нельзя доверять.

Как проверить цифровую подпись в сертификате сервера через сертификат ЦС?

цифровая Подпись генерируется из открытого и закрытого ключей. Организация ЦС будет использовать свой собственный закрытый ключ в качестве Сертификата. сервераизцифровая Подписано подписью. Поэтому при проверке Сертификата сервере, вам необходимо сначала использовать пару открытых ключей организации ЦС цифровая Подпись расшифровывается и получает Сертификат хеш-значение сервера, а затем Сертификат Хэш-значение для серверов Сертификат сам сервер сравнивается, и если соответствует, то указывает, что сертификат сертификата Сервер выдан организацией CA и ему можно доверять. Если оно не соответствует, то Сертификат Сервер может быть подделан или подделан, и ему не следует доверять. Этот процесс можно выполнить через цепочку сертификатов (сертификат цепочка), то есть через проверку Сертификата сервераизцифровая Может ли подпись успешно соответствовать Сертификату агентства ICA для подтверждения Сертификата авторитет сервера.

Что входит в сертификат сервера?

Выше мы упоминали, что сертификат сервера содержит такую ​​информацию, как открытый ключ, имя веб-сайта, срок действия и цифровую подпись. В частности, сертификат сервера содержит следующие основные части:

• Номер версии сертификата: идентификационный Сертификат Номер версии сервера.
• Серийный номер: уникальный серийный номер Сертификата, используемый для различения различных серверов Сертификатов.
• Идентификатор алгоритма подписи: указывает алгоритм, используемый для подписи Сертификата сервера.
• Выдано: Сертификат сервера Информация об органе, выдавшем сертификат.
• Срок действия: Срок действия Сертификата сервера, включая время начала и окончания.
• Тема: Сертификат сервера. Владелец информации, обычно веб-сайт или физическое лицо.
• Информация об открытом ключе: Содержит открытый ключ владельца Сертификата.
• цифровая подпись：использовать Сертификат Закрытый ключ органа, выдавшего сервер, подписывает содержимое Сертификата и используется для проверки подлинности Сертификата.

Например, содержимое сертификата сервера es01:

После декодирования base64 содержимое будет следующим:

Как https использует сертификаты и ключи сервера для шифрования и дешифрования данных при обмене данными?

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

Но помимо функции аутентификации HTTPS/TLS также имеет функцию шифрования связи. Как это реализовано?

• Когда клиент и сервер (узел ES) устанавливают HTTPS-соединение,Сначала заключается соглашение о рукопожатии. во время рукопожатия,Сервер отправит клиенту свой Сертификат сервера.,Клиент проверит Сертификат,После успешной проверки,客户端就可以использовать Сертификат中包含из公钥（напримерnode1.crt中из公钥）человеку, названному"Pre-master secret» шифруется и отправляется на сервер.
• Сервер получает зашифрованный «Pre-master secret"назад,использовать私钥（например,node1.key）верно其руководить解密,получать"Pre-master секрет". Далее и сервер, и клиент используют этот "Pre-master secret» генерирует файл под названием «Master секретный ключ», который будет использоваться для последующего шифрования связи.
• После создания «Главного секрета» и сервер, и клиент могут использовать его для шифрования и дешифрования данных при обмене данными. В частности, когда клиент отправляет данные на сервер, он шифрует данные с использованием «Главного секрета» и отправляет зашифрованные данные на сервер. После того, как сервер получает данные, он использует тот же «Главный секрет» для расшифровки данных.

В этом процессе сертификат сервера играет роль проверки личности сервера и предоставления открытого ключа, а закрытый ключ используется для расшифровки данных, отправленных клиентом. В то же время два ключа «Предварительный главный секрет» и «Главный секрет» также играют роль в шифровании и дешифровании передаваемых данных. Вместе эти шаги гарантируют, что ваше HTTPS-соединение безопасно и конфиденциально.

Должен ли каждый узел Elasticsearch иметь собственный сертификат и секретный ключ?

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

每个节点都有自己изIPадрес или имя хоста,需要использовать相应из Сертификати秘钥来идругие узлы или клиенты（transport клиент) для общения. Если все узлы используют один и тот же сертификат и ключ, конфиденциальность сертификата и ключа будет уничтожена, что сделает связь более небезопасной.

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

Используйте самозаверяющие сертификаты ЦС для выдачи сертификатов и управления ими.

выше,мы упомянулиElasticsearch提供配套изelasticsearch-certutilинструмент,создать самоподписанный Сертификат ЦС и используйте этот Сертификат для получения Сертификата. Выпуск и управление сервером.

В частности, вот шаги по использованию самозаверяющего сертификата ЦС для выдачи дополнительных сертификатов:

• Создайте самоподписанный сертификат ЦС первый,我们需要использоватьelasticsearch-certutilСоздайте самоподписанный сертификат ЦС。существовать Создать сертификатчас,Необходимо заполнить основную информацию,Например Сертификатиз名称、有效期限ждатьждать。Эту информацию предоставилelasticsearch-certutilСоздается автоматически для нас。
• Установите самоподписанный Сертификат на сервер. ЦС Преобразование самоподписанного сертификата Чтобы установить ЦС на сервер, вы обычно помещаете файл Сертификата в определенный каталог и записываете информацию о Сертификате в соответствующий файл конфигурации. Здесь мы увидим, что каждый узел ES или клиент необходимо настроить. Путь ЦС:

xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.http.ssl.key: certs/node1.key
xpack.security.http.ssl.certificate: certs/node1.crt
-> xpack.security.http.ssl.certificate_authorities: certs/ca.crt
xpack.security.transport.ssl.key: certs/node1.key
xpack.security.transport.ssl.certificate: certs/node1.crt
-> xpack.security.transport.ssl.certificate_authorities: certs/ca.crt

• Создать сертификат сервера проходитьelasticsearch-certutilСоздайте Сертификатпросить,Запрос содержит открытый ключ сервера и некоторую базовую информацию.,Например, имя сервера, имя домена и т. д. Запрос обычно представляет собой файл, содержащий открытый ключ и информацию о сертификате. например,

./bin/elasticsearch-certutil cert \
  --name node1 \
  --ca-cert /path/to/ca/ca.crt \
  --ca-key /path/to/ca/ca.key \
  --dns your.host.name.here \
  --ip 192.0.2.1 \
  --pem

• Подписано Сертификат ЦСпроблема Сертификат сервера Использовать самоподписанный сертификат ЦСверно Сертификат сервер запрашивает подпись, тем самым генерируя новый Сертификат сервера。此час,Сертификат Сервер уже содержит открытый ключ сервера, информацию о сертификате и сертификат Подпись ЦС может использоваться для безопасной связи с сервером.
• Установить Сертификат сервера Установить Сертификат сервера на сервер,И запишите информацию о сертификате в соответствующий файл конфигурации. в это время,Серверы могут использовать этот Сертификат для безопасной связи.

xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.enabled: true
-> xpack.security.http.ssl.key: certs/node1.key
-> xpack.security.http.ssl.certificate: certs/node1.crt
xpack.security.http.ssl.certificate_authorities: certs/ca.crt
-> xpack.security.transport.ssl.key: certs/node1.key
-> xpack.security.transport.ssl.certificate: certs/node1.crt
xpack.security.transport.ssl.certificate_authorities: certs/ca.crt

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

Может ли клиент также отказаться от проверки сертификата сервера?

мы видим,无论даbeats还даLogstashждатьинструмент,При подключении к ЕС,во избежание Преобразование самоподписанного сертификата ЦС拷贝到所有из采集端上,Мы выберемssl.verification_modeПараметры настроены какnone。это означает,Клиент будет выполнение Сертификат Верификация сервера.

Это разрешено и также известно как небезопасное соединение HTTPS. Однако без проверки сертификата сервера клиент может подвергнуться атаке «человек посередине», в результате чего передаваемые данные могут быть подделаны или украдены. Поэтому клиентам рекомендуется всегда проверять действительность сертификата сервера, чтобы обеспечить безопасную связь.

verification_mode 控制Сертификат Верификация сервера. Допустимые значения:

# full
Убедитесь, что предоставленный сертификат выдан доверенным органом. (CA) Подпишите и проверьте имя хоста сервера (или IP адрес) соответствует имени, указанному в Сертификате.
# strict
Убедитесь, что предоставленный сертификат выдан доверенным органом. (CA) Подпишите и проверьте имя хоста сервера (или IP адрес) соответствует имени, указанному в Сертификаты Subject Alternative Name Если пусто, возвращается ошибка.
# certificate
Убедитесь, что предоставленный сертификат выдан доверенным органом. (CA) Подписано, но не выполняет проверку имени хоста.
# none
Не выполнение Сертификат Верификация сервера. Этот режим отключает SSL/TLS имеет множество преимуществ с точки зрения безопасности, и его следует использовать только после тщательного рассмотрения. В основном он используется для решения TLS Временный механизм диагностики на случай ошибок; его использование в производственных средах настоятельно не рекомендуется.

Каковы шаги для зашифрованной связи без проверки сертификата?

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

• Клиент инициирует HTTPS-запрос к серверу, и запрос содержит такую ​​информацию, как алгоритм шифрования и версия протокола.
• Сервер возвращает Сертификат,включить открытый ключ、Название сайта、Срок действия и цифровая подпись.
• Клиент использует открытый ключ из Сертификата для шифрования случайно сгенерированного симметричного ключа, который будет использоваться для шифрования данных во время связи.
• Клиент отправляет зашифрованный ключ на сервер.
• Сервер использует закрытый ключ для расшифровки полученного случайно сгенерированного симметричного ключа.
• И клиент, и сервер используют симметричные ключи для шифрования и дешифрования данных, обеспечивая конфиденциальность и целостность данных во время обмена данными. Следует отметить, что если клиент решит не проверять Сертификат сервера,Тогда сервер сможет использовать любой Сертификат, чтобы замаскироваться.,Таким образом, данные во время связи могут быть украдены или подделаны.,поэтому不建议использовать不安全изHTTPSсоединять。

Почему нам не нужен сертификат при доступе к сервису Elasticsearch в облаке Elastic?

Elastic Сертификат, используемый в облаке, выдается общедоступным центром сертификации, которому доверяют браузеры и операционные системы, поэтому вы можете использовать его напрямую с браузером или инструментами API и Elastic. Общайтесь с кластерами Elasticsearch в облаке без необходимости дополнительной проверки сертификата. К числу таких общедоступных центров сертификации относятся DigiCert, GlobalSign, Let's Известные сторонние центры сертификации, такие как Encrypt, имеют свои корни, предварительно установленные в операционных системах и браузерах. Это означает, что в иElastic При взаимодействии с Elasticsearch в облаке ваш инструмент API проверяет, ведет ли цепочка сертификатов к корневому сертификату одного из доверенных центров сертификации.

Теперь Elastic Cloud использует сертификат CA Let’s Encrypt.