All roads lead to AWS #4 : Security
2B | +1% better 2day | aws.005
Өмнөх нийтлэл дээр AWS-ийн сервисүүдээс заримыг нь сонгон тайлбарласан бол өнөөдөр Аюулгүй байдалтай холбоотой сервисүүд, үндсэн ажиллагааны горим болон ганц хоёр зөвлөгөө өгөх болно.
- Үндсэн загвар (Shared responsibility model)
- Стандарт (Security compliance)
- Virtual Private Cloud (VPC) + Security Group (SG)
- Identity and Access Management (IAM)
- Хэрэгсэл болон зөвлөгөө (Tools & Tips)
өмнөх нийтлэл 👇👇👇
Shared responsibility model (OF vs IN)
Хэрэглэж байгаа сервисүүдийн байрлах газар, төхөөрөмж, сүлжээ, тог, аюул ослоос хамгаалах гэх мэт зүйлсийг “Security OF the cloud” гэж нэрлэн AWS бүхэлд нь хариуцдаг.
Харин тухайн сервисийг ашигласан аппликэйшн, архитектурын хандах эрх, өгөгдөл, шифрлэлт зэргийг хэрэглэгч өөрийн хүссэнээрээ тохируулж болох учраас “Security IN the cloud” гэж нэрлэн хэрэглэгч өөрөө хариуцдаг.
Дээрх хоёрыг хамтад нь Shared Responsibility Model буюу хариуцлагаа хуваалцсан загвар гэж нэрлээд байгаа.
Хэрэглэгч өөрийн хүссэнээр VPC, Security Group, IAM roles & permissions, Encryption тохируулж болох учраас аппликэйшнтэй холбоотой аюулгүй байдлыг ӨӨРӨӨ бүтнээр нь хариуцдаг.
Харин AWS нь өөрсдийн зүгээс хийж болох хамгаалалт, стандартын дагуух үйлчилгээ, аюулгүй байдал зэргийг хангаж whitepaper, blog, audit report гэх мэтийг хэрэглэгчдэд нээлттэйгээр түгээдэг. Зарим тохиолдолд гуравдагч этгээдийн аудитын дүгнэлтийг NDA буюу цаашид задлахгүй байх гэрээтэйгээр хуваалцдаг байна.
Security Compliance
AWS нь 24/7 харуул хамгаалалттай орчинд, олон улсын стандартын дагуу дэд бүтцээ зохион байгуулсан байдаг. Хэдийгээр хэрэглэгчдэд нээлттэй биш боловч өөрсдийн дэд бүтцэд байнга эрсдэлийн үнэлгээ хийж, гуравдагч аудитын компаниудаар хяналт шалгалтанд оруулдаг.
- Олон улсын стандартад нийцүүлдэг (Industry certificates)
- Аюулгүй байдлын талаар Whitepapers болон Best practice-ийг нийтэд ил мэдээллэдэг (publish & share)
- Нууцлалын гэрээн дор 3-дагч этгээдийн аудитын мэдээллийг хуваалцдаг (3rd party report under NDA)
AWS нь байнгын эрсдэлийн үнэлгээ хийж, өндөр харуул хамгаалалт, олон улсын стандартыг хангасан платформыг хэрэглэгчдэд санал болгодог.
Virtual Private Cloud (VPC) + Security Group (SG)
AWS-ийг үйлдлийн систем гэж ойлгох юм бол дотор нь өөр өөр (user) хэрэглэгчид зориулан хуваасан орчин нь VPC юм. VPC-г ашигласнаар privacy, security болон scalability зэрэг дээр санаа зовох хэрэггүйгээс гадна IP хаяг, Routing гэх мэт бүх тохиргоог хянах, удирдах боломжтойгоороо on premise архитектураас огтхон ч ялгарахгүй.
- VPC нь нэг region дотор байрладаг
- Subnet : Нэг хэрэглэгч доторх хавтастай (folder) зүйрлэж болно
- Route table : Орж гарч буй өгөгдлүүд хаанаас хаашаа явахыг заана
- Network Access Control List (NACL) : Subnet-ийн трафикийг хянах зорилготой (firewall шиг)
- Internet Gateway (IGW) : Интернетэд холбогдохын тулд хэрэглэнэ
Дээрх зургийг анзаарсан бол EC2 instance дээр нь Security Group гэж байгаа. SG нь тухайн instance-ийн хувьд орж, гарах трафикийг зохицуулж өгдөг.
SG-ийг үүсгэхдээ нэр, тайлбар, дүрмүүдийг (rules) үүсгэн хэрэглэх гэж байгаа VPC-тэйгээ холбоно.
Security Group-ийн дүрэм (rule) үүсгэхэд
- Type : төрөл
- Protocol : ямар протокол хэрэглэх
- Port : порт
- Source : хаанаас хандаж болох (all || my ip ||custom)
- Description : тайлбар
зэргийг тохируулах шаардлагатай бөгөөд Description-ээс бусад нь заавал бөглөх ёстой талбарууд.
Identity and Access Management (IAM)
IAM нь AWS-ийн ресорсууд руу хэн, хэрхэн хандаж болохыг тохируулах гол хэрэгсэл нь юм.
- Authentication : буюу ХЭН хэрэглэж болох вэ?
- Authorization : буюу ЮУ хийж чадах вэ?
Үндсэн 2 аргаар ресорсууд руу хандах боломжтой байдаг. Console буюу username/password ашиглах эсвэл access key id/secret access key ашиглан Programmatic аргаар.
User болон Role нь хоёулаа AWS дээр үйлдэл хийх чадвартай OPERATOR юм. Гэхдээ хэрэглээн дээр нэг User-т олон Role өгч ашиглах нь шууд policy тохируулж өгснөөс илүү хялбархан бөгөөд цэгцтэй байдаг.
User болон Role нь ХЭН БЭ гэдгийг нь (authentication) баталж байдаг бол тохируулж өгсөн policy нь юу хийж чадахыг нь (authorization) хэлж өгдөг.
Дээрх зургаас харвал
- IAM user A нь Role 1 : admin болон Role 2 : developer эрхтэйгээр
- IAM user B нь зөвхөн Role 2 : developer эрхтэйгээр тохируулсан
байгаа.
Тэгэхээр IAM user B-ийн хувьд аль хэдийн үүссэн байгаа EC2 instance-руу хандах, өөрчлөлт хийх боломжтой ч шинээр үүсгэх боломжгүй гэсэн үг.
1. Entity (User эсвэл Role) хүсэлт илгээх үед хамаарал бүхий policy-г нь шалгадаг.
2. Тухайн policy доторх permission-ий дагуу хүсэлт биелэх эсэх нь шийдэгддэг (allow || deny).
Tools & Tips :
AWS-ийн зүгээс ROOT хэрэглэгчийн access key-г устгах хэрэгтэй гэж зөвлөдөг. Бусад хэрэглэгчид шиг юу руу, яаж хандахыг нь өөрчлөх боломжгүй FULL ACCESS байдаг болохоор key-ээ алдвал тэгээд л дуусаа.
Харин шинээр үүсгэсэн хэрэглэгч дээрээ Least privilege буюу зөвхөн шаардлагатай гэсэн эрхийг нь л өгөх зарчмаар ажиллахыг санал болгодог. Шаардлагагүй бүх зүйлс хориотой гэсэн үг. ⛔⛔⛔
Түүнээс гадна :
- MFA буюу давхар хамгаалалтыг идэвхжүүлэх
- Permission тохируулахдаа Group ашиглах
- IAM-ийн нууц үгийн policy буюу ямар хэлбэртэй байх ёстойг заах
зэргийг зөвлөдөг.
Honorable mentions :
Энэ удаагийн нийтлэл AWS Security талаар өнгөцхөөн тайлбар хийлээ. Дурдаж амжаагүй хэд хэдэн services байгаа болохоор товчхон юу хийдгийг нь дараах зургаар оруулав.
AWS-ийн талаар сүүлчийн нийтлэл маань хамгийн чухал гэж хэлж болохоор төлбөрийн талаар байх болно. 💲💲💲 Хямд, хямд л гээд байдаг яг үнэндээ хэр хямд вэ гэдгийг дараагийн нийтлэл дээрээс уншаарай 😜
