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

Это руководство описывает функции безопасности, доступные в Chef Infra Server.

Сертификаты SSL

Изначальная настройка Chef Infra Server выполняется автоматически с использованием самозаверяющего сертификата для создания файлов сертификата и закрытого ключа для Nginx. Этот раздел подробно описывает процесс обновления сертификата SSL сервера Chef Infra Server.

Автоматическая установка (рекомендуется)

Chef Infra Server можно настроить на использование сертификатов SSL, добавив следующие настройки в файл конфигурации сервера:

Настройка	Описание
`nginx['ssl_certificate']`	Сертификат SSL, используемый для проверки связи по протоколу HTTPS.
`nginx['ssl_certificate_key']`	Ключ сертификата, используемый для связи SSL.

а затем задать их значения, определив пути к сертификату и ключу.

Например:

nginx['ssl_certificate'] = '/etc/pki/tls/certs/your-host.crt'
nginx['ssl_certificate_key'] = '/etc/pki/tls/private/your-host.key'

Сохраните файл, а затем выполните следующую команду:

sudo chef-server-ctl reconfigure

Дополнительную информацию о файле конфигурации сервера см. в chef-server.rb.

Ручная установка

Сертификаты SSL можно обновить вручную, поместив файл сертификата и закрытого ключа, полученный у удостоверяющего центра, в соответствующие файлы после начальной настройки Chef Infra Server.

Расположение файлов сертификата и закрытого ключа:

/var/opt/opscode/nginx/ca/FQDN.crt
/var/opt/opscode/nginx/ca/FQDN.key

Поскольку FQDN уже настроен, выполните следующие действия:

Замените содержимое /var/opt/opscode/nginx/ca/FQDN.crt и /var/opt/opscode/nginx/ca/FQDN.key файлами удостоверяющего центра.
Переконфигурируйте Chef Infra Server:
```
chef-server-ctl reconfigure
```
Перезапустите службу Nginx для загрузки нового ключа и сертификата:
```
chef-server-ctl restart nginx
```

Предупреждение

FQDN для Chef Infra Server должен быть разрешим, строчными буквами и иметь менее 64 символов, включая доменное имя, при использовании OpenSSL, так как OpenSSL требует, чтобы CN в сертификате не превышало 64 символов.

Протоколы SSL

Следующие настройки часто изменяются от значений по умолчанию в рамках оптимизации службы nginx и для настройки Chef Infra Server на использование сертификатов SSL:

nginx['ssl_certificate']

Сертификат SSL, используемый для проверки связи по HTTPS. Значение по умолчанию: nil.

nginx['ssl_certificate_key']

Ключ сертификата, используемый для SSL-связи. Значение по умолчанию: nil.

nginx['ssl_ciphers']

Список поддерживаемых наборов шифров, используемых для установления безопасного соединения. Для предпочтения AES256 с ECDHE forward security, удалите префикс RC4-SHA:RC4-MD5:RC4:RSA. Например:

nginx['ssl_ciphers'] =  "HIGH:MEDIUM:!LOW:!kEDH: \
                         !aNULL:!ADH:!eNULL:!EXP: \
                         !SSLv2:!SEED:!CAMELLIA: \
                         !PSK"

nginx['ssl_protocols']

Версии протокола SSL, которые включены. SSL 3.0 поддерживается Chef Infra Server; однако SSL 3.0 является устаревшим и небезопасным протоколом. Протокол Transport Layer Security (TLS) — TLS 1.0, TLS 1.1 и TLS 1.2 — фактически заменил SSL 3.0, что обеспечивает проверку версии между Chef Infra Client и Chef Infra Server, гарантируя использование последней версии протокола TLS. Для максимальной безопасности рекомендуется отключить SSL 3.0 и разрешить все версии протокола TLS. Например:

nginx['ssl_protocols'] = 'TLSv1 TLSv1.1 TLSv1.2'

Примечание

Дополнительную информацию о значениях, используемых с настройками nginx['ssl_ciphers'] и nginx['ssl_protocols'], см. на https://www.openssl.org/docs/man1.0.2/man1/ciphers.html.

Например, после копирования файлов сертификатов SSL на Chef Infra Server, обновите настройки nginx['ssl_certificate'] и nginx['ssl_certificate_key'] для указания путей к этим файлам, а затем (необязательно) обновите настройки nginx['ssl_ciphers'] и nginx['ssl_protocols'] для отражения желаемого уровня безопасности для Chef Infra Server:

nginx['ssl_certificate'] = '/etc/pki/tls/private/name.of.pem'
nginx['ssl_certificate_key'] = '/etc/pki/tls/private/name.of.key'
nginx['ssl_ciphers'] = 'HIGH:MEDIUM:!LOW:!kEDH:!aNULL:!ADH:!eNULL:!EXP:!SSLv2:!SEED:!CAMELLIA:!PSK'
nginx['ssl_protocols'] = 'TLSv1 TLSv1.1 TLSv1.2'

