Aktualita

ARB zápis 31.01.2023

Aktualizované 3 februára, 2023

Obsah

Dňa 03.02.2023 bol zverejnený zápis z pravidelného stretnutia Architecture Review Board, ktoré sa konalo dňa 31.01.2023.


Zápis zo stretnutia

ARB – ARCHITECTURE REVIEW BOARD

Stretnutie

Architecture Review Board

Dátum stretnutia

31.01.2023

Miesto stretnutia

MS Teams

Vypracoval

Anton Svetlošák

  1. ÚČASTNÍCI

Prítomní:

anton.svetlosak@mirri.gov.sk

vladimir.kovac@mirri.gov.sk

marian.nagy@mirri.gov.sk

radovan.kulin@slovenskoit.sk

viliam.tokarcik@slovenskoit.sk

peter.zovak@nases.gov.sk

martin.sulik@nases.gov.sk

peter.harvanik@nases.gov.sk

stefan.szilva@nases.gov.sk

Program stretnutia :

  1. Agenda stretnutia:
    • Prihlasovanie zamestnancov.
    • API mUPVS na CAMP
  1. Závery a úlohy
  2. Témy na ďalšie stretnutie
    • CAMP – onBehalfOf, workflow
    • OPZ pre platformu procesnej integrácie
    • Prístup k integrácií a ku cache na zdrojovom registri, konzumentovi OVM, centrálne na CSRU/CAMP
    • Integrácia MOU a SVM

ZÁPIS Z PRIEBEHU STRETNUTIA

P. č.

Typ

Zápis

  1. Zápis zo stretnutia
1.1

I

API mUPVS na CAMP

API budú vystavené, postupne ako sa budú vytvárať moduly. Všetky API mUPVS budú na internom APIGW, vybrané API budú na externom APIGW.

Ako prvý pôjde na internú APIGW modul Valibuk (BE je už hotový takže koncom februára už môže ísť, FE bude v PI5). Následne moduly z KSDR (ZORO).

CMDB, eGov služby, partner, feedback – tieto pôjdu do PI5, do produkcie koncom júna.

1.2

I

Prihlasovanie zamestnancov – admin GUI pre NASES, administrátor bude môcť meniť konfiguráciu v CMDB.

Zamestnanecké konto je oddelené od eID, mID. Povedzme si ako sa má zamestnanec prihlasovať. SKIT návrhu pre zamestnancov Keycloak a umožniť prihlásenie na základe mena a hesla.

  • Do CMDB pôjdu len ľudia z NASES
  • IAM admin – niečo ako správa partnerov, bude len pre ľudí z NASES
  • Spätná väzba – len NASES ľudia
  • CMS – len tu sa prihlasujú aj OVM

Môžeme sa pripojiť pre NASES adminov do AD, ktoré má NASES – áno. Preferované je Kerberos, klienti musia komunikovať cez TCP. NASES ešte nevie, ktoré AD presne.

  • Prečo nie ČISSŠ – obmedzenie s kartami, je to len PoC, tiež potencionálny vendor lock.
  • LDAP starého UPVS môžeme vylúčiť.
  • 4 Prípady použitia
    • KAV: možnosť nadrezortného o365 tenantu, menšie bezpečnostné požiadavky, práca s otvorenými dátami

    • Administrácia mUPVS, kde sa pristupuje cez VPN, oddelené od internetu, vyššie požiadavky na bezpečnosť. Nová báza používateľov, aj pre NASES používateľov – “UPVS privilegované účty”
    • CMS (Drupal) – rovnaké AD (UPVS privilegované účty)
    • Adobe – rovnaké AD (UPVS privilegované účty), ako v prípade mUPVS.
  • Autentifikácia pôjde z AD, role pôjdu z Valibuka (mUPVS, CMS). Adobe bude ťahať role z AD.
    • Na strane klienta sa preveruje oprávnenie, na základe id užívateľa a action. Drupal sa bude rozširovať (plugin).
    • Je potrebné vytvoriť a sprístupniť web stránku pre používateľov, cez ktorú si môžu minimálne pozrieť svoj účet v AD a zmeniť heslo a tiež web stránku pre správu používateľov administrátorom (service deskom), pre založenie účtu, aktiváciu zablokovaného účtu nastavenie rolí vo Valibuku a ďalšiu správu účtov.
    • Potrebné preveriť: Bude stačiť, meno a heslo alebo bude treba na základe existujúcej alebo novej rizikovej analýzy zvážiť použiť aj dvojfaktorovú autentifikáciu? Alebo bude prístup pre zamestnancov pristupujúcich na správu používateľov z radov zamestnancov
    • NASES si preverí so svojou sekciou bezpečnosti, špecialistami na MS AD a pracovníkmi service desk požiadavky na správu používateľov mÚPVS z radov zamestnancov VS tak, aby aj z pohľadu bezpečnosti aj prevádzky bolo riešenie pre NASES akceptovateľné.

NASES už má nástroje s admin rozhraním, vytvorí sa aj CMS (tam budú pristupovať OVM), Adobe na formuláre. Je bežné, že moduly majú nástroje, kde sa prihlasujú len niektoré osoby.

Aktuálne je bežné, že sa prihlasuje pre administráciu cez UPVS IAM.

Je zmätok ak existuje viac zdrojov účtov.

1.3

I

 

         2. Otvorené otázky a riziká

2.1

O

 

2.2

O

 

2.3

O

 

       3. Úlohy

 Zodpovedný

Termín

Stav

3.1

U

                                                                           

3.2

U

       

3.3

U

       

      4. Závery

4.1

Z

 

4.2

Z

 

4.3

Z

 

Typ: U – úloha, D – dohoda, I – informácia, P – predpoklad, R – riziko, O – otvorená otázka, S – schvaľovanie

Stav Úlohy: nová, splnená, prebieha, zrušená, budúca (identifikovaná naviazaná na splnenie niektorej ešte neukončenej úlohy, termín a zodpovednosti budú stanovené následne)

Prílohy k zápisu : žiadne

Aktualizované 3 februára, 2023

Zanechajte komentár

Vaša e-mailová adresa nebude zverejnená.