[Ru_ngi] Варианты развития центра GRID аутентификации.

[Eygene Ryabinkin]

Mon, May 16, 2022 at 11:52:13AM +0300, Andrey Zarochentsev wrote:
> Собственно я и представляю вопрос на общее обсуждение,
> а не предлагаю сразу готовое решение.
>
> Для примера хочу напомнить, как процедура выдачи происходит в ЦЕРН:
> 
> https://ca.cern.ch/ca/host/HostCertificates.aspx
> https://ca.cern.ch/ca/user/MyCertificates.aspx
> 
> Процедура автоматизирована и не требует круглосуточной занятости
> высококлассного специалиста. Да, в ЦЕРН сертификат может получить только
> уже зарегистрированный пользователь, и нет необходимости содержать штат RA,
> для подтверждения новых пользователей или статуса старых.

Если

 а. есть система регистрации пользователей и (когда это требуется)
    назначения им прав "этому сертификат для такого-то узла получать
    можно, этому -- нет",

 б. этой системе можно доверять; в смысле отсутствия возможностей
    её обмануть, в смысле доверия качеству данных (человек уже
    уволился, а запись о нём -- осталась), в смысле доверия её
    операторам и администраторам,

то она заменяет Registration Authority (вернее, переносит их
обязанности на другой/другие уровни).  Ниже такие системы будут
называться (*).

Не нужно, кстати, забывать о первом пункте в смысле привязки
(и пере-привязки) узлов/сервисов к их администратору/администраторам.
В CERN это база данных Human Resources + LanDB.

> Но сама по себе автоматизация имеет место быть.

"Автоматизация" -- это полностью автоматическая выдача сертификата
после его одобрения RA?

> И если RA уже подтвердил запрос, откуда последующие сложности?

Из моего опыта, некоторые RA иногда подтверждают по несколько
запросов для одного пользователя.  Некоторые -- держат свой
сертификат незашифрованным: я в прошлом встречал такие случаи,
проводил разъяснительную работу и наблюдал за поведением.

> Тут скорее сложности у RA, который проверяет каждого
> обратившегося на принадлежность к своей организации.
> А на уровне CA ручная обработка требуется только для добавления
> новых RA и решения нестандартных ситуаций.

А ещё -- чтобы инициировать процедуру подписания новых
сертификатов, CRL и отзыва сертификатов на offline-машине.
И активации (с помощью введения пароля, использования
многофакторной аутентификации или чего-то ещё) закрытого
ключа (корневого или промежуточного) УЦ.

Если у нас будет online-сервис (в котором для создания
и хранения корневого /или промежуточного/ сертификата УЦ
используются аппаратные средства), то сразу возникают вопросы,
связанные с защитой такого online-сервиса.  Вопросов --
много, не возьмусь их решать:

 - если думать про "неуловимого Джо" (как делал Лев Витальевич
   Шамардин), то буду их решать некачественно,

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

Ввиду этого, я рассматриваю offline-сервис по подписанию
сертификатов клиентов УЦ в качестве более приемлемой
технической альтернативы.  В конце концов, в RDIG CA есть
охраняемый физический периметр (и даже 3), один из которых
обеспечивается вполне регулярными военными.  Это не означает
полную защищённость от описанного выше, однако, по моему мнению
(которое я стараюсь не реже раза в год проверять/уточнять),
такой подход для задач RDIG CA является более правильным.


> Это по технической части.
> 
> По организационной. Я не могу предложить на данный момент конкретную
> кандидатуру, хотя варианты есть. Не могу по той простой причине, что должна
> предлагаться не кандидатура, а ставка с определённым финансированием. И не
> на кандидатуру, а на отдел. Т.е. выдачей сертификатов и поддержкой работы с
> ними должна заниматься группа людей, которые могут друг друга заменять.

Андрей Константинович, вы так говорите, как будто в RDIG есть деньги
и/или крайняя заинтересованность каких-то входящих в RDIG организаций
их находить для развития и поддержания RDIG.  Я боюсь, что это далеко
не так.  Поэтому "ставка с определённым финансированием", а тем
более на отдел, -- это мечты.  Я знаю только один случай за последнее
время, когда 2 огранизации из RDIG занимались (и занимаются) денежным
обеспечением функцинирования сервисов, общих для всего RDIG (а не
"вот, мы находим деньги для развития своих ресурсов"): это ОИЯИ и КИ.
Могу сказать про сетевую часть (LHCOPN и LHCONE), ибо она -- наиболее
затратна (если я всё правильно понимаю): в КИ эти средства находить
всё труднее и труднее.  И "труднее" это не "раньше давали перед твоей
просьбой о, сейчас же -- надо соорудить минимальную бумажку и всё
случится".

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

X.509 уходит в прошлое + Данила написал про token-ы + IAM,
их внедрение в рамках NICA и текущий статус.  Я могу сказать вот что:

 - IAM работает на базе желания совместить системы типа (*)
   с разными системами авторизации (вплоть до социальных сетей).
   И я прошу обратить внимание, "системы", не "систему" -- в рамках
   одного, фактически, эксперимента (в смысле сущности, которая
   принимает решение о том, доверять/не доверять ли аутентификационной
   информации различного типа и качества _для нужд этого конкретного
   эксперимента_); но имея возможность обслуживать различные эксперименты
   (причём, если я правильно понимаю, -- по-разному в смысле политик
   обслуживания),

 - IAM -- VOMS-на-стероидах, потребляющий разнородную аутентификационную
   информацию (и разнородную по качеству -- тоже), оперирующий, впрочем,
   понятием "уровнь доверия" (level-of-assurance profile), и раздающий
   token-ы, которые работают на базе единой технологии (именно она --
   не X.509, сейчас это OAuth/JWT, дальше -- что-там-будет-модно).

Возможно, такая система действительно более соответствует текущим
запросам граждан (особенно учитывая то, что потребители, скажем,
инфраструктуры WLCG, -- они вообще интересуются не безопасностью,
а удобством работы/качеством обслуживания).  Я полагаю, что без
координации деятельности базовых поставщиков аутентификационной
информации (т.е. для IAM, -- потенциально, -- это и Facebook,
и Гос-"прости-Г-ди"-Услуги), -- чем занимаются IGTF и EUGridPMA --
тут будет сложно.  Но, конечно, любой из экспериментов может
(если технически/административно выйдет) ограничить круг этих
поставщиков чем-им-надо, а дальше -- дальше оно VOMS-на-стероидах,
где X.509 заменён на другую подложку и навешаны более современные
(современные "индустриально-стандартным" сервисам и моделям)
средства сказать "я -- этот, мне надо то-то и мне оно разрешено".

Гражданам, вводящим и сопровождающим такие системы в рамках
хотя бы 4-х экспериментов на БАК -- удачи.  Она им понадобится.
-- 
Eygene Ryabinkin, National Research Centre "Kurchatov Institute"

Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live.