
AWS Security Specialty Note

Nuttakorn Dhiraprayudti
จากบทความ

สอบ AWS Certificate
AWS Certificate มีแบ่งเป็น 4 ระดับ ได้แก่ Foundation, Associate, Professional, Specialty ดูรายละเอียดตามรูปด้านล่างได้เลย
เหมือนจะมีคนสนใจ AWS Security Certificate มากกว่าที่คิด บทความนี้ผมขอนำ note ผมมา share เผื่อจะเป็นประโยชน์กับท่านอื่นที่เตรียมตัวสอบนะครับ
ภาพรวม AWS Security
- มีการ Implement Standard ต่าง ๆ เพื่อให้ comply ตาม regulation ทั่วโลก โดย Standard ที่เป็นที่นิยมคือ ISO27001, PCI DSS ในชีวิตจริงเราควรจะรู้พวกนี้เพราะว่าถ้าเราไป implement ระบบ บน AWS ตอนทำ Standard Auditor ก็จะมาถามเราแหละว่าระบบเราปลอดภัยไหม ถ้า service ส่วนไหนที่เราใช้ outsource เราจะต้องหาเอกสารที่ยืนยันว่า outsource รายนั้นจัดการเรื่อง Security ดีพอ ซึ่งเราสามารถ Download เอกสารเหล่านี้ได้จาก Artifact
- Corporate network ของ Amazon แยกกับ AWS Cloud ชัดเจน ไม่ใช่ว่าพนักงาน Amazon จะเข้าได้เลย ซึ่งก็เป็นเรื่อง Access control ทั่วไป ที่ถูกกำหนดไว้ในทุก Standard อยู่แล้ว
- Shared Responsibility Model -> AWS ดูแล Security of the Cloud แต่ Customer ดูแล Security in the Cloud เอาแบบง่าย ๆ คือ ถ้าส่วนไหนที่เรา config เกี่ยวกับ Security เราได้นั่นคือหน้าที่ของเรา เช่น EC2 (Server) เรา control ได้ทั้งเครื่องดังนั้นการลง Patch เป็นหน้าที่ของเรา
AWS Organization
- เกี่ยวกับการจัดการ AWS account จากส่วนกลาง ซึ่งสามารถทำ Consolidated Billing, Access Control รวมถึงทำเป็น OU (Organizational Unit) เพื่อควบคุมสิทธิตามโครงสร้างองค์กรได้
- การควบคุมสิทธิที่ OU หรือ User level สามารถใช้ SCP (Service Control Policy) ได้ โดยการใช้ SCP นี่คือจะใช้ "Deny" ได้เท่านั้น (ถ้าตอนสอบเห็น SCP ระบุว่า Allow นี่ choice หลอกต้มเรา)
IAM
- เรื่องการควบคุม Root account ทั่ว ๆ ไปเลยคือ ตั้ง password ให้ยาก, เปิด MFA (2 factors authentication), ลบ Access Key ID + Secret Access Key ถ้าไม่ใช้ หรือถ้าใช้ก็ลบแหละ แล้วค่อยไปสร้าง account ใหม่ที่มีสิทธิต่ำ เพียงพอกับที่ต้องการใช้เท่านั้น, ไม่ควรใช้ Root account ควรจะสร้าง account ใหม่แล้วใช้ account นั้นเป็นหลัก และ Root ควรจะใช้เมื่อเกิดปัญหา
- กรณีที่ Admin ลาออก หรือ เพิ่งได้สิทธิ root มาต่อจากคนอื่น เช็คตาม bullet ด้านบน แต่ password ก็ reset แล้วตั้งให้ยากนะ รวมไปถึงควรดูด้วยว่ามี user อะไรบ้างที่อยู่ภายใต้ account นี้ก็ไปไล่จัดการ อันไหนไม่ใช้ก็ลบ หรือ อันไหนสิทธิสูงไปก็ควรจะตรวจสอบเพิ่มเติม
- รู้จักกับ IAM Policy ทั้งแบบ AWS Managed Policies, Customer Managed Policies, Inline Policies
- การ Set สิทธิพวก Cross-account access นอกจากจะมีเรื่องที่เกี่ยวกับ IAM แล้วยังจะมี Resource-based policy ของแต่ละ Resource แยกกันอีก ควรจะแยกให้ออกว่าส่วนของ IAM มีขอบเขตแค่ไหน ส่วนของ Resource มีขอบเขตแค่ไหน
- IAM Credential Report เราสามารถ generate report ออกมาได้ ซึ่งจะออกมาในรูปแบบของ CSV file บอกถึง status ต่าง ๆ ของ user เช่น เปลี่ยน password ไปเมื่อไร ตั้ง MFA ป่าว (ซึ่ง report นี้ไม่สามารถ customize ได้นะ ถ้าจะ gen report ก็สามารถทำผ่าน Web UI หรือ CLI ก็ได้)
Identity Federation
กรณีที่ใช้ STS (Security Token Service) ในการให้สิทธิกับ User ข้างนอกเข้าถึง AWS Resources มี 3 ท่า
- เชื่อมกับ Web Identity Provider เช่น Facebook จะใช้ STS: AssumeRoleWithWebIdentity มักใช้ในกรณีที่เป็น User ภายนอกที่ไม่สามารถ control ได้ Growth rate สูงมาก
- เชื่อมกับ SAML Compliance ID Provider จะใช้ STS:AssumeRoleWithSAML ส่วนใหญ่พูดถึง Active Directory (AD) นั่นแหละ
- ใช้กับ AWS Cross Account Access จะใช้ STS:AssumeRole ควรจะแยกแยะความหมายของ Federation, Identity Broker, Identity Provider, Identity Store ได้และรู้ว่าในแต่ละ Architecture ที่โจทย์ต้องการนั้น ส่วนไหนเป็น component ไหน เช่น AD มันก็ควรเป็น Identity Store อยู่แล้ว
ในการ Login โดยใช้ Server ภายนอกนั้นเราต้องเข้าใจก่อนว่าจะมีแบ่งเป็น 2 ส่วนคือ
- Authentication ยืนยันตัวตนตอน Login เสร็จเราจะได้ Temporary Credential ซึ่งมาในรูปแบบ Token, Access Key, Secret Access Key และ Validity Period ของ Temporary Credential นี้
- Authorization เมื่อได้ Temporary Credential มาแล้วได้สิทธิอะไรค่อยเอาไป map กับ IAM role อีกที
Cognito จะช่วยในการจัดการเกี่ยวกับการเชื่อมต่อกับ Web Identity Provider ซึ่งทำในเรื่อง Sign-up, Sign-in, เหมาะกับพวก Mobile Application, ไม่ต้องยุ่งกับ coding ในส่วนของ Temporary Credential จะมาในรูปแบบของ JWT และมี 2 Keywords ที่ถูกพูดถึงคือ User pool = จัดการเกี่ยวกับ user ไม่เกี่ยวกับสิทธิ (Authentication) และ Identity pool = จัดการสิทธิ (Authorization)
S3
- การจัดการ Permission บน S3 สามารถทำได้ 3 ท่า
IAM Policy, Bucket Policy, Bucket ACL ซึ่ง Bucket Policy ก็จะ apply ไปทั้ง Bucket แต่ Bucket ACL สามารถที่จะจัดการในระดับ Object ได้ - Policy ทั้ง 3 ประเภทนั้นสามารถนำมารวมร่างกันได้ (Combination) แล้วพอรวมร่างกันการ Evaluate Policy จะออกมาท่าไหนล่ะ? ท่องไว้ 2 concepts
- Least privilege (ให้สิทธิน้อยที่สุดที่เป็นไปได้ นั่นคือ Default Deny)
- Explicit Deny ถ้ามีบอกว่า Deny ที่ policy ไหนปุ๊ปต่อให้มีบอกว่า Allow ก็จะถูก Deny (Deny overrides Allow)
โดยสรุปคือ จะ Allow ก็ต่อเมื่อ ไม่มี Deny "และ" มีบอกว่า Allow
- โดย Default S3 bucket จะ Block Public Access ถ้าจะให้คนที่ไม่มี Account เข้าถึง Private Object จะมีท่าที่ทำได้คือ Pre-sign ซึ่งเมื่อเราจะทำเสร็จได้ Pre-sign URL ในการเข้า S3 object นั้น ๆ ซึ่งใน URL ก็จะมี Parameter ยาว ๆ ในนั้นจะประกอบไปด้วยส่วนที่สำคัญคือ Access Key ID และ Token ในการเข้าถึง Object และเราสามารถกำหนด expiration ของ Pre-sign URL ได้
- สามารถ Encrypt S3 Object ได้หลายท่า
- Client-side Encryption คือ เรา zip ใส่ password จับโยนขึ้น S3 เอง (ไม่รู้จะพูดทำไม 55)
- Server-side Encryption ด้วย S3 Managed Key (SSE-S3) อันนี้คือ S3 จัดการ Key ทุกอย่าง Data-at-rest ถูก Encrypt แต่ถ้าเรามี link เข้าถึง Object เราก็จะเปิดได้
- Server-side Encryption ด้วย KMS service (SSE-KMS) อันนี้คือใช้ KMS Service (อธิบายเพิ่มในหัวข้อด้านล่าง) ซึ่งอันนี้จะมีเรื่อง Key permission ที่เราสามารถจัดการได้เพิ่มขึ้นมา ถ้าเรามี link เข้าถึง Object เราไม่สามารถเปิดได้ถ้าเราไม่มี permission ในการใช้ key เพื่อ decrypt data
- ใน Rule สามารถใช้ wildcard ได้ → *
- Metadata ของ Object ใน S3 ไม่ได้ถูก encrypt
- ถ้าจะ Integrate กับ CloudFront (CDN ของ AWS เหมือนพวก CloudFlare, Akamai) สามารถ Set Restrict Bucket Access ได้คือ บังคับให้เข้าผ่าน Edge Location (ผ่าน CloudFront เท่านั้น) ไม่ให้ access เข้า S3 ตรง คือจะปลอดภัยมากกว่า
- Logic ในการ Set Policy เช่น โจทย์ถามว่าจะบังคับให้เข้า S3 แบบ HTTPS เท่านั้นต้องทำอย่างไร ซึ่งในเคสนี้จะมี 2 ส่วนที่ต้อง concern คือ
1.จะ allow หรือ deny ให้ใช้ resource เช่น จะ readObject
2.condition ของ Secure Transport จะเป็น True หรือ False
ถ้าแบบไม่คิดมากเลยก็จะต้องบอกว่า Allow และให้ Condition SecureTransport เป็น True -> ภาษาคนแปลว่าไร? ให้เข้าแบบ HTTPS ได้ แต่มันไม่ได้ห้ามไม่ให้เข้าแบบ HTTP นี่นา ถ้าอยากทำให้มันห้ามไม่ให้เข้า HTTP แต่เข้าได้เฉพาะ HTTPS ควรจะต้อง Deny และให้ Condition SecureTransport เป็น False ขยายความเพิ่มด้านล่าง ถ้าเป็นสมัยเด็กน้อยเรียน Truth Table เราแบ่งเป็น 4 cases- Allow และ SecureTransport เป็น True ส่งผลให้เราเข้าได้ทั้งแบบ HTTP, HTTPS
- Allow และ SecureTransport เป็น False ส่งผลให้เข้าได้แต่แบบ HTTP
- Deny และ SecureTransport เป็น True ส่งผลให้เราเข้าได้แต่แบบ HTTP
- Deny และ SecureTransport เป็น False ส่งผลให้เราเข้าได้แต่แบบ HTTPS
ซึ่งตอนสอบก็เจอโจทย์อะไรแนว ๆ นี้บ้างแต่จะซับซ้อนขึ้นอีก Step เช่น พอ A และ B ส่งผลให้เกิด C แล้วต้องเอา C ไปวิเคราะห์ต่อว่าใช้สิ่งที่โจทย์ต้องการไหม
- S3 มีหลาย Tier แต่ละ Tier ราคาไม่เท่ากัน เวลาในการ Retrieve Data ไม่เท่ากัน และ จำนวน Copy ในการเก็บไม่เท่ากัน ซึ่งเวลาที่จะ Archive Data นั้นจะใช้ S3 Glacier เป็นหลัก
- S3 Glacier จะเก็บ data ในรูปแบบของ "Archive" ซึ่งเก็บอยู่ใน format .tar, .zip
- Vault หมายถึง Archive หลาย ๆ อัน
- Glacier Vault Lock Policy สามารถ config ให้เป็น Write Once Read Many (WORM) ซึ่งมักใช้เป็น Data retention policy เมื่อกำหนด Policy แล้วเราจะมีเวลา 24 ชั่วโมงในการตรวจสอบ Policy นี้ ถ้าต้องการแก้ไขสามารถทำได้ภายใน 24 ชั่วโมง (คือ Abort แล้ว set ใหม่) ถ้าเกิน 24 ชั่วโมงเราจะไม่สามารถทำอะไรกับ Policy ได้แล้ว
CloudTrail และ CloudWatch
- อันนี้เป็นอะไรที่ผมสับสนมาก ๆ ในตอนแรกและคิดว่าหลายคนคงสับสนเนื่องจากทั้งคู่ชื่อ Service คล้ายกัน และยังทำเรื่องเกี่ยวกับ Log ทั้งคู่
- CloudTrail เป็นส่วนของ Log ที่เกี่ยวกับการเรียก AWS API ในการ Control Resource ของ AWS โดยข้อมูลที่ Log คือ Identity of API caller, Source IP of caller, Time, Metadata, Request Parameter, Response return by service
- CloudTrail ส่งข้อมูลเข้า S3, เราสามารถ manage retention policy ผ่านทาง S3 bucket, ส่งทุก ๆ 5 นาที (near real-time ไม่ใช่ real-time), Integrate กับ SNS (Notification Service) เพื่อใช้ alert ง่าย ๆ ได้
- หลักการของการเก็บ Log ทั่วไปคือ Log ต้องถูกส่งมาและต้องแน่ใจว่าไม่ถูก modify หรือ ถูกลบได้, ถ้าถูกลบหรือถูกแก้ไขเราต้องรู้ได้ ซึ่งการเก็บใน course ก็จะเน้นย้ำเสมอว่าให้เปิด S3 bucket ให้ทุก account ที่เราต้องการ monitor ส่ง CloudTrail log เข้ามา (Aggregate Across Region, Across Accounts) โดยคนที่ส่ง Log ได้ก็มีสิทธิแค่เขียน Log จะแก้ไขหรือลบอะไรไม่ได้ ในส่วนของ Auditor ที่จะดู Log ก็ต้องมีสิทธิแค่ Read เท่านั้น
- การป้องกันสำหรับ CloudTrail
- เราสามารถจัดการเรื่อง Confidentiality ได้โดยการ Encrypt Data-at-Rest ซึ่งใช้ SSE-S3 (เดี๋ยวขยายความต่อในส่วนของ KMS)
- กำหนด Access control ได้โดยใช้ IAM policy และ S3 Buket policy (เพราะ CloudTrail เก็บข้อมูลใน S3)
- ในส่วนของ Integrity สามารถใช้ Log file validation ได้ ซึ่งจะมีการเก็บ Digest file โดยใน Digest file จะเก็บ hash ของแต่ละ file ถ้ามีการแก้ไข Log ค่า Hash ก็เปลี่ยน หรือ ถ้ามีลบ File ทิ้งไปก็ยังมีร่องรอยใน Digest file อยู่ โดยในส่วนของ Integrity Validation มี 2 แบบ SHA256 Hashing, SHA256 with RSA for Digital Signature (MAC) ซึ่งในมุมของเรื่อง Security MAC จะ Strong กว่า Hash
- นอกจากนี้ก็สามารถต่อกับ SNS ถ้ามีไรเกิดขึ้นได้จะได้มีการแจ้งเตือน
- CloudWatch เป็นส่วนของ Log ที่เกี่ยวข้องกับ Resource นั้น ๆ เช่น เรื่องของ Performance เราก็สามารถใช้ CloudWatch ได้ การใช้ CloudWatch ต้องมีการติดตั้ง Agent และสามารถใช้ Rule ในการ Matching event เพื่อไป Trigger Service อื่น ๆ ได้ ตัวอย่างเช่น รับ Log จาก CloudTrail เช่นมีการสร้าง EC2 instance โดยไม่ได้รับอนุญาต ซึ่งเมื่อ Rule ที่ตั้งไว้ Detect ได้ก็สามารถไปสั่ง Lambda ให้ไป Terminate EC2 instance ได้
AWS Config
- เป็น Service ที่ช่วยในการตรวจค่า Config เทียบกับ Based line รวมถึงสามารถแก้ไขค่า Config หรือ แจ้ง notification ได้
- มีลักษณะเป็น Region based, เก็บข้อมูลใน S3 สามารถดูข้อมูลในลักษณะ Timeline ได้ ทำให้ทราบว่าค่า Config ถูกเปลี่ยนแปลงไปเมื่อไร
- มี Rule ที่ Pre-defined โดย AWS และสามารถ Customize ได้
- Conformance pack หมายถึง Set ของ AWS Config rules รวมถึง Remediation Action มาในรูปของ YAML format
CloudHSM และ KMS
- ทั้งคู่เป็น HSM (Hardware Security Module) ซึ่งปกติ HSM จะเป็นอุปกรณ์ที่จัดการเกี่ยวกับ Key ทั้งหมด (Key Management) ถ้าตาม Lifecycle ก็จะมีเรื่องพวก Generation -> Store -> Transport -> Use -> Destroy ทำอย่างไรให้พวกนี้ปลอดภัยก็จะเป็นเรื่องของ Cryptography ทั้งนั้น
- CloudHSM เป็น Dedicated เราใช้คนเดียว แต่ KMS เป็น Multi-Tenant คือใช้ร่วมกันหลายคน
- CloudHSM ได้มาตรฐาน FIPS140–2 และ EAL4 แต่ KMS ได้ FIPS140–2 อย่างเดียว
- ทั้งคู่มีคุณสมบัติเป็น Tamper Resistance คือถ้ามีใครทำไรไม่ดีกับมัน มันจะทำลายตัวเองได้ (ทำลายข้อมูลนะ) คำว่าทำไม่ดี เช่น พยายามแงะเครื่อง Physical, Login ผิด ๆ หลายครั้ง (มีอีกคำที่เจอบ่อยในเรื่องของ Security คือ Tamper Evident คือ ถ้ามีใครมาทำอะไรไม่ดี จะมีการทิ้งร่องรอยหลักฐานให้รู้ได้ว่าโดนทำไรไม่ดี)
- KMS มี 3 ประเภท
- AWS Managed Key — AWS จัดการให้, Key จะถูก rotate เองทุก 3 ปี, พอเปลี่ยน Key แล้ว Key เก่าไม่ได้ถูกลบ แต่จะใช้ Key ใหม่ในการ Encrypt แทน ส่วน Key เก่าก็เก็บไว้ Decrypt ซึ่ง Key เราไม่สามารถ Delete Key ได้นะ
- Customer Managed Key (CMK) — เรามีสิทธิจัดการ Key บ้างแต่ AWS เป็นคน Generate Key นะ, สามารถตั้ง Auto Key Rotation ได้ แต่ไม่ได้เปิดโดย Default ซึ่งเมื่อเปิดจะเป็นการ Rotate ทุก 1 ปี แต่เราก็ยังสามารถทำ Manual ได้อยู่, เราสามารถ Delete Key ได้ แต่ถ้า Delete ก็ต้องระวัง ถ้าเราไม่มี Key เราก็ไม่สามารถเปิดไฟล์นั้นได้อีกเลย โดยการ Delete Key จะมี Waiting Period 7–30 วัน เผื่อมีพนักงานลาออกแบบเคือง ๆ สั่งลบ Key คนที่เป็น Admin ก็ยังสามารถที่จะ Cancel Key Deletion ได้อยู่
- Customer Managed Key with Import Key Material — เราจัดการ Key รวมถึงเป็นคน Generate Key เอง ซึ่งพอเลือกจะใช้แบบนี้ ระบบจะมี 2 Files ให้เรา คือ Wrapping Key และ Import Token ซึ่ง Wrapping Key ก็จะเป็น Key ที่ใช้มา Encrypt Key ของเราในจังหวะที่มีการย้าย Key จากเครื่องไปที่ AWS (Key Transportation) ส่วน Token ก็ใช้แล้วทิ้ง เหมือนเป็นค่าที่ยืนยันว่าเรามีสิทธิในการ import key นี้นะ, สำหรับแบบนี้ไม่ support key rotation ถ้าอยาก rotate เราต้องทำเอง, ถ้าจะ delete key ไม่ต้องรอ 7 วัน
- KMS สามารถใช้สร้าง Key ได้แต่ไม่สามารถ Export key ออกมาได้
- เรื่องระยะเวลาในการทำ Key Rotation นั้นเรามักจะถูกกำหนดโดย Standard หรือ Regulation ที่เราต้อง comply ตาม
- KMS สามารถ set Key policy ได้ ซึ่งถ้าเป็น Admin ก็จะสามารถ Manage ว่าใครใช้ Key ได้ และ สามารถกำหนดสิทธิสำหรับใช้ Key ในการ Encrypt/Decrypt ได้ ซึ่งการกำหนดสิทธิการใช้ Key หลัก ๆ จะอยู่ที่ IAM Role กับ Key Policy
- kms:viaService สามารถใช้ระบุใน policy ได้ว่าจะให้ Service ไหนเรียก KMS ได้
- เรื่องประเภทของ Algorithm หรือจะเรียกง่าย ๆ ว่าประเภทของ Key กับรูปแบบที่จะนำไปใช้งาน Sysmetric Key -> ใช้ Encrypt EBS ได้แต่ไม่ใช่ Login เข้า EC2, Asymetric Key -> ใช้ Login เข้า EC2 แต่ไม่สามารถไปใช้ Encrypt Data Volume แบบ EBS ได้
Infrastructure Security
- WAF คือ Web application firewall เน้นใช้ป้องกันการโจมตีที่ HTTP, HTTPS protocol (Layer 7)
- Shield ไว้ป้องกัน DDOS attack เน้นที่ Layer 3, 4 ให้บริการ 2 Level คือ แบบ ฟรี และ เสียเงิน ถ้า version เสียเงินจะมี support เพิ่ม เช่น DRT (DDoS Response Team) มาช่วยดู 24x7
- CloudFront ระบบ CDN ของ AWS สามารถ Block user ที่เป็น Region Based ได้
- VPC Flowlog คือ Traffic monitoring ทำได้หลาย Level คือระดับ VPC, Subnet, ENI แต่มี Log บางส่วนที่จะไม่ถูก Collect นะ เช่น DHCP log, AWS Windows License Activation log เป็นต้น
- Network ACL (NACL) เป็นเหมือน packet filtering ทำงานแบบ Stateless มี Rule ทั้ง inbound และ outbound ถ้าจะ allow ให้ traffic เข้า-ออก ก็ต้อง set rule ทั้ง inbound และ outbound
- Security Group เป็นเหมือน Traditional Firewall ทำงานแบบ Stateful มี Rule ทั้ง inbound และ outbound ถ้าจะ allow ให้ traffic เข้า-ออก ก็ต้อง set rule ขาแรกที่ packet จะไป (Set แค่ฝั่งเดียว) เช่น จะให้คนจาก Internet เข้ามาใช้งาน Web เรา ก็ set แค่ส่วนของ Inbound rule
- ถ้าจะ Block specific IP ให้ใช้ NACL ไม่ใช่ Security Group, ถ้าจะ Block เป็น Geolocation ให้ใช้ CloudFront
- Bastion host หรือ Jump box คือเครื่องที่ไว้เป็นเครื่องกลางในการเข้าถึง Server ใน Private subnet
- SSL/TLS Termination ตอนใช้ร่วมกับ Load Balancer (ELB) ถ้าให้ Terminate ที่ปลายทาง สมมติว่าเป็น EC2 ก็จะปลอดภัยเพราะว่าเป็น End-to-End Encryption แต่ว่าถ้าจะให้ Load Balancer เป็นตัว Terminate ให้ก็จะไม่เป็น End-to-End Encryption แต่จะมีข้อดีคือไม่ต้องไปเปลือง Performance EC2 ในการจัดการ Cryptographic operation (ถ้าโจทย์บอกว่าต้องการ E2E encryption ก็เลือกอันที่ Terminate ปลายทางเลย แต่โจทย์ไม่ถามง่าย ๆ งั้นหรอก ตอนสอบเจอข้อให้มาเป็น Scenario แล้วถามอะไรซักอย่างเกี่ยวกับ Key ประมาณว่าใน Scenario นี้ควร Terminate ที่จุดไหนถึงปกป้อง Key ของได้ดี)
- ถ้าจะทำ Custom Digital Certificate? -> ไปยุ่งกับ AWS Certificate Manager (ACM) เป็นหลัก ถ้าจะ Custom Digital Certificate บน CloudFront ต้องไปทำที่ US-East-1 region โดย Default CloudFront จะใช้ Cert Domain ที่เป็น *.cloudfront.net
System Manager
- Session Manage ทำหน้าที่แบบ Session Management Solution เลย สามารถเก็บ Log หน้าจอว่าทำอะไรไปบ้างที่เครื่องนั้น ๆ ในระดับ command เลย ทำงานผ่าน Browser ไม่ต้องเปิด Management port ให้เข้าจาก Internet ก็ใช้งานได้
- Parameter Store ไว้เก็บ sensitive data มี parameter type หลายแบบเช่น String, String list, Secure String (ถูก encrypt ด้วย KMS) นึกถึงเวลา provisioning EC2 แล้วต้องเอา config ไปใส่ใน Bootstrap ซึ่งไม่ค่อยปลอดภัย สามารถเอามาเก็บใน Parameter Store ได้
- Secret Manager ใช้เก็บ credential ของ Database โดยสามารถทำ Auto-rotation ได้ เมื่อสั่งให้ทำ Rotation จะมีการทดลองเปลี่ยน credential ทันที นั่นอาจจะทำให้ระบบใช้งานไม่ได้ ซึ่งก็หมายความว่ามีการ fix credential อยู่ใน Application เราอยู่ดังนั้นเราควรไปแก้ไขก่อนที่จะเริ่มให้ทำ Auto-rotation
- Run command สามารถสั่งคำสั่งบน EC2 หลาย ๆ เครื่องรวดเดียวได้ เช่นอยากจะ update patch ทั้งหมด (เหมือนเป็น botnet เลยนะ 55)
Security
- Inspector คือ VA Scan (Scan หาช่องโหว่ สนใจติดต่อ Incognito Lab ได้ครับ ถือโอกาสขายของ 555) Template ในการ Scan จะเน้นที่ CVE ทั่ว ๆ ไป และ ตาม CIS โดยการ Scan มี 2 แบบ
- Network assessment ไม่ต้องลง agent
- Host assessment ต้องลง agent
- Pentest โดย Default จะมี Pre-approved service ได้แก่ EC2, RDS, CloudFront, Aurora, API Gateway, Lambda & Lambda Edge, Lightsail, Elastic Beanstalk นอกเหนือจากนี้ส่งเมลไปขอ approve ทั้งนี้ห้ามทำ DDoS (ใครมองหาบริษัททำ Pentest ติดต่อ Incognito Lab ได้เช่นกันครับ)
- GuardDuty เป็น Threat detection service ทำหน้าที่ monitoring และ แจ้ง alert (ผมนึกถึงศูนย์ SOC)
- ถ้าเครื่องถูก Hack ทำอย่างไร? Stop instance -> Take snapshot EBS -> Deploy in isolated network -> Use forensics machine to connect and analyse
- ถ้าเผลอ upload token/key ไป public repositories ทำอย่างไร? ยกเลิกสิทธิในการใช้ key นั้นและสร้าง key ใหม่มาใช้แทน
อื่น ๆ
- Trusted Advisor ซึ่ง Service นี้ช่วย 4 ส่วนคือ Reduce cost, Increase performance, Improve security และ Advice fault tolerance โดย Trusted Advisor มี 2 level คือ Free กับจ่ายเงิน ถ้าฟรีจะได้แค่ Performance กับ Security แต่ถ้าเราจ่ายตังเราจะสามารถได้รับคำแนะนำเพื่อให้ประหยัดตังได้ด้วย (อยากประหยัดต้องจ่ายก่อน 55)
- ควรทำความเข้าเรื่อง Log มาก ๆ เลย ว่ามีอะไรบ้างแล้วมันเชื่อมกันอย่างไร เช่น CloudTrail, CloudWatch, AWS Config, VPC Flowlog
- รู้จัก Service อื่น ๆ บ้าง เช่น ECS, EKS, SES
- Athena ไว้สำหรับใช้ SQL query data ใน S3
- Macie เป็น Machine Learning ไว้ใช้ในการหา PII (Personal Identifiable Information) สามารถใช้กับ S3, CloudTrail ได้
- อ่านพวก Whitepaper กับ FAQs ของ Service ที่พูดถึงเยอะ ๆ นะครับ https://aws.amazon.com/whitepapers/
ถ้าอ่านจบถึงตรงนี้คงแปลว่าตั้งใจจะสอบแหละ ขอให้โชคดีในการสอบนะครับ
Up Next

