Методы аутентификации. TLS сертификаты

Данный механизм может использовать внешние сертификаты X.509 в качестве части проверки TLS или подписания. Проверка подписей по сертификатам X.509, использующим SHA-1, является устаревшей и больше не используется без обходного пути. Дополнительную информацию см. в разделе FAQ об устаревании.

Метод аутентификации cert позволяет выполнять аутентификацию с помощью клиентских сертификатов SSL/TLS, подписанных либо центром сертификации, либо самоподписанных. Сертификаты клиентов SSL/TLS должны содержать расширение ExtKeyUsage с параметром использования ClientAuth или Any.

Доверенные сертификаты и центры сертификации настраиваются непосредственнов методе аутентификации, задавая путь certs/. Этот метод не может считывать доверенные сертификаты из внешнего источника.

Сертификаты CA ассоциируются с ролью; имена ролей и имена CRL нормализованы к нижнему регистру.

Обратите внимание, что для использования этого метода авторизации значения tls_disable и tls_disable_client_certs в конфигурации StarVault должны быть равны false. Это связано с тем, что сертификаты отправляются через TLS-соединение.

1. Проверка отзыва

Метод поддерживает проверку отзыва.

Авторизованный пользователь может отправить CRL в формате PEM, идентифицированные по заданному имени; их можно обновлять или удалять по своему усмотрению. Также авторизованный пользователь может задать URL-адрес доверенной точки распространения CRL и попросить StarVault получить CRL по мере необходимости.

Когда CRL присутствуют, во время аутентификации клиента:

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

Этот метод обеспечивает хорошую безопасность и в то же время допускает гибкость. Например, если промежуточный ЦС (центр сертификации) будет отозван, клиент может быть настроен с двумя цепочками сертификатов: одна содержит начальный промежуточный ЦС в пути, а другая — замену. Если первоначальный промежуточный центр сертификации будет отозван, цепочка, содержащая замену, позволит клиенту успешно пройти аутентификацию.

N.B.: Сопоставление выполняется только по серийному номеру. Для большинства ЦС, включая метод pki в StarVault, можно успешно использовать несколько CRL, поскольку серийные номера глобально уникальны. Однако, поскольку в RFC указано, что серийные номера должны быть уникальными только для каждого CA, некоторые CA выдают серийные номера в порядке очереди, что может привести к конфликтам при попытке использовать CRL от двух таких CA в одном монтировании метода. Обходным решением в этом случае является монтирование нескольких копий метода cert, настройка каждой из них с одним CA/CRL и подключение клиентов к соответствующему монтированию.

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

В дополнение к автоматическому или ручному управлению CRL, для настроенного сертификата может быть включен OCSP, в этом случае StarVault будет запрашивать OCSP-сервер, указанный в представленном сертификате или настроенный в методе auth, для проверки отзыва.

2. Аутентификация

2.1. С помощью CLI

Ниже приведена аутентификация по роли web cert путем предоставления сертификата (cert.pem) и ключа (key.pem), подписанных ЦС, связанным с ролью web cert. Обратите внимание, что имя web связано с приведенным ниже примером конфигурации, записывающим путь auth/cert/certs/web. Если имя роли сертификата не указано, метод auth будет пытаться аутентифицироваться по всем доверенным сертификатам.

Значение -ca-cert здесь используется для сертификата ЦС Слушателя StarVault TLS, а не для ЦС, выпустившего сертификат аутентификации клиента. Это значение можно опустить, если ЦС, используемый для выдачи сертификата сервера StarVault, является доверенным для локальной системы, выполняющей эту команду.

starvault login \
    -method=cert \
    -ca-cert=starvault-ca.pem \
    -client-cert=cert.pem \
    -client-key=key.pem \
    name=web

2.2. С помощью API

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

Значение --cacert здесь используется для сертификата ЦС Слушателя StarVault TLS, а не для ЦС, выпустившего сертификат аутентификации клиента. Это значение можно опустить, если ЦС, используемый для выдачи сертификата сервера StarVault, является доверенным для локальной системы, выполняющей эту команду.

curl \
    --request POST \
    --cacert starvault-ca.pem \
    --cert cert.pem \
    --key key.pem \
    --data '{"name": "web"}' \
    https://127.0.0.1:8200/v1/auth/cert/login

3. Конфигурация

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

Включите метод аутентификации с помощью сертификата:
```
starvault auth enable cert
```
Настройте метод с помощью доверенных сертификатов, которым разрешена аутентификация:
```
starvault write auth/cert/certs/web \
    display_name=web \
    policies=web,prod \
    certificate=@web-cert.pem \
    ttl=3600
```
При этом создается новый доверенный сертификат "web" с тем же именем отображения и политиками "web" и "prod". Сертификат (открытый ключ), используемый для проверки клиентов, задается файлом "web-cert.pem". Наконец, можно указать необязательное значение ttl в секундах, чтобы ограничить продолжительность аренды.

4. API

Метод аутентификации с помощью сертификата TLS имеет полноценный HTTP API. Более подробная информация приведена в разделе API сертификата TLS.