Hỗ trợ các nhóm kỹ thuật thông qua quản lý bí mật ưu tiên nhà phát triển

Quản lý bí mật là một thách thức mà mọi tổ chức phải giải quyết, từ các doanh nghiệp lớn đến các nhóm phát triển nhỏ. Tổ chức càng lớn, càng có nhiều bí mật có xu hướng mở rộng và các nhóm kỹ thuật càng cảm thấy ma sát hoặc vất vả trong các quy trình tổ chức. Trong khi một số công cụ và sản phẩm tồn tại để cung cấp các giải pháp quản lý bí mật, mỗi công cụ sẽ phải chịu sự đánh đổi an ninh hoặc hậu cần riêng. Mặc dù không có giải pháp chung cho quản lý bí mật mà mọi tổ chức nên áp dụng, nhưng có những mô hình chung mà hầu hết các tổ chức phát triển thông qua. Đối với các doanh nghiệp muốn tích hợp các biện pháp kiểm soát bảo mật vào một tổ chức kỹ thuật gồm hàng trăm nhà phát triển, mô hình mô hình hóa phương pháp bảo mật ưu tiên nhà phát triển là điều cần thiết để phù hợp với tốc độ và quy mô của các doanh nghiệp hiện đại.

Vấn đề với việc dịch chuyển sang trái

Hiện nay, “dịch chuyển bảo mật sang trái” là xu hướng nóng để mở rộng quy mô hoạt động bảo mật thành thực tiễn kỹ thuật trong các tổ chức hiện đại. Việc thay đổi bảo mật khiến các nỗ lực cải thiện vòng đời phản hồi bảo mật bằng cách chèn các hoạt động bảo mật trước đó vào quy trình làm việc của nhà phát triển. Mục tiêu là cho phép các nhà phát triển nắm bắt sớm các vấn đề bảo mật và khắc phục chúng khi nó “rẻ hơn” – trong quá trình phát triển, trước khi vấn đề đến môi trường sản xuất.

Tuy nhiên, đối với nhiều tổ chức, mô hình dịch chuyển sang trái không tạo ra kết quả có ý nghĩa. Các nhóm bảo mật đang cố gắng thiết lập một sự thay đổi văn hóa trong các tổ chức kỹ thuật mà không thực hiện các thay đổi văn hóa cần thiết trong chương trình bảo mật. Họ chắc chắn đang bổ sung rất nhiều công việc bảo mật mới cho các nhóm kỹ thuật – nhưng những hoạt động này không ảnh hưởng có ý nghĩa đến tình hình rủi ro của doanh nghiệp.

Các tổ chức bảo mật chuyển sang trái từ bỏ quyền sở hữu sự phức tạp về hậu cần của việc tích hợp các sáng kiến bảo mật vào quy trình phát triển. Họ đưa ra các tín hiệu bảo mật cho các nhà phát triển và khiến các nhóm kỹ thuật chịu trách nhiệm tìm ra cách giải quyết những mối quan tâm này cùng với trách nhiệm sản phẩm, thử nghiệm và cơ sở hạ tầng của họ. Nick Liffen gần đây đã vạch ra những thách thức mà tư duy này tạo ra cho các nhà phát triển trong cuộc nói chuyện GitHub Universe 2022, “Chuyển sang trái và bảo mật ưu tiên nhà phát triển“. Kelly Shortridge mô tả hành vi này là “chủ nghĩa cản trở an ninh“. Các hoạt động bảo mật chỉ đơn giản là chuyển công việc vất vả từ một nhóm bảo mật sang một nhóm kỹ thuật là một sự tham nhũng đáng tiếc của tâm lý cánh tả thay đổi. Tập trung các sáng kiến và sản phẩm bảo mật xung quanh cách tiếp cận ưu tiên nhà phát triển là điều cần thiết cho các sáng kiến bảo mật để phù hợp với tốc độ và quy mô của các doanh nghiệp hiện đại.

Một lỗ hổng mà tôi đã thấy với nhiều cách tiếp cận dịch chuyển sang trái có ý định tốt là họ tìm kiếm sự thay đổi văn hóa chỉ trong kỹ thuật và không áp dụng cùng một sự thay đổi tư duy trong bảo mật. Chương trình bảo mật nên tập trung ít hơn, như Kelly Shortridge mô tả, “đầu ra bảo mật như một đại diện cho sự tiến bộ” và thay vào đó là những cây kim di chuyển đáng kể vị thế rủi ro của tổ chức. Rủi ro kinh doanh là bất kỳ rủi ro nào mà một tổ chức phải đối mặt với các yếu tố sẽ làm giảm lợi nhuận hoặc dẫn đến thất bại. Tương tự, rủi ro bảo mật là một lỗ hổng đe dọa khả năng đạt được mục tiêu của công ty, bao gồm cả việc mất lòng tin của khách hàng. Do đó, các thực tiễn bảo mật làm giảm tình trạng rủi ro của tổ chức đồng thời giúp doanh nghiệp đạt được mục tiêu của mình là rất quan trọng. Một cách mạnh mẽ để giúp đảm bảo các hoạt động bảo mật cải thiện doanh nghiệp một cách có ý nghĩa trong khả năng này là ưu tiên các tác động theo ngữ cảnh khi lập kế hoạch cho các sáng kiến bảo mật.

