Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий) – PKI Extensions

Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий) - PKI Extensions Сертификаты
Содержание
  1. Введение
  2. Организация взаимодействия клиента и сервера, основанного исключительно на доверии к удостоверяющему центру
  3. Запуск сервера
  4. Создание удостоверяющего центра
  5. Создание файла запроса на подпись сертификата
  6. Подписание сертификата с помощью запроса на подпись сертификата
  7. Аутентификация клиента (двусторонний TLS)
  8. Замена неподписанного сертификата подписанным
  9. Api3:2021 excessive data exposure (разглашение конфиденциальных данных)
  10. Api4:2021 lack of resources & rate limiting (отсутствие проверок и ограничений)
  11. Api8:2021 injection (внедрение)
  12. Content-security-policy
  13. X-frame-options (защита от clickjacking)
  14. Авторизация
  15. Аппаратные токены
  16. Аудит событий
  17. Аутентификация
  18. Биометрия
  19. Бывают ли разные типы sso?
  20. В чем разница между программным обеспечением единого входа и решением sso?
  21. Другие виды сертификатов
  22. Как работает sso?
  23. Многофакторная (двухфакторная) аутентификация
  24. Общая схема аутентификации по сертификатам
  25. Особенности аутентификации контроллера домена с использованием двух разных сертификатов
  26. Пароли
  27. Политика аудита
  28. Примеры сущностей rbac
  29. Стандарты безопасности
  30. Выводы
  31. Логон смарт-картой или pkinit
  32. Итоги

Введение

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

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

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

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

Обратимся к существующим методам аутентификации и освежим в памяти то, насколько они соответствуют требованиям времени – в том числе применительно к отечественной специфике.

Организация взаимодействия клиента и сервера, основанного исключительно на доверии к удостоверяющему центру

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

Сделаем это, выполнив на клиенте следующую команду:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore client/src/test/resources/truststore.jks -storepass secret -noprompt

На сервере выполним такую команду:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret -noprompt

В хранилищах TrustStore всё ещё хранятся собственные сертификаты клиента и сервера. Эти сертификаты нужно удалить.

Выполним на клиенте такую команду:

keytool -v -delete -alias server -keystore client/src/test/resources/truststore.jks -storepass secret

Вот — команда для сервера:

keytool -v -delete -alias client -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret

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

Запуск сервера


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

  1. Java 11
  2. Maven 3.5.0
  3. Eclipse, Intellij IDEA (или любой другой текстовой редактор вроде VIM)
  4. Доступ к терминалу
  5. Копия этого проекта

Если вы хотите приступить к экспериментам и при этом ничего не устанавливать — можете

вышеупомянутый проект в онлайновой среде разработки Gitpod.

В данном проекте содержится Maven-обёртка, поэтому запустить его можно и не устанавливая Maven. Тут будут приведены сведения и о стандартных командах, рассчитанных на mvn, и о командах, ориентированных на использование Maven-обёртки.

Если вы хотите запустить этот проект с использованием Java 8 — вы можете переключиться на более старую его версию с использованием нижеприведённой команды.

git checkout tags/java-8-compatible

При работе с этой версией проекта рекомендовано следовать инструкциям, подготовленным специально для него. Найти их можно

Сервер можно привести в рабочее состояние, вызвав метод main класса App или выполнив следующую команду в корневой директории проекта:

cd server/ && mvn spring-boot:run

Вот команда, рассчитанная на Maven-обёртку:

cd server-with-spring-boot/ && ./../mvnw spring-boot:run

Создание удостоверяющего центра

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

keytool -v -genkeypair -dname "CN=Root-CA,OU=Certificate Authority,O=Thunderberry,C=NL" -keystore root-ca/identity.jks -storepass secret -keypass secret -keyalg RSA -keysize 2048 -alias root-ca -validity 3650 -deststoretype pkcs12 -ext KeyUsage=digitalSignature,keyCertSign -ext BasicConstraints=ca:true,PathLen:3


Ещё можно воспользоваться

удостоверяющим центром.

Создание файла запроса на подпись сертификата

Для того чтобы подписать сертификат — нужен .csr-файл (Certificate Signing Request, файл запроса на подпись сертификата). Создать его можно с помощью особой команды.

Вот её вариант для сервера:

keytool -v -certreq -file shared-server-resources/src/main/resources/server.csr -keystore shared-server-resources/src/main/resources/identity.jks -alias server -keypass secret -storepass secret -keyalg rsa

Вот — эта команда для клиента:

keytool -v -certreq -file client/src/test/resources/client.csr -keystore client/src/test/resources/identity.jks -alias client -keypass secret -storepass secret -keyalg rsa

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

Подписание сертификата с помощью запроса на подпись сертификата


Вот соответствующая команда для клиента:

keytool -v -gencert -infile client/src/test/resources/client.csr -outfile client/src/test/resources/client-signed.cer -keystore root-ca/identity.jks -storepass secret -alias root-ca -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth

Вот команда для сервера:

keytool -v -gencert -infile shared-server-resources/src/main/resources/server.csr -outfile shared-server-resources/src/main/resources/server-signed.cer -keystore root-ca/identity.jks -storepass secret -alias root-ca -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth -ext SubjectAlternativeName:c=DNS:localhost,IP:127.0.0.1

Аутентификация клиента (двусторонний TLS)

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

client-auth

, сообщив серверу о том, что ему нужно проверять клиентов.

Приведём файл сервера application.yml к такому виду:

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:identity.jks
    key-password: secret
    key-store-password: secret
    client-auth: need

Если после этого запустить клиент, то он выдаст следующее сообщение об ошибке:

javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

Это указывает на то, что клиент не обладает подходящим сертификатом. Точнее — у клиента пока вообще нет сертификата. Поэтому создадим сертификат следующей командой:

keytool -v -genkeypair -dname "CN=Suleyman,OU=Altindag,O=Altindag,C=NL" -keystore client/src/test/resources/identity.jks -storepass secret -keypass secret -keyalg RSA -keysize 2048 -alias client -validity 3650 -deststoretype pkcs12 -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth

Нам ещё нужно создать TrustStore для сервера. Но, прежде чем создавать это хранилище, нужно иметь сертификат клиента. Экспортировать его можно так:

keytool -v -exportcert -file client/src/test/resources/client.cer -alias client -keystore client/src/test/resources/identity.jks -storepass secret -rfc


Теперь создадим TrustStore сервера, в котором будет сертификат клиента:

keytool -v -importcert -file client/src/test/resources/client.cer -alias client -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret -noprompt

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

Приведём файл application.yml клиента к такому виду:

client:
  ssl:
    one-way-authentication-enabled: false
    two-way-authentication-enabled: true
    key-store: identity.jks
    key-password: secret
    key-store-password: secret
    trust-store: truststore.jks
    trust-store-password: secret

Сервер тоже не знает о только что созданном для него TrustStore. Приведём его файл

application.yml

к такому виду:

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:identity.jks
    key-password: secret
    key-store-password: secret
    trust-store: classpath:truststore.jks
    trust-store-password: secret
    client-auth: need


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

Примите поздравления! Только что вы настроили двусторонний TLS!

Замена неподписанного сертификата подписанным

В хранилище идентификационных данных сервера и клиента всё ещё хранится неподписанный сертификат. Сейчас можно заменить его на подписанный. У инструмента

keytool

есть одна не вполне понятная особенность. А именно — он не позволяет напрямую импортировать в хранилище подписанный сертификат. Если попытаться это сделать — будет выведено сообщение об ошибке. Сертификат, подписанный удостоверяющим центром, должен быть представлен в файле

identity.jks

Экспортируем подписанный сертификат:

keytool -v -exportcert -file root-ca/root-ca.pem -alias root-ca -keystore root-ca/identity.jks -storepass secret -rfc

Выполним на клиенте следующие команды:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore client/src/test/resources/identity.jks -storepass secret -noprompt
keytool -v -importcert -file client/src/test/resources/client-signed.cer -alias client -keystore client/src/test/resources/identity.jks -storepass secret
keytool -v -delete -alias root-ca -keystore client/src/test/resources/identity.jks -storepass secret

На сервере выполним такие команды:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret -noprompt
keytool -v -importcert -file shared-server-resources/src/main/resources/server-signed.cer -alias server -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret
keytool -v -delete -alias root-ca -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret

Api3:2021 excessive data exposure (разглашение конфиденциальных данных)

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

