8 phương pháp tốt nhất để bảo mật trong microservices

1439

Hầu như không có bất kỳ kiểu kiến trúc phần mềm nào hoàn toàn giúp bạn thoát khỏi những vấn đề về bảo mật. Với microservices (kiến trúc nhiều dịch vụ nhỏ), một số vấn đề trở nên đặc biệt khó khăn hơn rất nhiều. Tuy nhiên, cũng có một số tính năng của microservices có thể tăng cường bảo mật.

Với microservices, mạng vẫn còn là một vấn đề có thể khiến cả hệ thống chậm lại. Những vấn đề như kiểm soát lượng truy cập, vốn được cho là đã ổn khi thông qua hệ thống một khối (Monolithic Applications), thì nay vấn đề đó đạt mức độ phức tạp mới. Chính điều này mở đầu cho các cuộc tranh luận và thử nghiệm xem liệu kiến trúc microservices có thực sự giải quyết được nhiều vấn đề hơn là tạo ra hay không. Quyết định có sử dụng microservices thì còn tuỳ thuộc vào nhiều điều kiện.

Khi bạn đã nghiên cứu cẩn thận và quyết định rằng microservices sẽ phù hợp với bạn, thì bạn cần đảm bảo rằng tất cả yêu cầu về bảo mật của ứng dụng đều được đáp ứng. Và dưới đây là 8 phương pháp tốt nhất để bảo vệ microservices của bạn.

1. Sử dụng OAuth cho nhận dạng người dùng và kiểm soát truy cập

Phần lớn các ứng dụng thực tế sẽ cần phải thực hiện một vài mức độ access controlauthorization handling. Những điều bạn muốn tránh ở đây là rơi vào lối mòn. OAuth / OAuth2 là giải pháp tiêu chuẩn cho user authorization. Trong khi xây dựng giao thức ủy quyền tùy chỉnh rõ ràng là một lựa chọn tốt.

Mặc dù OAuth2 không phải là hoàn hảo, nhưng đó là một tiêu chuẩn được áp dụng rộng rãi. Ưu điểm của việc sử dụng nó là bạn có thể dựa vào các thư viện và nền tảng để đẩy nhanh quá trình phát triển. Tương tự như vậy, một số giải pháp để cải thiện mức bảo mật của authorization service dựa trên OAuth, đã được một số công ty lớn và lập trình viên đỉnh nhất xây dựng.

2. Dùng ‘defence in depth’ để ưu tiên các key service

Giả sử, bạn cho rằng một firewall trên phạm vi mạng của bạn là đủ để bảo vệ phần mềm thì đó là một sai lầm lớn. “Defense in depth” được định nghĩa là “một khái niệm đảm bảo thông tin, trong đó có nhiều lớp kiểm soát bảo mật (defense) được đặt trong một hệ thống công nghệ thông tin.”

Bạn cần phải xác định những service nhạy cảm nhất và áp dụng một số lớp bảo mật khác nhau, sao cho kẻ tấn công dù có khả năng khai thác một trong những lớp bảo mật vẫn phải tiếp tục tìm ra từng cách để đánh bại hết tất cả các lớp phòng thủ khác trên các service quan trọng. Nói thì luôn dễ hơn làm, nhưng đây là một số several resources có sẵn để bạn tham khảo.

Bảo mật thường là một công việc dành cho các chuyên gia chứ không phải cho dân nghiệp dư. Một hệ thống bảo mật sẽ có nhiều khả năng thành công hơn nếu nó được thiết lập bởi những người thực sự hiểu họ đang làm gì.

Điều tuyệt vời của microservices là nó giúp bạn dễ dàng áp dụng chiến lược này một cách rất chi tiết bằng cách tập trung vào việc bảo mật và có nhiều resource cụ thể. Kiến trúc này cũng giúp bạn dễ dàng hơn trong việc đa dạng hóa các lớp bảo mật mà bạn muốn áp dụng trên mỗi microservice. Bằng cách đó, kẻ tấn công có thể khai thác được một trong các service của bạn nhưng khó có thể tìm ra cách khai thác cái thứ hai.

3. Đừng cố viết bộ mật mã của riêng bạn

Trong những năm qua, nhiều người đã đầu tư rất nhiều tiền, thời gian và tài nguyên đến mức đáng kinh ngạc vào việc xây dựng các thư viện xử lý việc mã hóa và giải mã. Nếu bạn thuê 10 nhân viên bảo mật chuyên nghiệp và có đủ kinh nghiệm, mang tất cả họ vào một phòng và yêu cầu họ tạo ra thư viện tốt nhất có thể mã hóa và giải mã, thì tôi nghĩ rằng họ sẽ tìm ra cái tốt tương tự như các thư viện tốt nhất đã có sẵn.

Hầu hết trong mọi thời kỳ, mỗi khi nói đến bảo mật, bạn không nên cố gắng đưa ra các giải pháp mới của riêng mình trừ khi bạn có những lý do chính đáng, cụ thể và bạn đã có đủ kỹ năng để tạo ra một cái gì đó tốt hơn tất cả công cụ open source đã có sẵn (các công cụ đã được cộng đồng thử nghiệm rất nhiều lần).

Trong hầu hết các trường hợp, bạn nên sử dụng NaCl/libsodium để mã hóa. Nó phù hợp cho một số vấn đề, nhanh chóng, dễ sử dụng và an toàn. Trong khi nguyên bản của NaCl được viết bằng C, nhưng nó cũng hỗ trợ C + + và Python. Và nhờ libsodium, nó cũng hỗ trợ cho các ngôn ngữ khác như PHP, Javascript và Go có sẵn.