Пример: Настройка SSL-ключей для Nginx

В следующем примере показано, как Chef Infra Server устанавливает и настраивает сертификаты SSL для Nginx. Набор шифров, используемый Nginx, настраивается с помощью настроек ssl_protocols и ssl_ciphers.

ssl_keyfile = File.join(nginx_ca_dir, "#{node['private_chef']['nginx']['server_name']}.key")
ssl_crtfile = File.join(nginx_ca_dir, "#{node['private_chef']['nginx']['server_name']}.crt")
ssl_signing_conf = File.join(nginx_ca_dir, "#{node['private_chef']['nginx']['server_name']}-ssl.conf")

unless ::File.exist?(ssl_keyfile) && ::File.exist?(ssl_crtfile) && ::File.exist?(ssl_signing_conf)
  file ssl_keyfile do
    owner 'root'
    group 'root'
    mode '0755'
    content '/opt/opscode/embedded/bin/openssl genrsa 2048'
    not_if { ::File.exist?(ssl_keyfile) }
  end

  file ssl_signing_conf do
    owner 'root'
    group 'root'
    mode '0755'
    not_if { ::File.exist?(ssl_signing_conf) }
    content <<-EOH
  [ req ]
  distinguished_name = req_distinguished_name
  prompt = no
  [ req_distinguished_name ]
  C                      = #{node['private_chef']['nginx']['ssl_country_name']}
  ST                     = #{node['private_chef']['nginx']['ssl_state_name']}
  L                      = #{node['private_chef']['nginx']['ssl_locality_name']}
  O                      = #{node['private_chef']['nginx']['ssl_company_name']}
  OU                     = #{node['private_chef']['nginx']['ssl_organizational_unit_name']}
  CN                     = #{node['private_chef']['nginx']['server_name']}
  emailAddress           = #{node['private_chef']['nginx']['ssl_email_address']}
  EOH
  end

  ruby_block 'create crtfile' do
    block do
      r = Chef::Resource::File.new(ssl_crtfile, run_context)
      r.owner 'root'
      r.group 'root'
      r.mode '0755'
      r.content "/opt/opscode/embedded/bin/openssl req -config '#{ssl_signing_conf}' -new -x509 -nodes -sha1 -days 3650 -key '#{ssl_keyfile}'"
      r.not_if { ::File.exist?(ssl_crtfile) }
      r.run_action(:create)
    end
  end
end

Knife, Chef Infra Client

Chef Server 12 и более поздние версии по умолчанию включают проверку SSL для всех запросов к серверу, таких как запросы knife и Chef Infra Client. Сертификат, сгенерированный при установке Chef Infra Server, самозаверяющий, что означает, что сертификат не подписан доверенным удостоверяющим центром (CA), поставляемым с Chef Infra Client. Сертификат, сгенерированный Chef Infra Server, необходимо загрузить на любой компьютер, с которого knife и/или Chef Infra Client будут отправлять запросы к Chef Infra Server.

Например, без загрузки сертификата SSL следующая команда knife:

knife client list

ответит ошибкой, подобной:

ERROR: SSL Validation failure connecting to host: chef-server.example.com ...
ERROR: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 ...

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

Дополнительную информацию о том, как knife и Chef Infra Client используют сертификаты SSL, сгенерированные Chef Infra Server, см. в разделе Сертификаты SSL Chef Infra Client.

Приватный центр сертификации

Если организация использует внутренний центр сертификации, то корневой сертификат не отобразится ни в одном файле cacerts.pem поставляемом по умолчанию с операционными системами и веб-браузерами. Из-за этого ни одно из текущих развернутых систем не сможет проверить сертификаты, выпущенные таким образом. Чтобы позволить другим системам доверять сертификатам из внутреннего центра сертификации, этот корневой сертификат должен быть настроен, чтобы другие системы могли отследить цепочку доверия до корневого сертификата. (Промежуточный сертификат недостаточно, потому что корневой сертификат не известен глобально).

Для использования внутреннего центра сертификации добавьте сертификаты сервера (необязательно, также промежуточные) и корневые сертификаты в один файл .crt. Например:

cat server.crt [intermediate.crt] root.crt >> /var/opt/opscode/nginx/ca/FQDN.crt

Проверьте действительность объединенного сертификата на сервере Chef Infra Server:

openssl verify -verbose -purpose sslserver -CAfile cacert.pem  /var/opt/opscode/nginx/ca/FQDN.crt

Файл cacert.pem должен содержать только файл сертификата вашего корневого центра сертификации. Это не обычная обработка, но имитирует поведение Chef Workstation после knife ssl fetch и knife ssl verify.