Эти данные зачастую сериализируются в JSON без проверок и отправляется клиенту с предположением, что клиент сам отфильтрует нужные данные. Но проблема в том, что запрос может отправить не только клиент, а может сформировать злоумышленник напрямую к серверу и получить конфиденциальные данные. Например, безобидный запрос данных по пользователю с ID 1:

Api4:2021 lack of resources & rate limiting (отсутствие проверок и ограничений)

Необходимо защитить сервер от атак по подбору пароля (brute force attack). Для этого нужно реализовать следующие ограничения:


Для JS существуют средства, позволяющие делать такие проверки автоматически (например,

) и сразу посылать ответ «429 Too Many Requests», не нагружая сервер.

Необходимо защитить сервер и от отказа в обслуживании (DoS-атаки)

Например, сервер ожидает в параметре size число записей:

Api8:2021 injection (внедрение)


Внедрение — это выполнение программного кода, не предусмотренного системой. Разделяют внедрения:

Про сертификаты:  Защита RDP соединения при помощи SSL. - Записки IT специалиста

Атака будет успешна, если сервер выполняет полученные команды без проверки. Чем-то напоминает «небезопасную десериализацию», только используются не дополнительные атрибуты, а SQL код или команды OS. В результате SQL инъекции можно получить несанкционированный доступ к данным.

GET /run

Content-security-policy

Позволяет защититься от атаки Cross-site scripting и других кросс-сайтовых инъекций, в том числе Clickjacking. Требует вдумчивого конфигурирования, т.к. параметров много. Но надо хотя бы поставить дефолтную политику, что предотвратит возможность атаки Cross-site Scripting:

Content-Security-Policy: default-src 'self'


Подробно значения заголовка Content-Security-Policy разбираются, например,

X-frame-options (защита от clickjacking)

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

X-Frame-Options: deny

или разрешить использование только в нашем домене:

X-Frame-Options: sameorigin

А лучше для предотвращения атаки Clickjacking использовать более современный механизм и установить правильную политику безопасности

Content-Security-Policy

Авторизация


Аутентифицированная учетная запись по умолчанию не имеет прав на действия в кластере. Для предоставления разрешений в Kubernetes реализован механизм авторизации.

До версии 1.6 в Kubernetes применялся тип авторизации, называемый ABAC (Attribute-based access control). Подробности о нём можно найти в официальной документации. В настоящее время этот подход считается устаревшим (legacy), однако вы всё ещё можете использовать его одновременно с другими типами авторизации.

Актуальный же (и более гибкий) способ разделения прав доступа к кластеру называется RBAC (Role-based access control). Он был объявлен стабильным с версии Kubernetes 1.8. RBAC реализует модель прав, в которой запрещено всё, что не разрешено явно.

Чтобы включить RBAC, нужно запустить Kubernetes api-server с параметром –authorization-mode=RBAC. Параметры выставляются в манифесте с конфигурацией api-server, которая по умолчанию находится по пути /etc/kubernetes/manifests/kube-apiserver.yaml, в секции command.

Впрочем, по умолчанию RBAC и так включен, поэтому скорее всего беспокоиться об этом не стоит: убедиться в этом можно по значению authorization-mode (в уже упомянутом kube-apiserver.yaml). К слову, среди его значений могут оказаться и другие типы авторизации (node, webhook, always allow), но их рассмотрение оставим за рамками материала.

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

Для управления доступом в Kubernetes через RBAC используются следующие сущности API:

Сущности Role и RoleBinding являются ограниченными namespace’ом, т.е. должны находиться в пределах одного пространства имен. Однако RoleBinding может ссылаться на ClusterRole, что позволяет создать набор типовых разрешений и управлять доступом с их помощью.

Роли описывают права при помощи наборов правил, содержащих:

Более подробный разбор авторизации в Kubernetes можно найти на странице

. Вместо этого (а точнее — в дополнение к этому) приведу примеры, которые иллюстрируют её работу.

Аппаратные токены

Аппаратный токен – это устройство, предназначенное специально для аутентификации.

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

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

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

Рисунок 2. Аппаратный токен с генерацией одноразовых ключей RSA SecurID

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

Каким бы именно образом ни работал аппаратный токен, для системы будет подлинным тот пользователь, который держит устройство в руках. Так же, как и в двух предыдущих случаях, наличие токена никоим образом не связано с конкретным человеком: устройство можно украсть и использовать злонамеренно.

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

