Управління налаштуваннями та секретами зовнішніх інтеграцій

Контекст

Інформаційний обмін з зовнішніми системами

Перелік зовнішніх систем, з якими реалізована взаємодія в рамках бізнес-сценаріїв:

Перелік реєстрів, з якими реалізовано інформаційний обмін (з детальною інформацією можна ознайомитись у розділі Реєстри та системи ШБО "Трембіта"):

  • Єдиний державний реєстр (ЄДР)

  • Державний реєстр актів цивільного стану (ДРАЦС)

  • Єдина інформаційна база даних внутрішньо переміщених осіб (ЄІБДВПО)

Інтеграційни сценарії

Назва компоненту Рівень Зовнішня система/Реєстр Конфігурація Спосіб інтеграції Сценарій

dso-citizen-authenticator

Платформа

ЄДР

Конфігурація інтеграцій та секретів в регламенті реєстру

Вбудований

Аутентифікація представників бізнесу у Кабінеті Громадянина (перевірка наявності активованого запису в реєстрі)

notification-service

Реєстр

Дія

Конфігурація інтеграції та секрету через інтерфейс control-plane

Вбудований

Відправлення інформаційних push-повідомлень громадянам

bpms

Реєстр

ЄДР

ДРАЦС

ЄІБДВПО

Конфігурація інтеграцій та секретів в регламенті реєстру

Типові інтеграційні SOAP-конектори

Інформаційний обмін з реєстрами через Трембіту в рамках виконання бізнес-процесів

Дія

Конфігурація інтеграцій в регламенті та ручне створення секрету

Універсальний інтеграційний REST-конектор

Інформаційний обмін в рамках виконання бізнес-процесів

<Зовнішня система>

Конфігурація інтеграцій в регламенті та ручне створення секретів

Універсальний інтеграційний REST-конектор

Інформаційний обмін через в рамках виконання бізнес-процесів

Поточний технічний дизайн

registry-ext-systems-secrets-baseline

Налаштування аутентифікатора громадян

В рамках аутентифікації громадян, система отримує дані користувача з ЄДР. Конфігурація інтеграції та секрет зберігаються на рівні регламенту та застосовуються Пайплайном публікації регламенту для налаштування dso-citizen-authenticator реєстру:

dso-citizen-authenticator

Налаштування зовнішніх інтеграцій на рівні регламенту

Наразі інтеграції з реєстрами через Трембіту реалізовані за допомогою типових інтеграційних SOAP-конекторів.

Детальніше можна ознайомитись у розділі Типові інтеграційні SOAP-конектори до інших реєстрів

Для REST-інтеграцій з зовнішніми системами реалізовано Універсальний REST-конектор, який підтримує наступні способи авторизації:

  • BASIC (username + password)

  • PARTNER_TOKEN (partner_token + Bearer token)

Детальніше можна ознайомитись у розділі Інтеграція із зовнішніми сервісами за допомогою REST-конектора
registry-gerrit:<registry-regulation>.git/bp-trembita/configuration.yml
trembita-exchange-gateway:
  registries:
    edr-registry:
      user-id: 'DDM'
      protocol-version: '4.0'
      trembita-url: 'trembita.url/mockEDRService'
      authorization-token: 'token'
      client:
        x-road-instance: 'SEVDEIR-TEST'
        member-class: 'GOV'
        member-code: '43395033'
        subsystem-code: 'IDGOV_TEST_01'
      service:
        x-road-instance: 'SEVDEIR-TEST'
        member-class: 'GOV'
        member-code: '00015622'
        subsystem-code: '2_MJU_EDR_prod'
external-systems:
  diia:
    url: http://api2.diia.gov.ua
    methods:
      get-damaged-property:
        path: /api/v1/public-service/damaged-property/filtered
        method: GET
    auth:
      type: PARTNER_TOKEN
      secret-name: diia-partner-token
      partner-token-auth-url: https://api2t.diia.gov.ua/api/v1/auth/partner
      token-json-path: $.token
  httpbin:
    url: http://httpbin.org/
    methods:
      get:
        path: /get
        method: GET
    auth:
      type: BASIC
      secret-name: httpbin-basic-authentication

