Cloud audit hay kiểm soát trên cloud

Tại sao cần kiểm soát (audit)?

Với con người, mắc lỗi, gặp sai lầm là một phần của cuộc sống. Từ sai lầm gặp phải, chúng ta nhận lỗi, sửa đổi, rút kinh nghiệm và phát triển. Việc quản trị trên cloud cũng tương tự. Gặp lỗi là điều khó tránh khỏi. Cho dù bạn là chuyên gia lâu năm hay người mới bắt đầu. Trong bài viết này, mình sẽ mô tả một góc nhìn của một người làm quản trị về việc kiểm soát lỗi trên môi trường cloud, cách thức kiểm soát, công cụ để giúp làm việc đó.

Lỗi thường gặp trong quá trình vận hành hệ thống trên cloud có thể chia làm ba phần:


 Loại thường gặp nhất: “bảo mật”:
Một số lỗi bảo mật thường gặp trong quá trình vận hành cloud có thể gặp phải: Mở port remote (22, 3389), mở dịch vụ private ra public với firewall (security group, firewall rule), hay thiết lập quyền không đúng (IAM), ví dụ thêm quyền admin vào user bình thường. Mức độ thiệt hại của lỗi phụ thuộc vào việc phát hiện lỗi sớm hay muộn. Mức độ nhẹ: Không ảnh hưởng, hay nặng: Server bị tấn công, chiếm quyền điều khiển mất mát dữ liệu, lộ thông tin nội bộ ra ngoài ảnh hưởng đến công ty và khách hàng.

Không thể không nhắc đến: “chi phí”. 
Xét về góc nhìn quản trị, việc lãng phí tiền trên môi trường cloud vẫn có thể tính là lỗi. Lỗi lãng phí có thể chia làm 2 loại lỗi: Tạo tài nguyên không sử dụng (ec2 instance, RDS, volume…), tạo tài nguyên quá mức sử dụng: service chỉ cần chạy 2 core cpu, nhưng tạo tài nguyên lên đến 8 core cpu. Cũng như lý do ở trên, nếu không kiểm soát. Vào một ngày đẹp trời, chúng ta nhận ra mình đã lãng phí bao nhiêu tiền sau khi rà soát lại tài nguyên sau khi nhận hoá đơn từ nhà cung cấp dịch vụ. Khác với lỗi bảo mật ở trên, trong trường hợp này phải thực sự để ý kỹ mới nhận ra, vì việc lãng phí thường được duy trì theo thời gian.

Bị lãng quên, ít để ý, và khó kiểm soát: “quy định”
Trong 1 tập thể, dự án, nhóm, hay lớn hơn là công ty nơi chúng ta làm việc, tuân thủ quy trình quy định là 1 điều nên làm. Việc tuân thủ ngoài việc đảm bảo bạn không bị đánh giá kém, trừ lương (nếu có), cũng nói lên sự tôn trọng của bạn đến tập thể. Nhưng chúng ta vẫn chấp nhận một suy nghĩ là chắc chắn vẫn có người phạm lỗi, cho dù cố tình hay chỉ là vô ý. Môi trường cloud cũng vậy. Chúng ta cũng đề ra các policy trên đó. Ví dụ như: IAM role cho developer chỉ có quyền giới hạn, production database phải sử dụng multi-az. Gắn tag về environment, name, description… Cũng như quy định với tập thể, việc vi phạm là không tránh khỏi.
Nếu coi phạm lỗi là một bản năng tự nhiên và chấp nhận nó tồn tại. Thì điều quan trọng chính là thái độ của chúng ta với lỗi. Có thể giấu, quên nó đi, lần sau lại lặp lại, hoặc đối diện với nó, sửa sai và phát triển. Trên môi trường cloud, thái độ tích cực với lỗi có thể đến từ hành động: Chủ động kiểm soát, phát hiện lỗi sớm nhất có thể, trước khi nó gây ra hậu quả, hoặc hạn chế hậu quả đã và đang xảy ra.

Chúng ta nên kiểm soát thế nào?

Với môi trường cloud nói chung. Các dịch vụ mới và tính năng mới được bổ sung liên tục. Chỉ tính riêng trong năm 2018, đã có đến 1,957 tính năng và dịch vụ mới được bổ sung trên AWS. Các môi trường cloud khác như Azure hay Google CLoud cũng có sự bổ sung tương tự. Với mỗi dịch vụ lại có những đặc tính riêng. Ví dụ: Multi-az với database, gắn tag với tài nguyên hay nhiều những đặc tính khác. Ngoài ra, xét về cách thức quản trị, theo khuyến cáo của các nhà cung cấp về mặt quản trị: Nên thiết lập 1 tổ chức (organization), sau đó với mỗi dự án tạo 1 account cloud riêng. Với mỗi account, dùng tính năng IAM để tạo role, thiết lập quyền hạn. Tổng hợp lại, khối lượng công việc cần kiểm soát tương đối lớn rồi đây. Khối lượng công việc tỷ lệ thuận với số lượng nhân sự nếu thao tác thủ công bằng người.
Như đã dể cập ở phần lý do. Chúng ta chấp nhận việc mắc lỗi trong quá trình quản trị. Do vậy, việc bỏ sót hay gặp lỗi trong quá trình giám sát thủ công là điều không tránh khỏi. Vậy để tối ưu trong chi phí, chất lượng, hiệu quả không thể làm thủ công được. Quản soát bằng máy, hay sâu hơn, kiểm soát một cách tự động bằng máy sẽ là phương thức phù hợp. (continuous audit)

