Quét IaC: Một cơ hội học tập tuyệt vời, bị bỏ qua

Mọi thứ bạn đọc về cơ sở hạ tầng dưới dạng mã (IaC) đều tập trung vào cách nó hoạt động hoặc lý do bạn muốn đảm bảo rằng nó thực sự đang được xây dựng theo cách bạn muốn.

Đây là những khu vực quan trọng. Nhưng chúng ta đã suy nghĩ đủ về cách sử dụng phương pháp này trong tổ chức của mình chưa?

As Dấu ấn Melinda từ ESG cho biết trong một báo cáo của công ty, “83% tổ chức đã gặp phải sự gia tăng về cấu hình sai mẫu IaC” khi họ tiếp tục áp dụng công nghệ.

Chúng tôi biết được thông tin từ công việc được thực hiện bởi Cloud Security Alliance (“Các mối đe dọa hàng đầu đối với điện toán đám mây: Eleven nghiêm trọng“) và những lỗi khác, việc cấu hình sai tiếp tục là rủi ro hàng đầu trên đám mây.

IaC được hỗ trợ để giảm
cấu hình sai bằng cách hệ thống hóa việc tạo cơ sở hạ tầng, bổ sung mức độ nghiêm ngặt và quy trình để đảm bảo các nhóm đang xây dựng những gì họ muốn và chỉ những gì họ muốn. Nếu ~83% các đội không thấy điều đó thì có một vấn đề sâu xa hơn đang diễn ra.

Đối với các nhóm nhỏ hơn, nơi mà các phần Dev và Ops của triết lý DevOps kết hợp với nhau, điều đó rất hợp lý. IaC cho phép các nhóm nhỏ này sử dụng cùng một ngôn ngữ — mã — để mô tả mọi thứ họ đang làm.

Đây là lý do tại sao chúng tôi thấy các tính năng trừu tượng ở cấp độ cao hơn cả các công cụ như Terraform hoặc AWS CloudFormation trong CDK AWS và các dự án như cdk8s. Những sự trừu tượng hóa cấp cao đó mang lại sự thoải mái hơn cho các nhà phát triển.

Phối cảnh hoạt động/SRE/nền tảng của dịch vụ đám mây sẽ rất khác so với quan điểm của nhà phát triển của cùng một dịch vụ. Nhà phát triển sẽ xem xét một dịch vụ xếp hàng và đi sâu vào giao diện của nó - một điểm cuối đơn giản để thêm và một điểm cuối để đọc? Đã bán. Đó là một sự tích hợp dễ dàng.

Quan điểm hoạt động này nhằm mục đích tìm ra các cạnh. Vậy khi nào hàng đợi này đạt đến giới hạn? Hiệu suất có ổn định hay nó thay đổi hoàn toàn khi tải?

Vâng, có những mối quan tâm chồng chéo. Và vâng, đây là một cái nhìn đơn giản. Nhưng ý tưởng vẫn được giữ vững. IaC giải quyết được rất nhiều vấn đề, nhưng nó cũng có thể tạo ra và khuếch đại sự mất kết nối giữa các nhóm. Quan trọng hơn, nó có thể làm nổi bật khoảng cách giữa mục đích của những gì bạn đang cố gắng xây dựng và thực tế của những gì bạn đã xây dựng.

Kết quả là, đây là nơi mà các mối lo ngại về bảo mật thường leo thang.

Hầu hết các công cụ - thương mại hoặc nguồn mở - đều tập trung vào việc xác định những điều không ổn với các mẫu cơ sở hạ tầng. T
là một cấu trúc tốt. Làm điều này
sẽ rất tệ. Những công cụ này nhằm mục đích tạo ra những kết quả này như một phần của quy trình tích hợp liên tục/phân phối liên tục (CI/CD).

Đó là một khởi đầu tuyệt vời. Nhưng nó lặp lại vấn đề ngôn ngữ tương tự.

Ai đang nói và ai đang nghe?

Khi công cụ IaC nêu bật một vấn đề, ai sẽ giải quyết vấn đề đó? Nếu đó là nhóm phát triển, liệu họ có đủ thông tin để biết lý do tại sao vấn đề này bị gắn cờ không? Nếu đó là nhóm vận hành, hậu quả của vấn đề có được nêu trong báo cáo không?