Недоліки поточної реалізації

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

  • Визначення секретів для доступу до зовнішніх систем на рівні регламенту

  • Необхідність виконання ротації секретів адміністратором регламенту

  • Необхідність ручного створення OpenShift-секретів зовнішніх систем адміністратором реєстру

  • Необхідність ручного налаштування мережевих політик (створення Istio Service Entry для зовнішніх систем)

  • Дублювання налаштувань клієнта Трембіти для реєстру на рівні регламенту

Цільовий технічний дизайн

Загальні принципи

  • Регламент реєстру не має містити налаштувань, які залежать від "оточення" / екземпляра реєстру

  • Регламент реєстру не має містити конфіденційних даних ні в якій формі

  • Налаштування параметрів зовнішніх інтеграцій не мають дублюватись та використовуються централізовано

  • Додання зовнішніх систем для інтеграції з реєстром не потребує ручних дій налаштування мережевих політик

  • Секрети з параметрами доступу до зовнішніх систем зберігаються в захищеному сховищі сервісу управління секретами HashiCorp Vault

  • Адміністратор реєстру та Адміністратор безпеки визначають правомірність взаємодії реєстру з зовнішніми системами

  • Адміністратор реєстру налаштовує інтеграції з зовнішніми системами (протокол інтеграції, адреса, протокол аутентифікації, секрети, тощо.) на рівні екземпляра реєстру

  • Адміністратор реєстру відповідає за ротацію секретів з параметрами доступу до зовнішніх систем

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

  • Між-реєстрова інтеграція через Трембіту реалізується у вигляді каталогу типових розширень-конекторів до реєстрів та не потребує додаткової конфігурації на рівні регламенту

  • Інтеграція з 3rd-party системами потребує додаткової конфігурації на рівні регламенту у вигляді переліку операцій та їх типів, які використовує реєстр через типове розширення БП Універсальний REST-конектор

  • Доступ до захищеного сховища сервісу управління секретами HashiCorp Vault має Control Plane Console та External Secrets Operator через окремого сервісного користувача

  • Кожний сервісний користувач для доступу в HashiCorp Vault повинен мати налаштовану полісі з мінімально необхідними Сapabilities для виконання своїх задач (Principle of least privilege)

Технічний дизайн рішення

Для синхронізації змін між секретами HashiCorp Vault та Secret-ресурсами реєстру використовується External Secrets Operator.

В рамках реалізації дизайну необхідно внести відповідні зміни до налаштування та використання конфігурації каналу зв’язку з Дією у підсистемі нотифікацій architecture/registry/operational/notifications/notifications-channels-configuration.adoc#_налаштування_каналу_звязку_для_відправки_push_повідомлень_у_мобільний_додаток_дія
registry-ext-secrets-operator

  • Адміністратор реєстру створює/редагую конфігурацію реєстру та вносить налаштування реєстру-клієнта ШБО Трембіта через control-plane-console, що призводить до:

    • збереження trembita.consumer-запису про конфігурацію у control-plane-gerrit:<registry>.git/deployment-templates/values.yaml

    • ініціювання platform-jenkins пайплайну та застосування відповідного Helm-чарту з використанням отриманих з git-репозиторію налаштувань до неймспейсу реєстру

  • Адміністратор реєстру створює/редагую конфігурацію реєстру та вносить налаштування інтеграції з Дією через control-plane-console, що призводить до:

    • збереження секрету та мета-даних у user-management:hashicorp-vault за шляхом "registry-kv/registry/<registry/>external-systems/diia" в залежності від обраного способу аутентифікації (AUTH_TOKEN+BEARER)

    • збереження external-systems.diia-запису про конфігурацію та vault:-посилання на зовнішній Vault-секрет у control-plane-gerrit:<registry>.git/deployment-templates/values.yaml

    • ініціювання platform-jenkins пайплайну та застосування відповідного Helm-чарту з використанням отриманих з git-репозиторію налаштувань до неймспейсу реєстру

    • створення ConfigMap-ресурсу "diia-configuration" у неймспейсі реєстру для використання сервісами bpms та ddm-notification-service

    • створення Istio ServiceEntry-ресурсу для забезпечення доступу до зовнішньої системи сервісам bpms та ddm-notification-service реєстру

    • створення Secret-ресурсу "diia-secret" оператором External Secrets Operator як результат опрацювання ExternalSecret-ресурсу diia-external-secret та отримання даних з user-management:hashicorp-vault для використання сервісами bpms та ddm-notification-service

      • …​