Quản lý bí mật Shift-Left

Để hiểu sự khác biệt giữa bảo mật dịch chuyển sang trái và bảo mật ưu tiên nhà phát triển, chúng ta hãy xem cách tiếp cận “dịch chuyển sang trái” đối với quản lý bí mật có thể trông như thế nào.

Theo cách tiếp cận này, các nhà phát triển có trách nhiệm quản lý các bí mật mà hệ thống của họ cần. An ninh cung cấp một kho bí mật; họ đã thiết lập HashiCorp Vault để tổ chức sử dụng. Thay đổi chính sách bí mật xảy ra trong kho lưu trữ GitHub trong thiết lập cơ sở hạ tầng dưới dạng mã. Khi các nhà phát triển muốn có vai trò Vault mới hoặc thực hiện thay đổi đối với các đường dẫn bí mật mà họ có thể truy cập, họ sẽ đẩy yêu cầu kéo đến repo này và bảo mật sẽ phê duyệt và hợp nhất các thay đổi. Để hỗ trợ theo dõi quyền sở hữu các bí mật bên trong vault, nhóm bảo mật thiết lập các mẫu cần thiết về cách các nhà phát triển phải định dạng vai trò và chính sách trong PR của họ.

Cho đến nay, xương của phương pháp này có vẻ tốt. Các nhà phát triển có khả năng thực hiện các thay đổi mà họ cần, trái ngược với việc nộp vé cho một nhóm khác và chờ đợi. Bảo mật cung cấp các phương pháp hay nhất chung và kỳ vọng để hợp lý hóa việc tiêu thụ trong tổ chức. Các thay đổi được quản lý thông qua kiểm soát phiên bản và được mã hóa trong mã nguồn. Bảo mật có một chút vai trò gác cổng, nhưng hành động đủ thường xuyên để đây là một cách sử dụng thời gian của bảo mật đáng ngờ hơn là một trở ngại thực sự cho các kỹ sư. Các vấn đề phát sinh khi bạn xem xét các hoạt động hàng ngày của các nhà phát triển tương tác với thiết lập này. Dưới đây là một cuộc trò chuyện bịa đặt bắt nguồn từ nhiều chủ đề rất thực tế mà tôi đã thấy trong quá khứ:

Nhà phát triển: “Này, tôi đang thiết lập bí mật cho một dịch vụ mới cho dự án ImportantToTheBusiness. Tôi phải làm gì đây?”

Bảo mật: “Đây là liên kết đến trang wiki của chúng tôi.”

20 phút trôi qua

Nhà phát triển: “Xin chào, tôi nghĩ rằng tôi đã làm theo những hướng dẫn đó một cách chính xác. Đây là PR của tôi.”

Bảo Ninh: “Không, điều này sẽ không hoạt động như bạn nghĩ.”

Nhà phát triển: “Ồ, ok. Tôi cần gì phải thay đổi?”

Bảo mật: “Đây là trang wiki khắc phục sự cố của chúng tôi.”

2 tuần qua lại sau đó

Bảo mật: “Ở đây, tôi đã làm lại PR của bạn thành định dạng chính xác. Bây giờ ngươi nên tốt rồi.”

Nhà phát triển: “Cảm ơn!”

Bảo mật: “Đây là thông tin đăng nhập cho vai trò bí mật của bạn. Đừng đánh mất chúng. Lưu trữ chúng một cách an toàn khi bạn tạo quy trình của mình.”

Nhà phát triển: “Làm thế nào để tôi làm điều đó?”

An Ninh: “Đó là trách nhiệm của anh.”

Mặc dù được chỉ ra, đây là một sự phản ánh thực tế về các tương tác mà tôi đã thấy trong các tổ chức thúc đẩy tâm lý “dịch chuyển sang trái” mà không có các thành phần ngữ cảnh quan trọng của tư duy ưu tiên nhà phát triển. Bảo mật thiết lập một số bí mật quản lý “cơ sở hạ tầng như một dịch vụ” để các nhà phát triển sử dụng và mong đợi các mẫu triển khai nhất định, nhưng không cung cấp tài nguyên “nền tảng như một dịch vụ” để giúp các nhà phát triển triển khai các mẫu đó.