Промежуточные сертификаты

Для использования с поставщиками сертификатов сторонних разработчиков, например, Verisign.

Чтобы использовать промежуточный сертификат, добавьте как сертификат сервера, так и промежуточный сертификат в один файл .crt. Например:

cat server.crt intermediate.crt >> /var/opt/opscode/nginx/ca/FQDN.crt

Проверка того, что сертификат был подписан правильным ключом

Возможна ситуация несоответствия сертификата/ключа во время процесса CertificateSigningRequest (CSR). Во время CSR всегда должен использоваться исходный ключ для данного сервера. Если результаты следующих команд не совпадают, то возможно, что CSR для нового ключа для этого хоста был сгенерирован с использованием случайного ключа или вновь сгенерированного ключа. Симптомы этой проблемы будут похожи на следующее в файлах журналов nginx:

nginx: [emerg] SSL_CTX_use_PrivateKey_file("/var/opt/opscode/nginx/ca/YOUR_HOSTNAME.key") failed (SSL: error:0B080074:x509    certificate routines:X509_check_private_key:key values mismatch)

Вот как точно определить, когда настроенный сертификат не соответствует ключу

## openssl x509 -in /var/opt/opscode/nginx/ca/chef-432.lxc.crt -noout -modulus | openssl sha1
(stdin)= 05b4f62e52fe7ce2351ff81d3e1060c0cdf1fa24

## openssl rsa -in /var/opt/opscode/nginx/ca/chef-432.lxc.key -noout -modulus | openssl sha1
(stdin)= 05b4f62e52fe7ce2351ff81d3e1060c0cdf1fa24

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

Перегенерировать сертификаты

Периодически необходимо перегенерировать сертификаты SSL. Это важная часть защиты Chef Infra Server от уязвимостей и помогает предотвратить компрометацию информации, хранящейся на Chef Infra Server.

Чтобы перегенерировать сертификаты SSL:

Выполните следующую команду:
```
chef-server-ctl stop
```
Chef Infra Server может перегенерировать их. Эти сертификаты будут находиться в /var/opt/opscode/nginx/ca/ и будут названы в соответствии с FQDN для Chef Infra Server. Для определения FQDN сервера выполните следующую команду:
```
hostname -f
```
Пожалуйста, удалите файлы, найденные в каталоге ca с именами, подобными $FQDN.crt и $FQDN.key.
Если ваша организация предоставила настроенные сертификаты SSL для Chef Infra Server, расположение этих настроенного сертификата и закрытого ключа определены в /etc/opscode/chef-server.rb в качестве значений для nginx['ssl_certificate'] и nginx['ssl_certificate_key'] настроек. Удалите файлы, указанные в этих двух настройках, и перегенерируйте новые ключи, используя тот же центр сертификации.
Выполните следующую команду, сервер Chef автоматически создаст необходимые SSL сертификаты, если необходимо:
```
chef-server-ctl reconfigure
```
Выполните следующую команду:
```
chef-server-ctl start
```

Управление учетными данными Chef Infra Server

Новое в Chef Server 12.14: Chef Infra Server ограничивает места, куда он записывает пароли и ключи службы на диск. В конфигурации по умолчанию учетные данные записываются только в файлы в /etc/opscode.

По умолчанию Chef Infra Server по-прежнему записывает учетные данные службы в несколько мест внутри /etc/opscode. Это сделано для поддержания совместимости с дополнениями. Chef Server 12.14 добавляет конфигурационный параметр insecure_addon_compat в /etc/opscode/chef-server.rb, который позволяет дополнительно ограничивать места записи учетных данных. insecure_addon_compat может использоваться, если вы не используете дополнения или используете последние версии дополнений. Установка insecure_addon_compat в false записывает учетные данные только в одно место: /etc/opscode/private-chef-secrets.json.

Секретные данные, предоставленные пользователем (например, пароль внешнего экземпляра PostgreSQL), по-прежнему можно задать в /etc/opscode/chef-server.rb или с помощью команд Управление секретами. Эти команды позволяют предоставлять внешние пароли без включения их в файл конфигурации.

Совместимость плагинов

В следующей таблице указаны версии плагинов, поддерживающие более ограниченное значение insecure_addon_compat false. Эти версии также требуют Chef Server 12.14.0 или более поздней версии:

Название плагина	Минимальная версия
Chef Backend	все
Chef Manage	2.5.0
Push Jobs Server	2.2.0

Эти новые плагины также будут записывать все свои секреты в /etc/opscode/private-chef-secrets.json. Более старые версии плагинов по-прежнему будут записывать свою конфигурацию в места в /etc и /var/opt.

/etc/opscode/private-chef-secrets.json