Налаштування зовнішніх інтеграцій реєстру через Центр управління платформою

Для налаштувань реєстру у якості учасника інформаційного обміну, необхідно задати адресу ШБО Трембіти, яка є єдиним екземпляром для інтеграції з іншими реєстрами. Необхідно розглянути можливість її глобального визначення замість дублювання для кожного з реєстрів.

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

Наразі при внесенні змін через control-plane-console система автоматично створює Gerrit MR та інтегрує його до репозиторію конфігурації цільового реєстру <registry>.git.
control-plane-gerrit:<registry>.git/deployment-templates/values.yaml
trembita:
# External registries used through Trembita / business processes specific integration connectors - can be updated & can't be removed by "control-plane" administrator
  registries:
    edr-registry:
      user-id: "DDM"
      protocol-version: "4.0"
      url: "https://trembita.mdtu-ddm.projects.epam.com"
      type: "platform" # non-removable record + secret metadata
      protocol: "SOAP"
      client:
        x-road-instance: "SEVDEIR-TEST"
        member-class: "GOV"
        member-code: "43395033"
        subsystem-code: "IDGOV_TEST_01"
      service:
        x-road-instance: "SEVDEIR-TEST"
        member-class: "GOV"
        member-code: "00015622"
        subsystem-code: "2_MJU_EDR_prod"
      auth:
        type: "AUTH_TOKEN"
        secret: "vault:registry-kv/registry/<registry>/trembita-registries/<trembita-registry-name>"
    dracs-registry:
      user-id: "DDM"
      protocol-version: "4.0"
      url: "https://trembita.mdtu-ddm.projects.epam.com"
      type: "platform" # non-removable record + secret metadata
      protocol: "SOAP"
      client:
        x-road-instance: "SEVDEIR-TEST"
        member-class: "GOV"
        member-code: "43395033"
        subsystem-code: "IDGOV_TEST_01"
      service:
        x-road-instance: "SEVDEIR-TEST"
        member-class: "GOV"
        member-code: "00015622"
        subsystem-code: "2_MJU_EDR_prod"
    idp-exchange-service-registry:
      user-id: "DDM"
      protocol-version: "4.0"
      url: "https://trembita.mdtu-ddm.projects.epam.com"
      type: "platform" # non-removable record + secret metadata
      protocol: "SOAP"
      client:
        x-road-instance: "SEVDEIR-TEST"
        member-class: "GOV"
        member-code: "43395033"
        subsystem-code: "IDGOV_TEST_01"
      service:
        x-road-instance: "SEVDEIR-TEST"
        member-class: "GOV"
        member-code: "00015622"
        subsystem-code: "2_MJU_EDR_prod"
external-systems:
# External system used both by registry services and business processes - can be updated & can't be removed by "control-plane" administrator
  diia:
    url: "https://api2t.diia.gov.ua"
    protocol: "REST"
    type: "platform" # non-removable record + secret metadata
    auth:
      type: "AUTH_TOKEN+BEARER"
      auth-url: "https://api2t-auth.diia.gov.ua/api/v1/auth/partner" # can be used both as an absolute url to external auth server or relative path to external system base url ('/api/v1/auth/partner')
      access-token-json-path: "$.token"
      secret: "vault:registry-kv/registry/<registry>/external-systems/<ext-system-name>"