Phần này sẽ không hoàn chỉnh nếu không đề cập đến thư viện Bouncy Castle nổi tiếng. Nếu bạn đang làm việc với Java hoặc C #, thì tốt nhất bạn nên sử dụng cái này. Nếu bạn muốn tìm hiểu thêm về mã hóa, hãy đọc bài hướng dẫn của các nhà phát triển khác (nguồn tiếng Anh).

4. Sử dụng hệ thống cập nhật bảo mật tự động

Nếu bạn muốn kiến trúc microservices của mình vừa an toàn vừa có thể mở rộng cùng một lúc, thì tốt nhất giai đoạn phát triển ban đầu hãy tìm ra cách tự động hóa hoặc ít nhất đặt tất cả các bản cập nhật phần mềm của bạn trong tầm kiểm soát.

Kiểm tra cấp cao trên diện rộng là điều thiết yếu hơn bao giờ hết. Mỗi khi một phần của hệ thống được cập nhật, cần đảm bảo rằng bạn sẽ theo kịp vấn đề càng sớm, càng chi tiết thì càng tốt.

Hãy chắc chắn rằng nền tảng của bạn chủ yếu là “atomic”. Điều đó có nghĩa là tất cả mọi thứ nên được gói trong các container để bạn có thể test ứng dụng bằng một thư viện cập nhật. Nếu quá trình đó thất bại, thì hoàn tác là khá dễ dàng và quan trọng nhất, điều đó hoàn toàn có thể tự động.

CoreOS, RedHat Atomic Linux và Ubuntu Snappy Core cũng là các dự án có lẽ bạn nên tìm hiểu, vì họ cố gắng đưa ra khái niệm tương tự trên mức độ hệ điều hành.

5. Sử dụng firewall phân tán trên hệ thống bằng cách kiểm soát tập trung

Đối với hầu hết các phần, đây có lẽ là phần chưa được khai thác, nhưng tôi tin rằng một bức tường lửa cho phép người dùng kiểm soát chi tiết hơn đối với mỗi microservice (như dự án Project Calico) sẽ trở thành cách giúp chúng tôi xây dựng tường lửa cho toàn bộ microservices. Nếu bây giờ chưa thể, thì ít nhất là trong tương lai gần.

6. Tách container của bạn ra khỏi public network

Amazon, với cổng API AWS của họ, thì khái niệm này trở nên phổ biến và dễ chấp nhận hơn bất kỳ điều gì khác trước đây.

Một cổng API thiết lập một điểm truy cập đơn cho tất cả các yêu cầu đến từ tất cả các khách hàng. Và sau đó biết làm thế nào để cung cấp một giao diện cho tất cả các microservices của bạn.

Bằng cách sử dụng kỹ thuật này, bạn có thể bảo vệ tất cả các microservices của bạn phía sau tường lửa, cho phép cổng API xử lý các yêu cầu bên ngoài và sau đó tương tác với các microservices phía sau tường lửa.

Hơn nữa, bài học kinh nghiệm từ Netflix dạy chúng ta rằng, sử dụng một cổng API là một cách tuyệt vời để tối ưu hóa các yêu cầu dựa trên máy khách, đặc biệt là trong trường hợp trên các thiết bị di động.

7. Sử dụng công cụ phát hiện lỗ hỏng bảo mật cho các container của bạn

Trong bộ kiểm tra tự động của bạn, sẽ bao gồm khả năng tính mức độ dễ xuất hiện lỗ hỏng định kỳ và kiểm tra mức độ an toàn cho các container của bạn. Các ứng cử viên sáng giá của open source trong khoảng này dường như là Clair, từ CoreOS. Docker Security Scanning và Twistlock là một vài lựa chọn tương đối ổn.

Một điều khác cần ghi nhớ ở đây là container có thể không đáng tin cậy trừ khi ký hiệu của nó đã được xác minh. rkt thực hiện điều đó mặc định, trong khi Docker giới thiệu một tính năng tương tự vào thời gian trước đây sau khi tìm thấy một số lỗ hổng bảo mật.

8. Giám sát mọi thứ bằng công cụ

Bạn không thể đủ khả năng để chạy một hệ thống phân phối mà không có một nền tảng giám sát vững chắc, tiên tiến và đáng tin cậy. Một số giải pháp đã có sẵn trên mạng, nhưng một trong những giải pháp đã được xây dựng thì đặc biệt phù hợp với microservices và được giám sát bởi Prometheus.

Được xây dựng bởi các kỹ sư tại SoundCloud, Prometheus là một nền tảng giám sát mã nguồn mở và là một phần của Cloud Native Computing Foundation. Nó đang được hỗ trợ và thông qua bởi một số nhà sản xuất lớn trong ngành, như SoundCloud, CoreOS và Digital Ocean.

Các giải pháp giám sát khác bao gồm InfluxDB, statsd và một số nền tảng nổi tiếng khác.

Và đừng bao giờ đi theo lối mòn

Mặc dù ở trên không phải là một danh sách đầy đủ, nhưng nó cũng đề cập tương đối đến những vấn đề bạn có nhiều khả năng phải đối mặt khi xây dựng các ứng dụng dựa trên kiến trúc microservices.

Khi nói đến bảo mật, việc đi theo lối mòn chưa bao giờ là một ý tưởng hay. Luôn luôn nghiên cứu cách thực tiễn tốt nhất được cộng đồng công nhận và được các chuyên gia góp ý.

Techtalk via Techbeacon

CHIA SẺ