ARTICLES
Mar
03
2021
Secure Code Warrior
วันก่อนเจอ Tweet ที่คุณ Troy Hunt เจ้าของ haveibeenpwned ได้ share มาเกี่ยวกับ paper อันนึงที่น่าสนใจมาก
READ MORE

ARTICLES
Mar
03
2021
หลักแห่งการออกแบบระบบอย่างมั่นคงปลอดภัย (Secure Design Principles)
ธนาคารรายใหญ่มีกฎระเบียบข้อบังคับในการคัดเลือกผู้ให้บริการหลายข้อ ทั้งในแง่ขีดความสามารถและความมั่นคงทางการเงินของบริษัท แต่เมื่อมีการจัดซื้อจัดจ้างผลิตภัณฑ์หรือบริการไปแล้ว
READ MORE

ARTICLES
Mar
02
2021
ทำความรู้จักกับ Application Sandboxing บน Mobile Platform
เมื่อพูดถึงกลไกการรักษาความปลอดภัยของ Smartphone ในปัจจุบัน ไม่ว่าจะ iOS, Android หรือ Windows Phone ล้วนมีกลไกการรักษาความปลอดภัยพื้นฐานมาอยู่แล้วซึ่งช่วยให้ผู้ใช้งานทั่วไปสามารถใช้งาน Smartphone ได้อย่างมั่นคงปลอดภัยในระดับหนึ่ง
READ MORE