По умолчанию разрешения файла /etc/opscode/private-chef-secrets.json разрешают чтение и запись файла только пользователю root. Этот файл содержит все секреты для доступа к базовым хранилищам данных сервера Chef, поэтому доступ к нему должен быть ограничен авторизованными пользователями.

Хотя файл не содержит паролей в открытом виде, его не безопасно предоставлять ненадёжным пользователям. Формат файла секретов позволяет развертываниям Chef Infra Server соответствовать правилам, запрещающим появление конфиденциальных данных в открытом виде в файлах конфигурации; однако, это не делает файл существенно более безопасным.

Шифрование SSL между Chef Infra Server и внешним PostgreSQL

Новое в Chef Infra Server 13.1.13: Chef Infra Server 13.1.13 добавляет возможность шифровать трафик между Chef Infra Server и внешним сервером PostgreSQL с использованием SSL. Данные инструкции не являются исчерпывающими и предполагают некоторую осведомленность в администрировании, настройке и устранении неполадок PostgreSQL. Для получения дополнительной информации обратитесь к документации PostgreSQL.

Ниже приведен типичный сценарий включения шифрования между машиной, на которой работает Chef Infra Server, и внешней машиной, на которой работает PostgreSQL. Обе машины должны быть соединены в сети и доступны пользователю.

Выполните следующую команду на обеих машинах для получения прав root:
```
sudo -i
```
Убедитесь, что OpenSSL установлен на машине PostgreSQL.
Убедитесь, что поддержка SSL скомпилирована в PostgreSQL. Это относится как к компиляции исходного кода, так и к использованию предварительно скомпилированного двоичного файла.
Поместите сертификаты SSL в соответствующие каталоги на машине PostgreSQL и убедитесь, что у них правильные имена файлов, владельцы и права доступа.
Включите SSL в PostgreSQL, отредактировав файл postgresql.conf. Установите ssl = on и укажите пути к сертификатам SSL:
```
ssl=on

ssl_cert_file='/path/to/cert/file'
ssl_key_file='/path/to/key/file'
```
Чтобы предотвратить принятие PostgreSQL не-SSL соединений, отредактируйте файл pg_hba.conf на машине PostgreSQL и измените соответствующие соединения Chef Infra Server на hostssl.

Вот пример файла pg_hba.conf с подключениями hostssl для Chef Infra Server (содержимое вашего файла pg_hba.conf будет отличаться):
```
# "local" is for Unix domain socket connections only
local      all             all                                     peer

# IPv4 local connections:
hostssl    all             all             127.0.0.1/32            md5

# IPv6 local connections:
hostssl    all             all             ::1/128                 md5

# nonlocal connections
hostssl    all             all            192.168.33.100/32        md5
```
Перезапустите PostgreSQL. Это обычно можно сделать с помощью следующей команды на машине PostgreSQL:
```
/path/to/postgresql/postgresql restart
```
Отредактируйте /etc/opscode/chef-server.rb на сервере Chef Infra Server и добавьте следующую строку:
```
postgresql['sslmode'] = 'require'
```
Выполните reconfigure на сервере Chef Infra Server:
```
chef-server-ctl reconfigure
```

Проверьте, что SSL включен и что SSL соединения работают между Chef Infra Server и вашим PostgreSQL. Один из способов сделать это — войти в базу данных PostgreSQL с сервера Chef Infra Server, выполнив chef-server-ctl psql, а затем изучить состояние SSL с помощью SQL запросов.

Запустите сеанс psql:

chef-server-ctl psql opscode_chef

В сеансе psql введите postgres=# show ssl; для проверки включения ssl:

postgres=# show ssl;

 ssl
-----
 on
(1 row)

Затем введите postgres=# select * from pg_stat_ssl; для возврата true (t) в строках с SSL-соединениями:

postgres=# select * from pg_stat_ssl;

  pid  | ssl | version |           cipher            | bits | compression | clientdn
-------+-----+---------+-----------------------------+------+-------------+----------
 16083 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16084 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16085 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16086 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16087 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16088 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16089 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16090 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16091 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16092 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16093 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16094 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16095 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16096 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16097 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16098 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16099 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16100 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16101 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16102 | t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |  256 | f           |
 16119 | f   |         |                             |      |             |
(21 rows)

Ротация ключей

См. команды chef-server-ctl для ротации ключей для получения дополнительной информации об управлении ключами пользователей.

© Chef Software, Inc.
Licensed under the Creative Commons Attribution 3.0 Unported License.
The Chef™ Mark and Chef Logo are either registered trademarks/service marks or trademarks/servicemarks of Chef, in the United States and other countries and are used with Chef Inc's permission.
We are not affiliated with, endorsed or sponsored by Chef Inc.
https://docs.chef.io/runbook/server_security/