Tại sao mình lại nói nếu public S3 không đúng sẽ gây hậu quả “chết người”? Hãy xem thử qua câu chuyện sau nhé!
Page bị bỏ bê lâu ngày chả đụng chạm gì 🙁
Nay tiện có một issue trong dự án làm mình khá nhức nhối nên muốn chia sẽ cho mọi người 1 chút kinh nghiệm, biết đâu lại cứu đc một dự án nào đó khỏi nguy cơ bị cắt hợp đồng vì lý do vi phạm bảo mật thông tin ^^!
Mình xin trường thuật lại 1 đoạn đối thoại ngắn giữa 2 SA trong 1 dự án cloud AWS cho khách hàng XXX. Context: SA_A thấy SA_B cho phép team public S3 bucket của dự án. Trong bucket có khá nhiều thứ, nhìn lướt qua thì “cảm giác ko có gì cần bảo mật lắm” =]]]]]]] (opensoft, middleware, script file, setting file, có file đuọc đặt tên bao gồm cả tên khách hàng, user/password của OS,…):
A: Tại sao S3 bucket này lại là PUBLIC nhỉ?
B: Mấy cái này toàn là opensoft và script không chứa thông tin gì private cả!
A: Nhưng mà thấy có define role để cấp quyền download cho EC2 từ S3 bucket này mà, sao ko dùng?
B: Thời gian ngắn, việc download bằng role cũng phức tạp nên dùng cách public cho nhanh.
A: Sao ko restrict việc access tới S3 bucket objects bằng bucket policy?
B: VIệc setting khó, tốn thời gian nên chưa làm được.
A: Uhm…! (Nothing to say – I mean “bó tay”!)
Ok, chắc mọi người đọc thì cũng hiểu đc context ở đây rồi nhỉ. Trong bài này mình sẽ tập trung vào những lỗi sai, issue, risk, để mọi người có thể nhận thức rõ hơn về độ nguy hiểm trong bảo mật thông tin.
- Về kĩ thuật:
- Đã được design là dùng IAM role để gắn vào EC2 instance, chỉ cho phép instance đó được download từ S3 bucket này về nhưng SA B và team lại ko làm theo design. => Không làm theo design là đã sai rồi! Cái gì design ra là đã đc cân nhắc khá nhiều ngay từ đầu.
- Không dùng role vì phải change code từ wget sang dùng aws CLI phức táp: không hợp lý, về cơ bản thì nếu sửa cũng chỉ 1 dòng aws cli là xong, ko có gì khá khăn về kĩ thuật
- Không setting restrict trong S3 bucket policy vì khó: nếu biết cách thì hoàn toàn không khó vì system này đc design rất chuẩn từ đầu về network, services,… và có dùng cả S3-VPC Endpoint => chỉ việc tạo 1 policy để restrict chỉ cho access bucket từ vpc-endoint-ID mà system đang dùng là xong.
- Về Mindset: đã làm với cloud thì càng phải cẩn thận trong mảng security, mindset luôn phải suy nghĩ sao cho đảm bảo security đầu tiên, rồi sau đó tùy vào tình hình mà thay đổi cho phù hợp nhưng kết quả cuối cùng vẫn phải đảm bảo bảo mật thông tin. Chưa kể đây là vị trí SA?!?
- Security:
- Nghĩ là sẽ khó có khả năng người khác kiếm đc S3 bucket mà dự án đang dùng vì tên bucket name là generate random? No No, hiện tại lên Github search 1 cái là ra rất nhiều script giúp scan public bucket và lưu lại file list,… Lỡ như có ai đó lấy ra đúng lúc đang share, capture lại info, public đâu đó là vào 1 ngày đẹp trời, khách hàng nhìn thấy thì… ôi thôi, tạch dự án for sure :d
- Golden securoty rule: Cách bảo mật tốt nhất là không có ai có thể access vào cả =]]] dựa vào đó, càng nhiều người, nhiều cách access đc thì tỉ lệ nghịch với độ bảo mật
- Về Pricing: Theo như mọi người đã biết, S3 tính tiền trên rất nhiều metric: data return size, number of request,… Mà một khi public, chỉ cần ai đó muốn, viết script đơn giản để liên tục request lấy data về với tần suất lớn => cuối tháng trả ngáp luôn =]]]
Đó là 1 vài điểm cần chú ý khi public S3 bucket, khi public thì phải xem mục đích là gì, data gì, có cần thiết public ko, nếu public cần làm gì để bảo mật data, protect data tránh việc copy data (xem bài về prevent hot link), giảm loading cost (CDN, cloudfornt,…),… rất rất nhiều thứ phải consider.
Chúc mọi người có cách suy nghĩ smart hơn khi làm việc với AWS!!!