Google Cloud платформын аюулгүй байдал: Систем шилжүүлэх үеийн эрсдэл ба удирдлага

Томоохон хэмжээний системийг үүлэн технологи руу, тэр дундаа Google Cloud Platform (GCP) руу шилжүүлэх нь зөвхөн дэд бүтцийн өөрчлөлт биш юм. Энэ нь аюулгүй байдлын архитектур, хандалтын удирдлага, үйл ажиллагааны процессыг сууриар нь шинэчлэх томоохон шилжилт болдог.

Технологийн хариуцсан захирлууд (CTO), үүсгэн байгуулагчид болон ахлах инженерүүдийн хувьд "GCP аюулгүй юу?" гэдэг асуулт нь ихэвчлэн "Бидний хяналтаас гадуурх эрсдэл хэр их вэ? Системээ шилжүүлэхэд бизнес зогсох, өгөгдөл алдагдах аюул хэр өндөр вэ?" гэсэн утгыг агуулдаг.

Энэхүү нийтлэлээр GCP-ийн аюулгүй байдлын суурь механик, томоохон систем шилжүүлэхэд гардаг бодит эрсдэлүүд болон уламжлалт дата төвөөс үүлэн орчинд шилжихэд гаргах ёстой архитектурын болон үйл ажиллагааны шийдвэрүүдийг задлан шинжлэх болно. Уншсаны дараа та үүлэн орчны хуваалцсан хариуцлагын загварыг гүнзгий ойлгож, шилжилтийн үеийн эрсдэлээ хэрхэн зөв үнэлэх болон технологийн багаа ямар чиглэлээр чиглүүлэх талаар тодорхой ойлголттой болох юм.

GCP-ийн аюулгүй байдлын суурь механик

Google нь өөрийн хайлтын систем, YouTube, Workspace зэрэг тэрбум гаруй хэрэглэгчтэй бүтээгдэхүүнүүдээ ажиллуулдаг яг тэр дэд бүтэц дээрээ GCP-ийг байгуулсан. Тиймээс дэд бүтцийн физик болон доод түвшний аюулгүй байдал нь салбартаа өндөр түвшинд хангагдсан байдаг. Энэ нь хэд хэдэн давхаргаас бүрдэнэ:

1. Физик болон техник хангамжийн түвшин: Google нь дата төвийнхөө сервер бүрд өөрсдийн бүтээсэн зориулалтын чип суурилуулж, серверийн эхлэх үеийн (boot) кодод хөндлөнгөөс халдсан эсэхийг микро түвшинд баталгаажуулдаг. Физик халдлагаас сэргийлэх энэхүү хяналт нь уламжлалт дата төвүүдтэй харьцуулахад хамаагүй илүү зохион байгуулалттай.
2. Өгөгдлийн шифрлэлт (Encryption): GCP нь амарч буй (at rest) болон дамжигдаж буй (in transit) бүх өгөгдлийг анхдагч тохиргоогоор (default) автоматаар шифрлэдэг. Хэрэв таны бизнесийн онцлог нь compliance буюу зохицуулалтын шаардлагатай бол Customer-Managed Encryption Keys (CMEK) ашиглан шифрлэлтийн түлхүүрээ өөрөө бүрэн удирдах, эсвэл бүр түлхүүрийг өөрийн дата төвдөө хадгалах External Key Management (EKM) сонголтууд бий.
3. Сүлжээний аюулгүй байдал ба тэг-итгэлцэл (Zero Trust): Уламжлалт сүлжээний хамгаалалт буюу "гаднаас орж ирэх хаалгыг түгжих" (perimeter security) ойлголтоос татгалзаж, BeyondCorp архитектур-т суурилсан "хандалт хийж буй хэрэглэгч, төхөөрөмж болон сүлжээнд хэзээ ч үл итгэх" зарчмаар ажилладаг. Хандалт бүрийг контекстээс (хэн, хаанаас, ямар төхөөрөмжөөр) хамаарч үнэлдэг.

