Kā aizsargāt piekļuvi serverim, nepalēninot darbu

Publicēts 2026. gada 5. augustā

Servera konts ar vienkāršu paroli, atvērtu attālināto piekļuvi un koplietotiem administratora akreditācijas datiem nav ērtība. Tas ir incidents, kas klusi gaida savā serveru skapī. Lai saprastu, kā aizsargāt piekļuvi serverim, sāciet ar to, ka samazināt, kas var pieslēgties, kā viņi autentificējas un ko viņi var mainīt pēc tam, kad ir iekšā.

Mērķis nav padarīt administrēšanu sāpīgu. Laba piekļuves politika ļauj īstajiem cilvēkiem strādāt ātri, vienlaikus padarot nesankcionētu piekļuvi sarežģītu, pamanāmu un atkopjamu. Mazam uzņēmumam, aģentūrai vai SaaS komandai tas parasti ir vērtīgāk nekā pievienot vēl vienu drošības rīku, kura uzturēšanai nevienam nav laika.

Kā aizsargāt piekļuvi serverim pareizajā secībā

Sāciet ar ceļiem, kas ved tieši uz jūsu infrastruktūru. SSH, vadības paneļi, attālās darbvirsmas pakalpojumi, mākoņa paneļi, datubāzu konsoles un dublējumkopiju krātuve — visiem tiem nepieciešama viena un tā pati pamata pieeja: vārdiskie lietotāji, spēcīga autentifikācija, ierobežotas atļaujas un noderīgi žurnāli.

Nemēģiniet mainīt visu ražošanas vides ārkārtas situācijas laikā. Vispirms inventarizējiet pašreizējo piekļuvi. Nosakiet katru personu, automatizācijas procesu, piegādātāju un servisa kontu, kas var sasniegt serveri vai tā pārvaldības paneli. Veci aģentūras akreditācijas dati un bijušo darbinieku konti ir bieži sastopamas problēmas, jo tos ir viegli aizmirst un grūti pamanīt, līdz kaut kas noiet greizi.

Katram kontam pierakstiet tā īpašnieku, mērķi, atļauju līmeni, autentifikācijas metodi un pēdējās lietošanas reizi. Ja neviens nevar paskaidrot, kāpēc konts eksistē, deaktivizējiet to. Leģitīmu kontu vēlāk var atjaunot. Kompromitēta servera atjaunošana aizņems daudz garāku pēcpusdienu.

Izmantojiet individuālus kontus, nevis koplietotu root piekļuvi

Katram administratoram jāizmanto atsevišķs konts. Koplietoti akreditācijas dati sarežģī piekļuves atcelšanu pēc aiziešanas no darba un padara žurnālus gandrīz bezjēdzīgus. Ja pieci cilvēki izmanto vienu un to pašu root paroli, audita pieraksti var parādīt, kas notika, bet ne uzticami noteikt, kurš to izdarīja.

Linux serveros izveidojiet vārdiskus administratoru kontus un piešķiriet paaugstinātas atļaujas, izmantojot `sudo` tikai tur, kur tas nepieciešams. Izvairieties no ikdienas tiešas pieteikšanās kā `root`. Izstrādātājam, kas izvieto lietotni, var būt vajadzīga piekļuve projekta direktorijai un izvietošanas komandai, bet ne atļauja mainīt ugunsmūra noteikumus, veidot jaunus sistēmas lietotājus vai lasīt katra klienta dublējumkopiju.

Tas ir vismazāko privilēģiju princips. Tas var izklausīties formāli, taču praktiskais jautājums ir vienkāršs: kāds ir mazākais piekļuves apjoms, kas šai personai vai procesam šodien vajadzīgs, lai paveiktu savu darbu?

Atļauju dizains ir atkarīgs no jūsu darbības modeļa. Divu cilvēku jaunuzņēmums var izmantot plašākas lomas nekā 40 cilvēku aģentūra ar atsevišķām izstrādes, atbalsta un finanšu komandām. Noteikums joprojām ir spēkā: plašai piekļuvei jābūt apzinātai, pārskatītai un piešķirtai konkrēti nosauktiem cilvēkiem.

Aizstājiet paroles ar SSH atslēgām un MFA

SSH administrēšanai autentifikācijai, kas balstīta uz atslēgām, jābūt noklusējuma izvēlei. SSH atslēgas ir ievērojami grūtāk uzminēt vai atkārtoti izmantot nekā paroles, īpaši tad, ja privātā atslēga ir aizsargāta ar ieejas frāzi un glabāta uzticamā paroļu pārvaldniekā vai aparatūras atbalstītā ierīcē.

Kad piekļuve ar atslēgām ir pārbaudīta katram nepieciešamajam administratoram, atspējojiet SSH paroles autentifikāciju. Atspējojiet arī tiešu root pieteikšanos caur SSH. Saglabājiet vienu pārbaudītu break-glass procedūru ārkārtas piekļuvei, taču neatstājiet ērtības dēļ atvērtas rezerves durvis ar iespējotu paroles piekļuvi.