Một lần nữa, có những xương tốt trong cuộc trò chuyện đó! Bảo mật có hướng dẫn tài liệu mà các kỹ sư có thể làm theo. Họ bước vào và cung cấp các giải pháp khi các nhà phát triển đang gặp khó khăn. Tuy nhiên, quá trình tổng thể tạo ra nhiều vấn đề cho các nhà phát triển hơn là giải quyết. Có ma sát cao để có được một thiết lập làm việc và các kỹ sư thường thất bại do các quy định không rõ ràng, đòi hỏi bảo mật phải bước vào và thực hiện công việc cho họ. Tại thời điểm mà quá trình không còn yêu cầu sự tham gia của bảo mật, chúng không còn hữu ích cho nhà phát triển.

Cách tiếp cận “dịch chuyển sang trái” này đặt trách nhiệm quản lý bí mật lên nhà phát triển, nhưng không cung cấp hướng dẫn để cho phép họ tự phục vụ. Nó giải quyết các vấn đề của nhóm bảo mật mà không cần xem xét các vấn đề của nhà phát triển. Nó thiếu thành phần ngữ cảnh của phương pháp bảo mật ưu tiên nhà phát triển.

Bảo mật ưu tiên nhà phát triển

Vậy một chương trình bảo mật ưu tiên nhà phát triển trông như thế nào? Chìa khóa để bảo mật ưu tiên nhà phát triển là đưa các thiết kế bảo mật theo ngữ cảnh vào môi trường. Chương trình bảo mật phải tích hợp vào các quy trình phát triển hiện có trong tổ chức bằng cách giải quyết các vấn đề có ý nghĩa. Thay vì tạo một danh sách các nhiệm vụ để các nhà phát triển tuân theo để tuân thủ yêu cầu bảo mật, bảo mật nên thiết kế một đường dẫn trải nhựa được nhúng trong quy trình hoạt động bình thường của tổ chức. Bảo mật nên làm cho con đường an toàn trở thành con đường dễ dàng cho các nhà phát triển. Bảo mật nên hoạt động tương đương với một nhóm kỹ thuật nền tảng, cung cấp chuyên môn về chủ đề và cung cấp các thực tiễn an toàn theo mặc định nền tảng mà các nhóm kỹ thuật có thể sử dụng.

Họ phải giải quyết các vấn đề kinh doanh thực sự. Câu trả lời cho “tại sao chúng ta phải làm điều này?” nên mô tả một con đường rõ ràng để cho phép các mục tiêu sản phẩm. “Bởi vì an ninh nói như vậy” là phản ứng tồi tệ nhất, một hiện vật di sản của các chương trình an ninh chiến đấu trong quá khứ, những người coi đồng nghiệp của họ là mối đe dọa mà từ đó doanh nghiệp phải được bảo vệ. Thay vào đó, nhóm bảo mật nên hoạt động như một đối tác hợp tác, giúp doanh nghiệp đạt được các sáng kiến của mình. Một chương trình bảo mật ưu tiên nhà phát triển đòi hỏi một sự thay đổi văn hóa lớn trong nhóm bảo mật – có lẽ lớn hơn – so với chương trình trong bộ phận kỹ thuật.

Quản lý bí mật ưu tiên nhà phát triển

Vậy làm thế nào để chúng ta điều chỉnh chương trình quản lý bí mật theo cách tiếp cận ưu tiên nhà phát triển? Mặc dù phải luôn có tài liệu, chương trình nên cố gắng loại bỏ nhu cầu sử dụng nó. Đường dốc phải là một con đường trải nhựa mà các nhà phát triển có thể đọc thêm, nếu họ quan tâm. Biến các hướng dẫn phổ biến và dễ bị lỗi thành các tập lệnh thực thi tạo ra một giải pháp khả thi. Cấu trúc hoặc mô hình dự kiến trong chính sách bí mật nên được mã hóa thông qua các linters để các nhà phát triển thực sự có thể tự phục vụ cấu hình của họ và bảo mật có thể lùi lại khỏi các yêu cầu kéo cổng. Tại DigitalOcean, phiên bản kho lưu trữ chính sách bí mật của chúng tôi cho phép các nhà phát triển chạy tương đương với tập lệnh tạo ra cấu hình bí mật được sử dụng phổ biến nhất cho các hệ thống. Các trường hợp sử dụng thay thế có thể được cấu hình với các cờ trên tệp thực thi và các khả năng đó được ghi lại cho các nhà phát triển. Kiểm tra xác thực trên các bí mật PR kiểm tra xem cấu hình mong muốn sẽ phá vỡ bất cứ điều gì hoặc nằm ngoài việc sử dụng được chấp nhận. ./bin/gen_new_service

