Багатофакторна автентифікація за допомогою КЕП

Загальний опис

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

Ролі користувачів

  • Розробник/моделювальник регламенту

  • Адміністратор даних

  • Адміністратор безпеки

  • Адміністратор доступу

  • Адміністратор посадових осіб

  • Адміністратор регламенту

  • Технічний адміністратор реєстру

  • Технічний адміністратор Платформи

  • Служба підтримки платформи (L2)

Перелік включає всіх Службових адміністраторів та частину Адміністраторів інфраструктури тому надалі використовується узагальнюючий термін адміністратори.

Функціональні сценарії

  • При автентифікації в сервіси зміни регламенту адміністратору необхідно використати КЕП.

  • При автентифікації в сервіси зміни конфігурації реєстру адміністратору необхідно використати КЕП.

  • При створенні адміністратора вказуються додаткові атрибути: номер в ДРФО, ЄДРПОУ організації та ПІБ які вказані в КЕП.

  • У разі технічної неможливості використання сервісів для входу за допомогою КЕП, технічний адміністратор платформи може відключити необхідність використання КЕП для окремих адміністраторів.

  • Автентифікація адміністраторів через КЕП можлива з використанням ІІТ віджета або через id.gov.ua.

Загальні принципи та положення

  • Автентифікація по логіну і паролю є варіантом за замовченням і достатнім при розробці.

  • В реєстрах які знаходяться в промисловій експлуатації обовʼязковим є використання другого персоніфікованого фактора для автентифікації.

  • Відключення другого фактора для автентифікації в реєстрах з промисловим використанням є виключною ситуацією і можливе тільки у разі технічної неможливості використання другого фактору.

  • Необхідність використання додаткового фактора для автентифікації за допомогою КЕП визначається на рівні користувача.

  • Конфігурація другого фактору здійснюється на рівні платформи.

  • Можливе використання двох варіантів у якості другого фактора для автентифікації це — ІІТ Віджет та id.gov.ua.

  • На платформі передбачена можливість співіснування реєстрів, що знаходяться в промисловій експлуатації та на стадії розробки.

  • Всі адміністратори знаходяться в одному realm (openshift).

  • Послідовність для автентифікації вказується на рівні налаштувань realm.

  • Приналежність адміністратора до реєстру або платформи визначається за наявністю у нього відповідної ролі (cp-registry-admin-%namespce% - для адміністратора реєстру, або cp-cluster-mgmnt)

  • Один адміністратор може мати доступ до декілька реєстрів за допомогою одного або декількох користувачів.

  • Користувач з унікальним e-mail може мати тільки один набір атрибутів, не допускається використання одного e-mail для декількох осіб або для декількох організацій.

  • Авторизація до ресурсів реєстру відбувається за рахунок надання користувачам відповідних ролей користувачу.

Високорівневий дизайн рішення

user managment components
Table 1. Нові компоненти
Назва Призначення

admin login page

Стилізована сторінка для автентифікації за логіном і паролем

admin MFA page

Стилізована сторінка для автентифікації за допомогою КЕП

Admin authenticator

Автентифікатор який використовується openshift realm-ом для автентифікації через ІІТ віджет

Admin id.gov.ua

Автентифікатор який використовується openshift realm-ом автентифікації через id.gov.ua
Diagram
Загальний підхід до автентифікації адміністраторів
Figure 1. Загальний підхід до автентифікації адміністраторів

Сервіси та їх призначення

Перелік адміністративних засобів
Figure 2. Перелік адміністративних засобів

Ресурси доступні можна розділити на дві категорії - адміністративні ресурси реєстру та адміністративні ресурси платформи.

Доступ до адміністративних ресурсів реєстру надається після автентифікації в адміністративній (admin realm) зоні сервісу управління ідентифікацією та доступом.

Доступ до адміністративних ресурсів платформи надається через автентифікацію в кластері OpenShift або зоні openshift realm сервісу управління ідентифікацією та доступом..