# Example external systems added for particular registry and explicitly "used" on regulation level - can be added/updated/removed if necessary by "control-plane" administrator
  http-bin:
    url: "http://httpbin.org/"
    protocol: "REST"
    type: "registry" # removable record + secret metadata
    auth:
      type: "BASIC"
      secret: "vault:registry-kv/registry/<registry>/external-systems/<ext-system-name>"
  secured-service:
    url: "http://secured-service.org/"
    protocol: "REST"
    type: "registry" # removable record + secret metadata
    auth:
      type: "BEARER"
      secret: "vault:registry-kv/registry/<registry>/external-systems/<ext-system-name>"

Для кожного запису налаштувань інтеграції з зовнішніми системами, має бути автоматично створений ресурс Istio Service Entry для надання дозволу взаємодії згідно дизайну.

Налаштування зовнішніх інтеграцій на рівні регламенту

registry-gerrit:<registry-regulation>.git/bp-trembita/configuration.yml
# reusing external system names configured on registry level
external-systems:
  diia:
    operations:
      get-damaged-property:
        resource-path: "/api/v1/public-service/damaged-property/filtered"
        method: "GET"
      create-distribution:
        resource-path: "/api/v1/notification/distribution/push"
        method: "POST"
  http-bin:
    operations:
      get-operation:
        resource-path: "/get"
        method: "GET"

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

ConfigMap: "external-systems-endpoint-configuration"
kind: ConfigMap
apiVersion: v1
metadata:
  name: external-systems-endpoint-configuration
  namespace: <registry-namespace>
data:
  external-systems-endpoint-configuration.yml: |
    external-systems:
      diia:
        operations:
          get-damaged-property:
            resource-path: "/api/v1/public-service/damaged-property/filtered"
            method: "GET"
          create-distribution:
            resource-path: "/api/v1/notification/distribution/push"
            method: "POST"
      http-bin:
        operations:
          get-operation:
            resource-path: "/get"
            method: "GET"

Створення ConfigMap ресурсів при застосуванні змін до налаштувань реєстру

ConfigMap: "trembita-registries-configuration"
kind: ConfigMap
apiVersion: v1
metadata:
  name: trembita-registries-configuration
  namespace: <registry-namespace>
data:
  trembita-registries-configuration.yml: |
    trembita:
     registries:
        edr-registry:
          user-id: "DDM"
          protocol-version: "4.0"
          url: "https://trembita.mdtu-ddm.projects.epam.com"
          protocol: "SOAP"
          client:
            x-road-instance: "SEVDEIR-TEST"
            member-class: "GOV"
            member-code: "43395033"
            subsystem-code: "IDGOV_TEST_01"
          service:
            x-road-instance: "SEVDEIR-TEST"
            member-class: "GOV"
            member-code: "00015622"
            subsystem-code: "2_MJU_EDR_prod"
          auth:
            type: "AUTH_TOKEN"
        dracs-registry:
          user-id: "DDM"
          protocol-version: "4.0"
          url: "https://trembita.mdtu-ddm.projects.epam.com"
          protocol: "SOAP"
          client:
            x-road-instance: "SEVDEIR-TEST"
            member-class: "GOV"
            member-code: "43395033"
            subsystem-code: "IDGOV_TEST_01"
          service:
            x-road-instance: "SEVDEIR-TEST"
            member-class: "GOV"
            member-code: "00015622"
            subsystem-code: "2_MJU_EDR_prod"
        idp-exchange-service-registry:
          user-id: "DDM"
          protocol-version: "4.0"
          url: "https://trembita.mdtu-ddm.projects.epam.com"
          protocol: "SOAP"
          client:
            x-road-instance: "SEVDEIR-TEST"
            member-class: "GOV"
            member-code: "43395033"
            subsystem-code: "IDGOV_TEST_01"
          service:
            x-road-instance: "SEVDEIR-TEST"
            member-class: "GOV"
            member-code: "00015622"
            subsystem-code: "2_MJU_EDR_prod"
ConfigMap: "external-systems-configuration"
kind: ConfigMap
apiVersion: v1
metadata:
  name: external-systems-configuration
  namespace: <registry-namespace>
