Un air gap reprezintă izolarea fizică a unui sistem informatic sau a unei rețele de rețelele nesecurizate, inclusiv de internetul public. Sistemele air-gapped nu au conexiuni prin cablu sau fără fir la rețele externe; transferul de date necesită deplasarea fizică a suporturilor de stocare aprobate sau a dispozitivelor de transfer unidirecțional de date. Air gap-urile reprezintă cel mai fundamental control de securitate pentru cele mai sensibile sisteme de informații clasificate: nicio cantitate de securitate software nu poate compensa o conexiune fizică la rețea atunci când modelul de amenințare include adversari la nivel de stat-națiune cu capacități cibernetice ofensive sofisticate.
Implementarea și întreținerea software-ului modern pe sisteme air-gapped necesită o abordare inginerească fundamental diferită față de implementările conectate la internet. Funcționalitățile de confort pe care echipele de dezvoltare le utilizează — manageri de pachete automatizați care extrag dependențe din depozite publice, imagini de containere extrase din Docker Hub sau registre publice, pipeline-uri CI/CD care accesează servicii SaaS externe, instrumente de management al configurației care comunică cu planuri de control cloud — toate eșuează în medii air-gapped. Software-ul trebuie să funcționeze fără niciuna dintre aceste conexiuni, iar procesul de dezvoltare și operare trebuie proiectat să susțină aceasta de la bun început.
Ce Înseamnă Air-Gap și Unde Este Necesar
Air gap-urile sunt necesare oriunde clasificarea sau sensibilitatea datelor prelucrate sau a sistemelor controlate justifică izolarea fizică a rețelei. În contexte militare:
Facilitățile de Informații Compartimentate Sensibile (SCIF) sunt camere sau clădiri securizate fizic unde informațiile clasificate peste SECRET — în special SCI (Informații Compartimentate Sensibile) — pot fi prelucrate și discutate. Sistemele informatice din interiorul unui SCIF care gestionează date la nivel SCI trebuie să fie air-gapped față de rețelele neacreditate la același nivel de clasificare. Securitatea fizică a SCIF (acces controlat, mascarea sunetului, blindaj electromagnetic în unele cazuri) combinată cu air gap-ul creează granița de securitate.
Rețelele operaționale clasificate — SECRET sau mai sus — sunt air-gapped față de rețelele neclasificate. Transferul de date între niveluri de clasificare necesită o Soluție de Domenii Încrucișate (CDS): un sistem hardware-software care aplică reguli de transfer de informații (inspecție de conținut, validare format, aplicarea transferului unidirecțional) între cele două niveluri de rețea. CDS în sine este un produs de securitate specializat care trebuie evaluat și aprobat de o autoritate de securitate națională.
Controlerele sistemelor de armament și sistemele integrate — computere de control al focului, sisteme de navigație, controlere radar și senzori — sunt air-gapped față de rețelele operaționale ca parte a arhitecturii lor de securitate. Actualizările software pentru aceste sisteme sunt livrate prin interfața de întreținere a platformei, folosind suporturi media aprobate, urmând o procedură documentată și testată.
Implementarea Software Fără Internet: Registre de Artefacte și Oglinzi de Pachete
Într-un mediu air-gapped, fiecare dependență software de care are nevoie o aplicație trebuie să fie prezentă în mediu înainte de implementare. Nimic nu poate fi extras din internet la momentul implementării. Aceasta necesită construirea unui ecosistem intern de artefacte care oglindește resursele externe pe care aplicația s-ar baza altfel.
Harbor este registrul de containere open-source certificat CNCF și reprezintă alegerea standard pentru registrele interne de imagini de containere în medii de apărare air-gapped. Harbor oferă: stocare și replicare de imagini (pentru distribuirea imaginilor în mai multe medii air-gapped dintr-o singură sursă), scanare de vulnerabilități ale imaginilor (prin Trivy), fiabilitate de conținut (verificarea semnăturilor digitale pentru imagini) și controale de acces bazate pe roluri. Popularea registrului Harbor necesită un proces de import al imaginilor de containere pre-aprobate, pre-scanate din afara air gap-ului prin suporturi media aprobate.
Oglinzile offline de pachete replică depozitele publice de pachete pentru utilizare în interiorul air gap-ului. Pentru Python, o oglindă internă PyPI (folosind instrumente precum bandersnatch sau devpi) servește cererile pip din interiorul mediului. Pentru npm, o instanță Nexus sau Artifactory (sau Verdaccio open-source) servește cererile npm. Pentru imaginile de bază ale containerelor, un proces sincronizează imaginile aprobate din registrul extern la instanța internă Harbor. Oglinda de pachete trebuie populată și menținută actualizată prin procesul aprobat de transfer de suporturi media.
Procesul de management al dependențelor trebuie să fie explicit: înainte de a începe dezvoltarea unei funcționalități care va fi implementată într-un mediu air-gapped, dezvoltatorul trebuie să identifice explicit toate dependențele (inclusiv dependențele tranzitive) și să verifice că acestea sunt prezente în oglinda internă. Adăugarea unei noi dependențe necesită o cerere de transfer de suporturi media și un proces de aprobare — implicând de obicei revizuirea de securitate a noului pachet înainte de admiterea sa în mediul air-gapped. Acest proces încetinește dezvoltarea și trebuie bugetat în planificarea sprint-urilor.
Managementul Patch-urilor: Pachete Testate și Controlul Schimbărilor
Managementul patch-urilor în medii air-gapped nu poate folosi sisteme automate de management al patch-urilor care extrag actualizări din serviciile cloud ale furnizorilor. În schimb, managementul patch-urilor necesită un proces definit, documentat pentru aducerea patch-urilor din afara air gap-ului în interiorul acestuia, testarea lor într-un mediu reprezentativ și aplicarea lor în mod controlat.
Pregătirea pachetului de patch-uri începe în afara air gap-ului: echipa de management al patch-urilor identifică patch-urile necesare (din buletinele de securitate ale furnizorilor, catalogul CISA de Vulnerabilități Exploatate Cunoscute și actualizările STIG), le descarcă din sursele furnizorilor, le verifică autenticitatea (verificare sumă de control și semnătură digitală) și le ambalează pentru transfer. Pachetul este revizuit de echipa de securitate și aprobat pentru transfer prin fluxul de lucru aprobat de suporturi media.
Transferul prin suporturi media amovibile aprobate este mecanismul standard pentru mutarea patch-urilor prin air gap. Procedurile pentru suporturi media aprobate implică de obicei: utilizarea exclusivă a suporturilor media gestionate de organizație (nu USB-uri personale), scanarea antivirus a suporturilor media pe ambele părți ale air gap-ului, utilizarea suporturilor media de scriere unică (discuri optice) pentru trasee de audit ireversibile, documentarea fiecărui transfer cu conținut, dată, aprobator și operator, și distrugerea suporturilor media care au traversat de la un mediu cu clasificare mai înaltă la unul cu clasificare mai joasă conform procedurilor de distrugere a clasificărilor.
Testarea în etape este non-negociabilă pentru sistemele operaționale air-gapped: patch-urile trebuie testate într-un mediu de pregătire care oglindește configurația de producție înainte de aplicarea în producție. Un patch care destabilizează un sistem de producție air-gapped nu poate fi retrogradat pur și simplu prin extragerea versiunii anterioare dintr-o sursă de internet — mecanismul de rollback trebuie, de asemenea, pre-pregătit în mediu.
Rotația Secretelor în Medii Air-Gapped
Secretele — certificate TLS, credențiale de baze de date, chei API — expiră și trebuie rotate. În mediile conectate la internet, rotația secretelor este din ce în ce mai automatizată: HashiCorp Vault generează și rotează dinamic credențialele; instrumentele de management al certificatelor (cert-manager în Kubernetes) reînoiesc automat certificatele TLS prin ACME. Niciunul dintre aceste mecanisme automatizate nu funcționează în medii air-gapped deoarece se bazează pe conectivitate la rețea către autoritățile de certificare și API-urile de management al secretelor care nu sunt accesibile din interiorul air gap-ului.
Modulele de Securitate Hardware (HSM) furnizează rădăcina de încredere pentru operațiunile criptografice în medii clasificate air-gapped. Un HSM (precum un dispozitiv Thales Luna sau nCipher nShield) stochează chei private în hardware rezistent la manipulare, efectuează operațiuni criptografice fără expunerea materialului cheii și oferă securitate validată FIPS 140-2 Nivel 3 sau Nivel 4 — îndeplinind cerințele pentru modulele criptografice ale sistemelor clasificate conform CNSSP Nr. 15.
Procedurile de seif offline și ceremonie de chei definesc modul în care secretele sunt rotate fără instrumente automatizate. O ceremonie de chei este o procedură formală, documentată — cu mai mulți membri autorizați prezenți — pentru generarea, încărcarea sau rotarea cheilor criptografice. Ceremonia este înregistrată în detaliu (cine a fost prezent, ce acțiuni au fost întreprinse, în ce ordine) pentru a furniza o urmă de audit. Pentru rotația certificatelor TLS, ceremonia implică generarea unei noi cereri de certificat, semnarea acesteia cu cheia CA offline (stocată în HSM) și distribuirea noului certificat sistemelor consumatoare prin suporturi media aprobate.
CI/CD pentru Medii Air-Gapped
Pipeline-urile de integrare și implementare continuă pot funcționa în medii air-gapped cu alegeri corecte de instrumente. Infrastructura pipeline trebuie să fie complet autonomă în interiorul air gap-ului, fără dependențe de servicii cloud.
GitLab Community Edition implementat on-premises este platforma standard self-hosted de git și CI/CD pentru medii air-gapped. GitLab CE oferă: găzduire de depozite git, fluxuri de lucru pentru cereri de fuzionare, execuția pipeline-urilor CI/CD (folosind GitLab Runners implementați în același mediu), registru de pachete (pentru artefacte) și registru de containere (pentru imagini Docker). Nu este necesară nicio conectivitate cloud — toată funcționalitatea GitLab este autonomă.
GitLab Runners trebuie configurați cu acces la oglinzile interne de pachete (oglinzi interne PyPI, npm, Maven) în locul depozitelor externe de pachete. Etapele de pipeline care ar apela în mod normal servicii externe (scanarea vulnerabilităților containerelor prin API-uri cloud, instrumente SAST care necesită validarea licențelor, webhook-uri de notificare) trebuie reconfigurate pentru a utiliza echivalente interne sau dezactivate.
Concluzie cheie: Cea mai costisitoare greșeală în programele de software de apărare air-gapped este proiectarea software-ului pentru implementare conectată la internet și încercarea de a-l adapta retroactiv pentru funcționare air-gapped târziu în ciclul de dezvoltare. Compatibilitatea air-gap trebuie să fie o cerință de proiectare de la bun început: nicio dependență de servicii cloud în aplicația de bază, toate dependențele catalogate explicit și disponibile în oglinzi interne, iar procesul de implementare și operare proiectat în jurul fluxului de lucru de transfer de la bun început.