Softver povezanog ormarića Promjena kontrole nakon primopredaje
Osiguravanje stabilnosti sistema, jasne odgovornosti i dugoročne-sigurnosti na hardveru, terminalskom softveru, API-ju i uslugama u oblaku nakon{1}}uvođenja.
Zašto je važna promjena kontrole nakon predaje projekta ormarića
Projekt povezanog ormarića se ne završava kada su ormari instalirani i prva vrata se otvore. Operativno okruženje može uključivati kontroler kabineta, softver terminala, server, platformu operatera, korisničke sisteme, mrežnu opremu i servisno osoblje. Promjena u jednom sloju može uticati na drugi.
Praktično pitanje za kupca nije samo da li ormarić radi na dan isporuke, već i ko odlučuje šta se kasnije može promijeniti i ko koordinira odgovor kada promjena dovede do neočekivanog rezultata.
ilustrativna arhitektura projektaCybersecurity & Remediation Responsibility
Agencija Sjedinjenih Američkih Država za kibernetičku sigurnost i sigurnost infrastrukture održava Katalog poznatih iskorištenih ranjivosti, javnu referencu fokusiranu na ranjivosti za koje se zna da su iskorištavane u stvarnom-svjetskom okruženju. CISA preporučuje korištenje ove vrste informacija kao jednog ulaza kada organizacije daju prioritet upravljanju ranjivostima.
Ova javna referenca ne opisuje YS LOCKER projekat i ne certificira nijednog proizvođača ormarića. Za povezanog operatera ormarića, koristan je podsjetnik da definiraju odgovornost za održavanje softvera i sanaciju kao dio plana primopredaje za efikasnurješenja paketnih ormarića.
Pet odluka koje treba donijeti prije objavljivanja softvera
Imenujte vlasnika izdanja
Operater treba da identifikuje ko može da zahteva izmenu softvera, ko razmatra njen uticaj na poslovanje i ko daje konačno odobrenje. Promjena može uključiti terminal ormarića, korisničku platformu, interfejs za{1}}kontrolu brave ili uslugu- na strani servera. Ako vlasništvo nije upisano, operater može pretpostaviti da dobavljač opreme kontroliše kompletan sistem, dok je dobavljač odgovoran samo za definisani sloj hardvera ili interfejsa.
Opišite zahvaćeni radni tok
Prije testiranja, projektni tim bi trebao opisati na šta izdanje može utjecati. Primjeri uključuju identifikaciju kurira, dodjelu odjeljka, komande na vratima, pristup primaoca, povratne informacije o statusu, zapise događaja, obavještenja ili izvoz podataka. Tim takođe treba da navede koji su tokovi posla izvan promene. Kratak zapis o uticaju je često korisniji od opšte izjave da je platforma ažurirana.
Testirajte granicu interfejsa
Kada korisnik koristi vlastiti softver, API ili protokol kontrolne ploče za zaključavanje-mogu biti jedan dio sistema. Kupac i integrator treba da se dogovore koja strana priprema podatke za testiranje, provjerava odziv vrata i bilježi greške. Testni slučajevi bi trebali pokrivati normalne komande, nevažeće unose, odgođene odgovore, prekide povezivanja i primopredaje transakcija za uspješneIntegracija softvera pametnog ormarića.
Odobre puštanje sa dokazima
Odobrenje bi trebalo da se zasniva na zapisu o verziji, rezultatu testiranja, pogođenom uređaju ili listi lokacija, planiranom vremenu objavljivanja, kontaktu za podršku i odluci o oporavku. Tačni dokumenti zavise od projekta. Operatoru više-lokacija može biti potrebno i postupno uvođenje umjesto istovremenog ažuriranja. Važna stvar je da odluka o puštanju bude vidljiva ljudima koji svakodnevno upravljaju ormarićima.
Definirajte vraćanje vlasništva
Plan vraćanja u prethodno stanje treba da odgovori ko može da zaustavi izdanje, ko vraća prethodnu verziju ili konfiguraciju, kako se evidentiraju transakcije na koje utiče i ko obaveštava tim sajta. Nemojte pretpostavljati da se svaki sistem može vratiti na isti način. Dostupna metoda oporavka zavisi od potvrđene softverske arhitekture, rasporeda servera, modela uređaja i ugovora o usluzi.
ilustrativna arhitektura projekta
Kako preispitujemo granice sa kupcem iz inostranstva
U YS LOCKER-u počinjemo s potvrđenom arhitekturom projekta umjesto da pretpostavljamo da svaki povezani ormarić koristi isti softverski model. Možemo pregledati konfiguraciju ormara, terminalne uređaje, API ili dokumente protokola za zaključavanje-kontrolne ploče, softver u vlasništvu korisnika-, odgovornosti servera i očekivani proces primopredaje. Ako korisnik već ima operativnu platformu, možemo procijeniti informacije potrebne za integraciju-strane ormarića nakon dostavljanja relevantnih dokumenata.
Naša uloga mora biti definisana projektnom dokumentacijom. Odobrenje za izdavanje softvera, praćenje ranjivosti, automatsko vraćanje nazad, daljinski oporavak i dugoročno-održavanje nisu predstavljeni kao univerzalne standardne funkcije. Kada su kupcu potrebne ove funkcije, preporučujemo da ih potvrdite kao zasebne tehničke i servisne zahtjeve prije proizvodnje i isporuke.
✓Praktična kontrolna lista kupaca
Opseg sistema:Koji slojevi ormara, terminala, kontrolera, servera i korisničkog softvera su uključeni u projekat?
Vlasništvo i evidencija:Ko posjeduje svaki interfejs, polje podataka, odluku o izdanju, rezultat testa i zapis o incidentu?
Pre{0}}testiranje:Šta se mora testirati prije nego što izdanje stigne do jedne stranice ili šire mreže ormarića?
Protokol oporavka:Koja je odobrena metoda oporavka ako oslobađanje utiče na komande vrata, zapise statusa ili pristup korisnika?
Uloge održavanja:Za koje radnje održavanja je potrebno osoblje na lokaciji, integrator, dobavljač ili ovlašteni administrator?
Često postavljana pitanja
Da li CISA certificira proizvode za pametne ormariće?
Ne. CISA KEV katalog je javna referenca za poznate iskorišćene ranjivosti. To nije certifikat proizvoda, odobrenje dobavljača ili ocjena performansi.
Može li YS LOCKER upravljati svakim softverskim slojem u projektu povezanog ormarića?
Ne podrazumevano. Možemo obezbijediti ili pregledati elemente interfejsa za hardver, terminal, server i zaključavanje{1}}u skladu sa potvrđenim obimom projekta. Kupac može koristiti vlastiti softver ili platformu-treće strane, a odgovornosti moraju biti dogovorene u tehničkom rješenju.
Može li se svaka promjena softvera automatski poništiti?
To ne treba pretpostavljati. Metoda vraćanja u prethodno stanje zavisi od potvrđenih uređaja, softverske arhitekture, rasporeda servera i odgovornosti za uslugu. Preporučujemo da definirate proces oporavka prije nego što se izdanje odobri.
Šta bi kupac trebao poslati na pregled integracije?
Molimo navedite model ormarića ili ciljnu konfiguraciju, količinu uređaja, radni tok, dokumente interfejsa, raspored servera, odgovornosti za izdavanje i očekivanja održavanja. Tada možemo identificirati granicu hardvera i softvera kojoj je potrebna dodatna potvrda.
Planirajte sljedeću promjenu prije nego što se dogodi prva promjena
Povezani ormarić je operativni sistem napravljen od fizičke opreme, pristupnih uređaja, softvera, podataka i ljudi. Kontrola promjena čini ove slojeve razumljivim nakon primopredaje. Omogućava operateru jasan način da odobri oslobađanje, verifikuje interfejs, snimi izuzetak i dodeli rad oporavka bez tretiranja svakog problema kao greške u ormaru.
Pošaljite YS LOCKER vašu trenutnu arhitekturu ormarića, dokumente o interfejsu, količinu uređaja, operativni softver i tabelu odgovornosti za održavanje. Pregledat ćemo granice projekta i identificirati informacije potrebne za praktičan plan kontrole{1}}promjene povezanih ormarića.
Zahtjevkonsultacije o projektu pametnog ormarića →