data:
  external-systems-configuration.yml: |
    external-systems:
      http-bin:
        url: "http://httpbin.org/"
        protocol: "REST"
        auth:
          type: "BASIC"
      secured-service:
        url: "http://secured-service.org/"
        protocol: "REST"
        auth:
          type: "BEARER"
ConfigMap: "diia-configuration"
kind: ConfigMap
apiVersion: v1
metadata:
  name: diia-configuration
  namespace: <registry-namespace>
data:
  diia-configuration.yml: |
    external-systems:
      diia:
        url: "https://api2t.diia.gov.ua"
        protocol: "REST"
        auth:
          type: "AUTH_TOKEN+BEARER"
          auth-url: "https://api2t-auth.diia.gov.ua/api/v1/auth/partner"
          access-token-json-path: "$.token"

Створення ExternalSecret ресурсів при застосуванні змін до налаштувань реєстру

ExternalSecret: "trembita-registries-external-secrets"
kind: ExternalSecret
apiVersion: external-secrets.io/v1beta1
metadata:
  name: trembita-registries-external-secrets
  namespace: <registry-namespace>
spec:
  refreshInterval: "10s"
  secretStoreRef:
    name: user-management:hashicorp-vault
    kind: SecretStore
  target:
    name: trembita-registries-secrets
  dataFrom:
  - extract:
      key: "registry/<registry>/trembita-registries"
ExternalSecret: "external-systems-external-secrets"
kind: ExternalSecret
apiVersion: external-secrets.io/v1beta1
metadata:
  name: external-systems-external-secrets
  namespace: <registry-namespace>
spec:
  refreshInterval: "10s"
  secretStoreRef:
    name: user-management:hashicorp-vault
    kind: SecretStore
  target:
    name: external-systems-secrets
  dataFrom:
  - extract:
      key: "registry/<registry>/external-systems"
ExternalSecret: "diia-external-secret"
kind: ExternalSecret
apiVersion: external-secrets.io/v1beta1
metadata:
  name: diia-external-secret
  namespace: <registry-namespace>
spec:
  refreshInterval: "10s"
  secretStoreRef:
    name: user-management:hashicorp-vault
    kind: SecretStore
  target:
    name: diia-secret
data:
  - secretKey: "external-systems.diia.auth.secret.token"
    remoteRef:
      key: "registry/<registry>/external-systems"
      property: "external-systems.diia.auth.secret.token"

Застосування змін до Secret ресурсів Kubernetes оператором External Secrets Operator

External Secrets Operator підтримує створення єдиного Secret-ресурсу на базі N записів секретів з HashiCorp Vault з можливостями проведення трансформацій.
Secret: "trembita-registries-secrets"
kind: Secret
apiVersion: v1
metadata:
  name: trembita-registries-secrets
  namespace: <registry-namespace>
data:
  trembita.registries.<registry-name-1>.auth.secret.token: "<token>"
  trembita.registries.<registry-name-2>.auth.secret.token: "<token>"
  trembita.registries.<registry-name-3>.auth.secret.token: "<token>"
Secret: "external-systems-secrets"
kind: Secret
apiVersion: v1
metadata:
  name: external-systems-secrets
  namespace: <registry-namespace>
data:
  external-systems.<external-system-name-1>.auth.secret.username: "<username>"
  external-systems.<external-system-name-1>.auth.secret.password: "<password>"
  external-systems.<external-system-name-2>.auth.secret.token: "<token>"
  external-systems.diia.auth.secret.token: "<token>"
Secret: "diia-secret"
kind: Secret
apiVersion: v1
metadata:
  name: diia-secret
  namespace: <registry-namespace>
data:
  external-systems.diia.auth.secret.token: "<token>"

Маунтинг Secret ресурсів на файлову систему