Daudzfaktoru autentifikācijai jāaizsargā katra tīmeklī balstītā vadības plakne, tostarp jūsu hostinga konts, DNS pakalpojumu sniedzējs, dublējumkopiju portāls, uzraudzības platforma un pirmkoda pakalpojums. Šīs sistēmas var būt tikpat jaudīgas kā SSH. Uzbrucējs, kurš kontrolē DNS, var pāradresēt datplūsmu. Uzbrucējs, kurš kontrolē dublējumkopijas, var iznīcināt jūsu atkopšanas iespējas. Tā visa ir piekļuve serverim, tikai citā veidolā.

Ja iespējams, izmantojiet autentifikatora lietotnes vai aparatūras drošības atslēgas. SMS ir labāks nekā nekāds otrais faktors, taču tas ir vairāk pakļauts SIM maiņas un tālruņa numura pārņemšanas riskiem. Glabājiet atkopšanas kodus drošā, ar piekļuves kontroli aizsargātā vietā, kas ir atsevišķi no paša servera.

Novietojiet attālo piekļuvi aiz tīkla kontrolēm

Autentifikācija atbild uz jautājumu, kam ir atļauts ieiet. Tīkla kontroles samazina to, kas vispār var pieklauvēt pie durvīm.

Ugunsmūrim jāatļauj tikai tie porti, kas nepieciešami jūsu pakalpojumiem. Tipiskam tīmekļa serverim var būt nepieciešams atvērt portus 80 un 443 publikai, savukārt SSH uz 22. porta, kad vien praktiski iespējams, būtu jāierobežo līdz zināmām biroja IP adresēm, VPN vai bastion host. SSH pārvietošana uz nestandarta portu var samazināt fona troksni žurnālos, taču tā pati par sevi nav drošības kontrole. Boti nav sentimentāli attiecībā uz portu numuriem.

Komandām ar mainīgām mājas biroju IP adresēm VPN vai zero-trust access gateway parasti ir vieglāk pārvaldāms nekā gara atļauto saraksta uzturēšana. Tas dod administratoriem kontrolētu ieejas punktu un ļauj jums centralizēti noņemt piekļuvi, kad kāds aiziet.

Neatklājiet datubāzu portus, Redis, Elasticsearch, administratora paneļus vai uzraudzības saskarnes tieši internetam, ja vien tam nav skaidra un pārskatīta iemesla. Daudzi pakalpojumi ir paredzēti lietošanai privātā tīklā un var kļūt bīstami, ja kļūdas dēļ tiek piesaistīti visām publiskajām saskarnēm.

Ja izmantojat dedicated server or VPS, pārskatiet arī pakalpojumu sniedzēja līmeņa ugunsmūra noteikumus un operētājsistēmas ugunsmūra noteikumus. Viens slānis var notvert kļūdu citā. Tā nav dublēšana tikai dublēšanas pēc. Tas ir mierīgs un saprātīgs rezerves plāns.

Saglabājiet privileģēto piekļuvi īslaicīgu

Pastāvīgu administratora piekļuvi ir viegli piešķirt un grūti pārvaldīt. Jutīgām izmaiņām izmantojiet laikā ierobežotu piekļuvi tur, kur jūsu rīki to atbalsta. Līgumdarbinieks var saņemt piekļuvi uzturēšanas logam, pabeigt darbu un pēc tam automātiski zaudēt privilēģiju.

Servisa konti ir pelnījuši tādu pašu rūpību. Lietotņu izvietošanas atslēgām, API tokeniem, datubāzu akreditācijas datiem un uzraudzības aģentiem jābūt šauram mērķim. Neizmantojiet vienu visvarenu tokenu visām testēšanas, ražošanas, dublējumkopiju un trešo pušu integrācijām. Ja tas noplūst, kaitējuma apjomam jābūt ierobežotam.

Mainiet akreditācijas datus pēc personāla izmaiņām, piegādātāju maiņas, aizdomām par noplūdi vai lielas piekļuves politikas sakopšanas. Regulāra plānota maiņa var palīdzēt, taču bieža piespiedu paroļu maiņa bieži noved pie paredzamiem paroļu paradumiem. Spēcīga MFA, unikāli noslēpumi un tūlītēja atsaukšana parasti ir noderīgāki nekā prasīt cilvēkiem mainīt paroles katru mēnesi.

Atjauniniet serveri un tā pārvaldības rīkus

Pat perfekti aizsargāta pieteikšanās ir mazāk noderīga, ja SSH dēmonam, operētājsistēmai, vadības panelim vai tīmekļa lietotnei ir zināma ievainojamība. Ieviesiet ielāpu uzlikšanas ritmu, kas aptver drošības atjauninājumus, pakotņu repozitorijus, konteineru attēlus, spraudņus un vadības paneļa programmatūru.

Ražošanas sistēmām, ja iespējams, testējiet nozīmīgus jauninājumus testēšanas vidē. Steidzamus drošības ielāpus ieviesiet ātrāk, ja ievainojamība tiek aktīvi izmantota vai ietekmē internetam pieejamu pakalpojumu. Kompromiss ir starp pieejamības risku un pakļautības risku, tāpēc pirms lielu izmaiņu veikšanas sagatavojiet atgriešanas plānu un pārbaudītu dublējumkopiju.