Аудит событий

Схематично архитектуру Kubernetes можно представить следующим образом:

Ключевой компонент Kubernetes, отвечающий за обработку запросов, — api-server. Все операции над кластером проходят через него. Подробнее об этих внутренних механизмах можно почитать в статье «Что происходит в Kubernetes при запуске kubectl run?».

Аудит системы — интересная фича в Kubernetes, которая по умолчанию выключена. Она позволяет логировать все обращения к Kubernetes API. Как легко догадаться, через этот API производятся все действия, связанные с контролем и изменением состояния кластера.

Итак, чтобы включить аудит, нам нужно передать контейнеру в api-server три обязательных параметра, подробнее о которых рассказано ниже:

Помимо этих трёх необходимых параметров, существует множество дополнительных настроек, относящихся к аудиту: от ротации логов до описаний webhook. Пример параметров ротации логов:

Но останавливаться подробнее на них не будем — найти все детали можно в

Как уже упоминалось, все параметры выставляются в манифесте с конфигурацией api-server (по умолчанию /etc/kubernetes/manifests/kube-apiserver.yaml), в секции command. Вернемся к 3 обязательным параметрам и разберём их:

  1. audit-policy-file — путь до YAML-файла с описанием политики (policy) аудита. К его содержимому мы ещё вернёмся, а пока замечу, что файл должен быть доступен для чтения процессом api-server’а. Поэтому необходимо смонтировать его внутрь контейнера, для чего можно добавить следующий код в соответствующие секции конфига:
      volumeMounts:
        - mountPath: /etc/kubernetes/policies
          name: policies
          readOnly: true
      volumes:
      - hostPath:
          path: /etc/kubernetes/policies
          type: DirectoryOrCreate
        name: policies
  2. audit-log-path — путь до файла лога. Путь также должен быть доступен процессу api-server’a, поэтому аналогично описываем его монтирование:
      volumeMounts:
        - mountPath: /var/log/kube-audit
          name: logs
          readOnly: false
      volumes:
      - hostPath:
          path: /var/log/kube-audit
          type: DirectoryOrCreate
        name: logs
  3. audit-log-format — формат лога аудита. По умолчанию это json, но доступен и устаревший текстовый формат (legacy).

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

В Kubernetes есть два типа пользователей:

Основное отличие этих типов в том, что для Service Accounts существуют специальные объекты в Kubernetes API (они так и называются —

ServiceAccounts

), которые привязаны к пространству имён и набору авторизационных данных, хранящихся в кластере в объектах типа Secrets. Такие пользователи (Service Accounts) предназначены в основном для управления правами доступа к Kubernetes API процессов, работающих в кластере Kubernetes.

Биометрия

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

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

Тем не менее, пока что технологии считывания этих показателей не вполне совершенны, и специалисты еще не могут рекомендовать полагаться всецело на биометрию. Известны случаи, когда исследователям удавалось обмануть считыватели с помощью распечаток на 3D-принтерах или даже просто фотографий в высоком разрешении.

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

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

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

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

Бывают ли разные типы sso?

Когда мы говорим о едином входе (SSO), используется множество терминов:

На самом деле, SSO это часть более крупной концепции под названием Federated Identity Management, поэтому иногда SSO обозначается, как федеративная SSO. FIM просто относится к доверительным отношениям, созданным между двумя или более доменами или системами управления идентификацией. Система единого входа (SSO) — это характеристика/фича, доступная внутри архитектуры FIM.

OAuth 2.0 — это особая программная платформа, которая также может считаться частью архитектуры FIM. OAuth фокусируется на доверительных отношениях, предоставляя доменам идентификационную информацию пользователя.

Про сертификаты:  Сертификация продукции в Москве. Оформление сертификатов и выдача сертификатов (получение) в центре сертификации Гостест

OpenID Connect (OIDC) — это уровень аутентификации, наложенный на базу OAuth 2.0, чтобы обеспечить фунциональность SSO.

Security Access Markup Language (SAML) — это открытый стандарт, который также разработан для обеспечения функциональности SSO.

image