Гэхдээ үүлэн орчинд шилжиж буй удирдлагуудын хамгийн сайн ойлгох ёстой концепц бол Хуваалцсан хариуцлагын загвар (Shared Responsibility Model) юм. Google нь "үүлний" (security of the cloud) аюулгүй байдлыг буюу дата төв, сүлжээний кабель, физик сервер, гипервизорыг хариуцна. Харин та "үүлэн доторх" (security in the cloud) аюулгүй байдлыг буюу хэн ямар өгөгдөл рүү хандах эрхтэй вэ (IAM), галт ханын дүрмүүд, хэрэглээний програмын эмзэг байдал, тохиргооны алдааг бүрэн хариуцна.

Архитектур ба үйлдлийн загварууд

Том хэмжээний системийг шилжүүлэхэд хамгийн эхний бөгөөд хамгийн чухал алхам бол Landing Zone буюу үүлэн орчны суурь бүтцийг зөв зурах явдал юм. Хэрхэн зурснаас шалтгаалж эрсдэлийн хэмжээ шууд тодорхойлогддог.

• Нөөцийн шатлал (Resource Hierarchy): GCP нь `Organization -> Folder -> Project -> Resources` гэсэн бүтэцтэй. Том системүүдийг нэг том төсөл (Project) дотор овоолох нь хамгийн аюултай алдаануудын нэг юм. Үүний оронд үйлчилгээ, баг, эсвэл орчноор (Development, Staging, Production) нь тусдаа төслүүдэд хуваах нь нэг систем эвдэрсэн ч бусад руу халдварлахгүй байх буюу халдлагын хүрээг (blast radius) хязгаарлах хамгийн сайн арга юм.
• Хандалтын удирдлага (Identity and Access Management - IAM): Үүлэн орчинд IP хаяг гэхээсээ илүү Identity буюу тухайн систем, хэрэглэгчийн таниулбар нь хамгаалалтын шинэ хил хязгаар болдог. Хэрэглэгчдэд бус, харин үйлчилгээнүүдэд (Service Accounts) эрх олгоход илүү анхаарал хандуулах шаардлагатай. Зөвхөн тухайн үйлдэлд шаардлагатай хамгийн бага эрхийг (Principle of Least Privilege) олгох нь системийн аюулгүй байдлын амин сүнс.
• VPC Service Controls (VPC SC): Энэ нь таны өгөгдлийг гадагш санамсаргүй болон санаатайгаар алдагдахаас (data exfiltration) сэргийлэх маш хүчирхэг хэрэгсэл юм. Үүлэн орчин дахь нөөцүүдээ логик хил хязгаараар хүрээлж, зөвшөөрөгдөөгүй сүлжээнээс буюу интернэтээс шууд API дуудаж дата хуулахыг хатуу хориглодог.

Том систем шилжүүлэх үеийн бодит эрсдэлүүд

Таны дата төвд олон жил ажилласан, өөр хоорондоо нарийн холбогдсон 100+ микросервис эсвэл хэд хэдэн том monolithic системүүдийг шилжүүлж байна гэж төсөөлье. Эрсдэл нь хэзээ ч GCP-ийн үндсэн технологи доголдоход байдаггүй, харин шилжүүлэлтийн явцад үүсэх хүний алдаа, архитектурын болон процессын зөрүүгээс үүсдэг.