Deployment: "bpms"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bpms
spec:
  template:
      containers:
        - name: bpms
          volumeMounts:
            - name: bpms-trembita-registries-secrets
              mountPath: /app/secrets/trembita-registries
            - name: bpms-external-systems-secrets
              mountPath: /app/secrets/external-systems
            - name: bpms-diia-secret
              mountPath: /app/secrets/diia
      volumes:
        - name: bpms-trembita-registries-secrets
          secret:
            secretName: trembita-registries-secrets
        - name: bpms-external-systems-secrets
          secret:
            secretName: external-systems-secrets
        - name: bpms-diia-secret
          secret:
            secretName: diia-secret
Файлова система
Figure 1. Файлова система

Типи підтримуваних протоколів аутентифікації для інтеграцій та зберігання секретів у HashiCorp Vault

При збереженні секретів у user-management:hashicorp-vault необхідно додатково вносити мета-дані в залежності від типу запису інтеграції для подальшого використання при фільтруванні секретів:

  • type: platform

  • type: registry

Інтеграції з іншими реєстрами через Трембіту:

  • NO_AUTH - взаємодія з реєстром через ШБО Трембіта не потребує додаткової авторизації

  • AUTH_TOKEN - взаємодія з реєстром через ШБО Трембіта потребує додаткової авторизації з використанням авторизаційного токену

Секрети для взаємодії з реєстрами зберігаються у HashiCorp Vault (user-management:hashicorp-vault) за шляхом, згенерованим згідно конвенції:

registry-kv/registry/<registry>/trembita-registries/<trembita-registry-name>

  • <registry> - службова назва реєстру

  • <trembita-registry-name> - службова назва реєстру, для якого налаштована інтеграція через ШБО Трембіта

Приклад зберігання "AUTH_TOKEN" секрету у HashiCorp Vault: "registry-kv/registry/<registry>/trembita-registries/<trembita-registry-name>"
{
  "trembita.registries.<registry-name>.auth.secret.token": "<authorization-token>"
}

Інтеграції з іншими системами:

  • NO_AUTH - взаємодія з зовнішньою системою не потребує авторизації

  • BASIC - взаємодія з зовнішньою системою потребую проходження стандартної аутентифікації з використанням username та password

  • AUTH_TOKEN - взаємодія з зовнішньою системою потребує авторизації з використанням авторизаційного токену

  • AUTH_TOKEN+BEARER - взаємодія з зовнішньою системою потребує двоетапної авторизації з отриманням токену доступу за авторизаційним токеном

  • BEARER - взаємодія з зовнішньою системою потребує авторизації з використанням авторизаційного токену

Секрети для взаємодії з зовнішніми системами зберігаються у HashiCorp Vault (user-management:hashicorp-vault) за шляхом, згенерованим згідно конвенції:

registry-kv/registry/<registry/>external-systems/<ext-system-name>

  • <registry> - службова назва реєстру

  • <ext-system-name> - службова назва системи, для якої налаштована інтеграція

Приклад зберігання "BASIC" секрету у HashiCorp Vault: registry-kv/registry/<registry/>external-systems/<ext-system-name>
{
  "external-systems.<external-system-name>.auth.secret.username": "<username>",
  "external-systems.<external-system-name>.auth.secret.password": "<password>"
}
Приклад зберігання "BEARER" | "AUTH_TOKEN" | "AUTH_TOKEN+BEARER" секретів у HashiCorp Vault: registry-kv/registry/<registry>/external-systems/<ext-system-name>
{
  "external-systems.<external-system-name>.auth.secret.token": "<authorization-token>"
}

Сервісні користувачі для доступу в HashiCorp Vault:

Кожний компонент, що отримує доступ до Vault повинен запускатись від окремого OpenShift сервіс акаунта. Сервісні користувачі створені в HashiCorp Vault повинні бути типу Kubernetes Auth Method та створюватись під час початкового налаштування HashiCorp Vault через виконання script-init ConfigMap.

Компонент

Назва сервіс акаунта

Прив’язані Namespaces

Capabilities

External Secrets Operator

external-secrets-operator

Registry namespace

["read"]

Адмін-консоль

control-plane-console

control-plane