Система Same Sign On, которую часто обозначают, как SSO, на самом деле, не похожа Single Sign-on, т.к не предполагает наличие доверительных отношений между сторонами, которые проходят аутентификацию. Она более привязана к идентификационным данным, которые дублируются и передаются в другие системы когда это необходимо. Это не так безопасно, как любое из решений единого входа.

Также существуют несколько конкретных систем, которые стоит упомянуть, говоря о платформе SSO: Active Directory, Active Directory Federation Services (ADFS) и Lightweight Directory Service Protocol (LDAP).

Active Directory, который в настоящее время именуется, как Active Directory Directory Services (ADDS) — это централизованная служба каталогов Microsoft. Пользователи и ресурсы добавляются в службу каталогов для централизованного управления, а ADDS работает с такими аутентификационными протоколами, как NTLM и Kerberos.

Active Directory Federation Services (ADFS) это тип управления федеративной идентификацией (Federated Identity Management system), которая также предполагает возможность Single Sign-on. Он также поддерживает SAML и OIDC. ADFS преимущественно используется для установления доверительных отношений между ADDS и другими системами, такими как Azure AD или других служб ADDS.

Протокол LDAP (Lightweight Directory Service Protocol) — это стандарт, определяющий способ запроса и организации информационной базы. LDAP позволяет вам централизованно управлять такими ресурсами, как пользователи и системы. LDAP, однако, не определяет порядок авторизации, это означает, что он не устанавливает непосредственный протокол, используемый для аутентификации.

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

В чем разница между программным обеспечением единого входа и решением sso?

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

Обычно это то, что разработано для определенного набора задач и ничего более. Программный продукт предполагает, что есть возможность расширяться и кастомизировать потенциальные возможности исходного варианта. Провайдер будет отличным вариантом, чтобы обратиться к компании, которая производит или пользуется программным продуктом. Например, OneLogin в качестве провайдера SSO.

Другие виды сертификатов

Напоследок хотелось бы сказать, что помимо обозначенной градации сертификатов — DV, OV, EV — существуют и другие типы сертификатов. Например, сертификаты могут отличаться по количеству доменов, на которые они выдаются. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, указываемому при покупке.

сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, но за каждое наименование, включаемое в список сверх обозначенного количества, придется доплачивать отдельно.

Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать помимо доменов несколько поддоменов.

В таких случаях стоит приобретать сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL. Отметим, что в этом случае можно также приобрести обычный мультидоменный сертификат, в котором просто указать необходимые поддомены.

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

P.S. Несколько материалов по теме из нашего блога:

Как работает sso?

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

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

Порядок авторизации обычно выглядит следующим образом:

Многофакторная (двухфакторная) аутентификация

Идеология многофакторной аутентификации (multi-factor authentication, MFA) заключается в том, чтобы взаимно компенсировать недостатки нескольких отдельных факторов, как минимум двух, у которых различаются ключевые риски. Чаще всего на практике используется двухфакторная аутентификация.

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

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

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

Например, Symantec предлагает сервис VIP – Validation and Identity Protection (бывший VeriSign Identity Protection), который не бесплатен, но предлагает довольно разнообразные функции вроде бесконтактной разблокировки, когда сотруднику не нужно ничего вставлять в считыватель или подносить к нему – достаточно находиться рядом.

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

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

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

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

Общая схема аутентификации по сертификатам

Когда пользователь аутентифицируется при помощи сертификата на веб-сайте, происходит примерно следующий процесс:

  1. Пользователь запрашивает доступ к некоторой сетевой службе;
  2. По запросу сервер посылает клиенту свой серверный сертификат (сертификат SSL). Клиент проверяет его на валидность. Если проверка провалилась, на этом всё заканчивается;
  3. Если проверка прошла успешно, клиент запрашивает доступ к ресурсам службы;
  4. Служба сконфигурирована на обязательную аутентификацию пользователя и отправляет клиенту доступные (на сервере) методы аутентификации. В нашем случае это требование клиентского сертификата;
  5. Клиент посылает на сервер публичную часть своего сертификата и некоторый объём подписанных клиентским сертификатом данных. Сервер проверяет клиентский сертификат на валидность. Если сертификат не прошёл проверку — разговор клиента и сервера на этом завершается. Если сертификат прошёл проверку, сервер пытается сопоставить (или ассоциировать) сертификат с учётной записью пользователя. Если сопоставление не удалось — разговор завершается.
  6. Если учётная запись найдена и сертификат удалось сопоставить с ней, сервер начинает установку защищённого канала. После установки этого канала, сервер предоставляет пользователю ресурсы в том объёме, в котором это позволяют списки доступа (ACL, например).

