Informacinių sistemų žemėlapis turi parodyti, kaip paslauga veikia nuo žmogaus įvesties iki galutinio rezultato. Jame susiejamos programos, duomenys, tiekėjai ir atsakomybės. Vien serverių sąrašas neatskleidžia, kam persiunčiama užsakymo byla ar nuo kokio išorinio prisijungimo priklauso apskaita.
Žemėlapį naudokite kartu su tvarkymo veiklos įrašais. Registras aprašo tvarkymo tikslus ir BDAR informaciją; techninis žemėlapis parodo sistemos bei srautų ryšius. Jie papildo vienas kitą, bet neturėtų būti aklai sutapatinami.
Pradėkite nuo vienos paslaugos
Pasirinkite aiškų scenarijų, pavyzdžiui, kliento užsakymą. Paprašykite proceso savininko parodyti jo kelią, o administratoriaus – patvirtinti, kokios programos iš tikrųjų perduoda duomenis. Patikrinkite automatinius srautus, rankinius eksportus, el. pašto priedus ir darbuotojų susikurtas skaičiuokles.
Žemėlapyje rodyklė turi turėti reikšmę: kokie duomenys, kokiu tikslu, kokiu būdu ir kaip dažnai perduodami. Dvi susietos sistemos nebūtinai perduoda visą duomenų bazę. Šis skirtumas svarbus vertinant tiekėjo vaidmenį, incidento apimtį ir galimybę sumažinti duomenų kiekį.
Programų ir srautų lentelės
| Sistemos laukas | Pavyzdys, kurį pakeiskite savo duomenimis |
|---|---|
| Identifikatorius | APP-01 |
| Paskirtis | Kliento užsakymo priėmimas |
| Proceso savininkas | Pardavimo padalinys |
| Techninis valdytojas | Paskirtas administratorius arba tiekėjas |
| Duomenų grupės | Kontaktai, užsakymo turinys, pristatymo informacija |
| Priklausomybės | Tapatybės teikėjas, pašto paslauga, mokėjimo integracija |
| Kritiškumas | Poveikio veiklai vertinimo rezultatas |
Atskiroje srautų lentelėje pridėkite šaltinį, gavėją, perdavimo kanalą, kategorijas, dažnį ir srauto savininką. Patogu nurodyti paskutinio patvirtinimo datą ir įrodymą, pavyzdžiui, integracijos aprašą ar pokalbį su proceso savininku. Nežinomą srautą pažymėkite kaip tikrintiną, o ne užpildykite spėjimu.
ANSSI sistemų kartografavimo vadovas pateikia metodinį pagrindą skirtingoms architektūros peržiūroms. BDAR 30 ir 32 straipsniai padeda susieti inventorių su duomenų tvarkymo dokumentavimu ir saugumo vertinimu.
Hipotetinis užsakymo kelias
Portale klientas pateikia kontaktus ir užsakymą. Mokėjimo paslaugai perduodama tik jai reikalinga informacija. Sandėlis gauna pristatymo duomenis, apskaita – sąskaitai būtinus laukus. Aptarnavimo komanda mato užsakymo būseną, bet jai nebūtinai reikalinga visa mokėjimo informacija.
Šis žemėlapis atskleidžia sprendimus: ar sandėliui reikia telefono numerio kiekvienu atveju; ar aptarnavimo eksportas ribojamas; ar testinėje aplinkoje naudojami tikri kontaktai. Duomenų kiekio mažinimo auditas paverčia šiuos klausimus konkrečiais laukų pakeitimais.
Trys naudingos peržiūros
Veiklos peržiūroje parodykite procesą ir naudotojus. Taikomųjų programų peržiūroje – programas ir sąsajas. Saugumo peržiūroje – prieigos ribas, administravimo kelius, išorinius gavėjus ir svarbiausias apsaugos priemones. Visų elementų talpinimas viename milžiniškame brėžinyje dažnai trukdo atsakyti į paprastą klausimą.
Tiekėjų peržiūroje pažymėkite valdytojo ir tvarkytojo vaidmenis bei duomenų perdavimus. Ne kiekviena debesijos sąsaja reiškia tą patį teisinį santykį. Jei duomenys perduodami į trečiąją valstybę, susiekite srautą su perdavimo vertinimu, o ne bendru tiekėjo pavadinimu.
Kaip patikrinti žemėlapį
Išsirinkite vieną užsakymą be perteklinių asmens duomenų ir patikrinkite, ar jo kelias atitinka aprašą. Paprašykite savininkų patvirtinti savo dalį. Tada pasirinkite sutrikimo scenarijų: jei neveikia tapatybės teikėjas, kokios kitos sistemos nepasiekiamos? Atsakymas turi sutapti su veiklos tęstinumo planu.
Atnaujinimą susiekite su nauju tiekėju, integracijos pakeitimu, duomenų eksporto atsiradimu ir sistemos uždarymu. Už žemėlapį atsakingas koordinatorius gali prižiūrėti formatą, tačiau kiekvieno srauto tikrumą turi patvirtinti jį valdantis žmogus.
Žemėlapio detalumo pasirinkimas
Detalumą pasirinkite pagal klausimą, kurį norite atsakyti. Vadovybei sprendžiant tęstinumo prioritetus reikalingi procesai, svarbiausios programos ir kritinės priklausomybės. Administratoriui planuojant tinklo atskyrimą reikalingos tikslesnės ryšio ribos ir administravimo keliai. Duomenų apsaugos specialistui svarbu, kokios žmonių grupės ir duomenų kategorijos susietos su konkrečiais gavėjais.
Naudokite bendrus identifikatorius, kad skirtingos peržiūros remtųsi tuo pačiu inventoriumi. Jei programa vienoje lentelėje vadinama „klientų sistema“, o kitoje tiekėjo prekės ženklu, gali atrodyti, kad tai du skirtingi objektai. Prie vieno identifikatoriaus saugokite aiškų pavadinimą, paskirtį ir alternatyvius pavadinimus, kuriuos vartoja komanda.
Neįtraukite į bendrą žemėlapį prisijungimo paslapčių, raktų ar nereikalingų asmens įrašų pavyzdžių. Jis turėtų parodyti struktūrą, ne atskleisti visą sistemos turinį. Detalesnę techninę informaciją laikykite kontroliuojamoje vietoje ir žemėlapyje nurodykite, kur ją gali rasti įgaliotas darbuotojas.
Kaip surinkti faktus iš skirtingų komandų
Pradėkite nuo procesų interviu, bet neapsiribokite vien pokalbiu. Paprašykite parodyti įprastą darbo eigą, eksportą, ataskaitą ir klaidos atvejį. Darbuotojai gali laikyti savo papildomą skaičiuoklę laikina pagalbine priemone, nors ji naudojama kasdien ir joje yra didelė duomenų kopija. Tokį srautą reikia įtraukti pagal faktinį naudojimą.
Palyginkite interviu rezultatą su leistinais techniniais duomenimis: integracijų sąrašu, sutartomis sistemų konfigūracijomis ir tiekėjų sąrašu. Skirtingi šaltiniai gali nesutapti. Užuot iškart pasirinkę vieną, pažymėkite neatitikimą, jo savininką ir patikros veiksmą. Pavyzdžiui, finansų komanda gali nebenaudoti senos paslaugos, bet automatinis eksportas į ją vis dar veikia.
Surinktus srautus grąžinkite atitinkamiems savininkams patvirtinti. Koordinatorius negali iš bendro technologijos pavadinimo nustatyti visos perduodamų duomenų apimties. Patvirtinime paprašykite aiškiai pažymėti, kurios dalys patikrintos ir kurios priklauso nuo dar negauto tiekėjo atsakymo.
Vieno srauto detalus darbo lapas
Hipotetiniam srautui iš užsakymų portalo į sandėlio programą įrašykite šaltinio bei gavėjo identifikatorius, perduodamus laukus, perdavimo įvykį, kanalą ir klaidos valdymą. Pristatymo adresas gali būti reikalingas, o kliento rinkodaros pasirinkimas – ne. Jei duomenys siunčiami kiekvieną naktį, pažymėkite, kaip perduodami vėlesni pataisymai ir atšaukti užsakymai.
Atskirai nurodykite, ar gavėjas saugo savo kopiją ir kas ją pašalina. Duomenų pašalinimas portale nebūtinai panaikina sandėlio kopiją. Toks skirtumas svarbus teisių įgyvendinimui ir saugojimo taisyklei. Srauto lapas turėtų parodyti, ar pokyčiai sinchronizuojami automatiškai, ar reikalinga atskira užduotis.
Patikrinkite nesėkmingą perdavimą. Ar sistema pakartoja siuntimą, ar sukuria dublikatą, ar duomenys lieka tarpiniame faile? Laikinos eilės ir klaidų katalogai taip pat gali turėti asmens duomenų. Žemėlapyje pažymėkite šias vietas, jeigu jos reikšmingos saugojimui, atkūrimui ar incidento tyrimui.
Duomenų ir infrastruktūros vieta
Geografinę vietą aprašykite pagal faktinį duomenų bei prieigos kelią. Vien sąskaitą išrašančios bendrovės adresas neparodo, kur saugomi duomenys arba iš kur juos gali pasiekti pagalbos komanda. Paprašykite tiekėjo informacijos apie naudojamą paslaugą, jos regioną, pagalbos prieigą ir susijusius paslaugos teikėjus.
Kartu atskirkite fizinį saugojimą, nuotolinę prieigą ir teisinį gavėją. Šie elementai susiję, bet nėra vienodi. Žemėlapis turi padėti teisinį perdavimo vertinimą atlikti konkrečiam srautui, ne pagal bendrą išvadą „naudojame europinį tiekėją“. Nežinomą pagalbos prieigos vietą pažymėkite kaip klausimą, kurį būtina išspręsti.
Pokyčio poveikio analizė
Prieš keičiant tapatybės teikėją žemėlapis turi parodyti visas nuo jo priklausomas programas, administravimo paskyras ir alternatyvų prisijungimą. Taip komanda gali suplanuoti migraciją bei patikrinti, ar neliks senų prieigų. Jei dalis sistemos pasiekiama vietinėmis paskyromis, tai turi būti atskirai įtraukta į darbų sąrašą.
Prieš uždarant programą patikrinkite išeinančius ir įeinančius srautus, teisių prašymų paiešką, kopijas ir pagrįstai saugomus duomenis. Uždaryta naudotojo sąsaja nereiškia, kad ištrinti archyvai ar nutraukta integracija. Žemėlapio uždarymo įrašas turi parodyti, kur perkelta reikalinga informacija ir kas patvirtino likusių kopijų tvarkymą.
Praktiniai kokybės kriterijai
Žemėlapis pakankamai naudingas, kai kitas atsakingas žmogus gali nustatyti sistemos savininką, duomenų gavėjus ir sutrikimo priklausomybes nesikreipdamas į vieną nepasiekiamą ekspertą. Tai nereiškia, kad jame reikia visų techninių detalių. Svarbiausia, kad nuorodos ir atsakomybės vestų į tikrą, valdomą informaciją.
Per periodinę peržiūrą pasirinkite kelis pasikeitusius procesus ir patikrinkite, ar žemėlapis juos atspindi. Rodykite ne tik inventoriaus dydį, bet ir nepatvirtintų srautų skaičių bei svarbą. Mažas tikslus žemėlapis gali padėti priimti sprendimą, o didelis, seniai nepatikrintas brėžinys gali sudaryti klaidingą išsamumo įspūdį.
Kaip pasirinkti žemėlapio priemonę
Pradžioje gali pakakti kelių susietų lentelių ir aiškaus brėžinio, jeigu jos turi savininką bei versijų kontrolę. Specializuotą priemonę vertinkite pagal tai, ar ji padeda palaikyti realius ryšius, tvarkyti patvirtinimus ir pastebėti pokyčius. Automatiškai aptiktas techninis objektas savaime neatskleidžia verslo paskirties ar teisinio pagrindo.
Pirkimo bandymui naudokite vieną jau aprašytą procesą. Paprašykite parodyti, kaip įvedamas srautas, pakeičiamas tiekėjas, pažymima nepatikrinta priklausomybė ir eksportuojama informacija. Patikrinkite, ar skirtingi naudotojai mato tik jiems reikalingą detalumą. Žemėlapis pats gali atskleisti jautrią organizacijos struktūrą, todėl jo prieigos valdymas yra svarbus pasirinkimo kriterijus.
Vertinkite ir išėjimą iš priemonės. Jei vėliau pakeisite įrankį, turite išsaugoti objektų identifikatorius, ryšius, savininkus ir patvirtinimų istoriją tinkamu formatu. Gražus paveikslėlis be susietų duomenų gali būti naudingas pristatymui, tačiau nepakankamas tolesniam inventoriaus palaikymui.