Bảo mật không nên từ bỏ bất kỳ phần nào của quy trình phát triển trong đó các bí mật có liên quan. Các mẫu và hướng dẫn được đề xuất của họ nên mở rộng đầy đủ trong vòng đời phát triển phần mềm. Trong DigitalOcean, một trình hướng dẫn tương tác tồn tại để hướng dẫn các nhà phát triển qua quá trình thiết lập vai trò để gắn vào dịch vụ của họ, định cấu hình nhiều đường dẫn truy cập chi tiết cho các mô hình triển khai phổ biến và tạo (các) quy trình triển khai kỹ thuật cho nhà phát triển với sự tích hợp hoạt động của vai trò bí mật mới, cụ thể được tích hợp sẵn của họ. Điều này không chỉ cung cấp một con đường mở đường cho việc quản lý bí mật mà bảo mật quan tâm, mà còn là một giải pháp giúp các nhà phát triển triển khai các đường ống kỹ thuật của họ dễ dàng hơn, bên trong đó tiêu thụ bí mật chỉ là một phần nhỏ.

Đáng chú ý, trình hướng dẫn không hỏi nhà phát triển nếu họ muốn thực hiện “nhiệm vụ bí mật A” hay “nhiệm vụ bí mật B”. Nhà phát triển dự kiến sẽ không hiểu được sự phức tạp liên quan đến việc đưa ra quyết định đó. Thay vào đó, nhà phát triển được hỏi tác vụ kỹ thuật nào họ muốn thực hiện và công cụ hướng dẫn họ qua các bước bảo mật có liên quan cho tác vụ đó. Do đó, thời gian của nhóm bảo mật có thể được dành cho việc thêm các đường dẫn chung bổ sung trong tổ chức vào trình hướng dẫn, củng cố đường dẫn trải nhựa có sẵn. Điều này giải quyết các mối quan tâm kỹ thuật cùng với các mối quan tâm về bảo mật. Điều này làm cho cuộc sống của các nhà phát triển dễ dàng hơn. Đây là bảo mật theo ngữ cảnh, ưu tiên nhà phát triển. Điều này đòi hỏi khả năng kỹ thuật và phân phối sản phẩm trong nhóm bảo mật, đây có thể là một sự thay đổi đối với một số tổ chức. Đó là một sự thay đổi cần thiết để chuyển đổi từ “những người cản trở bảo mật” sang những người hỗ trợ ưu tiên nhà phát triển, nhúng bảo mật vào tốc độ và quy mô của vòng đời nhóm phát triển hiện đại.

Giải pháp ưu tiên nhà phát triển cho vấn đề số không bí mật

Một điểm ma sát chưa được trả lời từ ví dụ “dịch chuyển sang trái” ban đầu là yêu cầu các nhà phát triển lưu trữ an toàn thông tin xác thực của họ cho kho lưu trữ bí mật trong quy trình của họ. Tại DigitalOcean, chúng tôi đã cung cấp tài liệu phác thảo các mẫu mà các nhà phát triển có thể sử dụng để xử lý chúng một cách an toàn trên các công cụ CI/CD khác nhau mà chúng tôi đã sử dụng. Hiện tại, các nhà phát triển đang chuyển sang GitHub Actions. Việc giới thiệu hỗ trợ OIDC vào cuối năm 2021 từ quy trình làm việc Hành động đã mang đến cho chúng tôi cơ hội phát triển một lộ trình trải nhựa theo ngữ cảnh mới để giúp các nhà phát triển chuyển đổi quy trình sang Hành động GitHub đồng thời loại bỏ trở ngại trong quản lý thông tin xác thực. Đọc bài viết tiếp theo của chúng tôi để tìm hiểu cách DigitalOcean cung cấp cho các nhóm kỹ thuật cách tiếp cận ưu tiên nhà phát triển đối với RBAC chi tiết trong khi loại bỏ “số không bí mật” với GitHub OIDC và HashiCorp Vault.

Ari Kalfus là Giám đốc Bảo mật Sản phẩm tại DigitalOcean. Nhóm Bảo mật Sản phẩm là cố vấn nội bộ tập trung vào việc cho phép doanh nghiệp đổi mới và thử nghiệm rủi ro một cách an toàn. Nhóm hướng dẫn thiết kế kiến trúc an toàn và giảm rủi ro trong tổ chức bằng cách xây dựng lan can và đường trải nhựa cho phép các kỹ sư đưa ra quyết định bảo mật sáng suốt.