Noņemiet pakotnes un pakalpojumus, kurus vairs neizmantojat. Katrs darbojošs pakalpojums ir vēl viens komponents, ko ielāpot, uzraudzīt un skaidrot pulksten 2:00 naktī. Mazāk atklātu pakalpojumu parasti nozīmē mazāk nepatīkamu pārsteigumu.

Reģistrējiet piekļuvi un meklējiet nepareizo stāstu

Drošības kontrolēm ir vajadzīgi pierādījumi. Iespējojiet žurnalēšanu SSH pieteikšanām, neveiksmīgiem autentifikācijas mēģinājumiem, privilēģiju paaugstināšanai, piekļuvei vadības panelim, ugunsmūra notikumiem un svarīgām konfigurācijas izmaiņām. Ja iespējams, sūtiet žurnālus uz atsevišķu sistēmu, jo iebrucējs ar servera līmeņa piekļuvi var mēģināt mainīt lokālos ierakstus.

Brīdinājumiem jābūt noderīgiem, nevis trokšņainiem. Vispirms koncentrējieties uz notikumiem, kas pelna tūlītēju uzmanību: veiksmīga pieteikšanās no nepazīstamas vietas, atkārtotas neveiksmīgas pieteikšanās, jauns administratora lietotājs, mainīta SSH konfigurācija, atspējoti dublējumkopiju uzdevumi, neparasta izejošā datplūsma vai ugunsmūra noteikums, kas atver negaidītu portu.

Periodiski pārskatiet piekļuvi, ne tikai pēc incidenta. Daudzām mazām komandām saprātīga ir ceturkšņa pārbaude. Augsta riska vidēm var būt nepieciešamas ikmēneša pārbaudes vai nepārtraukta identitātes uzraudzība. Žurnāli tagad stāsta to pašu stāstu, un tieši to jūs arī vēlaties.

Padariet dublējumkopijas par piekļuves drošības daļu

Dublējumkopijas bieži tiek uzskatītas par atkopšanas tēmu, taču tās ir arī piekļuves kontroles tēma. Ja uzbrucējs var dzēst vai šifrēt ražošanas serveri un tā dublējumkopijas, izmantojot vienus un tos pašus akreditācijas datus, atkopšana kļūst daudz grūtāka.

Glabājiet dublējumkopijas atsevišķi no galvenā servera, izmantojiet atšķirīgus akreditācijas datus un ierobežojiet dzēšanas tiesības. Kur pieejams, uzturiet versētas vai immutable kopijas, lai kompromitēts administratora konts nevarētu klusi izdzēst pēdējo labo atjaunošanas punktu. Pārbaudiet atjaunošanu pēc grafika. Dublējumkopija, kas nekad nav atjaunota, ir cerīga datne, nevis vēl atkopšanas plāns.

Pārvaldīti dublējumkopiju un uzraudzības pakalpojumi šeit var samazināt operacionālo slogu, īpaši komandām bez īpaša infrastruktūras inženiera. Uzņēmumā kodu.cloud praktiskais mērķis ir vienkāršs: kritiskajām sistēmām jābūt uzraudzītām, dublētām un atbalstītām ar cilvēkiem, kuri var palīdzēt, kad brīdinājums ir īsts.

Sagatavojiet nelielu piekļuves incidenta plānu

Pierakstiet, kas notiek, ja atslēga tiek pazaudēta, darbinieks negaidīti aiziet vai parādās aizdomīga pieteikšanās aktivitāte. Plānam nav jābūt 40 lappušu dokumentam. Tajā jānorāda, kurš var atsaukt piekļuvi, kur tiek glabāti akreditācijas dati, kā sazināties ar jūsu hostinga pakalpojumu sniedzēju, kā izolēt serveri un kā atjaunot no zināmi labas dublējumkopijas.

Pārbaudiet plānu vienu reizi, pirms tas jums ir vajadzīgs. Apstipriniet, ka norīkots administrators var piekļūt pakalpojumu sniedzēja kontam ar MFA, izgūt atkopšanas kodus, sazināties ar atbalstu un atjaunot dublējumkopiju, nepaļaujoties uz potenciāli kompromitēto serveri. Šāda veida izmēģinājums nav glamūrīgs, bet arī klientiem izskaidrot novēršamu dīkstāvi nav glamūrīgi.

Droša piekļuve serverim tiek uzturēta ar ikdienišķiem ieradumiem: vārdiskajiem kontiem, MFA, ierobežotiem tīkla ceļiem, savlaicīgiem ielāpiem, labiem žurnāliem un atjaunojamām dublējumkopijām. Rūpīgi izveidojiet šos pamatus, regulāri tos pārskatiet, un jūsu komanda varēs strādāt ar daudz mazākām bailēm fonā.

Andres Saar klientu apkalpošanas inženieris