Kiến trúc sư đám mây Nodir Safarov, người lãnh đạo quá trình di chuyển và tự động hóa cơ sở hạ tầng cho hàng nghìn khách hàng toàn cầu tại SOTI Inc., xác định các lỗi kiến trúc đằng sau các lỗ hổng bảo mật đám mây phổ biến nhất và các nguyên tắc thiết kế ngăn chặn chúng.
Việc áp dụng đám mây doanh nghiệp đã tăng tốc nhanh hơn bảo mật đám mây doanh nghiệp. Khi các tổ chức di chuyển khối lượng công việc quan trọng sang môi trường AWS, Azure và nhiều đám mây, nhiều tổ chức nhận thấy rằng tốc độ và quy mô đã vượt xa kiến trúc bảo mật của họ. Kết quả là khoảng cách ngày càng tăng giữa những gì các công ty cho là được bảo vệ và những gì thực sự là như vậy.
Hầu hết các nền tảng đám mây đều đã cung cấp các tính năng bảo mật gốc mạnh mẽ. Vấn đề không phải là công cụ. Vấn đề nằm ở kiến trúc: cách thức và thời điểm bảo mật được tích hợp vào thiết kế cơ sở hạ tầng đám mây. Trong quá nhiều tổ chức, bảo mật được tăng cường sau khi triển khai đã chạy trong sản xuất, tạo ra các lỗ hổng cần khắc phục tốn kém và dễ bỏ sót.
Chúng tôi đã nói chuyện với Nodir Safarov, Chuyên gia kiến trúc đám mây tại SOTI Inc., nơi ông lãnh đạo các sáng kiến tự động hóa cơ sở hạ tầng và di chuyển đám mây hỗ trợ môi trường doanh nghiệp trên khắp Bắc Mỹ, Châu Âu và Châu Á. Dựa trên kinh nghiệm từ việc triển khai quy mô lớn trên nhiều ngành, Safarov cho biết ông nhiều lần nhận thấy những sai lầm về kiến trúc giống nhau tạo ra những lỗ hổng bảo mật đám mây có thể tránh được, thường rất lâu trước khi các nhóm nhận ra rủi ro. Ông nổi tiếng với việc thiết kế các biện pháp kiểm soát bảo mật trực tiếp vào quy trình làm việc dưới dạng mã và cơ sở hạ tầng CI/CD, để các nhóm có thể thực thi các biện pháp bảo vệ nhất quán theo mặc định thay vì dựa vào các bản sửa lỗi sau triển khai. Trong cuộc trò chuyện của chúng tôi, Safarov nhấn mạnh các mẫu thiết kế có thể lặp lại, phân đoạn, quyền truy cập có ít đặc quyền nhất và ghi nhật ký sẵn sàng kiểm tra, làm nền tảng của các chương trình đám mây linh hoạt. Ông nói thêm rằng tiêu chuẩn hóa thông qua mã và tự động hóa là điều giúp bảo mật bền vững ở quy mô doanh nghiệp.
“Các mô hình lặp lại ở các tổ chức thuộc mọi quy mô,”Safariv nói.”Đây là những vấn đề mang tính hệ thống và chúng đòi hỏi các giải pháp kiến trúc. Chúng không thể được vá sau khi thực tế.”
💜 của công nghệ EU
Những tin đồn mới nhất từ bối cảnh công nghệ EU, câu chuyện từ người sáng lập thông thái Boris của chúng tôi và một số tác phẩm nghệ thuật AI đáng nghi vấn. Nó miễn phí hàng tuần trong hộp thư đến của bạn. Đăng ký ngay bây giờ!
Dựa trên những gì anh đã quan sát được trong quá trình triển khai quy mô lớn, đây là 5 lỗi bảo mật đám mây phổ biến nhất mà Safarov gặp phải và các phương pháp tiếp cận ở cấp độ thiết kế mà anh đề xuất để ngăn chặn chúng trước khi triển khai.
1. Xử lý bảo mật như lớp sau triển khai
Đây là sai lầm tạo điều kiện cho tất cả những sai lầm khác. Các tổ chức thường xây dựng cơ sở hạ tầng đám mây trước rồi cố gắng bảo mật cơ sở hạ tầng đó sau. Vào thời điểm các nhóm bảo mật đánh giá môi trường sản xuất, kiến trúc đã được thiết kế dựa trên các giả định không tương thích với tình hình bảo mật mạnh mẽ: kiểm soát quyền truy cập quá dễ dãi, kho dữ liệu không được mã hóa và cấu hình mạng mở vốn chỉ là tạm thời nhưng chưa bao giờ bị khóa.
Chi phí của phương pháp này tăng lên nhanh chóng. Trang bị thêm tính năng bảo mật cho kiến trúc hiện có đồng nghĩa với việc sửa đổi các hệ thống đang hoạt động và mọi sửa đổi đều gây ra rủi ro cho sự ổn định của quá trình sản xuất. Trong một môi trường doanh nghiệp mà Safarov đánh giá, một quy tắc truy cập mở tạm thời được tạo trong quá trình triển khai ban đầu đã tồn tại trong nhiều tháng, âm thầm đưa các API nội bộ ra internet công cộng. Cấu hình có vẻ ổn định theo mọi chỉ số giám sát tiêu chuẩn. Nó chỉ bị phát hiện trong quá trình đánh giá bảo mật thủ công xảy ra trước khi xảy ra sự cố.
“Thời điểm tốt nhất để triển khai các phương pháp hay nhất về bảo mật đám mây là trước khi triển khai lần đầu tiên,” Safarov nói. “Xây dựng nó vào bản thiết kế của bạn ngay từ ngày đầu tiên.”
Trong thực tế, điều này có nghĩa là nhúng trực tiếp các biện pháp kiểm soát bảo mật vào các mẫu cơ sở hạ tầng dưới dạng mã. Khi Safarov thiết kế các mô-đun Terraform và đường dẫn CI/CD, các chính sách bảo mật, phân đoạn mạng, tiêu chuẩn mã hóa, kiểm soát truy cập và cấu hình ghi nhật ký đều được ghi vào chính mã đó. Mọi hoạt động triển khai sử dụng các mẫu đó đều tự động kế thừa trạng thái bảo mật, giảm gánh nặng cho các nhóm kỹ thuật trong khi vẫn đảm bảo tính nhất quán. Bảo mật trở thành mặc định thay vì phải suy nghĩ lại.
2. Đầu tư chưa đủ vào Kiến trúc khắc phục thảm họa
Tính sẵn sàng cao và khắc phục thảm họa là một trong những khía cạnh quan trọng nhất của kiến trúc đám mây, tuy nhiên chúng thường được coi là mối quan tâm thứ yếu trong giai đoạn xây dựng ban đầu. Các tổ chức cho rằng chạy trên đám mây vốn đã mang lại khả năng phục hồi. Đúng vậy, nhưng chỉ khi kiến trúc được thiết kế có chủ ý để tận dụng lợi thế của nó.
Giả định này có thể hiểu được. Các nhà cung cấp đám mây cung cấp các vùng khả dụng, dự phòng và khả năng chuyển đổi dự phòng. Nhưng những tính năng đó đòi hỏi phải có những quyết định kiến trúc có chủ ý để kích hoạt. Nếu không lập kế hoạch DR có chủ ý, một lỗi cơ sở hạ tầng có thể khiến các hệ thống quan trọng ngừng hoạt động mà không có đường phục hồi rõ ràng. Tác động kinh doanh bao gồm từ mất doanh thu đến các hình phạt theo quy định, tùy thuộc vào ngành và thời gian ngừng hoạt động.
Safariv đã gặp phải các tổ chức ghi lại các kế hoạch khắc phục thảm họa nhưng chưa bao giờ thử nghiệm chúng với cơ sở hạ tầng thực tế của họ. Khi xảy ra sự cố, quy trình khôi phục giả định các cấu hình đã bị lỗi nhiều tháng trước đó và kế hoạch khôi phục đã thất bại ở bước đầu tiên.
“Mọi công ty đều cần có Kế hoạch B để khắc phục thảm họa,”Safariv nói.”Kiến trúc sư đám mây là người giám sát việc lập kế hoạch đó và thực hiện nó trước khi sự cố đầu tiên xảy ra. Giữa thời điểm ngừng hoạt động là thời điểm tồi tệ nhất để phát hiện ra chiến lược phục hồi của bạn chỉ tồn tại trên giấy tờ.”
Cách tiếp cận của ông coi DR như một yêu cầu kiến trúc ngang bằng với hiệu suất và khả năng mở rộng. Khả năng phục hồi được tích hợp vào nền tảng và được xác thực thông qua kiểm tra thường xuyên, không được ghi lại một lần trong danh sách kiểm tra tuân thủ và bị lãng quên.
3. Bỏ qua chi phí như một hạn chế về kiến trúc
Tối ưu hóa chi phí đám mây thường được coi là mối quan tâm tài chính, tách biệt với các quyết định về kiến trúc. Trong thực tế, chi phí là kiến trúc. Khi các nhóm kỹ thuật cung cấp quá nhiều tài nguyên để duy trì biên độ an toàn cao hoặc tạo ra các phiên bản không có chính sách vòng đời, thì doanh nghiệp sẽ nhanh chóng lãng phí. Ở quy mô lớn, những khoản lợi nhuận đó trở thành một trong những chi phí ẩn cao nhất trong chương trình đám mây.
Tác động tài chính là đáng kể và tự củng cố. Các tổ chức coi việc tối ưu hóa chi phí là giải pháp muộn màng sẽ thấy mình bị mắc kẹt trong những kiến trúc tốn kém để duy trì và khó tái cơ cấu. Trên thực tế, việc xác định kích thước nguồn lực phù hợp có nghĩa là tái cấu trúc các hệ thống sản xuất, một quy trình tốn kém và mang tính đột phá hơn nhiều so với việc thiết kế để mang lại hiệu quả ngay từ đầu.
Kinh nghiệm của Safarov về tài chính doanh nghiệp trước khi chuyển sang kiến trúc đám mây mang lại cho anh một lợi thế đặc biệt về vấn đề này. Ông tiếp cận việc phân bổ nguồn lực như một ràng buộc về thiết kế chứ không phải là một nhiệm vụ dọn dẹp vận hành.
“Kiến trúc phải có hiệu suất cao và linh hoạt nhưng cũng phải hiệu quả về mặt tài chính,”Safariv nói.”Tối ưu hóa phân bổ nguồn lực là một nguyên tắc thiết kế. Việc bỏ qua nó sẽ dẫn đến lãng phí ở quy mô doanh nghiệp và vào thời điểm các tổ chức nhận thấy, chi phí khắc phục là rất đáng kể.”
Việc sửa lỗi bắt đầu ở giai đoạn thiết kế. Khi hiệu quả chi phí được coi là yêu cầu kiến trúc cốt lõi bên cạnh hiệu suất và khả năng phục hồi thì mọi quyết định về nguồn lực đều có chủ ý. Tài sản có quy mô phù hợp ngay từ đầu, được giám sát liên tục và được điều chỉnh theo khối lượng công việc mà chúng hỗ trợ.
4. Cho phép thay đổi cấu hình thông qua các thay đổi thủ công
Khi cơ sở hạ tầng đám mây được định cấu hình theo cách thủ công, thông qua các lần nhấp vào bảng điều khiển, tập lệnh đặc biệt hoặc các thay đổi không có giấy tờ, môi trường chắc chắn sẽ bị lệch khỏi trạng thái dự kiến. Những gì bắt đầu từ một sai lệch nhỏ sẽ trở thành lỗ hổng bảo mật nghiêm trọng theo thời gian, khi các cấu hình sản xuất khác với các đường cơ sở bảo mật mà chúng được thiết kế để đáp ứng.
Sự lệch cấu hình đặc biệt nguy hiểm vì nó vô hình. Các công cụ giám sát tiêu chuẩn theo dõi thời gian hoạt động và hiệu suất, chứ không phải liệu quy tắc nhóm bảo mật có phù hợp với thông số kỹ thuật ban đầu của Terraform hay không. Môi trường có thể trông lành mạnh theo mọi số liệu trên trang tổng quan trong khi vẫn chứa đựng các cấu hình sai làm suy yếu ranh giới bảo mật hoặc cấp quyền truy cập ngoài ý muốn. Trong môi trường doanh nghiệp có nhiều bên thuê, nơi hàng trăm hoạt động triển khai của khách hàng chia sẻ các mô hình cơ sở hạ tầng cơ bản, một cấu hình bị sai lệch có thể xếp tầng trên các môi trường trước khi bất kỳ ai nhận ra.
Giải pháp là cơ sở hạ tầng dưới dạng mã và quy trình CI/CD tự động nhằm đảm bảo tính nhất quán và khả năng kiểm tra trên mọi môi trường. Khi tất cả các thay đổi về cơ sở hạ tầng đều diễn ra thông qua các cấu hình Terraform do phiên bản kiểm soát, mọi sửa đổi đều được ghi lại, xem xét và có thể tái tạo. Sự trôi dạt có thể được phát hiện và những thay đổi trái phép sẽ kích hoạt cảnh báo tự động.
Safarov triển khai phương pháp này thông qua các mẫu IaC được tiêu chuẩn hóa và tự động hóa quy trình giúp loại bỏ sự can thiệp thủ công vào môi trường sản xuất. Kết quả là cơ sở hạ tầng luôn phù hợp với thiết kế được ghi lại: nhất quán, có thể kiểm tra và đáng tin cậy trong mọi hoạt động triển khai.
5. Dựa vào đánh giá bảo mật tại thời điểm
Sai lầm cuối cùng là cho rằng việc triển khai an toàn vẫn được đảm bảo an toàn. Môi trường đám mây rất năng động: quy mô khối lượng công việc, cập nhật cấu hình, dịch vụ mới được thêm vào và bối cảnh mối đe dọa ngày càng phát triển. Tình trạng bảo mật được đánh giá tại thời điểm triển khai sẽ giảm dần trừ khi nó được duy trì tích cực thông qua giám sát liên tục.
Nhiều doanh nghiệp dựa vào kiểm toán an ninh định kỳ hoặc đánh giá hàng quý. Những điều này cung cấp ảnh chụp nhanh có giá trị nhưng bỏ lỡ các mối đe dọa xuất hiện giữa các lần đánh giá: quyền truy cập tạm thời trở thành vĩnh viễn, cấu hình thử nghiệm không thay đổi trong quá trình sản xuất và các thay đổi gia tăng âm thầm làm suy yếu thiết kế bảo mật ban đầu. Trong môi trường doanh nghiệp chuyển động nhanh, nơi việc triển khai diễn ra hàng ngày, các đánh giá hàng quý để lại nhiều tháng tiếp xúc không được giám sát.
Safarov thiết kế các hệ thống đám mây với khả năng giám sát liên tục và phát hiện tự động được tích hợp trong kiến trúc. Thay vì dựa vào đánh giá định kỳ của con người, hệ thống của anh sử dụng cảnh báo tự động để phát hiện các điểm bất thường về cấu hình, các thay đổi về mẫu truy cập và vi phạm chính sách khi chúng xảy ra. Khi một tài nguyên mới được triển khai bên ngoài quy trình IaC đã được phê duyệt, lớp giám sát sẽ gắn cờ tài nguyên đó ngay lập tức thay vì chờ đợt kiểm tra theo lịch trình tiếp theo.
“Bảo mật là một quá trình liên tục và kiến trúc phải thực thi điều đó,” Safarov nói. “Nếu việc giám sát của bạn chỉ cho bạn biết điều gì đã xảy ra trong quý trước thì bạn luôn phản ứng với những vấn đề đã gây ra thiệt hại.”
Chủ đề chung
Trong cả năm sai lầm này, nguyên nhân cốt lõi đều giống nhau: coi bảo mật như một lớp chứ không phải là một nguyên tắc. Khi bảo mật là một lớp, nó có thể bị bỏ qua, trì hoãn hoặc thiếu vốn. Khi bảo mật là một nguyên tắc kiến trúc, nó được nhúng vào mọi mẫu, mọi quy trình và mọi quyết định thiết kế ngay từ dòng mã đầu tiên.
Độ tin cậy, bảo mật và hiệu quả chi phí không phải là những ưu tiên cạnh tranh. Chúng phụ thuộc lẫn nhau và các kiến trúc đám mây mạnh nhất coi chúng như một thách thức thiết kế duy nhất. Các tổ chức có được quyền này sẽ xây dựng nền tảng bảo mật cho mình. Các tổ chức làm sai phải mất nhiều năm và nguồn lực đáng kể để cố gắng trang bị thêm những gì lẽ ra phải có ngay từ đầu.
Nguồn The Next Web