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

Mon May 16 21:42:47 MSK 2022

On Mon, 16 May 2022, Andrey Zarochentsev wrote:

> День добрый ещё раз.
>
> Позволю себе несколько кратко пересказать всеми изложенное.
>
> 1) Существующая работа RDIG-CA устраивает большинство, и не требует
> изменений для существующих потребителей, а это пока, практически только
> WLCG российские сайты, российские сотрудники ЦЕРН (которые могут
> пользоваться церновскими сертификатами) + ещё какие-то ещё меньшие
> организации, коих ни кто ни о чём не спрашивает. (в случае  СПбГУ - это
> студенты Вычфизики от Маргариты Степановой, которых, кстати давно не было)
>
> 2) Возможный апгрэйд/автоматизация/оптимизация существующей схемы требует
> средств, которые НИЦ-КИ не предоставляет (хотя мне казалось я слышал
> какие-то слова с год назад об RDIG2. Но про деньги я тогда тоже ничего не
> услышал).
>
> 3) Средства на создание чего-то нового могут быть у ОИЯИ, но сотрудники
> ОИЯИ считают, что x509 это отживший рудимент прошедших эпох и ни кому не
> нужен.
>
> Далее технические детали о возможном/невозможном переводе на частичную
> автоматизацию работы CA - тут Евгений Александрович уточнил ряд нюансов, но
> общие возражения относятся скорее к пункту 2.
>
> Моё скромное мнение, что новости о безвременном уходе аутентификации
> посредством x509 несколько преждевременны. И для нужд NICA, таки
> понадобится структура типа RIDG-CA.  Но понятно это будет через некоторое
> время, через которое я и предлагаю вернуться к этой теме.
>

я тоже думаю, что x509 ещё будет востребован довольно долго.
особенно, если российские коллаборации будут иметь распределённую
инфраструктуру.
но не вижу особого смысла иметь дополнительный CA в оияи,
это вряд ли существенно улучшит/ускорит процесс получения
сертификатов хостов и людей.
можно конечно доделать и в оияи, но работы ещё много.
на самом интерфейсе CA не хватает нужных сервисов, поэтому
пока использоваться не может.
/var/log/fetch-crl-cron.log
{{{
ERROR CRL verification failed for JINR/0 (JINR)
VERBOSE(0) JINR/0: CRL has nextUpdate time in the past
}}}
и нужно обеспечить все URI, которые есть в сертификатах.

в оияи реально можно обойтись и токенами, у нас есть
керберос - нормальный нижний уровень для токенов. но
как быть в распределённой структуре - мне не ясно.

>
>
>
> 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
>>
>

---
Best regards,
  Valery Mitsyn