1. Lift-and-Shift-ийн уршиг: Уламжлалт орчинд дотоод сүлжээндээ (internal network) бүх системүүд хоорондоо чөлөөтэй харьцдаг байж болно. Үүнийг ямар ч өөрчөлтгүйгээр шууд хуулж GCP дээр тавихад (Lift-and-Shift) нэг л аппликейшн халдлагад өртөхөд бүх дотоод систем рүү нэвтрэх үүд хаалга нээгддэг. Шилжүүлэхдээ микросегментаци хийж, сүлжээний дүрмүүдийг илүү нарийвчлах шаардлагатай.
2. Хандалтын эрх хяналтаас гарах (IAM Sprawl): Шилжилтийн эхний үед ажлыг хурдан явуулахын тулд инженерүүд "Editor" эсвэл "Owner" зэрэг маш өргөн эрхтэй үндсэн дүрүүдийг (Basic roles) хэрэглэгч болон аппликейшнд өгөх хандлагатай байдаг. Эдгээр дүрүүд нь үүлэн орчинд хэтэрхий их эрх олгодог бөгөөд хөгжүүлэгчийн нэг л алдагдсан түлхүүр нийт системийг хяналтаас гаргах эрсдэлтэй.
3. Тохиргооны алдаа (Misconfiguration): Cloud орчин дахь хамгийн түгээмэл бөгөөд хор хөнөөлтэй эрсдэл. Өгөгдлийн санг санамсаргүйгээр нийтэд ил болгох (Public IP өгөх), Cloud Storage bucket-ийн эрхийг буруу тохируулж "allUsers" унших боломжтой болгох зэрэг нь томоохон компаниуд хүртэл датагаа алддаг хамгийн том сул талууд юм.

Сул тал, эрсдэл ба хязгаарлалтууд

Аюулгүй байдал нь хэзээ ч үнэгүй олддоггүй бөгөөд үргэлж хөгжүүлэлтийн хурд болон үйл ажиллагааны уян хатан байдалтай зөрчилдөж байдаг. Удирдлагын түвшинд шийдвэрлэх ёстой хэд хэдэн асуудлууд бий:

• Хамгаалалт vs. Хөгжүүлэлтийн хурд: VPC Service Controls болон маш хатуу IAM бодлогууд хэрэгжүүлсэн үед CI/CD (тасралтгүй хөгжүүлэлт) дамжуурга ажиллахгүй болох, хөгжүүлэгчид шинэ үйлчилгээ гаргахдаа заавал сүлжээний админаас эрх хүлээх зэрэг хязгаарлалтууд үүсдэг. Энэ нь хөгжүүлэлтийн хурдыг сааруулж магадгүй. Аюулгүй байдлыг хангахын тулд инженерийн багийн хурд, бүтээмжийг хаана хүртэл золиослох эсэхээ баланслах хэрэгтэй.
• Cloud-Native аюулгүй байдлын хэрэгслийн өртөг: Google-ийн Security Command Center (SCC) гэх мэт хэрэгслүүд нь орчин дахь тохиргооны алдаа болон эмзэг байдлыг автоматаар илрүүлж хянадаг боловч дээд зэрэглэлийн (Premium/Enterprise) хувилбарууд нь нэмэлт өндөр өртөгтэй байдаг. Архитектурын дизайн гаргахдаа эдгээр зардлыг зөв тооцоолохгүй бол үүлэн орчны зардал хүлээлтээс давах аюултай.
• Vendor Lock-in ба үүлний олон талт байдал: Хэрэв танай байгууллага зөвхөн GCP биш, AWS эсвэл Azure-тэй хослуулан олон үүлэн (Multi-cloud) орчин ашигладаг бол GCP-ийн нарийн IAM дүрмүүд болон лог хяналтын системүүдийг бусад орчинтой уялдуулах нь нэлээд түвэгтэй, хүн хүч шаардсан процессыг бий болгодог.

Шийдвэр гаргах шалгуур ба харьцуулалт

Системээ бүрэн шилжүүлэх шийдвэр гаргахын өмнө танай баг дараах концепцийн өөрчлөлтүүдэд бэлэн эсэхээ дотооддоо баталгаажуулах шаардлагатай.

• Сүлжээний хил хязгаар (Firewall, DMZ) - Identity буюу Хэн болохыг таних (IAM)
• Project, VPC болон Subnet | Орчингуудыг (Dev/Prod) Project-ийн түвшинд зааглах
• Байгууллага өөрийн түлхүүрээ (CMEK) удирдах эсэхийг шийдэх
• Үйлчилгээ төвтэй, богино хугацааны токен - Кодод бичигдсэн (Hardcoded) нууц үгнүүдээс бүрэн салах