Я посчитал нужным немного развернуть последний пункт, чтобы вы понимали общее устройство этого канала (поскольку, у людей есть некоторые заблуждения на этот счёт):

  1. Клиент запрашивает установку безопасного канала;
  2. Сервер отвечает согласием и пересылает клиенту список поддерживаемых симметричных протоколов шифрования;
  3. Клиент посылает на сервер свой список протоколов симметричного шифрования;
  4. Клиент и сервер договариваются и выбирают наиболее подходящий протокол. Например, — Я умею DES и 3DES, а что умеешь ты? — А я умею только 3DES и AES. — Отлично, давай тогда использовать 3DES;
  5. Клиент на своей стороне генерирует сессионный симметричный ключ шифрования и шифрует его открытым ключом сертификата сервера. Этот процесс называется Key exchange. Как мы знаем, прочитать этот ключ сможет только веб сервер, т.к. только он владеет закрытым ключом, который ассоциирован с конкретным сертификатом SSL;
  6. После этого, все передаваемые данные шифруются именно этим сессионным ключом. Помните, что при передаче данных сертификаты уже не используются (а многие считают, что все данные шифруются открытыми ключами сертификатов). Сертификаты используются только при обновлении сессионного ключа (который периодически меняется).

Немного другой процесс происходит при интерактивном логоне или логоне на сервер терминалов посредством Remote Desktop при помощи смарт-карты.

Особенности аутентификации контроллера домена с использованием двух разных сертификатов

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

image

Схожая проблема возникла в одном из наших проектов, где заказчику необходимо было организовать аутентификацию пользователей в домене Microsoft Windows по сертификатам ГОСТ. Обычно подобные задачи решаются путем использования специализированного средства компании «КРИПТО-ПРО», а именно «КриптоПро Winlogon». Данный продукт существует на рынке достаточно давно и максимально проработан, но иногда могут возникать непредвиденные сложности при его внедрении, с которыми нашей компании и пришлось столкнуться. Для его функционирования необходимо соответствующим образом настроить рабочую станцию, домен и контроллеры домена. Одним из требований при настройке контроллера домена в данном случае является выпуск сертификата на ГОСТ.

Про сертификаты:  Купить 374042800, Лампа натриевая ДНаТ 100Вт Е40 Лисма по цене 365.76 р. в наличии

В случае с нашим заказчиком возникла ситуация, при которой для доступа к контроллеру домена используется, кроме протокола LDAP, еще и LDAP через SSL (LDAPS) с использованием уже установленного на контроллере сертификата RSA.

Небольшое отступление: по умолчанию трафик LDAP не защищен, что предоставляет возможность осуществлять мониторинг трафика между LDAP–клиентом и сервером. Чтобы обеспечить передачу трафика LDAP в безопасном режиме, необходимо использовать технологию SSL/TLS, сокращенно такая технология называется LDAPS.

LDAPS рекомендуется использовать в следующих случаях:

Таким образом, в нашей ситуации для работы LDAP over SSL/TLS (LDAPS) требуется установить сертификат на контроллер домена. Для активации LDAPS необходимо установить доверенный сертификат, выданный центром сертификации (которому доверяют контроллер домена и клиенты LDAPS) в хранилище сертификатов локального компьютера.

В связи с этим и возник вопрос совместного использования двух сертификатов, причем на различных криптографических алгоритмах при условии использования решения КриптоПро Winlogon, которое не предполагает одновременного использования двух сертификатов на контроллере домена.

Комментарий из инструкции:

image

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

Итак, как же работает выбор сертификата контроллером домена?

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

Однако в Windows Server существует возможность легитимного использования нескольких сертификатов. Для этого используется отдельное хранилище Active Directory Domain Services (NTDSPersonal), в котором хранится сертификат для доступа по LDAPS.

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

Чтобы просмотреть хранилище сертификатов сервисов на контролере домена, необходимо запустить консоль управления (MMC) и добавить оснастку «Сертификаты». Далее с помощью диспетчера сертификатов следует выбрать тип управления сертификатами.

image