Ключові сценарії взаємодії сервісів

Автоматичний перехід на сторінку логіну openshift-sso поза межами даного дизайну
Автентифікація через admin realm
Figure 3. Автентифікація через admin realm

Управління конфігурацією реєстру

Конфігурація реєстру

Поточна схема створення адміністратора 
administrators:
    - username: admin@platform.ua
      email: admin@platform.ua
      firstName: Admin
      lastName: Adminchenko
      passwordVaultSecret: registry-kv/registry/%registry_name%/administrators/admin@platform.ua
      passwordVaultSecretKey: password
Схема створення адміністратора для автентифікації з КЕП 
administrators:
    - username: admin@platform.ua
      email: admin@platform.ua
      firstName: Admin
      lastName: Adminchenko
      #Розширення конфігурації
      authVaultSecret: registry-kv/registry/%registry_name%/administrators/admin@platform.ua
      passwordVaultSecretKey: password
      mfaDetailsVaultEdrpuoKey: edrpuo
      mfaDetailsVaultDrfoKey: drfo
      mfaDetailsVaultFullnameKey: fullName
      mfaRequired: %true/false%

Розгортання реєстру

Для підтримки зворотної сумісності версій при розгортанні відсутність атрибута mfaRequired має трактуватись як mfaRequired = false
Оскільки атрибут mfa на рівні користувача передбачає масив то пропонується розділяти елементи в ньому через ##, що дасть змогу вичитувати в коді цей атрибут як масив, а не робити ручне розбиття по розподільнику.
edp-library-pipeline resources/templates/keycloakRealmUser.yaml 
apiVersion: v1.edp.epam.com/v1alpha1
kind: KeycloakRealmUser
metadata:
  name: ${resourceName}
  namespace: user-management
spec:
  #Розширення шаблону
  attributes:
    mfa: "admin-mfa##admin-mfa-prod"
    drfo: "%drfo%"
    edrpuo: "%edrpuo%"
    fullName: "%fullName%"
  #Існуюча конфігурація
  firstName: ${firstName}
  lastName: ${lastName}
  username: ${username}
  email: ${email}
  password: ${password}
  realm: openshift
  enabled: true
  emailVerified: true
  keepResource: true
  roles: ${roles}
  groups: ${groups}
  requiredUserActions:
    - UPDATE_PASSWORD
Приклад створення автентифікаційної послідовності в компоненті user-management
Альтернативою даного підходу є створення одної автентифікаційної послідовності і зміна переліку authenticationExecutions в ньому
Приклад створення /deploy-templates/keycloak-operator-resources/templates/keycloak/authflow_iit_openshift.yaml
apiVersion: v1.edp.epam.com/v1alpha1
kind: KeycloakAuthFlow
metadata:
  name: admin-mfa-flow-iit
spec:
  alias: admin-mfa-flow-iit
  authenticationExecutions:
  - authenticator: admin-mfa-flow-iit
  # Продовження конфігурації
  # ...
Приклад створення /deploy-templates/keycloak-operator-resources/templates/keycloak/authflow_idgovua_openshift.yaml
apiVersion: v1.edp.epam.com/v1alpha1
kind: KeycloakAuthFlow
metadata:
  name: admin-mfa-flow-idgovua
spec:
  alias: admin-mfa-flow-idgovua
  authenticationExecutions:
  - authenticator: admin-mfa-flow-idgovua
  # Продовження конфігурації
  # ...
Приклад змін /deploy-templates/keycloak-operator-resources/templates/keycloak/keycloakrealm_openshift.yaml
apiVersion: v1.edp.epam.com/v1alpha1
kind: KeycloakRealm
metadata:
  name: openshift
  labels:
    targetRealm: openshift