Giải pháp cho việc kiểm soát.
Việc kiểm soát chắc chắn là điều nên có. Bài toán là: Kiểm soát được 3 loại lỗi trên. Bảo mật, chi phí, việc tuân thủ quy định. Ngoài ra có 1 tính năng và đặc tính tuỳ chọn khác: tích hợp liên tục, miễn phí hoặc trả phí với chi phí hợp lý, có khả năng tuỳ chỉnh và trực quan.
Ở trong phần này, mình sẽ mô tả một số giải pháp bản thân đã tìm hiểu, thử nghiệm và lựa chọn để áp dụng vào thực tế.

Giải pháp đầu tiên, dễ nhìn thấy nhất, giải pháp chính chủ của Amazon. Aws trusted advisor. Theo mô tả, 1 chuyên gia từ aws sẽ đưa cho chúng ta cho chúng ta các lời khuyên: Tối ưu chi phí (dùng reverse instance,..) bảo mật (có port đang mở không giới hạn truy cập, các bản snapshot đang bị public…).. và các lời khuyên khác. Hàng chính chủ thì tốt rồi. Nhưng nhìn sâu hơn 1 chút. Vấn đề về chi phí và chỉnh sửa có vẻ không hợp lý với nhiều trường hợp: tối thiểu là 3% đến 10% chi phí sử dụng hàng tháng tuỳ gói hỗ trợ. Về khả năng tuỳ chỉnh: chỉ mới kiểm tra mở port remote ra internet, chưa kiểm tra dạng blacklist & whitelist IPs được. Cũng khó có thể kiểm soát việc tuân thủ quy định. Thử các giải pháp khác coi. Nên có nhiều hơn 1 sự lựa chọn trước khi ra quyết dịnh.

Các giải pháp tiếp theo.
 Lần này mình theo hướng open source. Hi vọng, với cộng đồng mở, khả năng tìm được giải pháp phù hợp sẽ cao hơn, nhiều lựa chọn hơn.

Security monkey. Đến từ ông lớn Netflix. Hơn 3000 sao trên github, cũng có vẻ khả quan đấy. Cài đặt dùng thử coi. Sau vài tiếng cài đặt với document không rõ ràng lắm, cuối cùng giải pháp cũng đã lên.
Nhìn qua tốt đấy, giao diện rõ ràng, liệt kê hẳn từng issue đang có, đánh điểm nghiêm trọng, hiển thị. Hỗ trợ các tra cứu để biết việc cấu hình đã thay đổi thế nào theo thời gian. Thử nhìn vào những mặt hạn chế coi. Rule fix cứng, nhưng viết bằng python, cũng có thể customize được, dường như sẽ mất nhiều thời gian cho phần này với việc code rule. Cài đặt phức tạp, tài liệu không đầy đủ. Làm thế nào để security monkey nhận diện được ingress (chiều vào) và egress (chiều ra) với security group? Trước khi đi sâu hơn, tiếp tục thử các giải pháp khác xem.

ScoutSuite. Giải pháp này ít nổi bật hơn với 5xx trên github, nhưng cứ thử coi. Chạy xong, view offline như ảnh. Có vẻ tương đối tốt đấy. Tìm hiểu sâu vào kỹ hơn chút xem: Không hỗ trợ kiểm soát liên tục (continous audit). Các rule bị fix cứng rồi, không sửa, có thể thêm ngoại lệ. Thêm ngoại lệ lại phải chạy lại từ đầu. Có vẻ vẫn chưa phù hợp. 
Thêm một số giải pháp nhỏ khác. Hammer, krampus, coud-inquisitor. Vừa không tin tưởng lắm 1xx star, đọc document cũng không phù hợp với yêu cầu. 

Cloud Custodian: Tóm tắt tài liệu mô tả: đảm bảo tuân thủ các policy bảo mật, gắn tag, dọn rác với những tài nguyên không dùng; Quản trị chi phí thông qua việc kiểm soát thời gian bật tắt tài nguyên, có khả năng chỉnh sửa và tích hợp, serverless, 2xxx star ở github, policy as code. Có vẻ phù hợp đấy, cũng không nên chỉ nhìn nhận một chiều, thử nhìn vào những hạn chế coi. Không giao diện, đồng nghĩa không trực quan so với các giải pháp trên. Tự viết policy từ đầu thì đúng chuẩn khả năng tuỳ chỉnh rồi, nhưng có vẻ sẽ mất nhiều công sức đấy. Sau khi thử nghiệm và áp dụng vào chạy thực tế, mình thấy đây đúng giải pháp phù hợp nhất để triển khai. Các bài sau mình sẽ hướng dẫn:
– Cách sử dụng custodian để kiểm soát tài nguyên trên aws. Giám sát liên tục và tích hợp với các giải pháp khác.

References:
https://aws.amazon.com/what-is-aws/
https://aws.amazon.com/organizations/
https://cloudcustodian.io
https://github.com/Netflix/security_monkey