Затем необходимо выбрать учетную запись Active Directory Domain Services.

image

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

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

image

В ходе стендирования были сделаны следующие шаги:

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

Пароли

Классика удостоверения личности в информационных системах – пароль. Он так прочно ассоциируется с аутентификацией, что иногда считается ее сущностью. Например, в ГОСТе по судебно-технической экспертизе (Р 57429-2021) значится, что аутентификация пользователя – это «процедура проверки подлинности пользователя путём сравнения введенного им пароля с паролем, сохраненным в базе данных пользователей».

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

Помимо этого, средний пользователь современного Интернета зарегистрирован на десятках (если не на сотне-другой) разных ресурсов и сервисов, и каждый из них требует от него пароль. Один пароль на все сайты удобен, но небезопасен. Отдельный пароль для каждого сайта безопасен, но неудобен, поскольку пользователь нуждается либо в великолепной памяти, либо в хранилище для кодовых слов (которое опять же можно взломать).

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

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

Впрочем, обработку одноразовых паролей можно переложить на «подрядчика»: скажем, Google предлагает всем желающим воспользоваться приложением Authenticator, которое берет работу с одноразовыми паролями на себя. В этом случае можно не разрабатывать свою систему, а воспользоваться уже существующей – что и делает, например, популярное геймерское приложение Discord. Впрочем, это – уже тема для разговора о двухфакторной аутентификации.

Рисунок 1. Одноразовый пароль по SMS

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

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

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

Политика аудита

Теперь об упомянутом файле с описанием политики логирования. Первое понятие audit policy — это

levelуровень логирования

. Они бывают следующими:


Последние два уровня (

RequestRequestResponse

) не логируют запросы, которые не обращались к ресурсам (обращения к так называемым non-resources urls).

Также все запросы проходят через несколько стадий:

Для пропуска каких-либо стадий можно использовать

omitStages

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

Демон kubelet отслеживает изменение манифеста с конфигурацией api-server и при обнаружении таковых перезапускает контейнер с api-server. Но есть важная деталь: изменения в файле policy будут им игнорироваться. После внесения изменений в файл policy потребуется перезапустить api-server вручную.

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

При включении аудита важно помнить, что

на kube-apiserver повышается нагрузка

. В частности, увеличивается потребление памяти для хранения контекста запросов. Запись в лог начинается только после отправки заголовка ответа. Также нагрузка зависит от конфигурации политики аудита.

Примеры сущностей rbac


Простая

Role

, позволяющая получать список и статус pod’ов и следить за ними в пространстве имен

target-namespace

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: target-namespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Пример

ClusterRole

, что позволяет получать список и статус pod’ов и следить за ними во всем кластере:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # секции "namespace" нет, так как ClusterRole задействует весь кластер
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]


Пример

RoleBinding

, что позволяет пользователю

Стандарты безопасности

Начнем со стандартов. Существует несколько стандартов, которые помогут нам сформулировать список требований к безопасности API:

OWASP (Open Web Application Security Project) известна своими списками рисков в разных программных технологиях. Нам интересен список «10 наиболее опасных уязвимостей при разработке API»:

Добавлю пункты, которые

, но относятся к нашей теме:


А также уязвимости из списка другой организации Common Weakness Enumeration (CWE):

И несколько пунктов из других найденных списков:

В результате получился список, который, на мой взгляд, достаточно полно отражает современные проблемы безопасности API. Для проверки того, что список получился общим и применимым для всех технологий я использовал рекомендации по безопасности API, найденные на просторах Интернета (ссылки приведены в конце статьи). Далее рассмотрим все перечисленные пункты.

Выводы

Как обычно, при выборе элементов системы безопасности необходимо подчиняться требованиям законов и стандартов, а также соизмерять риски с затратами.

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

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

Логон смарт-картой или pkinit

Интерактивная аутентификация в Active Directory по сертификату не является самостоятельным механизмом. Как и всегда, основной протокол аутентификации в домене — Kerberos. Чтобы обеспечить взаимодействие между аутентификацией по смарт-карте и Керберосом, применяется нехитрый протокол PKINIT.

Примечание: если у пользователя уже есть соответствующий сервисный тикет (TGS), выполняются только шаги 5 и 6.

Итоги

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

Оцените статью
Мой сертификат
Добавить комментарий