Нийтлэг алдаанууд ба түүнээс зайлсхийх нь

Том төслүүд болон туршлагагүй багуудын GCP рүү шилжихдээ гаргадаг нийтлэг алдаануудыг инженерүүдийнхээ ажилд тогтмол хянах шаардлагатай.

• Ерөнхий дүрүүд (Basic Roles) ашиглах: Төслийн орчинд хэзээ ч `roles/owner`, `roles/editor`, `roles/viewer` зэрэг хуучин бөгөөд маш өргөн эрхтэй дүрүүдийг бүү ашигла. Үүний оронд зөвхөн тухайн үйлчилгээнд зориулсан `roles/storage.objectAdmin` эсвэл бүр өөрсдийн үүсгэсэн (Custom) дүрүүдийг ашиглах нь зүйтэй.
• Service Account Key татаж авах: Service Account-ийн түлхүүрийг (JSON файл хэлбэрээр) татаж аваад хөгжүүлэгчийн компьютер, эсвэл код хадгалах санд (GitHub/GitLab) хадгалах нь өгөгдлөө алдах хамгийн том эрсдэл юм. Үүний оронд Workload Identity Federation ашиглаж, түлхүүргүйгээр аюулгүй хандах замыг сонгох хэрэгтэй.
• Ганц том VPC буюу сүлжээ үүсгэх: Бүх төслүүд болон орчингуудаа нэг том VPC сүлжээнд холбох нь халдлагын эрсдэлийг нэмэгдүүлнэ. Shared VPC архитектурыг ашиглан сүлжээний администратор болон хөгжүүлэлтийн багийн эрх мэдлийг тусгаарлах замаар дотоод сүлжээг сегментчлэх хэрэгтэй.

Гол дүгнэлтүүд

GCP руу томоохон систем шилжүүлэх нь технологийн хувьд өндөр хамгаалалттай дэд бүтэц рүү очиж байгаа хэдий ч, танай багийн хэрэгжилтийн чанараас (implementation) шалтгаалж эрсдэлийн хэмжээ тодорхойлогдоно. Шийдвэр гаргах түвшинд дараах зүйлсийг анхаарах нь зүйтэй:

• Хуваалцсан хариуцлагыг практикт нэвтрүүлэх: GCP-ийн физик дата төв рүү хэн ч дайрч орж чадахгүй байж болох ч, танай багийн тохиргооны алдаанаас (misconfiguration) болж дата алдагдах магадлалтай. Аюулгүй байдлын бодлого, аудитыг "үүлэн доторх" эрсдэлдээ бүрэн чиглүүл.
• Identity бол шинэ Firewall: Аюулгүй байдлын шинэ хил хязгаар бол зөвхөн сүлжээний галт хана биш, харин IAM юм. Бүх систем хоорондын болон хэрэглэгчийн хандалтыг хамгийн бага эрхийн зарчмаар хязгаарлаж, тасралтгүй хяналт тавих.
• Орчны тусгаарлалтыг эхнээс нь зөв хийх: Систем шилжүүлж эхлэхээсээ өмнө Landing Zone буюу Resource Hierarchy-г зөв зураглаж, халдлагын хүрээг (blast radius) багасгах бүтцийг гаргах нь ирээдүйд гарах олон сая долларын эрсдэлээс хамгаална.
• Автоматжуулалт ба тасралтгүй сайжруулалт: Олон зуун үйлчилгээний тохиргооны алдааг хүн гараар хянах боломжгүй болдог. Аюулгүй байдлын автомат хяналт (Security Posture Management) болон илрүүлэлтийг анхнаас нь CI/CD процесс болон байгууллагын соёлын нэг хэсэг болгож төлөвлөх нь практик хэрэгжилтэд хамгийн чухал юм.