["create", "update"]
Приклад Capability Policy HashiCorp Vault
{
      "policy": "path \"registry-kv/registry/<registry/>external-systems/\" \"{ capabilities = [ \"read\" ]}\""}
}
Приклад привʼязки сервіс акаунта OpenShift в HashiCorp Vault
{
      "bound_service_account_names": ["control-plane-console"],
      "bound_service_account_namespaces": "ns",
      "policies": ["policy-name"],
      "ttl": "1h"
}

Моделювання регламенту

Зміни до інтеграційних конекторів ЄДР:

Перейти до використання змінної оточення "trembita.registries.edr-registry.auth.secret.token", яка була створена на базі "trembita-registries-secrets"-секрету , для отримання авторизаційного токену у типових розширеннях:

  • com.epam.digital.data.platform.bpms.extension.delegate.connector.registry.edr.SearchSubjectsEdrRegistryConnectorDelegate

  • com.epam.digital.data.platform.bpms.extension.delegate.connector.registry.edr.SubjectDetailEdrRegistryConnectorDelegate

Зміни до універсального REST-конектора:

Для вказаної на рівні REST-конектора назви зовнішньої системи, необхідно визначити тип авторизації зі змінної оточення "external-systems.<ext-system-name>.auth-type", який було налаштовано адміністратором реєстру ("NO_AUTH" | "BASIC" | "BEARER" | "AUTH_TOKEN+BEARER"), та в залежності від типу отримати необхідні дані для проведення авторизації запиту з "external-systems-secrets"-секрету:

  • com.epam.digital.data.platform.bpms.extension.delegate.connector.rest.ExternalSystemConnectorDelegate

Управління налаштуваннями реєстру

Інтерфейси управління зовнішніми інтеграціями реєстру

registry-integrations-management
Figure 2. Управління зовнішніми інтеграціями реєстру
trembita-registry-integration-configuration
Figure 3. Налаштування взаємодії з реєстром через Трембіту
external-system-integration-configuration
Figure 4. Налаштування взаємодії з зовнішньою системою

Безпека

Бізнес Дані

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

Опис

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

Цілісність

Доступність

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

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

Середня

Висока

Висока

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

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

Висока

Висока

Висока

Спрощена модель загроз

ext sec TM

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

Ризик Засоби контролю безпеки Реалізація Пріорітет

Компрометація данних у Vault через корневий токен. Зараз корневий токен який має доступ до всього а також до ансілу сховища використовується усіма сервісами як основний.

  • Створити сервісних користувачів та налаштувати розмежування доступу у Vault

  • Налаштувати RBAC для доступу до секретів в яких лежить корневий токен

Ризик було усунено

Критичний

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

  • Монтувати секрети до цільових сервісів як файли.

  • Налаштувати механізм загальної обробки помилок

Враховано в початковому дизайні

Критичний

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

  • Створити окремого сервісного користувача для інтеграції з оператором зовнішніх секретів відповідаючи принципу найменьших привілеїв

  • Налаштувати RBAC для доступу до CRD оператора зовнішніх секретів

Не враховано в початковому дизайні

Високий

Відмова від авторства. Відсутність аудит логу і інформації про доступ до секретів у Vault.

  • Налаштувати систему логування та аудиту для Vault

Не враховано в початковому дизайні

Високий

Ризик бекдору у компоненті external secrets operator

  • Заборонити на рівні мережевих політик будь яке спілкування сервісу external secrets operator з зовнішніми ресурсами і дозволити комунікацію з сервісами задіяними згідно бізнес логіки.

Не враховано в початковому дизайні

Високий

  • Несанкціонований доступ до даних у датацентрі.

  • Неправильне регламентне виведення з обігу компонентів датацентру

  • Несанкціонований доступ до резервних копій

  • Налаштувати шифрування для розділів які використовуються Vault-ом

Не враховано в початковому дизайні

Середній

Ризик ухилення від виявлення та закріплення в системі за відсутності ротації секретів

  • Налаштувати систему\процес ротації секретів

Не враховано в початковому дизайні

Середній