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

Mon May 16 20:34:14 MSK 2022

День добрый ещё раз.

Позволю себе несколько кратко пересказать всеми изложенное.

1) Существующая работа RDIG-CA устраивает большинство, и не требует
изменений для существующих потребителей, а это пока, практически только
WLCG российские сайты, российские сотрудники ЦЕРН (которые могут
пользоваться церновскими сертификатами) + ещё какие-то ещё меньшие
организации, коих ни кто ни о чём не спрашивает. (в случае  СПбГУ - это
студенты Вычфизики от Маргариты Степановой, которых, кстати давно не было)

2) Возможный апгрэйд/автоматизация/оптимизация существующей схемы требует
средств, которые НИЦ-КИ не предоставляет (хотя мне казалось я слышал
какие-то слова с год назад об RDIG2. Но про деньги я тогда тоже ничего не
услышал).

3) Средства на создание чего-то нового могут быть у ОИЯИ, но сотрудники
ОИЯИ считают, что x509 это отживший рудимент прошедших эпох и ни кому не
нужен.

Далее технические детали о возможном/невозможном переводе на частичную
автоматизацию работы CA - тут Евгений Александрович уточнил ряд нюансов, но
общие возражения относятся скорее к пункту 2.

Моё скромное мнение, что новости о безвременном уходе аутентификации
посредством x509 несколько преждевременны. И для нужд NICA, таки
понадобится структура типа RIDG-CA.  Но понятно это будет через некоторое
время, через которое я и предлагаю вернуться к этой теме.

Best Regards,
Andrey Zarochentsev
---------------------------------------
Всего доброго,
С уважением,
Андрей Зароченцев.

пн, 16 мая 2022 г. в 17:53, Eygene Ryabinkin <rea at grid.kiae.ru>:

> 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.
> --
> Ru_ngi mailing list
> Ru_ngi at theory.sinp.msu.ru
> http://theory.sinp.msu.ru/cgi-bin/mailman/listinfo/ru_ngi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://theory.sinp.msu.ru/pipermail/ru_ngi/attachments/20220516/382c3ed5/attachment-0001.htm>