Prijungtos spintelės programinės įrangos keitimo valdymas po perdavimo
Sistemos stabilumo, aiškios atsakomybės ir ilgalaikės aparatinės įrangos, terminalo programinės įrangos, API ir debesies paslaugų saugumo užtikrinimas po-diegimo.
Kodėl svarbu pakeisti valdymą po to, kai buvo perduotas spintelių projektas
Sumontavus spinteles ir atsidarius pirmas duris, prijungtas spintelės projektas nesibaigia. Operacinė aplinka gali apimti kabineto valdiklį, terminalo programinę įrangą, serverį, operatoriaus platformą, klientų sistemas, tinklo įrangą ir aptarnaujantį personalą. Vieno sluoksnio pasikeitimas gali turėti įtakos kitam.
Praktinis pirkėjo klausimas yra ne tik tai, ar spintelė veikia pristatymo dieną, bet ir tai, kas nusprendžia, kas vėliau gali pasikeisti ir kas koordinuoja atsakymą, kai pakeitimas sukuria netikėtą rezultatą.
Atsakomybė už kibernetinį saugumą ir taisymą
Jungtinių Valstijų kibernetinio saugumo ir infrastruktūros saugumo agentūra tvarko žinomų išnaudotų pažeidžiamumų katalogą – viešą nuorodą, skirtą pažeidžiamoms vietoms, kurios, kaip žinoma, buvo išnaudotos realioje{0}}pasaulio aplinkoje. CISA rekomenduoja naudoti šio tipo informaciją kaip vieną įvestį, kai organizacijos teikia pirmenybę pažeidžiamumo valdymui.
Ši vieša nuoroda neaprašo YS LOCKER projekto ir nesertifikuoja nė vieno spintelės gamintojo. Prijungtam spintelės operatoriui tai yra naudingas priminimas apibrėžti programinės įrangos priežiūros ir taisymo atsakomybę kaip dalį perdavimo plano, kad būtų veiksmingas.siuntų spintelių sprendimai.
Penki sprendimai, kuriuos reikia priimti prieš išleidžiant programinę įrangą
Pavadinkite leidimo savininką
Operatorius turėtų nustatyti, kas gali prašyti pakeisti programinę įrangą, kas peržiūri jos poveikį verslui ir kas suteikia galutinį patvirtinimą. Pakeitimas gali būti susijęs su spintelės terminalu, klientų platforma, užrakto-valdymo sąsaja arba serverio-puse paslauga. Jei nuosavybės teisė nenurašyta, operatorius gali manyti, kad įrangos tiekėjas kontroliuoja visą sistemą, o tiekėjas yra atsakingas tik už apibrėžtą aparatinės įrangos arba sąsajos sluoksnį.
Apibūdinkite paveiktą darbo eigą
Prieš bandymą projekto komanda turėtų aprašyti, ką leidimas gali paveikti. Pavyzdžiai: kurjerio identifikavimas, skyriaus priskyrimas, durų komandos, gavėjo prieiga, atsiliepimai apie būseną, įvykių įrašai, pranešimai arba duomenų eksportavimas. Komanda taip pat turėtų nurodyti, kurios darbo eigos nepatenka į pakeitimą. Trumpas poveikio įrašas dažnai yra naudingesnis nei bendras pareiškimas, kad platforma buvo atnaujinta.
Patikrinkite sąsajos ribą
Kai klientas naudoja savo programinę įrangą, užrakto{0}}valdymo plokštės API arba protokolas gali būti viena sistemos dalis. Pirkėjas ir integratorius turėtų susitarti, kuri šalis rengia bandymo duomenis, tikrina durų atsaką ir fiksuoja klaidas. Bandomieji atvejai turėtų apimti įprastas komandas, netinkamas įvestis, uždelstus atsakymus, ryšio trikdžius ir operacijų perdavimus, kad būtų sėkmingas.išmaniosios spintelės programinės įrangos integravimas.
Patvirtinti išleidimą su įrodymais
Patvirtinimas turėtų būti pagrįstas versijos įrašu, bandymo rezultatu, paveiktų įrenginių arba svetainių sąrašu, planuojamu išleidimo laiku, palaikymo kontaktu ir atkūrimo sprendimu. Tikslūs dokumentai priklauso nuo projekto. Kelių-svetainių operatoriui taip pat gali prireikti laipsniško išleidimo, o ne naujinimo vienu metu. Svarbu, kad sprendimas paleisti būtų matomas žmonėms, kurie kasdien valdo spinteles.
Apibrėžkite nuosavybės teisės grąžinimą
Atkūrimo planas turėtų atsakyti, kas gali sustabdyti leidimą, kas atkuria ankstesnę versiją arba konfigūraciją, kaip įrašomos paveiktos operacijos ir kas informuoja svetainės komandą. Nemanykite, kad kiekviena sistema gali būti grąžinta taip pat. Galimas atkūrimo būdas priklauso nuo patvirtintos programinės įrangos architektūros, serverio išdėstymo, įrenginio modelio ir paslaugų sutarties.
iliustracinė projekto architektūra
Kaip mes peržiūrime ribas su užsienio pirkėju
YS LOCKER pradedame nuo patvirtintos projekto architektūros, o ne darome prielaidą, kad kiekviena prijungta spintelė naudoja tą patį programinės įrangos modelį. Galime peržiūrėti korpuso konfigūraciją, galinius įrenginius, užrakto-valdymo plokštės API arba protokolo dokumentus, klientui-priklausomą programinę įrangą, serverio atsakomybę ir numatomą perdavimo procesą. Jei klientas jau turi operacinę platformą, pateikę atitinkamus dokumentus galime įvertinti informaciją, reikalingą spintelės integravimui.
Mūsų vaidmuo turi būti apibrėžtas projekto dokumentuose. Programinės įrangos leidimo patvirtinimas, pažeidžiamumo stebėjimas, automatinis atšaukimas, nuotolinis atkūrimas ir ilgalaikė -priežiūra nėra pateikiamos kaip universalios standartinės funkcijos. Jei klientui reikia šių funkcijų, rekomenduojame prieš gaminant ir pristatant jas patvirtinti kaip atskirus techninius ir aptarnavimo reikalavimus.
✓Praktinis pirkėjo kontrolinis sąrašas
Sistemos taikymo sritis:Kurie korpuso, terminalo, valdiklio, serverio ir kliento programinės įrangos sluoksniai yra įtraukti į projektą?
Nuosavybė ir įrašai:Kam priklauso kiekviena sąsaja, duomenų laukas, sprendimas išleisti, bandymo rezultatas ir incidentų įrašas?
Išankstinis{0}}išleidimas:Ką reikia išbandyti, kol leidimas pasiekia vieną svetainę ar platesnį saugyklų tinklą?
Atkūrimo protokolas:Koks yra patvirtintas atkūrimo metodas, jei leidimas paveikia durų komandas, būsenos įrašus arba vartotojo prieigą?
Priežiūros vaidmenys:Kuriems priežiūros darbams atlikti reikalingi svetainės darbuotojai, integratorius, tiekėjas ar įgaliotas administratorius?
Dažnai užduodami klausimai
Ar CISA sertifikuoja išmaniųjų spintelių gaminius?
Ne. CISA KEV katalogas yra vieša žinomų išnaudotų pažeidžiamumų nuoroda. Tai nėra produkto sertifikavimas, tiekėjo patvirtinimas ar našumo įvertinimas.
Ar YS LOCKER gali valdyti kiekvieną prijungto spintelės projekto programinės įrangos sluoksnį?
Ne pagal nutylėjimą. Galime pateikti arba peržiūrėti techninės įrangos, terminalo, serverio ir užrakto{1}}valdymo sąsajos elementus pagal patvirtintą projekto apimtį. Klientas gali naudoti savo programinę įrangą arba trečiosios šalies platformą, o dėl atsakomybės turi būti susitarta techniniame sprendime.
Ar kiekvienas programinės įrangos pakeitimas gali būti automatiškai atšauktas?
To nereikėtų manyti. Atšaukimo metodas priklauso nuo patvirtintų įrenginių, programinės įrangos architektūros, serverio išdėstymo ir atsakomybės už paslaugą. Prieš patvirtinant leidimą rekomenduojame apibrėžti atkūrimo procesą.
Ką pirkėjas turėtų siųsti integracijos peržiūrai?
Pateikite spintelės modelį arba tikslinę konfigūraciją, įrenginio kiekį, darbo eigą, sąsajos dokumentus, serverio išdėstymą, išleidimo atsakomybę ir priežiūros lūkesčius. Tada galime nustatyti aparatinės ir programinės įrangos ribą, kuriai reikia papildomo patvirtinimo.
Suplanuokite kitą pakeitimą prieš įvykstant pirmajam pakeitimui
Prijungta spintelė yra operacinė sistema, sudaryta iš fizinės įrangos, prieigos įrenginių, programinės įrangos, duomenų ir žmonių. Pakeitimų valdymas leidžia suprasti šiuos sluoksnius po perdavimo. Tai suteikia operatoriui aiškų būdą patvirtinti leidimą, patikrinti sąsają, įrašyti išimtį ir priskirti atkūrimo darbus, nelaikant kiekvienos problemos kaip spintelės gedimo.
Atsiųskite YS LOCKER savo dabartinę spintelės architektūrą, sąsajos dokumentus, įrenginių kiekį, operacinę programinę įrangą ir priežiūros atsakomybės lentelę. Peržiūrėsime projekto ribas ir nustatysime informaciją, reikalingą praktiniam prijungtos spintelės keitimo{1}}valdymo planui.
Prašymasišmaniosios spintelės projekto konsultacija →