spec:
  keycloakOwner: main
  realmName: openshift
  ssoRealmEnabled: {{ .Values.keycloak.ssoRealm.ssoRealmEnabled }}
  {{- if .Values.keycloak.ssoRealm.ssoRealmEnabled }}
  ssoAutoRedirectEnabled: {{ .Values.keycloak.ssoRealm.autoRedirectEnabled }}
  ssoRealmName: openshift
  {{- end }}
  ## Зміни
  browserFlow: %browserFlow/admin-mfa-flow-idgovua/admin-mfa-flow-iit%

Інтерфейси адміністратора

Налаштування другого фактору

Приклади екранів конфігурації параметрів другого фактору автентифікації для адміністраторів

platform mfa config options

Можливі три опції поля none - значення за замовченням, ІІТ віджет або id.gov.ua

none - означає використання browserFlow.
ІІТ віджет або id.gov.ua - означає використання відповідних автентифікаторів.

platform mfa config idgovua platform mfa config widget

При зміні способів автентифікації параметри попередньої конфігурації лишаються.

Створення адміністратора

Приклади екранів створення адміністратора з та без другого фактору

admin creation admin creation mfa config

Безпека

Бізнес Дані

Категорія Даних

Опис

Конфіденційність

Цілісність

Доступність

Технічні дані що містять службову інформацію

Налаштування системи, конфіги, параметри які являються службовою інформацію

Висока

Висока

Висока

Механізми протидії ризикам безпеки та відповідність вимогам безпеки

Ризик

Засоби контролю безпеки

Реалізація

Пріорітет

Ризик взлому облікового запису адміністратора реєстру через слабкий пароль. Стійкість пароля адміністратора не перевіряється при створенні.

Додати до фронтенду механізм перевірки стійкості паролю та відповідності вимогам безпеки

Ризик було зменшено. Пароль який задаєтсья при створенні користувача є тимчасовим. Для керування стійкості постійного паролю було вирішено створити політику стійкості паролів на рівні Keycloak та інструкцію для адміністраторів по її розгортанню.

Низький

Порушення рольової моделі доступу до MFA або її відсутність. Будь-який адміністратор реєстру може відключити MFA собі та будь-якому іншому адміністратору через yaml кофігураційний файл що зберігається у геріті.

Налаштувати рольову модель доступу та авторизацію щоб доступ до налаштування MFA мав тільки Адміністратор безпеки.

Ризик було прийнято власником ризиків

Високий

Ризик взлому облікового запису адміністратора реєстру через відключення MFA та відсутність механізму оповіщення користувача. При відключенні MFA користувач не отримує ніякого оповіщення та не може зреагувати на помилкові або протиправні дії.

Додати механізм оповіщення адміністратора про зміни в налаштуванні безпеки його облікового запису.

Ризик було прийнято власником ризиків

Середній

Відсутність механізму зміни пароля у кабінеті адміністратора. Адміністратор не має механізму щоб вчасно змінити пароль облікового запису при виявленні компрометації його даних.

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

Ризик було прийнято власником ризиків

Середній

Міграція даних при оновленні реєстру

  • Для вже створених користувачів зміни не будуть мати сили.

Високорівневий план розробки

Технічні експертизи

  • Front-end development

  • Back-end development (Java, Go)

План розробки

  • Розширення функціональності Сервіс управління ідентифікацією та доступом

    • Створення автентифікаційної послідовності з використанням IIT віджет в якості другого фактору

    • Створення автентифікаційної послідовності з використанням id.gov.ua в якості другого фактору

    • Створення екрана для входу за допомогою другого фактору.

  • Розширення функціональності Консолі адміністратора для адміністратора платформи

    • Створення екранів для конфігурації другого фактору автентифікації

    • Розширення центрального компонента управління користувачами user-management можливістю конфігурації різних автентифікаційних послідовностей для центрального рілма openshift.

  • Розширення функціональності Консолі адміністратора при створенні адміністратора

    • Розширення екранів створення адміністратора

    • Розширення шаблону для створення користувача адміністратора та відповідного pipline-а з вичитуванням даних з сервісу управління секретами та шифруванням.

  • Написання інструкції для налаштування політик для паролей