Bài viết đến từ Ngô Doãn Thông – DevSecOps Engineer
DevSecOps team @Techcombank
Giới thiệu
Trong 20 năm qua, DevOps đã cùng với Agile, thay thế cho mô hình phát triển Waterfall. Microservices được coi là công nghệ tiên tiến nhất để triển khai kiến trúc dịch vụ. Thời gian phát triển sản phẩm đã được giảm đi, triển khai tự động được thực hiện hàng tuần hoặc hàng ngày và cloud thì cung cấp khả năng tính toán, cơ sở hạ tầng, lưu trữ và mạng rất mạnh mẽ.
Triết lý DevOps thường được tóm tắt bằng khẩu hiệu “move fast and break things”, điều này có nghĩa là triển khai mọi thứ nhanh hơn, mạnh dạn hơn và sẵn sàng, phá bỏ các cấu trúc silo, rào cản, chấp nhận rủi ro và khắc phục nhanh từ những rủi ro đó.
Tuy nhiên, có một yếu tố quan trọng chưa được đề cập tới. Các tổ chức áp dụng DevOps vẫn cần đáp ứng tiêu chuẩn an ninh thông tin và tuân thủ quy định. Sự linh hoạt, đa dạng và tính mở của chuỗi cung ứng phần mềm (software supply chain), đặc biệt là các phần mềm mã nguồn mở, buộc chúng ta phải đánh giá đến yếu tố security này.
Đó là giá trị cốt lõi của DevSecOps: Tưởng tượng ra các giải pháp an ninh mới để bảo vệ phần mềm cũng như quy trình phát triển phần mềm.
Tuy nhiên, đó là một con đường không hề dễ dàng. Cần có một sự hợp tác giữa các nhóm phát triển sản phẩm, đội an ninh thông tin và vận hành để làm cho “security” trở thành quá trình thông suốt. Software supply chain và các CI/CD pipeline là những thành phần vô cùng quan trọng cần được bảo vệ khi áp dụng DevSecOps.
Security: Bảo vệ thông tin cũng như tốc độ phát triển sản phẩm
Có một sự thật là việc áp dụng các tiêu chuẩn an ninh thông tin vào có thể là rào cản làm chậm quá trình phát triển phần mềm. Khi mà time-to-market là quan trọng, thì việc áp dụng tiêu chuẩn an ninh thông tin vào có thể trở thành “bottleneck”. Một số rào cản, vấn đề có thể đưa ra như sau:
- Thiếu chuyên môn về security hoặc khả năng viết code an toàn trong suốt vòng đời phát triển sản phẩm. Developer thường được chấp nhận để triển khai nhanh hơn và khắc phục sau.
- Security ownership: Ai chịu trách nhiệm về mặt security này? Nhà cung cấp dịch vụ cloud? Hay maintainer của các sản phẩm mã nguồn mở? Ta có thể thường mặc nhiên cho rằng các nhà cung cấp dịch vụ, phần mềm khác đã đảm bảo security cho ta khi ta sử dụng. Tuy nhiên đó là một giả định sai lầm.
- Chuyên gia an ninh và kỹ sư phần mềm hoạt động độc lập với nhau, vì vậy an ninh bị đe dọa bởi sự thiếu giao tiếp, thiếu sự phối hợp từ đầu.
Những vấn đề này có thể gây ra những rủi ro tiềm ẩn về mặt security. Nhưng bản thân chúng cũng có thể giúp các tổ chức xây dựng một thái độ thận trọng hơn trước những rủi ro.
Khi mà hệ thống được mở rộng và trở nên phức tạp hơn, các tổ chức sẽ có xu hướng đánh giá nghiêm túc hơn về những rủi ro. Nỗi lo lắng về việc thiếu các tiêu chuẩn an ninh thông tin có thể ảnh hưởng lớn đến toàn bộ sản phẩm, quy trình phát triển tự động hóa, sẽ khiến các tổ chức chủ động tiếp cận đến với các giải pháp quản lý và ngăn ngừa rủi ro hơn.
Security: Sự bổ sung cho DevOps
Nắm bắt được những điểm yếu trong quá trình phát triển phần mềm
Hiện nay, các team DevOps hiện đại hiểu được tầm quan trọng của software supply chain trong chu trình phát triển sản phẩm. Supply chain là thuật ngữ rộng lớn bao gồm rất nhiều thứ khác nhau (công cụ mã nguồn mở hoặc đóng, dependency, platform…) để mô tả cách thức xây dựng phần mềm hiện đại. Software supply chain là một “con đường”, là một cấu trúc phân lớp bao gồm các phần cứng, Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS), và các công cụ khác, được kết hợp cùng với nhau để hỗ trợ cho phần mềm cũng như quá trình phát triển phần mềm đó.
Hiếm khi ta thấy được một công ty làm phần mềm mà có 100% phần mềm, công cụ được sử dụng là do họ tự phát triển. Hầu hết các công ty phần mềm hiện đại đều sử dụng hàng trăm, nếu không phải là hàng ngàn các building block, các thư viện và công cụ mã nguồn mở, các hệ thống triển khai, cơ sở hạ tầng đám mây và dịch vụ SaaS. Mỗi block này lần lượt là sản phẩm cuối cùng từ một supply chain riêng của nó, mà khi sử dụng, ta không kiểm soát được cũng như không có khả năng nhìn thấy được supply chain trước đó của nó.
CI/CD pipeline
CI/CD pipeline là xương sống, là trụ cột của DevOps. Nó dùng để kết nối developer tới các môi trường triển khai, dùng để tối ưu hóa 4 luồng sau đây:
- Continuous integration: Tích hợp liên tục. Tự động hóa việc xây dựng các bản build ứng dụng từ source code và các library, dependency của chúng.
- Continuous testing: Kiểm thử liên tục. Tự động hóa việc kiểm thử ứng dụng sau mỗi commit.
- Continuous monitoring: Giám sát liên tục. Tự động hóa việc thu thập các dữ liệu về log, metric của ứng dụng cũng như hạ tầng trên từng môi trường triển khai.
- Continuous delivery/deployment: Triển khai liên tục. “One-click” để triển khai toàn bộ ứng dụng lên bất cứ môi trường nào.
4 luồng này, được tích hợp trong các CI/CD pipeline, để nhắm tới mục tiêu tối thượng cuối cùng của DevOps, đó là: Continuous improvement – Cải tiến liên tục.
Lợi thế mà những CI/CD pipeline này đem lại là rất lớn. Chúng giúp cho từng thay đổi nhỏ cũng có thể được triển khai (cũng như phục hồi, rollback) một cách nhanh chóng và chính xác.
Tuy nhiên, bản thân chúng cũng tồn tại những mối rủi ro. Mỗi stage trong một CI/CD pipeline là một “interface” có thể bị tấn công, khai thác. Điều đáng lo ngại hơn là mỗi stage có thể đại diện cho mục tiêu có giá trị cao đối với các kẻ tấn công: Không chỉ vì nó có thể lưu giữ các secret, credential, mà còn vì đây là nơi mà một kẻ tấn công có thể thay đổi mã nguồn, thay đổi cấu hình nào đó một cách lặng lẽ ngay giữa luồng build và deploy mà không ai có thể can thiệp được bởi luồng này đang vận hành tự động.
Kết quả là, supply chain cũng như CI/CD pipeline đang trở nên ngày càng dễ bị tấn công do tính mở và phức tạp của chúng. Chúng để lại rất nhiều vùng xám chưa rõ ràng trong các security framework truyền thống.
Từ DevOps tới DevSecOps
DevSecOps là gì?
DevSecOps là kết hợp của việc tích hợp giữa những công cụ, tiêu chuẩn của Security và triết lý “Continuous improvement” của DevOps thành một phương pháp, quy trình phát triển, triển khai phần mềm nhất quán, tự động, hiệu quả và đảm bảo an toàn bảo mật.
DevSecOps sẽ giúp nhận diện các vấn đề an ninh sớm trong quá trình phát triển thay vì sau khi sản phẩm được release như trước kia.
DevSecOps có thể giảm chi phí liên quan đến việc khắc phục những lỗ hổng an ninh bằng cách tích hợp các công cụ security vào mỗi giai đoạn của quá trình phát triển, có thể ngay từ giai đoạn đưa ra yêu cầu, thiết kế trở đi.
Nguyên tắc bảo mật phải là một phần không thể thiếu trong văn hóa của bất kỳ công ty nào. An ninh thông tin phải là một phần của quá trình phát triển phần mềm. Nói ngắn gọn, DevSecOps sẽ giúp đưa những nguyên tắc, trách nhiệm đó đến với từng developer, đến từng bước trong quá trình phát triển phần mềm.
Giá trị cốt lõi của DevSecOps
Tăng tần suất triển khai ứng dụng an toàn
Khi security bao trùm lên toàn bộ CI/CD pipeline, chất tốc độ sẽ sản phẩm được cải thiện. Ta phải thực tế và chấp nhận rằng giai đoạn đầu của việc tích hợp có thể sẽ rất khó khăn. Khi việc phối hợp giữa các nhóm phát triển và security trở nên mượt mà hơn, những vấn đề này sẽ dần biến mất và chỉ còn lại kết quả tích cực.
Giảm thời gian khắc phục các lỗ hổng nguy hiểm
DevSecOps sẽ cải thiện đáng kể thời gian khắc phục trung bình nhờ việc rà quét sớm và tự động, có luồng feedback tốt hơn và mô hình chia sẻ trách nhiệm. Khi trách nhiệm về security được chia sẻ trên toàn bộ CI/CD pipeline cũng như trong quy trình phát triển phần mềm, thay vì tách biệt hoàn toàn về một nhóm security, các vấn đề an ninh được phát hiện sớm và nhanh hơn. Điều này cũng trực tiếp liên quan đến hiệu quả chi phí, vì nó sẽ tốn nhiều tiền hơn để khắc phục lỗi được tìm thấy trong quá trình vận hành hơn là sửa lỗi được xác định trong giai đoạn thiết kế phát triển.
Cải thiện tư duy về an ninh thông tin
Nói chung, việc phát triển phần mềm hiện nay tương đối là phức tạp. Đưa security vào như một “tính năng” từ đầu sẽ giúp tiết kiệm rất nhiều thời gian cho các nhóm security bằng cách loại bỏ các vấn đề vô hại hoặc false positive nhờ vào các quy trình tự động kiểm soát ở mỗi bước. Nó sẽ tạo ra một nền văn hóa mới, tư duy mới, nơi các phương pháp an ninh tốt nhất được chia sẻ và đem đến lợi ích cho tất cả – bắt đầu ngay từ bước thiết kế, phát triển cho tới quá trình triển khai, vận hành phần mềm ứng dụng.
Best practices
DevSecOps nhấn mạnh rằng security là trách nhiệm của tất cả thành viên trong một tổ chức, và mọi người đều phải tuân thủ và thực hiện đảm bảo an toàn bảo mật thông tin.
Chìa khoá để áp dụng thành công mô hình DevSecOps nằm ở ba yếu tố: Con người, quy trình và công nghệ.
Yếu tố con người
Không quan trọng bao nhiêu công nghệ được áp dụng, yếu điểm lớn nhất về mặt an ninh thông tin luôn là con người. Đây cũng là điểm khởi đầu cho bất cứ quá trình áp dụng DevSecOps nào.
Một trong những điều quan trọng nhất nhưng cũng là khía cạnh khó nhất của DevSecOps là thay đổi cách làm việc truyền thống của security team. Đa số cách tiếp cận rủi ro là loại bỏ khi nó đã xảy ra, thay vì chủ động phòng bị trước.
Security team cần chuyển từ việc hoạt động độc lập sang việc tham gia cùng trong luồng phát triển phần mềm. Điều này vừa giúp tăng nhận thức về an ninh thông tin tới tất cả thành viên trong đội dự án, vừa giúp nhận biết sớm các rủi ro tiềm tàng trong phần mềm, trong hệ thống.
Tại Techcombank, DevSecOps team sẽ nhắm tới việc phá bỏ rào cản này giữa security team và project team, đồng thời cung cấp những chính sách và công cụ hỗ trợ cho việc này. Việc tạo ảnh hưởng đến yếu tố con người này sẽ đặt nền móng vững chắc cho việc thay đổi hai yếu tố “Quy trình” và “Công nghệ” tiếp theo của DevSecOps.
Yếu tố quy trình
Các quy trình thông thường được quy phạm tới từng team và thường ít khi có sự chia sẻ giữa các team với nhau. Điều này có thể gây ra ảnh hưởng tới năng suất trong cả một tổ chức. DevSecOps hướng tới việc thiết lập các quy trình tiêu chuẩn chung, các tài liệu đảm bảo security cho tổ chức để tạo sự phối hợp giữa các team như là một khối thống nhất. Việc xây dựng ra một quy trình, tiêu chuẩn tự động hoá đảm bảo an toàn thông tin là trách nhiệm của team DevSecOps tại Techcombank.
Version control
Khi mọi thứ được tự động hoá, thứ quan trọng nhất cần được track đó là các thay đổi (changes). Mỗi hành động tạo ra changes phải được quản lý bởi version, cũng giống như version control khi code vậy. Việc versioning này sẽ giúp ta ghi lại được lịch sử thực hiện cũng như dễ dàng khi khôi phục lại. Để đáp ứng yếu tố này, DevSecOps team ở Techcombank đã xây dựng một hệ thống Gitlab private nhằm lưu trữ tất cả các mã nguồn được viết ra bởi developer.
Tích hợp
Security cần phải được đưa vào quá trình phát triển sản phẩm sớm nhất có thể, ngay từ bước thiết kế. Phương pháp này được gọi là “shift left” hay “shift security to the left”.
Techcombank áp dụng những công cụ rà soát an ninh thông tin tự động ngay từ giai đoạn đầu của việc phát triển ứng dụng. Điều này vừa giúp những vấn đề về an ninh được phát hiện và ngăn chặn sớm, đồng thời cũng giúp các developer có nhận thức tốt hơn về việc viết code an toàn.
Compliance
Tuân thủ compliance là điều bắt buộc. Nếu nền móng về yếu tố con người đã được thực hiện tốt trước đó, thì việc tuyên truyền về việc tuân thủ compliance sẽ trở nên rất đơn giản và hiệu quả. Bên cạnh đó, compliance có thể không chỉ là các văn bản quy phạm. Ta hoàn toàn có thể xây dựng các metadata biểu diễn cho các compliance requirement và đưa vào các security policy để thực hiện tự động hoá.
Xử lý sự cố
Phản ứng với các sự cố liên quan tới an ninh thông tin không nên là tạm bợ nhất thời. Thay vào đó, việc xây dựng workflow, action plan, runbook, playbook luôn cần được chuẩn bị sẵn sàng từ trước. Điều này sẽ đảm bảo việc phản ứng với các sự cố trở nên có tính chắc chắn, có khả năng đo đếm và nhanh chóng hơn. Theo quy trình và tiêu chuẩn DevSecOps tại Techcombank, các kịch bản khôi phục sự cố cần được thực hiện dưới dạng code và tự động thông qua CI/CD pipeline. Điều này sẽ giúp việc ứng phó sự cố hệ thống trên môi trường live được thực hiện nhanh chóng hơn và số lượng sự cố trong quá trình triển khai cũng sẽ giảm đi.
Yếu tố công nghệ
Công nghệ là thứ cho phép mọi người thực hiện được các quy trình DevSecOps. Đây cũng là yếu tố cuối cùng quyết định việc áp dụng DevSecOps của một tổ chức có đủ trưởng thành, có thành công hay không.
Tự động hóa việc quản lý cấu hình
Tổ chức quản lý và tự động hóa việc quản lý cấu hình dưới dạng code sẽ giúp việc audit, việc đảm bảo baseline, compliance trở nên dễ dàng hơn rất nhiều. Các template dưới dạng code được đưa ra giúp việc rà soát các thay đổi được kiểm soát qua version control, rollback, phục hồi cũng trở nên rất nhanh chóng.
Tại Techcombank, Puppet được sử dụng như là một công cụ kiểm soát cấu hình. Các cấu hình đạt tiêu chuẩn baseline sẽ được định nghĩa trước và quản trị thông qua Puppet. Mọi hành vi cố ý thay đổi ngoài baseline sẽ luôn được phục hồi lại nhanh chóng.
Host hardening
Trước khi bảo mật đến tầng ứng dụng, tầng OS cần phải được an toàn trước. Có vô số những sự cố an ninh bắt nguồn từ việc host, đặc biệt là các host bị expose ra internet, bị khai thác. Do đó, một hardening checklist là rất cần thiết trong việc xây dựng template cũng như trust model cho việc cấu hình host. Kết hợp với tự động hóa việc quản lý cấu hình, host sẽ luôn được đảm bảo ở trạng thái an toàn cao nhất.
Audit và scan tại tầng ứng dụng
Việc thực hiện audit và scan liên tục là một phương diện thiết yếu của DevSecOps, giúp cho tổ chức hiểu được rõ ràng về các mối nguy. Các giải pháp hiện tại ở Techcombank gồm có:
- Quét mã nguồn: Việc quét mã nguồn có thể được thực hiện bằng cách áp dụng các SAST tool (Static Application Security Testing). SAST tool phân tích mã nguồn của dự án để xác định ra các lỗi liên quan đến bảo mật trong code cũng như vấn đề của các dependency và library mà ứng dụng sử dụng. Các công cụ được DevSecOps team đưa vào tiêu chuẩn gồm có SonarQube và Synopsys Coverity.
- Tích hợp vào IDE: Mọi developer đều cần sử dụng IDE trong việc code. Sử dụng một số plugin trong IDE sẽ giúp ngăn chặn một phần lỗi trong code ngay từ máy cá nhân của developer trước khi cả commit code lên repository. Hiện tại, việc ngăn chặn này đang được thực hiện bằng pre-commit và sắp tới là SonarLint
- Binary scanning: Các package của ứng dụng sau khi được build ra cần phải được rà quét lại dưới dạng binary bằng Synopsys BlackDuck. Việc một lần nữa rà quét lại bản build này giúp đảm bảo chắc chắn rằng phần mềm kể cả đã đóng gói cũng đảm bảo an toàn thông tin.
- Audit trước và sau triển khai: Thêm một bước audit trước và sau triển khai sẽ đảm bảo ứng dụng an toàn tại day-0 và cả day-1 khi triển khai.
Quản lý secret
Secret và credential là các dữ liệu nhạy cảm hoặc thậm chí là tối mật được sử dụng cho ứng dụng. Trong quá trình thực hiện CI/CD, việc sử dụng đến các secret hay credential là một việc thường xuyên xảy ra. Do vậy, sử dụng các công cụ mã hoá và lưu trữ các dạng dữ liệu này là tối quan trọng, đặc biệt trong CI/CD pipeline. Các công cụ, nền tảng hỗ trợ cho việc này đang được áp dụng tại Techcombank có thể kể đến như HashiCorp Vault, AWS Secrets Manager, GPG, Ansible Vault…
Tổng kết
DevSecOps chuyển dịch security từ phản ứng sang chủ động tham gia vào quy trình phát triển phần mềm. Những ưu điểm mà DevSecOps mang lại cho tổ chức là rất nhiều, bao gồm giảm thiểu chi phí, tăng tốc độ triển khai, tăng tốc độ phục hồi, kiểm soát và truy tìm các mối nguy. DevSecOps cũng phá bỏ đi rào cản giữa DevOps và Security, giúp tất cả cùng hoạt động hướng tới những mục tiêu chung của tổ chức.
Các cơ hội việc làm tại Techcombank
Expert, Software Engineering (Data Operations)
Quận Cầu Giấy, Hà Nội - Quận 1, Hồ Chí Minh
Ngân Hàng
Bài viết liên quan
Hơn cả một phương pháp, DevSecOps chính là “triết lý bảo mật” tại Techcombank
