Pievienotā skapja programmatūras maiņas vadība pēc nodošanas
Nodrošiniet sistēmas stabilitāti, skaidrus pienākumus un ilgtermiņa{0}}aparatūras, termināļa programmatūras, API un mākoņpakalpojumu drošību pēc-izvietošanas.
Kāpēc maiņas kontrole ir svarīga pēc skapja projekta nodošanas
Savienots skapja projekts nebeidzas, kad ir uzstādīti skapji un atveras pirmās durvis. Darbības vide var ietvert skapja kontrolieri, termināļa programmatūru, serveri, operatora platformu, klientu sistēmas, tīkla aprīkojumu un apkalpojošo personālu. Izmaiņas vienā slānī var ietekmēt citu.
Praktisks pircēja jautājums ir ne tikai tas, vai piegādes datumā skapītis strādā, bet arī tas, kurš izlemj, kas vēlāk var mainīties un kas koordinē reakciju, ja izmaiņas rada negaidītu rezultātu.
ilustratīvā projekta arhitektūraKiberdrošības un sanācijas atbildība
Amerikas Savienoto Valstu Kiberdrošības un infrastruktūras drošības aģentūra uztur zināmo izmantoto ievainojamību katalogu — publisku atsauci, kas koncentrējas uz ievainojamībām, par kurām zināms, ka tās ir izmantotas reālajā vidē{0}}. CISA iesaka izmantot šāda veida informāciju kā vienu ievades veidu, kad organizācijas nosaka ievainojamības pārvaldības prioritāti.
Šī publiskā atsauce neapraksta YS LOCKER projektu un nesertificē nevienu skapīšu ražotāju. Pieslēgtam skapja operatoram tas ir noderīgs atgādinājums definēt programmatūras uzturēšanas un atlīdzināšanas atbildību kā daļu no nodošanas plāna, lai nodrošinātu efektīvupaku skapīšu risinājumi.
Pieci lēmumi, kas jāpieņem pirms programmatūras izlaišanas
Nosauciet laidiena īpašnieku
Operatoram ir jānosaka, kurš var pieprasīt programmatūras izmaiņas, kurš pārskata tās ietekmi uz uzņēmējdarbību un kas sniedz galīgo apstiprinājumu. Izmaiņas var būt saistītas ar skapja termināli, klienta platformu, bloķēšanas-vadības saskarni vai servera-puses pakalpojumu. Ja īpašumtiesības nav norakstītas, operators var pieņemt, ka iekārtu piegādātājs kontrolē visu sistēmu, kamēr piegādātājs ir atbildīgs tikai par noteiktu aparatūras vai saskarnes slāni.
Aprakstiet ietekmēto darbplūsmu
Pirms testēšanas projekta komandai jāapraksta, ko laidiens var ietekmēt. Piemēri: kurjera identifikācija, nodalījuma piešķiršana, durvju komandas, adresāta piekļuve, atsauksmes par statusu, notikumu ieraksti, paziņojumi vai datu eksportēšana. Komandai arī jānorāda, kuras darbplūsmas ir ārpus izmaiņām. Īss ietekmes ieraksts bieži vien ir noderīgāks nekā vispārīgs paziņojums, ka platforma ir atjaunināta.
Pārbaudiet interfeisa robežu
Ja klients izmanto savu programmatūru, bloķēšanas -vadības paneļa API vai protokols var būt viena sistēmas daļa. Pircējam un integratoram jāvienojas, kura puse sagatavo testa datus, pārbauda durvju reakciju un reģistrē kļūdas. Pārbaudes gadījumiem jāietver parastas komandas, nederīgas ievades, aizkavētas atbildes, savienojamības pārtraukumi un darījumu nodošana veiksmīgai darbībai.viedā skapja programmatūras integrācija.
Apstipriniet atbrīvošanu ar pierādījumiem
Apstiprināšanai ir jābūt balstītai uz versijas ierakstu, testa rezultātu, ietekmēto ierīču vai vietņu sarakstu, plānoto izlaišanas laiku, atbalsta saziņu un atkopšanas lēmumu. Precīzi dokumenti ir atkarīgi no projekta. Vairāku-vietņu operatoram var būt nepieciešama pakāpeniska izlaišana, nevis vienlaicīga atjaunināšana. Svarīgi ir panākt, lai lēmums par atbrīvošanu būtu redzams cilvēkiem, kuri katru dienu izmanto skapīšus.
Definējiet atcelšanas īpašumtiesības
Atcelšanas plānā ir jāatbild, kurš var apturēt laidienu, kurš atjauno iepriekšējo versiju vai konfigurāciju, kā tiek reģistrēti ietekmētie darījumi un kas informē vietnes komandu. Nedomājiet, ka katru sistēmu var atgriezt tādā pašā veidā. Pieejamā atkopšanas metode ir atkarīga no apstiprinātās programmatūras arhitektūras, servera izkārtojuma, ierīces modeļa un pakalpojuma līguma.
ilustratīvā projekta arhitektūra
Kā mēs pārskatām robežas ar ārzemju pircēju
YS LOCKER mēs sākam ar apstiprināto projekta arhitektūru, nevis pieņemam, ka katrs pievienotais skapītis izmanto vienu un to pašu programmatūras modeli. Mēs varam pārskatīt korpusa konfigurāciju, termināļa ierīces, bloķēšanas-vadības paneļa API vai protokola dokumentus, klientam piederošo-programmatūru, servera pienākumus un paredzamo nodošanas procesu. Ja klientam jau ir darbības platforma, mēs varam novērtēt informāciju, kas nepieciešama skapīša -puses integrācijai pēc attiecīgo dokumentu iesniegšanas.
Mūsu lomai jābūt noteiktai projekta dokumentos. Programmatūras izlaišanas apstiprināšana, ievainojamības uzraudzība, automātiska atcelšana, attālā atkopšana un ilgtermiņa apkope-netiek uzrādītas kā universālas standarta funkcijas. Ja klientam ir nepieciešamas šīs funkcijas, mēs iesakām tās apstiprināt kā atsevišķas tehniskās un servisa prasības pirms ražošanas un piegādes.
✓Praktisks pircēja kontrolsaraksts
Sistēmas darbības joma:Kuri korpusa, termināļa, kontrollera, servera un klienta programmatūras slāņi ir iekļauti projektā?
Īpašumtiesības un ieraksti:Kam pieder katra saskarne, datu lauks, lēmums par atbrīvošanu, testa rezultāts un incidentu ieraksts?
Pirms-izlaiduma testēšana:Kas ir jāpārbauda, pirms laidiens nonāk vienā vietnē vai plašākā skapīšu tīklā?
Atkopšanas protokols:Kāda ir apstiprinātā atkopšanas metode, ja izlaidums ietekmē durvju komandas, statusa ierakstus vai lietotāja piekļuvi?
Uzturēšanas lomas:Kurām uzturēšanas darbībām ir nepieciešams vietnes personāls, integrators, piegādātājs vai pilnvarots administrators?
Bieži uzdotie jautājumi
Vai CISA sertificē viedo skapīšu produktus?
Nē. CISA KEV katalogs ir publiska atsauce uz zināmām izmantotajām ievainojamībām. Tas nav produkta sertifikācija, piegādātāja apstiprinājums vai veiktspējas novērtējums.
Vai YS LOCKER var pārvaldīt katru programmatūras slāni savienotā skapja projektā?
Nav pēc noklusējuma. Mēs varam nodrošināt vai pārskatīt aparatūras, termināļa, servera un bloķēšanas-vadības saskarnes elementus atbilstoši apstiprinātajam projekta apjomam. Klients var izmantot savu programmatūru vai trešās puses platformu, un par pienākumiem ir jāvienojas tehniskajā risinājumā.
Vai visas programmatūras izmaiņas var automātiski atsaukt?
To nevajadzētu pieņemt. Atcelšanas metode ir atkarīga no apstiprinātajām ierīcēm, programmatūras arhitektūras, servera izkārtojuma un atbildības par pakalpojumu. Pirms laidiena apstiprināšanas ieteicams definēt atkopšanas procesu.
Kas pircējam jānosūta integrācijas pārskatīšanai?
Lūdzu, norādiet skapja modeli vai mērķa konfigurāciju, ierīces daudzumu, darbības darbplūsmu, saskarnes dokumentus, servera izkārtojumu, atbrīvošanas pienākumus un uzturēšanas prasības. Pēc tam mēs varam noteikt aparatūras un programmatūras robežu, kurai nepieciešams papildu apstiprinājums.
Plānojiet nākamās izmaiņas, pirms notiek pirmās izmaiņas
Savienots skapītis ir operētājsistēma, kas sastāv no fiziska aprīkojuma, piekļuves ierīcēm, programmatūras, datiem un cilvēkiem. Izmaiņu kontrole saglabā šos slāņus saprotamus pēc nodošanas. Tas sniedz operatoram skaidru veidu, kā apstiprināt izlaidumu, pārbaudīt saskarni, reģistrēt izņēmumu un piešķirt atkopšanas darbu, neuzskatot katru problēmu kā skapja kļūdu.
Nosūtiet YS LOCKER savu pašreizējo skapja arhitektūru, saskarnes dokumentus, ierīču daudzumu, darbības programmatūru un uzturēšanas atbildības tabulu. Mēs pārskatīsim projekta robežu un noteiksim informāciju, kas nepieciešama praktiskai savienotā skapja maiņas{1}}vadības plānam.
Pieprasītviedo skapīšu projekta konsultācija →