Đối với các nhà phát triển, điều thường xảy ra là họ sẽ chỉ điều chỉnh cấu hình để vượt qua thử nghiệm IaC.

Đối với các hoạt động, vấn đề thường là liệu các bài kiểm tra có vượt qua hay không. Nếu đúng như vậy thì hãy chuyển sang nhiệm vụ tiếp theo. Đó không phải là một cú hích vào một trong hai đội; đúng hơn, nó làm nổi bật khoảng cách giữa kỳ vọng và thực tế.

Điều cần thiết là bối cảnh. Công cụ bảo mật IaC cung cấp khả năng hiển thị những gì sắp được xây dựng (hy vọng). Mục tiêu là ngăn chặn các vấn đề trước họ bắt tay vào sản xuất.

Công cụ bảo mật IaC ngày nay đang nêu bật các vấn đề thực sự cần được giải quyết. Lấy đầu ra của các công cụ này và làm phong phú nó bằng ngữ cảnh bổ sung dành riêng cho nhóm chịu trách nhiệm về mã là cơ hội hoàn hảo cho một số tự động hóa tùy chỉnh.

Điều này cũng sẽ giúp thu hẹp khoảng cách ngôn ngữ. Đầu ra từ công cụ của bạn về cơ bản là bằng ngôn ngữ thứ ba — chỉ để làm cho mọi thứ trở nên phức tạp hơn — và cần được truyền đạt theo cách có ý nghĩa đối với đối tượng phát triển hoặc vận hành. Thường là cả hai.

Ví dụ: khi quét cờ rằng quy tắc nhóm bảo mật không có mô tả, tại sao điều đó lại quan trọng? Chỉ nhận được thông báo có nội dung “Thêm mô tả cho ngữ cảnh” sẽ không giúp bất kỳ ai xây dựng tốt hơn.

Loại cờ này là cơ hội tuyệt vời để đào tạo các nhóm đang xây dựng trên đám mây. Việc thêm phần giải thích rằng các quy tắc của nhóm bảo mật phải càng cụ thể càng tốt sẽ làm giảm cơ hội xảy ra các cuộc tấn công độc hại. Cung cấp tài liệu tham khảo cho các ví dụ về các quy tắc mạnh mẽ. Gọi điều đó ra mà không biết mục đích và các nhóm khác không thể kiểm tra tính hợp lệ của xác nhận bảo mật.

Bảo mật là trách nhiệm của mọi người, do đó, việc thừa nhận khoảng cách ngôn ngữ giữa nhà phát triển và hoạt động sẽ làm nổi bật những cơ hội như thế này để bổ sung các tính năng tự động hóa đơn giản nhằm cung cấp thông tin chi tiết cho nhóm của bạn. Điều này sẽ giúp cải thiện những gì họ đang xây dựng và kết quả là sẽ mang lại kết quả bảo mật tốt hơn.

Lưu ý

Tôi là nhà khoa học pháp y, diễn giả và nhà phân tích công nghệ đang cố gắng giúp bạn hiểu về thế giới kỹ thuật số và tác động của nó đối với chúng ta. Đối với người dùng hàng ngày, công việc của tôi giúp giải thích những thách thức của thế giới kỹ thuật số. Việc sử dụng mạng xã hội có ảnh hưởng lớn đến quyền riêng tư của bạn như thế nào? Điều đó có ý nghĩa gì khi các công nghệ như nhận dạng khuôn mặt bắt đầu được sử dụng trong cộng đồng của chúng ta? Tôi giúp trả lời những câu hỏi như thế này và hơn thế nữa. Đối với những người xây dựng công nghệ, tôi giúp họ áp dụng lăng kính bảo mật và quyền riêng tư vào công việc của mình để họ có thể cho phép người dùng đưa ra quyết định rõ ràng hơn về thông tin và hành vi của họ. Có rất nhiều sự nhầm lẫn khi nói đến quyền riêng tư và bảo mật. Không nên có. Tôi làm cho vấn đề bảo mật và quyền riêng tư trở nên dễ hiểu hơn.